Re: GCC 4.0 RC1 Available

[Eric Botcazou]

> We severely regressed for Java (22*2 new failures) 3 days ago.

Ugh.  Not very surprising, given that a jumbo patch landed by that time:

2005-04-06  Tom Tromey  <[EMAIL PROTECTED]>

* Makefile.in: Rebuilt.
* Makefile.am (lib_gnu_java_awt_peer_gtk_la_SOURCES): Removed
gtk_awt_peer_sources.
(lib_gnu_java_awt_peer_gtk_la_LIBADD): Added gtk-awt-peer.lo.
(lib_gnu_java_awt_peer_gtk_la_DEPENDENCIES): Likewise.
($(gtk_awt_peer_sources:.java=.lo)): Removed.
(gtk-awt-peer.lo): New target.

* java/lang/natVMClassLoader.cc (getSystemClassLoaderInternal):
Updated for name change.
(nativeFindClass): New method.
(loadClass): Use nativeFindClass.
* java/lang/natClassLoader.cc (_Jv_FindClass): Use single-argument
form of loadClass.
* java/lang/VMClassLoader.java (tried_libraries, lib_control,
LIB_FULL, LIB_CACHE, LIB_NEVER): New fields from old
VMClassLoader.
(initialize): New method.
(nativeFindClass): Declare.
* gnu/gcj/runtime/natVMClassLoader.cc: Removed.
* gnu/gcj/runtime/VMClassLoader.java: Removed.
* gnu/gcj/runtime/ExtensionClassLoader.java: Renamed from
VMClassLoader.java.
(definePackageForNative): Removed.
(tried_libraries, LIB_CACHE, LIB_FULL, LIB_NEVER, lib_control):
Moved to VMClassLoader.java.
* prims.cc (_Jv_CreateJavaVM): Updated for renaming.
* Makefile.am (gnu/gcj/runtime/ExtensionClassLoader.h): Renamed.
(ordinary_java_source_files): Added ExtensionClassLoader.java,
removed VMClassLoader.java.
(nat_source_files): Removed natVMClassLoader.cc.

* java/lang/natRuntime.cc (insertSystemProperties): Set
gnu.gcj.runtime.endorsed.dirs.
* Makefile.in: Rebuilt.
* Makefile.am (ordinary_java_source_files): Added
HelperClassLoader.java.
(AM_CXXFLAGS): Define GCJ_ENDORSED_DIRS.
* gnu/gcj/runtime/VMClassLoader.java (VMClassLoader): Extends
HelperClassLoader.
(init): Use addDirectoriesFromProperty.
* gnu/gcj/runtime/BootClassLoader.java (BootClassLoader): Extends
HelperClassLoader.  Use addDirectoriesFromProperty.  Handle
gnu.gcj.runtime.endorsed.dirs.
* gnu/gcj/runtime/HelperClassLoader.java: New file.

* gnu/gcj/runtime/BootClassLoader.java (BootClassLoader): Don't
add sax and w3c libraries.
* Makefile.am (libgij_la_LIBADD): Added libsax-gcj.la and
libw3c-gcj.la.
* external/w3c_dom/Makefile.in: Rebuilt.
* external/w3c_dom/Makefile.am (libw3c_gcj_la_GCJFLAGS): Include
AM_GCJFLAGS.
(libw3c_gcj_la_LDFLAGS): New variable.
(noinst_LTLIBRARIES): Renamed.
* external/sax/Makefile.in: Rebuilt.
* external/sax/Makefile.am (libsax_gcj_la_GCJFLAGS): Include
AM_GCJFLAGS.
(libsax_gcj_la_LDFLAGS): New variable.
(noinst_LTLIBRARIES): Renamed.

* Makefile.in: Rebuilt.
* Makefile.am (AM_CXXFLAGS): Define TOOLEXECLIBDIR.
(libgcj0_convenience_la_SOURCES): Don't include
gnu_xml_source_files.
(libgcj0_convenience_la_LIBADD): New variable.
(libgcj_la_LIBADD): Don't include sax or w3c_dom.
(all_java_source_files): javax_imageio_source_files,
javax_xml_source_files, and gnu_java_beans_source_files.
($(gnu_xml_source_files:.java=.lo)): Removed target.
(gnu-xml.lo): New target.
(javax-imageio.lo): Likewise.
(javax-xml.lo): Likewise.
(gnu-java-beans.lo): Likewise.
(gnu_java_beans_source_files): New variable.
(javax_imageio_source_files): Likewise.
(javax_xml_source_files): Likewise.
(javax_source_files): Moved files to other variable.
(awt_java_source_files): Likewise.
(ordinary_java_source_files): Added BootClassLoader.java.
* java/lang/natVMClassLoader.cc (defineClass): Use boot loader,
not system class loader.
(initBootLoader): New method.
(loadClass): Search bootLoader.
* java/lang/natClassLoader.cc (_Jv_RegisterInitiatingLoader): Use
boot loader, not system class loader.
(_Jv_UnregisterInitiatingLoader): Likewise.
(_Jv_FindClass): Likewise.  Ensure entries in
bootstrap_class_list are unique.
* java/lang/natClass.cc (getClassLoader): Don't special case
system class loader.
* java/lang/VMClassLoader.java (bootLoader): New field.
(getResource): Use bootLoader.
(getResources): Likewise.
(initBootLoader): Declare.
* gnu/gcj/runtime/BootClassLoader.java: New file.
* external/sax/org/xml/sax/helpers/NamespaceSupport.java
(EMPTY_ENUMERATION): Now package-private.
* external/w3c_com/Makefile.in: Rebuilt.
* external/w3c_com/Makefile.am (MULTIBUILDTOP): New variable.
(w3c.jar): New target

Re: GCC 4.0 RC1 Available

[Andrew Haley]

Eric Botcazou writes:
 >  > 
 > We severely regressed for Java (22*2 new failures) 3 days ago.

Please post the list of failures to [EMAIL PROTECTED]

Andrew.

Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Andrew Haley]

Mark Mitchell writes:
 > Your primary objective (get rid of -fno-unit-at-a-time) is one that I 
 > strongly support.

I have a problem with getting rid of -fno-unit-at-a-time.  Sometimes
we compile huge Java programs; however, keeping all the method bodies
consumes vast amouts of memory.  So, we sometimes need to generate
code for each class as soon as it is parsed and then free the bodies.

Might it still be possible for a front end to force all pending code
to be generated, even with -fno-unit-at-a-time gone?

Andrew.

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Steven Bosscher]

On Monday 11 April 2005 12:18, Andrew Haley wrote:
> Mark Mitchell writes:
>  > Your primary objective (get rid of -fno-unit-at-a-time) is one that I
>  > strongly support.
>
> I have a problem with getting rid of -fno-unit-at-a-time.  Sometimes
> we compile huge Java programs; however, keeping all the method bodies
> consumes vast amouts of memory. 

This is what C++ does now too.  Why would this be a problem
for Java but not for C++?

> So, we sometimes need to generate
> code for each class as soon as it is parsed and then free the bodies.

(The proper solution is of course to have an IR that we can
stream to disk, *sigh*  ;-)

Gr.
Steven

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Andrew Haley]

Steven Bosscher writes:
 > On Monday 11 April 2005 12:18, Andrew Haley wrote:
 > > Mark Mitchell writes:
 > >  > Your primary objective (get rid of -fno-unit-at-a-time) is one that I
 > >  > strongly support.
 > >
 > > I have a problem with getting rid of -fno-unit-at-a-time.  Sometimes
 > > we compile huge Java programs; however, keeping all the method bodies
 > > consumes vast amouts of memory. 
 > 
 > This is what C++ does now too.  Why would this be a problem
 > for Java but not for C++?

I don't know why it's not a problem for C++; I do know why it's a
problem for Java.  Perhaps the files we're compiling are larger.
Certainly jarfiles can get to be very large, and once gcc's store
starts to exceed the size of physical memory things can get very
painful.

Andrew.

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Nathan Sidwell]

Andrew Haley wrote:
Might it still be possible for a front end to force all pending code
to be generated, even with -fno-unit-at-a-time gone?
I think this is a bad idea.  You're essentially asking for the backend
to retain all the functionality of -fno-unit-at-a-time.
Might I refer you to Mike Stump's answer regarding swap :)
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Mostafa Hagog]

Andrew Haley wrote on 11/04/2005 13:31:52:

> Steven Bosscher writes:
>  >
>  > This is what C++ does now too.  Why would this be a problem
>  > for Java but not for C++?
>
> I don't know why it's not a problem for C++; I do know why it's a
> problem for Java.  Perhaps the files we're compiling are larger.
> Certainly jarfiles can get to be very large, and once gcc's store
> starts to exceed the size of physical memory things can get very
> painful.
>
...
> Steven Bosscher wrote:
>
> > (The proper solution is of course to have an IR that we can
> > stream to disk, *sigh*  ;-)

If a program's memory usage exceeds the physical memory, then it will be
paged in and out to the disk by the OS, and if the OS's paging algorithm
doesn't fit well the program it will be painful.  IMHO, streaming the
memory used by GCC to disk or letting the OS page it in/out can introduce
the same problem; we aren't solving the problem we are moving the
responsibility of solving it from the OS side to GCC's side.
Moreover, it sounds to me that the way we jump from one function/class to
the other should be paging (and cache) friendly; we usually do a lot of
things to one class before we move to the other; that is the expected
behavior from programs from the side of the OS (the paging system). So what
am I missing here?

Mostafa.

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Gabriel Dos Reis]

Nathan Sidwell <[EMAIL PROTECTED]> writes:

| Andrew Haley wrote:
| 
| > Might it still be possible for a front end to force all pending code
| > to be generated, even with -fno-unit-at-a-time gone?
| 
| I think this is a bad idea.  You're essentially asking for the backend
| to retain all the functionality of -fno-unit-at-a-time.
| 
| Might I refer you to Mike Stump's answer regarding swap :)

That might sound funny the first time.  But when it becomes a recurring
answer, it reaaly IS UNPLEASANT.

