gccadmin | 1 May 01:49 2005

gcc-4.0-20050430 is now available

Snapshot gcc-4.0-20050430 is now available on
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050430 

You'll find:

gcc-4.0-20050430.tar.bz2              Complete GCC (includes all of below)

gcc-core-4.0-20050430.tar.bz2         C front end and core compiler

gcc-ada-4.0-20050430.tar.bz2          Ada front end and runtime

gcc-fortran-4.0-20050430.tar.bz2      Fortran front end and runtime

gcc-g++-4.0-20050430.tar.bz2          C++ front end and runtime

gcc-java-4.0-20050430.tar.bz2         Java front end and runtime

gcc-objc-4.0-20050430.tar.bz2         Objective-C front end and runtime

gcc-testsuite-4.0-20050430.tar.bz2    The GCC testsuite

Diffs from 4.0-20050423 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.0
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.
(Continue reading)

Jason Thorpe | 1 May 03:51 2005

Re: GCC 4.1: Buildable on GHz machines only?

On Apr 30, 2005, at 12:33 PM, Giovanni Bajo wrote:

> I would also like to note that I *myself* requested preprocessed  
> source code to
> NetBSD developers at least 6 times in the past 2 years. I am sure  
> Andrew Pinski
> did too, a comparable amound of times. These requests, as far as I can
> understand, were never answered. This also helped building up a  
> stereotype of
> the average NetBSD developer being "just a GCC whine troll".

While I have not had much time for a quite a while to work on GCC  
myself, I am listed as NetBSD maintainer... you can always drop me a  
note directly when this sort of thing happens.

-- thorpej

Vladimir A. Merzliakov | 1 May 01:06 2005

Re: ext/stdio_sync_filebuf/wchar_t/12077.cc

> it looks like in mainline this test recently started failing at compile 
> time on  some machines. I'm puzzled, unfortunately cannot reproduce the 
> problem and would be grateful is someone could send me (either privately 
> or in public) more information (e.g., an extract from libstdc++.log, at 
> least).

At FreeBSD 5.3 this testcase failed with gcc version 4.1.0 20050429 
(extracted log attached)

Attachment (12077.log): application/octet-stream, 9 KiB
Paolo Carlini | 1 May 01:13 2005

Re: ext/stdio_sync_filebuf/wchar_t/12077.cc

Vladimir A. Merzliakov wrote:

> At FreeBSD 5.3 this testcase failed with gcc version 4.1.0 20050429
> (extracted log attached)

Ah! Thanks a lot Vladimir: now it's also obvious why I'm not seeing it:
often, while working hard on the library, I don't update the compiler
proper every day.

I'm not sure whether we should file a specific PR for this ICE: people
working on compiler patches are supposed to regtest the library too... ;)

Thanks again,

Bill Northcott | 1 May 04:51 2005

Re: PPC 64bit library status?

On 01/05/2005, at 1:11 AM, Andrew Pinski wrote:
>>> Even if the libraries build, will libffi or libobjc work on 64 bit
>>> PPC????  Since I don't have access to a 64 bit PPC machine I cannot
>>> test this.
> There was some talk about this earlier this year and then the support
> for building the 64bit libraries on darwin was turned off for both the
> 4.0.0 release and on the mainline.

That much was sort of obvious.  However, if they are enabled in the  
build, libobjc and libgfortran do build.  Are they likely to be  

Libffi does not build using the -m64 flag on the compiler.
> Note why again are you using Apple's branch.  It does not get all  
> fixes
> which the 4.0 release branch will get.
Basically my logic is fairly simple.  If I use Apple's OS, I feel  
happier using their compiler.  While that creates some problems, it  
avoids others like the restFP,savFP issue.

The code I am using was synced to the release gcc-4.0.0 on 20 April.   
So it is not that out of date.

Bill Northcott

Andrew Pinski | 1 May 04:57 2005

Re: PPC 64bit library status?

On Apr 30, 2005, at 10:51 PM, Bill Northcott wrote:

> Basically my logic is fairly simple.  If I use Apple's OS, I feel 
> happier using their compiler.  While that creates some problems, it 
> avoids others like the restFP,savFP issue.

