[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #48 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Alright, I found it, -fstack-protector-strong is the culprit. Will file a new bug report now. Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #45 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Kazumoto Kojima from comment #44) Not likely. The sane gmp/mpfr/mpc libraries are needed, though. Hmm, so the gcc I built is still broken. Many packages compiled with it still segfault right away: root@tirpitz:..procps/bin LD_PRELOAD=/root/procps/lib/sh4-linux-gnu/libprocps.so.4 ./ps Signal 11 (SEGV) caught by ps (procps-ng version 3.3.10). ./ps:display.c:66: please report this bug Segmentation fault root@tirpitz:..procps/bin This is procps taken from: http://incoming.debian-ports.org/buildd/packages/sid/main/libprocps4_3.3.10-2+b2_sh4.deb http://incoming.debian-ports.org/buildd/packages/sid/main/procps_3.3.10-2+b2_sh4.deb Could this still be the same bug, a different bug or does it happen because my gmp/mpfr/mpc might not have been sane while building gcc-4.9_4.9.3-1? This affects many packages that previously built fine. I'm still not sure where to look for the source of this bug. Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #46 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Furthermore, gcc also built a version of grep that is broken and simply refuses to read any options: root@tirpitz:..grep-test2/bin ls egrep fgrep grep root@tirpitz:..grep-test2/bin ./grep Usage: ./grep [OPTION]... PATTERN [FILE]... Try './grep --help' for more information. root@tirpitz:..grep-test2/bin echo hello bla.txt root@tirpitz:..grep-test2/bin grep hello *txt hello root@tirpitz:..grep-test2/bin ./grep hello *txt Usage: ./grep [OPTION]... PATTERN [FILE]... Try './grep --help' for more information. root@tirpitz:..grep-test2/bin ./grep hello *txt j Usage: ./grep [OPTION]... PATTERN [FILE]... Try './grep --help' for more information. root@tirpitz:..grep-test2/bin ./grep hello *txt 1 Usage: ./grep [OPTION]... PATTERN [FILE]... Try './grep --help' for more information. root@tirpitz:..grep-test2/bin ./grep -v hello *txt 1 Usage: ./grep [OPTION]... PATTERN [FILE]... Try './grep --help' for more information. root@tirpitz:..grep-test2/bin ./grep --help Usage: ./grep [OPTION]... PATTERN [FILE]... Try './grep --help' for more information. root@tirpitz:..grep-test2/bin ./grep --help Usage: ./grep [OPTION]... PATTERN [FILE]... Try './grep --help' for more information. root@tirpitz:..grep-test2/bin grep taken from here: http://ftp.de.debian.org/debian-ports//pool-sh4/main/g/grep/grep_2.21-2+b1_sh4.deb Freshly built with gcc-4.9.3 with the patch from this bug report. I don't know whether this related though. Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #47 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Well, now I just compiled both procps and grep with the latest toolchain (gcc-4.9_4.9.3 and binutils_2.25-9) from a pristine tarball with no Debian patches applied and *outside* of the build root and the issues are gone. So there is something installed in the build root of each buildd that results in miscompiled packages. But I have absolutely no idea what is is. Will do more debugging until I can figure out who the culprit is. Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #43 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to John Paul Adrian Glaubitz from comment #42) Cross your fingers ;). Btw, could building the fixed gcc-4.9 with a compiler affected by this particular bug still propagate the problem? Or, asking the other way around: Should the latest package version rather be built with an older, unaffected gcc version? I'm asking because I am worried the current compiler might generate another broken gcc. On the other hand, it's also not that trivial to downgrade the compiler in the build root, albeit it is possible. It just involves lots of manual work. Or is the bootstrap process with its 3 stages enough to mitigate such problems? Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #42 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to John Paul Adrian Glaubitz from comment #41) So, please bear with me until I can give some feedback. Matthias has uploaded the 4.9.3 release now with additional patches from the snapshot r225135 SVN revision. I just started building right now and the build takes around 3 to 4 days. I'll report back once the build is finished and the new gcc version is installed on all buildds. Cross your fingers ;).
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #44 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #43) Btw, could building the fixed gcc-4.9 with a compiler affected by this particular bug still propagate the problem? Or, asking the other way around: Should the latest package version rather be built with an older, unaffected gcc version? Not likely. The sane gmp/mpfr/mpc libraries are needed, though.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #41 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Kazumoto Kojima from comment #40) with my 4.9 native compiler built with 4.9 cross compiler for svn gcc-4_9-branch. I hope that miscompilation for mpfr is gone for bootstrapped 4.9 compiler and it fixes the original gcc issue too. Matthias, Adrian, what about the original error? I cannot test yet as I have to fix the buildds first. This miscompilation issue seems to have affected a couple of packages that found their way into the build roots now and are causing me headaches. I am waiting for Matthias to upload a new gcc-4.9 snapshot in the following days while I will use the time to fix the build roots, then have the buildds build the latest gcc-4.9 package and finally reschedule as many as possible affected packages for rebuild. So, please bear with me until I can give some feedback. Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #40 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #39) Can we close this PR as fixed? I've got Testsuite summary for MPFR 3.1.3 # TOTAL: 160 # PASS: 159 # SKIP: 1 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 with my 4.9 native compiler built with 4.9 cross compiler for svn gcc-4_9-branch. I hope that miscompilation for mpfr is gone for bootstrapped 4.9 compiler and it fixes the original gcc issue too. Matthias, Adrian, what about the original error?
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #39 from Oleg Endo olegendo at gcc dot gnu.org --- Can we close this PR as fixed?
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #38 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Sun Jun 28 07:02:47 2015 New Revision: 225104 URL: https://gcc.gnu.org/viewcvs?rev=225104root=gccview=rev Log: PR target/66563 * [SH] Add a new operand to GOTaddr2picreg so to avoid CSE. Modify caller of gen_GOTaddr2picreg. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sh.c branches/gcc-4_9-branch/gcc/config/sh/sh.md
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #37 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 4.9.3 has been released.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.3 |4.9.4
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #36 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Thu Jun 25 10:15:18 2015 New Revision: 224935 URL: https://gcc.gnu.org/viewcvs?rev=224935root=gccview=rev Log: PR target/66563 * [SH] Add a new operand to GOTaddr2picreg so to avoid CSE. Modify caller of gen_GOTaddr2picreg. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sh/sh.c branches/gcc-5-branch/gcc/config/sh/sh.md
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #34 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Wed Jun 24 22:11:04 2015 New Revision: 224925 URL: https://gcc.gnu.org/viewcvs?rev=224925root=gccview=rev Log: PR target/66563 * [SH] Add a new operand to GOTaddr2picreg so to avoid CSE. Modify caller of gen_GOTaddr2picreg. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #35 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #33) I see, thanks. In this case, could you please add a comment e.g.: ;; Loads of the GOTPC relocation values must not be optimized away ;; by e.g. any kind of CSE and must stay as they are. Although there ;; are other various ways to ensure this, we use an artificial counter ;; operand to generate unique symbols. (define_expand GOTaddr2picreg Good thinking. I've committed the patch with your comment on trunk.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #33 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #32) I see, thanks. In this case, could you please add a comment e.g.: ;; Loads of the GOTPC relocation values must not be optimized away ;; by e.g. any kind of CSE and must stay as they are. Although there ;; are other various ways to ensure this, we use an artificial counter ;; operand to generate unique symbols. (define_expand GOTaddr2picreg
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #31 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #29) Unfortunately, 4.9 and later compilers 'optimize' the above code to the code like Just for my understanding ... In the pattern ... (define_expand GOTaddr2picreg [(set (reg:SI R0_REG) (unspec:SI [(const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))] UNSPEC_MOVA)) (set (match_dup 0) (const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))) (set (match_dup 0) (plus:SI (match_dup 0) (reg:SI R0_REG)))] ... the 2nd (set ...) becomes the mov.l load from the constant pool, which is CSE'ed by some other optimization after the initial RTL expansion. If so, wouldn't it be a bit cleaner to avoid CSE by hiding the constant/symref load from CSE passes by doing something like the following ... (define_expand GOTaddr2picreg [(parallel [(set (reg:SI R0_REG) (unspec:SI [(const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))] UNSPEC_MOVA)) (set (match_dup 0) (const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))) (set (match_dup 0) (plus:SI (match_dup 0) (reg:SI R0_REG)))])] ... everything else stays the same ... (define_insn_and_split *GOTaddr2picreg [(set (reg:SI R0_REG) (unspec:SI [(const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))] UNSPEC_MOVA)) (set (match_dup 0) (const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))) (set (match_dup 0) (plus:SI (match_dup 0) (reg:SI R0_REG)))] # reload_completed [(set (reg:SI R0_REG) (unspec:SI [(const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))] UNSPEC_MOVA)) (set (match_dup 0) (const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))) (set (match_dup 0) (plus:SI (match_dup 0) (reg:SI R0_REG)))]) Alternatively, can't the mov.l constant load insn be marked as volatile so that it doesn't get optimized away for sure?
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #32 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #31) Yes, your insn_and_split is quite same with the one I've tried first and it resolved this case too. The volatile will work of cause. The CSE in problem was done by IRA, not by CSE pass, though. Then I'm curious about how other targets handle the issue and found that some targets like arm differentiate GOT sequences for the different constant pool with the similar counter. I like it because it seems that differentiated RTLs fix the root cause of the issue, even though such CSE won't be done after reload. I've just done the usual tests for trunk and will apply it on trunk. Unfortunately 4.9 is now frozen for 4.9.3 release. I'll backport the patch to 4.9 when it reopens.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #27 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Alright, I have tracked it down now! It's definitely a bug in mpfr4 and *not* gcc. I rebuilt both mpfr4_3.1.2-1 and mpfr4_3.1.2-3 with the latest compiler we have in Debian which is gcc-4.9_4.9.2-21 (r224436). This is the result with the compile test of wmfire with mpfr4_3.1.2-1: glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0) wmfire.c: In function ‘do_help’: wmfire.c:770:62: error: ‘VERSION’ undeclared (first use in this function) fprintf(stderr, \nWmfire - Flaming Monitor Dock V %s\n\n, VERSION); ^ wmfire.c:770:62: note: each undeclared identifier is reported only once for each function it appears in glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ This is the result with mpfr4_3.1.2-3: glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0) wmfire.c: In function ‘draw_fire’: wmfire.c:559:6: internal compiler error: Segmentation fault psi = i * 3.14 / 20.0; ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions. Preprocessed source stored into /tmp/cc4xNN4u.out file, please attach this to your bugreport. glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src Again, *both* compiled fresh with the *same* compiler. Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #28 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Addendum: mpfr4_3.1.3-1 seems to be affected as well but I need to perform more testing. But it's definitely the jump from 3.1.2-1 to 3.1.2-3 that caused the bug!
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #30 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Created attachment 35829 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35829action=edit possible patch for 4.9 The patch adds a counter to unspec vector of (unspec [...] UNSPEC_PIC) pattern to avoid that memoization when these unspecs are used for TLS.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #29 from Kazumoto Kojima kkojima at gcc dot gnu.org --- I've reproduced one problem for mpfr-3.1.3 with the cross compiler. For some TLS variables, we need to set GOT address to the PIC register R12 even in non-PIC objects. Here is a hypothetical example what is going on. Assume that we computed GOT address twice in a function: mova1f,r0 mov.l 1f,r12 add r0,r12 ... 1: .long _GLOBAL_OFFSET_TABLE_ ! GOTPC relocation ... mova2f,r0 mov.l 2f,r12 add r0,r12 ... 2: .long _GLOBAL_OFFSET_TABLE_ ! GOTPC relocation GOTPC relocation means that the value should set to (GOT address - .) by linker. Unfortunately, 4.9 and later compilers 'optimize' the above code to the code like mova1f,r0 mov.l 1f,r12 mov r12,r11 add r0,r12 ... 1: .long _GLOBAL_OFFSET_TABLE_ ! GOTPC relocation ... mova2f,r0 mov.l r11,r12 add r0,r12 ... 2: .long _GLOBAL_OFFSET_TABLE_ ! GOTPC relocation i.e. try to memoize the _GLOBAL_OFFSET_TABLE_ 'value'. This doesn't work because the 2nd computation gets (GOT address - 1f) + 2f instead of the correct GOT address. This issue will affect the non-PIC objects which use TLS aggressively.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #26 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Oleg Endo from comment #25) I don't know the code of mpfr. It could use __builtin_strlen for stuff like parsing numbers etc. However, the builtin_strlen code looks OK and hasn't been causing trouble elsewhere. So I guess that it just runs on broken data and then causes a buffer overrun. In other words, the actual bug is somewhere else -- a quite common scenario for segfault class of bugs. From my current observations it seems that many packages seem to be affected and all were compiled with the new compiler (with the patches since December). I'm currently trying to localize the issue with procps which is also affected. I'm doing a build with gcc-4.9_4.9.2-21 now which is svn r224436. Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #25 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #22) Provided that you're right, how would a bug in strlen this explain that gcc always segfaults when it needs to do float arithmetics? I don't know the code of mpfr. It could use __builtin_strlen for stuff like parsing numbers etc. However, the builtin_strlen code looks OK and hasn't been causing trouble elsewhere. So I guess that it just runs on broken data and then causes a buffer overrun. In other words, the actual bug is somewhere else -- a quite common scenario for segfault class of bugs.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #18 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Kazumoto Kojima from comment #17) Which version of mpfr/gmp is used for compilers? mpfr has self test and you could run it with make check in its build directory. You seem to be on to something here as, in fact, mpfr had problems previously when built with make check [1]: PASS: tcheck PASS: tisnan ../../test-driver: line 107: 5759 Segmentation fault $@ $log_file 21 FAIL: texceptions PASS: tset_exp I have to admit that I recently disabled checks during builds on some buildds to speed up the build process and this may have triggered the whole dilemma. Assuming that mpfr would be the origin of this, would this also explain the segmentation faults in the recently compiled systemd package? Because apparently the systemd binaries crash because gcc has produced broken code here. Could it be possible that the compiler made some float calculation which gave a weird result, embedded that into systemd which in turns segfaults? Adrian [1] http://buildd.debian-ports.org/status/fetch.php?pkg=mpfr4arch=sh4ver=3.1.2-3stamp=1425025691
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #19 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #18) You seem to be on to something here as, in fact, mpfr had problems previously when built with make check [1]: I see many segfaults and bus errors in [1]. Clearly this mpfr is problematic to use in compiler. It might show some other problem of the compiler which was used to build mpfr, though I have no experience for such failures. Anyway your current mpfr looks broken and should be replaced with the sane one. Assuming that mpfr would be the origin of this, would this also explain the segmentation faults in the recently compiled systemd package? Because apparently the systemd binaries crash because gcc has produced broken code here. Could it be possible that the compiler made some float calculation which gave a weird result, embedded that into systemd which in turns segfaults? There is too little information to say something and there are many possibilities, I think.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #21 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #20) I'm curious... Kaz, when bootstrapping the native 4.9 on sh4-linux, did you use the 4.9 native compiler to build mpfr, mpc, gmp libraries? They might indeed be silently miscompiled due to some unknown hidden bug. No, I use always 'system' compiler to build these libraries. In this case, 4.6.3 is my native system compiler.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #16) ... 763a3c: 03 61 mov r0,r1 763a3e: 00 e3 mov #0,r3 763a40: 16 62 mov.l @r1+,r2 763a42: 3c 22 cmp/str r3,r2 763a44: fc 8b bf 763a40 ... That's a code snippet of the builtin strlen which has been added in 4.9... I'm curious... Kaz, when bootstrapping the native 4.9 on sh4-linux, did you use the 4.9 native compiler to build mpfr, mpc, gmp libraries? They might indeed be silently miscompiled due to some unknown hidden bug.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #22 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Oleg Endo from comment #20) (In reply to John Paul Adrian Glaubitz from comment #16) ... 763a3c: 03 61 mov r0,r1 763a3e: 00 e3 mov #0,r3 763a40: 16 62 mov.l @r1+,r2 763a42: 3c 22 cmp/str r3,r2 763a44: fc 8b bf 763a40 ... That's a code snippet of the builtin strlen which has been added in 4.9... That's strange. As Kaz has observed correctly, gcc always seems to segfault when it comes to float arithmetics as I posted in #7. Provided that you're right, how would a bug in strlen this explain that gcc always segfaults when it needs to do float arithmetics? Hmm. I will do some further testing with a downgraded libmpfr.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #23 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- It seems that Kaz was right. Downgrading libmpfr fixes the issue for me: glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0) wmfire.c: In function ‘do_help’: wmfire.c:770:62: error: ‘VERSION’ undeclared (first use in this function) fprintf(stderr, \nWmfire - Flaming Monitor Dock V %s\n\n, VERSION); ^ wmfire.c:770:62: note: each undeclared identifier is reported only once for each function it appears in glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #24 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to John Paul Adrian Glaubitz from comment #23) It seems that Kaz was right. Downgrading libmpfr fixes the issue for me: In order to test whether this problem is actually a result of a miscompilation bug in gcc, I suggest building mpfr from source with a current gcc-4.9 and then run make check and see if the segfaults reproduce on native hardware.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #17 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #16) From the dump and floatformat.c:529:2: internal compiler error: Segmentation fault dto = ldexp (1.0, exponent); wmfire.c:559:6: internal compiler error: Segmentation fault psi = i * 3.14 / 20.0; it looks that the segfaults happen on some computations of floating point numbers in compiler itself. I suspect mpfr libraries of which functions are used in the dump. Which version of mpfr/gmp is used for compilers? mpfr has self test and you could run it with make check in its build directory.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #6 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Kazumoto Kojima from comment #5) (In reply to Matthias Klose from comment #0) Created attachment 35792 [details] preprocessed source seen while building the GCC 5 branch using GCC 4.9 SVN 20150531 (r223898): I can't reproduce the problem with all my 4.9 compilers: cross 4.9 (SVN rev. 224552) compiler native 4.9 (SVN rev. 224552) compiler built with the above cross 4.9 compiler native 4.9 (SVN rev. 222859) compiler built with bootstrap Hmm, can you maybe try to compile wmfire? It's a comparably small package, so it shouldn't take too long to build even natively. Log a failed build can be found here [1]. Adrian [1] http://buildd.debian-ports.org/status/fetch.php?pkg=wmfirearch=sh4ver=1.2.4-1stamp=1434405734
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #12 from Kazumoto Kojima kkojima at gcc dot gnu.org --- All my 4.9 compilers don't fail for given pre-processed source. Could you show us segfaultlog with running the following commands? gcc -E wmfire.c -o wmfire.i strace -i -f -o segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1 wmfire.i
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #10 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 35810 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35810action=edit Pre-processed source for wmfire.c test compile (run without strace)
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #9 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 35809 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35809action=edit Pre-processed source for wmfire.c test compile (run with strace)
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #11 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 35811 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35811action=edit Same compiler invocation, but this time with strace -f
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #7 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Alright, I did some further tests. I downloaded the source package for wmfire with apt-get source wmfire and installed its build dependencies with apt-get build-dep wmfire. Then I just tried to compile wmfire.c: glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0) wmfire.c: In function ‘draw_fire’: wmfire.c:559:6: internal compiler error: Segmentation fault psi = i * 3.14 / 20.0; ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions. Preprocessed source stored into /tmp/ccSeTi7v.out file, please attach this to your bugreport. glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ I did a second run with strace: glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ strace -o gcc-segfault-wmfire gcc wmfire.c -o wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0) wmfire.c: In function ‘draw_fire’: wmfire.c:559:6: internal compiler error: Segmentation fault psi = i * 3.14 / 20.0; ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions. Preprocessed source stored into /tmp/cchKm9Ad.out file, please attach this to your bugreport. glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ Attaching the strace output as well as the preprocessed source. Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #8 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 35808 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35808action=edit strace of gcc segfaulting when compiling wmfire.c on sh4
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #13 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Alright: glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc -E wmfire.c -o wmfire.i $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0) glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ strace -i -f -o segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1 wmfire.i __bswap_32 __bswap_64 g_bit_nth_lsf g_bit_nth_msf g_bit_storage g_mutex_locker_new g_mutex_locker_free g_steal_pointer g_string_append_c_inline g_trash_stack_push g_trash_stack_pop g_trash_stack_peek g_trash_stack_height g_autoptr_cleanup_generic_gfree glib_autoptr_cleanup_GAsyncQueue glib_autoptr_cleanup_GBookmarkFile glib_autoptr_cleanup_GBytes glib_autoptr_cleanup_GChecksum glib_autoptr_cleanup_GDateTime glib_autoptr_cleanup_GDir glib_autoptr_cleanup_GError glib_autoptr_cleanup_GHashTable glib_autoptr_cleanup_GHmac glib_autoptr_cleanup_GIOChannel glib_autoptr_cleanup_GKeyFile glib_autoptr_cleanup_GList glib_autoptr_cleanup_GArray glib_autoptr_cleanup_GPtrArray glib_autoptr_cleanup_GByteArray glib_autoptr_cleanup_GMainContext glib_autoptr_cleanup_GMainLoop glib_autoptr_cleanup_GSource glib_autoptr_cleanup_GMappedFile glib_autoptr_cleanup_GMarkupParseContext glib_autoptr_cleanup_GNode glib_autoptr_cleanup_GOptionContext glib_autoptr_cleanup_GOptionGroup glib_autoptr_cleanup_GPatternSpec glib_autoptr_cleanup_GQueue glib_auto_cleanup_GQueue glib_autoptr_cleanup_GRand glib_autoptr_cleanup_GRegex glib_autoptr_cleanup_GMatchInfo glib_autoptr_cleanup_GScanner glib_autoptr_cleanup_GSequence glib_autoptr_cleanup_GSList glib_autoptr_cleanup_GStringChunk glib_autoptr_cleanup_GThread glib_auto_cleanup_GMutex glib_autoptr_cleanup_GMutexLocker glib_auto_cleanup_GCond glib_autoptr_cleanup_GTimer glib_autoptr_cleanup_GTimeZone glib_autoptr_cleanup_GTree glib_autoptr_cleanup_GVariant glib_autoptr_cleanup_GVariantBuilder glib_auto_cleanup_GVariantBuilder glib_autoptr_cleanup_GVariantIter glib_autoptr_cleanup_GVariantDict glib_auto_cleanup_GVariantDict glib_autoptr_cleanup_GVariantType g_set_object glib_auto_cleanup_GStrv glib_autoptr_cleanup_GObject glib_autoptr_cleanup_GInitiallyUnowned glib_auto_cleanup_GValue glib_autoptr_cleanup_GListModel G_LIST_MODEL G_IS_LIST_MODEL G_LIST_MODEL_GET_IFACE glib_autoptr_cleanup_GListStore G_LIST_STORE G_IS_LIST_STORE glib_autoptr_cleanup_GAction glib_autoptr_cleanup_GActionMap glib_autoptr_cleanup_GAppInfo glib_autoptr_cleanup_GAppLaunchContext glib_autoptr_cleanup_GAppInfoMonitor glib_autoptr_cleanup_GApplicationCommandLine glib_autoptr_cleanup_GApplication glib_autoptr_cleanup_GAsyncInitable glib_autoptr_cleanup_GAsyncResult glib_autoptr_cleanup_GBufferedInputStream glib_autoptr_cleanup_GBufferedOutputStream glib_autoptr_cleanup_GBytesIcon glib_autoptr_cleanup_GCancellable glib_autoptr_cleanup_GCharsetConverter glib_autoptr_cleanup_GConverter glib_autoptr_cleanup_GConverterInputStream glib_autoptr_cleanup_GConverterOutputStream glib_autoptr_cleanup_GCredentials glib_autoptr_cleanup_GDataInputStream glib_autoptr_cleanup_GDataOutputStream glib_autoptr_cleanup_GDBusActionGroup glib_autoptr_cleanup_GDBusAuthObserver glib_autoptr_cleanup_GDBusConnection glib_autoptr_cleanup_GDBusInterface glib_autoptr_cleanup_GDBusInterfaceSkeleton glib_autoptr_cleanup_GDBusMenuModel glib_autoptr_cleanup_GDBusMessage glib_autoptr_cleanup_GDBusMethodInvocation glib_autoptr_cleanup_GDBusNodeInfo glib_autoptr_cleanup_GDBusObject glib_autoptr_cleanup_GDBusObjectManagerClient glib_autoptr_cleanup_GDBusObjectManager glib_autoptr_cleanup_GDBusObjectManagerServer glib_autoptr_cleanup_GDBusObjectProxy glib_autoptr_cleanup_GDBusObjectSkeleton glib_autoptr_cleanup_GDBusProxy glib_autoptr_cleanup_GDBusServer glib_autoptr_cleanup_GDrive glib_autoptr_cleanup_GEmblemedIcon glib_autoptr_cleanup_GEmblem glib_autoptr_cleanup_GFileEnumerator glib_autoptr_cleanup_GFile glib_autoptr_cleanup_GFileIcon glib_autoptr_cleanup_GFileInfo glib_autoptr_cleanup_GFileInputStream glib_autoptr_cleanup_GFileIOStream glib_autoptr_cleanup_GFileMonitor glib_autoptr_cleanup_GFilenameCompleter glib_autoptr_cleanup_GFileOutputStream glib_autoptr_cleanup_GFilterInputStream glib_autoptr_cleanup_GFilterOutputStream glib_autoptr_cleanup_GIcon glib_autoptr_cleanup_GInetAddress glib_autoptr_cleanup_GInetAddressMask glib_autoptr_cleanup_GInetSocketAddress glib_autoptr_cleanup_GInitable glib_autoptr_cleanup_GInputStream glib_autoptr_cleanup_GIOModule glib_autoptr_cleanup_GIOStream glib_autoptr_cleanup_GLoadableIcon glib_autoptr_cleanup_GMemoryInputStream glib_autoptr_cleanup_GMemoryOutputStream glib_autoptr_cleanup_GMenu glib_autoptr_cleanup_GMenuItem glib_autoptr_cleanup_GMenuModel glib_autoptr_cleanup_GMenuAttributeIter glib_autoptr_cleanup_GMenuLinkIter glib_autoptr_cleanup_GMount glib_autoptr_cleanup_GMountOperation glib_autoptr_cleanup_GNativeVolumeMonitor glib_autoptr_cleanup_GNetworkAddress
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Matthias Klose from comment #0) Created attachment 35792 [details] preprocessed source seen while building the GCC 5 branch using GCC 4.9 SVN 20150531 (r223898): I can't reproduce the problem with all my 4.9 compilers: cross 4.9 (SVN rev. 224552) compiler native 4.9 (SVN rev. 224552) compiler built with the above cross 4.9 compiler native 4.9 (SVN rev. 222859) compiler built with bootstrap against the test case in my environment. The last target specific change of 4.9 SVN tree was r221686 | olegendo | 2015-03-26 16:46:51 +0900 (Thu, 26 Mar 2015) | 6 lines So if the test case fails with the vanilla gcc 4.9 rev 223898 built on Debian, the issue isn't caused by the target specific changes or it depends on the environment weirdly. I'll try a new bootstrap on 4.9 SVN rev. 224552 and see it's ok with the test case. It'll take ~2 weeks, though. Perhaps it's better to run your cc1 under gdb or strace and see where/why that segfault happens.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #3 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- So, it seems Matthias is right, there is definitely a regression in gcc-4.9 in the code generation. Packages that were recently build with gcc-4.9_4.9.2-20 or newer tend to segfault. I noticed this with systemd, for example on tirpitz: systemd_220-2 works fine (compiled with gcc-4.9_4.9.2-10): root@tirpitz:~/systemd-test journalctl --version systemd 220 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN root@tirpitz:~/systemd-test systemd_220-6 segfaults (compiled with gcc-4.9_4.9.2-20): root@tirpitz:~/systemd-test ./systemd/bin/journalctl --version systemd 220 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN Segmentation fault root@tirpitz:~/systemd-test Attaching the strace for this segfault if that could be in any way helpful. Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #4 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 35807 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35807action=edit strace of journalctl_220-6-sh4 during segfault
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #15 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #14)
Created attachment 35812 [details]
Log for strace -i -f -o segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1
wmfire.i
30836 [00763a40] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x454} ---
Could you see the code near the address 0x00763a40 in
/usr/lib/gcc/sh4-linux-gnu/4.9/cc1 binary with objdump or gdb?
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #14 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 35812 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35812action=edit Log for strace -i -f -o segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1 wmfire.i
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #16 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- I included some more context: glaubitz@tirpitz:~/debian/segfault-test$ objdump -d /usr/lib/gcc/sh4-linux-gnu/4.9/cc1 |grep -C20 763a40 763a18: 10 38 cmp/eq r1,r8 763a1a: 39 8d bt.s763a90 _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x90 763a1c: 00 e4 mov #0,r4 763a1e: 7d 90 mov.w 763b1c _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x11c,r0 ! a8 763a20: 52 2f mov.l r5,@r15 763a22: 10 e6 mov #16,r6 763a24: 7b 95 mov.w 763b1e _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x11e,r5 ! ff7c 763a26: fc 30 add r15,r0 763a28: 71 1f mov.l r7,@(4,r15) 763a2a: 0c 35 add r0,r5 763a2c: 3e d0 mov.l 763b28 _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x128,r0 ! 4cee84 mpfr_get_str@plt 763a2e: 0b 40 jsr @r0 763a30: 00 e7 mov #0,r7 763a32: 08 20 tst r0,r0 763a34: 6d 8d bt.s763b12 _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x112 763a36: 03 68 mov r0,r8 763a38: 03 c8 tst #3,r0 763a3a: 05 8f bf.s763a48 _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x48 763a3c: 03 61 mov r0,r1 763a3e: 00 e3 mov #0,r3 763a40: 16 62 mov.l @r1+,r2 763a42: 3c 22 cmp/str r3,r2 763a44: fc 8b bf 763a40 _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x40 763a46: fc 71 add #-4,r1 763a48: 14 62 mov.b @r1+,r2 763a4a: 28 22 tst r2,r2 763a4c: fc 8f bf.s763a48 _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x48 763a4e: 83 66 mov r8,r6 763a50: 01 76 add #1,r6 763a52: 68 31 sub r6,r1 763a54: 73 e2 mov #115,r2 763a56: 26 31 cmp/hi r2,r1 763a58: 5b 8d bt.s763b12 _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x112 763a5a: f9 57 mov.l @(36,r15),r7 763a5c: f3 6a mov r15,r10 763a5e: 28 7a add #40,r10 763a60: 08 47 shll2 r7 763a62: 79 1f mov.l r7,@(36,r15) 763a64: 80 60 mov.b @r8,r0 763a66: 2d 88 cmp/eq #45,r0 763a68: 33 8d bt.s763ad2 _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0xd2 763a6a: a3 64 mov r10,r4 763a6c: 2f d0 mov.l 763b2c _Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x12c,r0 ! 4cd3b8 sprintf@plt glaubitz@tirpitz:~/debian/segfault-test$ Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #1 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Hi Matthias! Thanks for the bug report but I think this might actually a problem with the host compiler or its libraries. I have seen segfaults in multiple packages now [1-3] and so I am very sure this is not an issue with gcc but with the gcc-4.9_4.9.2-20+sh4 package that I built. The problem occurred after I built gcc-4.9_4.9.2-20+sh4 manually to re-add libstdc++6 back which was missing yet and I am suspecting that I messed something up while doing that. I have even seen segfaults during packages postinst scripts, for example, so I suspect an issue with the libstdc++6 library being broken. The buildd tirpitz is currently [4] building gcc-4.9_4.9.2-21 which will be your vanilla gcc-4.9 package and I hope that this will fix the issue. Cheers, Adrian [1] http://buildd.debian-ports.org/status/fetch.php?pkg=gnutls28arch=sh4ver=3.3.15-7stamp=1434506763 [2] http://buildd.debian-ports.org/status/fetch.php?pkg=wmfirearch=sh4ver=1.2.4-1stamp=1434405734 [3] http://buildd.debian-ports.org/status/fetch.php?pkg=cdebconfarch=sh4ver=0.194stamp=1434394400 [4] http://buildd.debian-ports.org/status/package.php?p=gcc-4.9suite=sid
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #2 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Just as a heads up: Once the buildd has finished building the latest gcc-4.9_4.9.2-21 package, I will update all buildds and reschedule all affected packages to see if that fixes the problem. If not, we might actually see really a regression here which could certainly be attributed to any of the recent changes listed here [1]. But I really hope it's just this single package built which is broken :). Adrian [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979#c8