Yes, I noticed the smiley but, this is at least the second the time,
in a relatively short timeframe, you're making similar answers to
reasonable concerns and I would hate it becomes a canonical answer to
whatever concerns. 

Apart from that, I believe different front-ends may have different
constraints as is the case for the Java vs. C++ front-ends, having to
do with language semantics.

-- Gaby

Re: reload-branch created

[Bernd Schmidt]

Ulrich Weigand wrote:
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html
  there is a code path in find_reloads that sets rld[].inc to a
  nonzero value even for a platform that doesn't actually *have*
  pre-/post-increment insns, leading to an ICE later on.

Index: gcc/reload.c
===
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.268.6.1
diff -c -p -r1.268.6.1 reload.c
*** gcc/reload.c	18 Mar 2005 18:40:32 -	1.268.6.1
--- gcc/reload.c	18 Mar 2005 21:43:47 -
*** find_reloads (struct insn_chain *chain, 
*** 3215,3222 
  			 MODE_BASE_REG_CLASS (VOIDmode),
  			 GET_MODE (XEXP (recog_data.operand[i], 0)),
  			 VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
! 	rld[operand_reloadnum[i]].inc
! 	  = GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
  	  }
  	else if (goal_alternative_matched[i] == -1)
  	  {
--- 3215,3224 
  			 MODE_BASE_REG_CLASS (VOIDmode),
  			 GET_MODE (XEXP (recog_data.operand[i], 0)),
  			 VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
! 
! 	if (rld[operand_reloadnum[i]].inc)
! 	  rld[operand_reloadnum[i]].inc
! 	= GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
  	  }
  	else if (goal_alternative_matched[i] == -1)
  	  {
This is wrong.  inc is unconditionally cleared in push_reload, so it 
can't be nonzero here.

I did a bit of research into how autoinc is currently dealt with by 
reload.  The obscure "out && ! out_reg" test is used at the last stage, 
but this condition is set up a bit earlier in choose_reload_regs with a 
much more sensible test for PRE_DEC codes etc.

I guess the best solution is to change the place you modified, but to 
use a test that checks for autoinc codes.  I'll come up with something.

Bernd

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Andrew Haley]

Nathan Sidwell writes:
 > Andrew Haley wrote:
 > 
 > > Might it still be possible for a front end to force all pending code
 > > to be generated, even with -fno-unit-at-a-time gone?
 > 
 > I think this is a bad idea.  You're essentially asking for the backend
 > to retain all the functionality of -fno-unit-at-a-time.

OK.  So, what else?

 > Might I refer you to Mike Stump's answer regarding swap :)

I haven't seen it.

Andrew.

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Nathan Sidwell]

Andrew Haley wrote:
Nathan Sidwell writes:
 > Andrew Haley wrote:
 > 
 > > Might it still be possible for a front end to force all pending code
 > > to be generated, even with -fno-unit-at-a-time gone?
 > 
 > I think this is a bad idea.  You're essentially asking for the backend
 > to retain all the functionality of -fno-unit-at-a-time.

OK.  So, what else?
As steven asked, I'd like to understand why this is not a problem
for the C++ community.  There are several alternatives
1) The C++ programs are smaller than the java programs
2) the c++ representation is denser
3) the c++ users have more memory
4) The ones the C++ community *has* complained about are seen as
pathelogical cases or acknowledged IR deficiencies
5) The c++ community are too timid to complain
 > Might I refer you to Mike Stump's answer regarding swap :)
I haven't seen it.
It was basically 'get more memory'.  I'd like to understand if you're
really talking about 'when I compile this humungous source, I need
a lot of memory', or if it's 'when I compile this source, I use more
memory than is reasonable'.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: gcc-3.4-20050401 BUG? generates illegal instruction in X11R6.4.2/mkfontscale/freetypemacro (worksforme)

[Clemens Koller]

Hello again!
In the freetype-devel list, I got some suggestions:
This bug/problem seems to concentrate on ppc32/64 and s390 architectures.
Basically all Type1 fonts shipped with X11 are suspect to this
problem. I made tests agains UTBI.pfa
The possible (temporary)fix:
If I re-compile freetype with -fno-strict-aliasing I can get
mkfontscale to work!
It's still not clear whether this is a problem in freetype
(2.1.7 to 2.1.9 at least), the macros there, or in gcc.
Please see the following links for more information on
this problem (also referred as 'aliasing issues in freetype macros'):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118021
http://rpm.sh-linux.org/rpm-index-2004/sh4/freetype-utils-2.1.7-4.sh4.html
http://lists.freedesktop.org/pipermail/x-packagers/2004-March/10.html
https://svn.uludag.org.tr/paketler/trunk/media-libs/freetype/freetype-2.1.9-r1.ebuild
http://archives.devshed.com/a/ml/200408-12273/strange-compilation-on-PowerPC
And my thread in freetype-devel:
[ft-devel] Bug on PowerPC: Illegal Intruction in FT_Get_Name_Index
Currently don't feel confortable to deal with the freetype-type1-driver
code which seems pretty nasty. (I am not into font-writing at all).
Possible fixes might get discussed at the freetype-devel list.
Suggestions are welcome to further track down the problem.
But I first need to get X working on my platform...
Best greets,
Clemens Koller
___
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Clemens Koller wrote:
Hello, Dan!
I did some more debugging on that problem.
This bug was also reported on this list:
http://gcc.gnu.org/ml/gcc/2004-07/msg00861.html
To isolate it for the first step it's sufficient to only build
mkfontscale within <...>/xc/programs/mkfontscale
and then call it with mkfontscale Type1 (as mentioned below)
And then, the fun starts: (let me just recite the old mail)
Compilation of mkfontscale is ok, but its execution is quite strange.
In the source code of mkfontscale, a call to a function of freetype-2.1.9
is made : FT_Get_Name_Index() in freetype-2.1.9/src/base/ftobjs.c:3279
In the source code of this freetype function, a call to another function
of freetype is made : FT_FACE_LOOKUP_SERVICE()
The full code of the function FT_Get_Name_Index() is :
FT_EXPORT_DEF( FT_UInt )
 FT_Get_Name_Index( FT_Face face,
FT_String*  glyph_name )
 {
   FT_UInt  result = 0;
   if ( face && FT_HAS_GLYPH_NAMES( face ) )
   {
 FT_Service_GlyphDict  service;
 FT_FACE_LOOKUP_SERVICE( face,
 service,
 GLYPH_DICT );
 if ( service && service->name_index )
   result = service->name_index( face, glyph_name ); /*CRASHES HERE*/
   }
   return result;
 }
I am not finished with anlysing the code...
but on my target it crashes on the same place after the
0xff4a988 :  blrl
instruction. So, it jumps out of executable code
to some 0x10034cxxsomething until it hits an illegal
instruction (after about 4 steps).
(ppc, mpc8540, gcc-3.4-20040401 or gcc-3.4.3, binutils-2.15.96)
So, the first basic question: Is the above code okay?
Is the stack just trashes? I am not much into ppc assembly
code. Maybe I need a helping hand.
I can also let you ssh onto that machine if it's of
any use.
For me, I try to get what you said...

Thank you, so far!
Clemens
Dump of assembler code for function FT_Get_Name_Index:
0xff4a8d8 :  stwur1,-32(r1)
0xff4a8dc :mflrr0
0xff4a8e0 :bcl-20,4*cr7+so,0xff4a8e4 

0xff4a8e4 :   stw r30,24(r1)
0xff4a8e8 :   mflrr30
0xff4a8ec :   stw r31,28(r1)
0xff4a8f0 :   mr. r31,r3
0xff4a8f4 :   stw r0,36(r1)
0xff4a8f8 :   stw r28,16(r1)
0xff4a8fc :   li  r28,0
0xff4a900 :   lwz r0,-16(r30)
0xff4a904 :   stw r29,20(r1)
0xff4a908 :   mr  r29,r4
0xff4a90c :   add r30,r0,r30
0xff4a910 :   beq-0xff4a990 

0xff4a914 :   lwz r0,8(r31)
0xff4a918 :   andi.   r9,r0,512
0xff4a91c :   beq-0xff4a990 

0xff4a920 :   lwz r11,128(r31)
0xff4a924 :   lwz r3,40(r11)
0xff4a928 :   cmpwi   cr7,r3,-2
0xff4a92c :   beq-cr7,0xff4a9b4 

0xff4a930 :   cmpwi   cr7,r3,0
0xff4a934 :   bne-cr7,0xff4a960 

0xff4a938 :   lwz r10,96(r31)
0xff4a93c :  lwz r9,0(r10)
0xff4a940 :  lwz r0,32(r9)
0xff4a944 :  cmpwi   cr7,r0,0
0xff4a948 :  bne-cr7,0xff4a9bc 

0xff4a94c :  cmpwi   cr7,r3,0
0xff4a950 :  mr  r0,r3
0xff4a954 :  bne-cr7,0xff4a95c 

0xff4a958 :  li  r0,-2
0xff4a95c :  stw r0,40(r11)
0xff4a960 :  lwz r9,8(r1)
0xff4a964 :  stw r3,8(r1)
0xff4a968 :  cmpwi   cr7,r9,0
0xff4a96c :  beq-cr7,0xff4a990 

0xff4a970 :  lwz r0,4(r9)
0xff4a974 :  cmpwi   cr7,r0,0
0xff4a978 :  beq+cr7,0xff4a990 

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Andrew Haley]

Nathan Sidwell writes:
 > Andrew Haley wrote:
 > > Nathan Sidwell writes:
 > >  > Andrew Haley wrote:
 > >  > 
 > >  > > Might it still be possible for a front end to force all pending code
 > >  > > to be generated, even with -fno-unit-at-a-time gone?
 > >  > 
 > >  > I think this is a bad idea.  You're essentially asking for the backend
 > >  > to retain all the functionality of -fno-unit-at-a-time.
 > > 
 > > OK.  So, what else?
 > As steven asked, I'd like to understand why this is not a problem
 > for the C++ community.  There are several alternatives
 > 
 > 1) The C++ programs are smaller than the java programs

That's my guess.  Usually, C++ users compile one source file at a
time, whereas Java users find it convenient to compile a whole
archive.

