[Bug c++/119498] New: Incompatible FMV functions not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119498 Bug ID: 119498 Summary: Incompatible FMV functions not diagnosed Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alfierichards at gcc dot gnu.org Target Milestone: --- Cases such as ```c __attribute__ ((target_version("default"))) int foo (int a) { return 1; } __attribute__ ((target_version("sve"))) int foo (int a) { return 1; } __attribute__ ((target_version("sme"))) float foo (int a) { return 1; } ``` There the return type is inconsistent and should not be compatible are not diagnosed and create invalid output. Aarch64 example https://godbolt.org/z/E8s71Y1jK X86 example: https://godbolt.org/z/nbadoTTMW
[Bug tree-optimization/119920] Missed vectorization for conditioned adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920 --- Comment #4 from Alfie Richards --- Ah okay great, I'll shelve this for now and check back later.
[Bug tree-optimization/119920] Missed vectorization for conditioned adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920 --- Comment #2 from Alfie Richards --- Ive explored adding a simplify to match.pd and a case to tree-vect-patterns.cc but both cause other trade-offs that are sub-optimal. Interested in any thoughts on changing ifcvt behavior in this case to change the output, and adding slp patterns for this as other options.
[Bug tree-optimization/119920] New: Missed vectorization for conditioned adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920 Bug ID: 119920 Summary: Missed vectorization for conditioned adds Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: alfierichards at gcc dot gnu.org Target Milestone: --- The following case misses optimization (for Aarch64 SVE) ```c int func(int a, int b, int c, int *m, int n) { int i=0; for (i=0; i
[Bug target/119372] [12/13/14 Regression] Aarch64: Compiling with -march=armv8-a+pauth -mbranch-protection=standard produces autiasp and retaa in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119372 Alfie Richards changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Alfie Richards --- Fixed in: r14-11513-g35ed15af7ddab5 r13-9482-g070296e6c313a7 r12-11010-g0c66b2f14b5d4c
[Bug target/119372] [12/13/14 Regression] Aarch64: Compiling with -march=armv8-a+pauth -mbranch-protection=standard produces autiasp and retaa in the function epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119372 --- Comment #4 from Alfie Richards --- Apologies, I got the PR formatting/number wrong on the commits gcc-14: https://gcc.gnu.org/cgit/gcc/patch/?id=35ed15af7ddab55c2ea1c07811f273a7c4e223fa gcc-13: https://gcc.gnu.org/cgit/gcc/commit/?h=releases/gcc-13&id=070296e6c313a7748efe053feacade4905901b5e gcc-12: https://gcc.gnu.org/cgit/gcc/commit/?h=releases/gcc-12&id=0c66b2f14b5d4cd46388d79b4a73a77433e1dd22
[Bug c++/119383] [14/15 Regression] Boost 1.85 lib test failures after commit r15-8011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119383 Alfie Richards changed: What|Removed |Added CC||alfierichards at gcc dot gnu.org --- Comment #14 from Alfie Richards --- Apologies, I seem to have managed to typod the PR number on the unrelated backport.
[Bug testsuite/120519] g++.target/powerpc/mvc-symbols1.C fail starting with r16-965-g83eee43e998d0a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120519 Alfie Richards changed: What|Removed |Added CC||alfierichards at gcc dot gnu.org --- Comment #1 from Alfie Richards --- Hi Kishan, Apologies for this. I have checked this with a cross compiler and the tests are passing, so its likely a lack of understanding on my part about the ppc architecture. Are you able to share the generated assembly? I configured with `--target=powerpc64le-unknown-linux-gnu --enable-long-long --disable-libsanitizer --disable-bootstrap --disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++`.
[Bug testsuite/120519] g++.target/powerpc/mvc-symbols1.C fail starting with r16-965-g83eee43e998d0a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120519 --- Comment #6 from Alfie Richards --- Pushed a fix for this test. Ive tested it on all the PPC targets I have access to. If Kishan could confirm it fixes your configuration as well that would be great. Sorry for this break! Thanks for the help.
[Bug tree-optimization/119920] Missed vectorization for conditioned adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920 --- Comment #9 from Alfie Richards --- Confirmed this fixes my test case. The optimization is fascinating, and looks really elegant. Thanks for sending it!
[Bug target/120986] ICE when expanding svdot_lane_fpm intrinsic with compile time know FPMR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986 --- Comment #2 from Alfie Richards --- Final reproducer: ```c #include svfloat16_t test (svfloat16_t a, svmfloat8_t b, svmfloat8_t c) { return svdot_lane_fpm (a, b, c, 0, 0); } ``` Compiled with `-O2 -march=armv8-a+sve2+fp8dot2`
[Bug target/120986] ICE when expanding svcreate2 intrinsic with compile time know FPMR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986 --- Comment #1 from Alfie Richards --- Improved reproducer (https://godbolt.org/z/axcc4vzxn)
[Bug c++/119498] Incompatible FMV functions not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119498 Alfie Richards changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Alfie Richards --- Closing as fixed.
[Bug target/120986] New: ICE when expanding svcreate2 intrinsic with compile time know FPMR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986 Bug ID: 120986 Summary: ICE when expanding svcreate2 intrinsic with compile time know FPMR Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: alfierichards at gcc dot gnu.org Target Milestone: --- Reproducer here: https://godbolt.org/z/W3Thbc766 Seemingly some internal logic assumptions are invalidated when the FMPR value is known at compile time? The error does not happen if the function isn't static, or if the FMPR value isn't evaluatable at compile time.