The restFP/saveFP issue has been resolved since
2004-03-31  Andrew Pinski  <pinskia <at> physics.uc.edu>

         * config/rs6000/t-darwin (LIB2FUNCS_STATIC_EXTRA):
         Add darwin-fpsave.asm, darwin-vecsave.asm,
         and darwin-world.asm.
         (TARGET_LIBGCC2_CFLAGS): Add -Wa,-force_cpusubtype_ALL
         as the asm files contain altivec instructions.
         * config/rs6000/darwin-fpsave.asm: New file.
         * config/rs6000/darwin-vecsave.asm: New file.
         * config/rs6000/darwin-world.asm: New file.

-- Pinski

Richard Henderson | 1 May 05:48 2005

libjava build times

On Sat, Apr 30, 2005 at 10:33:43AM +0100, Andrew Haley wrote:
> OK, so the low-hanging fruit that remains is the libtools script and
> the linker.  In the latter case, it seems that the big link causes
> severe problems with small memory systems.

I did some experiments today just to see what kind of time it actually
takes to compile the actual objects, and thus how much time is on the
table to be retrieved from libtool.

The following was performed on a 2.3Ghz G5, with 2G of ram.  So I'm
not swapping and in fact everything can reside in cache.  I.e. just
about the ideal setup.  There are in fact two cpus, but I'm not using
the -j option to make at all.

I began by building the whole of libjava, and then using find to 
delete all of *.o *.lo *.a *.la.  I then timed rebuilding the library:

  2248.43user 661.42system 47:46.01elapsed 101%CPU (0major+47501310minor)

Next, I canibalized the makefile in order to bypass libtool, and invoke
gcc directly.  My solution does assume gnu ld and ar, but this is just
a test after all.

  -O2 -fPIC compile
  824.80user 86.88system 15:11.69elapsed 99%CPU (0major+7102491minor)

  .so link + .a create
  10.45user 9.59system 0:19.97elapsed 100%CPU (0major+851815minor)

Now, unless I've done something drastically wrong, it appears as if we
(Continue reading)

Ayal Zaks | 1 May 10:58 2005

Fw: Store scheduling with DFA scheduler

As you noted, when the scheduler decides between stores and adds it always
prefers the adds (first at t = 5), due to its critical path heuristic. In
Jon's example, stores seem "costly" as one cannot issue a load or store
immediately following a store. Perhaps the scheduler could take the
(resource-related) "cost" of candidates into consideration (in addition to
their latency-related critical path) when making such decisions. Still
heuristically speaking, of-course.


Andrew Haley | 1 May 11:15 2005

Re: libjava build times

Richard Henderson writes:
 > Now, unless I've done something drastically wrong, it appears as if we
 > are spending 2/3 of our time in the libtool script.

Yes, that's right.  That's similar to what my oprofile experiments suggest.


Gerald Pfeifer | 1 May 15:45 2005

Re: i?86-*-sco3.2v5* / i?86-*-solaris2.10 / x86_64-*-*, amd64-*-*

On Fri, 29 Apr 2005, Dimitri Papadopoulos-Orfanos wrote:
> Some links are broken on this page:
> 	http://gcc.gnu.org/install/specific.html
> Specifically:
> 	i?86-*-sco3.2v5*
> 	i?86-*-solaris2.10
> 	x86_64-*-*, amd64-*-*
> 	all ELF targets

That's even further collateral damage caused by the design changes in
recent versions of GNU makeinfo for strict HTML/XHTML support. :-(

Thanks for the clear report, Dimitri.  I just installed the following
change to mainline (which will become GCC 4.1) and will shortly do the
same on the 4.0 branch.  Please allow up to 24 hours until this has
propagated to the http://gcc.gnu.org/install/specific.html web page.

I tested this patch by running gcc/doc/install.texi2html and also
verified that the changed links still work when using makeinfo 4.5


2005-05-01  Gerald Pfeifer  <gerald <at> pfeifer.com>

	* doc/install.texi (Specific): Omit dots in the  <at> anchors names
	for i?86-*-sco3.2v5*, i?86-*-solaris2.10, and sparc-sun-solaris2.7.
	Omit underscores for x86_64-*-* and the "all ELF targets" entry.

Index: doc/install.texi
(Continue reading)