headers
Joseph S. Myers | 1 Jan 2011 02:16

kfreebsd-gnu etc. issues

I'm trying to stop non-Linux GCC targets from using config/linux.h and
other headers whose names indicate they relate to the Linux kernel,
separating GNU-userspace and Linux-kernel configuration more cleanly.
<http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02055.html> is the
initial patch in this series, and in the course of working on the
corresponding changes for i386/linux.h and i386/linux64.h I found
several possible problems with the configurations for *-kfreebsd-gnu,
*-knetbsd-gnu and *-kopensolaris-gnu.

* The headers config/kfreebsd-gnu.h etc. override
  GLIBC_DYNAMIC_LINKER.  But the 64-bit configurations
  x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to
  use any header that would override GLIBC_DYNAMIC_LINKER32 and
  GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h
  actually uses.  Thus those configurations would use Linux-specific
  dynamic linker settings, which seems unlikely to be as intended.

* These configurations use file_end_indicate_exec_stack to use the
  PT_GNU_STACK convention.  While some of the implementation of this
  is in the GNU linker and glibc, it also requires kernel support for
  correct operation.  Do all these kernels support this convention, or
  should this code actually be disabled for them in GCC and glibc?

* The kfreebsd-gnu and knetbsd-gnu configurations use linux-unwind.h
  (kopensolaris-gnu disables this).  They define REG_NAME to adapt
  linux-unwind.h to their system headers.  But linux-unwind.h also
  contains hardcoded checks for the particular instructions, complete
  with hardcoded Linux syscall numbers, in Linux signal trampolines.
  Do the FreeBSD and NetBSD kernels really use identical instructions?
  Does this code do anything useful on those systems?  If it's useful
(Continue reading)

Permalink | Reply | 11 comments |
headers
Dongsheng Song | 1 Jan 2011 04:43
Picon

Fwd: r168382 - in /trunk/libstdc++-v3: ChangeLog Mak...

I think gcc-cvs mail list should set reply address to gcc <at> gcc.gnu.org
instead of gcc-cvs <at> gcc.gnu.org.

---------- Forwarded message ----------
From: Dongsheng Song <dongsheng.song <at> gmail.com>
Date: Sat, Jan 1, 2011 at 11:29
Subject: Re: r168382 - in /trunk/libstdc++-v3: ChangeLog Mak...
To: bkoz <at> gcc.gnu.org
Cc: gcc-cvs <at> gcc.gnu.org

Hi Benjamin,

Your commit have 2 drawbacks:

1.  insufficient docbook xsl path checker (trunk/libstdc++-v3/configure.ac)

# Check for docbook
AC_CHECK_PROG([XSLTPROC], xsltproc, yes, no)
AC_CHECK_PROG([XMLLINT], xmllint, yes, no)
AC_CHECK_FILE([/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION],
             [glibcxx_stylesheets=yes], [glibcxx_stylesheets=no])

For Debian, here is the correct path:
-rw-r--r-- 1 root root 4510 Jul 22  2009
/usr/share/xml/docbook/stylesheet/docbook-xsl-ns/VERSION
-rw-r--r-- 1 root root 4504 Jul 21  2009
/usr/share/xml/docbook/stylesheet/docbook-xsl/VERSION

2.  break cross compiling (trunk/libstdc++-v3/configure)
(Continue reading)

Permalink | Reply | 2 comments |
headers
gccadmin | 1 Jan 2011 23:48
Picon
Favicon

gcc-4.6-20110101 is now available

Snapshot gcc-4.6-20110101 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110101/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 168391

You'll find:

 gcc-4.6-20110101.tar.bz2             Complete GCC (includes all of below)

  MD5=0e9735595eeb4c50dc57e039610f313a
  SHA1=316f67d75c2c8a0e9df7e06d1bdf895b9af2a419

 gcc-core-4.6-20110101.tar.bz2        C front end and core compiler

  MD5=b3b4206c5f2110690d0398cf290dfd1b
  SHA1=31355804f297475530c03066ed22d3c90fc341c7

 gcc-ada-4.6-20110101.tar.bz2         Ada front end and runtime

  MD5=0d62d5f27de1e6eeba2c50ae7695cf35
  SHA1=150a4cf81cb587a09ca4601355364f04cfa97f24

 gcc-fortran-4.6-20110101.tar.bz2     Fortran front end and runtime

  MD5=96dff268cbcaedea8bb45c44bacfac42
  SHA1=3d7763a09094f56277dfd6c4a61bf700d8a722df

 gcc-g++-4.6-20110101.tar.bz2         C++ front end and runtime
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Guenther | 2 Jan 2011 16:55
Picon

