[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855 John Paul Adrian Glaubitz changed: What|Removed |Added Version|9.2.1 |10.0 --- Comment #10 from John Paul Adrian Glaubitz --- Okay, this is interesting. I just tried again to reproduce the problem and it does not reproduce with GCC-8 and GCC-9 anymore but it does reproduce with GCC-10. Changing the affected version to 10.0, accordingly.
[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855 --- Comment #11 from John Paul Adrian Glaubitz --- I can no longer reproduce the problem with the snapshot as of 2020-03-04 (94f7d7ec6eb). So it looks like the problem was fixed between (20200222, e99b18cf710) and (20200304, 94f7d7ec6eb).
[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855 John Paul Adrian Glaubitz changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #12 from John Paul Adrian Glaubitz --- Closing this as "works for me" now. I will continue to observe the issue though.
[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #8 from John Paul Adrian Glaubitz --- (In reply to Martin Liška from comment #0) > I can't reproduce that with a cross compiler and I noticed that one needs to > bootstrap compiler. --disable-bootstrap seems fine. I don't have a handy > machine where I could reproduce that right now.. There are POWER machines available in the GCC compile farm. If these aren't helpful, I can create an account for you on one of the machines we use for Debian.
[Bug target/94059] New: [10 Regression] Bootstrap fails configuring libiberty with 'cannot compute sizeof (long long)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059
Bug ID: 94059
Summary: [10 Regression] Bootstrap fails configuring libiberty
with 'cannot compute sizeof (long long)'
Product: gcc
Version: 10.0
URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-10&;
arch=m68k&ver=10-20200304-1&stamp=1583407512&raw=0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, schwab at gcc dot gnu.org
Target Milestone: ---
Target: m68k-*-*
Since (20200304, 94f7d7ec6eb), a bootstrap build on m68k fails with:
checking size of long long... ok
checking for dlfcn.h... yes
checking for objdir... .libs
configure: error: in `/<>/build/libiberty':
configure: error: cannot compute sizeof (long long)
See `config.log' for more details
checking if /<>/build/./prev-gcc/xgcc
-B/<>/build/./prev-gcc/ -B/usr/m68k-linux-gnu/bin/
-B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem
/usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -isystem
/<>/build/sys-include -fchecking=1 supports -fno-rtti
-fno-exceptions... make[4]: *** [Makefile:11035: configure-stage3-libiberty]
Error 77
make[4]: *** Waiting for unfinished jobs
no
(20200222, e99b18cf710) still built fine.
Full log in
https://buildd.debian.org/status/fetch.php?pkg=gcc-10&arch=m68k&ver=10-20200304-1&stamp=1583407512&raw=0
[Bug target/94059] [10 Regression] m68k: Bootstrap fails configuring libiberty with 'cannot compute sizeof (long long)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059 --- Comment #3 from John Paul Adrian Glaubitz --- (In reply to Jeffrey A. Law from comment #2) > Also note I bootstrap m68k regularly, last build was: > > 8e6d0dba166324f4b257329bd4b4ddc2b4522359 > > Without more relevant data, there's nothing we can do here. I'm testing now whether this might have been caused by r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9 as well.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #36 from John Paul Adrian Glaubitz --- The m68k bootstrap also recently got broken (PR/94059). Currently testing whether this is also a result of this change (r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9).
[Bug target/94059] [10 Regression] m68k: Bootstrap fails configuring libiberty with 'cannot compute sizeof (long long)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059 John Paul Adrian Glaubitz changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #3 from John Paul Adrian Glaubitz --- A second build attempt on the buildds was successful and so were two manual builds, so it seems this was just an artifact. Log of successful build: https://buildd.debian.org/status/fetch.php?pkg=gcc-10&arch=m68k&ver=10-20200304-1&stamp=1583616557&raw=0
[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE and PIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 --- Comment #7 from John Paul Adrian Glaubitz --- (In reply to Alan Modra from comment #6) > Since it is very unlikely that a bugzilla entry for gcc or binutils will > prompt anyone to write the necessary linker support or change gcc, I'm > closing this as won't fix. Isn't that what "severity: wishlist" is for? You just explained that there is a limitation in binutils on POWER and we have seen at least one case where this limitation causes problems, so I think it's fair to keep this bug report open in case someone else runs into this particular problem and decides to fix the bug. I don't think it's safe to assume that no one is going to fix this bug unless you have a crystal ball.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #3 from John Paul Adrian Glaubitz --- (In reply to Max from comment #2) > Is there anyone more familiar with GCC internals and/or the AVR backend who > I would be able to consult or possibly work with on this? I think Jeff Law mentioned on the gcc-patches mailing list that he would be willing to answer questions and assist anyone willing to work on MODE_CC conversion. So, I would ask on the list: https://gcc.gnu.org/mailman/listinfo/gcc-patches
[Bug target/95294] New: [vax] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294 Bug ID: 95294 Summary: [vax] Convert the backend to MODE_CC so it can be kept in future releases Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: martin at netbsd dot org Target Milestone: --- Target: vax-*-* This is a tracker bug for the convert the vax backend from CC0 to MODE_CC so it can be kept in future releases as there has been interest raised on the NetBSD/VAX mailing list: See: http://mail-index.netbsd.org/port-vax/2020/04/16/msg003460.html For the background of the CC0 transition, see: > https://gcc.gnu.org/wiki/CC0Transition I will be using this bug report to create a bounty on BountySource.com. We have already successfully funded such a conversion for the m68k backend, see #91851. Another campaign is ongoing for the avr backend, see #92729. To test the backend, the emulator SimH can be used to install the VAX port of NetBSD. For that matter, a test image has been provided by John Klos: > http://mail-index.netbsd.org/port-vax/2020/04/18/msg003481.html There is also a generic howto which explains how to set up and install NetBSD/VAX inside SimH: > http://www.netbsd.org/ports/vax/emulator-howto.html SimH is available for immediate installation in openSUSE, Ubuntu, Debian and Fedora. Alternatively, SimH can be obtained from the upstream project: > https://github.com/simh > http://simh.trailing-edge.com/
[Bug target/95381] New: [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 Bug ID: 95381 Summary: [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867 Product: gcc Version: 11.0 URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-sna pshot&arch=m68k&ver=1%3A20200525-1&stamp=1590584234&ra w=0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: bernds at gcc dot gnu.org, schwab at gcc dot gnu.org Target Milestone: --- Bootstrapping gcc-11 on m68k fails with: ln -sf libgccjit.so.0 libgccjit.so echo | /<>/build-jit/./gcc/xgcc -B/<>/build-jit/./gcc/ -E -dM - | \ sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \ -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ sort -u > tmp-macro_list /bin/bash ../../src/gcc/../move-if-change tmp-macro_list macro_list echo timestamp > s-macro_list /<>/build-jit/./gcc/xgcc -B/<>/build-jit/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests cc1: internal compiler error: in operator[], at vec.h:867 mmap: Bad file descriptor close: Bad file descriptor Please submit a full bug report, with preprocessed source if appropriate. See for instructions. /<>/build-jit/./gcc/xgcc -B/<>/build-jit/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests make[4]: *** [../../src/gcc/c/Make-lang.in:124: s-selftest-c] Error 1 make[4]: *** Waiting for unfinished jobs cc1plus: internal compiler error: in operator[], at vec.h:867 mmap: Bad file descriptor close: Bad file descriptor Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[4]: *** [../../src/gcc/cp/Make-lang.in:178: s-selftest-c++] Error 1
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 --- Comment #2 from John Paul Adrian Glaubitz --- (In reply to Richard Biener from comment #1) > can we have a backtrace? Working on it.
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 --- Comment #3 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #2) > (In reply to Richard Biener from comment #1) > > can we have a backtrace? > > Working on it. I'm at the point now where I can invoke the command which provokes the crash: (sid-m68k-sbuild)root@epyc:/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/gcc# /build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/./gcc/xgcc -B/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests cc1plus: internal compiler error: in operator[], at vec.h:867 mmap: Bad file descriptor close: Bad file descriptor Please submit a full bug report, with preprocessed source if appropriate. See for instructions. (sid-m68k-sbuild)root@epyc:/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/gcc# What kind of backtrace are you looking for? Through GDB?
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 --- Comment #5 from John Paul Adrian Glaubitz --- Here's what I get on qemu-m68k-system (instead of qemu-user): root@pacman:/srv/gcc-debug/build-jit/gcc# ./xgcc -B ./ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests cc1plus: internal compiler error: in operator[], at vec.h:867 0x801e40f3 vec::operator[](unsigned int) ../../src/gcc/vec.h:867 0x80e11f13 vec::operator[](unsigned int) ../../src/gcc/tree.h:3296 0x80e11f13 vec::operator[](unsigned int) ../../src/gcc/vec.h:1433 0x80e11f13 test_vector_cst_patterns ../../src/gcc/tree.c:15340 0x80e11f13 selftest::tree_c_tests() ../../src/gcc/tree.c:15853 0x812fd8fb selftest::run_tests() ../../src/gcc/selftest-run-tests.c:86 0x80ae443b toplev::run_self_tests() ../../src/gcc/toplev.c:2340 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. root@pacman:/srv/gcc-debug/build-jit/gcc#
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #7 from John Paul Adrian Glaubitz --- > I'd be really grateful for advice on how to test and improve this. Is there a > test suite somewhere that I've missed? Ideally, one that works with a free > simulator? Probably best to ask on the gcc-patches mailing list or one of the AVR forums (avrfreaks maybe).
[Bug target/96899] New: [10.2 Regression] [SH] Bootstrap fails when building libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899 Bug ID: 96899 Summary: [10.2 Regression] [SH] Bootstrap fails when building libgomp Product: gcc Version: 10.2.0 URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-10&; arch=sh4&ver=10.2.0-6&stamp=1598935952&raw=0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: jrtc27 at jrtc27 dot com, kkojima at rr dot iij4u.or.jp, oleg.e...@t-online.de Target Milestone: --- Target: sh*-*-* With gcc-10.2, the bootstrap has started to fail on Debian/sh4, please see: > https://buildd.debian.org/status/fetch.php?pkg=gcc-10&arch=sh4&ver=10.2.0-6&stamp=1598935952&raw=0 It's failing when building libgomp, not sure exactly what the problem is. I have not yet bisected which commit broke the build. Might do that later. I cannot copy and paste the partial build log because that triggers the spam filter and locks my bugzilla account :(.
[Bug target/96899] [10 Regression] [SH] Bootstrap fails when building libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899 --- Comment #2 from John Paul Adrian Glaubitz --- (In reply to Richard Biener from comment #1) > Did it work with GCC 10.1? Yes. I'm currently performing some test builds and will hopefully start bisecting soon.
[Bug target/96899] [10 Regression] [SH] Bootstrap fails when building libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899 --- Comment #3 from John Paul Adrian Glaubitz --- I managed to successfully perform a local build natively with an updated version of QEMU. I have updated QEMU on the build servers as well and rescheduled the gcc-10 package. Let's see if it builds fine now, then we can hopefully close this as invalid.
[Bug target/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851 --- Comment #2 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #1) > > https://wiki.debian.org/M68k/QemuSystemM68k > > The guide is not complete yet, I will finish it throughout next week. The code has been completed now after a regression in the serial emulation in qemu-system-m68k was fixed. Following through the guide now yields a fully usable Debian/m68k system running on an emulated Macintosh Quadra 800. > The bounty on BountySource.com can be found at: > > > https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases The bounty is now at $5000 with 43 backers.
[Bug target/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851 --- Comment #3 from John Paul Adrian Glaubitz --- Forgot to mention: The task is considered completed when the necessary changes have been merged upstream so that m68k will be part of GCC-11 and newer releases.
[Bug target/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851 --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to Tobias Burnus from comment #4) > Bernd posted the CC0-to-MODE_CC patches for review, cf: > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01028.html [0/4] > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01029.html [1/4] > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01030.html [2/4] > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01031.html [3/4] > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01032.html [4/4] Woohoo, awesome. I'm really impressed how fast that was. > Side remark: once MODE_CC is used, at some point the register allocator > should also be changed from 'reload' to LRA, cf. > https://gcc.gnu.org/wiki/LRAIsDefault ; for now, only CC0 was suggested to > be deprecated in GCC 10 and scheduled for removal in GCC 11, cf. > https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html – still, getting > rid of reload is also a goal. If Bernd could make that switch as well, that would be awesome but since it was not in the original Bounty I'm not sure it would be fair to ask for that to be done as well.
[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426 --- Comment #10 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #9) > Unfortunately, there's no simple fix for it that I know of. You can try to > use the new register allocator with the option -mlra on a selective basis, > because it's got its own set of issues on SH. Isn't switching to LRA by default going to happen in the near future anyway? We might as well do that and I'll report every issue we're seeing in Debian. There are definitely cases where I remember switching to LRA helped.
[Bug target/92729] New: [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 Bug ID: 92729 Summary: [avr] Convert the backend to MODE_CC so it can be kept in future releases Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target Milestone: --- Target: avr-*-* This is a tracker bug for the convert the avr backend from CC0 to MODE_CC so it can be kept in future releases. See: https://gcc.gnu.org/wiki/CC0Transition I will be using this bug report to create a bounty on BountySource.com. We have already successfully funded such a conversion for the m68k backend, see #91851.
[Bug target/92767] New: [m68k]: Random ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92767 Bug ID: 92767 Summary: [m68k]: Random ICE: verify_flow_info failed Product: gcc Version: 10.0 URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-sna pshot&arch=m68k&ver=1%3A20191130-1&stamp=1575330554&ra w=0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: bernds at gcc dot gnu.org, schwab at gcc dot gnu.org Target Milestone: --- Target: m68k-*-* Trying a full bootstrap with gm2 enabled on m68k, the build fails with an internal compiler error: GCC_FOR_TARGET /<>/build/./gcc/xgcc -B/<>/build/./gcc/ bash ../../src/gcc/m2/tools-src/makeSystem -fpim \ ../../src/gcc/m2/gm2-libs/SYSTEM.def \ ../../src/gcc/m2/gm2-libs/SYSTEM.mod \ -I../../src/gcc/m2/gm2-libs \ "/<>/build/./gcc/xgm2 -B/<>/build/./gcc/" /<>/build/gcc/m2/gm2-libs/SYSTEM.def ../../src/gcc/m2/gm2-libs/SYSTEM.mod: In function 'ShiftVal': ../../src/gcc/m2/gm2-libs/SYSTEM.mod:89:1: error: verify_flow_info: Wrong count of block 23 89 | END ShiftVal ; | ^~~ ../../src/gcc/m2/gm2-libs/SYSTEM.mod:89:1: error: verify_flow_info: Wrong count of block 22 during RTL pass: outof_cfglayout ../../src/gcc/m2/gm2-libs/SYSTEM.mod:89:1: internal compiler error: verify_flow_info failed mmap: Permission denied Please submit a full bug report, with preprocessed source if appropriate. See for instructions. But even with gm2 disabled, the issue shows at other places: ../../../src/libgomp/target.c: In function 'gomp_map_vars': ../../../src/libgomp/target.c:1052:1: error: verify_flow_info: Wrong count of block 110 1052 | } | ^ ../../../src/libgomp/target.c:1052:1: error: verify_flow_info: Wrong count of block 42 during RTL pass: expand ../../../src/libgomp/target.c:1052:1: internal compiler error: verify_flow_info failed mmap: Permission denied Please submit a full bug report, with preprocessed source if appropriate. See for instructions. From: https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=m68k&ver=1%3A20190719-1&stamp=1563578948&raw=0 It seems the issue was introduced between r271016 and r271670 when comparing the Debian builds at: > https://buildd.debian.org/status/logs.php?pkg=gcc-snapshot&arch=m68k Last successful build with snapshot version (20190508, r271016) and first unsuccessful build with snapshot version (20190527, r271670). The issue is older than the MODE_CC conversion recently performed on the m68k backend. I will perform some more testing to find out whether this issue might be Debian-specific.
[Bug target/92767] [m68k]: Random ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92767 --- Comment #2 from John Paul Adrian Glaubitz --- A local native bootstrap went through without problems, so maybe it's a problem with the Debian buildds. I'll try to track it down and if I can reproduce it locally, I will provide the preprocessed source, of course.
[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282 --- Comment #3 from John Paul Adrian Glaubitz --- This problem is still present in r278870: ../../src/gcc/ubsan.c: In function 'tree_node* ubsan_type_descriptor(tree, ubsan_print_style)': ../../src/gcc/ubsan.c:409:33: warning: unterminated quote character ''' in format [-Wformat-diag] 409 | pp_printf (&pretty_name, "'%s%s%s%s%s%s%s", | ^ ../../src/gcc/ubsan.c:428:36: warning: spurious trailing space in format [-Wformat-diag] 428 | pp_printf (&pretty_name, "'%s ", tname); |^ ../../src/gcc/ubsan.c:428:33: warning: unterminated quote character ''' in format [-Wformat-diag] 428 | pp_printf (&pretty_name, "'%s ", tname); | ^ /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/lib/gcc-snapshot/ia64-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu -I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o sancov.o -MT sancov.o -MMD -MP -MF ./.deps/sancov.TPo ../../src/gcc/sancov.c /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/lib/gcc-snapshot/ia64-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu -I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o tree-call-cdce.o -MT tree-call-cdce.o -MMD -MP -MF ./.deps/tree-call-cdce.TPo ../../src/gcc/tree-call-cdce.c /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/lib/gcc-snapshot/ia64-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu -I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o tree-cfg.o -MT tree-cfg.o -MMD -MP -MF ./.deps/tree-cfg.TPo ../../src/gcc/tree-cfg.c ../../src/gcc/tree-call-cdce.c: In function 'void gen_shrink_wrap_conditions(gcall*, vec, unsigned int*)': ../../src/gcc/tree-call-cdce.c:793:1: error: qsort comparator non-negative on sorted output: 1 793 | } | ^ during RTL pass: mach ../../src/gcc/tree-call-cdce.c:793:1: internal compiler error: qsort checking failed 0x444ce41f qsort_chk_error ../../src/gcc/vec.c:214 0x444cf3bf qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*, void*), void*) ../../src/gcc/vec.c:256 0x4458daaf gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) ../../src/gcc/sort.cc:270 0x440b72ff ready_sort_real ../
[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282 --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to Andreas Schwab from comment #4) > Workaround: use release checking. Stupid question: How do I do that? Is there a switch that can be passed to the configure script?
[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282 --- Comment #7 from John Paul Adrian Glaubitz --- (In reply to Martin Liška from comment #6) > (In reply to John Paul Adrian Glaubitz from comment #5) > > (In reply to Andreas Schwab from comment #4) > > > Workaround: use release checking. > > > > Stupid question: How do I do that? Is there a switch that can be passed to > > the configure script? > > -fno-checking, or -fchecking=0. I will take a look at the bug today. Okay. Thanks. Let me know if you need access to an Itanium box. To my shame, I haven't managed to set up a GCC porterbox for ia64 yet which has been on my TODO list for quite a while. Hopefully early next year.
[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282 --- Comment #10 from John Paul Adrian Glaubitz --- (In reply to Martin Liška from comment #9) > @John: Can you please attach a pre-processed source file (-E option). I > should be able to reproduce that then with a cross compiler. Is the output after "=== BEGIN GCC DUMP ===" in the logfile what you need? > https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=ia64&ver=1%3A20191130-1&stamp=1575698799&raw=0 Otherwise, I'll generate the pre-processed source as requested.
[Bug target/83464] [SH] ICE: in final_scan_insn, at final.c:3025 with -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83464 --- Comment #4 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #3) > Is this still an issue with current trunk? > Can you please check? I have to try. I'll run a testbuild. Currently the package has the following workaround for PR/81426: # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426 ifneq (,$(filter $(DEB_HOST_ARCH_CPU),sh3 sh4)) export DEB_CXXFLAGS_MAINT_STRIP += -O2 export DEB_CXXFLAGS_MAINT_APPEND += -O1 endif See: https://salsa.debian.org/qt-kde-team/qt/qt5webkit/blob/master/debian/rules#L20 Maybe LRA works these days.
[Bug target/83464] [SH] ICE: in final_scan_insn, at final.c:3025 with -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83464 --- Comment #6 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #5) > I'm not sure this is an acceptable solution. It disables various other > optimizations and reduces in worse code than normally should be. When you > rebuild all of debian with LRA enabled, please make sure to take out any > such hacks. It's not a solution, it was a work-around. FWIW, I have tried to build the package with the gcc-10 package from Debian (which is a recent snapshot) and -mlra, but so far cmake doesn't want to accept gcc-10 as the build compiler when set with export CC/CXX, so I have to poke around what the problem is. I will report back once I have a result.
[Bug target/92946] New: [9 Regression] [SH] Native GCC crashes when invoking with -m4 -m4-nofpu -pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92946 Bug ID: 92946 Summary: [9 Regression] [SH] Native GCC crashes when invoking with -m4 -m4-nofpu -pipe Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de, jrtc27 at jrtc27 dot com, oleg.e...@t-online.de Target Milestone: --- Target: sh*-*-* In Debian, kernel builds have been failing for a while now on sh4 due to gcc-9 crashing when run natively on sh4: root@tirpitz:~> gcc-9 -m4 -m4-nofpu -pipe -c -x c /dev/null malloc(): corrupted top size Aborted root@tirpitz:~> See https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=5.3.15-1&stamp=1575738446&raw=0 for a log file. The issue does not reproduce on earlier GCC versions: root@tirpitz:~> gcc-5 -m4 -m4-nofpu -pipe -c -x c /dev/null root@tirpitz:~> gcc-6 -m4 -m4-nofpu -pipe -c -x c /dev/null root@tirpitz:~> gcc-7 -m4 -m4-nofpu -pipe -c -x c /dev/null root@tirpitz:~> gcc-8 -m4 -m4-nofpu -pipe -c -x c /dev/null root@tirpitz:~>
[Bug target/92946] [9 Regression] [SH] Native GCC crashes when invoking with -m4 -m4-nofpu -pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92946 --- Comment #1 from John Paul Adrian Glaubitz --- Michael Karcher has figured out that this might be a bug in Debian's gcc-9, in particular the patch https://sources.debian.org/src/gcc-9/9.2.1-21/debian/patches/gcc-search-prefixed-as-ld.diff. CC'ing Matthias Klose.
[Bug target/92946] [9 Regression] [SH] Native GCC crashes when invoking with -m4 -m4-nofpu -pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92946 --- Comment #2 from John Paul Adrian Glaubitz --- Filed as: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946792
[Bug target/92946] [9 Regression] [SH] Native GCC crashes when invoking with -m4 -m4-nofpu -pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92946 John Paul Adrian Glaubitz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from John Paul Adrian Glaubitz --- I can confirm that the issue is introduced by the Debian patch gcc-search-prefixed-as-ld.diff. Changing the patch as suggested in the Debian bug report fixes the problem for me. So it's not an upstream bug.
[Bug other/93090] New: RFE: Add a frontend for the Rust programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 Bug ID: 93090 Summary: RFE: Add a frontend for the Rust programming language Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target Milestone: --- This is a request for enhancement to add a frontend for the Rust programming language to GCC. Currently, there is only one official implementation of the Rust language which is the rustc compiler developed by the Rust developers. The goal of this enhancement request is to add a Rust frontend to GCC as an independent implementation, analogue to the already existing Go frontend. The benefits of having an independent implementation of the Rust language in GCC is that it helps writing a formal specification for the Rust language which doesn't exist yet as well as making the language available to a wider range of architectures which are supported by GCC but not LLVM which is what Rust uses as its backend. There are currently two ongoing development projects working on such a Rust frontend for GCC and either of them may be a potential candidate for this request for enhancement: > https://github.com/redbrain/gccrs > https://github.com/sapir/gcc-rust/tree/rust This bug report was created after a short discussion on the gcc-patches mailing list with the intention to create a campaign on BountySource.com to help stimulate the development with a financial incentive to anyone working on a Rust frontend for GCC: > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01568.html I will be using this bug report to create a bounty on BountySource.com.
[Bug other/93090] RFE: Add a frontend for the Rust programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 --- Comment #2 from John Paul Adrian Glaubitz --- (In reply to Jakub Jelinek from comment #1) > The Go FE actually isn't that independent, the same gofrontend is used by > both GCC and LLVM, the same FE written in C++ in that case has then a > compiler dependent layer for GCC and another one for LLVM. Right. I think this argument was partially true though for earlier implementations of the Go frontend in GCC, wasn't it? > So, is for the bountysource another interface for the rustc FE ok, or are > you looking for completely independent FE implementation? I'm fine with either way actually. My main motivation is to have a Rust compiler that supports more architectures than the one currently developed by the Rust develeopers. > And even if yes, can e.g. the runtime library be shared with rustc, > or does it need to be independent? If I understand the approach by "sapir" correctly, this is actually what's being worked on in his gcc-rust frontend: > https://github.com/sapir/gcc-rust/tree/rust > Again, talking about Go, I think the go runtime is shared by all of goland, > gcc-go and gollvm. Which would be perfectly fine with me. I didn't want to leave the impression that a completely independent implementation would be necessary. I just mentioned it because it was brought up as one of the arguments for having a Rust frondend in GCC within the community. I think the approach by "sapir" is actually very promising as it should be able to keep up with Rust upstream which is currently a rather fast moving target.
[Bug target/13515] `asm' operand requires impossible reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13515
--- Comment #4 from John Paul Adrian Glaubitz ---
(In reply to Jason Duerstock from comment #3)
> For giggles, I just tried the test case on ia64, and it compiled
> successfully with GCC 7.2.
On the other hand, the issues occurs when building cgal on ia64:
/<>/include/CGAL/FPU.h:198:32: error: ‘asm’ operand requires
impossible reload
198 | asm volatile ("" : "+gf"(x) );
|^
Full log:
https://buildd.debian.org/status/fetch.php?pkg=cgal&arch=ia64&ver=5.0-5&stamp=1575734711&raw=0
cgal has the following defined for ia64:
# elif defined __ia64
// Itanium
asm volatile ("" : "+gf"(x) );
# else
From: https://sources.debian.org/src/cgal/5.0-5/include/CGAL/FPU.h/#L198
[Bug target/92767] [m68k]: Random ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92767 --- Comment #5 from John Paul Adrian Glaubitz --- Recent builds have been fine: > https://buildd.debian.org/status/fetch.php?pkg=gcc-10&arch=m68k&ver=10-20200117-2&stamp=1579373512&raw=0 I guess it's safe to close this issue.
[Bug target/93808] New: [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 Bug ID: 93808 Summary: [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9 Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de, jrtc27 at jrtc27 dot com, kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* When compiling the ruby2.5 package on Debian/sh4 with gcc-9 instead of gcc-8, the Ruby interpretor crashes with 'Illegal Instruction'. root@tirpitz:..ruby2.5-ixXW4Q/ruby2.5-2.5.5> ./miniruby Illegal instruction root@tirpitz:..ruby2.5-ixXW4Q/ruby2.5-2.5.5> Printing the assembly with GDB shows that the IP seems to be pointing at data instead of code(?): (gdb) x/5i $pc => 0x5380c0 : .word 0x 0x5380c2 : .word 0x0010 0x5380c4 : mov r14,r2 0x5380c6 : bra 0x538094 0x5380c8 : add #-16,r2 (gdb) I have not tested gcc-10 yet. Will do that now.
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #1 from John Paul Adrian Glaubitz --- Log for a successful build with gcc-8: https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=sh4&ver=2.5.5-4&stamp=1564498024&raw=0 Log for a failed build with gcc-9: https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=sh4&ver=2.5.7-1&stamp=1571859355&raw=0
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #3 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #2) > Yeah, that looks like data. Something makes it jump to a wrong address. No > idea why. Can you try to get a bit bigger code snippet at that point? > What's the code/data before and after? I have put the compiled source into a tarball so you can have a look yourself: > https://people.debian.org/~glaubitz/ruby2.5-G7ZWPI.tgz
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #5 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #4)
> (In reply to John Paul Adrian Glaubitz from comment #3)
> >
> > I have put the compiled source into a tarball so you can have a look
> > yourself:
> >
> > > https://people.debian.org/~glaubitz/ruby2.5-G7ZWPI.tgz
>
> Sorry, I will not wade through the whole thing. If you have it crashing in
> the debugger already, please try to provide a bit more context of the crash.
> Like file name, function name ... something like that would be helpful.
Okay, so the backtrace looks like this:
483 switch (e - p) {
(gdb) bt
#0 0x005380c0 in search_nonascii (e=, p=) at
string.c:483
#1 coderange_scan (p=, len=, enc=0x63d698) at
string.c:505
#2 0x00538866 in rb_enc_str_coderange (str=6750060) at string.c:634
#3 0x00538920 in rb_str_hash (str=6750060) at string.c:3112
#4 0x0052fb94 in do_hash (tab=0x63fe20, key=) at st.c:1479
#5 st_update (tab=0x63fe20, key=, func=0x539fb8
, arg=2080371772) at st.c:1479
#6 0x00534c46 in register_fstring (str=6750060) at string.c:341
#7 0x0054e06a in register_static_symid_str (id=33, str=) at
symbol.c:417
#8 0x0054e458 in register_static_symid (enc=0x63d698, len=1, name=0x7bfff47f
"!\\\bI", id=33) at symbol.c:407
#9 Init_op_tbl () at symbol.c:46
#10 Init_sym () at symbol.c:86
#11 0x0049085c in rb_call_inits () at inits.c:21
#12 0x00472c86 in ruby_setup () at eval.c:61
#13 0x0047444c in ruby_init () at eval.c:78
#14 0x00418e76 in main (argc=, argv=) at
./main.c:41
(gdb)
I will probably have to rebuild with debug symbols disabled so we can see more.
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #7 from John Paul Adrian Glaubitz --- Created attachment 47871 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47871&action=edit Source and compiler output for string.c I have created a tarball which contains both the C source, the assembly, the preprocessed source and the object file for string.
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #9 from John Paul Adrian Glaubitz --- (In reply to Richard Biener from comment #8) > One may want to see whether GCC 10 is affected or not. Yes, I can confirm it affects GCC-10 as well.
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #11 from John Paul Adrian Glaubitz --- Created attachment 47878 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47878&action=edit Source and compiler output for string.c with stack-protector disabled (In reply to Oleg Endo from comment #10) > It's difficult to see what's going on there. Can you try building this > without the stackprotector options and see if still crashes in the same way? I have stripped "-fstack-protector" and "-fstack-protector-strong" from the CFLAGS, still crashes. Attaching the corresponding tarball of the string.* files. I can try removing more flags from CFLAGS and see if that helps.
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #12 from John Paul Adrian Glaubitz --- Building with -O1 fixes the problem for me. Now I need to compare the flags for -O1 and -O2 and check which one breaks the build.
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #13 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #12) > Building with -O1 fixes the problem for me. Now I need to compare the flags > for -O1 and -O2 and check which one breaks the build. It's -fcrossjumping which causes the crash. Passing -fno-crossjumping fixes the build.
[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
John Paul Adrian Glaubitz changed:
What|Removed |Added
CC||glaubitz at physik dot
fu-berlin.d
||e, olegendo at gcc dot gnu.org
--- Comment #6 from John Paul Adrian Glaubitz ---
I'm seeing this exact problem SH as well when trying to build webkit2gtk:
FAILED:
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
/usr/bin/c++ -DANGLE_ENABLE_ESSL -DANGLE_ENABLE_GLSL -DBUILDING_GTK__=1
-DBUILDING_WITH_CMAKE=1 -DEGL_EGL_PROTOTYPES=0
-DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DGL_GLES_PROTOTYPES=0 -DHAVE_CONFIG_H=1
-DJSC_GLIB_API_ENABLED -DLIBANGLE_IMPLEMENTATION
-DWEBKITGTK_API_VERSION_STRING=\"4.0\" -I../Source/ThirdParty/ANGLE/include
-I../Source/ThirdParty/ANGLE/include/KHR -I../Source/ThirdParty/ANGLE/src
-I../Source/ThirdParty/ANGLE/src/common/third_party/base
-fdiagnostics-color=always -Wextra -Wall -Wno-expansion-to-defined -Wno-psabi
-Wno-noexcept-type -Wno-maybe-uninitialized -Wwrite-strings -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -g1
-O2 -fdebug-prefix-map=/<>=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -mlra -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti -fPIC
-Wno-cast-align -Wno-suggest-attribute=format -Wno-type-limits -Wno-undef
-Wno-unused-parameter -std=c++17 -MD -MT
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
-MF
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o.d
-o
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
-c ../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp: In static
member function ‘static sh::TConstantUnion*
sh::TIntermConstantUnion::FoldAggregateBuiltIn(sh::TIntermAggregate*,
sh::TDiagnostics*)’:
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
error: insn does not satisfy its constraints:
3747 | }
| ^
(insn 9655 9654 3155 385 (parallel [
(set (reg:SF 66 fr2 [orig:645 _696 ] [645])
(reg:SF 0 r0 [3233]))
(use (reg:SI 154 fpscr0))
(clobber (scratch:SI))
]) 214 {movsf_ie}
(expr_list:REG_DEAD (reg:SF 0 r0 [3233])
(nil)))
during RTL pass: cprop_hardreg
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
internal compiler error: in extract_constrain_insn, at recog.c:2211
Should the constraints be adjusted on SH as well? CC'ing Oleg.
[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913 --- Comment #9 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #8) > It's the same error message, but the actual cause is different. Please open > a new PR for this and attach the pre-processed source file that fails to > compile. Thanks! Working on it.
[Bug target/93876] New: [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
Bug ID: 93876
Summary: [9 10 Regression] [SH] webkit2gtk fails to build with
"error: unable to find a register to spill in class
'R0_REGS'"
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de,
jrtc27 at jrtc27 dot com, kkojima at gcc dot gnu.org,
olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
Trying to build webkit2gtk on Debian sh4 with gcc-9/gcc-10 fails with:
../Source/JavaScriptCore/runtime/JSArrayBufferView.cpp: In member function
'JSC::ArrayBuffer* JSC::JSArrayBufferView::slowDownAndWasteMemory()':
../Source/JavaScriptCore/runtime/JSArrayBufferView.cpp:298:1: error: unable to
find a register to spill in class 'R0_REGS'
298 | }
| ^
../Source/JavaScriptCore/runtime/JSArrayBufferView.cpp:298:1: error: this is
the insn:
(insn 419 418 425 47 (parallel [
(set (subreg:SI (reg:QI 433) 0)
(unspec_volatile:SI [
(mem/v:QI (reg/f:SI 3 r3 [orig:487 _347 ] [487]) [-1
S1 A8])
(reg:QI 7 r7 [425])
(subreg:QI (reg:SI 5 r5 [432]) 0)
] UNSPECV_CMPXCHG_1))
(set (mem/v:QI (reg/f:SI 3 r3 [orig:487 _347 ] [487]) [-1 S1 A8])
(unspec_volatile:QI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_2))
(set (reg:SI 147 t)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_3))
(clobber (scratch:SI))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))
]) "/usr/include/c++/10/bits/atomic_base.h":464:36 405
{atomic_compare_and_swapqi_soft_gusa}
(expr_list:REG_DEAD (reg:SI 5 r5 [432])
(expr_list:REG_DEAD (reg:QI 7 r7 [425])
(expr_list:REG_UNUSED (reg:QI 433)
(expr_list:REG_UNUSED (reg:SI 1 r1)
(expr_list:REG_UNUSED (reg:SI 0 r0)
(nil)))
../Source/JavaScriptCore/runtime/JSArrayBufferView.cpp:298: confused by earlier
errors, bailing out
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #1 from John Paul Adrian Glaubitz --- Command line is: /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore -DBUILDING_WITH_CMAKE=1 -DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DHAVE_CONFIG_H=1 -DJSC_COMPILATION -DJSC_GLIB_API_ENABLED -DJavaScriptCore_EXPORTS -DSTATICALLY_LINKED_WITH_WTF -DWEBKITGTK_API_VERSION_STRING=\"4.0\" -IDerivedSources/ForwardingHeaders -I. -I../Source/JavaScriptCore -I../Source/JavaScriptCore/API -I../Source/JavaScriptCore/assembler -I../Source/JavaScriptCore/b3 -I../Source/JavaScriptCore/b3/air -I../Source/JavaScriptCore/bindings -I../Source/JavaScriptCore/builtins -I../Source/JavaScriptCore/bytecode -I../Source/JavaScriptCore/bytecompiler -I../Source/JavaScriptCore/dfg -I../Source/JavaScriptCore/disassembler -I../Source/JavaScriptCore/disassembler/ARM64 -I../Source/JavaScriptCore/disassembler/udis86 -I../Source/JavaScriptCore/domjit -I../Source/JavaScriptCore/ftl -I../Source/JavaScriptCore/heap -I../Source/JavaScriptCore/debugger -I../Source/JavaScriptCore/inspector -I../Source/JavaScriptCore/inspector/agents -I../Source/JavaScriptCore/inspector/augmentable -I../Source/JavaScriptCore/inspector/remote -I../Source/JavaScriptCore/interpreter -I../Source/JavaScriptCore/jit -I../Source/JavaScriptCore/llint -I../Source/JavaScriptCore/parser -I../Source/JavaScriptCore/profiler -I../Source/JavaScriptCore/runtime -I../Source/JavaScriptCore/tools -I../Source/JavaScriptCore/wasm -I../Source/JavaScriptCore/wasm/js -I../Source/JavaScriptCore/yarr -IDerivedSources/JavaScriptCore -IDerivedSources/JavaScriptCore/inspector -IDerivedSources/JavaScriptCore/runtime -IDerivedSources/JavaScriptCore/yarr -IDerivedSources/ForwardingHeaders/JavaScriptCore/glib -IDerivedSources/JavaScriptCore/javascriptcoregtk/jsc -I../Source/JavaScriptCore/API/glib -IDerivedSources/JavaScriptCore/javascriptcoregtk -I../Source/JavaScriptCore/inspector/remote/glib -IDerivedSources -I../Source/ThirdParty -isystem /usr/include/glib-2.0 -isystem /usr/lib/sh4-linux-gnu/glib-2.0/include -fdiagnostics-color=always -Wextra -Wall -Wno-expansion-to-defined -Wno-psabi -Wno-noexcept-type -Wno-maybe-uninitialized -Wwrite-strings -Wundef -Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -g1 -O2 -fdebug-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti -fPIC -ffp-contract=off -std=c++17 -MD -MT Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-f2e18ffc-15.cpp.o -MF Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-f2e18ffc-15.cpp.o.d -o Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-f2e18ffc-15.cpp.o -c DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-f2e18ffc-15.cpp
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #2 from John Paul Adrian Glaubitz --- Created attachment 47885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47885&action=edit Source and preprocessed source plus assembly
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #3 from John Paul Adrian Glaubitz --- The problem does not affect gcc-8. It affects gcc-9 and gcc-10.
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #4) > the error message is > > unable to find a register to spill in class 'R0_REGS' > > please try to re-build with -mlra Yes, that helps and I just realized that I reported the wrong issue since building webkit2gtk provokes multiple bugs. The one I mentioned in PR91913 affected a different source file.
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #7 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #6) > If -mlra helps with this case, then let's close this one as 'WON'T FIX', ok? Yes, I'll open a new issue for the actual bug I wanted to report. I can reproduce it just fine.
[Bug target/93877] New: [9 10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
Bug ID: 93877
Summary: [9 10 Regression] [SH] webkit2gtk fails to build with
"internal compiler error: in extract_constrain_insn,
at recog.c:2211"
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, kkojima at gcc dot gnu.org,
olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
As mentioned in PR91913, the issue reported there for ARM affects SH as well
when building webkit2gtk on Debian sh4:
(sid-sh4-sbuild)root@nofan:/build/webkit2gtk-huItPy/webkit2gtk-2.26.4/build#
g++-9 -DANGLE_ENABLE_ESSL -DANGLE_ENABLE_GLSL -DBUILDING_GTK__=1
-DBUILDING_WITH_CMAKE=1 -DEGL_EGL_PROTOTYPES=0
-DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DGL_GLES_PROTOTYPES=0 -DHAVE_CONFIG_H=1
-DJSC_GLIB_API_ENABLED -DLIBANGLE_IMPLEMENTATION
-DWEBKITGTK_API_VERSION_STRING=\"4.0\" -I../Source/ThirdParty/ANGLE/include
-I../Source/ThirdParty/ANGLE/include/KHR -I../Source/ThirdParty/ANGLE/src
-I../Source/ThirdParty/ANGLE/src/common/third_party/base
-fdiagnostics-color=always -Wextra -Wall -Wno-expansion-to-defined -Wno-psabi
-Wno-noexcept-type -Wno-maybe-uninitialized -Wwrite-strings -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -g1
-O2 -fdebug-prefix-map=/build/webkit2gtk-huItPy/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -mlra -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti -fPIC
-Wno-cast-align -Wno-suggest-attribute=format -Wno-type-limits -Wno-undef
-Wno-unused-parameter -std=c++17 -MD -MT
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
-MF
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o.d
-o
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
-c ../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp: In static
member function 'static sh::TConstantUnion*
sh::TIntermConstantUnion::FoldAggregateBuiltIn(sh::TIntermAggregate*,
sh::TDiagnostics*)':
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
error: insn does not satisfy its constraints:
3747 | }
| ^
(insn 9655 9654 3155 385 (parallel [
(set (reg:SF 66 fr2 [orig:645 _696 ] [645])
(reg:SF 0 r0 [3233]))
(use (reg:SI 154 fpscr0))
(clobber (scratch:SI))
]) 214 {movsf_ie}
(expr_list:REG_DEAD (reg:SF 0 r0 [3233])
(nil)))
during RTL pass: cprop_hardreg
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
internal compiler error: in extract_constrain_insn, at recog.c:2211
[Bug target/93877] [9 10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #1 from John Paul Adrian Glaubitz --- Created attachment 47886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47886&action=edit Source and preprocessed source plus assembly
[Bug target/93877] [9 10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #2 from John Paul Adrian Glaubitz --- This bug does not affect gcc-8. It affects gcc-9 and gcc-10. Using -mlra does not help.
[Bug target/93877] [9 10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #3 from John Paul Adrian Glaubitz --- Building with -O1 instead of -O2 helps. I can try to bisect the optimization flag which causes this problem later.
[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #4 from John Paul Adrian Glaubitz --- Passing -fno-move-loop-invariants to the command line fixes the problem for me.
[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #5 from John Paul Adrian Glaubitz --- Hmm, there is one other source code file within webkit2gtk where -fno-move-loop-invariants does not help. I can only get that particular source file to be compiled if I disable all optimizations. I tried bisecting the flags between -O0 and -O1 but that didn't work as I expected, unfortunately. So, I guess we can't compile webkit2gtk until this bug has been fixed :(.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #118 from John Paul Adrian Glaubitz --- Is there anything that currently speaks against switching to LRA by default now? I think, it would be a good idea for gcc-11 or even gcc-10 if possible. I will report all issues I'm running into since I am constantly monitoring package builds on Debian/sh4.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #120 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #119) > Last time this issue came up, I asked you to re-build all debian with -mlra > enabled > > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00977.html > > I'm still waiting for the results. > > I've been telling you to turn on LRA for specific cases, but that doesn't > mean it's not gonna have regressions. So please try using -mlra for *all* > packages, including kernel and let the system boostrap. That's a huge task which is why I prefer fixing issues on the fly. We are going to switch over anyway with GCC-12 or GCC-13, so I'm not sure what we are gaining if we continue to wait.
[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #7 from John Paul Adrian Glaubitz --- Created attachment 47907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47907&action=edit Source and preprocessed source plus assembly, second case Here are the saved temps for the second case for which -fno-move-loop-invariants does not help: /usr/bin/c++ -save-temps -DBUILDING_GTK__=1 -DBUILDING_WEBKIT -DBUILDING_WITH_CMAKE=1 -DBUILDING_WebCore -DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DSTATICALLY_LINKED_WITH_PAL=1 -DWEBKITGTK_API_VERSION_STRING=\"4.0\" -IDerivedSources/ForwardingHeaders -I../Source/WebCore/platform/graphics/libwpe -I. -IDerivedSources/WebCore -I../Source/WebCore -I../Source/WebCore/Modules/airplay -I../Source/WebCore/Modules/applepay -I../Source/WebCore/Modules/applepay/paymentrequest -I../Source/WebCore/Modules/applicationmanifest -I../Source/WebCore/Modules/beacon -I../Source/WebCore/Modules/cache -I../Source/WebCore/Modules/credentialmanagement -I../Source/WebCore/Modules/encryptedmedia -I../Source/WebCore/Modules/encryptedmedia/legacy -I../Source/WebCore/Modules/entriesapi -I../Source/WebCore/Modules/fetch -I../Source/WebCore/Modules/geolocation -I../Source/WebCore/Modules/indexeddb -I../Source/WebCore/Modules/indexeddb/client -I../Source/WebCore/Modules/indexeddb/server -I../Source/WebCore/Modules/indexeddb/shared -I../Source/WebCore/Modules/mediacapabilities -I../Source/WebCore/Modules/mediacontrols -I../Source/WebCore/Modules/mediarecorder -I../Source/WebCore/Modules/mediasession -I../Source/WebCore/Modules/mediasource -I../Source/WebCore/Modules/mediastream -I../Source/WebCore/Modules/mediastream/libwebrtc -I../Source/WebCore/Modules/navigatorcontentutils -I../Source/WebCore/Modules/notifications -I../Source/WebCore/Modules/paymentrequest -I../Source/WebCore/Modules/plugins -I../Source/WebCore/Modules/quota -I../Source/WebCore/Modules/speech -I../Source/WebCore/Modules/streams -I../Source/WebCore/Modules/webaudio -I../Source/WebCore/Modules/webauthn -I../Source/WebCore/Modules/webauthn/cbor -I../Source/WebCore/Modules/webauthn/fido -I../Source/WebCore/Modules/webdatabase -I../Source/WebCore/Modules/webdriver -I../Source/WebCore/Modules/webgpu -I../Source/WebCore/Modules/webgpu/WHLSL -I../Source/WebCore/Modules/webgpu/WHLSL/AST -I../Source/WebCore/Modules/websockets -I../Source/WebCore/Modules/webvr -I../Source/WebCore/accessibility -I../Source/WebCore/accessibility/isolatedtree -I../Source/WebCore/animation -I../Source/WebCore/bindings -I../Source/WebCore/bindings/js -I../Source/WebCore/bridge -I../Source/WebCore/bridge/c -I../Source/WebCore/bridge/jsc -I../Source/WebCore/contentextensions -I../Source/WebCore/crypto -I../Source/WebCore/crypto/algorithms -I../Source/WebCore/crypto/keys -I../Source/WebCore/crypto/parameters -I../Source/WebCore/css -I../Source/WebCore/css/parser -I../Source/WebCore/css/typedom -I../Source/WebCore/cssjit -I../Source/WebCore/dom -I../Source/WebCore/dom/messageports -I../Source/WebCore/domjit -I../Source/WebCore/editing -I../Source/WebCore/fileapi -I../Source/WebCore/history -I../Source/WebCore/html -I../Source/WebCore/html/canvas -I../Source/WebCore/html/forms -I../Source/WebCore/html/parser -I../Source/WebCore/html/shadow -I../Source/WebCore/html/track -I../Source/WebCore/inspector -I../Source/WebCore/inspector/agents -I../Source/WebCore/inspector/agents/page -I../Source/WebCore/inspector/agents/worker -I../Source/WebCore/layout -I../Source/WebCore/layout/blockformatting -I../Source/WebCore/layout/displaytree -I../Source/WebCore/layout/floats -I../Source/WebCore/layout/inlineformatting -I../Source/WebCore/layout/inlineformatting/text -I../Source/WebCore/layout/layouttree -I../Source/WebCore/loader -I../Source/WebCore/loader/appcache -I../Source/WebCore/loader/archive -I../Source/WebCore/loader/archive/mhtml -I../Source/WebCore/loader/cache -I../Source/WebCore/loader/icon -I../Source/WebCore/mathml -I../Source/WebCore/page -I../Source/WebCore/page/animation -I../Source/WebCore/page/csp -I../Source/WebCore/page/scrolling -I../Source/WebCore/platform -I../Source/WebCore/platform/animation -I../Source/WebCore/platform/audio -I../Source/WebCore/platform/encryptedmedia -I../Source/WebCore/platform/gamepad -I../Source/WebCore/platform/graphics -I../Source/WebCore/platform/graphics/cpu/arm -I../Source/WebCore/platform/graphics/cpu/arm/filters -I../Source/WebCore/platform/graphics/displaylists -I../Source/WebCore/platform/graphics/filters -I../Source/WebCore/platform/graphics/iso -I../Source/WebCore/platform/graphics/opentype -I../Source/WebCore/platform/graphics/transforms -I../Source/WebCore/platform/mediacapabilities -I../Source/WebCore/platform/mediarecorder -I../Source/WebCore/platform/mediasession -I../Source/WebCore/platform/mediastream -I../Source/WebCore/platform/mediastream/libwebrtc -I../Source/WebCore/platform/mock -I../Source/WebCore/platform/mock/mediasource -I../Source/WebCore/platform/network -I.
[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #8 from John Paul Adrian Glaubitz --- The second case compiles fine with gcc-8 as well, but fails with g++-9 and g++-10.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #122 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #121) > (In reply to John Paul Adrian Glaubitz from comment #120) > > > > That's a huge task which is why I prefer fixing issues on the fly. > > I thought this is almost fully automated? The build process is. Fixing broken packages isn't. > You can apply this patch to GCC to enable LRA by default for SH > > --- sh.opt.orig 2019-03-04 10:09:09.244521000 +0900 > +++ sh.opt2020-02-26 10:19:55.414340269 +0900 > @@ -299,5 +299,5 @@ > Enable the use of the fsrra instruction. > > mlra > -Target Report Var(sh_lra_flag) Init(0) Save > +Target Report Var(sh_lra_flag) Init(1) Save > Use LRA instead of reload (transitional). > > Then let it rebuild everything. Everything is around 13.000 source packages. > > We are going to switch over anyway with GCC-12 or GCC-13, so I'm not sure > > what we are gaining if we continue to wait. > > I don't get it. You want to enable LRA by default for your distro, but you > don't want to rebuild all the packages with that modification? It's like .. > shipping a distro with a new compiler, which potentially can't compile the > distro packages (correctly), so instead we secretly use an older compiler to > build the packages ? Is that normal practice? Sorry, sounds like a > mess to me. Debian/sh4 is not a release target, so it's not being shipped and there is no warranty anyway. I also don't have the possibility to rebuild the whole archive in a separate project. There is only unstable. If am doing a complete rebuild now, I will be busy for the next weeks or months (there are new packages coming in every day) looking at issues because there might be a lot of failing packages, also for other reasons. It's simply not practical from my perspective. I'm doing this as a hobby, not as a full time job, so I can't take care of all issues all-day long. And, finally, the buildd capacity is limited on sh4. If this was POWER or SPARC, we would have plenty of resources for a complete rebuild.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #123 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #121) > (In reply to John Paul Adrian Glaubitz from comment #120) > > > > That's a huge task which is why I prefer fixing issues on the fly. > > I thought this is almost fully automated? > > You can apply this patch to GCC to enable LRA by default for SH > > --- sh.opt.orig 2019-03-04 10:09:09.244521000 +0900 > +++ sh.opt2020-02-26 10:19:55.414340269 +0900 > @@ -299,5 +299,5 @@ > Enable the use of the fsrra instruction. > > mlra > -Target Report Var(sh_lra_flag) Init(0) Save > +Target Report Var(sh_lra_flag) Init(1) Save > Use LRA instead of reload (transitional). I will just do that for the default kernel now. But I won't trigger a full archive rebuild. Just report issues once I see them.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #124 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #123) > I will just do that for the default kernel now. But I won't trigger a full > archive rebuild. Just report issues once I see them. Compiler, of course. Not kernel.
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #25 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #24) > Adrian, have you had a chance to apply the test patch in comment #22 and > re-run it? I hadn't seen this patch, sorry. I will try that tonight.
[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #13 from John Paul Adrian Glaubitz ---
Indeed, this seems to be related to LRA.
I just tried to build gcc-9 with LRA enabled by default and the build fails
when trying to build gnat with:
checking for shl_load in -ldld... s-gearop.adb: In function
'Ada.Numerics.Complex_Arrays.Back_Substitute.Sub_Row':
s-gearop.adb:124:11: error: insn does not satisfy its constraints:
(insn 463 462 465 5 (parallel [
(set (reg:SF 65 fr1 [343])
(reg:SF 0 r0 [344]))
(use (reg:SI 154 fpscr0))
(clobber (scratch:SI))
]) "a-ngcoty.adb":68:10 214 {movsf_ie}
(expr_list:REG_DEAD (reg:SF 0 r0 [344])
(nil)))
+===GNAT BUG DETECTED==+
| 9.2.1 20191130 (sh4-linux-gnu) in extract_constrain_insn, at recog.c:2211|
| Error detected around s-gearop.adb:124:11|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ . |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact command that you entered. |
| Also include sources listed below. |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).
[Bug go/88500] New: [SH]: SETCONTEXT_CLOBBERS_TLS needs to be handled in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88500 Bug ID: 88500 Summary: [SH]: SETCONTEXT_CLOBBERS_TLS needs to be handled in libgo Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: glaubitz at physik dot fu-berlin.de CC: cmang at google dot com, ian at airs dot com, jrtc27 at jrtc27 dot com, kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* Trying to build gcc-8 with gccgo enabled fails on sh4 now with: libtool: compile: /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem /<>/build/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libgo -I ../../../src/libgo/runtime -I../../../src/libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -fno-stack-protector -Wall -Wextra -Wwrite-strings -Wcast-qual -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../src/libgo/../libgcc -I ../../../src/libgo/../libbacktrace -I ../../gcc/include -g -O2 -MT go-unsafe-pointer.lo -MD -MP -MF .deps/go-unsafe-pointer.Tpo -c ../../../src/libgo/runtime/go-unsafe-pointer.c -o go-unsafe-pointer.o >/dev/null 2>&1 ../../../src/libgo/runtime/proc.c:171:4: error: #error unknown case for SETCONTEXT_CLOBBERS_TLS # error unknown case for SETCONTEXT_CLOBBERS_TLS ^ ../../../src/libgo/runtime/proc.c: In function 'runtime_gogo': ../../../src/libgo/runtime/proc.c:289:2: warning: implicit declaration of function 'fixcontext'; did you mean 'setcontext'? [-Wimplicit-function-declaration] fixcontext(ucontext_arg(&newg->context[0])); ^~ setcontext ../../../src/libgo/runtime/proc.c: In function 'runtime_mstart': ../../../src/libgo/runtime/proc.c:492:2: warning: implicit declaration of function 'initcontext'; did you mean 'setcontext'? [-Wimplicit-function-declaration] initcontext(); ^~~ setcontext Looking at libgo/runtime/proc.c, it looks like this is because sh*-*-* defines SETCONTEXT_CLOBBERS_TLS and it needs to be handled in libgo/runtime/proc.c.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #27 from John Paul Adrian Glaubitz --- > Port is now obsolete, will be removed in GCC9 unless sufficient maintenance > is provided. So, instead fixing bugs upstream projects just now tell users to go away?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #28 from John Paul Adrian Glaubitz --- Just built two weeks ago, natively: root@atlantis:~> gcc-8 -v Using built-in specs. COLLECT_GCC=gcc-8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnuspe/8/lto-wrapper Target: powerpc-linux-gnuspe Configured with: ../src/configure -v --with-pkgversion='Debian 8-20180402-1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=powerpc-linux-gnuspe- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --disable-libphobos --enable-objc-gc=auto --enable-secureplt --disable-multilib --enable-multiarch --with-cpu=8548 --enable-e500_double --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnuspe --host=powerpc-linux-gnuspe --target=powerpc-linux-gnuspe Thread model: posix gcc version 8.0.1 20180402 (experimental) [trunk revision 259004] (Debian 8-20180402-1) root@atlantis:~> Full build log: https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=powerpcspe&ver=8-20180402-1&stamp=1522856967&raw=0
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #30 from John Paul Adrian Glaubitz --- (In reply to Jakub Jelinek from comment #29) > The rs6000 backend had since the split around 290 commits that didn't touch > the powerpcspe backend, if we just assume that only 20% of those are > relevant to powerpcspe too (hard to judge exactly because the dead code from > there isn't removed), then that is still significant number of known issues > in the port. It works fine for Debian. gcc-8 is able to build itself on powerpcspe with no apparent issues. I can also run the testsuite if necessary. We currently have turned it off to save build time as we currently have only three powerpcspe build machines. But we will add two more in the near future and then we can also enable running testsuites. > The announcement of the intent to obsolete the port has been posted already > more than a year ago, if you look in the comments in this PR, you'll see > numerous pings, despite which no (significant) action has been taken. Well, not everyone can be on every list, so it's easy to miss such announcements. There are many projects like OpenJDK, binutils, glibc, the kernel and such which want upstream attention, so you have to agree it's a bit difficult to be always everywhere to be able to answer questions. I was just pointed at your deprecation mail on IRC. In any case, Debian is probably the largest downstream user that has such a huge variety of ports. We are building always the latest versions of gcc natively on more than 20 architectures: > https://buildd.debian.org/status/package.php?p=gcc-8&suite=sid Matthias Klose is constantly uploading new versions and we always make sure gcc builds fine on all targets - natively. We also have a gcc-snapshot package that is constantly updated to the latest SVN version and built natively as well: > https://buildd.debian.org/status/package.php?p=gcc-snapshot&suite=sid We have users who are using Debian on these targets, even on m68k because retro computing is very popular around that CPU. So, I think it would be fair if important upstream projects like gcc could send a message to downstream projects like Debian in such cases, to give at least users of certain ports a notice if there are any concerns upstream. > GCC backends need active maintainance, including regular testing, reporting > regressions and fixing those, otherwise they are only significant burden to > other maintainers and not really useful to users. I am aware of that. But the thing is, the backend in question works fine at the moment. I would agree with your stance if we were seeing any serious issues with it. But that's currently not the case, so I don't understand this particular action. Is there anything specific bug that blocks things at the moment that we are missing downstream?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #32 from John Paul Adrian Glaubitz --- (In reply to Segher Boessenkool from comment #31) > It would have been announced in gcc-7/changes.html (linked from the > announcement on gcc-announce@, I do hope you read that?), but instead of > obsoleting SPE support in the rs6000 port we split off the powerpcspe port, > which was promised to be maintained. Now that that does not seem to be > happening, it will be obsoleted anyway. Andrew said he is still working on it. That is not the same as saying the promise is not going to be kept. gcc isn't a trivial project after all and that work can take some time. > Someone needs to do the work. Sure. I understand that and I am not denying that. But I don't see that this particular port is broken as it is claimed here. Otherwise it wouldn't work for Debian at all, would it? > > We have users who are using Debian on these targets, even on m68k because > > retro computing is very popular around that CPU. > > m68k needs some serious work, too, in the not far future (if the cc0 removal > finally goes through -- that has been over ten years now). Yes, I am aware of that. But there are enough people interested in such work so I think we will be able get around doing that at some point. > > So, I think it would be fair if important upstream projects like gcc could > > send a message to downstream projects like Debian in such cases, to give at > > least users of certain ports a notice if there are any concerns upstream. > > Read gcc-announce@. It's what it is for. Only a few posts per year :-) Ok, I will be subscribing to that one. > > > GCC backends need active maintainance, including regular testing, > > > reporting > > > regressions and fixing those, otherwise they are only significant burden > > > to > > > other maintainers and not really useful to users. > > > > I am aware of that. But the thing is, the backend in question works fine at > > the moment. I would agree with your stance if we were seeing any serious > > issues with it. But that's currently not the case, so I don't understand > > this particular action. > > > > Is there anything specific bug that blocks things at the moment that we are > > missing downstream? > > A port does not need maintenance only for that port, and its users, but also > for GCC itself. All ports are a cost to _all_ GCC developers. If a port is > not maintained it has to be removed. So, again my question is: What exactly is the with the powerpcspe target at the moment and why does upstream claim the port is broken when it apparently works for us in Debian? Am I missing something? I understand where you are coming from and I know that maintenance needs manpower. However, gcc isn't just any project, it's probably the core project besides the kernel. If you remove a target in gcc, you are killing that target for everyone and that is a problem for its users. And probably the biggest advantage of gcc over LLVM is the plethora of targets it supports. If you are going to ax most of it so that only the targets of commercial relevance would survive - i.e. x86, ARM, s390 and POWER8+ - you will be loosing one of the biggest selling points of gcc.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #36 from John Paul Adrian Glaubitz --- (In reply to Jakub Jelinek from comment #33) > Yes, but the port split was done in May last year, and nothing substantial > happened since then. Port maintainance is not about promises, but about > doing the work. If he does the work soon, the port can be de-obsoleted in > GCC9, otherwise it will be removed, which doesn't mean it can't be added at > some point later. Of course, the later it will be done, the harder it will > be. He is working on it and people are using it. It's not surprising that it takes longer than any work done by paid developers on the x86 or POWER targets. > > > m68k needs some serious work, too, in the not far future (if the cc0 > > > removal > > > finally goes through -- that has been over ten years now). > > > > Yes, I am aware of that. But there are enough people interested in such work > > so I think we will be able get around doing that at some point. > > Nobody did the work in the last 15+ years for m68k, it doesn't seem likely > that all of sudden it will happen. There have been numerous posts about > what to do to get rid of cc0, e.g. in 2005 and several other years. > See https://gcc.gnu.org/backends.html for details, a healthy port doesn't > have > c (cc0), p (not using define_peephole2), has a (uses LRA). We can't > maintain old reload, or cc0 support indefinitely. I have been doing some research yesterday myself and couldn't find a page which documents on how to write a port. I couldn't even find documentation on the cc0 stuff. > > > A port does not need maintenance only for that port, and its users, but > > > also > > > for GCC itself. All ports are a cost to _all_ GCC developers. If a port > > > is > > > not maintained it has to be removed. > > > > So, again my question is: What exactly is the with the powerpcspe target at > > the moment and why does upstream claim the port is broken when it apparently > > works for us in Debian? Am I missing something? > > Have you read all the threads mentioned in > https://gcc.gnu.org/ml/gcc/2018-04/msg00102.html > and all the above comments? All the details are in there. Could you please just mention issue in question that causes trouble? The messages directly linked only mention PR81084 but I haven't run into this issue myself. Again, could you please mention an urgent issue with the powerpcspe target that causes serious issues for other users or developers? Thanks!
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #38 from John Paul Adrian Glaubitz --- (In reply to Eric Botcazou from comment #35) > Do you IBM guys have a hidden agenda to bury the left-overs of Freescale? ;-) I thought Jakub works for RedHat? > The SPE port has already been moved out of the way so I don't really see the > point in further hammering it like that; there are plenty of obsolete ports > in the tree that would have to removed before this one if the above > criterion was followed to the letter. To be honest: I made this experience already in multiple projects. IBM employees have been quite unfriendly towards PPC targets which were not POWER8 or newer. The answer was usually "Anything lower than POWER8 is no longer supported." talking as if the project in question belongs to IBM. Quite frustrating.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #39 from John Paul Adrian Glaubitz --- (In reply to Jakub Jelinek from comment #37) > Not sure about IBM, I as a GCC developer and RM have major problem with the > amount of dead code in the port, because anyone who makes changes to the > middle-end that need backend changes will waste time adjusting code that is > dead and can't be really tested (all the Altivec/VMX code, all the 64-bit > support in there, all the power6/7/8/9, all the floating point modes stuff, > etc.). It's not a waste of time if people are actually still using the code which is the case for both PowerPCSPE and m68k. I don't understand why some people think it's acceptable to kill open source stuff that is actively being used by others. > Furthermore the lack of -mno-lra removal in it. If somebody is > willing to change all backends rather than waiting on target maintainers to > fix stuff up, at least the work should not be wasted on dead code. Just > look e.g. how many times in the last year Richard Sandiford modified this > dead code in config/powerpcspe. That is pretty much all wasted effort > (others too). I think your problem lies in the fact that you are solely seeing this from the gcc maintainers perspective (which I cannot blame you for and which is not surprising). However, you have to keep in mind that - in the end - gcc is a product that people are using for productive work. So, there has to be a balance between the objective quality of the code and the usefulness of the project. If I understand Eric correctly, the PowerPCSPE backend has been split off from the other PPC code so as long as the code works and people are using it (and with someone even working on updating it), why the hurry to remove it?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #40 from John Paul Adrian Glaubitz --- Is there documentation like this for gcc? > https://llvm.org/docs/WritingAnLLVMBackend.html Would be very useful for people wanting to help with the old backends.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #44 from John Paul Adrian Glaubitz --- (In reply to David Edelsohn from comment #41) > SPE mostly is a separate architecture that happens to share many of the > basic mnemonics with PowerPC. Maintaining the SPE port was a burden to the > Power/PowerPC maintainers. As discussed in the other threads, despite years > of promises, the SPE port was not maintained, not even regular testsuite > results. The communication mostly consisted of bug reports raised a year > after the patch or release. Those are apparent mistakes made in the past. I am happy to provide testsuite results starting next week. As I said, gcc-8 is stable at the moment on real PowerPCSPE hardware. > In regard to IBM employee response to PowerPC targets older than Power8, you > said yourself that these are IBM employees. They are directed to work on > specific projects and patches. Sometimes IBM developers can become too > focused on the Power8 and later issue and include portability in their > design, but IBM also is not a general support center for all PowerPC. IBM is > a business. As with all commercially-supported Open Source projects and all > forms of work in general, some developers have broader interest in the > project and others approach it as a job. I understand how that works. No one is actually asking IBM people to fix anything if they don't want to. But I have a problem with people removing working code that people are using and then dismissing it with answers like the one I received. It would be different if project X belongs to IBM. One of such examples was that POWER5 support was forcefully removed by IBM people from Golang. They claimed that this move was urgently necessary to reduce maintenance burden. Yet all that was needed to get Golang working again on POWER5 was to revert three patches and slightly modify them. I am still rebasing it regularly without any problems.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #45 from John Paul Adrian Glaubitz --- (In reply to Jakub Jelinek from comment #42) > See e.g. https://gcc.gnu.org/onlinedocs/gccint/ > https://gcc.gnu.org/onlinedocs/gccint/#toc-RTL-Representation > https://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html#Machine-Desc > https://kristerw.blogspot.cz/2017/08/writing-gcc-backend_4.html > and many others. Thank you. > Don't really know how is writing a new backend relevant to > maintaining an existing one. Well, I guess there is no documentation "How to fix an unmaintained target and bring it back into shape.", is there? Documenation which explains how to write a backend should also help fixing an existing one.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #48 from John Paul Adrian Glaubitz --- (In reply to Segher Boessenkool from comment #47) > Believe it or not, but the rs6000 port maintainers *care* about older > systems. Then why is something that is still working and being used by people being deprecated? > I wanted to obsolete SPE support because it is a big burden, not in small > part > because no one maintains it. This has been going on for years and years. In what sense? Care to elaborate? I thought the codebase has already been separated out so it doesn't bother the rest of the code base. As mentioned above, it would be nice to be pointed to an actual problem the code is causing right now as-is. > Big pushback; people still want SPE, they just don't want to spend work on > it. So, does every gcc user also have to be a gcc developer? I think the number of people using gcc is magnitudes larger than the people capable of working on the gcc codebase. So I think this argument is a bit unfair. > Well neither do we, it's been enough. So I spent a week splitting off the > port > (also tested removing VSX etc.; removing unused code does not take that long; > I just have no way to *test* it so that was not included). It was agreed the > powerpcspe port would be maintained or it would be removed. Ignoring that there are people still using it. > Now a year later GCC 8 is on the horizon, and the powerpcspe port is still > not > maintained. And the RMs decided to give it *another* year: it is not removed > but merely obsoleted. Why not leave it in as long as it works and it's being used? Mark it as unsupported, broken or wontfix, but please don't remove it.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #49 from John Paul Adrian Glaubitz --- Hi Andrew! (In reply to Andrew Jenner from comment #21) > I'm still actively working on it. The patch is close to ready for commit > now, I think - I'm going to try to get it committed by the end of the week. Is there any progress on this? Is there anything we (Debian) can do to help you? Do you need access to a porterbox or do you need your own powerpcspe hardware for testing? It might be possible to arrange that, I know people who could supply such hardware. Debian got its PowerPC e500v2 boards through donations as well.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #51 from John Paul Adrian Glaubitz --- (In reply to Andrew Jenner from comment #50), > > Thanks for the offer of help. I already have hardware, but I need to get my > test scripts in order. Ok, great! > I'm attaching my current patch. If you could get some > test results with and without this patch to make sure it doesn't break > anything, that would be a tremendous help. Absolutely. Where should I test the patch? Natively on powerpcspe? On x86_64? Or anything else? We have a wide range of architectures available for testing. > Unfortunately I've been > side-tracked onto other projects and haven't been able to give this the > attention it deserves, but I hope to get back to it in the next couple of > weeks. Thanks again! No worries. Your efforts are highly appreciated and I'm happy to help whereever I can.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #53 from John Paul Adrian Glaubitz --- (In reply to Andrew Jenner from comment #52) > (In reply to John Paul Adrian Glaubitz from comment #51) > > Absolutely. Where should I test the patch? Natively on powerpcspe? On > > x86_64? Or anything else? We have a wide range of architectures available > > for testing. > > The patch only changes the powerpcspe backend - there's no need to test it > against any other targets. Ok. I will try a native build then.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #54 from John Paul Adrian Glaubitz --- Just tried a native build with gcc from trunk plus the patch, fails due to an apparent syntax error: powerpc-linux-gnuspe-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 -no-pie -o build/genmatch \ build/genmatch.o ../../build-powerpc-linux-gnuspe/libcpp/libcpp.a build/errors.o build/vec.o build/hash-table.o ../../build-powerpc-linux-gnuspe/libiberty/libiberty.a build/genmddeps ../.././gcc/common.md ../.././gcc/config/powerpcspe/powerpcspe.md > tmp-mddeps ../.././gcc/config/powerpcspe/powerpcspe.md:4362:1: unterminated construct make[3]: *** [Makefile:2306: s-mddeps] Error 1 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod make[3]: Leaving directory '/srv/glaubitz/gcc/host-powerpc-linux-gnuspe/gcc' make[2]: *** [Makefile:4624: all-stage1-gcc] Error 2 make[2]: Leaving directory '/srv/glaubitz/gcc' make[1]: *** [Makefile:23666: stage1-bubble] Error 2 make[1]: Leaving directory '/srv/glaubitz/gcc' make: *** [Makefile:953: all] Error 2 Configured with ./configure --build=powerpc-linux-gnuspe --host=powerpc-linux-gnuspe --target=powerpc-linux-gnuspe --enable-obsolete --with-cpu=8548 --enable-e500_double --with-long-double-128 --disable-libphobos
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #55 from John Paul Adrian Glaubitz --- This seems to help: diff --git a/gcc/config/powerpcspe/powerpcspe.md b/gcc/config/powerpcspe/powerpcspe.md index 746f2bd1ee3..2e08bcea2b5 100644 --- a/gcc/config/powerpcspe/powerpcspe.md +++ b/gcc/config/powerpcspe/powerpcspe.md @@ -4367,7 +4367,7 @@ "#" [(set_attr "type" "store,store,load,load,*,*") (set_attr "update" "yes") - (set_attr "indexed" "yes")] + (set_attr "indexed" "yes")]) (define_split [(set (match_operand:TI2 0 "nonimmediate_operand" "") @@ -4671,7 +4671,7 @@ (clobber (reg:SI LR_REGNO))])] "" [(set_attr "type" "two") - (set (attr "length") (const_int 16))] + (set (attr "length") (const_int 16))]) (define_insn_and_split "tls_gd_sysv" [(set (match_operand:TLSmode 0 "gpc_reg_operand" "=b")
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #56 from John Paul Adrian Glaubitz --- Another issue: In file included from ../.././gcc/config/powerpcspe/powerpcspe.h:1865:0, from ./tm.h:25, from ../.././gcc/genopinit.c:24: ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:14: error: expected ‘}’ before ‘(’ token BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^ ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:20: error: expected ‘)’ before ‘,’ token BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^ ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:23: error: expected unqualified-id before string constant BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^~~ In file included from ./tm.h:25:0, from ../.././gcc/genopinit.c:24: ../.././gcc/config/powerpcspe/powerpcspe.h:1868:1: error: expected declaration before ‘}’ token }; ^ In file included from ../.././gcc/config/powerpcspe/powerpcspe.h:1865:0, from ./tm.h:25, from ../.././gcc/genattrtab.c:108: ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:14: error: expected ‘}’ before ‘(’ token BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^ ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:20: error: expected ‘)’ before ‘,’ token BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^ ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:23: error: expected unqualified-id before string constant BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^~~ In file included from ./tm.h:25:0, from ../.././gcc/genattrtab.c:108: ../.././gcc/config/powerpcspe/powerpcspe.h:1868:1: error: expected declaration before ‘}’ token }; ^ Here I haven't figured out yet where the syntax error is. Either in gcc/config/powerpcspe/powerpcspe.h or gcc/config/powerpcspe/powerpcspe-builtin.def. What I noticed that gcc/config/powerpcspe/powerpcspe-builtin.def has some stray control sequences "^L" around line 212. Removing them did not change anything though.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #57 from John Paul Adrian Glaubitz --- Andrew, could you refresh your patch for the current trunk branch? It doesn't fully apply for me.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #59 from John Paul Adrian Glaubitz --- (In reply to Andrew Jenner from comment #58) > Acknowledged. I will try to get to that later this week. Any news on this? News from Debian's side is that we have upgraded build capacity for powerpcspe now with two additional e500v2 machines hosted by Turris in Czech Republic (the guys who make those open source routers).
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #60 from John Paul Adrian Glaubitz --- Ping?
[Bug target/86317] New: ICE: in sched_speculate_insn, at haifa-sched.c:8703 when building OpenJDK-11 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86317 Bug ID: 86317 Summary: ICE: in sched_speculate_insn, at haifa-sched.c:8703 when building OpenJDK-11 on ia64 Product: gcc Version: 8.1.1 URL: https://buildd.debian.org/status/fetch.php?pkg=openjdk -11&arch=ia64&ver=11%7E19-1&stamp=1529924927&raw=0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target Milestone: --- Target: ia64-*-* Created attachment 44320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44320&action=edit Gzipped preprocessed source of taskqueue.inline.hpp Trying to build OpenJDK-11 (Zero VM) on Debian unstable with gcc-8.1.1 ia64 fails with: In file included from /<>/src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp:38:0, from /<>/src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp:31, from /<>/src/hotspot/share/gc/g1/g1OopClosures.cpp:26: /<>/src/hotspot/share/gc/shared/taskqueue.inline.hpp: In member function 'bool GenericTaskQueue::push(E) [with E = G1TaskQueueEntry; MemoryType F = (MemoryType)5; unsigned int N = 131072]': /<>/src/hotspot/share/gc/shared/taskqueue.inline.hpp:98:1: internal compiler error: in sched_speculate_insn, at haifa-sched.c:8703 } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Attaching the preprocessed source. Full build log in: https://buildd.debian.org/status/fetch.php?pkg=openjdk-11&arch=ia64&ver=11%7E19-1&stamp=1529924927&raw=0
[Bug c/91472] New: gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 Bug ID: 91472 Summary: gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7 Product: gcc Version: 8.0 URL: https://buildd.debian.org/status/fetch.php?pkg=gmp&arc h=sparc64&ver=2%3A6.1.2%2Bdfsg-4&stamp=1565898628&raw= 0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com, matorola at gmail dot com Target Milestone: --- Host: sparc64-*-* Starting from gcc-8, the testsuite of gmp fails with the test segfaulting: PASS: t-divis_2exp PASS: t-cong PASS: t-cong_2exp PASS: t-sizeinbase PASS: t-set_str PASS: t-aorsmul ../../test-driver: line 107: 227694 Segmentation fault "$@" > $log_file 2>&1 FAIL: t-cmp_d PASS: t-cmp_si PASS: t-hamdist PASS: t-oddeven PASS: t-popcount PASS: t-set_f PASS: t-io_raw PASS: t-import PASS: t-export PASS: t-pprime_p PASS: t-nextprime PASS: t-remove PASS: t-limbs Testsuite summary for GNU MP 6.1.99 # TOTAL: 64 # PASS: 63 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See tests/mpz/test-suite.log Please report to gmp-b...@gmplib.org, see https://gmplib.org/manual/Reporting-Bugs.html The same gmp builds and tests fine with gcc-7.
[Bug lto/64636] Bootstrapping gcc-4.9.2 fails if lto is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #4 from John Paul Adrian Glaubitz --- This looks very similar to the failure on linux-sparc64 with LTO enabled: ../../src/libiberty/strerror.c: In function 'strtoerrno': ../../src/libiberty/strerror.c:773:1: warning: '/<>/build/libiberty/strerror.gcda' profile count data file not found [-Wmissing-profile] 773 | } | ^ ../../src/libiberty/strsignal.c: In function 'strtosigno': ../../src/libiberty/strsignal.c:536:1: warning: '/<>/build/libiberty/strsignal.gcda' profile count data file not found [-Wmissing-profile] 536 | } | ^ during IPA pass: pure-const ../../src/libiberty/simple-object.c: In function 'simple_object_write_add_data': ../../src/libiberty/simple-object.c:565:1: internal compiler error: in stream_out_histogram_value, at value-prof.c:369 565 | } | ^ if [ x"" != x ]; then \ /<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/lib/ -isystem /usr/sparc64-linux-gnu/include -isystem /usr/sparc64-linux-gnu/sys-include -isystem /<>/build/sys-include -c -DHAVE_CONFIG_H -g -O2 -fprofile-use -flto=jobserver -I. -I../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE -fPIC ../../src/libiberty/simple-object-elf.c -o noasan/simple-object-elf.o; \ else true; fi /<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/lib/ -isystem /usr/sparc64-linux-gnu/include -isystem /usr/sparc64-linux-gnu/sys-include -isystem /<>/build/sys-include -c -DHAVE_CONFIG_H -g -O2 -fprofile-use -flto=jobserver -I. -I../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE ../../src/libiberty/simple-object-elf.c -o simple-object-elf.o ../../src/libiberty/cp-demangle.c: In function 'd_print_cast.isra.0': ../../src/libiberty/cp-demangle.c:6648:1: warning: '/<>/build/libiberty/pic/cp-demangle.gcda' profile count data file not found [-Wmissing-profile] 6648 | } | ^ ../../src/libiberty/regex.c: In function 'xregfree': ../../src/libiberty/regex.c:8131:1: warning: '/<>/build/libiberty/pic/regex.gcda' profile count data file not found [-Wmissing-profile] 8131 | } | ^ configure: creating cache ./config.cache checking build system type... sparc64-unknown-linux-gnu checking host system type... sparc64-unknown-linux-gnu checking target system type... sparc64-unknown-linux-gnu checking whether /usr/bin/make sets $(MAKE)... if [ x"" != x ]; then \ /<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/lib/ -isystem /usr/sparc64-linux-gnu/include -isystem /usr/sparc64-linux-gnu/sys-include -isystem /<>/build/sys-include -c -DHAVE_CONFIG_H -g -O2 -fprofile-use -flto=jobserver -I. -I../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE -fPIC ../../src/libiberty/regex.c -o noasan/regex.o; \ else true; fi /<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/lib/ -isystem /usr/sparc64-linux-gnu/include -isystem /usr/sparc64-linux-gnu/sys-include -isystem /<>/build/sys-include -c -DHAVE_CONFIG_H -g -O2 -fprofile-use -flto=jobserver -I. -I../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE ../../src/libiberty/regex.c -o regex.o if [ x"" != x ]; then \ /<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/bin/ -B/usr/sparc64-linux-gnu/lib/ -isystem /usr/sparc64-linux-gnu/include -isystem /usr/sparc64-linux-gnu/sys-include -isystem /<>/build/sys-include -c -DHAVE_CONFIG_H -g -O2 -fprofile-use -flto=jobserver -I. -I../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE -fPIC ../../src/libiberty/cp-demangle.c -o noasan/cp-demangle.o; \ else true; fi yes checking for a BSD-compatible install... 0x9ab447 stream_out_histogram_value(output_block*, histogram_value_t*) ../../src/gcc/value-prof.c:369 /usr/bin/install -c Full log in: https://buildd.debian.org/status/fetch.php?pkg=gcc-9&arch=sparc64&ver=9.2.1-1&stamp=1565961822&raw=0
[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472 --- Comment #3 from John Paul Adrian Glaubitz --- It can reproduced by simply cloning the gmp repo, building it and running the testsuite: $ hg clone https://gmplib.org/repo/gmp $ cd gmp $ ./.bootstrap && ./configure --enable-cxx --enable-fat --build sparc64-linux-gnu && make -j32 && make check Switching gcc versions can be achieved by just setting the CC variable, e.g.: $ export CC=gcc-8
[Bug lto/64636] Bootstrapping gcc-4.9.2 fails if lto is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 --- Comment #5 from John Paul Adrian Glaubitz --- I can confirm that disabling LTO on sparc64 makes gcc build fine.
[Bug lto/64636] Bootstrapping gcc-4.9.2 fails if lto is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 --- Comment #7 from John Paul Adrian Glaubitz --- (In reply to Martin Liška from comment #6) > Can you please debug the internal compiler error? > I'm interested in how 'hist' struct looks like? The gcc compile farm has a fast sparc64 porterbox running Debian unstable, so if you want, you can try it yourself.
[Bug target/91851] New: [m68k] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851 Bug ID: 91851 Summary: [m68k] Convert the backend to MODE_CC so it can be kept in future releases Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: burnus at gcc dot gnu.org, jason.duerstock at gmail dot com, jrtc27 at jrtc27 dot com, law at redhat dot com, sch...@linux-m68k.org Target Milestone: --- Host: m68k-*-* This is a tracker bug for the convert the m68k backend from CC0 to MODE_CC so it can be kept in future releases. See: https://gcc.gnu.org/wiki/CC0Transition I will be using this bug report to create a bounty on BountySource.com.
