Build failure with 3.1 CVS on sparc-sun-solaris2.8

Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Kenneth Lareau]

I know the release of 3.1 is still a few months away, but I'm wondering
if it will be buildable with earlier releases of gcc on the Sparc plat-
form.  I know there's been some corrections with using Sun's compiler
to build it (and it seems to be working), but trying with gcc 2.95.3
seems to fail shortly after the first stage pass completes:

../configure --with-cpu=ultrasparc --prefix=/usr/local/gcc
[...]

make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
[stage 1 runs successfully]
[...]
stage1/xgcc -Bstage1/ -B/usr/local/gcc/sparc-sun-solaris2.8/bin/ -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H -DGENERATOR_FILE  -o genflags \
 genflags.o rtl.o read-rtl.o bitmap.o ggc-none.o gensupport.o print-rtl.o errors.o ../libiberty/libiberty.a
ld: warning: file ../libiberty/libiberty.a(hashtab.o): wrong ELF class: ELFCLASS32
Undefined          first referenced
 symbol                in file
htab_create                         read-rtl.o
_obstack_begin                      genflags.o
_sch_toupper                        genflags.o
obstack_free                        read-rtl.o
htab_find                           read-rtl.o
_sch_istable                        read-rtl.o
xstrdup                             read-rtl.o
xmalloc                             genflags.o
htab_find_slot                      read-rtl.o
_obstack_newchunk                   genflags.o
htab_traverse                       read-rtl.o
ld: fatal: Symbol referencing errors. No output written to genflags
collect2: ld returned 1 exit status
gmake[2]: *** [genflags] Error 1
gmake[2]: Leaving directory home/klareau/gcc/sparc-sun-solaris2.8/gcc'
gmake[1]: *** [stage2_build] Error 2
gmake[1]: Leaving directory home/klareau/gcc/sparc-sun-solaris2.8/gcc'
gmake: *** [bootstrap] Error 2

After trying a quick test, apparently it seems that the stage 1 xgcc
builds 64-bit object files and executables by default, which causes
the above to fail since libiberty was built as a 32-bit library.  I
can get around this by first building a single pass of just the C com-
piler, install it, then use it to do a full bootstrap, but that method
seems a bit of a hack.

So I guess the question is will gcc 3.1 be buildable with only Sun's
compilers or a pre-built 64-bit version of gcc 3.1 on Sparc, or can
this issue be fixed relatively easily to allow earlier versions of
gcc to build 3.1 properly?

Ken Lareau
elessar@numenor.org

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Jeff Sturm]

On Wed, 6 Feb 2002, Kenneth Lareau wrote:
> ../configure --with-cpu=ultrasparc --prefix=/usr/local/gcc

You cannot bootstrap the 64-bit compiler with a 32-bit compiler.
The GCC build framework doesn't currently distinguish between build
libraries and host libraries, so effectively it requires (build == host)
for a bootstrap.

If you omit --with-cpu=ultrasparc the bootstrap will be
straightforward, resulting in a compiler that can run on a 32-bit host but
still generate executables for 64-bit ultrasparc.

Bootstrapping in two steps as you say is one workaround, building a cross
compiler is another.

Jeff

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Richard Henderson]

On Wed, Feb 06, 2002 at 02:06:47PM -0500, Jeff Sturm wrote:
> If you omit --with-cpu=ultrasparc the bootstrap will be
> straightforward, resulting in a compiler that can run on a 32-bit host but
> still generate executables for 64-bit ultrasparc.

This indicates a bug in the configury somewhere: --with-cpu should only
affect arch selection and tuning.  It should not affect 32-bit vs 64-bit.

So --with-cpu=ultrasparc should select TARGET_V8PLUS, not TARGET_64BIT.


r~

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Kenneth Lareau]

In message <20020206171648.B28289@redhat.com>, Richard Henderson writes:
>On Wed, Feb 06, 2002 at 02:06:47PM -0500, Jeff Sturm wrote:
>> If you omit --with-cpu=ultrasparc the bootstrap will be
>> straightforward, resulting in a compiler that can run on a 32-bit host but
>> still generate executables for 64-bit ultrasparc.
>
>This indicates a bug in the configury somewhere: --with-cpu should only
>affect arch selection and tuning.  It should not affect 32-bit vs 64-bit.
>
>So --with-cpu=ultrasparc should select TARGET_V8PLUS, not TARGET_64BIT.