Re: cloog(-parma) 0.16 and ppl 0.11 in infrastructure?

On Fri, Dec 31, 2010 at 12:40 AM, Jack Howarth <howarth <at> bromo.med.uc.edu> wrote:
> Sebastian,
>    It appears that the official tarballs are now posted at http://www.cloog.org/
> for cloog and cloog-parma 0.16. Do you plan on placing those both in the infrastructure
> directory at gcc.gnu.org's ftp site? If so, the newer ppl 0.11 tarball should be added
> as well. If those files are updated, we should be set to switch gcc trunk to require
> ppl >= 0.11, cloog >= 0.16 and the default cloog backend from legacy cloog-ppl to
> cloog-isl.

I don't think this is a very good idea at this point.

Richard.

>          Jack
>
>
Permalink | Reply | 3 comments |
headers
Richard Guenther | 2 Jan 2011 16:59
Picon

Re: [wwwdocs] PATCH for Re: rsync'd repo size

On Fri, Dec 31, 2010 at 8:07 PM, Mike Stump <mikestump <at> comcast.net> wrote:
> On Dec 31, 2010, at 8:27 AM, Gerald Pfeifer wrote:
>> On Wed, 8 Dec 2010, DJ Delorie wrote:
>>> http://gcc.gnu.org/rsync.html says 17 Gb.
>>>
>>> I just did it, and it's up to 22 Gb.
>>
>> Thanks for the heads up, DJ!  I had a look, and it is, in fact,
>> 184 Gb as of today, or 23 GB.  (SCNR. :-)
>
> You can replace it with a equation that has a year in it, that way, you don't have to fix it as often...  :-)

Or just use a date instead of "today".  Or say "more than 23 GB" which also
stays true ;)

Richard.
Permalink | Reply | 1 comment |
headers
Ralf Wildenhues | 2 Jan 2011 17:01
Picon
Picon

development stage timeline

