[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/
-B/usr/gcc/7/sparc-sun-solaris2.11/bin/
-B/usr/gcc/7/sparc-sun-solaris2.11/lib/ -isystem
/usr/gcc/7/sparc-sun-solaris2.11/include -isystem
/usr/gcc/7/sparc-sun-solaris2.11/sys-include -c -g -O2 -mno-app-regs
conftest.c >&5
conftest.c: In function 'main':
conftest.c:11:1: internal compiler error: Segmentation Fault
 main ()
 ^~~~

conftest.c:11:1: internal compiler error: Abort
xgcc: internal compiler error: Abort (program cc1)

This is a known problem, and an old one.  The --enable-initfini-array option is
not shown in the help output from gcc-7 configure.  When I did a subsequent
build without that option, I got a successful build.  It's quite possible that
this option was the source of all the problems.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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 CXX=/usr/gcc/4.9/bin/g++
F77=/usr/gcc/4.9/bin/gfortran FC=/usr/gcc/4.9/bin/gfortran CFLAGS=-O2
-mno-app-regs LDFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig
--prefix=/usr/gcc/7 --mandir=/usr/gcc/7/share/man
--bindir=/usr/gcc/7/bin --sbindir=/usr/gcc/7/bin
--libdir=/usr/gcc/7/lib --libexecdir=/usr/gcc/7/lib
--with-pkgversion=OpenIndiana 7.3.0-OI-0
--with-bugurl=https://bugs.openindiana.org --enable-languages=c,c++
--without-gnu-ld --with-ld=/usr/bin/ld --without-gnu-as
--with-as=/usr/bin/as LDFLAGS=-R/usr/gcc/7/lib

There still was no ICE.  I'm going to try an even larger configuration next in
an attempt to identify which configuration setting causes the ICE.  I'm
suspicious of these three:

CONFIGURE_OPTIONS+= --host $(GNU_ARCH)
CONFIGURE_OPTIONS+= --build $(GNU_ARCH)
CONFIGURE_OPTIONS+= --target $(GNU_ARCH)

which are part of the OI Makefile.  Note the missing equal signs (=).  I only
noticed these a few days ago.  I'll include these at the very end of my
testing.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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-ld --with-ld=/usr/bin/ld --without-gnu-as --with-as=/usr/bin/as

I got a successful build.  Still, we are not quite at the root cause.  This
result does suggest that something in the previous configuration caused the
ICE.  Note that /usr/local, the default prefix, does not exist.  Also,
/usr/gcc/7, the desired prefix, does not exist.  I'm going to try to
re-introduce some of the previous configuration to identify what causes the
ICE.  This will take some time, as each build takes about three days.  Any
suggestions about the culprit in the previous configuration will be
appreciated.

I do see this error in all six copies of libgcc/config.log:

configure:3471:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/
-B/usr/local/sparc-sun-solaris2.11/bin/ -B/usr/local/sparc-sun-solaris2.11/lib/
-isystem /usr/local/sparc-sun-solaris2.11/include -isystem
/usr/local/sparc-sun-solaris2.11/sys-include-o conftest -g -O2   conftest.c
 >&5
ld: fatal: file crtp.o: open failed: No such file or directory
ld: fatal: file crtbegin.o: open failed: No such file or directory
ld: fatal: file crtend.o: open failed: No such file or directory
ld: fatal: file processing errors. No output written to conftest
collect2: error: ld returned 1 exit status
configure:3474: $? = 1
configure:3662: checking for suffix of object files

It happens because the configure script ran before the crt*.o files had been
created.  Here's an example of the timestamps:

-rw-r--r--   1 millsstaff504 Jan  7 05:43 build/sparcv7/gcc/crtp.o
-rw-r--r--   1 millsstaff  60825 Jan  7 05:38
build/sparcv7/sparc-sun-solaris2.11/libgcc/config.log

As far as I can tell, a failure of the linker at this point tells the script
that we are cross-compiling, and bypasses any subsequent tests that require the
linker.  I don't know what effect these assumptions might have.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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 SPARC too, and avoids
the ICE.  Unfortunately, gcc with gas can't be used to compile the SPARC
kernel.  That's because some SPARC kernel files are written in assembler
language.  These won't compile with gas, only with the native assembler.  It
would be difficult, but not impossible, to use gcc with gas on SPARC hardware.

I've just attempted to build gcc-7.3.0 on SPARC with an even more restricted
configuration:

  $
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure
--without-gnu-ld --with-ld=/usr/bin/ld --without-gnu-as --with-as=/usr/bin/as

The compilers are not specified on the command line but they are in the
environment.  The compilers were identified correctly.

The build got considerably farther, but ended with this error:

libtool: compile: 
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc
-shared-libgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc
-nostdinc++
-L/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src
-L/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs
-L/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs
-B/usr/local/sparc-sun-solaris2.11/bin/ -B/usr/local/sparc-sun-solaris2.11/lib/
-isystem /usr/local/sparc-sun-solaris2.11/include -isystem
/usr/local/sparc-sun-solaris2.11/sys-include
-I/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/libstdc++-v3/../libgcc
-I/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include/sparc-sun-solaris2.11
-I/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include
-I/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=new_opa.lo -g -O2 -std=gnu++1z -c
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/libstdc++-v3/libsupc++/new_opa.cc
 -fPIC -DPIC -D_GLIBCXX_SHARED -o new_opa.o
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/libstdc++-v3/libsupc++/new_opa.cc:
In function 'void* operator new(std::size_t, std::align_val_t)':
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/libstdc++-v3/libsupc++/new_opa.cc:103:33:
error: 'aligned_alloc' was not declared in this scope
   while (__builtin_expect ((p = aligned_alloc (align, sz)) == 0, false))
 ^
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/libstdc++-v3/libsupc++/new_opa.cc:103:33:
note: suggested alternative:
In file included from /usr/include/stdlib.h:39:0,
 from
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include/cstdlib:75,
 from
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include/stdlib.h:36,
 from
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/libstdc++-v3/libsupc++/new_opa.cc:27:
/usr/include/iso/stdlib_c11.h:60:14: note:   'std::aligned_alloc'
 extern void *aligned_alloc(size_t, size_t);
  ^
Makefile:936: recipe for target 'new_opa.lo' failed
make[6]: *** [new_opa.lo] Error 1
make[6]: Leaving directory
'/dpool/export/home/mills/Downloads/code/oi-userland-apr/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++'

There is a patch which seems to fix this error:

--- gcc-7.1.0.orig/libstdc++-v3/libsupc++/new_opa.cc2017-01-26
15:30:45.0 +0100
+++ gcc-7.1.0/libstdc++-v3/libsupc++/new_opa.cc 2017-05-04 17:16:25.920300456
+0200
@@ -31,7 +31,6 @@
 using std::new_handler;
 using std::bad_alloc;

-#if !_GLIBCXX_HAVE_ALIGNED_ALLOC
 #if _GLIBCXX_HAVE__ALIGNED_MALLOC
 #define aligned_alloc(al,sz) _aligned_malloc(sz,al)
 #elif _GLIBCXX_HAVE_POSIX_MEMALIGN
@@ -82,7 +81,6 @@
   return aligned_ptr;
 }
 #endif