This is merely a convenience, for sure.  But it's quite a big
convenience.

Andrew.

RE: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Rupert Wood]

Just as another idea -

Steven Bosscher wrote:

> (The proper solution is of course to have an IR that we can stream
> to disk, *sigh*  ;-)

AFAICT, MSVC solves this by generating some of the code when it reaches some
memory limit. So when GCC is under some memory pressure it could identify
functions with no/limited interdependency on other functions in the tree,
then carry out the rest of the compile passes on those functions only (i.e.
write out their code and free the IR), then pick up where it left off for
the test of the code?

Except I don't really know enough about the passes to know if that's
feasible or not, and in any case it sounds like a lot of work to hop between
passes :-/

Rup.

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Gabriel Dos Reis]

Nathan Sidwell <[EMAIL PROTECTED]> writes:

| Andrew Haley wrote:
| > Nathan Sidwell writes:
| >  > Andrew Haley wrote:
| >  >  > > Might it still be possible for a front end to force all
| > pending code
| >  > > to be generated, even with -fno-unit-at-a-time gone?
| >  >  > I think this is a bad idea.  You're essentially asking for the
| > backend
| >  > to retain all the functionality of -fno-unit-at-a-time.
| > OK.  So, what else?
| As steven asked, I'd like to understand why this is not a problem
| for the C++ community.  There are several alternatives
| 
| 1) The C++ programs are smaller than the java programs
| 2) the c++ representation is denser
| 3) the c++ users have more memory
| 4) The ones the C++ community *has* complained about are seen as
| pathelogical cases or acknowledged IR deficiencies
| 5) The c++ community are too timid to complain


  6) Java programs (more precisely) typically have to fit in a single 
 "unit", therefore tend to make Java "units" much larger than C++'s.
 (And incidently, Java representation is usually richer than
 C++'s.)  

6+5/2
  
-- Gaby

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Nathan Sidwell]

Andrew Haley wrote:
Nathan Sidwell writes:

 > 1) The C++ programs are smaller than the java programs
That's my guess.  Usually, C++ users compile one source file at a
time, whereas Java users find it convenient to compile a whole
archive.
ok, thanks.  This sounds like you're really in an IMA mode :) If I
understand java archives correctly, they're really a set of concatenated
TUs, so could be compiled individually and then having a final link.
That would more naturally match other language's uses of the toolchain.
you'd like the backend to handle the breaking appart bit (by preserving
no-unit-at-a-time).  I think that's merely pushing the complexity out
of the java FE and into the backend.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Andreas Schwab]

Andrew Haley <[EMAIL PROTECTED]> writes:

> That's my guess.  Usually, C++ users compile one source file at a
> time,

Unless you use --enable-final in KDE.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Andrew Haley]

Nathan Sidwell writes:
 > Andrew Haley wrote:
 > > Nathan Sidwell writes:
 > 
 > >  > 1) The C++ programs are smaller than the java programs
 > > 
 > > That's my guess.  Usually, C++ users compile one source file at a
 > > time, whereas Java users find it convenient to compile a whole
 > > archive.
 > ok, thanks.  This sounds like you're really in an IMA mode :) If I
 > understand java archives correctly, they're really a set of concatenated
 > TUs, so could be compiled individually and then having a final link.

Yes.

 > That would more naturally match other language's uses of the toolchain.

 > you'd like the backend to handle the breaking appart bit (by preserving
 > no-unit-at-a-time).  I think that's merely pushing the complexity out
 > of the java FE and into the backend.

Sure, it is, yes.  But it has hitherto been a very convenient way to
work.

Andrew.

Re: reload-branch created

[Bernd Schmidt]

I guess the best solution is to change the place you modified, but to 
use a test that checks for autoinc codes.  I'll come up with something.
Try this.
Bernd
	* reload.c (find_reloads): Only set INC field if we know we have an
	autoinc reload.
	* reload.h (struct reload): Update comment to match.

Index: reload.c
===
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.268.6.2
diff -c -p -r1.268.6.2 reload.c
*** reload.c	7 Apr 2005 11:21:35 -	1.268.6.2
--- reload.c	11 Apr 2005 12:33:13 -
*** find_reloads (struct insn_chain *chain, 
*** 3203,3216 
  		 && goal_alternative_offmemok[i]
  		 && MEM_P (recog_data.operand[i]))
  	  {
  	operand_reloadnum[i]
  	  = push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,
  			 &XEXP (recog_data.operand[i], 0), (rtx*) 0,
  			 MODE_BASE_REG_CLASS (VOIDmode),
  			 GET_MODE (XEXP (recog_data.operand[i], 0)),
  			 VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
! 	rld[operand_reloadnum[i]].inc
! 	  = GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
  	  }
  	else if (goal_alternative_matched[i] == -1)
  	  {
--- 3203,3221 
  		 && goal_alternative_offmemok[i]
  		 && MEM_P (recog_data.operand[i]))
  	  {
+ 	struct reload *rl;
  	operand_reloadnum[i]
  	  = push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,
  			 &XEXP (recog_data.operand[i], 0), (rtx*) 0,
  			 MODE_BASE_REG_CLASS (VOIDmode),
  			 GET_MODE (XEXP (recog_data.operand[i], 0)),
  			 VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
! 	rl = rld + operand_reloadnum[i];
! 	if (GET_CODE (rl->in_reg) == PRE_INC
! 		|| GET_CODE (rl->in_reg) == PRE_DEC
! 		|| GET_CODE (rl->in_reg) == POST_INC
! 		|| GET_CODE (rl->in_reg) == POST_DEC)
! 	  rl->inc = GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
  	  }
  	else if (goal_alternative_matched[i] == -1)
  	  {

Re: GCC 4.0 RC1 Available

[Andrew Haley]

Eric Botcazou writes:
 > 
 > Tom, I presume there was a very good reason for installing such a 
 > potentially 
 > destabilizing patch a few days before the prerelease?  

In defence of my fellow maintainer:

There was.  We are now, for the first time ever, in a position where
we can run a large number of big Java applications using entirely free
software.  

 > What amount of testing did it undergo before being backported?

A good deal.  It was in mainline for some time before, after some
contemplation, we decided that it was so important that it should go
into 4.0.  Without this patch many important applications will not
work correctly.

I appreciate that it's important that gcc runs on many platforms and
that Solaris has been an important platform for gcc.  But it's also
important that we can run a large number of real world applications on
gcj on free platforms.

 > Still, we are a bit stuck on SPARC/Solaris because there is not
 > much interest for that platform among the Java hackers (for
 > SPARC/Linux either, I think).  AFAIK the only Java patches aimed at
 > fixing problems there have been posted or initiated by me.  So I
 > suspect nobody will step up to investigate what broke.
 > 
 > I understand that Java on SPARC is not a priority, but I think in
 > such extreme cases Java hackers should coordinate with the platform
 > maintainers that try to keep the Java compiler healthy on their
 > architecture, despite the huge tax of CPU cycles this entails.

We're in a diffcult position here, because SPARC has few maintainers,
and Java has few maintainers.  However, if you can let me have a logon
I can have a look.

Andrew.

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Richard Guenther]

On Apr 11, 2005 2:01 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Nathan Sidwell writes:
>  > Andrew Haley wrote:
>  > > Nathan Sidwell writes:
>  > >  > Andrew Haley wrote:
>  > >  >
>  > >  > > Might it still be possible for a front end to force all pending code
>  > >  > > to be generated, even with -fno-unit-at-a-time gone?
>  > >  >
>  > >  > I think this is a bad idea.  You're essentially asking for the backend
>  > >  > to retain all the functionality of -fno-unit-at-a-time.
>  > >
>  > > OK.  So, what else?
>  > As steven asked, I'd like to understand why this is not a problem
>  > for the C++ community.  There are several alternatives
>  >
>  > 1) The C++ programs are smaller than the java programs
> 
> That's my guess.  Usually, C++ users compile one source file at a
> time, whereas Java users find it convenient to compile a whole
> archive.

That's not really true.  For C++ programs relying heavily on templates libraries
like POOMA, all of the C++ program is usually in one translation unit.  Memory
usage of GCC in this respect is reasonable for me (it was much worse!)
- compiling
a big app fits in a Gig of ram easily.  Unlike with the Intel
compiler, f.i. which cannot
even compile a moderately large POOMA program with the 2GB virtual(!) memory
limit.

This is one important point, though - if the Java stuff takes more
than the usual
_virtual_ memory limits on a 32bit machine, the simple answer cannot
be "buy more ram"
any longer.  Of course "buy a 64bit machine" would be the canonical
response then.

It would be interesting to know what part of GCC is requiring so much
memory - does
it help switching to -O0, or is the internal representation really
taking so much memory?

RIchard.

Re: GCC 4.0 RC1 Available

[Georg Bauhaus]

Mark Mitchell wrote:
The first GCC 4.0 candidate is available from:
...
a minor issue with the configure script:
...
checking whether gcc-3.4 accepts -g... yes
checking for gnatbind... gnatbind
--- here --->
checking whether compiler driver understands Ada... 
../src/gcc-4.0.0-20050410/configure: line 2141: break: only meaningful in a 
`for', `while', or `until' loop
yes
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 
$$f2
...
looks like there is a "break" without the (usual?) "for" around it.

Georg

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Marcin Dalecki]

On 2005-04-11, at 14:01, Andrew Haley wrote:
Nathan Sidwell writes:
Andrew Haley wrote:
Nathan Sidwell writes:
Andrew Haley wrote:
Might it still be possible for a front end to force all pending 
code
to be generated, even with -fno-unit-at-a-time gone?
I think this is a bad idea.  You're essentially asking for the 
backend
to retain all the functionality of -fno-unit-at-a-time.
OK.  So, what else?
As steven asked, I'd like to understand why this is not a problem
for the C++ community.  There are several alternatives
1) The C++ programs are smaller than the java programs
That's my guess.  Usually, C++ users compile one source file at a
time, whereas Java users find it convenient to compile a whole
archive.
If it is an archive the answer would be to change gcc.c to recognize 
this
and to let it compile the archive one item at a time. (.jar).

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Andrew Haley]