Is there an expected date for when stage 3 should end, or some other
measure of pressure?  The 4.6.0 status report link on gcc.gnu.org does
not seem to tell (and I'm not sure whether it usually does or not).

It would be good to get Libtool updated before, but I'm not sure I can
finish it this weekend.

Thanks (and sorry for not following irc, and happy gnu year!),
Ralf
Permalink | Reply | 1 comment |
headers
Richard Guenther | 2 Jan 2011 17:03
Picon

Re: Behavior change of driver on multiple input assembly files

On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu <hjl.tools <at> gmail.com> wrote:
> On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang <jie <at> codesourcery.com> wrote:
>> On 12/31/2010 01:07 PM, Jie Zhang wrote:
>>>
>>> I just found a behavior change of driver on multiple input assembly
>>> files. Previously (before r164357), for the command line
>>>
>>> gcc -o t t1.s t2.s
>>>
>>> , the driver will call assembler twice, once for t1.s and once for t2.s.
>>> After r164357, the driver will only call assembler once for t1.s and
>>> t2.s. Then if t1.s and t2.s have same symbol, assembler will report an
>>> error, like:
>>>
>>> t2.s: Assembler messages:
>>> t2.s:1: Error: symbol `.L1' is already defined
>>>
>>> I read the discussion on the mailing list starting by the patch email of
>>> r164357.[1] It seems that this behavior change is not the intention of
>>> that patch. And I think the previous behavior is more useful than the
>>> current behavior. So it's good to restore the previous behavior, isn't?
>>>
>>> For a minimal fix, I propose to change combinable fields of assembly
>>> languages in default_compilers[] to 0. See the attached patch
>>> "gcc-not-combine-assembly-inputs.diff". I don't know why the combinable
>>> fields were set to 1 when --combine option was introduced. There is no
>>> explanation about that in that patch email.[2] Does anyone still remember?
>>>
>>> For an aggressive fix, how about removing the combinable field from
>>> "struct compiler"? If we change combinable fields of assembly languages
(Continue reading)

Permalink | Reply | 15 comments |
headers
Richard Guenther | 2 Jan 2011 17:16
Picon

Re: development stage timeline

On Sun, Jan 2, 2011 at 5:01 PM, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
> Is there an expected date for when stage 3 should end, or some other
> measure of pressure?  The 4.6.0 status report link on gcc.gnu.org does
> not seem to tell (and I'm not sure whether it usually does or not).
>
> It would be good to get Libtool updated before, but I'm not sure I can
> finish it this weekend.

It's expected to end as soon as one of the RMs manages to do a status
report.  Which means very likely (early) this week.

Richard.

> Thanks (and sorry for not following irc, and happy gnu year!),
> Ralf
>
Permalink | Reply | 0 comments |
headers
Dennis Clarke | 2 Jan 2011 17:21

Re: cloog(-parma) 0.16 and ppl 0.11 in infrastructure?


> On Fri, Dec 31, 2010 at 12:40 AM, Jack Howarth <howarth <at> bromo.med.uc.edu>
> wrote:
>> Sebastian,
>>    It appears that the official tarballs are now posted at
>> http://www.cloog.org/
>> for cloog and cloog-parma 0.16. Do you plan on placing those both in the
>> infrastructure
>> directory at gcc.gnu.org's ftp site? If so, the newer ppl 0.11 tarball
>> should be added
>> as well. If those files are updated, we should be set to switch gcc
>> trunk to require
>> ppl >= 0.11, cloog >= 0.16 and the default cloog backend from legacy
>> cloog-ppl to
>> cloog-isl.
>
> I don't think this is a very good idea at this point.

I think ppl is in a stae of change and between releases. I have not yet
seen it compile cleanly once with any version of GCC on Solaris. It
certainly never passes its own testsuites without a coredump or some
significant failure. Roberto Bagnara is aware of this and I am going to
work with him on this to get something valid in the POSIX/UNIX world and
hopefully a new release of ppl will come out that is solid for integration
into GCC. As for ClooG, I have no data at this time. This is merely an
observation from someone that tries to be very very careful with testing
and with testsuite results.

--

-- 
Dennis Clarke
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.J. Lu | 2 Jan 2011 17:31
Picon

Re: Behavior change of driver on multiple input assembly files

On Sun, Jan 2, 2011 at 8:03 AM, Richard Guenther
<richard.guenther <at> gmail.com> wrote:
> On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu <hjl.tools <at> gmail.com> wrote:
>> On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang <jie <at> codesourcery.com> wrote:
>>> On 12/31/2010 01:07 PM, Jie Zhang wrote:
>>>>
>>>> I just found a behavior change of driver on multiple input assembly
>>>> files. Previously (before r164357), for the command line
>>>>
>>>> gcc -o t t1.s t2.s
>>>>
>>>> , the driver will call assembler twice, once for t1.s and once for t2.s.
>>>> After r164357, the driver will only call assembler once for t1.s and
>>>> t2.s. Then if t1.s and t2.s have same symbol, assembler will report an
>>>> error, like:
>>>>
>>>> t2.s: Assembler messages:
>>>> t2.s:1: Error: symbol `.L1' is already defined
>>>>
>>>> I read the discussion on the mailing list starting by the patch email of
>>>> r164357.[1] It seems that this behavior change is not the intention of
>>>> that patch. And I think the previous behavior is more useful than the
>>>> current behavior. So it's good to restore the previous behavior, isn't?
>>>>
>>>> For a minimal fix, I propose to change combinable fields of assembly
>>>> languages in default_compilers[] to 0. See the attached patch
>>>> "gcc-not-combine-assembly-inputs.diff". I don't know why the combinable
>>>> fields were set to 1 when --combine option was introduced. There is no
>>>> explanation about that in that patch email.[2] Does anyone still remember?
>>>>
(Continue reading)

Permalink | Reply | 14 comments |

Gmane