* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
@ 2002-02-06 18:32 Brad Lucier
2002-02-06 21:54 ` Jeff Sturm
0 siblings, 1 reply; 17+ messages in thread
From: Brad Lucier @ 2002-02-06 18:32 UTC (permalink / raw)
To: rth, gcc; +Cc: 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
...
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-06 18:32 Build failure with 3.1 CVS on sparc-sun-solaris2.8 Brad Lucier
@ 2002-02-06 21:54 ` Jeff Sturm
2002-02-07 0:07 ` Richard Henderson
2002-02-07 10:40 ` Brad Lucier
0 siblings, 2 replies; 17+ messages in thread
From: Jeff Sturm @ 2002-02-06 21:54 UTC (permalink / raw)
To: Brad Lucier; +Cc: rth, gcc
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);
}
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-06 21:54 ` Jeff Sturm
@ 2002-02-07 0:07 ` Richard Henderson
2002-02-07 7:55 ` Jeff Sturm
2002-02-07 10:40 ` Brad Lucier
1 sibling, 1 reply; 17+ messages in thread
From: Richard Henderson @ 2002-02-07 0:07 UTC (permalink / raw)
To: Jeff Sturm; +Cc: Brad Lucier, gcc
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~
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-07 0:07 ` Richard Henderson
@ 2002-02-07 7:55 ` Jeff Sturm
2002-02-07 8:17 ` Jakub Jelinek
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Sturm @ 2002-02-07 7:55 UTC (permalink / raw)
To: Richard Henderson; +Cc: Brad Lucier, gcc
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-07 7:55 ` Jeff Sturm
@ 2002-02-07 8:17 ` Jakub Jelinek
2002-02-07 10:03 ` Jeff Sturm
0 siblings, 1 reply; 17+ messages in thread
From: Jakub Jelinek @ 2002-02-07 8:17 UTC (permalink / raw)
To: Jeff Sturm; +Cc: Richard Henderson, Brad Lucier, gcc
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-07 8:17 ` Jakub Jelinek
@ 2002-02-07 10:03 ` Jeff Sturm
0 siblings, 0 replies; 17+ messages in thread
From: Jeff Sturm @ 2002-02-07 10:03 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-06 21:54 ` Jeff Sturm
2002-02-07 0:07 ` Richard Henderson
@ 2002-02-07 10:40 ` Brad Lucier
2002-02-07 10:52 ` Richard Henderson
1 sibling, 1 reply; 17+ messages in thread
From: Brad Lucier @ 2002-02-07 10:40 UTC (permalink / raw)
To: Jeff Sturm; +Cc: Brad Lucier, rth, gcc
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);
> }
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
@ 2002-02-06 17:49 Richard Kenner
0 siblings, 0 replies; 17+ messages in thread
From: Richard Kenner @ 2002-02-06 17:49 UTC (permalink / raw)
To: rth; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Build failure with 3.1 CVS on sparc-sun-solaris2.8
@ 2002-02-06 10:17 Kenneth Lareau
2002-02-06 11:37 ` Jeff Sturm
0 siblings, 1 reply; 17+ messages in thread
From: Kenneth Lareau @ 2002-02-06 10:17 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-06 10:17 Kenneth Lareau
@ 2002-02-06 11:37 ` Jeff Sturm
2002-02-06 17:21 ` Richard Henderson
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Sturm @ 2002-02-06 11:37 UTC (permalink / raw)
To: Kenneth Lareau; +Cc: gcc
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-06 11:37 ` Jeff Sturm
@ 2002-02-06 17:21 ` Richard Henderson
2002-02-06 17:32 ` Kenneth Lareau
0 siblings, 1 reply; 17+ messages in thread
From: Richard Henderson @ 2002-02-06 17:21 UTC (permalink / raw)
To: Jeff Sturm; +Cc: Kenneth Lareau, gcc
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~
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-06 17:21 ` Richard Henderson
@ 2002-02-06 17:32 ` Kenneth Lareau
2002-02-06 17:34 ` Richard Henderson
0 siblings, 1 reply; 17+ messages in thread
From: Kenneth Lareau @ 2002-02-06 17:32 UTC (permalink / raw)
To: Richard Henderson, Jeff Sturm, gcc
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-06 17:32 ` Kenneth Lareau
@ 2002-02-06 17:34 ` Richard Henderson
2002-02-06 18:36 ` Kenneth Lareau
0 siblings, 1 reply; 17+ messages in thread
From: Richard Henderson @ 2002-02-06 17:34 UTC (permalink / raw)
To: Kenneth Lareau; +Cc: Jeff Sturm, gcc
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~
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-06 17:34 ` Richard Henderson
@ 2002-02-06 18:36 ` Kenneth Lareau
2002-02-07 15:25 ` Kenneth Lareau
0 siblings, 1 reply; 17+ messages in thread
From: Kenneth Lareau @ 2002-02-06 18:36 UTC (permalink / raw)
To: Richard Henderson; +Cc: jsturm, gcc
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-06 18:36 ` Kenneth Lareau
@ 2002-02-07 15:25 ` Kenneth Lareau
2002-02-09 0:33 ` Kenneth Lareau
0 siblings, 1 reply; 17+ messages in thread
From: Kenneth Lareau @ 2002-02-07 15:25 UTC (permalink / raw)
To: Kenneth Lareau; +Cc: Richard Henderson, jsturm, gcc
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Build failure with 3.1 CVS on sparc-sun-solaris2.8
2002-02-07 15:25 ` Kenneth Lareau
@ 2002-02-09 0:33 ` Kenneth Lareau
0 siblings, 0 replies; 17+ messages in thread
From: Kenneth Lareau @ 2002-02-09 0:33 UTC (permalink / raw)
To: gcc; +Cc: rth, jsturm
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
>
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2002-02-09 5:23 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-06 18:32 Build failure with 3.1 CVS on sparc-sun-solaris2.8 Brad Lucier
2002-02-06 21:54 ` Jeff Sturm
2002-02-07 0:07 ` Richard Henderson
2002-02-07 7:55 ` Jeff Sturm
2002-02-07 8:17 ` Jakub Jelinek
2002-02-07 10:03 ` Jeff Sturm
2002-02-07 10:40 ` Brad Lucier
2002-02-07 10:52 ` Richard Henderson
-- strict thread matches above, loose matches on Subject: below --
2002-02-06 17:49 Richard Kenner
2002-02-06 10:17 Kenneth Lareau
2002-02-06 11:37 ` Jeff Sturm
2002-02-06 17:21 ` Richard Henderson
2002-02-06 17:32 ` Kenneth Lareau
2002-02-06 17:34 ` Richard Henderson
2002-02-06 18:36 ` Kenneth Lareau
2002-02-07 15:25 ` Kenneth Lareau
2002-02-09 0:33 ` Kenneth Lareau
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).