-#endif

 _GLIBCXX_WEAK_DEFINITION void *
 operator new (std::size_t sz, std::align_val_t al)

I can't be certain that this patch does not have unwanted side 

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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 Common 12 SunOS_sparc snv_121 08/03/2009
$ uname -a
SunOS t2000 5.11 master-0-g5093b3b sun4v sparc SUNW,Sun-Fire-T200

This is on x86 hardware:
$ as -V  
as: Sun Compiler Common 12 SunOS_i386 snv_121 08/03/2009
Usage: as [-V] [-Q{y,n}] [-s]
  [-S[aAbBcClL]] [-K {pic,PIC}] [-o objfile] [-L] [-T]
  [-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
  [-m [-Ym,path]] [-n] [-xF] [-F] [-b] [-i] file.s ...
$ uname -a
SunOS tyan 5.11 illumos-8dfe5547fb i86pc i386 i86pc

They seem to be the same.  illumos does not have source for the assembler, only
the binaries.  They can't be changed.  illumos does have source for the
linkers.

Yes, /usr/gcc/4.9/bin/gcc and /usr/gcc/4.9/bin/g++ are the 32-bit-default
compilers.  They will produce 64-bit binaries with the -m64 option.  They are
actually 4.9.4.  I built the compilers myself, using gcc-4.4.4.

I just tried a build of gcc-7 (gcc-7.3.0) with a minimal configuration.  This
is what appears in the oldest config.log:

  $
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure
CC=/usr/gcc/4.9/bin/gcc CXX=/usr/gcc/4.9/bin/g++ F77=/usr/gcc/4.9/bin/gfortran
FC=/usr/gcc/4.9/bin/gfortran CFLAGS= -O3 -mno-app-regs CXXFLAGS=  FFLAGS= 
FCFLAGS= LDFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig --prefix=/usr/gcc/7
--mandir=/usr/gcc/7/share/man --bindir=/usr/gcc/7/bin --libdir=/usr/gcc/7/lib
--sbindir=/usr/gcc/7/sbin --sbindir=/usr/gcc/7/bin --libdir=/usr/gcc/7/lib
--libexecdir=/usr/gcc/7/lib --host sparc-sun-solaris2.11 --build
sparc-sun-solaris2.11 --target sparc-sun-solaris2.11 --without-gnu-ld
--with-ld=/usr/bin/ld --without-gnu-as --with-as=/usr/bin/as
LDFLAGS=-R/usr/gcc/7/lib

I also removed all of the patches except for one that modifies
libgcc/config.host to create crtbeginS.o and crtendS.o.  The build stopped
quite early with this error:

/usr/gcc/4.9/bin/g++ -std=gnu++98   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++
-static-libgcc -R/usr/gcc/7/lib  -o build/genmddeps \
build/genmddeps.o build/read-md.o build/errors.o
../build-sparc-sun-solaris2.11/libiberty/libiberty.a
build/genmddeps
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/common.md
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/config/sparc/sparc.md
> tmp-mddeps
/bin/bash: line 1: 28485 Bus Error   (core dumped) build/genmddeps
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/common.md
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/config/sparc/sparc.md
> tmp-mddeps
Makefile:2240: recipe for target 's-mddeps' failed
make[4]: *** [s-mddeps] Error 138
make[4]: Leaving directory
'/dpool/export/home/mills/Downloads/code/oi-userland-apr/components/developer/gcc-7/build/sparcv7/gcc'

This is what gdb said about the core file:

(gdb) bt
#0  0x0001f7bc in __gnu_cxx::__mutex::__mutex (
this=0x5007c <(anonymous namespace)::emergency_mutex>)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc49/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include/ext/concurrence.h:132
#1  __static_initialization_and_destruction_0 (__priority=65535, 
__initialize_p=1)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc49/gcc-4.9.4/libstdc++-v3/libsupc++/eh_alloc.cc:96
#2  _GLOBAL__sub_I_eh_alloc.cc(void) ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc49/gcc-4.9.4/libstdc++-v3/libsupc++/eh_alloc.cc:211
#3  0x0002f19c in __do_global_ctors_aux ()
#4  0x0002f1d4 in _init ()
#5  0x000165f0 in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit

The build didn't dump core at this point before.  Something in the
configuration must have changed its behavior.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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 contains many NULL pointers,
which cause a segmentation violation when xgcc dereferences one of the NULL
pointers.

I've been attempting to find the origin of this structure by examining the
source, without success.  Can someone show me a debugging technique that will
reveal the origin of this structure?

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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/sparcv7/./gcc/xgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/
-nostdinc -x c /dev/null -S -o /dev/null
-fself-test=/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/testsuite/selftests
cc1: internal compiler error: Bus Error

The bus error occurs here, in gcc-7.3.0/gcc/et-forest.c:218:

203 static int
204 record_path_before_1 (struct et_occ *occ, int depth)
205 {
206   int mn, m;
207  
208   depth += occ->depth;
209   mn = depth;
210  
211   if (occ->prev)
212 {
213   m = record_path_before_1 (occ->prev, depth);
214   if (m < mn)
215 mn = m;
216 }
217  
---
218   fprintf (stderr, "%d (%d); ", ((basic_block) occ->of->data)->index,
depth);
---
219  

It's likely dereferencing a NULL pointer.

When I later tested xgcc with my trivial source file, I got this output:

$ build/sparcv7/gcc/xgcc -B build/sparcv7/./gcc/ -S
/tmp/conftest.c
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
4 (0); 
0 (0); 2 (1); 4 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 

The compile was successful.  The output file, conftest.s, had the correct
assembly language.  The debugging output from the compile showed each chain of
blocks within the tree structure.  The first number is the index.  The second,
in brackets, is the depth.  There seems to be some unwanted chains in that
list.
These are always one block long and begin with a non-zero index.  I don't know
the origin of these chains, but they likely cause the ICE when compiling a
regular file.  How do I determine their origin?

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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 native assembler.  Hence, gcc
is
built to use the native assembler.

On OI-x86, the native assembler is not necessary and therefore not used.

It's entirely possible that the assembler is an old version.  OI does not have
source for the assembler, only the binary that came from Opensolaris.  The one
I use on my T2000 has this version string:

as: Sun Compiler Common 12 SunOS_sparc snv_121 08/03/2009

I'm in the midst of tracking down the origin of that null pointer that causes
the ICE.  With gdb, breakpoints seem not to work, but I can use it to analyze
core files.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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.  This is the usual
configuration on SPARC hardware.

Then I built gcc-7 on OI-x86 with the native assembler.  This is the opposite
of
the normal configuration.  It failed with the ICE.  xgcc by itself gets the
same
ICE.

My conclusion is that the ICE only occurs when gcc-7 is configured with the
native
assembler.  It doesn't matter if the hardware is SPARC or x86.  The fatal
configuration is with:

--without-gnu-as --with-as=/usr/bin/as

Something happens in that case that passes a null pointer to functions that
dereference it and cause the ICE.

Note that the assembler is not actually invoked.  My test uses the -S option
that causes the assembly output to be placed in a file.  xgcc still fails if
the
native assembler is configured.

Anybody should be able to reproduce this problem.  My guess is a logic error.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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 compiler is doing before that.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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 rule out a mis-compilation of
the
intermediate compiler.  The ICE seems to be real!

The curious thing is that gcc/xgcc seems to work correctly for building all of
the gcc-7 source.  It's only during the configuration tests that the ICE
appears.
At that time, it's compiling trivial source files.

I'm wondering if the cause could be faulty code that only misbehaves with a
trivial source file.  How do I investigate further?

The other curious thing is that gcc-7 builds correctly on x86 hardware.  The
ICE
only appears on SPARC hardware.  How do I investigate further?

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/
-B/usr/gcc/7/sparc-sun-solaris2.11/bin/ -B/usr/gcc/7/sparc-sun-solaris2.11/lib/
-isystem /usr/gcc/7/sparc-sun-solaris2.11/include -isystem
/usr/gcc/7/sparc-sun-solaris2.11/sys-include-c -O2 -g -O0  conftest.c >&5
conftest.c: In function 'main':
conftest.c:11:1: internal compiler error: Segmentation Fault

Here's some information on the intermediate compiler:

$ build/sparcv7/./gcc/xgcc -v   
Using built-in specs.
COLLECT_GCC=build/sparcv7/./gcc/xgcc
Target: sparc-sun-solaris2.11
Configured with:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure
CC=/usr/gcc/4.9/bin/gcc CXX=/usr/gcc/4.9/bin/g++ F77=/usr/gcc/4.9/bin/gfortran
FC=/usr/gcc/4.9/bin/gfortran CFLAGS='-g -O0' CXXFLAGS=' ' FFLAGS=' ' FCFLAGS=
LDFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig --prefix=/usr/gcc/7
--mandir=/usr/gcc/7/share/man --bindir=/usr/gcc/7/bin --libdir=/usr/gcc/7/lib
--sbindir=/usr/gcc/7/sbin --sbindir=/usr/gcc/7/bin --libdir=/usr/gcc/7/lib
--libexecdir=/usr/gcc/7/lib --host sparc-sun-solaris2.11 --build
sparc-sun-solaris2.11 --target sparc-sun-solaris2.11
--with-pkgversion='OpenIndiana 7.3.0-OI-0'
--with-bugurl=https://bugs.openindiana.org --enable-plugins --enable-objc-gc
--enable-initfini-array --enable-languages=c,c++,fortran,lto,objc
--without-gnu-ld --with-ld=/usr/bin/ld
--with-build-time-tools=/usr/gnu/sparc-sun-solaris2.11/bin --disable-libitm
--without-gnu-as --with-as=/usr/bin/as LDFLAGS=-R/usr/gcc/7/lib
Thread model: posix
gcc version 7.3.0 (OpenIndiana 7.3.0-OI-0)

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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
ICE.  Here's part of build/sparcv7/sparc-sun-solaris2.11/libgcc/config.log:

configure:3662: checking for suffix of object files
configure:3684:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/
-B/usr/gcc/7/sparc-sun-solaris2.11/bin/ -B/usr/gcc/7/sparc-sun-solaris2.11/lib/
-isystem /usr/gcc/7/sparc-sun-solaris2.11/include -isystem
/usr/gcc/7/sparc-sun-solaris2.11/sys-include-c -O2 -g -O1  conftest.c >&5
conftest.c: In function 'main':
conftest.c:11:1: internal compiler error: Segmentation Fault
 main ()
 ^~~~
0x68930f crash_signal
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/toplev.c:337
0x399380 et_splay
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/et-forest.c:312
0x39a06b et_set_father
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/et-forest.c:526
0x32f4b7 calculate_dominance_info(cdi_direction)
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/dominance.c:739
0x6cb28b cleanup_tree_cfg_noloop
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/tree-cfgcleanup.c:766
0x6cb28b cleanup_tree_cfg()
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/tree-cfgcleanup.c:883
0x6c58af execute_build_cfg
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/tree-cfg.c:404
0x6c58af execute
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/tree-cfg.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
configure:3688: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/;
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3702: error: in
`/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/libgcc':
configure:3705: error: cannot compute suffix of object files: cannot compile

I had hoped that a reduction from -O2 to -O1 would be sufficient, but it must
not have been.  The curious thing was that two copies of xgcc were created
during the build:

$ find build -name xgcc -ls 
23236147 5382 -rwxr-xr-x   1 millsstaff 5436884 Nov 11 21:10
build/sparcv7/gcc/xgcc
23217408 4870 -rwxr-xr-x   1 millsstaff 4929308 Nov 10 15:19
build/sparcv7/prev-gcc/xgcc

I'll try the build again with -O0 to see what happens then.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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/cc1 core
...
(gdb) bt
...
#9  
#10 et_splay (occ=occ@entry=0x0)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:311
#11 0x00361834 in et_set_father (t=0xeaf810, father=0xeaf808)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:525
#12 0x00301e6c in calculate_dominance_info (dir=dir@entry=CDI_DOMINATORS)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/dominance.c:658
#13 0x006701cc in cleanup_tree_cfg_noloop ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:759
#14 cleanup_tree_cfg ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:818
#15 0x0066ab88 in execute_build_cfg ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:360
#16 (anonymous namespace)::pass_build_cfg::execute (this=)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:389
#17 0x0056a7e0 in execute_one_pass (pass=pass@entry=0xe30408)
---Type  to continue, or q  to quit---
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/passes.c:2336
#18 0x0056ad80 in execute_pass_list_1 (pass=0xe30408, pass@entry=0xe2e938)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/passes.c:2420
#19 0x0056ae1c in execute_pass_list (fn=0xfb410068, pass=0xe2e938)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/passes.c:2431
#20 0x002c8e18 in cgraph_node::analyze (this=this@entry=0xfb4a6000)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/cgraphunit.c:636
#21 0x002cc2b0 in analyze_functions (first_time=first_time@entry=true)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/cgraphunit.c:1086
#22 0x002cc9d0 in symbol_table::finalize_compilation_unit (this=0xfb41)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/cgraphunit.c:2554
#23 0x006321e4 in compile_file ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:488
#24 0x00633f28 in do_compile ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:2014
---Type  to continue, or q  to quit---
#25 toplev::main (this=this@entry=0xffbff91e, argc=, 
argc@entry=19, argv=, argv@entry=0xffbff984)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:2123
#26 0x00adcc28 in main (argc=19, argv=0xffbff984)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/main.c:39
(gdb) q

So, it wasn't an alignment error after all.  It was the most common thing that
causes a bus error: dereferencing a null pointer.  The backtrace shows that
et_splay() was called with a NULL operand, occ.  That NULL pointer was
dereferenced by this line:

311   while (occ->parent)

In et_set_father(), the et_splay() function was called with the operand rmost,
which must also be NULL.

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 that the configuration on
SPARC hardware uses the native assembler.  On x86 hardware, it uses the GNU
assembler.  That's the only configuration difference.  The hardware is
different, of course.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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-bit executables reside
in
a sparcv9 directory.

I don't see anything in the various FLAGS that might cause this ICE.

I still need full instructions on how to use gdb to determine if the ICE is
caused by an alignment error.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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.

[Bug c/87836] New: ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836

Bug ID: 87836
   Summary: ICE in cc1 for gcc-6.5.0 with SPARC hardware
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  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-OI-4) 6.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ -6/build/sparcv7/./gcc/xgcc -v<
Using built-in specs.
COLLECT_GCC=/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/build/sparcv7/./gcc/xgcc
Target: sparc-sun-solaris2.11
Configured with:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/configure
CC=/usr/gcc/4.9/bin/gcc CXX=/usr/gcc/4.9/bin/g++ F77=/usr/gcc/4.9/bin/gfortran
FC=/usr/gcc/4.9/bin/gfortran CFLAGS='-g -O2' CXXFLAGS=' ' FFLAGS=' ' FCFLAGS=
LDFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig --prefix=/usr/gcc/6
--mandir=/usr/gcc/6/share/man --bindir=/usr/gcc/6/bin --libdir=/usr/gcc/6/lib
--sbindir=/usr/gcc/6/sbin --sbindir=/usr/gcc/6/bin --libdir=/usr/gcc/6/lib
--libexecdir=/usr/gcc/6/lib --host sparc-sun-solaris2.11 --build
sparc-sun-solaris2.11 --target sparc-sun-solaris2.11
--with-pkgversion='OpenIndiana 6.5.0-OI-4'
--with-bugurl=https://bugs.openindiana.org --enable-plugins --enable-objc-gc
--enable-initfini-array --enable-languages=c,c++,fortran,lto,objc
--without-gnu-ld --with-ld=/usr/bin/ld
--with-build-time-tools=/usr/gnu/sparc-sun-solaris2.11/bin --disable-libitm
--without-gnu-as --with-as=/usr/bin/as LDFLAGS=-R/usr/gcc/6/lib
Thread model: posix
gcc version 6.5.0 (OpenIndiana 6.5.0-OI-4) 

Here's the error I get:
$
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/build/sparcv7/./gcc/xgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/build/sparcv7/./gcc/
-S conftest.c
conftest.c: In function 'main':
conftest.c:2:1: internal compiler error: Segmentation Fault
 main ()
 ^~~~
0x631deb crash_signal
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:333
0x360b3c et_splay
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:311
0x361833 et_set_father
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:525
0x301e6b calculate_dominance_info(cdi_direction)
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/dominance.c:658
0x6701cb cleanup_tree_cfg_noloop
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:759
0x6701cb cleanup_tree_cfg()
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:818
0x66ab87 execute_build_cfg
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:360
0x66ab87 execute
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:389
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.openindiana.org> for instructions.

Here's the source file:
$ cat conftest.c
int
main ()
{

  ;
  return 0;
}

This happens on a Sun T2000 running v9os (oi_151a9).  The kernel is illumos.
I get the same error and backtrace with gcc-6.4.0 and gcc-7.3.0 .  It worked
with gcc-4.9.4 .  The error appears with the configuration for phase 2 and
also when xgcc is run separately as in this test.  It does build correctly on
x86 hardware.

Note that all of these gcc versions have some patches applied.  These patches
adapt gcc for building the illumos kernel.

I'm willing to test potential fixes on my hardware and OS or to gather
additional debugging information.