Marcin Dalecki writes:
 > 
 > On 2005-04-11, at 14:01, Andrew Haley wrote:
 > 
 > > Nathan Sidwell writes:
 > >> Andrew Haley wrote:
 > >>> Nathan Sidwell writes:
 >  Andrew Haley wrote:
 > 
 > > Might it still be possible for a front end to force all pending 
 > > code
 > > to be generated, even with -fno-unit-at-a-time gone?
 > 
 >  I think this is a bad idea.  You're essentially asking for the 
 >  backend
 >  to retain all the functionality of -fno-unit-at-a-time.
 > >>>
 > >>> OK.  So, what else?
 > >> As steven asked, I'd like to understand why this is not a problem
 > >> for the C++ community.  There are several alternatives
 > >>
 > >> 1) The C++ programs are smaller than the java programs
 > >
 > > That's my guess.  Usually, C++ users compile one source file at a
 > > time, whereas Java users find it convenient to compile a whole
 > > archive.
 > 
 > If it is an archive the answer would be to change gcc.c to
 > recognize this and to let it compile the archive one item at a
 > time. (.jar).

Well, yes, but a) it would be slow, and b) the output is a .o file and
we'd have to find some portable way to link a bunch of .o files into
another .o.  'ld -r' works on some systems.

Andrew.

Re: GCC 4.0 RC1 Available

[Mark Mitchell]

Andrew Haley wrote:
We're in a diffcult position here, because SPARC has few maintainers,
and Java has few maintainers.  However, if you can let me have a logon
I can have a look.
That would be much appreciated.  Java isn't release-critical, but it 
still seems like it would be nice to understand what's wrong here.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.0 RC1 Available

[Joe Buck]

On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote:
> The first GCC 4.0 candidate is available from:
> 
> /pub/gcc/prerelease-4.0.0-20050410/

My first build result is at

http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00742.html

However, the system info is wrong due to my error; it is really a
Fedora Core 2 system, with "up2date" components for the kernel, gcc,
and binutils, and there are no Ada tests -- configure reports that
libada isn't supported (despite the presence of gnat), though I haven't
investigated why.

I will be doing tests on more platforms.

RE: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Daniel Kegel]

"Rupert Wood" <[EMAIL PROTECTED]> wrote:
I have a problem with getting rid of -fno-unit-at-a-time.  Sometimes
we compile huge Java programs; however, keeping all the method bodies
consumes vast amouts of memory. 
AFAICT, MSVC solves this by generating some of the code when it reaches some
memory limit. So when GCC is under some memory pressure it could identify
functions with no/limited interdependency on other functions in the tree,
then carry out the rest of the compile passes on those functions only (i.e.
write out their code and free the IR), then pick up where it left off for
the test of the code?
I think msvc does do that, but in some circumstances, it can
be a real problem.  What if there's a code generation bug that only happens
on build machines with X megabytes of memory as a result?
Or what if you care about bit-for-bit repeatable builds for some other reason?
I think some groups at Microsoft now use vmware images with
a known amount of memory to do all their builds to get around this 'feature'.
Please, if this behavior is added, let us turn it off with a flag.
BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
or so... I still lean on that crutch.
- Dan

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Daniel Jacobowitz]

On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> or so... I still lean on that crutch.

A user!  Can you explain why?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: GCC 4.0 RC1 Available

[Jakub Jelinek]

On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote:
> The first GCC 4.0 candidate is available from:
> 
> /pub/gcc/prerelease-4.0.0-20050410/
> 
> on the usual gcc.gnu.org mirrors:
> 
> http://gcc.gnu.org/mirrors.html
> 
> I would like to know whether or not we have achieved the objective 
> aspects of the release criteria:
> 
> http://gcc.gnu.org/gcc-4.0/criteria.html
> 
> for primary and secondary platforms.  In particular, for primary platforms:
> 
> * The DejaGNU testsuite has been run, and compared with a run of 
> the testsuite on the previous release of GCC, and no regressions are 
> observed.

Just an early warning.
We are seeing (possible) miscompilation of KDE 3.4.0's cssstyleselector.cpp
on i386-linux, a regression between 20050330 (where it worked) and 20050403.
The resulting assembly with 20050403+ is also ~ 17% bigger.
There are no differences in *.generic dump, but already in *.gimple
dump the difference is huge.
We'll keep looking into this.

Jakub

Re: GCC 4.0 RC1 Available

[Mark Mitchell]

Jakub Jelinek wrote:
On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote:
The first GCC 4.0 candidate is available from:
/pub/gcc/prerelease-4.0.0-20050410/
on the usual gcc.gnu.org mirrors:
http://gcc.gnu.org/mirrors.html
I would like to know whether or not we have achieved the objective 
aspects of the release criteria:

http://gcc.gnu.org/gcc-4.0/criteria.html
for primary and secondary platforms.  In particular, for primary platforms:
   * The DejaGNU testsuite has been run, and compared with a run of 
the testsuite on the previous release of GCC, and no regressions are 
observed.

Just an early warning.
Thanks for the heads up.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.0 RC1 Available

[Andrew Pinski]

On Apr 11, 2005, at 1:04 PM, Jakub Jelinek wrote:
On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote:
The first GCC 4.0 candidate is available from:
/pub/gcc/prerelease-4.0.0-20050410/
on the usual gcc.gnu.org mirrors:
http://gcc.gnu.org/mirrors.html
I would like to know whether or not we have achieved the objective
aspects of the release criteria:
http://gcc.gnu.org/gcc-4.0/criteria.html
for primary and secondary platforms.  In particular, for primary 
platforms:

* The DejaGNU testsuite has been run, and compared with a run of
the testsuite on the previous release of GCC, and no regressions are
observed.
Just an early warning.
We are seeing (possible) miscompilation of KDE 3.4.0's 
cssstyleselector.cpp
on i386-linux, a regression between 20050330 (where it worked) and 
20050403.
The resulting assembly with 20050403+ is also ~ 17% bigger.
There are no differences in *.generic dump, but already in *.gimple
dump the difference is huge.
We'll keep looking into this.
This with optimization turned on right, then there is more inlining 
happening,
which was caused by:
2005-04-01  Richard Guenther <[EMAIL PROTECTED]>
Jan Hubicka  <[EMAIL PROTECTED]>
Steven Bosscher <[EMAIL PROTECTED]>

* cgraphunit.c (cgraph_estimate_size_after_inlining): Compute
call cost based on argument sizes.
(cgraph_mark_inline_edge): Avoid inline unit from shrinking by
inlining.
* params.def: (max-inline-inssn-single): Set to 450.
(max-inline-insns-auto): Set to 90.
(max-inline-insns-recursive): Set to 450
(max-inline-insns-recursive-auto): Set to 450.
(large-function-insns): Set to 2700.
(inline-call-cost): New parameter.
* tree-inline.c (estimate_move_cost): New function.
(estimate_num_insns_1): Compute move sizes costs by 
estimate_move_cost
for non-gimple-regs, set cost to 0 for gimple-regs.  Compute 
call size
based on arguments.
* tree-inline.h (estimate_move_cost): Declare.
* invoke.texi: (max-inline-inssn-single): Change default to 450.
(max-inline-insns-auto): Change default to 90.
(max-inline-insns-recursive): Change default to 450
(max-inline-insns-recursive-auto): Change default to 450.
(large-function-insns): Change default to 2700.
(inline-call-cost): Document new parameter.

-- Pinski

GCC Cross Compilation

[Vishal Kothari]

Hi,

How can I use GCC for cross compilation?
I want to build an application for the EPOC platform. It is for a
Psion 5MX device which has an 32-bit RISC-based ARM 710 processor.
The application is in C. Is it possible to build the application using
GCC for that platform?

-- 
Regards,
Vishal Kothari.

re: GCC Cross Compilation

[Daniel Kegel]

Vishal Kothari <[EMAIL PROTECTED]> wrote:
How can I use GCC for cross compilation?
I want to build an application for the EPOC platform. It is for a
Psion 5MX device which has an 32-bit RISC-based ARM 710 processor.
The application is in C. Is it possible to build the application using
GCC for that platform?
I see you use Google's fine gmail service.
Have you tried their search engine?  It seems to work pretty well for questions 
like this.
A search for
  EPOC arm gcc
yielded lots of hits, including
  http://gnupoc.sourceforge.net/
If that doesn't do it for you, please take your question
to the crossgccc mailing list.  See
  http://sources.redhat.com/ml/crossgcc/
- Dan

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Daniel Kegel]

Daniel Jacobowitz wrote:
On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
or so... I still lean on that crutch.
A user!  Can you explain why?
Hmm.  I just looked, and it seems the only thing I still
use it for is glibc-2.2.x and later.
For glibc-2.3.2, I use the nice patch from glibc cvs:
http://kegel.com/crosstool/crosstool-0.28-rc26/patches/glibc-2.3.2/glibc-2.3.2-allow-gcc-3.4-nounit.patch
For earlier glibc's, I just force in -fno-unit-at-a-time globally.
I might use it somewhere else, too, but I can't put my finger on it.
Generally I prefer to fix software to really build with newer
compilers, but sometimes when faced with a pile of legacy third-party source
turning on a magic compiler flag is more practical.
- Dan

Re: GCC 4.0 RC1 Available

[Richard Sandiford]

Mark Mitchell <[EMAIL PROTECTED]> writes:
> If you are willing to help, please download the release candidate, build
> it on appropriate platforms, and post testresults by using
> contrib/test_summary.  Please use the release candidate itself, *not*
> the CVS 4.0 release branch, as part of the goal is to ensure that the
> packaging scripts are working.
>
> Then, if you are running on a primary or secondary platform, please send
> me an email pointing me at the results you've posted, and highlighting
> any failures to meet the release criteria.

Results for mips-elf posted here:

http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00792.html