As per Jeff's suggestion, I removed the --with-cpu option and the build
completed successfully without any further issues; of this, I am grateful.

However, on a whim, I installed the new binaries, then tried to rebuild
gcc with the following configure:

CC="gcc -m64" ../configure --with-cpu=ultrasparc --prefix=/usr/local/gcc64 sparcv9-sun-solaris2.8

Things went well during the first stage, and into the second, until this
point:

stage1/xgcc -Bstage1/ -B/usr/local/gcc64/sparcv9-sun-solaris2.8/bin/ -c -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H    -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include ../../gcc/expr.c -o expr.o
xgcc: Internal error: Segmentation Fault (program cc1)
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
gmake[2]: *** [expr.o] Error 1

It took quite a while (nearly 10 minutes) before it errored out, so it
looks like gcc may not be sufficient to build itself in full 64-bit.  If
additional information is desired regarding this, I can produce it.

Once again, thanks for the help; it looks like there's a light at the end
of the tunnel for 64-bit support on Sparc with gcc.


Kenneth Lareau
elessar@numenor.org

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Richard Henderson]

On Wed, Feb 06, 2002 at 05:29:10PM -0800, Kenneth Lareau wrote:
> It took quite a while (nearly 10 minutes) before it errored out, so it
> looks like gcc may not be sufficient to build itself in full 64-bit.  If
> additional information is desired regarding this, I can produce it.

With sources as of what date?  I believe I fixed this
Monday afternoon (2002-02-04).


r~

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Kenneth Lareau]

On Wed, 6 Feb 2002 17:32:07 -0800 Richard Henderson <rth@redhat.com> wrote:

> On Wed, Feb 06, 2002 at 05:29:10PM -0800, Kenneth Lareau wrote:
> > It took quite a while (nearly 10 minutes) before it errored out, so it
> > looks like gcc may not be sufficient to build itself in full 64-bit.  If
> > additional information is desired regarding this, I can produce it.
> 
> With sources as of what date?  I believe I fixed this
> Monday afternoon (2002-02-04).

I'm pretty certain I ran 'cvs update' before building this morning... un-
fortunately I'm now at home while my build is (inaccessibly) at work, so
I can't verify until tomorrow.

Kenneth Lareau
elessar@numenor.org

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Kenneth Lareau]

In message <20020206183224.105bf938.elessar@numenor.org>, Kenneth Lareau writes
:
>On Wed, 6 Feb 2002 17:32:07 -0800 Richard Henderson <rth@redhat.com> wrote:
>
>> On Wed, Feb 06, 2002 at 05:29:10PM -0800, Kenneth Lareau wrote:
>> > It took quite a while (nearly 10 minutes) before it errored out, so it
>> > looks like gcc may not be sufficient to build itself in full 64-bit.  If
>> > additional information is desired regarding this, I can produce it.
>> 
>> With sources as of what date?  I believe I fixed this
>> Monday afternoon (2002-02-04).
>
>I'm pretty certain I ran 'cvs update' before building this morning... un-
>fortunately I'm now at home while my build is (inaccessibly) at work, so
>I can't verify until tomorrow.

I checked, and I had updated my sources yesterday before doing the build.
I ran a 'cvs update' again this afternoon, with the same error occurring:

CC="gcc -m64" ../configure --with-cpu=ultrasparc --prefix=/usr/local/gcc64 sparcv9-sun-solaris2.8

gmake CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
[stage 1 successful]
[...]
stage1/xgcc -Bstage1/ -B/usr/local/gcc64/sparcv9-sun-solaris2.8/bin/ -c -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H    -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include ../../gcc/expr.c -o expr.o
xgcc: Internal error: Segmentation Fault (program cc1)
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
gmake[2]: *** [expr.o] Error 1


Kenneth Lareau
elessar@numenor.org

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Kenneth Lareau]

Update:

I decided to rebuild the 32-bit bi-arch version with a CVS update, and then
try the 64-bit build again... this time both builds went flawlessly.  Thanks
for your help, folks, it was greatly appreciated, and it's good to see that
full 64-bit support for Sparc is almost fully here.

