https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
Rainer Orth changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #31 from Gary Mills ---
> When I built gcc-7 with even more configuration options, including
> --enable-initfini-array, I got this segmentation fault on SPARC hardware:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #31 from Gary Mills ---
When I built gcc-7 with even more configuration options, including
--enable-initfini-array, I got this segmentation fault on SPARC hardware:
configure:3662: checking for suffix of object files
configure:3684:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #30 from Gary Mills ---
A build of gcc-7 on SPARC just completed successfully with a much larger
configuration:
$
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure
CC=/usr/gcc/4.9/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #28 from Gary Mills ---
> I installed the patch mentioned above to bypass that error. Now, with this
> minimal configuration:
>
> $
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #28 from Gary Mills ---
I installed the patch mentioned above to bypass that error. Now, with this
minimal configuration:
$
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #26 from Gary Mills ---
> I have no concerns about removal of gcc support for Solaris 10: That is an
I've only mentioned it to make clear that the oldest version of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #26 from Gary Mills ---
I have no concerns about removal of gcc support for Solaris 10: That is an
obsolete operating system, after all. illumos is equivalent to Solaris 11.
gas is used for illumos compilers on x86. It works on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> I may try a build on Solaris 10 with the snv_121 assembler myself.
> The sparc machine is busy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Gary Mills ---
> It's not Solaris, first of all. Solaris is a closed system once again. It's
> illumos, which is derived from Opensolaris. These are the two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #23 from Gary Mills ---
It's not Solaris, first of all. Solaris is a closed system once again. It's
illumos, which is derived from Opensolaris. These are the two assemblers:
This is on SPARC hardware:
$ as -V
as: Sun Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from Gary Mills ---
> Most of the words in the title are wrong now. I'm attempting to build gcc-7
> now. The ICE occurs on both SPARC and x86 systems. It only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #21 from Gary Mills ---
Most of the words in the title are wrong now. I'm attempting to build gcc-7
now. The ICE occurs on both SPARC and x86 systems. It only happens with the
native assembler. The result is a structure that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #20 from Gary Mills ---
For a test, I defined the symbol DEBUG_ET in gcc-7.3.0/gcc/et-forest.c .
During
the build, I got this ICE and a backtrace:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #19 from Gary Mills ---
The reason that OI-SPARC uses the native assembler is the same as in Fiddler
on the Roof: tradition. Actually, there are some kernel files written in SPARC
assembly language. These only compile with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Eric Botcazou ---
>> Anybody should be able to reproduce this problem. My guess is a logic error.
>
> I'm not sure whether we still support the native assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
Eric Botcazou changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #16 from Gary Mills ---
I have a clue now. I built gcc-7 on OI-SPARC with the GNU assembler. The
build
was successful. xgcc worked, without the ICE. Clearly the ICE only happens
when gcc-7 is configured with the native assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #15 from Eric Botcazou ---
> Regarding your suggestion, is there a way to get the compiler to reveal the
> steps it goes through in compiling the program? All I get now is the
> backtrace when it hits the error. I need to know what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #14 from Gary Mills ---
Regarding your suggestion, is there a way to get the compiler to reveal the
steps it goes through in compiling the program? All I get now is the backtrace
when it hits the error. I need to know what the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #13 from Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #12 from Gary Mills ---
Just in case it was the C++ compiler that was mis-compiling the intermediate
gcc
compiler, I did a build with both CFLAGS and CXXFLAGS set to '-g -O0'. Again,
I
got the same ICE. With that, I suppose we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #11 from Gary Mills ---
Well, I got the same ICE when the compiler was built with -O0. It always seems
to happen during the configure tests, always this one:
configure:3662: checking for suffix of object files
configure:3684:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #10 from Gary Mills ---
Thanks for the explanation. It's entirely possible that the intermediate gcc
was miss-compiled because of excessive optimization.
I tried building gcc-7.3.0 with -O1 for 32-bit SPARC only, and got the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #9 from Gary Mills ---
Okay, I'm compiling it with -O0 right now. It might take a couple of days.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #8 from Eric Botcazou ---
> That's the immediate cause of the ICE. I haven't identified the root cause
> yet. I'm wondering, though, why the compiler built and ran on x86 hardware,
> but failed on SPARC hardware. One difference is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #7 from Gary Mills ---
I'm still waiting for information on how to use gdb to check the alignment of
the structures involved in this ICE.
I had to RTFM and experiment. Here's the result:
$ /usr/bin/sparcv7/gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #6 from Gary Mills ---
I'm still waiting for information on how to use gdb to check the alignment of
the structures involved in this ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #5 from Eric Botcazou ---
> I don't see anything in the various FLAGS that might cause this ICE.
CFLAGS='-g -O2' LDFLAGS=-m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #4 from Gary Mills ---
sparcv7 is a file path component. It implies that this is a 32-bit executable
running on a 64-bit kernel. That's normal behavior on OI and Solaris builds.
Generally there are both 32 and 64-bit builds. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #2 from Gary Mills ---
I just built and installed gdb. I've never used it, though. I'll need
complete
instructions on how to determine if it's an alignment error.
That is a very good suggestion, something I never even considered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
Richard Biener changed:
What|Removed |Added
Target||sparc
Status|UNCONFIRMED
33 matches
Mail list logo