I think these results are OK:

   - copysign1.c is a new test.  It fails because the MIPS neg.fmt
 instruction implements arithmetic negation, not the sign-flipping
 implementation suggested in the IEEE appendix.  Signs are therefore
 not correctly copied to NaNs.

 I'm still trying to make my mind up what the best fix is.

   - The gcsec-1.c failures are caused by a problem in the
 libgloss linker scripts.

   - execute/20020720-1.c is a standard soft-float failure.

   - The two PCH glitches (one gcc and one g++) were caused by running
 "make check -j2".  The gcc and g++ PCH tests happened to collide
 at one point, both trying to handle system-1.

   - Wdtor-1.C fails for the same reason as discussed on [EMAIL PROTECTED]

Richard

Re: GCC 4.0 RC1 Available

[Kaveh R. Ghazi]

 > --- here --->
 > checking whether compiler driver understands
 > Ada... ../src/gcc-4.0.0-20050410/configure: line 2141: break: only
 > meaningful in a `for', `while', or `until' loop
 > yes
 > checking how to compare bootstrapped objects... cmp
 > --ignore-initial=16 $$f1 $$f2
 > ...
 > looks like there is a "break" without the (usual?) "for" around it.
 > Georg

On closer inspection, I'm seeing the same thing on 4.0 and mainline.

I believe the offending "break" was added to config/acx.m4 here:
http://gcc.gnu.org/ml/gcc/2004-02/msg00755.html
Although it seems to be that Paolo simply moved existing code from
gcc/aclocal.m4 to config/acx.m4.

Going back through aclocal.m4, the original breakage (no pun intended)
occurred here when Nathanael removed the surrounding for-stmt but left
the break inside the if-stmt.
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02109.html

Nathanael, can you please take a look?

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[Kate Minola]

Has anyone had success in building gcc-4.0.0 RC1 on a 
powerpc-ibm-aix5.2.0.0 (a primary platform)?

After 

  configure --enable-languages=c
  make bootstrap

I get 

: [stuff deleted]
: build/genattrtab 
/home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ 
rs6000.md > tmp-attrtab.c
: 
: out of memory allocating 12016 bytes after a total of 4161654476 bytes

My bootstrap compiler is 

% gcc -v
Reading specs from
/usr/local/gcc-3.4.2/powerpc-AIX/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.2/specs
Configured with: ../gcc-3.4.2/configure --enable-languages=c
--prefix=/usr/local/gcc-3.4.2/powerpc-AIX
Thread model: aix
gcc version 3.4.2
%

Of course, the problem could be with my machine rather than gcc.

Kate Minola
University of Maryland, College Park

Re: GCC 4.0 RC1 Available

[Marcus Meissner]

Btw,

We still see some critical 4.0 problems, ordered by my view of 
importance:

PR/20126 triggers a miscompilation of python (i386 and x86_64 at least).
PR/20917 triggers a miscompilation of glibc (on s390).
PR/20739 triggers a --enable-checking problem triggering in ncurses (all 
platforms)
PR/20929 triggers a miscompilation of Mozilla.


At least 20126 should probably be considered for 4.0.

Ciao, Marcus


pgpfY5yLSUi6C.pgp
Description: PGP signature

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Jeffrey A Law]

On Mon, 2005-04-11 at 13:03 -0400, Daniel Jacobowitz wrote:
> On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> > BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> > or so... I still lean on that crutch.
> 
> A user!  Can you explain why?
Actually, I still use -fno-unit-at-a-time as well.  I've find it quite
useful to help in isolating problems with the compiler.

jeff

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Alexandre Oliva]

On Apr  4, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:

> On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote:
>> My head hurts about the GGC implications of opaque pointers in such a
>> hash table, and retaining pointers in the hash table that have already
>> been otherwise freed.

> These are solved problems.

Only in the mathematical sense.  We still have such incorrect uses in
our tree, as the bootstrap problem I reported shows.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: GCC 4.0 RC1 Available

[Eric Botcazou]

> Please post the list of failures to [EMAIL PROTECTED]

http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00671.html

-- 
Eric Botcazou

Re: Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074

[Alexandre Oliva]

On Apr 10, 2005, Andreas Jaeger <[EMAIL PROTECTED]> wrote:

> Laurent GUERBY <[EMAIL PROTECTED]> writes:

>> stage1/xgcc -Bstage1/ 
>> -B/home/guerby/work/gcc/install/install-20050410T003153/i686-pc-linux-gnu/bin/
>>  -c -O2 -g -fomit-frame-pointer  -gnatpg -gnata -I--I. -Iada 
>> -I/home/guerby/work/gcc/version-head/gcc/ada 
>> /home/guerby/work/gcc/version-head/gcc/ada/errout.adb -o ada/errout.o
>> +===GNAT BUG DETECTED==+
>> | 4.1.0 20050409 (experimental) (i686-pc-linux-gnu) GCC error: |
>> | tree check: accessed operand 2 of view_convert_expr with 1 operands  |
>> |in visit_assignment, at tree-ssa-ccp.c:1074   |
>> | Error detected at errout.adb:2563:1  |

> And on x86_64-linux-gnu I see now:

> stage1/xgcc -Bstage1/ -B/opt/gcc/4.1-devel/x86_64-suse-linux-gnu/bin/ -c -g 
> -O2  -gnatpg -gnata -I- -I. -Iada -I/cvs/gcc/gcc/ada 
> /cvs/gcc/gcc/ada/ada.ads -o ada/ada.o
> +===GNAT BUG DETECTED==+
> | 4.1.0 20050409 (experimental) (x86_64-suse-linux-gnu) Segmentation fault |
> | Error detected at ada.ads:17:1   |
> | Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
> | Use a subject line meaningful to you and us to track the bug.|
> | Include the entire contents of this bug box in the report.   |
> | Include the exact gcc or gnatmake command that you entered.  |
> | Also include sources listed below in gnatchop format |
> | (concatenated together with no headers between files).   |
> +==+

I'm testing the following patches to fix these two problems.  I'll
submit them formally when bootstrap is complete, but early review and
maybe even pre-approval wouldn't hurt :-)

Index: tree-ssa-ccp.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-ccp.c,v
retrieving revision 2.64
diff -u -p -d -u -p -d -u -p -r2.64 tree-ssa-ccp.c
--- tree-ssa-ccp.c  9 Apr 2005 01:37:23 -   2.64
+++ tree-ssa-ccp.c  11 Apr 2005 19:54:39 -
@@ -1071,7 +1071,7 @@ visit_assignment (tree stmt, tree *outpu
   TREE_TYPE (TREE_OPERAND (orig_lhs, 0)),
   val.value));
 
-   orig_lhs = TREE_OPERAND (orig_lhs, 1);
+   orig_lhs = TREE_OPERAND (orig_lhs, 0);
if (w && is_gimple_min_invariant (w))
  val.value = w;
else
Index: varasm.c
===
RCS file: /cvs/gcc/gcc/gcc/varasm.c,v
retrieving revision 1.495
diff -u -p -d -u -p -d -u -p -r1.495 varasm.c
--- varasm.c9 Apr 2005 20:41:49 -   1.495
+++ varasm.c11 Apr 2005 19:55:05 -
@@ -307,7 +307,7 @@ in_unlikely_text_section (void)
   cfun = DECL_STRUCT_FUNCTION (current_function_decl);
 
   ret_val = ((in_section == in_unlikely_executed_text)
-|| (in_section == in_named
+|| (in_section == in_named && cfun
 && cfun->unlikely_text_section_name
 && strcmp (in_named_name, 
cfun->unlikely_text_section_name) == 0));


-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074

[Andrew Pinski]

On Apr 11, 2005, at 3:55 PM, Alexandre Oliva wrote:
Index: varasm.c
===
RCS file: /cvs/gcc/gcc/gcc/varasm.c,v
retrieving revision 1.495
diff -u -p -d -u -p -d -u -p -r1.495 varasm.c
--- varasm.c9 Apr 2005 20:41:49 -   1.495
+++ varasm.c11 Apr 2005 19:55:05 -
@@ -307,7 +307,7 @@ in_unlikely_text_section (void)
   cfun = DECL_STRUCT_FUNCTION (current_function_decl);
   ret_val = ((in_section == in_unlikely_executed_text)
-|| (in_section == in_named
+|| (in_section == in_named && cfun
 && cfun->unlikely_text_section_name
 && strcmp (in_named_name,
cfun->unlikely_text_section_name) == 0));
Also note Caroline is testing a patch to fix this and the other
fall out due to her hot/cold patch.
Thanks,
Andrew Pinski

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[David Edelsohn]

> Kate Minola writes:

Kate> Has anyone had success in building gcc-4.0.0 RC1 on a 
Kate> powerpc-ibm-aix5.2.0.0 (a primary platform)?

Kate> After 

Kate> configure --enable-languages=c
Kate> make bootstrap

Kate> I get 

Kate> : [stuff deleted]
Kate> : build/genattrtab 
/home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ 
rs6000.md > tmp-attrtab.c
Kate> : 
Kate> : out of memory allocating 12016 bytes after a total of 4161654476 bytes

Kate> My bootstrap compiler is 

Kate> % gcc -v
Kate> Reading specs from
Kate> 
/usr/local/gcc-3.4.2/powerpc-AIX/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.2/specs
Kate> Configured with: ../gcc-3.4.2/configure --enable-languages=c
Kate> --prefix=/usr/local/gcc-3.4.2/powerpc-AIX
Kate> Thread model: aix
Kate> gcc version 3.4.2
Kate> %

Kate> Of course, the problem could be with my machine rather than gcc.

This probably says more about GCC 3.4.2 on AIX than about GCC 4.0
RC1.  See the messages to the gcc-testresults mailinglist about successful
AIX 5.2 bootstrap of GCC 4.

David

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Alexandre Oliva]

On Apr 11, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> On Apr  4, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
>> On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote:
>>> My head hurts about the GGC implications of opaque pointers in such a
>>> hash table, and retaining pointers in the hash table that have already
>>> been otherwise freed.

>> These are solved problems.

> Only in the mathematical sense.  We still have such incorrect uses in
> our tree, as the bootstrap problem I reported shows.

I take that back.  The hash tables seem to be fine.  I suspect it's
the sorting on pointers in the goto_queue that triggers the problem.
In fact, I'm pretty sure comparing pointers that are not guaranteed to
be in the same array invokes undefined behavior, and I do remember
having run into errors because of such abuse in bfd many moons ago.
Ugh...

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Richard Henderson]