Kenneth Lareau
elessar@numenor.org


On Thu, 07 Feb 2002 15:21:12 -0800 Kenneth Lareau <elessar@numenor.org> wrote:

> In message <20020206183224.105bf938.elessar@numenor.org>, Kenneth Lareau writes
> :
> >On Wed, 6 Feb 2002 17:32:07 -0800 Richard Henderson <rth@redhat.com> wrote:
> >
> >> On Wed, Feb 06, 2002 at 05:29:10PM -0800, Kenneth Lareau wrote:
> >> > It took quite a while (nearly 10 minutes) before it errored out, so it
> >> > looks like gcc may not be sufficient to build itself in full 64-bit.  If
> >> > additional information is desired regarding this, I can produce it.
> >> 
> >> With sources as of what date?  I believe I fixed this
> >> Monday afternoon (2002-02-04).
> >
> >I'm pretty certain I ran 'cvs update' before building this morning... un-
> >fortunately I'm now at home while my build is (inaccessibly) at work, so
> >I can't verify until tomorrow.
> 
> I checked, and I had updated my sources yesterday before doing the build.
> I ran a 'cvs update' again this afternoon, with the same error occurring:
> 
> CC="gcc -m64" ../configure --with-cpu=ultrasparc --prefix=/usr/local/gcc64 sparcv9-sun-solaris2.8
> 
> gmake CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
> [stage 1 successful]
> [...]
> stage1/xgcc -Bstage1/ -B/usr/local/gcc64/sparcv9-sun-solaris2.8/bin/ -c -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H    -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include ../../gcc/expr.c -o expr.o
> xgcc: Internal error: Segmentation Fault (program cc1)
> Please submit a full bug report.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> gmake[2]: *** [expr.o] Error 1
> 
> 
> Kenneth Lareau
> elessar@numenor.org
> 

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Richard Henderson]

> > 	* config/sparc/sparc.c (compute_frame_size): Don't correct frame
> > 	offset for stack bias.

Applied.


r~

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Brad Lucier]

I just finished a bootstrap with regression tests with this patch.
Things seemed good---there were more failures in the gcc test library,
but these tests seem to have been added since the last time I ran the
regression tests.

Also, I did not get the same failure as before in compiling that large
program.  A cursory examination of the stack-pointer manipulation code
seems to indicate good code generation.

The test results are at

http://gcc.gnu.org/ml/gcc-testresults/2002-02/msg00148.html

Brad

> 
> On Wed, 6 Feb 2002, Brad Lucier wrote:
> > 0x1002aff90 in ggc_set_mark ()
> > (gdb) disassem
> > Dump of assembler code for function ggc_set_mark:
> > 0x1002aff90 <ggc_set_mark>:     save  %sp, -2240, %sp
> 
> That's not a reasonable stack frame.  Well, not for ggc_set_mark anyway.
> 
> Richard, taking the stack bias out of STARTING_FRAME_OFFSET causes
> compute_frame_size to get the wrong answer.
> 
> Perhaps this'd work?  (Untested; I've really got to get my sparc back
> online.)
> 
> 2002-02-06  Jeff Sturm  <jsturm@one-point.com>
> 
> 	* config/sparc/sparc.c (compute_frame_size): Don't correct frame
> 	offset for stack bias.
> 
> Index: sparc.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/config/sparc/sparc.c,v
> retrieving revision 1.181
> diff -u -p -r1.181 sparc.c
> --- sparc.c     2002/02/04 18:16:06     1.181
> +++ sparc.c     2002/02/07 05:29:06
> @@ -3383,9 +3383,8 @@ compute_frame_size (size, leaf_function)
>      }
>    else
>      {
> -      /* We subtract STARTING_FRAME_OFFSET, remember it's negative.
> -         The stack bias (if any) is taken out to undo its effects.  */
> -      apparent_fsize = (size - STARTING_FRAME_OFFSET + SPARC_STACK_BIAS + 
> 7) & -8;
> +      /* We subtract STARTING_FRAME_OFFSET, remember it's negative. */
> +      apparent_fsize = (size - STARTING_FRAME_OFFSET + 7) & -8;
>        apparent_fsize += n_regs * 4;
>        actual_fsize = apparent_fsize + ((outgoing_args_size + 7) & -8);
>      }
>                                                                                
> 

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Jeff Sturm]

