Re: gcc trunk build failure on i686 darwin9

[Dominique Dhumieres]

> Is anyone else seeing the following build failure on i686 Darwin9?

Yes, on both ppc and i686 Darwin9.

Dominique

Re: Who broke bootstrap!

[Gerald Pfeifer]

On Fri, 29 Aug 2008, Steve Kargl wrote:
> checking for i386-unknown-freebsd8.0-gcc... 
> /usr/home/kargl/gcc/obj/./gcc/xgcc -B/usr/home/kargl/gcc/obj/./gcc/ 
> -B/usr/home/kargl/work/i386-unknown-freebsd8.0/bin/ 
> -B/usr/home/kargl/work/i386-unknown-freebsd8.0/lib/ -isystem 
> /usr/home/kargl/work/i386-unknown-freebsd8.0/include -isystem 
> /usr/home/kargl/work/i386-unknown-freebsd8.0/sys-include
> checking for suffix of object files... configure: error: in 
> `/usr/home/kargl/gcc/obj/i386-unknown-freebsd8.0/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> gmake[2]: *** [configure-stage2-target-libgcc] Error 1
> gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj'
> gmake[1]: *** [stage2-bubble] Error 2
> gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj'
> gmake: *** [all] Error 2

On i386-unknown-freebsd6.3 (instead of 8.0) I am getting the following
for SVN revision 139789 and since 2008-08-25 21:00 UTC at least:

/files/pfeifer/gcc/i386-unknown-freebsd6.3/sys-include -g -O2 -O2  -g -O2 
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
-Wcast-qual -Wold-style-definition  -isystem ./include   -fPIC -pthread -g 
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. 
-I../.././gcc -I/sw/test/GCC/trunk/libgcc -I/sw/test/GCC/trunk/libgcc/. 
-I/sw/test/GCC/trunk/libgcc/../gcc -I/sw/test/GCC/trunk/libgcc/../include -o 
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c 
/sw/test/GCC/trunk/libgcc/../gcc/libgcc2.c \
/sw/test/GCC/trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/sw/test/GCC/trunk/libgcc/../gcc/libgcc2.c:566: internal compiler error:
Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gmake[3]: *** [_muldi3.o] Error 1
gmake[3]: Leaving directory 
`/usr/nabil-files/pfeifer/OBJ-0829-2328/i386-unknown-freebsd6.3/libgcc'
gmake[2]: *** [all-stage2-target-libgcc] Error 2
gmake[2]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0829-2328'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0829-2328'
gmake: *** [bootstrap-lean] Error 2

I assume this is one the too common cases where we have broken i386 (as
opposed to i486/i586).

Gerald

Re: Who broke bootstrap!

[Eric Botcazou]

> On i386-unknown-freebsd6.3 (instead of 8.0) I am getting the following
> for SVN revision 139789 and since 2008-08-25 21:00 UTC at least:
>
> /files/pfeifer/gcc/i386-unknown-freebsd6.3/sys-include -g -O2 -O2  -g -O2
> -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include
>   -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
> -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
> -I/sw/test/GCC/trunk/libgcc -I/sw/test/GCC/trunk/libgcc/.
> -I/sw/test/GCC/trunk/libgcc/../gcc -I/sw/test/GCC/trunk/libgcc/../include
> -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
> /sw/test/GCC/trunk/libgcc/../gcc/libgcc2.c \
> /sw/test/GCC/trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3':
> /sw/test/GCC/trunk/libgcc/../gcc/libgcc2.c:566: internal compiler error:
> Segmentation fault: 11
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> gmake[3]: *** [_muldi3.o] Error 1
> gmake[3]: Leaving directory

i586-linux is broken in exactly the same way.  gimple.c:gimple_build_asm_vec 
is miscompiled at -O2 -fomit-frame-pointer by regalloc/reload because of 
inconsistent elimination offsets at a block boundary.  It's the IRA merge.

I'd suggest opening a PR, I'll attach a reduced testcase and the analysis.

-- 
Eric Botcazou

Re: gcc trunk build failure on i686 darwin9

[Jack Howarth]

