[Bug tree-optimization/103255] [11/12 Regression] optimization breaks address of struct member since r11-4984-g47923622c663ffad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103255 Felix Fietkau changed: What|Removed |Added CC||nbd at nbd dot name --- Comment #4 from Felix Fietkau --- (In reply to Martin Liška from comment #3) > Started with r11-4984-g47923622c663ffad. A revert of that commit in 11.2.0 fixes the issue for me.
[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790 Felix Fietkau changed: What|Removed |Added CC||nbd at nbd dot name --- Comment #3 from Felix Fietkau --- Created attachment 43627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43627&action=edit Proposed fix I've hacked up a patch that seems to fix this issue, but I have no idea if the approach is correct.
[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #28 from Felix Fietkau --- Never mind, it seems that gcc 5.5 is doing that as well. I will run some more tests.
[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #27 from Felix Fietkau --- On the original test case, it generates this code: 00400690 : 400690: 8c830008lw v1,8(a0) 400694: 24020001li v0,1 400698: 10620011beq v1,v0,4006e0 40069c: nop 4006a0: 8c83lw v1,0(a0) 4006a4: nop 4006a8: 28630002sltiv1,v1,2 4006ac: 106abeqzv1,4006d8 4006b0: nop 4006b4: 8c82000clw v0,12(a0) 4006b8: nop 4006bc: 8c42lw v0,0(v0) 4006c0: nop 4006c4: 00a2182bsltuv1,a1,v0 4006c8: 1467bnezv1,4006e8 4006cc: nop 4006d0: 0045102bsltuv0,v0,a1 4006d4: 00021023neguv0,v0 4006d8: 03e8jr ra 4006dc: nop 4006e0: 03e8jr ra 4006e4: 2402li v0,-1 4006e8: 03e8jr ra 4006ec: 24020001li v0,1 It looks to me like it's generating lots of useless nop instructions after lw
[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #24 from Felix Fietkau --- Created attachment 43498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43498&action=edit Test case for internal compiler error (musl source file)´ When I test it with a patched gcc 7.3.x, I get this error on compiling remquo.c from musl with: -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -msoft-float remquo.c: In function 'remquo': remquo.c:82:1: internal compiler error: Segmentation fault } ^ 0x9dd06f crash_signal /var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/toplev.c:337 0x9797f8 fix_reg_dead_note /var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:1787 0x97e409 relax_delay_slots /var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3231 0x97e409 dbr_schedule /var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3723 0x97e409 rest_of_handle_delay_slots /var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3864 0x97e409 execute /var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3895 Line 1787 in reorg.c is this piece of code: if (REG_NOTE_KIND (link) != REG_DEAD || !REG_P (XEXP (link, 0))) continue;
[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #16 from Felix Fietkau --- Any update on this, or any way I could help in getting this fixed? It would be nice if we could finally switch OpenWrt to a more recent GCC version soon.
[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 Felix Fietkau changed: What|Removed |Added CC||nbd at nbd dot name --- Comment #10 from Felix Fietkau --- (In reply to Leslie Zhai from comment #9) > GCC 8.0 Still reproducible: > > > : >0: 8c830008lw v1,8(a0) >4: 24020001li v0,1 >8: 1062000dbeq v1,v0,40 >c: nop > 10: 8c83lw v1,0(a0) > 14: 28630002sltiv1,v1,2 > 18: 106bbeqzv1,48 > 1c: nop > 20: dc820010ld v0,16(a0) > 24: dc42ld v0,0(v0) > 28: 00a2182bsltuv1,a1,v0 > 2c: 1466bnezv1,48 > 30: nop > 34: 0045102bsltuv0,v0,a1 > 38: 03e8jr ra > 3c: 0002102fdnegu v0,v0 > 40: 03e8jr ra > 44: 2402li v0,-1 > 48: 03e8jr ra > 4c: 24020001li v0,1 Actually, I think that assembly looks unaffected by the issue. I have some doubts about the commits mentioned in this thread as well. r240965 looks like it simply changes the code generator in a way that makes the bug appear (without being the root cause of it) by affecting how and where branches are generated. It also looks like r248351 changes it again to avoid tripping over the bug, again without affecting the root cause. I don't know that much about GCC internals, so if I'm missing something here, please help me understand.
[Bug target/68400] ICE in change_address_1, at emit-rtl.c:2125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68400 --- Comment #2 from Felix Fietkau --- Created attachment 37446 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37446&action=edit Preprocessed source code to reproduce the issue Triggered the error using the following command: mips-openwrt-linux-musl-gcc -Os -fstack-protector -Os -mips32r2 -mtune=34kc -fno-caller-saves -msoft-float -mips16 -minterlink-mips16 -c -o foo.o pcap-common.preprocessed.c
[Bug target/68400] New: ICE in change_address_1, at emit-rtl.c:2125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68400 Bug ID: 68400 Summary: ICE in change_address_1, at emit-rtl.c:2125 Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nbd at nbd dot name Target Milestone: --- Created attachment 36748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36748&action=edit Proposed fix When MIPS16 is enabled, I get the following ICE when compiling libpcap: ./pcap-common.c: In function 'swap_linux_usb_header.isra.0': ./pcap-common.c:1296:1: internal compiler error: in change_address_1, at emit-rtl.c:2125 } I've analyzed this, and found that it generates a single-byte load from the stack, which is not valid in MIPS16 - only size 4 or 8 is valid for access with offset from the stack pointer, as explained by the comment in mips_regno_mode_ok_for_base_p(). I've attached a patch which fixes the issue.