On Thu, 7 Feb 2002, Jakub Jelinek wrote:
> > To satisfy my curiosity, does anybody know why v9 has a stack bias?
> 
> Sparc load/store instruction addresses are either reg + reg or reg + 13 bit
> signed immediate. This is +-4KB. In most functions, the region accessed
> above frame pointer is quite small (function arguments) while below it is
> much larger. So, the stack bias makes these areas 2KB above and 6KB below.

I see.  Thanks for the enlightenment.

> Register windows aren't brain damaged as you think, it means that typical
> programs pass all arguments/return values in registers all the time without
> need for their saving.

Yes, that's the theory.  I suppose it depends on the code whether that
savings is offset by the overhead of overflow/underflow trap handlers.  In
particular, deep recursion must be bad on sparc.

And sparc stack frames are large and sloppy, creating a nuisance for
conservative garbage collectors e.g. the Boehm GC used by gcj.

Jeff

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Jakub Jelinek]

On Thu, Feb 07, 2002 at 10:51:30AM -0500, Jeff Sturm wrote:
> On Thu, 7 Feb 2002, Richard Henderson wrote:
> > Looks close.  The stack frame has been irritatingly complex to change.
> 
> I think your soft fp patch will improve things in the long run.  Thanks
> for doing that.
> 
> To satisfy my curiosity, does anybody know why v9 has a stack bias?

Sparc load/store instruction addresses are either reg + reg or reg + 13 bit
signed immediate. This is +-4KB. In most functions, the region accessed
above frame pointer is quite small (function arguments) while below it is
much larger. So, the stack bias makes these areas 2KB above and 6KB below.
And the 1 subtracted from it is so that in mixed 32-bit and 64-bit saving
environment register spill/fill handler can figure out whether it needs to
save 32 or 64 bits from each register.

> realize it's part of the platform ABI, but why?  (Along with register
> windows and other brain damage... gosh I miss my Alpha.)

Register windows aren't brain damaged as you think, it means that typical
programs pass all arguments/return values in registers all the time without
need for their saving.

	Jakub

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Jeff Sturm]

On Thu, 7 Feb 2002, Richard Henderson wrote:
> Looks close.  The stack frame has been irritatingly complex to change.

I think your soft fp patch will improve things in the long run.  Thanks
for doing that.

To satisfy my curiosity, does anybody know why v9 has a stack bias?  I
realize it's part of the platform ABI, but why?  (Along with register
windows and other brain damage... gosh I miss my Alpha.)

Jeff

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Richard Henderson]

On Thu, Feb 07, 2002 at 12:34:38AM -0500, Jeff Sturm wrote:
> Richard, taking the stack bias out of STARTING_FRAME_OFFSET causes
> compute_frame_size to get the wrong answer.
> 
> Perhaps this'd work?  (Untested; I've really got to get my sparc back
> online.)

Looks close.  The stack frame has been irritatingly complex to change.



r~

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Jeff Sturm]

On Wed, 6 Feb 2002, Brad Lucier wrote:
> 0x1002aff90 in ggc_set_mark ()
> (gdb) disassem
> Dump of assembler code for function ggc_set_mark:
> 0x1002aff90 <ggc_set_mark>:     save  %sp, -2240, %sp

That's not a reasonable stack frame.  Well, not for ggc_set_mark anyway.

Richard, taking the stack bias out of STARTING_FRAME_OFFSET causes
compute_frame_size to get the wrong answer.

Perhaps this'd work?  (Untested; I've really got to get my sparc back
online.)

2002-02-06  Jeff Sturm  <jsturm@one-point.com>

	* config/sparc/sparc.c (compute_frame_size): Don't correct frame
	offset for stack bias.