On Mon, Apr 11, 2005 at 05:41:56PM -0300, Alexandre Oliva wrote:
> I take that back.  The hash tables seem to be fine.  I suspect it's
> the sorting on pointers in the goto_queue that triggers the problem.
> In fact, I'm pretty sure comparing pointers that are not guaranteed to
> be in the same array invokes undefined behavior, and I do remember
> having run into errors because of such abuse in bfd many moons ago.

Technically, yes.  I deny that it's a problem in practice except
for segmented architectures.  Which includes no gcc hosts.


r~

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Mike Stump]

On Apr 11, 2005, at 4:58 AM, Nathan Sidwell wrote:
 > Might I refer you to Mike Stump's answer regarding swap :)
I haven't seen it.
It was basically 'get more memory'.
Actually, an expanded version of it would be:
If gcc swaps, you're in serious trouble, gcc won't perform very well  
well when it starts to swap.  Compiling _big_ software (software that  
requires lots of ram to compile), requires one to simply have enough  
hard memory for the compiler to use.  If one doesn't have this amount  
of memory, one will want to go buy some more.  It _is_ alright if we  
require more than is typical for a consumer PC, as developers can be  
expected to have more memory, on average that most.  This, is a user  
point of view.

At the same time, from a gcc developer view point, yes, we want to  
keep memory under control and actually think about the ramifications  
of wasting memory.  gcc used to free memory after each statement, to  
ensure memory consumption was low.  With things like unit at a time,  
memory consumption is on the rise, we just need to be careful of it.   
A bad algorithm can quickly shoot it up, it is those unnatural spikes  
that are the most egregious and maybe the easiest to fix.  gcse in  
the past was one of my favorite examples of this sort of thing.

Re: GCC 4.0 RC1 Available

[Eric Botcazou]

> There was.  We are now, for the first time ever, in a position where
> we can run a large number of big Java applications using entirely free
> software.

Congratulations!

> We're in a diffcult position here, because SPARC has few maintainers,
> and Java has few maintainers.

Frankly, I don't see what the number of SPARC maintainers has to do with the 
affair.  libstdc++-v3 maintainers ask from time to time to test in advance 
potentially controversial patches they intend to backport to stable branches 
and the turnaround time is generally a matter of days.

And SPARC is the port that features the greatest number of officially 
appointed maintainers. :-)

> However, if you can let me have a logon I can have a look.

Thanks for the offer.  I'll try and see what I can do.

-- 
Eric Botcazou

Re: GCC 4.0 RC1 Available

[Per Bothner]

I can no longer build Kawa using the 4.0 branch.  This is with a
'cvs update' late last night.  Kawa did built last time I tried
the 4.0 branch.  Unfortunately, I don't know how long ago that was,
but it wasn't *that* long ago.
The cause appears to failure to find a class in the CLASSPATH.
That suggests it might be related to Tom's check-in.
I'll track it down a little bit further.
This is on Fedora Core 3, x86.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: GCC 4.0 RC1 Available

[Per Bothner]

Per Bothner wrote:
I can no longer build Kawa using the 4.0 branch.
Some more information:
The failing statement is:
Class.forName("kawa.lib.prim_syntax", false,
  getClass().getClassLoader());
prim_syntax.class exists in the current directory,
which is ../../kawa/lib.  The program is run with
CLASSPATH=../..
Printing getClass().getClassLoader() yields:
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
  parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Note the urls=[file:./].  Looks like it's ignoring the CLASSPATH
environment option.
It works after I do:
mkdir kawa kawa/lib && cp prim_syntax.class kawa/lib
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

successful bootstrap/install of GCC 4.0 RC1 on OpenDarwin 7.2.1/x86

[Lars Sonchocky-Helldorf]

The system:
===
uname -a
Darwin localhost 7.2.1 Darwin Kernel Version 7.2.1: Wed Jul 14 03:00:02
PDT 2004; root:tmp/xnu-7.2.1-1-root.obj/RELEASE_I386  x86 i386
gcc -v
Reading specs from /usr/libexec/gcc/darwin/i386/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)

Prerequisites:
==
# link libmx to libSystem
# this is necessary because some libraries are missing
# from OpenDarwin, in this case the -lmx argument results in:
# /usr/bin/ld: can't locate file for: -lmx
# see http://www.opendarwin.org/bugzilla/show_bug.cgi?id=2194
#
# note: this is just enough to bootstrap the compiler,
# some floating point compiliations might fail
sudo ln -s /usr/lib/libSystem.B.dylib /usr/lib/libmx.dylib
# install new cctools
# according to: http://gcc.gnu.org/ml/gcc/2005-03/msg01149.html
# new cctools are required to build HEAD of gcc
# Since building Apples cctools is somewhat complicated and
# won't work on (Open)Darwin/x86 better use OpenDarwin cctools  
(odcctools)
# see: http://www.opendarwin.org/projects/odcctools/
# and: http://www.opendarwin.org/projects/odcctools/usingodcctools.html
# and:  
http://www.opendarwin.org/pipermail/odcctools/2005-March/51.html

ftp http://www.opendarwin.org/downloads/odcctools-20050327.tar.bz2
tar -jxf odcctools 20050327.tar.bz2
mkdir odcctools-20050327-build
cd odcctools-20050327-build/
../odcctools-20050327/configure --prefix=/usr
make
sudo make install
cd ..

Bootstrapped like:
==
# bootstrap the compiler
# note: those STAGE1_CFLAGS are needed to avoid
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14780
ftp  
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050410/gcc-4.0.0- 
20050410.tar.bz2
openssl md5 gcc-4.0.0-20050410.tar.bz2
tar -jxf gcc-4.0.0-20050410.tar.bz2
mkdir gcc-4.0.0-20050410-build
cd gcc-4.0.0-20050410-build/
../gcc-4.0.0-20050410/configure --prefix=/tmp/gcc
make bootstrap STAGE1_CFLAGS="-force_cpusubtype_ALL"
sudo make install
cd ..


Results of bootstraps:
==
localhost:~ lars$ /tmp/gcc/bin/gcc -v
Using built-in specs.
Target: i686-apple-darwin7.2.1
Configured with: ../gcc-4.0.0-20050410/configure --prefix=/tmp/gcc
Thread model: posix
gcc version 4.0.0 20050410 (prerelease)
localhost:~ lars$
testresults are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00797.html
and here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00798.html

regards, Lars

Re: GCC 4.0 RC1 Available

[Julian Brown]

On 2005-04-10, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
>  * The DejaGNU testsuite has been run, and compared with a run of 
> the testsuite on the previous release of GCC, and no regressions are 
> observed.
>
> If you are willing to help, please download the release candidate, build 
> it on appropriate platforms, and post testresults by using 
> contrib/test_summary.  Please use the release candidate itself, *not* 
> the CVS 4.0 release branch, as part of the goal is to ensure that the 
> packaging scripts are working.

For arm-none-elf (cross from i686-pc-linux-gnu), with binutils and newlib
from CVS:

  http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00800.html

And, for comparison, 3.4.3 tests:

  http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00799.html

Quite a few of the 4.0 RC1 tests FAIL, though I'm not sure how many of
these are regressions, and how many are just new tests which fail.

Julian

Re: GCC 4.0 RC1 Available

[Julian Brown]

On 2005-04-11, Julian Brown <[EMAIL PROTECTED]> wrote:
> On 2005-04-10, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>>
>>  * The DejaGNU testsuite has been run, and compared with a run of 
>> the testsuite on the previous release of GCC, and no regressions are 
>> observed.
>>
>> If you are willing to help, please download the release candidate, build 
>> it on appropriate platforms, and post testresults by using 
>> contrib/test_summary.  Please use the release candidate itself, *not* 
>> the CVS 4.0 release branch, as part of the goal is to ensure that the 
>> packaging scripts are working.
>
> For arm-none-elf (cross from i686-pc-linux-gnu), with binutils and newlib
> from CVS:
>
>   http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00800.html
>
> And, for comparison, 3.4.3 tests:
>
>   http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00799.html
>
> Quite a few of the 4.0 RC1 tests FAIL, though I'm not sure how many of
> these are regressions, and how many are just new tests which fail.

In more detail, for gcc.sum:

Tests that now fail, but worked before:

gcc.c-torture/execute/bitfld-1.c execution,  -O0
gcc.c-torture/execute/bitfld-1.c execution,  -O1
gcc.c-torture/execute/bitfld-1.c execution,  -O2
gcc.c-torture/execute/bitfld-1.c execution,  -O3 -fomit-frame-pointer
gcc.c-torture/execute/bitfld-1.c execution,  -O3 -g
gcc.c-torture/execute/bitfld-1.c execution,  -Os
gcc.c-torture/execute/builtin-constant.c execution,  -O1
gcc.dg/array-5.c bad vla handling (test for bogus messages, line 40)
gcc.dg/bitfld-2.c  (test for warnings, line 14)
gcc.dg/bitfld-2.c  (test for warnings, line 15)
gcc.dg/bitfld-2.c  (test for warnings, line 20)
gcc.dg/bitfld-2.c  (test for warnings, line 21)
gcc.dg/builtins-18.c (test for excess errors)
gcc.dg/builtins-20.c (test for excess errors)
gcc.dg/const-elim-1.c scan-assembler-not L\\$?C[^A-Z]
gcc.dg/cpp/trad/include.c (test for excess errors)
gcc.dg/redecl-1.c  (test for errors, line 67)
gcc.dg/sequence-pt-1.c sequence point warning (test for warnings, line 59)
gcc.dg/uninit-1.c uninitialized variable warning (test for bogus messages,
line 16)
gcc.dg/uninit-2.c uninitialized variable warning (test for bogus messages,
line 28)
gcc.dg/uninit-3.c uninitialized variable warning (test for bogus messages,
line 11)
gcc.dg/uninit-8.c uninitialized variable warning (test for bogus messages,
line 14)
gcc.dg/Wunreachable-1.c (test for excess errors)


For g++.sum:

Tests that now fail, but worked before:

