headers
gccadmin | 1 May 2005 01:49
Picon
Favicon

gcc-4.0-20050430 is now available

Snapshot gcc-4.0-20050430 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050430/
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)

Permalink | Reply | 0 comments |
headers
Jason Thorpe | 1 May 2005 03:51

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
Permalink | Reply | 1 comment |
headers
Vladimir A. Merzliakov | 1 May 2005 01:06
Picon

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)

Vladimir
Attachment (12077.log): application/octet-stream, 8 KiB
Permalink | Reply | 1 comment |
headers
Paolo Carlini | 1 May 2005 01:13
Picon

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,
Paolo.
Permalink | Reply | 0 comments |
headers
Bill Northcott | 1 May 2005 04:51
Picon
Picon
Favicon

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  
functional?

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
Permalink | Reply | 2 comments |
headers
Andrew Pinski | 1 May 2005 04:57
Picon

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
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 May 2005 05:48
Picon
Favicon

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)

Permalink | Reply | 3 comments |
headers
Ayal Zaks | 1 May 2005 10:58
Picon
Favicon

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.

Ayal.
Permalink | Reply | 0 comments |
headers
Andrew Haley | 1 May 2005 11:15
Picon
Favicon

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.

Andrew.
Permalink | Reply | 2 comments |
headers
Gerald Pfeifer | 1 May 2005 15:45

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

Gerald

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)

Permalink | Reply | 4 comments |

Gmane