Index: sparc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/sparc/sparc.c,v
retrieving revision 1.181
diff -u -p -r1.181 sparc.c
--- sparc.c     2002/02/04 18:16:06     1.181
+++ sparc.c     2002/02/07 05:29:06
@@ -3383,9 +3383,8 @@ compute_frame_size (size, leaf_function)
     }
   else
     {
-      /* We subtract STARTING_FRAME_OFFSET, remember it's negative.
-         The stack bias (if any) is taken out to undo its effects.  */
-      apparent_fsize = (size - STARTING_FRAME_OFFSET + SPARC_STACK_BIAS + 
7) & -8;
+      /* We subtract STARTING_FRAME_OFFSET, remember it's negative. */
+      apparent_fsize = (size - STARTING_FRAME_OFFSET + 7) & -8;
       apparent_fsize += n_regs * 4;
       actual_fsize = apparent_fsize + ((outgoing_args_size + 7) & -8);
     }
                                                                               

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Brad Lucier]

> With sources as of what date?  I believe I fixed this
> Monday afternoon (2002-02-04).

I'm having a similar problem in cc1, where the stack pointer is bogus upon
entry to a function.  The .i file is quite big, so I was hoping to
find time to come up with a smaller example, but since the problem is in
cc1, perhaps the following example will help to find it.

These are sources from

LAST_UPDATED: Wed Feb  6 08:12:45 UTC 2002

So it's after some of your recent fixes.

The source file is at

http://www.math.purdue.edu/~lucier/GNATS/GNATS-1/_meroon.i.gz

It seems that the frame pointer is bogus, too.

Brad

banach-5% gdb /pkgs/gcc-3.1v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/cc1
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc64-sun-solaris2.8"...
(gdb) run -m64 -fPIC -O1 -fschedule-insns2 -fno-math-errno -fno-strict-aliasing -mcpu=ultrasparc -mtune=ultrasparc -Wall -W -Wno-unused _meroon.i
Starting program: /pkgs/gcc-3.1v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/cc1 -m64 -fPIC -O1 -fschedule-insns2 -fno-math-errno -fno-strict-aliasing -mcpu=ultrasparc -mtune=ultrasparc -Wall -W -Wno-unused _meroon.i
 {GC 5329k -> 1143k} ___H__20___meroon {GC 150229k -> 
Program received signal SIGSEGV, Segmentation fault.
0x1002aff90 in ggc_set_mark ()
(gdb) disassem
Dump of assembler code for function ggc_set_mark:
0x1002aff90 <ggc_set_mark>:     save  %sp, -2240, %sp
0x1002aff94 <ggc_set_mark+4>:   sethi  %hi(0), %o3
0x1002aff98 <ggc_set_mark+8>:   sethi  %hi(0x50b000), %o0
0x1002aff9c <ggc_set_mark+12>:  or  %o3, 1, %o1
0x1002affa0 <ggc_set_mark+16>:  sllx  %o1, 0x20, %o1
0x1002affa4 <ggc_set_mark+20>:  add  %o1, %o0, %o1
0x1002affa8 <ggc_set_mark+24>:  mov  -1, %o0
...
(gdb) info registers
g0             0x0      0
g1             0x0      0
g2             0x0      0
g3             0x0      0
g4             0xffffffff7f248a1c       -2161866212
g5             0x80ffe400       2164253696
g6             0x0      0
g7             0x0      0
o0             0x10a76a480      4470514816
o1             0x10018e10c      4296597772
o2             0x100    256
o3             0x40000  262144
o4             0x10a75a8c0      4470450368
o5             0x0      0
sp             0xffffffff7f7fdbb1       18446744071553670065
o7             0x10018e118      4296597784
l0             0x10675f700      4403361536
l1             0x0      0
l2             0x41     65
l3             0x10a765c88      4470496392
l4             0x0      0
l5             0x0      0
l6             0x0      0
l7             0x0      0
i0             0x10a772240      4470547008
i1             0x3c4c00 3951616
i2             0x178    376
i3             0x200000 2097152
i4             0x10a75a8c0      4470450368
i5             0x0      0
fp             0xffffffff7f7fec70       18446744071553674352
...

Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8

[Richard Kenner]

    With sources as of what date?  I believe I fixed this
    Monday afternoon (2002-02-04).

As another datapoint, the last two nights a GNAT bootstrap on Sparc
failed with a miscompiled stage2/gnat1.  I haven't looked at it yet.