[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-19 Ever confirmed|0 |1 --- Comment #3 from Oleg Endo --- In your attached libcanberra_la-read-vorbis.s I can spot the following suspicious code: .LBB70: .loc 1 44 9 is_stmt 0 mova.L52,r0 .LVL48: mov.b @(r0,r2),r1 extu.b r1,r1 .LVL49: brafr1 nop . .L82: .long ca_vorbis_get_nchannels@PLT-(.LPCS10+2-.) .L86: .long free@PLT-(.LPCS9+2-.) .L87: .long ov_clear@PLT-(.LPCS11+2-.) .align 2 .L52: .byte .L54-.L53 .byte .L54-.L53 .byte .L51-.L53 .align 1 (1) .L54: .LBE70: .LBE72: (2) .loc 1 61 24 bra .L50 mov #-7,r9 In (1) a lookup table of 3 bytes is emitted. Because of the following ".align 1" directive, the following code at (2) will be misaligned. Can you please try to compile with -fverbose-asm maybe it will give a first hint as to where the problematic code comes from.
[Bug tree-optimization/115154] [13 Regression] wrong code at optimization levels -O2, -O3, -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 --- Comment #3 from Andrew Pinski --- I wonder if my r13-7434-g682bbd364708fe exposed the issue. And then r14-3432-gddd64a6ec3b38e "fixed" it (on accident).
[Bug tree-optimization/115154] [13 Regression] wrong code at optimization levels -O2, -O3, -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added Known to work||13.1.0, 14.1.0 Keywords||needs-bisection Target Milestone|--- |13.3 Known to fail||13.2.0 --- Comment #2 from Andrew Pinski --- It was caused by something that was backported to GCC 13 for GCC 13.2.0 too. It works in GCC 14.1.0 and the trunk for me.
[Bug tree-optimization/115154] [13 Regression] wrong code at optimization levels -O2, -O3, -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added Summary|[13/14 Regression] wrong|[13 Regression] wrong code |code at optimization levels |at optimization levels -O2, |-O2, -O3, -Os |-O3, -Os --- Comment #1 from Andrew Pinski --- This is fixed in GCC 14. I think it was one of my match.pd patches and it might be backported already to the GCC 13 branch. Let me look.
[Bug tree-optimization/115154] New: [13/14 Regression] wrong code at optimization levels -O2, -O3, -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Bug ID: 115154 Summary: [13/14 Regression] wrong code at optimization levels -O2, -O3, -Os Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: bic60176 at gmail dot com Target Milestone: --- Created attachment 58242 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58242=edit testcase OS: Ubuntu 22.04.3 LTS We found that there are discrepancies when compiling with gcc-13.2.0, gcc-14.1.0 at optimization levels -O2, -O3, and -Os. $ ../compiler-builds/gcc-13.2.0_build/bin/gcc -fsanitize=undefined -g -lgcc_s -I/home/csmith/include/csmith-2.3.0 -O2 testcase.c -o exec $ timeout 1s ./exec 2>exec.err f.b=0 $ ../compiler-builds/gcc-12.3.0_build/bin/gcc -fsanitize=undefined -g -lgcc_s -I/home/csmith/include/csmith-2.3.0 -O2 testcase.c -o exec $ timeout 1s ./exec 2>exec.err f.b=-1
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 --- Comment #5 from Hans-Peter Nilsson --- Created attachment 58241 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58241=edit tree-dump file@518 w. ivopts As above @518 without -fno-ivopts
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 --- Comment #4 from Hans-Peter Nilsson --- Created attachment 58240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58240=edit tree-dump file@517 w. ivopts As above @517, but no -fno-ivopts
[Bug sanitizer/115127] [12/13/14/15 Regression] passing zero to __builtin_ctz() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115127 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 --- Comment #3 from Hans-Peter Nilsson --- Created attachment 58239 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58239=edit tree-dump file @518 arith-rand.c @r15-518 compiled with -fno-ivopts -fdump-tree-optimized -march=v10 -O2
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 --- Comment #2 from Hans-Peter Nilsson --- Created attachment 58238 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58238=edit tree-dump file@517 arith-rand.c @r15-517 compiled with -fno-ivopts -fdump-tree-optimized -march=v10 -O2
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144
--- Comment #1 from Hans-Peter Nilsson ---
I also ran a round compiled with -fno-ivopts -fno-delayed-branch: the latter
because it's somewhat non-linear in finding delay-slot-filling opportunities
(lack of "luck" causing improvements to negate) and the former because it was
mentioned in the commit as similarly messing things up.
That "fixed" all of the performance drop for random_bitstring, but still left
an almost-as-large performance drop in main in
gcc.c-torture/execute/arith-rand-ll.c. IOW, the net performance drop is 1.25%:
r15-0517:
Basic clock cycles, total @: 13662157
r15-0518:
Basic clock cycles, total @: 13832953
The focus of this bug was the on subset of arith-rand-ll.c that is in
gcc.target/cris/pr93372-47.c (i.e. no main function), so if I keep that, the
gist of this PR should instead shift to something like 50% "r15-518 doesn't
play nice with ivopts" but I guess that's already known.
So if anyone's interested in improving r15-518 (but not in ivopts interaction),
I'd suggest that'd be in what happens in the main function for
gcc.c-torture/execute/arith-rand-ll.c.
Having said that, I did compile gcc.target/cris/pr93372-47.c adding -fno-ivopts
-fdump-tree-optimized and it shows that the tot_bits computation ("tot_bits_13
= tot_bits_8 + n_bits_12;") is moved later, right before it's used in a
conditional, which makes me think the delay-branch-scheduling has less
"material" to fill the first delays-slots.
I also compiled gcc.c-torture/execute/arith-rand-ll.c with -fno-ivopts
-fdump-tree-optimized (plus the usual -O2 -march=v10) and will attach the
tree-dump files. They show what the pr93372-47.c change *and* that several
division operations are moved forward. This separates them from the modulus
opterations on the same values, so I guess targets where computing these values
together is a win (not CRIS), we'll see a performance loss.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #4 from Halalaluyafail3 ---
(In reply to Halalaluyafail3 from comment #3)
> enum E { a = 1L, b = _Generic(a, enum E: 2) }; /* { dg-warning "outside the
> range" } */
Seems like I copied this wrong, the comment should be a part of the first
quote.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #3 from Halalaluyafail3 ---
(In reply to uecker from comment #2)
> PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652093.html
I'm confused about the tests added here:
> enum H { x = 1 };
> enum H { x = 2UL + UINT_MAX };
Shouldn't this be a constraint violation if unsigned long is wide than
unsigned?
> If two declarations of the same type have a member-declaration or
> enumerator-list, one shall not be nested within the other and both
> declarations shall fulfill all requirements of compatible types (6.2.7)
> with the additional requirement that corresponding members of structure or
> union types shall have the same (and not merely compatible) types.
Section 6.7.3.4 "Tags" Paragraph 1 N3220
I don't see anything that would require a conversion to int here, nor would I
expect this to be the intent. It should just have the same value and the type
will end up the same as in the previous declaration.
> enum E { a = 1L, b = 2 };
> enum E { a = 1L, b = _Generic(a, enum E: 2) }; /* { dg-warning "outside the
> range" } */
This just seems to be testing if int is compatible with enum E. Which from
testing on godbolt is false on GCC since it would pick for enum E to be
compatible with unsigned. This test also doesn't seem related to the problem
which was having the types of the integral constant expressions for a be
different types.
[Bug sanitizer/115127] [12/13/14/15 Regression] passing zero to __builtin_ctz() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115127 --- Comment #3 from Bi6c --- Created attachment 58237 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58237=edit preprocessed source file
[Bug target/115153] [14/15 Regression] Error: bad immediate value for 8-bit offset - armv7ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153 --- Comment #7 from rudi at heitbaum dot com --- (In reply to Andrew Pinski from comment #6) > I suspect r14-4365-g0731889c026bfe is the cause. > > ``` > (define_insn "arm_atomic_loaddi2_ldrd" >[(set (match_operand:DI 0 "register_operand" "=r") > (unspec_volatile:DI > - [(match_operand:DI 1 "arm_sync_memory_operand" "Q")] > + [(match_operand:DI 1 "memory_operand" "m")] > VUNSPEC_LDRD_ATOMIC))] >"ARM_DOUBLEWORD_ALIGN && TARGET_HAVE_LPAE" > - "ldrd%?\t%0, %H0, %C1" > - [(set_attr "predicable" "yes")]) > + "ldrd\t%0, %H0, %1" > +) > ``` > > Most likely that should have been `ldrd_strd_offset_operand/Do` . There > might be other places in that patch which made the same mistake too. I can confirm that reverting https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0731889c026bfe;hp=bada3c27d855430af736de51439ce275cffda754 allows for the successful compile of both libsanitizer and kodi.
[Bug target/115153] [14/15 Regression] Error: bad immediate value for 8-bit offset - armv7ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153 Andrew Pinski changed: What|Removed |Added Summary|Error: bad immediate value |[14/15 Regression] Error: |for 8-bit offset - armv7ve |bad immediate value for ||8-bit offset - armv7ve Status|WAITING |NEW Target Milestone|--- |14.2 --- Comment #6 from Andrew Pinski --- I suspect r14-4365-g0731889c026bfe is the cause. ``` (define_insn "arm_atomic_loaddi2_ldrd" [(set (match_operand:DI 0 "register_operand" "=r") (unspec_volatile:DI - [(match_operand:DI 1 "arm_sync_memory_operand" "Q")] + [(match_operand:DI 1 "memory_operand" "m")] VUNSPEC_LDRD_ATOMIC))] "ARM_DOUBLEWORD_ALIGN && TARGET_HAVE_LPAE" - "ldrd%?\t%0, %H0, %C1" - [(set_attr "predicable" "yes")]) + "ldrd\t%0, %H0, %1" +) ``` Most likely that should have been `ldrd_strd_offset_operand/Do` . There might be other places in that patch which made the same mistake too.
[Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153 --- Comment #5 from rudi at heitbaum dot com --- (In reply to rudi from comment #4) > We have also see the same failure building kodi (vpeter4 did the > investigation) > The difference between gcc13 and 14 is > > gcc-13, ok > add r0, r0, #384 > ldrdr2, r3, [r0] > > gcc-14, not ok > dmb ish > ldrdr2, r3, [r0, #384] > > The kodi issue is at - https://github.com/xbmc/xbmc/issues/25221 This was when we built a working gcc (we compiled it without libsanitizer)
[Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153 --- Comment #4 from rudi at heitbaum dot com --- We have also see the same failure building kodi (vpeter4 did the investigation) The difference between gcc13 and 14 is gcc-13, ok add r0, r0, #384 ldrdr2, r3, [r0] gcc-14, not ok dmb ish ldrdr2, r3, [r0, #384] The kodi issue is at - https://github.com/xbmc/xbmc/issues/25221
[Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153 --- Comment #3 from rudi at heitbaum dot com --- (In reply to Andrew Pinski from comment #1) > What is your exact configure command line? Executing (host): /var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain --bindir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/bin --sbindir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/sbin --sysconfdir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/etc --libexecdir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/lib --localstatedir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/var --disable-static --enable-shared --target=armv7ve-libreelec-linux-gnueabihf --with-sysroot=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/armv7ve-libreelec-linux-gnueabihf/sysroot --with-gmp=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain --with-mpfr=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain --with-mpc=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain --with-zstd=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain --with-gnu-as --with-gnu-ld --enable-plugin --enable-lto --enable-gold --enable-ld=default --with-linker-hash-style=gnu --disable-multilib --disable-nls --enable-checking=release --without-ppl --without-cloog --disable-libada --disable-libmudflap --disable-libitm --disable-libquadmath --disable-libgomp --disable-libmpx --disable-libssp --enable-__cxa_atexit --enable-languages=c,c++ --enable-libatomic --enable-decimal-float --enable-tls --enable-shared --disable-static --enable-long-long --enable-threads=posix --disable-libstdcxx-pch --enable-libstdcxx-time --enable-clocale=gnu --with-abi=aapcs-linux --with-arch=armv7ve --with-float=hard --with-fpu=neon-vfpv4
[Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-05-19 --- Comment #2 from Andrew Pinski --- Also can you attach the preprocessed source? and add -v to gcc command line to provide the exact command line which is causing the error?
[Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153 --- Comment #1 from Andrew Pinski --- What is your exact configure command line?
[Bug sanitizer/115153] New: Error: bad immediate value for 8-bit offset - armv7ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153 Bug ID: 115153 Summary: Error: bad immediate value for 8-bit offset - armv7ve Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: rudi at heitbaum dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- When compiling libsanitizer or kodi with a target of armv7ve an assembly failure occurs, this failure does not occur the armv7a target (nor on 64bit targets) Below is the snippet of the failure /var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/.x86_64-linux-gnu/./gcc/xgcc -shared-libgcc -B/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/.x86_64-linux-gnu/./gcc -nostdinc++ -L/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/.x86_64-linux-gnu/armv7ve-libreelec-linux-gnueabihf/libstdc++-v3/src -L/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/.x86_64-linux-gnu/armv7ve-libreelec-linux-gnueabihf/libstdc++-v3/src/.libs -L/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/.x86_64-linux-gnu/armv7ve-libreelec-linux-gnueabihf/libstdc++-v3/libsupc++/.libs -B/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/armv7ve-libreelec-linux-gnueabihf/bin/ -B/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/armv7ve-libreelec-linux-gnueabihf/lib/ -isystem /var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/armv7ve-libreelec-linux-gnueabihf/include -isystem /var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/armv7ve-libreelec-linux-gnueabihf/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 -DCAN_SANITIZE_UB=0 -DASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION=0 -DHAVE_AS_SYM_ASSIGN=1 -I. -I/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/libsanitizer/asan -I.. -I /var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/libsanitizer/include -I /var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/libsanitizer -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf -I../../libstdc++-v3/include -I../../libstdc++-v3/include/armv7ve-libreelec-linux-gnueabihf -I/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++14 -g -O2 -D_GNU_SOURCE -MT asan_preinit.o -MD -MP -MF .deps/asan_preinit.Tpo -c -o asan_preinit.o /var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/libsanitizer/asan/asan_preinit.cpp mv -f .deps/asan_descriptions.Tpo .deps/asan_descriptions.Plo /var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/libsanitizer/asan/asan_thread.h:192:8: warning: ISO C++ forbids flexible array member 'start_data_' [-Wpedantic] 192 | char start_data_[]; |^~~ mv -f .deps/asan_interceptors_vfork.Tpo .deps/asan_interceptors_vfork.Plo mv -f .deps/asan_suppressions.Tpo .deps/asan_suppressions.Plo mv -f .deps/asan_preinit.Tpo .deps/asan_preinit.Po cp asan_preinit.o libasan_preinit.o mv -f .deps/asan_errors.Tpo .deps/asan_errors.Plo /tmp/ccorxrMD.s: Assembler messages: /tmp/ccorxrMD.s:523: Error: bad immediate value for 8-bit offset (272) /tmp/ccorxrMD.s:682: Error: bad immediate value for 8-bit offset (272) /tmp/ccorxrMD.s:1122: Error: bad immediate value for 8-bit offset (272) /tmp/ccorxrMD.s:1460: Error: bad immediate value for 8-bit offset (272) /tmp/ccorxrMD.s:2140: Error: bad immediate value for 8-bit offset (568) /tmp/ccorxrMD.s:2293: Error: bad immediate value for 8-bit offset (568) /tmp/ccorxrMD.s:2550: Error: bad immediate value for 8-bit offset (568) /tmp/ccorxrMD.s:2726: Error: bad immediate value for 8-bit offset (568) /tmp/ccorxrMD.s:2888: Error: bad immediate value for 8-bit offset (272) /tmp/ccorxrMD.s:3077: Error: bad immediate value for 8-bit offset (272) /tmp/ccorxrMD.s:3352: Error: bad immediate value for 8-bit offset (272) /tmp/ccorxrMD.s:3493: Error: bad immediate value for 8-bit offset (272) make[4]: *** [Makefile:661: asan_stats.lo] Error 1
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146 --- Comment #9 from Sergei Trofimovich --- (In reply to Levy Hsu from comment #7) > Created attachment 58236 [details] > [PR]115146 The change fixed `highway-1.0.7` testsuite failure for me.
[Bug tree-optimization/115143] [11/12/13/14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/652 ||095.html --- Comment #10 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652095.html
RENTALS...June 30th, 2024/July 28th, 2024
Hello Mr./Mrs, please confirm if the dates listed below are available. Dates listed below. Arrival date: June 30th, 2024 Departure date: July 28th, 2024 Number of guests: 2 adults Send me the price for the booking period by e-mail. Warm regards, Mr. and Mrs. Martinez
[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115152 --- Comment #3 from Andrew Pinski --- That is it looks like a bad interaction between `Vector(1) char` stores and reads from char. BUT I don't understand how it gets that badly wrong.
[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115152 --- Comment #2 from Andrew Pinski --- The bug is in strlen1: ``` maybe_invalidate called for MEM[(char *)] = vect_pretmp_76.13_77; maybe_invalidate returns 1 maybe_invalidate called for MEM[(char *)] = vect_pretmp_89.18_79; maybe_invalidate returns 1 Optimizing: pretmp_34 = e[0]; into: pretmp_34 = 0; maybe_invalidate called for e[0] = pretmp_34; statement may clobber object 0 bytes in size maybe_invalidate returns 1 maybe_invalidate called for c = _5; maybe_invalidate returns 0 maybe_invalidate called for a = _54; maybe_invalidate returns 0 maybe_invalidate called for b = 2; maybe_invalidate returns 0 maybe_invalidate called for __builtin_abort (); maybe_invalidate returns 0 pointer_query counters: index cache size: 0 index entries: 0 access cache size: 0 access entries: 0 hits: 0 misses: 0 failures: 0 max_depth: 0 ```
[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115152 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-18 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115152 Andrew Pinski changed: What|Removed |Added Summary|wrong code at -O3 with |[13/14/15 Regression] wrong |"-fno-tree-fre |code at -O3 with |-fno-tree-dominator-opts|"-fno-tree-fre |-fno-tree-loop-im" on |-fno-tree-dominator-opts |x86_64-linux-gnu|-fno-tree-loop-im" on ||x86_64-linux-gnu Target Milestone|--- |13.3
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #11 from Andrew Pinski --- Note using "/tmp/rsp.txt" is not acceptable at all since there might be a few linking happening on the machine. You should use make_at_file (which will make either a tmp file which will be deleted at the end compiling or an .args.N file which can be looked at if used with -save-temps) instead from gcc.cc and then pass the filename to collect2 as "@filename" and then inside collect2 expand as needed.
[Bug target/115142] [14/15 Regression] Unrecognizable insn in extract_insn, at recog.cc:2812 with -ftree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115142 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4
[Bug target/115142] [14/15 Regression] Unrecognizable insn in extract_insn, at recog.cc:2812 with -ftree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115142 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2024-05-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug analyzer/114896] analyzer: false-positive with VLA (analyzer-out-of-bounds, CWE-121)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114896
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--- Comment #3 from uecker at gcc dot gnu.org ---
Minimal example:
void foo(void*);
int main(void)
{
unsigned int n;
foo();
int e[n] = { };
return e[n - 1];
}
https://godbolt.org/z/hYPqahYY8
[Bug c++/115121] ++const_dependent_ptr is accepted in uninstantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115121
Andrew Pinski changed:
What|Removed |Added
Summary|++this is accepted in |++const_dependent_ptr is
|uninstantiated template |accepted in uninstantiated
||template
--- Comment #1 from Andrew Pinski ---
Slightly different testcase (without using this) which shows the issue:
```
template
int f() {
T t = 0;
T *const t1 =
int t2 = 0;
int *const t3 =
++t1;
//++t3;
return 0;
}
//const int t = f();
```
This should be rejected as pointer can't have an overload for operator++ even
if the pointer type has a dependent type.
GCC does reject `++t3;` but not `++t1;` at definition time.
[Bug libstdc++/115122] Incorrect detection of C99 support when cross back builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115122 Andrew Pinski changed: What|Removed |Added Build||x86_64-linux-gnu Summary|Incorrect detection of C99 |Incorrect detection of C99 |support when|support when cross back |cross-compiling |builds Host||x86_64-w64-mingw32 --- Comment #1 from Andrew Pinski --- When I do cross back builds, I normally don't rebuild the target libraries and just use the already built target libraries from the cross builds. Since you are now building the target libraries twice and you really don't need to though.
[Bug middle-end/115131] [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115131 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |15.0
[Bug sanitizer/115127] [12/13/14/15 Regression] passing zero to __builtin_ctz() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115127
--- Comment #2 from Andrew Pinski ---
Also I tested even the simplified testcase:
```
volatile int t = 1;
int main (int argc, char* argv[])
{
volatile int print_hash_value = 0;
if (t == 2) print_hash_value = 1;
__builtin_ctz(print_hash_value);
return 0;
}
```
And the trunk reports:
/app/example.cpp:261:5: runtime error: passing zero to ctz(), which is not a
valid argument
Just fine.
[Bug tree-optimization/115152] New: wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115152
Bug ID: 115152
Summary: wrong code at -O3 with "-fno-tree-fre
-fno-tree-dominator-opts -fno-tree-loop-im" on
x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a regression from 12.*, and affects 13.* and later.
Compiler Explorer: https://godbolt.org/z/cvM1TYd7h
[598] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240516 (experimental) (GCC)
[599] %
[599] % gcctk -O3 small.c; ./a.out
[600] %
[600] % gcctk -O3 -fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im
small.c
[601] % ./a.out
Aborted
[602] %
[602] % cat small.c
int a, b, c, d;
char e[1] = {1};
int main() {
for (a = 0; a < 3; a++)
for (b = 0; b < 2; b++)
c = e[0] = e[0] ^ d;
if (!c)
__builtin_abort();
return 0;
}
[Bug c/114831] typeof doesn't evaluate expression when it has variably modified type in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114831 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #2 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652089.html
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #2 from uecker at gcc dot gnu.org --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652093.html
[Bug sanitizer/115127] [12/13/14/15 Regression] passing zero to __builtin_ctz() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115127 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-18 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source?
[Bug other/115136] [15 regression] experimental/functional/searchers.cc fails after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115136 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |FIXED Target Milestone|--- |15.0 Keywords||testsuite-fail, wrong-code
[Bug tree-optimization/115035] Missed optimization: fold min/max in phi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115035
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-05-18
--- Comment #1 from Andrew Pinski ---
Confirmed. GCC does have some code that handles some of this in phiopt but not
in a generic way.
Jump threading can handle:
```
int src1(unsigned a, unsigned b, int c) {
unsigned phi;
if(c) {
dummy();
phi = a < 5 ? a : 5;
} else {
phi = b;
}
if (phi < 6)
dummy();
}
```
But not:
```
int src(unsigned a, unsigned b, int c) {
unsigned phi;
if(c) {
dummy();
phi = a < 5 ? a : 5;
} else {
phi = b;
}
return (phi < 6);
dummy();
}
```
[Bug tree-optimization/115035] Missed optimization: fold min/max in phi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115035 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug other/115140] [15 regression] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c excess errors after r15-579-ga9251ab3c91c8c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115140 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization CC||pinskia at gcc dot gnu.org Target Milestone|--- |15.0
[Bug tree-optimization/115147] exp2 with integer arguments could be translated into ldexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115147 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/115149] [15 Regression] ICE on valid code at -O3 with "-fno-inline -fno-tree-vrp -fno-ipa-sra -fno-tree-dce -fno-tree-ch" on x86_64-linux-gnu: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115149 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Summary|ICE on valid code at -O3|[15 Regression] ICE on |with "-fno-inline |valid code at -O3 with |-fno-tree-vrp -fno-ipa-sra |"-fno-inline -fno-tree-vrp |-fno-tree-dce -fno-tree-ch" |-fno-ipa-sra -fno-tree-dce |on x86_64-linux-gnu:|-fno-tree-ch" on |verify_ssa failed |x86_64-linux-gnu: ||verify_ssa failed Keywords||ice-on-valid-code Version|unknown |15.0
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 --- Comment #8 from Eric Botcazou --- > However, I will comment that it maybe built but there are cats regressions > (1) on x86_64, (2) on i686-darwin17 (many) on i686-darwin9. No idea what > caused those at the moment - and my hardware is very tied up with the > releases. The ACATS regression on x86-64 (cxa4001) is an issue in the test itself, not in the compiler. Darwin-specific regressions might come from Ada changes though.
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146 --- Comment #8 from Uroš Bizjak --- (In reply to Levy Hsu from comment #5) > case E_V16QImode: > mode = V8HImode; > gen_shr = gen_vlshrv8hi3; > gen_shl = gen_vashlv8hi3; Hm, why vector-by-vector shift here? Should there be a call to gen_lshrv8hi3 and gen_ashlv8hi3 instead?
[Bug fortran/115151] New: procedure(acos) [,pointer] :: p - is wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115151
Bug ID: 115151
Summary: procedure(acos) [,pointer] :: p - is wrongly rejected
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
IT looks as if the following is wrongly rejected:
procedure(acos) [,pointer] :: p
While the examples below are with 'pointer', I don't see why it shouldn't be
also valid without 'pointer', but I have not verified it.
But I have to admit that I also have not fully understood C1218 – as I don't
see how one could ever specify something else - it either is by construction an
external procedure or it clashes name wise.
Only:
procedure(acos)[,pointer] :: acos
does not make sense as the former pulls in an 'intrinsic :: acos'.
* * *
Found at https://github.com/klausler/fortran-wringer-tests/ which has several
corner case testcases.
Testcase: acos-iface.f90
-
! Intel, NVF, NAG, f18: works
! GNU, XLF: errors about elemental or non-external procedure as interface
intrinsic :: acos
procedure(acos), pointer :: p
p => acos
print *, p(1.)
end
-
gfortran:
Error: Procedure pointer 'p' at (1) shall not be elemental
GCC's source code refers for this to F2008's ("15.4.3.6 Procedure declaration
statement"):
"C1218 (R1211) If a proc-interface describes an elemental procedure, each
procedure-entity-name shall specify an external procedure."
where
R1211 procedure-declaration-stmt is PROCEDURE ( [ proc-interface ] )7
[ [ , proc-attr-spec ] ... :: ] proc-decl -list
R1214 proc-decl is procedure-entity-name [ => proc-pointer-init ]
* * *
Furthermore, for procedure pointers, there is:
C1220 (R1217) The procedure-name shall be the name of a nonelemental external
or module procedure, or a specific intrinsic function listed in 13.6 and not
marked with a bullet (•).
where:
"R1216 proc-pointer-init is null-init
or initial-proc-target
R1217 initial-proc-target is procedure-name"
'acos' has no dot – and 13.6 has:
"Note that a specific function that is marked with a bullet (•) is not
permitted to be used as an actual argument (12.5.1, C1220), as a target in a
procedure pointer assignment statement (7.2.2.2, C729), or as the interface in
a procedure declaration statement (12.4.3.6, C1216)."
The latter implies that 'acos' is permitted on 'p => acos'.
* * *
Thus, the question is still whether C1218 makes sense for 'p', i.e. does it
apply to 'p' and (if so) is this is valid for proc pointers or not?
"C855 A named procedure with the POINTER attribute shall have the EXTERNAL
attribute." is in any case required for proc-pointers as well.
However, that's given by:
"A procedure declaration statement declares procedure pointers, dummy
procedures, and external procedures. It specifies the EXTERNAL attribute
(8.5.9) for all entities in the proc-decl-list."
Which means - unsurprisingly - that the following is invalid:
module m
contains
subroutine msub; end;
end
use m
intrinsic :: acos
pointer :: msub, intsub, acos ! INVALID
contains
subroutine intsub; end
end
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 --- Comment #7 from Iain Sandoe --- I have not tested on solaris - hopefully that is OK too. However, I will comment that it maybe built but there are cats regressions (1) on x86_64, (2) on i686-darwin17 (many) on i686-darwin9. No idea what caused those at the moment - and my hardware is very tied up with the releases.
[Bug fortran/115150] [12/13/14/15 Regression] SHAPE of zero-sized array yields a negative value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115150 Tobias Burnus changed: What|Removed |Added Target Milestone|--- |12.5 CC||sandra at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- Looking at the dump, GCC 11 has: _gfortran_shape_4 (, D.3966); while GCC 12 has: x[S.3] = (integer(kind=4)) (((unsigned int) a.dim[S.3].ubound - (unsigned int) a.dim[S.3].lbound) + 1); * * * * Probably caused by: r12-4591-g1af78e731feb93 Author: Sandra Loosemore Date: Tue Oct 19 21:11:15 2021 -0700 Fortran: Fixes and additional tests for shape/ubound/size [PR94070] This patch reimplements the SHAPE intrinsic to be inlined similarly to LBOUND and UBOUND, instead of as a library call, to avoid an unnecessary array copy. Various bugs are also fixed. gcc/fortran/ PR fortran/94070 * * * SHAPE has: "Result Value. The result has a value whose i-th element is equal to the extent of dimension i of SOURCE, except that if SOURCE is assumed-rank, and associated with an assumed-size array, the last element is equal to −1." Thus, an example for the latter: GCC 11.4 - good: 0 2 -1 GCC 12 (to trunk) - wrong: -3 2 -1 integer :: x(10) call f(x, -3) contains subroutine f(y,n) integer :: y(1:n,2,*) call g(y) end subroutine g(z) integer :: z(..) print *, shape(z) end end
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146 --- Comment #7 from Levy Hsu --- Created attachment 58236 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58236=edit [PR]115146
[Bug fortran/115150] New: [12/13/14/15 Regression] SHAPE of zero-sized array yields a negative value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115150 Bug ID: 115150 Summary: [12/13/14/15 Regression] SHAPE of zero-sized array yields a negative value Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- GCC 11.4 has: Shape: 0 0 Shape: 0 3 0 But since GCC 12: Shape: -2 0 Shape: -3 3 0 Testcase: implicit none real,allocatable :: A(:),B(:,:) allocate(a(3:0), b(5:1, 3)) print *, 'Shape:', shape(a), size(a) print *, 'Shape:', shape(b), size(b) end
[Bug fortran/44744] Missing -fcheck=bounds diagnostic for function assignment with tmp array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44744 --- Comment #5 from Tobias Burnus --- (In reply to Tobias Burnus from comment #4) > Another variant from lsdalton – or rather the BTW: I have not verified that the cause is the same (temporary variable), but it seems to be likely. When replacing the 'A(i,:,:)' on the LHS with 'B(:,:)', gfortran does diagnose the too large RHS.
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146 H.J. Lu changed: What|Removed |Added Last reconfirmed||2024-05-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #6 from H.J. Lu --- Created attachment 58235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58235=edit A patch Please try this.
[Bug fortran/44744] Missing -fcheck=bounds diagnostic for function assignment with tmp array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44744 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- Another variant from lsdalton – or rather the https://github.com/openrsp/openrsp/archive/v1.0.0.tar.gz it downloads during the build. FLANG diagnoses the LSDalton issue as: error(/home/jehammond/DALTON/lsdalton/build/_deps/openrsp_sources-src/src/ao_dens/rsp_property_caching.f90:2164): Assign: mismatching element counts in array assignment (to 6, from 3) * * * GCC fails to do so. Testcase: – the problem is that the RHS is 3 and the LHS is 6: implicit none real,allocatable :: A(:,:,:) integer :: n, n2, i n = 6 n2 = 3 allocate(A(3,n,3)) do i = 1, 3 print *, shape(a), '|', shape(f(n2)) a(i,:,:) = f(n2) end do deallocate(A) contains function f(n) integer :: n real :: f(n,3) f = 99.0 end end
[Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930 Sam James changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #5 from Sam James --- This one is still an issue (unlike PR114927 which is fixed).
[Bug c/114927] [14/15 Regression] ICE when building Emacs with -std=c23 -flto (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114927 Sam James changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Sam James --- Fixed now (PR114931).
[Bug tree-optimization/115149] New: ICE on valid code at -O3 with "-fno-inline -fno-tree-vrp -fno-ipa-sra -fno-tree-dce -fno-tree-ch" on x86_64-linux-gnu: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115149
Bug ID: 115149
Summary: ICE on valid code at -O3 with "-fno-inline
-fno-tree-vrp -fno-ipa-sra -fno-tree-dce -fno-tree-ch"
on x86_64-linux-gnu: verify_ssa failed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression as it doesn't reproduce with 14.1 and
earlier.
Compiler Explorer: https://godbolt.org/z/xGfY5vofe
[729] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240516 (experimental) (GCC)
[730] %
[730] % gcctk -O3 -fno-inline -fno-tree-vrp -fno-ipa-sra -fno-tree-dce
-fno-tree-ch small.c
small.c: In function ‘main’:
small.c:4:5: error: stmt with wrong VUSE
4 | int main() {
| ^~~~
# VUSE <.MEM_16(D)>
c_lsm.18_25 = c;
expected .MEM_17
during GIMPLE pass: sink
small.c:4:5: internal compiler error: verify_ssa failed
0x140abbe verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.cc:1203
0x102ded5 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2096
0x102e73e execute_todo
../../gcc-trunk/gcc/passes.cc:2143
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #5 from Levy Hsu ---
switch (d->vmode)
{
case E_V8QImode:
if (!TARGET_MMX_WITH_SSE)
return false;
mode = V4HImode;
gen_shr = gen_ashrv4hi3(should be gen_lshrv4hi3);
gen_shl = gen_ashlv4hi3;
gen_or = gen_iorv4hi3;
break;
case E_V16QImode:
mode = V8HImode;
gen_shr = gen_vlshrv8hi3;
gen_shl = gen_vashlv8hi3;
gen_or = gen_iorv8hi3;
break;
default: return false;
}
Obviously, under V8QImode it should be gen_lshrv4hi3 instead of gen_ashrv4hi3.
I mistakenly used gen_ashrv4hi3 due to the similar naming conventions and
failed to find out. gen_lshrv4hi3 is the correct logical shift needed.
Will send a patch soon
[Bug target/107563] __builtin_shufflevector fails to pshufd instructions under default x86_64 compilation toggle which is the sse2 one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107563
--- Comment #12 from Levy Hsu ---
switch (d->vmode)
{
case E_V8QImode:
if (!TARGET_MMX_WITH_SSE)
return false;
mode = V4HImode;
gen_shr = gen_ashrv4hi3(should be gen_lshrv4hi3);
gen_shl = gen_ashlv4hi3;
gen_or = gen_iorv4hi3;
break;
case E_V16QImode:
mode = V8HImode;
gen_shr = gen_vlshrv8hi3;
gen_shl = gen_vashlv8hi3;
gen_or = gen_iorv8hi3;
break;
default: return false;
}
Obviously, under V8QImode it should be gen_lshrv4hi3 instead of gen_ashrv4hi3.
I mistakenly used gen_ashrv4hi3 due to the similar naming conventions and
failed to find out. gen_lshrv4hi3 is the correct logical shift needed.
Will send a patch soon
[Bug tree-optimization/115143] [11/12/13/14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143
--- Comment #9 from Andrew Pinski ---
here is one that is more correct to show the failure:
```
unsigned __GIMPLE (ssa,startwith("phiopt"))
foo (unsigned a, unsigned b)
{
unsigned j;
unsigned _23;
unsigned _12;
__BB(2):
if (a_6(D) > 0u)
goto __BB3;
else
goto __BB4;
__BB(3):
j_10 = __PHI (__BB2: b_7(D));
_23 = __MIN (a_6(D), j_10);
goto __BB4;
__BB(4):
_12 = __PHI (__BB3: _23, __BB2: 0u);
return _12;
}
```
But note this does use the canonical form for the comparison; `a > 0u` is the
non-canonical form of `a != 0u` (for unsigned types). That is why it didn't
show up before. My patch (r14-3827-g30e6ee074588ba ) fixed the issue with the
way comparison was doing and exposed this latent bug. It was trying `j_10 >=
1u` before when it should have been doing `j_10 >= 0u` and that is the issue.
THIS only shows up with unsigned types because `j_10 >= 0u` is always true and
it needed that to match the constant really.
Anyways my patch fixes the issue
[Bug target/115142] [14/15 Regression] Unrecognizable insn in extract_insn, at recog.cc:2812 with -ftree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115142 --- Comment #2 from Jeffrey A. Law --- So just one high level note. Nobody is ever going to do something like "-ftree-ter" without having one of the optimization levels on. It's an option combination that just doesn't make sense. But we still shouldn't trigger aborts, ICEs and such. I think this is a minor bug in the mem_shadd_or_shadd_rtx_p function. It probably should be verifying that the value being shifted is a REG. Testing a fix.
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #2 from John Paul Adrian Glaubitz --- It will succeed, if any of the following optimizations are removed: -fcrossjumping -finline-functions -finline-small-functions -freorder-blocks-algorithm=stc -ftree-pre -ftree-tail-merge -ftree-vrp Consequently, it always fails when these flags are present at the same time.
[Bug tree-optimization/115143] [11/12/13/14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Here is one which failed since GCC 10 (when __MIN support was added for
> gimple FE):
> ```
> signed __GIMPLE (ssa,startwith("phiopt"))
> foo (signed a, unsigned b)
> {
> signed j;
> signed _23;
> signed _12;
>
> __BB(2):
> if (a_6(D) > 0)
> goto __BB3;
> else
> goto __BB4;
>
> __BB(3):
> j_10 = __PHI (__BB2: b_11(D));
> _23 = __MIN (a_6(D), j_10);
> goto __BB4;
>
> __BB(4):
> _12 = __PHI (__BB3: _23, __BB2: 0);
> return _12;
>
> }
> ```
This testcase is buggy.
[Bug tree-optimization/115143] [11/12/13/14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 Andrew Pinski changed: What|Removed |Added Known to work|13.2.0 | Severity|blocker |normal Known to fail||10.1.0
[Bug tree-optimization/115143] [11/12/13/14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143
--- Comment #7 from Andrew Pinski ---
here is the simplified gimple testcase so it does not depend on optimizations
before hand:
```
unsigned __GIMPLE (ssa,startwith("phiopt"))
foo (unsigned a, unsigned b)
{
unsigned j;
unsigned _23;
unsigned _12;
__BB(2):
if (a_6(D) != 0u)
goto __BB3;
else
goto __BB4;
__BB(3):
j_10 = __PHI (__BB2: b_11(D));
_23 = __MIN (a_6(D), j_10);
goto __BB4;
__BB(4):
_12 = __PHI (__BB3: _23, __BB2: 0u);
return _12;
}
```
Here is one which failed since GCC 10 (when __MIN support was added for gimple
FE):
```
signed __GIMPLE (ssa,startwith("phiopt"))
foo (signed a, unsigned b)
{
signed j;
signed _23;
signed _12;
__BB(2):
if (a_6(D) > 0)
goto __BB3;
else
goto __BB4;
__BB(3):
j_10 = __PHI (__BB2: b_11(D));
_23 = __MIN (a_6(D), j_10);
goto __BB4;
__BB(4):
_12 = __PHI (__BB3: _23, __BB2: 0);
return _12;
}
```
[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148 --- Comment #1 from John Paul Adrian Glaubitz --- Created attachment 58234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58234=edit Preprocessed source from building read-vorbis.c with gcc-14
[Bug tree-optimization/115137] [15 regression] Miscompilation of wget (test suite hangs) since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115137 Andrew Pinski changed: What|Removed |Added Version|unknown |15.0 Component|middle-end |tree-optimization Target Milestone|--- |15.0
[Bug target/115148] New: [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
Bug ID: 115148
Summary: [SH] [12/13/14 Regression]: libcanberra fails with
'unaligned opcodes detected in executable segment'
Product: gcc
Version: 14.1.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: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
Since gcc 12, building libcanberra on sh4 fails with:
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
gcc-12 -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -W -Wextra -Winline
-Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security
-Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition
-Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wunsafe-loop-optimizations -Wpacked -Werror=overflow -Wp,-D_FORTIFY_SOURCE=2
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-ffunction-sections -fdata-sections
-DCA_PLUGIN_PATH=\"/usr/lib/sh4-linux-gnu/libcanberra-0.30\"
-DCA_MACHINE_ID=\"/var/lib/dbus/machine-id\" -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/build/libcanberra-x2Sqti/libcanberra-0.30/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -c read-vorbis.c -fPIC -DPIC -o
.libs/libcanberra_la-read-vorbis.o
{standard input}: Assembler messages:
{standard input}: Error: unaligned opcodes detected in executable segment
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
This goes away when reducing the optimization to -O1:
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
gcc-12 -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -W -Wextra -Winline
-Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security
-Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition
-Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wunsafe-loop-optimizations -Wpacked -Werror=overflow -Wp,-D_FORTIFY_SOURCE=2
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-ffunction-sections -fdata-sections
-DCA_PLUGIN_PATH=\"/usr/lib/sh4-linux-gnu/libcanberra-0.30\"
-DCA_MACHINE_ID=\"/var/lib/dbus/machine-id\" -g -O1
-Werror=implicit-function-declaration
-ffile-prefix-map=/build/libcanberra-x2Sqti/libcanberra-0.30/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -c read-vorbis.c -fPIC -DPIC -o
.libs/libcanberra_la-read-vorbis.o
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
or switching to gcc 11:
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
gcc-11 -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -W -Wextra -Winline
-Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security
-Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition
-Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wunsafe-loop-optimizations -Wpacked -Werror=overflow -Wp,-D_FORTIFY_SOURCE=2
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-ffunction-sections -fdata-sections
-DCA_PLUGIN_PATH=\"/usr/lib/sh4-linux-gnu/libcanberra-0.30\"
-DCA_MACHINE_ID=\"/var/lib/dbus/machine-id\" -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/build/libcanberra-x2Sqti/libcanberra-0.30/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -c read-vorbis.c -fPIC -DPIC -o
.libs/libcanberra_la-read-vorbis.o
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
This might be related
[Bug middle-end/115137] [15 regression] Miscompilation of wget (test suite hangs) since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115137 --- Comment #9 from Sam James --- Created attachment 58233 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58233=edit reduced.c
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Botcazou --- > as of r15-644, Ada bootstrap succeeded on i686-darwin9 and 17. Great! > I do not known whether that means the issue is actually fixed by recent Ada > commits, or that it's now just become latent. Ada commits have nothing to do with it though, the breakage and the probable fix both came from recent optimization changes.
[Bug tree-optimization/115143] [11/12/13/14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 --- Comment #6 from Andrew Pinski --- Created attachment 58232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58232=edit Patch which I am testing
[Bug tree-optimization/115143] [11/12/13/14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 --- Comment #5 from Andrew Pinski --- Note this is a latent bug that dates back to r0-66475-g8eaa0f34a3387d (GCC 4.1.0) Note also r13-1950-g9bb19e143cfe88 introduced the similar bug too. Basically there needs a check for no phi nodes in the middle bb's.
[Bug target/115065] AVR clz is not always fast as can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115065 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Severity|normal |minor Target Milestone|--- |14.2 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Georg-Johann Lay --- Fixed in v14.2+
[Bug tree-optimization/115143] [11/12/13/14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 Andrew Pinski changed: What|Removed |Added Summary|[13/14/15 Regression] tree |[11/12/13/14/15 Regression] |check: expected class |tree check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.cc:85|at gimple-expr.cc:85 --- Comment #4 from Andrew Pinski --- And GCC 11, and 12 too.
[Bug target/115065] AVR clz is not always fast as can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115065 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:3b88dade7ff8a07fd0843ac1281e095cfd94453e commit r14-10217-g3b88dade7ff8a07fd0843ac1281e095cfd94453e Author: Wolfgang Hospital Date: Sat May 18 15:02:51 2024 +0200 AVR: target/115065 - Tweak __clzhi2. The libgcc implementation of __clzhi2 can be tweaked by one cycle in some situations by re-arranging the instructions. It also reduces the WCET by 1 cycle. libgcc/ PR target/115065 * config/avr/lib1funcs.S (__clzhi2): Tweak. (cherry picked from commit 988838da722dea09bd81ee9d49800a6f24980372)
[Bug tree-optimization/115143] [13/14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 Andrew Pinski changed: What|Removed |Added Known to work||13.2.0 Summary|[14/15 Regression] tree |[13/14/15 Regression] tree |check: expected class |check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.cc:85|at gimple-expr.cc:85 Severity|normal |blocker Target Milestone|14.2|13.3 Known to fail||13.2.1 --- Comment #3 from Andrew Pinski --- Which means it is now a regression in GCC 13.
[Bug target/115065] AVR clz is not always fast as can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115065 --- Comment #2 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:988838da722dea09bd81ee9d49800a6f24980372 commit r15-645-g988838da722dea09bd81ee9d49800a6f24980372 Author: Wolfgang Hospital Date: Sat May 18 15:02:51 2024 +0200 AVR: target/115065 - Tweak __clzhi2. The libgcc implementation of __clzhi2 can be tweaked by one cycle in some situations by re-arranging the instructions. It also reduces the WCET by 1 cycle. libgcc/ PR target/115065 * config/avr/lib1funcs.S (__clzhi2): Tweak.
[Bug tree-optimization/115143] [14/15 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > the bug is in minmax part of phiopt and I think it was caused by my > r14-4279-g68fa82e2d8f868 . > It was not caused by that. Rather it was caused by r14-3827-g30e6ee074588ba .
[Bug tree-optimization/115147] exp2 with integer arguments could be translated into ldexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115147 --- Comment #1 from Jan Schultke --- I did some quick low-quality benchmarks. It doesn't seem to make any kind of difference for libc++ and clang: https://quick-bench.com/q/aq1mZ1sKTWHzdmZf5D7BO2yJ1Yo (or for libstdc++ and clang) For GCC and libstdc++, ldexp turns out to be substantially slower than exp2, which is very surprising: https://quick-bench.com/q/iqGdSMmsUIYNo8O8jC7Py8yOg84
[Bug tree-optimization/115147] New: exp2 with integer arguments could be translated into ldexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115147
Bug ID: 115147
Summary: exp2 with integer arguments could be translated into
ldexp
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: janschultke at googlemail dot com
Target Milestone: ---
https://godbolt.org/z/9141MdG6b
float e(int x) {
return __builtin_exp2f(x);
}
GCC (-O2) optimizes this to:
> e(int):
> pxorxmm0, xmm0
> cvtsi2ssxmm0, edi
> jmp exp2f
Clang (-O2) optimizes this to:
> .LCPI0_0:
> .long 0x3f80
> e(int):
> movss xmm0, dword ptr [rip + .LCPI0_0]
> jmp ldexpf@PLT
I believe translating to ldexp is usually better, and this is a missed
optimization. ldexp takes an integer exponent. Converting x to float and then
going through exp2 seems wasteful in this case.
[Bug c/114831] typeof doesn't evaluate expression when it has variably modified type in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114831 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-18 CC||uecker at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from uecker at gcc dot gnu.org --- Confirmed. We need to propagate C_TYPE_VARIABLY_MODIFIED correctly for address of an array-to-pointer-decay.
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146 Andrew Pinski changed: What|Removed |Added Version|14.0|15.0 Keywords||wrong-code Target Milestone|--- |15.0
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 --- Comment #7 from Iain Sandoe --- additional notes: 1. jamming -std=c++11 into stage2 and 3 cxxflags did not make any difference (I was wondering if some c++17 copy elision thing might have changed the number of temporaries). 2. still there at r15-644 (no surprise) 3. building the object using the stage3 compiler gives the same result as the stage2 one. 4. building the object with the stage3 compiler and -fcompare-debug succeeds. 5. (although it's still out of tree) my aarch64-darwin branch, rebased onto r15-644 also fails in the same way. (not that any of these observations gets us any closer .. )
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146 --- Comment #4 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #3) > Bisected down to r15-498-gc6cc6d4741a880 Sorry, should be r15-499-ga71f90c5a7ae29
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146 Sergei Trofimovich changed: What|Removed |Added CC||admin at levyhsu dot com --- Comment #3 from Sergei Trofimovich --- Bisected down to r15-498-gc6cc6d4741a880
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 --- Comment #5 from Iain Sandoe --- as of r15-644, Ada bootstrap succeeded on i686-darwin9 and 17. I do not known whether that means the issue is actually fixed by recent Ada commits, or that it's now just become latent.
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 Iain Sandoe changed: What|Removed |Added Target|x86_64-darwin |x86_64-darwin, x86_64-linux --- Comment #6 from Iain Sandoe --- (In reply to Andreas Schwab from comment #5) > Dup of PR115137? honestly, I don't know, perhaps but it's not obvious. However, I think that the debug-compare is a red herring (clearly there's some difference in codegen). note: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815459.html which seems to indicate that this does fire on x86_64 linux too - with the right bootstrap conditions.
[Bug target/115065] AVR clz is not always fast as can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115065 --- Comment #1 from Georg-Johann Lay --- IIUC, this is just about the timing of a branch, which in the general != 0 is currently taken (takes 2 ticks), but it's better to only take it in the non-common (= 0) case? So that the common case falls through and thus takes 1 cycle less.
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146 Sergei Trofimovich changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Sergei Trofimovich --- Sounds very similar to https://gcc.gnu.org/PR108064
[Bug target/115146] [15 Regression] Incorrect 8-byte vectorization: psrlw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #1 from Sergei Trofimovich ---
Specifically if I change original example to contain 16 bytes instead of 8:
--- bug.c.orig 2024-05-18 11:07:47.426351557 +0100
+++ bug.c 2024-05-18 11:08:02.135601287 +0100
@@ -15,2 +15,2 @@
-u8 src[8] __attribute__((aligned(16))) = { 0 };
-u8 dst[8] __attribute__((aligned(16))) = { 0 };
+u8 src[16] __attribute__((aligned(16))) = { 0 };
+u8 dst[16] __attribute__((aligned(16))) = { 0 };
@@ -23 +23 @@
-for (unsigned long i = 0; i < 8; i += 2) {
+for (unsigned long i = 0; i < 16; i += 2) {
I get expected code:
Dump of assembler code for function main:
0x00401030 <+0>: sub$0x28,%rsp
0x00401034 <+4>: pxor %xmm0,%xmm0
0x00401038 <+8>: mov%rsp,%rdi
0x0040103b <+11>:movaps %xmm0,(%rsp)
0x0040103f <+15>:movaps %xmm0,0x10(%rsp)
0x00401044 <+20>:call 0x401170
0x00401049 <+25>:movdqa (%rsp),%xmm0
0x0040104e <+30>:lea0x10(%rsp),%rdi
0x00401053 <+35>:movdqa %xmm0,%xmm1
0x00401057 <+39>:psllw $0x8,%xmm0
0x0040105c <+44>:psrlw $0x8,%xmm1
0x00401061 <+49>:por%xmm0,%xmm1
0x00401065 <+53>:movaps %xmm1,0x10(%rsp)
0x0040106a <+58>:call 0x401180
0x0040106f <+63>:xor%eax,%eax
0x00401071 <+65>:add$0x28,%rsp
0x00401075 <+69>:ret
[Bug target/115146] New: [15 Regression] Incorrect 8-byte vectorization: psllw/psraw confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
Bug ID: 115146
Summary: [15 Regression] Incorrect 8-byte vectorization:
psllw/psraw confusion
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially observed as a test failures on highway-1.0.7 on
r15-644-g7422e050f33dd9 compiler:
HwyReverseTestGroup/HwyReverseTest.TestAllReverseLaneBytes/EMU128 FAILED
Self-contained example:
// $ cat bug.c
typedef unsigned char u8;
__attribute__((noipa))
static void fill_src(u8 * src) {
src[0] = 0x00; src[1] = 0xff;
}
__attribute__((noipa))
static void assert_dst(const u8 * dst) {
if (dst[0] != 0xff) __builtin_trap();
if (dst[1] != 0x00) __builtin_trap();
}
int main() {
u8 src[8] __attribute__((aligned(16))) = { 0 };
u8 dst[8] __attribute__((aligned(16))) = { 0 };
// place 0x00 into src[0] and 0xFF into src[1]
fill_src(src);
// swap bytes:
// place 0xFF into dst[0], 0x00 into dst[1]
for (unsigned long i = 0; i < 8; i += 2) {
dst[i + 0] = src[i + 1];
dst[i + 1] = src[i + 0];
}
// make sure bytes swapped
assert_dst(dst);
}
Triggering:
$ gcc bug.c -o a -O1 && ./a
$ gcc bug.c -o a -O2 && ./a
Illegal instruction (core dumped)
A bit of analysis:
Dump of assembler code for function main:
0x00401030 <+0>: sub$0x28,%rsp
0x00401034 <+4>: mov%rsp,%rdi
0x00401037 <+7>: movq $0x0,(%rsp)
0x0040103f <+15>:movq $0x0,0x10(%rsp)
0x00401048 <+24>:call 0x401170
0x0040104d <+29>:movq (%rsp),%xmm0
0x00401052 <+34>:lea0x10(%rsp),%rdi
0x00401057 <+39>:movdqa %xmm0,%xmm1
0x0040105b <+43>:psllw $0x8,%xmm0
0x00401060 <+48>:psraw $0x8,%xmm1 ; <<<- why arithmetic shift?
should be psrllw
0x00401065 <+53>:por%xmm0,%xmm1
0x00401069 <+57>:movq %xmm1,0x10(%rsp)
0x0040106f <+63>:call 0x401180
0x00401074 <+68>:xor%eax,%eax
0x00401076 <+70>:add$0x28,%rsp
0x0040107a <+74>:ret
End of assembler dump.
Here `psraw` should have been `psrllw` to avoid sign bit extension.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-15.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-15.0.0/libexec/gcc/x86_64-unknown-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-15.0.0
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.1/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.39-52-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/<>/gcc-15.0.0/include/c++/15.0.0/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 (experimental) (GCC)
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 Georg-Johann Lay changed: What|Removed |Added Target Milestone|10.5|12.3
[Bug fortran/103312] [11/12/13/14/15 Regression] ICE in gfc_find_component since r9-1098-g3cf89a7b992d483e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103312
--- Comment #9 from Paul Thomas ---
(In reply to Paul Thomas from comment #7)
> Created attachment 58231 [details]
> Preliminary fix for this PR
>
> I went back to the beginning on this problem, having realised that it is far
> too early to resolve the compcall of a class argument in
> gfc_reduce_init_expr. Hence the chunk in expr.cc. The second chunk is
> (possibly) a bit of a kludge and, I would have thought, should be checked,
> at very least by checking that the class extends an abstract type. I will
> come back to this - yard duty calls!
>
> A reduced test case, without the module 'example' and no type extension also
> failed and is now fixed. Also failing in this reduced testcase was:
> function func (this) result (string)
> class(bar) :: this
> character (:), allocatable :: string
> allocate (character(this%size()) :: string)
> string = repeat ("x", len (string))
> end function
>
> Again, this is fixed.
>
> Finally, the patch even regression tests OK :-)
>
> Enough for now.
>
> Paul
I just noticed that the version on my tree has expr guarded in the additional
condition in gfc_reduce_init_expr. Otherwise gfortran.dg/pr103588.f90
segfaults.
Paul
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 --- Comment #5 from Andreas Schwab --- Dup of PR115137?
[Bug fortran/103312] [11/12/13/14/15 Regression] ICE in gfc_find_component since r9-1098-g3cf89a7b992d483e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103312 Paul Thomas changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #8 from Paul Thomas --- Hi Harald, I put you in copy as a heads-up. I think that the patch of comment 7 will be done and dusted by tomorrow night. Regards Paul
