[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #43 from Andrew Pinski  ---
.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[pinskia at gcc dot gnu.org]

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

--- Comment #42 from Andrew Pinski  ---
Closing astatement invalid then.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #41 from Joshua Kinard  ---
(In reply to Andrew Pinski from comment #38)
> Does this work now?

Whatever the issue on MIPS/N32 was, it's resolved by dropping -Wl,-z,now.  So
no longer an issue AFAICT.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #40 from Eric Botcazou  ---
> I believe the --disable-checking issue on ppc is still there.  Wonder if
> somebody can try on ppc-linux ... (or other archs, I believe just nobody
> uses --disable-checking)

Bootstrap with --disable-checking on 32-bit PowerPC/Linux is OK on mainline.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenth at gcc dot gnu.org]

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

--- Comment #39 from Richard Biener  ---
I believe the --disable-checking issue on ppc is still there.  Wonder if
somebody can try on ppc-linux ... (or other archs, I believe just nobody uses
--disable-checking)

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[pinskia at gcc dot gnu.org]

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

--- Comment #38 from Andrew Pinski  ---
Does this work now?

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|5.4 |5.5

--- Comment #37 from Richard Biener  ---
GCC 5.4 is being released, adjusting target milestone.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #36 from Joshua Kinard  ---
(In reply to Joshua Kinard from comment #35)
> 
> It looks like it's my LDFLAGS, specifically with -Wl,-z,now.

It looks like this might be a problem with my toolchain, possibly in binutils,
and possibly only for MIPS N32.  I discovered another program that was having
odd issues, and on a whim, re-compiled it without using -Wl,-z,now, and it
started to work correctly again.  Going to downgrade binutils a few times and
see if there's a specific version that stands out as causing the problem.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #35 from Joshua Kinard  ---
(In reply to rguent...@suse.de from comment #34)
> On Thu, 14 Jan 2016, kumba at gentoo dot org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
> > 
> > --- Comment #33 from Joshua Kinard  ---
> > The problem may be tied to a particular CFLAG on glibc-n32 MIPS.  I ran our
> > (Gentoo's) stage-building script, and forgot to block gcc-5.3.0 from 
> > building,
> > and it ended up completing.  Difference between that script (which builds
> > inside a chroot) is I used saner CFLAGS.
> > 
> > The CFLAGS I am using in my rootfs that fails to build gcc-5.3.0 is:
> > CFLAGS="-O2 -pipe -march=r12k -mtune=r12k -mno-fix-r1 -mabi=n32 -mplt
> > -fomit-frame-pointer -fforce-addr -fivopts -fmodulo-sched -ftree-vectorize"
> > LDFLAGS="-Wl,-O2 -Wl,-z,now -Wl,-z,relro"
> > 
> > So I'll look at dropping one flag at a time, along with trimming LDFLAGS, 
> > and
> > see if I can pin down which one causes ./genmatch --gimple to segfault 
> on N32.
> 
> -fforce-addr is a no-op and -fivopts is enabled at -O2 by default, so
> you can omit those without testing.

It looks like it's my LDFLAGS, specifically with -Wl,-z,now.  I let the build
proceed after removing LDFLAGS from my environment, and once it built genmatch
and ran it w/o a SIGSEGV, I interrupted the build, copied the linking command
for genmatch, and then tested with both -Wl,-z,now and -Wl,-z,relro, and the
relro version runs fine.

# mips64-unknown-linux-gnu-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
-DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,-z,now -o
build/genmatchZ3 build/genmatch.o
../build-mips64-unknown-linux-gnu/libcpp/libcpp.a build/errors.o build/vec.o
build/hash-table.o ../build-mips64-unknown-linux-gnu/libiberty/libiberty.a

# build/genmatchZ3 --gimple
Segmentation fault


# mips64-unknown-linux-gnu-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
-DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,-z,relro
-o build/genmatchZ4 build/genmatch.o
../build-mips64-unknown-linux-gnu/libcpp/libcpp.a build/errors.o build/vec.o
build/hash-table.o ../build-mips64-unknown-linux-gnu/libiberty/libiberty.a

# build/genmatchZ4 --gimple
(null):0:0 error: --gimple: No such file or directory


Currently using binutils-2.25.1.  Can provide strace runs if needed.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenther at suse dot de]

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

--- Comment #34 from rguenther at suse dot de  ---
On Thu, 14 Jan 2016, kumba at gentoo dot org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
> 
> --- Comment #33 from Joshua Kinard  ---
> The problem may be tied to a particular CFLAG on glibc-n32 MIPS.  I ran our
> (Gentoo's) stage-building script, and forgot to block gcc-5.3.0 from building,
> and it ended up completing.  Difference between that script (which builds
> inside a chroot) is I used saner CFLAGS.
> 
> The CFLAGS I am using in my rootfs that fails to build gcc-5.3.0 is:
> CFLAGS="-O2 -pipe -march=r12k -mtune=r12k -mno-fix-r1 -mabi=n32 -mplt
> -fomit-frame-pointer -fforce-addr -fivopts -fmodulo-sched -ftree-vectorize"
> LDFLAGS="-Wl,-O2 -Wl,-z,now -Wl,-z,relro"
> 
> So I'll look at dropping one flag at a time, along with trimming LDFLAGS, and
> see if I can pin down which one causes ./genmatch --gimple to segfault 
on N32.

-fforce-addr is a no-op and -fivopts is enabled at -O2 by default, so
you can omit those without testing.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #33 from Joshua Kinard  ---
The problem may be tied to a particular CFLAG on glibc-n32 MIPS.  I ran our
(Gentoo's) stage-building script, and forgot to block gcc-5.3.0 from building,
and it ended up completing.  Difference between that script (which builds
inside a chroot) is I used saner CFLAGS.

The CFLAGS I am using in my rootfs that fails to build gcc-5.3.0 is:
CFLAGS="-O2 -pipe -march=r12k -mtune=r12k -mno-fix-r1 -mabi=n32 -mplt
-fomit-frame-pointer -fforce-addr -fivopts -fmodulo-sched -ftree-vectorize"
LDFLAGS="-Wl,-O2 -Wl,-z,now -Wl,-z,relro"

So I'll look at dropping one flag at a time, along with trimming LDFLAGS, and
see if I can pin down which one causes ./genmatch --gimple to segfault on N32.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #32 from Joshua Kinard  ---
(In reply to Richard Biener from comment #30)
> Any status update?  Does bootstrap work on trunk (with --disable-checking)?

Okay, here's updates from the MIPS angle on a few configurations:

MIPS-IV, Big-endian, N32, glibc (mips64-unknown-linux-gnu):
Still fails with either --disable-checking or --enable-checking=release.  Same
problem as before:

build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/match.pd \
> tmp-gimple-match.c
/bin/bash: line 1: 16563 Segmentation fault  build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/match.pd >
tmp-gimple-match.c
Makefile:2325: recipe for target 's-match' failed
make[3]: *** [s-match] Error 139
make[3]: *** Waiting for unfinished jobs

Can't test O32/glibc at present due to accidentally mangling my old O32 rootfs.
 Might get something up and working again at some point, but I *highly* suspect
the problem only exists in N32 (unknown about N64).  See below for why.

---

MIPS-IV, Big-endian, O32, uclibc (mips-unknown-linux-uclibc):
--disable-checking appears to produce an ICE in an O32/uclibc rootfs.  I assume
you'll want a fresh bug opened on this:
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/../libcpp/include  \
-o build/genoutput.o
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/genoutput.c
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/genautomata.c: In
function 'void form_regexp(regexp_t)':
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/genautomata.c:6867:1:
internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2318
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:2451: recipe for target 'build/genautomata.o' failed
make[3]: *** [build/genautomata.o] Error 1
make[3]: *** Waiting for unfinished jobs

I'll have to re-create the above scenario to do so, as I'm running a few
different experiments w/ uclibc at the moment, so I need to make sure it really
is --disable-checking causing the problem there and I'll run the bug through
our (Gentoo's) toolchain team first before opening a PR here.

---

Now, same O32/uclibc rootfs, --enable-checking=release, gcc-5.3.0 works fine
(so far).  This is why I suspect the N32 case is broken only.  I don't know how
good N32 support in uclibc is, so I can't test that configuration to verify.

So to tackle the N32 issue, are there any additional tricks you want me to try
to get, say, a static copy of genmatch built w/ debugging symbols and then step
through it in GDB to see what may be triggering the segfault?  I didn't try
removing the 'gcc_checking_assert', as suggested in earlier comments.

N32 does affect the reported size of several datatypes, so that may be the
source of the issue on MIPS.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|5.3 |5.4

--- Comment #31 from Richard Biener  ---
GCC 5.3 is being released, adjusting target milestone.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Status|NEW |WAITING

--- Comment #30 from Richard Biener  ---
Any status update?  Does bootstrap work on trunk (with --disable-checking)?

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[dougmencken at gmail dot com]

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

--- Comment #29 from Douglas Mencken  ---
Vanilla GCC 5.2 bootstraps perfectly (without --disable-checking) on my side

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #27 from Joshua Kinard kumba at gentoo dot org ---
(In reply to Richard Biener from comment #26)
 Don't hold your breath.  Basically somebody who can reproduce it has to find
 the root-cause and a fix.

4.9.3 works, and the problem appears specific to genmatch with the '--gimple'
argument.  I guess I can test to see if 5.0.0 is also affected, and then start
diffing the genmatch.c files between working/non-working version to trace the
problem down.  That will be quicker than git bisecting on these machines (old
SGI machines).  Can't stay stuck on 4.9.x forever...

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Target|powerpc-darwin  |powerpc-darwin,
   ||mips64-linux-n32
 Status|WAITING |NEW

--- Comment #26 from Richard Biener rguenth at gcc dot gnu.org ---
Don't hold your breath.  Basically somebody who can reproduce it has to find
the root-cause and a fix.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenther at suse dot de]

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

--- Comment #28 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 25 Aug 2015, kumba at gentoo dot org wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
 
 --- Comment #27 from Joshua Kinard kumba at gentoo dot org ---
 (In reply to Richard Biener from comment #26)
  Don't hold your breath.  Basically somebody who can reproduce it has to find
  the root-cause and a fix.
 
 4.9.3 works, and the problem appears specific to genmatch with the '--gimple'
 argument.  I guess I can test to see if 5.0.0 is also affected, and then start
 diffing the genmatch.c files between working/non-working version to trace the
 problem down.  That will be quicker than git bisecting on these machines (old
 SGI machines).  Can't stay stuck on 4.9.x forever...

Can you also nail the issue down to using --disable-checking?  For the
powerpc case I think we run into a miscompile of stage2 and thus
genmatch.c is really only the trigger and wouldn't be the place for
a fix (well, maybe a workaround is fine for the GCC 5 branch here)

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #25 from Joshua Kinard kumba at gentoo dot org ---
Still present in gcc-5.2.  Reverting commit r218976 also didn't help. 
Reproduced on a second MIPS machine running N32 ABI as well.  any idea if this
is being looked at for 5.3?

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|5.2 |5.3

--- Comment #24 from Richard Biener rguenth at gcc dot gnu.org ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

Joshua Kinard kumba at gentoo dot org changed:

   What|Removed |Added

 CC||kumba at gentoo dot org

--- Comment #23 from Joshua Kinard kumba at gentoo dot org ---
I ran into this on a Linux/mips64 (MIPS-IV ISA) build as well, running N32 ABI.

mips64-unknown-linux-gnu-g++ -c  -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  
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc
-I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/build
-I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/../include 
-I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/../libcpp/include  \
-o build/gcov-iov.o
/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/gcov-iov.c
build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/match.pd \
 tmp-gimple-match.c
/bin/bash: line 1:   835 Segmentation fault  build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/match.pd 
tmp-gimple-match.c
Makefile:2318: recipe for target 's-match' failed
make[3]: *** [s-match] Error 139
make[3]: *** Waiting for unfinished jobs

This is in the 'all-stage1-gcc' stage from 'stage1-bubble'.  I did not see any
'ld' warnings prior to that, but I have this in dmesg:

[47163.043326]
   do_page_fault(): sending SIGSEGV to genmatch for invalid read
access from 
[47163.043354] epc =  in
[47163.043402]  genmatch[1000+9]
[47163.043412] ra  = 1000b960 in
[47163.043436]  genmatch[1000+9]

Running a 64KB PAGE_SIZE, too, if that matters.  I'll try to reverse commit
r218976 from Comment #11 to see if that resolves the issue for me as well and
update later.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[dougmencken at gmail dot com]

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

--- Comment #22 from Douglas Mencken dougmencken at gmail dot com ---
Created attachment 35619
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35619action=edit
pre-processed source of genmatch

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Douglas Mencken from comment #20)
 I'm lost. “Vanilla” 5.1.0 configured without --disable-checking went thru
 stage2 w/o any issue...

That's interesting - we might run into a miscompilation here.  Can you
check with --disable-checking again but with just the gcc_checking_assert
in hash_table_mod1 removed?

Please also attach preprocessed source of genmatch.c for the stage2 build
so it's possible to investigate that with a cross compiler.  (preprocessed
source with --disable-checking and the assert left in place)

Btw, thanks for your help in tracking this down.

I wonder if anybody tried a powerpc-linux bootstrap with --disable-checking...