Dominique,
Can you try to identify the regression (I'm at work today)? It
should be somewhere between r139740 and r139791.
   Jack

On Sat, Aug 30, 2008 at 10:21:49AM +0200, Dominique Dhumieres wrote:
> > Is anyone else seeing the following build failure on i686 Darwin9?
> 
> Yes, on both ppc and i686 Darwin9.
> 
> Dominique

Re: gcc trunk build failure on i686 darwin9

[Dominique Dhumieres]

> should be somewhere between r139740 and r139791.

I have a slightly narrower range: r139753 worked with a clean bootstrap.
Then incremental updates worked for r139766, 768, and 786. r139791 failed 
with a clean bootstrap up to 801 (incremental updates).  Now the strange 
thing is that I reverted to r139780 and the incremental bootstrap failed!
I am currently doing a clean bootstrap of r139786.

Dominique

Re: gcc trunk build failure on i686 darwin9

[Dominique Dhumieres]

I have done a clean bootstrap for r139780 and it failed.
So the fork is between r139753 (working) and r139780 (broken).
I have also understood why I did not see the failures for the
incremental updates: they did not rebuild libstdc++-v3 where
the failure occurs.

Dominique

mkheaders in GCC 4.3.2 seems to break studio.h ?

[Dennis Clarke]

Chances are that I botched up something .. not sure what exactly.
Nothing fancy here .. just a bootstrapped GCC 4.3.2

I ran mkheaders and I think that managed to really botch up studio.h

/* first, some sample code ***/

$ cat hello.c
#include 
int main(int argc, char *argv[]){
int some_int;
some_int = 1;
printf( "Hello World, have an integer. This one = %i\n", some_int );
return (0);
}

/* compile with vendor compiler tools /

On Solaris 8 Sparc I can use Sun Studio 8 thus :

$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.5 Patch 112760-19 2007/08/02
usage: cc [ options] files.  Use 'cc -flags' for details

I'm using the local Sun provided assembler and linker :

$ which as
/usr/ccs/bin/as
$ which ld
/usr/ccs/bin/ld

$ /opt/SUNWspro/bin/cc -o hello.s -S -c hello.c

$ cat hello.s

.section".text",#alloc,#execinstr
.align  8
.skip   16

! block 0

.global main
.type   main,#function
main:
save%sp,-104,%sp

! block 1
.L90:
st  %i0,[%fp+68]
st  %i1,[%fp+72]

! File hello.c:
!1  #include 
!2  int main(int argc, char *argv[]){
!3  int some_int;
!4  some_int = 1;

mov 1,%o1
st  %o1,[%fp-8]

!5  printf( "Hello World, have an integer. This one = %i\n",
some_int );

sethi   %hi(.L92),%o0
or  %o0,%lo(.L92),%o0
callprintf
nop

!6  return (0);

st  %g0,[%fp-4]
mov %g0,%i0
jmp %i7+8
restore

! block 2
.L89:
mov %g0,%i0
jmp %i7+8
restore
.size   main,(.-main)
.align  8

.section".rodata1",#alloc
.align  4
.L92:
.ascii  "Hello World, have an integer. This one = %i\n\000"
.type   .L92,#object
.size   .L92,45

.section".bss",#alloc,#write
Bbss.bss:
.skip   0
.type   Bbss.bss,#object
.size   Bbss.bss,0

.section".data",#alloc,#write
Ddata.data:
.skip   0
.type   Ddata.data,#object
.size   Ddata.data,0

.section".rodata",#alloc
Drodata.rodata:
.skip   0
.type   Drodata.rodata,#object
.size   Drodata.rodata,0

.file   "hello.c"
.xstabs ".stab.index","V=10.0;DBG_GEN=4.14.14;cd;backend;Xa;R=Sun
C 5.5 Patch 112760-19 2007/08/02",60,0,0,0
.xstabs ".stab.index","/export/home/dclarke/pgm/mpfr;
/opt/SUNWspro/prod/bin/cc -S -c  hello.c",52,0,0,0
.xstabs ".stab.index","main",42,0,0,0
.ident  "@(#)stdio.h1.7899/12/08 SMI"
.ident  "@(#)stdio_iso.h1.2 99/10/25 SMI"
.ident  "@(#)feature_tests.h1.1899/07/26 SMI"
.ident  "@(#)isa_defs.h 1.2099/05/04 SMI"
.ident  "@(#)va_list.h  1.1299/05/04 SMI"
.ident  "@(#)stdio_tag.h1.3 98/04/20 SMI"
.ident  "@(#)stdio_impl.h   1.8 99/06/10 SMI"
.ident  "acomp: Sun C 5.5 Patch 112760-19 2007/08/02"

.global __fsr_init_value
__fsr_init_value = 0x0

We can compile, link and run that :

$ /opt/SUNWspro/bin/cc -o hello hello.s

Here is what we have from Sun Studio 8 :

$ ls -lap hello*
-rwxr-xr-x   1 dclarke  csw 5372 Aug 30 16:57 hello
-rw-r--r--   1 dclarke  csw  180 Aug 30 16:53 hello.c
-rw-r--r--   1 dclarke  csw 1764 Aug 30 16:56 hello.s

$ ./hello
Hello World, have an integer. This one = 1

Nothing fancy ..

/** GCC 4.3.2 ***/

Let's try that with GCC 4.3.2 now :

$ which gcc
/opt/csw/gcc4/bin/gcc
$ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix
--enable-nls --enable-shared --enable-languages=c,c++,fortran,objc
--with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-multilib
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--enable-java-awt=xlib --with-system-zlib --enable-bootstrap
Thread model: posix
gcc version 4.3.2 (GCC)

$ gcc -v -o hello_gnu.s -c -S hello.c
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix
--enable-nls --enable-shared --enable-languages=c,c++,fortran,objc
--with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-multilib
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--enable-java-awt=xlib --with-system-zlib --enable-bootstrap
Thread model: posix
gcc version 4.3.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 'hello_gnu.s' '-c' '-S' '-mcpu=v7'
 /opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/cc1 -quiet -v
hello.c -quiet -dumpbase hello.c

going away for a while

[Manuel López-Ibáñez]

Dear all,

My laptop broke today and it was my only computer, so I will be away
for an unspecified amount of time from GCC development until I can get
a new one and sort everything out. Feel free to take any bug that is
assigned to me, or change and resubmit any of my pending patches.
Apologies to anyone who was waiting for me to fix something in
particular. It is a pity because I had a long queue of patches almost
ready for GCC 4.4. :-(

Best wishes,

Manu.

Re: gcc trunk build failure on i686 darwin9

[Dominique Dhumieres]

>From broken r139780, I did an incremental downgrade to r139770 (still
broken) then to r139760 which seems to work (building libjava).
So the window seems between r139760 and r139770.

Dominique

Re: IRA_COVER_CLASSES

[Vladimir Makarov]

Hans-Peter Nilsson wrote:

I think the necessity and urgency of IRA_COVER_CLASSES, calls
for a few more details to be documented.

tm.texi says for it:
Cover classes are a set of non-intersecting register
classes covering all hard registers used for register allocation
purposes.

Ok, so I can construct a set from reg_class already.  It's so
simple a gen* program could do it.  But I hear, some tweaking is
usually at least recommended.

  
Actually I tried to construct an algorithm to build IRA_COVER_CLASSES 
but I failed.  There are usually several variants of choosing 
IRA_COVER_CLASS.  Some of them will work best (with performance point of 
view).  Some (or all in worst case scenario) variants might result in 
reload bugs and some pattern and reload related macros tweaking will be 
need.

Should I prune that set and if so, what's a good huristic to
prune it?  Which classes *must* I keep?  The ones used with
REG_CLASS_FROM_CONSTRAINT/REG_CLASS_FROM_LETTER?  Should
e.g. singleton classes be avoided for some reason?

  
My experience shows that classes in IRA_COVER_CLASS should be as big as 
possible.  So it is better to avoid singleton classes.  But again there 
might be exceptions (as I remember ppc has one signleton class separated 
from GENERAL_REGS).


I tried to implement algorithm to choose IRA_COVER_CLASSES as biggest 
non-intersected classes within each cover class any hard-register moving 
(if it is possible) is cheaper than load or store of the register.

It also says:
Any move between two registers in the same cover class
should be cheaper than load or store of the registers.

But, one of the classes, is such that I can't move between
registers *within* the same class (just between that class and
GENERAL_REGS or memory)!  How should I treat that class?  Or
maybe the documentation should be amended to say "If a move
between two registers in the same cover class are possible, it
should be cheaper than a load or store"?  (Looking at the ARM
port, it looks like the answer to the last question is "yes".)
  
Yes, that is true.  Your definition is more clear and unambigous.  I'll 
post a patch with your variant.

Re: gcc trunk build failure on i686 darwin9

[Jack Howarth]

On Sat, Aug 30, 2008 at 09:13:03PM +0200, Dominique Dhumieres wrote:
> >From broken r139780, I did an incremental downgrade to r139770 (still
> broken) then to r139760 which seems to work (building libjava).
> So the window seems between r139760 and r139770.
> 
> Dominique

Dominique,
I am seeing the same failure in r139763. I'll try r139761 next.
   Jack

RE: "random" "Link tests are not allowed after GCC_NO_EXECUTABLES" -- resolved and some suggestions..

[Jay]

> From: [EMAIL PROTECTED]
> To: gcc@gcc.gnu.org
> Subject: "random" "Link tests are not allowed after GCC_NO_EXECUTABLES"
> Date: Wed, 27 Aug 2008 08:30:29 +
>
>
> gcc 4.3.1 with small patches... (merged tree with binutils 2.18/gmp/mpfr, 
> also slightly patched)
> build=i686-pc-cygwin
> host=i686-pc-cygwin
> target=i686-pc-mingw32
>
> checking for ld that supports -Wl,--gc-sections... configure: error: Link 
> tests
> are not allowed after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-target-libstdc++-v3] Error 1
> make[1]: Leaving directory `/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32'
> make: *** [all] Error 2
>
...
> Anyway, this is just a random report, like "cross building is a little too 
> difficult".


This was, for me a problem I have hit multiple times, lack of a sys-root, or 
lack
of a correct sys-root.
I'm wrapping everything up in Python...and I rather think toplevel
configure should do some of the checks my Python does, to
catch errors earlier and to tell people what to do about them.

SOMETHING LIKE SO: 

def DoBuild(Host = None, Target = None, ExtraConfig = " "):

if Host == None:
Host = Build

if Target == None:
Target = Build

DefaultSysroot = (Prefix + "/" + Target + "/sys-root")

 [snip] 
#
# cross builds have extra requirements that are not automated,
# in particular setting up "sys-root" or headers/libs ahead of time.
# This is a very tricky area -- since it isn't automated and errors
# doing this are often not caught till late, which is extra
# frustrating.
# Try to catch these errors early here.
#
# NOTE that if you are doing an "integrated" build with glibc or newlib,
# then this is likely less of an issue, you are building the sysroot.
# glibc is typical for Linux.
# newlib is typical for embedded systems.
# That still leaves many other systems such as Cygwin, MinGWin, and
# commercial Unices with their native libc such as Solaris, HP-UX, AIX.
#
# NOTE that Cygwin does use newlib, but I don't have that setup to work 
here yet.
# I build Cygwin separately.
#

if Build != Target:

if Target.find("msdosdjgpp") != -1:

#
# I don't remember why I put this in, but it makes some sense -- no 
dynamic linking on djgpp.
#

ExtraConfig += " -disable-shared -enable-static "

#
# djgpp "favors" the pre-sysroot method, via the djgpp cross package
#

for a in [
#"lib",
"include"]:
b = Prefix + "/" + Target + "/" + a
if not os.path.isdir(b):
print("ERROR: Please create " + b + ", such as by 
extracting djcrx.zip in /usr/local/i586-pc-msdosdjgpp")
exit(1)
ExtraConfig += " -with-headers=" + Prefix + "/" + Target + 
"/include "
#ExtraConfig += " -with-libs=" + Prefix + "/" + Target + "/lib "

else:

#
# mingw sys-root is unusual; help the user
#

if Target == 'i686-pc-mingw32':

for a in ["lib", "include"]:
b = DefaultSysroot + "/mingw/" + a
if not os.path.isdir(b):
print("ERROR: Please create " + b + ", such as by a 
link (or NTFS junction) to /mingw/" + a)
exit(1)

#
# normal sys-root
#

if not os.path.isdir(DefaultSysroot):
print("ERROR: Please put appropriate subset of " + Target + " 
file system at " + DefaultSysroot + " (such as /lib, /usr/lib, /usr/include)")
exit(1)
ExtraConfig += " -with-sysroot "

#
# try workaround Canadian fixincludes not understanding sysroot of the 
cross compiler used to build it
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37036
#
if (Host == Target) and (Host != Build):
ExtraConfig += " -with-sysroot=/"
ExtraConfig += " -with-build-sysroot=" + DefaultSysroot


I've used this for native cygwin, sparc-solaris, sparc64-solaris, mingwin.
Not yet djgpp (despite some code).
Not yet Linux, BSD, ARM, embedded, AIX, HPUX, IRIX, etc.

That is: It maybe isn't yet as general or specific as it should be.
In particular, I think for a merged tree with newlib/glibc, it can just notice
the existance of certain directories and know everything is ok.
It is probably correct for all the "commercial Unices" and *BSD.

As well, if user specified -with-sysroot and/or -with-build-sysroot, help them 
less -- skip all this approx.
   But still some sanity checking like for mingwin I think.
   Or maybe sanity check them all -- check for limits.h and/or stdio.h.
   You know, like how cc/cpp are checked for, check for those files up front, 
unless
   detected that you are going to build them (again, the glibc/newlib case, I 
think). 
  
See here, I'm 

Re: gcc trunk build failure on i686 darwin9

[Dominique Dhumieres]

> I am seeing the same failure in r139763. I'll try r139761 next.

r139761 works, and I confirm that r139763 is broken.
I'll do r139762.

Dominique

Re: gcc trunk build failure on i686 darwin9

[Dominique Dhumieres]

r139762 seems broken. Could you fill a bug report: it's bed time for me
and our mail exchange did not seem to have attracted any attention.

Revision 139762

Jump to revision:
Author: hubicka
Date:   Fri Aug 29 11:39:04 2008 UTC (35 hours, 39 minutes ago)
Log Message:
* doc/invoke.texi (-fipa-cp): Enabled by default at -O2/-Os/-O3
(-fipa-cp-clone): Enabled by default at -O3.
* opts.c (decode_options): Enable ipa-cp at -O2, ipa-cp-clone at -O3;
make ipa-cp-clone to imply ipa-cp; disable cloning at -Os.

TIA

Dominique

Re: Who broke bootstrap!

[Steve Kargl]

On Sat, Aug 30, 2008 at 03:24:08PM +0200, Eric Botcazou wrote:
> > On i386-unknown-freebsd6.3 (instead of 8.0) I am getting the following
> > for SVN revision 139789 and since 2008-08-25 21:00 UTC at least:
> >
> > /files/pfeifer/gcc/i386-unknown-freebsd6.3/sys-include -g -O2 -O2  -g -O2
> > -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> > -Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include
> >   -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
> > -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
> > -I/sw/test/GCC/trunk/libgcc -I/sw/test/GCC/trunk/libgcc/.
> > -I/sw/test/GCC/trunk/libgcc/../gcc -I/sw/test/GCC/trunk/libgcc/../include
> > -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
> > /sw/test/GCC/trunk/libgcc/../gcc/libgcc2.c \
> > /sw/test/GCC/trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3':
> > /sw/test/GCC/trunk/libgcc/../gcc/libgcc2.c:566: internal compiler error:
> > Segmentation fault: 11
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> > gmake[3]: *** [_muldi3.o] Error 1
> > gmake[3]: Leaving directory
> 
> i586-linux is broken in exactly the same way.  gimple.c:gimple_build_asm_vec 
> is miscompiled at -O2 -fomit-frame-pointer by regalloc/reload because of 
> inconsistent elimination offsets at a block boundary.  It's the IRA merge.
> 
> I'd suggest opening a PR, I'll attach a reduced testcase and the analysis.
> 


I've opened PR 37296 for this problem.

-- 
Steve