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 CX
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
--without-gnu
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 SP
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 Comm
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 conta
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:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv
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 nativ
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 #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 compi
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 r
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:
/expor
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
IC
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 #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 build/sparcv7/./gcc/c
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 #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 64
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.
Assignee: unassigned at gcc dot gnu.org
Reporter: gary_mills at fastmail dot fm
Target Milestone: ---
Here's information on the compiler:
$
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/build/sparcv7/./gcc/xgcc
--version
xgcc (OpenIndiana 6.5.0
19 matches
Mail list logo