g++.dg/other/error8.C duplicate error messages (test for bogus messages, line
8)
g++.dg/other/error8.C duplicate error messages (test for bogus messages, line
9)
g++.dg/rtti/tinfo1.C scan-assembler-not
.section[^\n\r]*_ZTIP9CTemplateIhE[^\n\r
]*
g++.dg/template/nested3.C  (test for errors, line 12)
g++.dg/template/nested3.C  (test for errors, line 14)
g++.dg/template/nested3.C  (test for errors, line 25)
g++.dg/template/nested3.C  (test for errors, line 8)
g++.old-deja/g++.jason/cond.C  (test for errors, line 20)
g++.old-deja/g++.jason/cond.C  (test for errors, line 22)
g++.old-deja/g++.jason/cond.C  (test for errors, line 25)
g++.old-deja/g++.jason/cond.C  (test for errors, line 27)
g++.old-deja/g++.oliva/expr2.C execution test
g++.old-deja/g++.oliva/template10.C  (test for errors, line 22)
g++.old-deja/g++.other/decl5.C  (test for warnings, line 55)
g++.old-deja/g++.other/decl5.C  (test for warnings, line 56)


For libstdc++.sum:

Tests that now fail, but worked before:

27_io/basic_filebuf/open/char/9507.cc (test for excess errors)


That's a total of about 39 regressions, I think. I also got quite a few
"Old tests that passed, that have disappeared" results. Is that expected?

Julian

Re: Major bootstrap time regression on March 30

[James E Wilson]

On Fri, 2005-04-08 at 16:36, Daniel Berlin wrote:
> Jim works on a  machine:

Athlon64 3400+, with 1GB main memory, running SuSE 9.1 x86_64-linux. 

Mainline build failure on i686-pc-linux-gnu

[Gabriel Dos Reis]

Build of freshly updated mainline tree fails with:

/home/gdr/build/4.1/./gcc/xgcc -B/home/gdr/build/4.1/./gcc/ -B/home/gdr/i686-pc-
linux-gnu/bin/ -B/home/gdr/i686-pc-linux-gnu/lib/ -isystem /home/gdr/i686-pc-lin
ux-gnu/include -isystem /home/gdr/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-de
finition  -isystem ./include  -I. -I. -I/home/gdr/redhat/egcs/gcc -I/home/gdr/re
dhat/egcs/gcc/. -I/home/gdr/redhat/egcs/gcc/../include -I/home/gdr/redhat/egcs/g
cc/../libcpp/include   -g0 -finhibit-size-directive -fno-inline-functions -fno-e
xceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-point
er \
   -c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \
  -o crtbegin.o
make[1]: *** [crtbegin.o] Aborted
make[1]: Leaving directory `/home/gdr/build/4.1/gcc'
make: *** [all-gcc] Error 2


Configuration options were:  --enable-languages=c++ --disable-nls

-- Gaby

Re: GCC 4.0 RC1 Available

[Greg Schafer]

On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote:

> The first GCC 4.0 candidate is available from:
> 
> /pub/gcc/prerelease-4.0.0-20050410/

My test results on i686-pc-linux-gnu:

  http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00812.html

All looks good except for the libmudflap failures which I'm not sure about..
but browsing the results from others indicates I'm not alone with those.

Regards
Greg

Re: gcc-3.4-20050401 BUG? generates illegal instruction inX11R6.4.2/mkfontscale/freetypemacro (worksforme)

[Roland Mainz]

Clemens Koller wrote:
> In the freetype-devel list, I got some suggestions:
> This bug/problem seems to concentrate on ppc32/64 and s390 architectures.
> Basically all Type1 fonts shipped with X11 are suspect to this
> problem. I made tests agains UTBI.pfa
> 
> The possible (temporary)fix:
> If I re-compile freetype with -fno-strict-aliasing I can get
> mkfontscale to work!
> It's still not clear whether this is a problem in freetype
> (2.1.7 to 2.1.9 at least), the macros there, or in gcc.

1. Could you please file a bug at https://bugs.freedesktop.org/ and post
the bugid back here ?
2. Can you test the attached patch
(xorg_gcc_strict_aliasing_crasher_fix001.gudiff.txt) and check whether
this fixes the problem (please make sure to use the libfreetype library
build in the xc/ tree or link FreeType2 statically) ?



Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) [EMAIL PROTECTED]
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)Index: xc/config/cf/xorg.cf
===
RCS file: /cvs/xorg/xc/config/cf/xorg.cf,v
retrieving revision 1.45
diff -u -2 -0 -r1.45 xorg.cf
--- xc/config/cf/xorg.cf1 Feb 2005 02:02:31 -   1.45
+++ xc/config/cf/xorg.cf12 Apr 2005 02:03:39 -
@@ -1524,41 +1524,46 @@
 #  else
 #   define DefaultCCOptions -ansi -pedantic GccWarningOptions
 #  endif
 # endif
 # if defined(UseInstalled)
 #  ifndef UseGccMakeDepend
 #   define UseGccMakeDepend YES
 #  endif
 # endif
 #endif
 
 /* Make imake noisier.  Note that this is ineffective for 3.0 <= GCC <= 3.2 */
 #ifndef ImakeWarningFlags
 # ifdef Gcc28Warnings
 #  define ImakeWarningFlags Gcc28Warnings
 # else
 #  define ImakeWarningFlags /* */
 # endif
 #endif
 
-#if  ((GccMajorVersion == 3) &&  (GccMinorVersion >= 1)) || (GccMajorVersion > 
3)
+/* PPC and S390(x) always need -fno-strict-aliasing to avoid crash in in
+ * Freetype code and some other locations */
+#if  (((GccMajorVersion == 3) &&  (GccMinorVersion >= 1)) || (GccMajorVersion 
> 3)) \
+  || defined (PpcArchitecture) \
+  || defined (s390Architecture) \
+  || defined (s390xArchitecture) 
 # define GccAliasingArgs  -fno-strict-aliasing
 #else
 # define GccAliasingArgs  /* */
 #endif
 
 #if HasGcc2 && defined(i386Architecture)
 # ifndef DefaultGcc2i386Opt
 #  define DefaultGcc2i386Opt -O2 -fno-strength-reduce GccAliasingArgs
 # endif
 #endif
 
 #if HasGcc2 && defined(AMD64Architecture)
 # ifndef DefaultGcc2AMD64Opt
 #  define DefaultGcc2AMD64Opt -O2 -fno-strength-reduce GccAliasingArgs
 # endif
 #endif
 
 #if HasGcc2 && defined(AlphaArchitecture)
 # ifndef DefaultGcc2AxpOpt
 #  define DefaultGcc2AxpOpt -O2 GccAliasingArgs

Re: Mainline build failure on i686-pc-linux-gnu

[Diego Novillo]

On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote:

>-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \
>   -o crtbegin.o
> make[1]: *** [crtbegin.o] Aborted
> make[1]: Leaving directory `/home/gdr/build/4.1/gcc'
> make: *** [all-gcc] Error 2
> 
What's your top-of-ChangeLog?  Works for me up to

2005-04-11  Diego Novillo  <[EMAIL PROTECTED]>

PR tree-optimization/20933
* tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move
[ ... ]


Diego.

Re: GCC 4.0 RC1 Available

[Geoffrey Keating]

Mark Mitchell <[EMAIL PROTECTED]> writes:

> The first GCC 4.0 candidate is available
...
> Then, if you are running on a primary or secondary platform, please
> send me an email pointing me at the results you've posted, and
> highlighting any failures to meet the release criteria.

Hi Mark,

I'm pleased to say that there are no regressions in RC1 on
powerpc-darwin8 compared to 3.4.3, except for:

gcc/testsuite/g++.sum:FAIL: g++.dg/warn/Wdtor1.C (test for excess errors)

which I see you've already committed a patch for, and a large number
of Java failures.

You can see full test results at



for 3.4.3, and



for 4.0.0-20050410.

Re: GCC 4.0 RC1 Available

[Mark Mitchell]

Marcus Meissner wrote:
Btw,
We still see some critical 4.0 problems, ordered by my view of 
importance:

PR/20126 triggers a miscompilation of python (i386 and x86_64 at least).
PR/20917 triggers a miscompilation of glibc (on s390).
PR/20739 triggers a --enable-checking problem triggering in ncurses (all 
platforms)
PR/20929 triggers a miscompilation of Mozilla.
Those are all on the Wiki page as possible patches for an RC2.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

about the parse tree

[zouq]

i want very much to learn more about the parse tree in gcc.
but it`s much more complicate than i have thought.
can some one show me some way to learn it a little easier,
i have tried to debug it, but the structure is difficult to understand,
and i can`t find any document about it, except the comment in the source
code.
thanks.

RTL code

[Rajkishore Barik]

Can someone tell me if there is a way to generate RTL code which does not
include use and def of the same pseudo in the same insn? Of course, I 
can break every such instruction into two but I am wondering if it is 
already
there or anyone has the code already available.

i.e. generate 
t=p56+p76;
p56=t;

instead of
p56=p56+p76;

--R

Re: Mainline build failure on i686-pc-linux-gnu

[Gabriel Dos Reis]

Diego Novillo <[EMAIL PROTECTED]> writes:

| On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote:
| 
| >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \
| >   -o crtbegin.o
| > make[1]: *** [crtbegin.o] Aborted
| > make[1]: Leaving directory `/home/gdr/build/4.1/gcc'
| > make: *** [all-gcc] Error 2
| > 
| What's your top-of-ChangeLog?  Works for me up to
| 
| 2005-04-11  Diego Novillo  <[EMAIL PROTECTED]>
| 
| PR tree-optimization/20933
| * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move
|   [ ... ]

I have

2005-04-11  Geoffrey Keating  <[EMAIL PROTECTED]>

* config/t-slibgcc-darwin: Don't put shared libraries in
directories other than $(slibdir).
* config/rs6000/darwin.h: Find -m64 libgcc under the name the
OS uses for it.

2005-04-11  Diego Novillo  <[EMAIL PROTECTED]>

PR tree-optimization/20933
* tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move
logic to reject aliases between read-only and writable
variables ...
(may_alias_p): ... here.
(get_tmt_for): Do not associate read-only tags to pointers
whose pointed-to type is not read-only.
* tree-ssa.c (verify_ssa): Check that memory stores have at
least one V_MAY_DEF or V_MUST_DEF.


Bootstrap fails at the same point as regular make.

-- Gaby

Re: Mainline build failure on i686-pc-linux-gnu

[Gabriel Dos Reis]

Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

| Diego Novillo <[EMAIL PROTECTED]> writes:
| 
| | On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote:
| | 
| | >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \
| | >   -o crtbegin.o
| | > make[1]: *** [crtbegin.o] Aborted
| | > make[1]: Leaving directory `/home/gdr/build/4.1/gcc'
| | > make: *** [all-gcc] Error 2
| | > 
| | What's your top-of-ChangeLog?  Works for me up to
| | 
| | 2005-04-11  Diego Novillo  <[EMAIL PROTECTED]>
| | 
| | PR tree-optimization/20933
| | * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move
| | [ ... ]
| 
| I have
| 
| 2005-04-11  Geoffrey Keating  <[EMAIL PROTECTED]>
| 
| * config/t-slibgcc-darwin: Don't put shared libraries in
| directories other than $(slibdir).
| * config/rs6000/darwin.h: Find -m64 libgcc under the name the
| OS uses for it.

This might be due to the bootstrapping compiler -- I was using a
compiler built from yesterday tree to bootstrap

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/gdr/redhat/egcs/configure --prefix=/home/gdr 
--enable-languages=c++ --disable-nls
Thread model: posix
gcc version 4.1.0 20050411 (experimental)


Blowing away that compiler and using the native compiler (3.3.1) of my
system let me complete the build.

Whatever problem there was yesterday, it seems to have been fixed.

Thanks,

-- Gaby

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Alexandre Oliva]

On Apr 11, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:

> On Mon, Apr 11, 2005 at 05:41:56PM -0300, Alexandre Oliva wrote:
>> I take that back.  The hash tables seem to be fine.  I suspect it's
>> the sorting on pointers in the goto_queue that triggers the problem.
>> In fact, I'm pretty sure comparing pointers that are not guaranteed to
>> be in the same array invokes undefined behavior, and I do remember
>> having run into errors because of such abuse in bfd many moons ago.

> Technically, yes.  I deny that it's a problem in practice except
> for segmented architectures.  Which includes no gcc hosts.

The comparison of pointers may not be a problem for GCC hosts, but
it's indeed what breaks bootstraps.  We sort the goto queue on
the address of its stmt, and then walk the array in sequential order
in lower_try_finally_switch().  This is exactly the sort of dependency
on pointers that we've just agreed we should avoid.

In case the problem isn't clear, we assign switch indexes growing from
0, then we sort the goto_queue VARRAY by stmt address, then generate
the switch stmt along with new artificial labels.  Even though the
switch statement is later sorted by index, its label names and
redirecting BBs that follow are in a different order, so bootstrap
comparison fails.  Here's a diff between two compiles of
targparm.adb's t12.eh dump:

@@ -1526,8 +1526,8 @@
   system__soft_links__set_jmpbuf_address_soft (JMPBUF_SAVED.1373);
   switch (finally_tmp.174D.3471)
 {
-  case 0: goto ;
-  case 2: goto ;
+  case 0: goto ;
+  case 1: goto ;
   case 3: goto ;
   default : goto ;
 }
@@ -1544,13 +1544,13 @@
   goto ;
   :;
   __builtin_stack_restore (saved_stack.54D.1849);
-  goto ;
+  goto ploop_continueD.1185;
   :;
   __builtin_stack_restore (saved_stack.54D.1849);
-  goto ploop_continueD.1185;
+  goto line_loop_continueD.1186;
   :;
   __builtin_stack_restore (saved_stack.54D.1849);
-  goto line_loop_continueD.1186;
+  goto ;
   :;
   ploop_continueD.1185:;
   kD.1369 = kD.1369 + 1;

See how we've simply rotated the final target of the switch indexes?
The intermediate group of labels that are goto targets from the switch
statement are each followed by a goto statement to a label in the
second hunk of the diff, in the same order.


It looks like it wouldn't be too hard to overcome this problem by
generating the artificial labels in case_index order, instead of in
goto_queue order, but it's not obvious to me that the potential
randomness from sorting of stmt addresses in the goto_queue that have
the same index couldn't possibly affect the outcome.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Bootstrap failure on i686-pc-linux-gnu since 2005-04-09 20:41UTC

[Kazu Hirata]

Hi,

I have been getting bootstrap failures on i686-pc-linux-gnu since
Caroline's patch

  http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00541.html

Errors go like so:

org/xml/sax/helpers/ParserAdapter.java: In class 
'org.xml.sax.helpers.ParserAdapter':
org/xml/sax/helpers/ParserAdapter.java: In constructor '()':
org/xml/sax/helpers/ParserAdapter.java:84: internal compiler error: 
Segmentation fault

I have confirmed that the first patch attached to PR 20934 fixes this
problem.  Looking at the audit trails in PR 20934, I see that Caroline
has been working on this problem.  What is the status of the patch?
Is there more work or refinement needed?

Kazu Hirata

Re: GCC 4.0 RC1 Available

[Eric Botcazou]

> which I see you've already committed a patch for, and a large number
> of Java failures.
>
> 
>
> for 4.0.0-20050410.

Same failure as on Solaris.

Andrew, do you have a Darwin machine at hand?

-- 
Eric Botcazou

Re: Bootstrap failure on i686-pc-linux-gnu since 2005-04-09 20:41UTC

[Caroline Tice]

The patch has just been submitted to gcc-patches for
approval (the tests are nearly done and appear to
be passing so far).
-- Caroline
[EMAIL PROTECTED]
On Apr 11, 2005, at 10:12 PM, Kazu Hirata wrote:
Hi,
I have been getting bootstrap failures on i686-pc-linux-gnu since
Caroline's patch
  http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00541.html
Errors go like so:
org/xml/sax/helpers/ParserAdapter.java: In class 
'org.xml.sax.helpers.ParserAdapter':
org/xml/sax/helpers/ParserAdapter.java: In constructor '()':
org/xml/sax/helpers/ParserAdapter.java:84: internal compiler error: 
Segmentation fault

I have confirmed that the first patch attached to PR 20934 fixes this
problem.  Looking at the audit trails in PR 20934, I see that Caroline
has been working on this problem.  What is the status of the patch?
Is there more work or refinement needed?
Kazu Hirata

Re: GCC 4.0 RC1 Available

[Ranjit Mathew]

Geoffrey Keating wrote:
[...]
> which I see you've already committed a patch for, and a large number
> of Java failures.
> 
> You can see full test results at
[...]
> 
> 
> 
> for 4.0.0-20050410.

It might be helpful to put your "libjava.log" somewhere
or if all the Java failures seem similar, to post
the error messages around the "FAIL" lines from your
libjava.log.

Thanks,
Ranjit.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Alexandre Oliva]

On Apr 12, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> It looks like it wouldn't be too hard to overcome this problem by
> generating the artificial labels in case_index order, instead of in
> goto_queue order, but it's not obvious to me that the potential
> randomness from sorting of stmt addresses in the goto_queue that have
> the same index couldn't possibly affect the outcome.

This is what I had in mind with the paragraph above.  Does it feel
like a reasonable approach?  (Note that the two sets of
last_case_index were dead, so the patch removes them)

Index: gcc/tree-eh.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-eh.c,v
retrieving revision 2.28
diff -u -p -r2.28 tree-eh.c
--- gcc/tree-eh.c 1 Apr 2005 03:42:44 - 2.28
+++ gcc/tree-eh.c 12 Apr 2005 05:51:36 -
@@ -1194,7 +1194,6 @@ lower_try_finally_switch (struct leh_sta
   q = tf->goto_queue;
   qe = q + tf->goto_queue_active;
   j = last_case_index + tf->may_return;
-  last_case_index += nlabels;
   for (; q < qe; ++q)
 {
   tree mod;
@@ -1217,20 +1216,37 @@ lower_try_finally_switch (struct leh_sta
 
   case_index = j + q->index;
   if (!TREE_VEC_ELT (case_label_vec, case_index))
-	{
-	  last_case = build (CASE_LABEL_EXPR, void_type_node,
-			 build_int_cst (NULL_TREE, switch_id), NULL,
-			 create_artificial_label ());
-	  TREE_VEC_ELT (case_label_vec, case_index) = last_case;
-
-	  x = build (LABEL_EXPR, void_type_node, CASE_LABEL (last_case));
-	  append_to_statement_list (x, &switch_body);
-	  append_to_statement_list (q->cont_stmt, &switch_body);
-	  maybe_record_in_goto_queue (state, q->cont_stmt);
-	}
+	TREE_VEC_ELT (case_label_vec, case_index)
+	  = build (CASE_LABEL_EXPR, void_type_node,
+		   build_int_cst (NULL_TREE, switch_id), NULL,
+		   /* We store the cont_stmt in the
+		  CASE_LABEL, so that we can recover it
+		  in the loop below.  We don't create
+		  the new label while walking the
+		  goto_queue because pointers don't
+		  offer a stable order.  */
+		   q->cont_stmt);
+}
+  for (j = last_case_index; j < last_case_index + nlabels; j++)
+{
+  tree label;
+  tree cont_stmt;
+
+  last_case = TREE_VEC_ELT (case_label_vec, j);
+
+  gcc_assert (last_case);
+
+  cont_stmt = CASE_LABEL (last_case);
+
+  label = create_artificial_label ();
+  CASE_LABEL (last_case) = label;
+
+  x = build (LABEL_EXPR, void_type_node, label);
+  append_to_statement_list (x, &switch_body);
+  append_to_statement_list (cont_stmt, &switch_body);
+  maybe_record_in_goto_queue (state, cont_stmt);
 }
   replace_goto_queue (tf);
-  last_case_index += nlabels;
 
   /* Make sure that the last case is the default label, as one is required.
  Then sort the labels, which is also required in GIMPLE.  */

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}