[Bug c/111398] New: GCC should warn if a struct with flexible array member is declared static or onstack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111398
Bug ID: 111398
Summary: GCC should warn if a struct with flexible array member
is declared static or onstack
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tg at mirbsd dot org
Target Milestone: ---
If I have (-std=c99 and up) a…
struct foo {
size_t len;
char buf[];
};
… then I would like to be warned (at least with -Wextra or something) if I do
either of…
static struct foo a; // this
struct foo b; // this
extern struct foo x; // and probably even this!
void bla(void) {
static struct foo c; // this
struct foo d; // and this
}
(Probably the same for GCC’s char buf[0]; extension.)
[Bug tree-optimization/111303] [14 Regression] ICE: in type, at value-range.h:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303 --- Comment #6 from CVS Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:8d8bc560b6ab7f3153db23ffb37157528e5b2c9a commit r14-3913-g8d8bc560b6ab7f3153db23ffb37157528e5b2c9a Author: Jiufu Guo Date: Wed Sep 6 21:38:11 2023 +0800 Checking undefined_p before using the vr For pattern "(X + C) / N": "div (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)", Even if "X" has value-range and "X + C" does not overflow, "@3" may still be undefined. Like below example: _3 = _2 + -5; if (0 != 0) goto ; [34.00%] else goto ; [66.00%] ;; succ: 3 ;; 4 ;; basic block 3, loop depth 0 ;; pred: 2 _5 = _3 / 5; ;; succ: 4 The whole pattern "(_2 + -5 ) / 5" is in "bb 3", but "bb 3" would be unreachable (because "if (0 != 0)" is always false). And "get_range_query (cfun)->range_of_expr (vr3, @3)" is checked in "bb 3", "range_of_expr" gets an "undefined vr3". Where "@3" is "_5". So, before using "vr3", it would be safe to check "!vr3.undefined_p ()". PR tree-optimization/111303 gcc/ChangeLog: * match.pd ((X - N * M) / N): Add undefined_p checking. ((X + N * M) / N): Likewise. ((X + C) div_rshift N): Likewise. gcc/testsuite/ChangeLog: * gcc.dg/pr111303.c: New test.
[Bug libstdc++/111390] 'make check-compile' target is not useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390 --- Comment #4 from Jonathan Wakely --- I think what you're describing or looking for is something completely different, which might be useful but is not what is present today. The libstdc++-v3/scripts/check_compile script cannot be turned into what you're describing. There's simply no way to get to what you want from a naive shell script that isn't parallelized, and doesn't understand the dg-* directives in the tests, and only supports a single -std option for all tests. What we have today is not useful. A replacement would have to be written from scratch anyway, so ripping it out entirely has no downside as far as I can see.
[Bug libstdc++/111390] 'make check-compile' target is not useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390 --- Comment #3 from Eric Gallager --- (In reply to Jonathan Wakely from comment #2) > The fact nobody has tried to use it in 10+ years makes me think it's not all > that useful. Only reason I haven't tried to use it is because I didn't know it existed; if it were also available from the top-level Makefile, it would be more discoverable, and more likely to be used.
[Bug tree-optimization/110293] Some `A CMP (A NEEQ 0)` is not simplified in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293 --- Comment #9 from Andrew Pinski --- Actually here is the rest for the non-zero comparisons. Note for the below case, s can be swapped around with unsigned and the CST comparisons become unsigned comparisons too. s < (s == CST) -> CST == 0 ? s <= 0 : CST < 0 s >= (s == CST) -> CST == 0 ? s > 0 : CST > 0 s > (s == CST) -> CST == 0 ? s <= 0 : CST > 1 s <= (s == CST) -> CST == 0 ? s > 0 : CST <= 1 s < (s != CST) -> CST == 0 ? s < 0 : (CST > 0 ? s < 1 : (s < 1 & s != CST)) s >= (s != CST) -> CST == 0 ? s >= 0 : (CST == 1 ? s > 1 : (CST > 1 ? s != CST & s >= 1 : s >= 1)) s > (s != CST) -> CST == 0 ? s <= 1 : s <= (s != CST) -> CST == 0 ? s > 1 :
[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351 --- Comment #6 from Arthur O'Dwyer --- (In reply to James Y Knight from comment #5) > > Does using __builtin_is_constant_p on the union member not work? > > I've created a proof-of-concept patch for libc++ to support SSO strings > during constant evaluation. It works. > > If everyone disagrees with me and believes that this is a really awesome > foot-gun to give to users, I will go ahead and propose that patch to libc++ > maintainers. (As mentioned, that'll cause more code to be compilable under > libc++ than is possible to permit under libstdc++/MSVC implementations). FWIW #1: Personally I would be weakly in favor of that patch, but I would also be pessimistic about its chances of getting accepted in the current libc++ climate. FWIW #2: A worst-of-both-worlds option ;) would be for your patch to `if consteval` the SSO buffer size so that it would be 24 at runtime (matching libc++'s current behavior) but 16 at compile time (matching libstdc++ and Microsoft if I'm not mistaken, so you'd get your cross-vendor portability at compile time). *I* would still consider that an unnecessary-and-thus-bad crippling of libc++ string's cool 24-byte-SSO feature; but I could imagine someone else finding it more palatable than any other alternative. ["Worst-of-both-worlds" in the sense that you're paying to change the code at all, but the end result still has two codepaths that both need to be maintained, and divergence between compile-time and runtime SSO behavior.]
[Bug tree-optimization/111345] `X % Y is smaller than Y.` pattern could be simpified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111345 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/630109.html --- Comment #1 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630109.html
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 --- Comment #30 from JuzheZhong --- Hi.Richard. I understand your conern: If we are possible have this following possible rule to fold to ELSE value in the future: 1. (cond_len all-false a b c len bias) 2. (cond_len any mask a b c len bias) (len + bias == 0) I think it also can be easily fixed in the backend by ELSE_VALUE targethook. We can return scalar 0 for else value only if (ops[0] != all false mask && LEN+BIAS ！= 0). Am I right? Thanks.
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 JuzheZhong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #15 from JuzheZhong --- fixed
[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393 --- Comment #6 from Andrew Pinski --- (In reply to AK from comment #5) > Created attachment 55890 [details] > GlobalModuleIndex.cpp preprocessed files > > Everytime the crash is in a different file. it could be just because of > memory issues. this does seem like a HW issue. Are you sure you have a decent RISCV machine without any memory issues? I suspect ninja is building with all of the cores which pushes the memory usage high. Maybe lower the clock speed of the CPU you are using. Try with a cross compile also.
[Bug tree-optimization/111394] Warning about uninitialized memory that is actually initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111394 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- (In reply to Sayu from comment #3) > (In reply to Andrew Pinski from comment #1) > > N could be -1 which then would access out of bounds .. > > > > I suspect if you add a check for n being negative in memoized_cut_rod the > > warning will go away and a security issue is solved too. > > I see. I didn't realize that negative indexes are allowed in C, I always > assumed it was undefined behavior or just invalid. However, what does "*r_30 > + _122" mean in the warning? well for pointers it is not undefined. Just in this case it is being allocated via malloc which does make it undefined. But that is the whole reason for the warning. The trunk gives: In function 'memoized_cut_rod_aux', inlined from 'memoized_cut_rod' at :34:14: :5:10: warning: '*' may be used uninitialized [-Wmaybe-uninitialized] 5 | if (r[n] >= 0) | ~^~~ Which was fixed by PR 111253 . But yes this is warning about r being used as not being initialized in the case n in memoized_cut_rod being negative and acessing r[n] here.
[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393 --- Comment #5 from AK --- Created attachment 55890 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55890=edit GlobalModuleIndex.cpp preprocessed files Everytime the crash is in a different file. it could be just because of memory issues.
[Bug tree-optimization/110293] Some `A CMP (A NEEQ 0)` is not simplified in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293 --- Comment #8 from Andrew Pinski --- Created attachment 55889 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55889=edit Runtime test
[Bug bootstrap/111141] Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41 --- Comment #6 from Hans-Peter Nilsson --- Possibly also *gcc-multilib*
[Bug bootstrap/111141] Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson --- ISTR this one is what you get when you miss *linux-libc-dev*; at least it was for Debian, and last I looked Ubuntu was still a derivative. (Noticed last month when building a Docker suitable for gcc.)
[Bug tree-optimization/111394] Warning about uninitialized memory that is actually initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111394 Sayu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Sayu --- (In reply to Andrew Pinski from comment #1) > N could be -1 which then would access out of bounds .. > > I suspect if you add a check for n being negative in memoized_cut_rod the > warning will go away and a security issue is solved too. I see. I didn't realize that negative indexes are allowed in C, I always assumed it was undefined behavior or just invalid. However, what does "*r_30 + _122" mean in the warning?
[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351 --- Comment #5 from James Y Knight --- > Does using __builtin_is_constant_p on the union member not work? I've created a proof-of-concept patch for libc++ to support SSO strings during constant evaluation. It works. If everyone disagrees with me and believes that this is a really awesome foot-gun to give to users, I will go ahead and propose that patch to libc++ maintainers. (As mentioned, that'll cause more code to be compilable under libc++ than is possible to permit under libstdc++/MSVC implementations). However, I continue to believe the opposite outcome, prohibiting this everywhere, would be preferable.
[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393 --- Comment #4 from Andrew Pinski --- Did you first report this to Debian also: See for instructions.
[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393 --- Comment #3 from AK --- gcc -v COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-linux-gnu/13/lto-wrapper Target: riscv64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 13.1.0-6' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --disable-multilib --with-arch=rv64gc --with-abi=lp64d --enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu --target=riscv64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=32 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.1.0 (Debian 13.1.0-6) root@lpi4a:/media/root/d2fc9f48-c166-4a9
[Bug tree-optimization/111394] Warning about uninitialized memory that is actually initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111394 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- Adding: if (n < 0) exit(1); Or: if (n < 0) __builtin_unreachable(); Fixes the warning. Yes the warning could be slightly better but it is definitely a bug in your code if you are not checking the input ...
[Bug tree-optimization/111397] Spurious warning "'({anonymous})' is used uninitialized" when calling a __returns_twice__ function (-Wuninitialized -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111397 --- Comment #1 from Andrew Pinski --- Looks loop copy header change which allowed the warning not to happen. The warning is about the argument of test_setjmpex. Because GCC does not realize __builtin_frame_address cannot jump to the test_setjmpex ... In the case of GCC 12-13, the copy of the loop header happens during thread-full rather than earlier and inserts: _4(ab) = _11(D); Which is what is warned about. _11(D) does not get proped into the phi ...
[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin or fails on x86_64-linux-gnu with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.5 Status|ASSIGNED|RESOLVED --- Comment #11 from Uroš Bizjak --- Fixed.
[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin or fails on x86_64-linux-gnu with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:513bfd3271e7b425e91b0a55f72c134d917e9c12 commit r11-11005-g513bfd3271e7b425e91b0a55f72c134d917e9c12 Author: Uros Bizjak Date: Mon Sep 11 20:56:42 2023 +0200 i386: Handle CONST_WIDE_INT in output_pic_addr_const [PR111340] PR target/111340 gcc/ChangeLog: * config/i386/i386.c (output_pic_addr_const): Handle CONST_WIDE_INT. Call output_addr_const for CASE_CONST_SCALAR_INT. gcc/testsuite/ChangeLog: * gcc.target/i386/pr111340.c: New test. (cherry picked from commit 048927ed8561ca994ad853fe85ccf8c2ca07a8fe)
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #14 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:701b9309b687ed46188b9caeb7d88ad60b0212e5 commit r14-3910-g701b9309b687ed46188b9caeb7d88ad60b0212e5 Author: Juzhe-Zhong Date: Tue Sep 12 21:32:02 2023 +0800 RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337] As this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 We support VECTOR BOOL vcond_mask to fix this following ICE: 0x1a9e309 gimple_expand_vec_cond_expr ../../../../gcc/gcc/gimple-isel.cc:283 0x1a9ea56 execute ../../../../gcc/gcc/gimple-isel.cc:390 gcc/ChangeLog: PR target/111337 * config/riscv/autovec.md (vcond_mask_): New pattern.
[Bug tree-optimization/111397] New: Spurious warning "'({anonymous})' is used uninitialized" when calling a __returns_twice__ function (-Wuninitialized -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111397
Bug ID: 111397
Summary: Spurious warning "'({anonymous})' is used
uninitialized" when calling a __returns_twice__
function (-Wuninitialized -O2)
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: skiminki at gmail dot com
Target Milestone: ---
The following piece of code triggers a spurious warning when calling
test_setjmpex() on GCC 12.3 and GCC 13.2 using -O2 or -O3.
test.c: # compile with: gcc -c -O2 -Wuninitialized test.c
int globalVar = 1;
int __attribute__ ((__returns_twice__)) test_setjmpex(void *context);
void testfn()
{
int localVar = globalVar;
while (!localVar) {
// The below triggers:
// warning: '({anonymous})' is used uninitialized [-Wuninitialized]
test_setjmpex(__builtin_frame_address (0));
if (globalVar)
break;
}
}
No includes needed, so I omitted the .i file. Initially setting
tree-optimization as the component based on a guess.
This was found when compiling Weiss (chess engine) for mingw, but the reduced
test case triggers the warning on regular Linux, too. (Link to the original
issue: https://github.com/TerjeKir/weiss/issues/680 )
Godbolt link: https://godbolt.org/z/ec1dKsx4q
Experimentation with godbolt:
- Affected GCC versions: 12.1 - 12.3; 13.1 - 13.2 ; multiple targets (at least:
x86-64, aarch64, risc-v)
- No warning on 11.x
- No warning on trunk
- No warning on -O1
Full repro:
---
# Ubuntu 23.04 / x86_64-linux-gnu
docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp gcc:13.2 gcc -v -c
-O2 -Wuninitialized test.c
Repro output:
-
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.3.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-O2' '-Wuninitialized' '-mtune=generic'
'-march=x86-64'
/usr/local/libexec/gcc/x86_64-linux-gnu/12.3.0/cc1 -quiet -v -imultiarch
x86_64-linux-gnu test.c -quiet -dumpbase test.c -dumpbase-ext .c -mtune=generic
-march=x86-64 -O2 -Wuninitialized -version -o /tmp/ccZm0Pke.s
GNU C17 (GCC) version 12.3.0 (x86_64-linux-gnu)
compiled by GNU C version 12.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/include
/usr/local/include
/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C17 (GCC) version 12.3.0 (x86_64-linux-gnu)
compiled by GNU C version 12.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1e1b4098557fa4aa478a5470075c20a5
test.c: In function 'testfn':
test.c:12:11: warning: '({anonymous})' is used uninitialized [-Wuninitialized]
12 | test_setjmpex(__builtin_frame_address (0));
| ^~
COLLECT_GCC_OPTIONS='-v' '-c' '-O2' '-Wuninitialized' '-mtune=generic'
'-march=x86-64'
as -v --64 -o test.o /tmp/ccZm0Pke.s
GNU assembler version 2.40 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.40
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-linux-gnu/12.3.0/:/usr/local/libexec/gcc/x86_64-linux-gnu/12.3.0/:/usr/local/libexec/gcc/x86_64-linux-gnu/:/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/:/usr/local/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/:/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-O2' '-Wuninitialized' '-mtune=generic'
'-march=x86-64'
[Bug libstdc++/111172] Dead code in std::get for variant?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-09-12 Status|UNCONFIRMED |NEW
[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951 --- Comment #12 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:08dfde5a30ca818715e6d2bc2f2b592f8a98af77 commit r14-3909-g08dfde5a30ca818715e6d2bc2f2b592f8a98af77 Author: Ian Lance Taylor Date: Tue Sep 12 09:11:48 2023 -0700 libgo: fix DejaGNU testsuite compiler when using build sysroot Patch from Thomas Schwinge. PR testsuite/109951 * configure.ac: 'AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)'. * Makefile.in: Regenerate. * configure: Likewise. * testsuite/Makefile.in: Likewise. * testsuite/lib/libgo.exp (libgo_init): If '--with-build-sysroot=[...]' was specified, use it for build-tree testing. * testsuite/libgo-test-support.exp.in (GOC_UNDER_TEST): Don't set. (SYSROOT_CFLAGS_FOR_TARGET): Set. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/527755
[Bug c/111394] Warning about uninitialized memory that is actually initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111394 --- Comment #1 from Andrew Pinski --- N could be -1 which then would access out of bounds .. I suspect if you add a check for n being negative in memoized_cut_rod the warning will go away and a security issue is solved too.
[Bug libstdc++/111390] 'make check-compile' target is not useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390 --- Comment #2 from Jonathan Wakely --- The fact nobody has tried to use it in 10+ years makes me think it's not all that useful.
[Bug jit/111396] New: Segfault when using -flto with libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396 Bug ID: 111396 Summary: Segfault when using -flto with libgccjit Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 55888 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55888=edit Reproducer for part of the bug Hi. There's a bug when compiling multiple times with -flto. I attached a reproducer for a part of the bug. (The other part of the bug should be fixed by https://gcc.gnu.org/pipermail/jit/2023q3/001668.html.)
[Bug middle-end/111395] New: RISC-V Vector Fortran: ICE in get_avl_or_vl_reg (vsetvl pass)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111395 Bug ID: 111395 Summary: RISC-V Vector Fortran: ICE in get_avl_or_vl_reg (vsetvl pass) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jeremy.bennett at embecosm dot com Target Milestone: --- Created attachment 55887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55887=edit Reproducer Found because of failure of SPEC CPU 2017 621_wrf_s to compile. This appears to be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11137, which is now resolved. Reproducer (test.f90): MODULE a REAL b CONTAINS SUBROUTINE c(d,KTE) REAL,DIMENSION(KTE) :: d,e,f,g REAL,DIMENSION(KTE) :: h i : DO j=1,b z=k DO l=m,n IF(o>=p)THEN IF(laf)THEN DO l=m,n d=h ENDDO ENDIF END SUBROUTINE c END MODULE a Compile with: riscv64-unknown-linux-gnu-gfortran -w -march=rv64gcv -mabi=lp64d -c -Ofast \ -ftree-vectorize --param=riscv-autovec-preference=scalable test.f90 Output: during RTL pass: vsetvl test.f90:37:18: 37 | END SUBROUTINE c | ^ internal compiler error: in get_avl_or_vl_reg, at config/riscv/riscv-vsetvl.cc:2297 0x9a24e5 riscv_vector::vector_insn_info::get_avl_or_vl_reg() const /home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:2297 0x9a24e5 riscv_vector::vector_insn_info::get_avl_or_vl_reg() const /home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:2271 0x16102f7 insert_vsetvl /home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:724 0x1610edd pass_vsetvl::commit_vsetvls() /home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:3615 0x1611191 pass_vsetvl::pre_vsetvl() /home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:3728 0x1611ed8 pass_vsetvl::lazy_vsetvl() /home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4360 0x1612031 pass_vsetvl::execute(function*) /home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4395 0x1612031 pass_vsetvl::execute(function*) /home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4376 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. System information -- Using built-in specs. COLLECT_GCC=riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/home/jeremy/gittrees/mustang/install/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /home/jeremy/gittrees/mustang/gcc/configure --target=riscv64-unknown-linux-gnu --prefix=/home/jeremy/gittrees/mustang/install --with-sysroot=/home/jeremy/gittrees/mustang/install/sysroot --with-pkgversion=g35f498d8dfc --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=/home/jeremy/gittrees/mustang/gcc --enable-multilib --with-abi=lp64d --with-arch=rv64gc --with-tune= --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2 -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medany' Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230912 (experimental) (g35f498d8dfc) Tool chain built with component commits: Repository SHA-1 hash (commit ID) -- -- gcc 35f498d8dfc8e579eaba2ff2d2b96769c632fd58 binutils-gdb 318d3bda5cad124bd11eebb0349d0f183ba625b1 glibc073edbdfabaad4786e974a451efe4b6b3f7a5a61
[Bug libstdc++/111390] 'make check-compile' target is not useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103324 CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- kinda related: bug 103324 (In reply to Jonathan Wakely from comment #0) > If we want to do compilation-only testing, I think it would be better to > modify the dejagnu procs so that "dg-do run" tests are treated as "dg-do > compile". Yes, I think this solution would be preferable to ripping it out entirely. Also, it would be useful if such a target were available tree-wide, rather than just for libstdc++.
[Bug other/111360] contrib/gcc_update: bad test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111360 --- Comment #5 from Eric Gallager --- (In reply to Jonathan Wakely from comment #4) > Fixed on trunk Cool, thanks. I'm wondering if it might be worthwhile to run shellcheck[1] on GCC's various shell scripts to catch similar mistakes? I just tried running it on all the ones in contrib/, but the output seemed rather noisy... [1]: https://www.shellcheck.net/
[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-09-12 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Can you provide the preprocessed source? Also provide the output of `gcc -v`?
[Bug c/111394] New: Warning about uninitialized memory that is actually initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111394
Bug ID: 111394
Summary: Warning about uninitialized memory that is actually
initialized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: aiya64bits at gmail dot com
Target Milestone: ---
#include
#include
int memoized_cut_rod_aux(const int p[], int n, int c, int r[]) {
if (r[n] >= 0)
return r[n];
int q = p[n - 1];
if (!n) {
q = 0;
} else {
for (int i = 1; i <= n / 2; ++i) {
const int v = p[i - 1] + memoized_cut_rod_aux(p, n - i, c, r) - c;
if (v > q)
q = v;
}
}
r[n] = q;
return q;
}
int memoized_cut_rod(const int p[], int n, int c) {
int result;
int *const r = malloc((n + 1) * sizeof(int));
if (!r) {
fprintf(stderr, "Out of memory.\n");
exit(1);
}
for (int i = 0; i < n + 1; ++i)
r[i] = -1;
result = memoized_cut_rod_aux(p, n, c, r);
free(r);
return result;
}
The above code when compiled with "gcc -Wall -O3 -o rod_cutting rod_cutting.c"
gives the following warning:
In function ‘memoized_cut_rod_aux’,
inlined from ‘memoized_cut_rod’ at rod_cutting.c:95:17:
rod_cutting.c:59:14: warning: ‘*r_30 + _122’ may be used uninitialized
[-Wmaybe-uninitialized]
59 | if (r[n] >= 0)
| ~^~~
But all the elements of r are initialized to -1 in the loop in
memoized_cut_rod. I got this warning with GCC 13.2.1 and then got the same
warning with the trunk branch.
[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
--- Comment #1 from AK ---
oot/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build# ninja clang
check-clang
[100/845] Building CXX object
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o
FAILED:
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o
/usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE
-D_LIBCPP_ENABLE_HARDENED_MODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build/tools/clang/lib/Serialization
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/lib/Serialization
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/include
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build/tools/clang/include
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build/include
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/llvm/include
-fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time
-fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long
-Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull
-Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move
-Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment
-Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual
-fno-strict-aliasing -fno-exceptions -funwind-tables -fno-rtti -UNDEBUG
-std=c++17 -MD -MT
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o
-MF
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o.d
-o
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o
-c
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/lib/Serialization/GlobalModuleIndex.cpp
In file included from
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/llvm/include/llvm/ADT/DenseMapInfo.h:20,
from
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/llvm/include/llvm/ADT/DenseMap.h:17,
from
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/include/clang/Serialization/GlobalModuleIndex.h:18,
from
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/lib/Serialization/GlobalModuleIndex.cpp:13:
/usr/include/c++/13/tuple: In instantiation of ‘struct std::_Tuple_impl<0,
clang::ModuleFileExtensionReader*,
std::default_delete >’:
/usr/include/c++/13/tuple:1232:11: required from ‘class
std::tuple >’
/usr/include/c++/13/bits/unique_ptr.h:232:27: required from ‘class
std::__uniq_ptr_impl >’
/usr/include/c++/13/bits/unique_ptr.h:239:12: required from ‘struct
std::__uniq_ptr_data, true, true>’
/usr/include/c++/13/bits/unique_ptr.h:283:33: required from ‘class
std::unique_ptr’
/usr/include/c++/13/bits/stl_vector.h:367:35: required from
‘std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp =
std::unique_ptr; _Alloc =
std::allocator >]’
/usr/include/c++/13/bits/stl_vector.h:528:7: required from here
/usr/include/c++/13/tuple:269:7: internal compiler error: Segmentation fault
269 | _M_head(_Tuple_impl& __t) noexcept { return _Base::_M_head(__t);
}
| ^~~
0x85d7c5 crash_signal
../../src/gcc/toplev.cc:314
0xa0d5e0 profile_count::operator==(profile_count const&) const
../../src/gcc/profile-count.h:865
0xa0d5e0 profile_count::apply_probability(profile_probability) const
../../src/gcc/profile-count.h:1104
0xa0d5e0 edge_def::count() const
../../src/gcc/basic-block.h:639
0xa0d5e0 eliminate_tail_call
../../src/gcc/tree-tailcall.cc:982
0xa0d5e0 optimize_tail_call
../../src/gcc/tree-tailcall.cc:1053
0xa0d5e0 tree_optimize_tail_calls_1
../../src/gcc/tree-tailcall.cc:1193
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See for instructions.
[Bug tree-optimization/111393] New: ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393 Bug ID: 111393 Summary: ICE: Segmentation fault src/gcc/toplev.cc:314 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hiraditya at msn dot com Target Milestone: --- riscv64-gnu-linux (version Debian 13.1) building llvm-project (GlobalModuleIndex.cpp) crashed with ICE. src/gcc/toplev.cc:314 profile_count::operator==(proile_count const&) const ../../src/gcc/profile-count.h:865 profile_count::apply_probability(proile_probability) const ../../src/gcc/profile-count.h:1104
[Bug target/98596] registers not reused on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596 Vineet Gupta changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||vineetg at gcc dot gnu.org --- Comment #3 from Vineet Gupta --- This is fixed with following commit (and will make it into gcc-14) commit b41d7eb0e14785ff0ad6e6922cbd4c880e680bf9 Author: Vineet Gupta Date: Mon Aug 7 13:45:29 2023 -0700 RISC-V: Enable Hoist to GCSE simple constants Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for hoist candidates. For a simple const (say 6 which needs seperate insn "LI 6") backend currently returns 0, causing Hoist to bail and elide GCSE. Note that constants requiring more than 1 insns to setup were working fine since riscv_rtx_costs () was returning non-zero (although that itself might need refining: see bugzilla 39). To keep testsuite parity, some V tests need updating which started failing in the new costing regime.
[Bug c++/111272] [13/14 Regression] Truncated error messages with -std=c++23 and -std=c++26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111272 --- Comment #4 from Paul Keir --- I believe P2448R2 would only allow the code, without the static_assert. Explicitly calling `test()`, `Jam::Jam()` and then `Jam::ft()` here would mean evaluating a non-constexpr function (i.e. `ft`). ft is *constexpr-suitable*, but still needs the `constexpr` specifier when it is constant evaluated.
[Bug c++/107198] [13/14 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107198 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- Fixed for 14, not backporting error-recovery fix.
[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f73d2d61a5926f42e9e5d771d23868787ef9d800 commit r14-3908-gf73d2d61a5926f42e9e5d771d23868787ef9d800 Author: Jason Merrill Date: Mon Sep 11 09:40:32 2023 -0400 c++: __integer_pack with class argument [PR111357] The argument might not already be an integer. PR c++/111357 gcc/cp/ChangeLog: * pt.cc (expand_integer_pack): Convert argument to int. gcc/testsuite/ChangeLog: * g++.dg/ext/integer-pack7.C: New test.
[Bug c++/107198] [13/14 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107198 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ea5abbb263315e558c876b50c9371b90ddd5e028 commit r14-3907-gea5abbb263315e558c876b50c9371b90ddd5e028 Author: Jason Merrill Date: Thu Sep 7 05:15:01 2023 -0400 c++: ICE with -fno-exceptions and array init [PR107198] The removed line no longer has an effect on anew5.C error recovery, and removing it improves error recovery for this testcase. PR c++/107198 gcc/cp/ChangeLog: * typeck2.cc (process_init_constructor_array): Use VEC_INIT_EXPR regardless of seen_error. gcc/testsuite/ChangeLog: * g++.dg/eh/no-exceptions1.C: New test.
[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256
--- Comment #16 from Jonathan Wakely ---
The std::format case looks like this:
namespace x
{
inline namespace v {
namespace detail {
template struct bar;
}
template
auto make(Arg);
template
class detail::bar {
bar() { }
template
friend auto x::make(Arg);
};
template
auto make(Arg)
{
detail::bar b;
return 1;
}
}
}
int main()
{
return x::make(1);
}
[Bug fortran/111271] gcc/fortran/trans-expr.cc:1134:8: warning: duplicated ‘if’ condition [-Wduplicated-cond]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111271 Paul Thomas changed: What|Removed |Added Last reconfirmed||2023-09-12 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Paul Thomas --- (In reply to David Binderman from comment #1) > git blame says > > 6c95fe9bc0 (Paul Thomas 2023-05-16 06:35:40 +0100 1087) if > (unlimited_poly) > > ... > > 6c95fe9bc0 (Paul Thomas 2023-05-16 06:35:40 +0100 1134) else > if (unlimited_poly) > > Adding Paul for their best advice. Hah! You got me. r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42 Thanks for pointing it out. The fix is easy enough. Paul
[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2021-12-13 00:00:00 |2023-9-12 --- Comment #15 from Jonathan Wakely --- This affects std::format now too.
[Bug tree-optimization/111383] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-5138-ge82c382971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111383 --- Comment #4 from Andrew Pinski --- I think iv-opts is changing: (d - 1625015511) + (d - 1625015341) into (2*d - N) which introduces an overflow ...
[Bug tree-optimization/111383] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-5138-ge82c382971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111383 --- Comment #3 from Andrew Pinski --- -fwrapv also allows causes the correct code to happen. The difference with/without -fwrapv is: _7 = _6 + -1625040257; if (_7 <= 6) vs if (_6 <= 1625040263)
[Bug c++/111392] Implement omp::decl attribute support for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111392 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-09-12 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 55886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55886=edit gcc14-pr111392.patch Rough untested initial WIP patch. Need to add testsuite support at least for it.
[Bug tree-optimization/111383] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-5138-ge82c382971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111383 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-09-12 --- Comment #2 from Andrew Pinski --- Note -fno-ivopts causes the wrong code to go away ... So it must be the IR that IV-opts produces causes the wrong code to happen.
[Bug c++/111392] New: Implement omp::decl attribute support for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111392
Bug ID: 111392
Summary: Implement omp::decl attribute support for C++
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The new syntax allows e.g.
void
foo ()
{
[[omp::decl (declare simd)]]
extern int bar (int);
bar (0);
[[omp::decl (threadprivate)]] static int a, b;
static int c [[omp::decl (threadprivate)]];
[[maybe_unused, omp::decl (threadprivate)]] static int d, e;
}
int f [[omp::decl (declare target, enter)]], g;
[[omp::decl (declare target)]] int h, i;
which will be very useful e.g. for threadprivate vars with ctors/dtors (which
we often reject in pragma syntax), or allocate directive.
[Bug tree-optimization/111285] vector ABSU is lowered incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111285 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-12 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > are you going to fix it? Yes I am going to fix this but maybe the week after next. I filed it so I would not lose track of what needs to be done.
[Bug middle-end/111391] New: RISC-V Vector: ICE in lra_split_hard_reg_for during reload pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111391
Bug ID: 111391
Summary: RISC-V Vector: ICE in lra_split_hard_reg_for during
reload pass
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremy.bennett at embecosm dot com
Target Milestone: ---
Created attachment 55885
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55885=edit
Reproducer
This looks like a reappearance of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111296. Found when investigating
failure of SPEC CPU 2017 600_perlbench_s to compile.
Reproducer (test.c)
int d ();
typedef struct
{
int b;
} c;
int
e (char *f, long g)
{
f += g;
while (g--)
*--f = d;
}
int
d (c * f)
{
while (h ())
switch (f->b)
case 'Q':
{
long a;
e (, sizeof (a));
i (a);
}
}
Compile with:
riscv64-unknown-linux-gnu-gcc -Wno-int-conversion -Wno-implicit-function \
-Wno-incompatible-pointer-types -Wno-implicit-function-declaration \
-march=rv64gcv -mabi=lp64d -c -Ofast -ftree-vectorize \
--param=riscv-autovec-preference=scalable test.c
Output is:
test.c: In function 'd':
test.c:25:1: error: unable to find a register to spill
25 | }
| ^
test.c:25:1: error: this is the insn:
(insn 49 48 58 5 (set (subreg:V8QI (reg:DI 158) 0)
(if_then_else:V8QI (unspec:V8BI [
(const_vector:V8BI [
(const_int 1 [0x1]) repeated x8
])
(const_int 8 [0x8])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(vec_duplicate:V8QI (reg:QI 155))
(unspec:V8QI [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))) "test.c":23:2 1450 {*pred_broadcastv8qi}
(expr_list:REG_DEAD (reg:QI 155)
(expr_list:REG_DEAD (reg:SI 67 vtype)
(expr_list:REG_DEAD (reg:SI 66 vl)
(expr_list:REG_DEAD (reg:SI 0 zero)
(nil))
during RTL pass: reload
test.c:25:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1861
0x904fbb _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/jeremy/gittrees/mustang/gcc/gcc/rtl-error.cc:108
0xf35590 lra_split_hard_reg_for()
/home/jeremy/gittrees/mustang/gcc/gcc/lra-assigns.cc:1861
0xf2f205 lra(_IO_FILE*)
/home/jeremy/gittrees/mustang/gcc/gcc/lra.cc:2495
0xee6519 do_reload
/home/jeremy/gittrees/mustang/gcc/gcc/ira.cc:5970
0xee6519 execute
/home/jeremy/gittrees/mustang/gcc/gcc/ira.cc:6156
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
System information
--
Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/jeremy/gittrees/mustang/install/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /home/jeremy/gittrees/mustang/gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/home/jeremy/gittrees/mustang/install
--with-sysroot=/home/jeremy/gittrees/mustang/install/sysroot
--with-pkgversion=g35f498d8dfc --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=/home/jeremy/gittrees/mustang/gcc --enable-multilib --with-abi=lp64d
--with-arch=rv64gc --with-tune= --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
-mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medany'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230912 (experimental) (g35f498d8dfc)
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 --- Comment #29 from JuzheZhong --- (In reply to JuzheZhong from comment #27) > (In reply to rsand...@gcc.gnu.org from comment #26) > > But this is how technical debt builds up. We'd be making a change > > that doesn't match the type system, and that we know to be wrong > > in principle. And we'd be making it with no realistic prospect > > that it will be cleaned up later. > > > > > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments > > > type are compatible for COND_LEN_xxx in the future (Currently, it's > > > obviously > > > not checking this). Then, it will cause ICE. > > > > Yeah. But like I say, I don't think that's the most worrying > > scenario. For me the most worrying scenario is that a match.pd > > fold will say that: > > > > (cond_len all-false a b c len bias) > > > > folds to c without checking whether c is compatible with the return > > type. And IMO it shouldn't need to check that the type is compatible. > > > > If a rule like that triggers after this patch goes in, the pressure > > will be to continue to support the hack and add workarounds for it. > > Thanks Richard a lot. > > But I don't think we need to worry about the fold COND_LEN into > the ELSE_VALUE. > > Let's back to the previous comments you gave for COND_LEN_xxx: > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html > > Following your suggestions, I support cond_len_xxx by following your (1): > > (1) RVV implements cond_* optabs as expanders. RVV therefore supports > both IFN_COND_ADD and IFN_COND_LEN_ADD. No dummy length arguments > are needed at the gimple level. > > I use this approach to support COND_LEN_xxx since last time you have > mentioned > we will need more work in GIMPLE FOLD and other things. > > To simplify the implementation of COND_LEN_xxx. We support both COND_XXX and > COND_LEN_XXX in RISC-V backend. > > We don't have COND_LEN_xxx with dummy length (All dummy length case will go > back to COND_XXX). So we forbid the case that FOLD COND_LEN_xxx into ELSE > value since COND_LEN_xxx is built always with a meaning length. > > The only GIMPLE FOLD optimization of COND_LEN_XXX is operations fusion, > meaning > FOLD cond_len_mult + cond_len_add into ==> cond_len_fma. That's what I am > worry about. But currently it works fine (I have tests to test that). Sorry. I am wrong about the comments. The COND_LEN_xxx for GIMPLE FOLD should be like: NEG + COND_LEN_FMA -> COND_LEN_FNMA etc operations fusion. And since the length is never a dummy length (we always use COND_XXX to build for dummy length situation), we forbid COND_LEN_xxx into any argument in FOLD.
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 --- Comment #28 from JuzheZhong --- (In reply to JuzheZhong from comment #27) > (In reply to rsand...@gcc.gnu.org from comment #26) > > But this is how technical debt builds up. We'd be making a change > > that doesn't match the type system, and that we know to be wrong > > in principle. And we'd be making it with no realistic prospect > > that it will be cleaned up later. > > > > > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments > > > type are compatible for COND_LEN_xxx in the future (Currently, it's > > > obviously > > > not checking this). Then, it will cause ICE. > > > > Yeah. But like I say, I don't think that's the most worrying > > scenario. For me the most worrying scenario is that a match.pd > > fold will say that: > > > > (cond_len all-false a b c len bias) > > > > folds to c without checking whether c is compatible with the return > > type. And IMO it shouldn't need to check that the type is compatible. > > > > If a rule like that triggers after this patch goes in, the pressure > > will be to continue to support the hack and add workarounds for it. > > Thanks Richard a lot. > > But I don't think we need to worry about the fold COND_LEN into > the ELSE_VALUE. > > Let's back to the previous comments you gave for COND_LEN_xxx: > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html > > Following your suggestions, I support cond_len_xxx by following your (1): > > (1) RVV implements cond_* optabs as expanders. RVV therefore supports > both IFN_COND_ADD and IFN_COND_LEN_ADD. No dummy length arguments > are needed at the gimple level. > > I use this approach to support COND_LEN_xxx since last time you have > mentioned > we will need more work in GIMPLE FOLD and other things. > > To simplify the implementation of COND_LEN_xxx. We support both COND_XXX and > COND_LEN_XXX in RISC-V backend. > > We don't have COND_LEN_xxx with dummy length (All dummy length case will go > back to COND_XXX). So we forbid the case that FOLD COND_LEN_xxx into ELSE > value since COND_LEN_xxx is built always with a meaning length. > > The only GIMPLE FOLD optimization of COND_LEN_XXX is operations fusion, > meaning > FOLD cond_len_mult + cond_len_add into ==> cond_len_fma. That's what I am > worry about. But currently it works fine (I have tests to test that). Moreover, Maybe we will need to worry about COND_XXX into ELSE_VALUE if I return scalar 0 in the else targethook. However, for RVV, we always use COND_LEN_xxx in the loop vectorizer which may build with the argument from the ELSE_VALUE targethook. The only situation we will use COND_XXX is the UNCOND_OP + VEC_COND_EXPR -> COND_XXX in match.pd which always has a real ELSE VALUE. After these analysis, it seems that there is no risks? Not sure whether I am correct or not.
[Bug libstdc++/111390] New: 'make check-compile' target is not useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390 Bug ID: 111390 Summary: 'make check-compile' target is not useful Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- This makefile target does compilation-only testing, to check that tests can be built. But there's no parallelism, so it takes ages. Worse, it ignores dejagnu directives so just runs everything with a default set of options, including the implicit -std=gnu++17 This means that all C++20 and later tests fail. And any XFAIL tests with dg-error directives "fail" noisily. I'm not sure it is useful to keep it. If we want to do compilation-only testing, I think it would be better to modify the dejagnu procs so that "do-do run" tests are treated as "dg-do compile".
[Bug tree-optimization/111389] [14 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111389 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Summary|ICE in |[14 Regression] ICE in |check_loop_closed_ssa_def, |check_loop_closed_ssa_def, |at |at |tree-ssa-loop-manip.cc:647 |tree-ssa-loop-manip.cc:647
[Bug middle-end/111375] RISC-V vector Fortran: SEGV ICE during get_avl_or_vl_reg (vsetvl pass)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111375 Jeremy Bennett changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeremy Bennett --- Thanks @JuzheZhong, I have tried again with the latest GCC and the problem has gone away. This can now be marked as fixed.
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 --- Comment #27 from JuzheZhong --- (In reply to rsand...@gcc.gnu.org from comment #26) > But this is how technical debt builds up. We'd be making a change > that doesn't match the type system, and that we know to be wrong > in principle. And we'd be making it with no realistic prospect > that it will be cleaned up later. > > > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments > > type are compatible for COND_LEN_xxx in the future (Currently, it's > > obviously > > not checking this). Then, it will cause ICE. > > Yeah. But like I say, I don't think that's the most worrying > scenario. For me the most worrying scenario is that a match.pd > fold will say that: > > (cond_len all-false a b c len bias) > > folds to c without checking whether c is compatible with the return > type. And IMO it shouldn't need to check that the type is compatible. > > If a rule like that triggers after this patch goes in, the pressure > will be to continue to support the hack and add workarounds for it. Thanks Richard a lot. But I don't think we need to worry about the fold COND_LEN into the ELSE_VALUE. Let's back to the previous comments you gave for COND_LEN_xxx: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html Following your suggestions, I support cond_len_xxx by following your (1): (1) RVV implements cond_* optabs as expanders. RVV therefore supports both IFN_COND_ADD and IFN_COND_LEN_ADD. No dummy length arguments are needed at the gimple level. I use this approach to support COND_LEN_xxx since last time you have mentioned we will need more work in GIMPLE FOLD and other things. To simplify the implementation of COND_LEN_xxx. We support both COND_XXX and COND_LEN_XXX in RISC-V backend. We don't have COND_LEN_xxx with dummy length (All dummy length case will go back to COND_XXX). So we forbid the case that FOLD COND_LEN_xxx into ELSE value since COND_LEN_xxx is built always with a meaning length. The only GIMPLE FOLD optimization of COND_LEN_XXX is operations fusion, meaning FOLD cond_len_mult + cond_len_add into ==> cond_len_fma. That's what I am worry about. But currently it works fine (I have tests to test that).
[Bug tree-optimization/111389] New: ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111389
Bug ID: 111389
Summary: ICE in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
gcc at -O2 crashes on the following testcase.
Bisected to r14-301-gf2d6beb7a4d
Compiler explorer: https://godbolt.org/z/o98qrd5nr
$cat a.c
int *a;
char b;
int d;
int e(int f) {
int c = 0;
for (; f > 1; c++)
f >>= 1;
return c;
}
void g() {
for (;;) {
for (; d; d++)
;
b = 0;
for (; e(92) - 6 + b; b = b + 8)
*a = 0;
}
}
int main() {}
$ gcc -O0 a.c && ./a.out
$ gcc -O2 a.c
during GIMPLE pass: ch_vect
a.c: In function ‘g’:
a.c:10:6: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:645
10 | void g() {
| ^
0x7f8ffe5f1082 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 --- Comment #11 from Jonathan Wakely --- Right. The _M_valptr() function compiles to something like: return (_Value*)((char*)this + offsetof(_Hash_node_value_base, _M_storage); In GCC 10, the offsetof expression was non-zero, specifically it was sizeof(_Hash_node_base). So the _M_valptr() function emitted by GCC 10 expected to access the storage member at a non-zero offset to the 'this' pointer pointing to the _Hash_node_value_base subobject. In GCC 11+ the offsetof expression is zero, so the definition of _M_valptr() emitted by GCC 11 does something different. That's an ABI break. If the linker chooses the GCC 10 definition of the function, but the function gets called with a 'this' pointer from GCC 11 code, it will apply the non-zero offset when it shouldn't (and vice versa).
[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin or fails on x86_64-linux-gnu with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:724e9b12ce2b06cceeb59255a5eb0f31b0a7af65 commit r12-9874-g724e9b12ce2b06cceeb59255a5eb0f31b0a7af65 Author: Uros Bizjak Date: Mon Sep 11 20:56:42 2023 +0200 i386: Handle CONST_WIDE_INT in output_pic_addr_const [PR111340] PR target/111340 gcc/ChangeLog: * config/i386/i386.cc (output_pic_addr_const): Handle CONST_WIDE_INT. Call output_addr_const for CASE_CONST_SCALAR_INT. gcc/testsuite/ChangeLog: * gcc.target/i386/pr111340.c: New test.
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 --- Comment #26 from rsandifo at gcc dot gnu.org --- But this is how technical debt builds up. We'd be making a change that doesn't match the type system, and that we know to be wrong in principle. And we'd be making it with no realistic prospect that it will be cleaned up later. > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments > type are compatible for COND_LEN_xxx in the future (Currently, it's obviously > not checking this). Then, it will cause ICE. Yeah. But like I say, I don't think that's the most worrying scenario. For me the most worrying scenario is that a match.pd fold will say that: (cond_len all-false a b c len bias) folds to c without checking whether c is compatible with the return type. And IMO it shouldn't need to check that the type is compatible. If a rule like that triggers after this patch goes in, the pressure will be to continue to support the hack and add workarounds for it.
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 John Drouhard changed: What|Removed |Added CC||john at drouhard dot dev --- Comment #10 from John Drouhard --- (In reply to frs.dumont from comment #9) > To be honest before that report I thought that preserving abi was just a > matter of preserving memory layout of types. I had no idea that member > methods mattered ! (I was the original reporter of this to TC) I think the specific issue here is that the member function `_M_valptr()` returns the address of the storage data member, and that _function_ is used in a construct call elsewhere to point to the address where a new object should be placed. It returns the address based on the offset from the beginning of the object which changed when the base class (which had its own data members) was removed. So, if the function isn't inlined, the symbol that's actually loaded by the dynamic linker during runtime will return a potentially bogus address for that data member if the definition of that function came from a library compiled with the other version.
[Bug tree-optimization/111364] `MAX_EXPR <= a` is not optimized to `a >= b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111364 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/630075.html --- Comment #5 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630075.html
[Bug rtl-optimization/111384] missed optimization: GCC adds extra any extend when storing subreg#0 multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111384 --- Comment #3 from Andrew Pinski --- I thought I saw/reported a similar bug but I can't find it right now.
[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4289f6ceefe74ea46e792692448c06197ac20c86 commit r14-3902-g4289f6ceefe74ea46e792692448c06197ac20c86 Author: Patrick Palka Date: Tue Sep 12 11:23:12 2023 -0400 libstdc++: Fix std::bind_front perfect forwarding [PR111327] In order to properly implement a perfect forwarding call wrapper (without C++23 deducing 'this') we need a total of 8 operator() overloads, 4 enabled ones and 4 deleted ones, i.e. two for each const/ref qual pair, as described in section 5.5 of P0847R6. Otherwise the wrapper may not do the right thing if the underlying function object has a deleted const/ref-qualified operator() overload. This patch fixes this issue in std::bind_front. PR libstdc++/111327 libstdc++-v3/ChangeLog: * include/std/functional (_Bind_front::operator()): Add deleted fallback overloads for each const/ref qualifier pair. Give the enabled overloads dummy constraints to make each one more specialized than the corresponding deleted overload. * testsuite/20_util/function_objects/bind_front/111327.cc: New test.
[Bug rtl-optimization/111384] missed optimization: GCC adds extra any extend when storing subreg#0 multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111384 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:52f65d17c85fa513887a3bb31e3c3c329d9ace58 commit r14-3903-g52f65d17c85fa513887a3bb31e3c3c329d9ace58 Author: Patrick Palka Date: Tue Sep 12 11:26:50 2023 -0400 libstdc++: Fix std::not_fn perfect forwarding [PR111327] The previous patch fixed perfect forwarding in std::bind_front. This patch fixes the same issue in std::not_fn. PR libstdc++/111327 libstdc++-v3/ChangeLog: * include/std/functional (_GLIBCXX_NOT_FN_CALL_OP): Also define a deleted fallback operator() overload. Constrain both the enabled and deleted overloads accordingly. * testsuite/20_util/function_objects/not_fn/111327.cc: New test.
[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f1e87aee5b7023fb4f5791c6869db705e18c2705 commit r14-3901-gf1e87aee5b7023fb4f5791c6869db705e18c2705 Author: Patrick Palka Date: Tue Sep 12 11:23:08 2023 -0400 libstdc++: Remove std::bind_front specialization for no bound args The specialization used by std::bind_front when there are no bound args (added by r13-4214-gcbd05ca5ab1231) seems to be mostly obsoleted by r13-5033-ge2eab3c4edb6aa which added [[no_unique_address]] to the main template's data members. What's left to consider is the compile time advantage of the specialization, which doesn't seem huge since it just avoids using tuple<> (which is an explicit specialization anyway) and expanding some pack expansions with an empty argument pack. So this patch removes this specialization; this means we have one less spot to fix the PR libstdc++/111327 perfect forwarding bug. libstdc++-v3/ChangeLog: * include/std/functional (_Bind_front0): Remove. (_Bind_front_t): Adjust.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #13 from Jason Merrill --- (In reply to Jakub Jelinek from comment #12) > BTW, shall size() and data() be manifestly constant-evaluated? > I think it doesn't satisfy any of the https://eel.is/c++draft/expr.const#19 > bullets (unlike first static_assert argument). Good point, I think we're missing some wording to make that all manifestly constant-evaluated; it absolutely should be. (In reply to Jakub Jelinek from comment #10) > Then it should be a warning rather than error IMHO. Because it isn't > invalid, just likely unintended. Agreed.
[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Last reconfirmed||2023-09-12 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Summary|std::bind_front doesn't |std::bind_front (and |perfectly forward according |std::not_fn) doesn't always |to value category of the|perfectly forward according |call wrapper object |to value category of the ||call wrapper object
[Bug middle-end/111378] Missed optimization for comparing with exact_log2 constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111378 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Note I thought I saw another bug requesting the same thing but I could not > find it. PR 85234 is mostly requesting the opposite way though ...
[Bug middle-end/111378] Missed optimization for comparing with exact_log2 constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111378 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- Note I thought I saw another bug requesting the same thing but I could not find it.
[Bug tree-optimization/107881] (a <= b) == (b >= a) should be optimized to (a == b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107881 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #18 from Andrew Pinski --- Fixed.
[Bug tree-optimization/107880] bool tautology missed optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107880 Bug 107880 depends on bug 107881, which changed state. Bug 107881 Summary: (a <= b) == (b >= a) should be optimized to (a == b) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107881 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/107887] (bool0 > bool1) | bool1 is not optimized to bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107887 Bug 107887 depends on bug 107881, which changed state. Bug 107881 Summary: (a <= b) == (b >= a) should be optimized to (a == b) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107881 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/107881] (a <= b) == (b >= a) should be optimized to (a == b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107881 --- Comment #17 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:895e476f64c308dfdbf49693d0b1166c0b7733de commit r14-3881-g895e476f64c308dfdbf49693d0b1166c0b7733de Author: Andrew Pinski Date: Mon Sep 11 15:35:59 2023 -0700 MATCH: Simplify (a CMP1 b) ^ (a CMP2 b) This adds the missing optimizations here. Note we don't need to match where CMP1 and CMP2 are complements of each other as that is already handled elsewhere. I added a new executable testcase to make sure we optimize it correctly as I had originally messed up one of the entries for the resulting comparison to make sure they were 100% correct. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/107881 gcc/ChangeLog: * match.pd (`(a CMP1 b) ^ (a CMP2 b)`): New pattern. (`(a CMP1 b) == (a CMP2 b)`): New pattern. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/pr107881-1.c: New test. * gcc.dg/tree-ssa/cmpeq-4.c: New test. * gcc.dg/tree-ssa/cmpxor-1.c: New test.
[Bug tree-optimization/111388] std:.get_if variant, unnecessary branch when outside of if statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111388 --- Comment #2 from Andrew Pinski --- Adding: ``` if (ab.index()>=2) __builtin_unreachable(); ``` to operator-> Also fixes the issue. C++23 would be: [[assume(ab.index()<2)]]; (Except that does not optimize currently).
[Bug tree-optimization/111388] std:.get_if variant, unnecessary branch when outside of if statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111388 --- Comment #1 from Andrew Pinski --- Note variant can still hold neither ... You might need to add a check for valueless_by_exception here. But variant::index could be improved to say the only values that are valid is [0,N],[-1]. and that will remove the check. Note clang even produces the similar code even with libc++: xorl%eax, %eax cmpl$2, 8(%rdi) cmovaeq %rax, %rdi Just GCC isolates the null pointer access.
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 --- Comment #25 from JuzheZhong --- (In reply to rsand...@gcc.gnu.org from comment #24) > Heh, nice hack. :) But I guess this shows that the type checking of > internal functions isn't as strong it should be. > > IMO it's wrong to pass a scalar else value to a vector operation. > Even if it happens to work now, it's likely to fail in the future. > E.g. I think match.pd fold rules should be entitled to assume > (without checking) that all data operands to a COND_* function > have compatible types. > > If we want an undefined operand value, I think we'll need add to > add one that specifically has that meaning. Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments type are compatible for COND_LEN_xxx in the future (Currently, it's obviously not checking this). Then, it will cause ICE. Adding undefine value will be the optimal solution. However, it will be a big project: 1. Add undefine in tree.def 2. Add undefine in RTL representation. 3. Adjust each PASS to handle undefine value. 4. Adjust register allocation to handle undefine value. ... etc I can image it will be long term project to support undefine. But we want to fix this inferior codegen of RVV currently since I have tested various benchmark, the ELSE value hurt the performance so much so that I want to use current infrastructure GCC to fix this issue.
[Bug target/111317] RISC-V: Incorrect COST model for RVV conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111317 --- Comment #1 from Robin Dapp --- I think the default cost model is not too bad for these simple cases. Our emitted instructions match gimple pretty well. The thing we don't model is vsetvl. We could ignore it under the assumption that it is going to be rather cheap on most uarchs. Something that needs to be fixed is the general costing used for length-masking: /* Each may need two MINs and one MINUS to update lengths in body for next iteration. */ if (need_iterate_p) body_stmts += 3 * num_vectors; We don't actually need min with vsetvl (they are our mins) so this would need to be adjusted down, provided vsetvl is cheap. This is the scalar baseline: .L3: lw a5,0(a0) sd a5,0(a1) addia0,a0,4 addia1,a1,8 bne a4,a0,.L3 While this is what zvl128b would emit: .L3: vsetvli a5,a2,e8,mf8,ta,ma vle32.v v2,0(a0) vsetvli a4,zero,e64,m1,ta,ma vsext.vf2 v1,v2 vsetvli zero,a2,e64,m1,ta,ma vse64.v v1,0(a1) sllia4,a5,2 add a0,a0,a4 sllia4,a5,3 add a1,a1,a4 sub a2,a2,a5 bne a2,zero,.L3 With a vectorization factor of 2 (might effectively be higher of course but possibly unknown at compile time) I'm not sure vectorization is always a win and the costs actually reflect that. If we disregard vsetvl for now we have 8 instructions in the vectorized loop and 2 * 4 instructions in the scalar loop for the same amount of data. Factoring in the vsetvls I'd say it's worse. Once we statically know the VF is higher, we will vectorize.
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 --- Comment #24 from rsandifo at gcc dot gnu.org --- Heh, nice hack. :) But I guess this shows that the type checking of internal functions isn't as strong it should be. IMO it's wrong to pass a scalar else value to a vector operation. Even if it happens to work now, it's likely to fail in the future. E.g. I think match.pd fold rules should be entitled to assume (without checking) that all data operands to a COND_* function have compatible types. If we want an undefined operand value, I think we'll need add to add one that specifically has that meaning.
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #13 from rsandifo at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #6) > I wonder whether SVE/GCN have those. Just to answer this: yeah, SVE does have both vector and predicate SEL (vcond_mask). So the fold is useful there.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #12 from Jakub Jelinek --- BTW, shall size() and data() be manifestly constant-evaluated? I think it doesn't satisfy any of the https://eel.is/c++draft/expr.const#19 bullets (unlike first static_assert argument).
[Bug libstdc++/111327] std::bind_front doesn't perfectly forward according to value category of the call wrapper object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327 --- Comment #1 from Jonathan Wakely --- We might want to look into bind too: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0826r0.html#3.-implementation-experience
[Bug rtl-optimization/111384] missed optimization: GCC adds extra any extend when storing subreg#0 multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111384 --- Comment #2 from Siarhei Volkau --- Well what the godbolt says with -O2 -fomit-frame-pointer. ARM: uxthr0, r0 @ << zero extend strhr0, [r1] strhr0, [r2] bx lr ARM64: and w0, w0, 65535 @ << zero extend strhw0, [x1] strhw0, [x2] ret MIPS64: andi$4,$4,0x@ << zero extend sh $4,0($5) jr $31 sh $4,0($6) MRISC32: shufr1, r1, #2888 @ << zero extend sth r1, [r2] sth r1, [r3] ret RISC-V: sllia0,a0,16@ << zero extend srlia0,a0,16@ << zero extend sh a0,0(a1) sh a0,0(a2) ret RISC-V (64-bit): sllia0,a0,48@ << zero extend srlia0,a0,48@ << zero extend sh a0,0(a1) sh a0,0(a2) ret Xtensa ESP32: entry sp, 32 extui a2, a2, 0, 16 @ << zero extend s16ia2, a3, 0 s16ia2, a4, 0 retw.n Loongarch64: bstrpick.w $r4,$r4,15,0 @ << zero extend st.h$r4,$r5,0 st.h$r4,$r6,0 jr $r1 MIPS: andi$4,$4,0x@ << zero extend sh $4,0($5) jr $31 sh $4,0($6) SH: extu.w r4,r4 @ << zero extend mov.w r4,@r5 rts mov.w r4,@r6 Other available at godbolt (x86-64/Power/Power64/s390) unaffected.
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #12 from Robin Dapp --- Yes, as far as I know. I would also go ahead and merge the test suite patch now as there is already a v2 fix posted. Even if it's not the correct one it will be done soon so we should not let that block enabling the test suite.
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #11 from JuzheZhong --- (In reply to Robin Dapp from comment #10) > I would be OK with the riscv implementation, then we don't need to touch > isel. Maybe a future vector extension will also help us here so we could > just switch the implementation then. Thank. I will send a patch for it. I guess the last issue related to testsuite is the incorrect COND_LEN_XXX gimple fold?
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #10 from Robin Dapp --- I would be OK with the riscv implementation, then we don't need to touch isel. Maybe a future vector extension will also help us here so we could just switch the implementation then.
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #9 from JuzheZhong --- So, should we support this pattern in RISC-V backend ? Or adjust gimple-isel to generate these 4 STMTs naturally?
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #8 from Robin Dapp --- Yes, I doubt we would get much below 4 instructions with riscv specifics. A quick grep yesterday didn't reveal any aarch64 or gcn patterns for those (as long as they are not hidden behind some pattern replacement). But aarch64 doesn't encounter this situation anyway as we fold differently before.
[Bug tree-optimization/111387] ICE on valid code at -O2 and -O3: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111387 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2023-09-12 Keywords||ice-on-valid-code Version|unknown |14.0 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener --- I will have a look, probably latent on the branch(es). On 13 we have a conversion in the way: [local count: 91268056]: # k_9 = PHI <0(6), k_17(4)> # l_10 = PHI k.2_4 = (unsigned int) k_9; c.a = k.2_4; c.b = l_10;
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
--- Comment #7 from JuzheZhong ---
(In reply to rguent...@suse.de from comment #6)
> On Tue, 12 Sep 2023, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
> >
> > --- Comment #5 from JuzheZhong ---
> > Oh. I see.
> >
> >
> > (define_expand "@vcond_mask_"
> > [(match_operand:VB 0 "register_operand")
> >(match_operand:VB 3 "register_operand")
> >(match_operand:VB 1 "nonmemory_operand")
> >(match_operand:VB 2 "register_operand")]
> > "TARGET_VECTOR"
> > {
> >printf ("vcond_mask\n");
> > })
> >
> > I implemented this pattern which can address this issue
> >
> > Note that VB is VECTR_BOOL...
> >
> > So, this is a more reasonable way to do. Is that right?
>
> Ah, I suppose ISEL could special-case VECTOR_BOOLEAN_P COND_EXPR
> to expand to bitwise ops - it already does this, but only for
> non-vector-mode masks:
>
> /* Lower mask typed, non-vector mode VEC_COND_EXPRs to bitwise
> operations.
> Those can end up generated by folding and at least for integer mode
> masks
> we cannot expect vcond expanders to exist. We lower a ? b : c
> to (b & a) | (c & ~a). */
> if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (lhs))
> && !VECTOR_MODE_P (mode))
> {
> gcc_assert (types_compatible_p (TREE_TYPE (op0), TREE_TYPE (op1)));
> gimple_seq stmts = NULL;
> tree type = TREE_TYPE (lhs);
> location_t loc = gimple_location (stmt);
> tree tem0 = gimple_build (, loc, BIT_AND_EXPR, type, op1,
> op0);
> tree tem1 = gimple_build (, loc, BIT_NOT_EXPR, type, op0);
> tree tem2 = gimple_build (, loc, BIT_AND_EXPR, type, op2,
> tem1);
> tree tem3 = gimple_build (, loc, BIT_IOR_EXPR, type, tem0,
> tem2);
> gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
> return gimple_build_assign (lhs, tem3);
> }
>
> that could be a viable expansion strathegy when the rest fails,
> but as you can see we need four stmts for this. If you can
> think of a smarter, maybe even single-instruction, way for riscv
> then yes, handling the above pattern looks good.
>
> I wonder whether SVE/GCN have those.
I have supported this pattern but also need 4 instructions:
(define_expand "@vcond_mask_"
[(match_operand:VB 0 "register_operand")
(match_operand:VB 1 "register_operand")
(match_operand:VB 2 "register_operand")
(match_operand:VB 3 "register_operand")]
"TARGET_VECTOR"
{
/* mask1 = operands[3] & operands[1]. */
rtx mask1 = expand_binop (mode, and_optab, operands[1],
operands[3], NULL_RTX, 0,
OPTAB_DIRECT);
/* mask2 = ~operands[3] & operands[2]. */
rtx inverse = expand_unop (mode, one_cmpl_optab, operands[3],
NULL_RTX,
OPTAB_DIRECT);
rtx mask2 = expand_binop (mode, and_optab, operands[2],
inverse, NULL_RTX, 0,
OPTAB_DIRECT);
/* result = mask1 | mask2. */
rtx result = expand_binop (mode, ior_optab, mask1,
mask2, NULL_RTX, 0,
OPTAB_DIRECT);
emit_move_insn (operands[0], result);
DONE;
})
[Bug rtl-optimization/111384] missed optimization: GCC adds extra any extend when storing subreg#0 multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111384 Richard Biener changed: What|Removed |Added Version|unknown |14.0 Component|middle-end |rtl-optimization --- Comment #1 from Richard Biener --- can you name one of many?
[Bug tree-optimization/111383] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-5138-ge82c382971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111383 Richard Biener changed: What|Removed |Added Keywords||wrong-code Summary|Wrong code at -Os on|[12/13/14 Regression] Wrong |x86_64-linux-gnu since |code at -Os on |r12-5138-ge82c382971|x86_64-linux-gnu since ||r12-5138-ge82c382971 Target Milestone|--- |12.4
[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
--- Comment #6 from rguenther at suse dot de ---
On Tue, 12 Sep 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
>
> --- Comment #5 from JuzheZhong ---
> Oh. I see.
>
>
> (define_expand "@vcond_mask_"
> [(match_operand:VB 0 "register_operand")
>(match_operand:VB 3 "register_operand")
>(match_operand:VB 1 "nonmemory_operand")
>(match_operand:VB 2 "register_operand")]
> "TARGET_VECTOR"
> {
>printf ("vcond_mask\n");
> })
>
> I implemented this pattern which can address this issue
>
> Note that VB is VECTR_BOOL...
>
> So, this is a more reasonable way to do. Is that right?
Ah, I suppose ISEL could special-case VECTOR_BOOLEAN_P COND_EXPR
to expand to bitwise ops - it already does this, but only for
non-vector-mode masks:
/* Lower mask typed, non-vector mode VEC_COND_EXPRs to bitwise
operations.
Those can end up generated by folding and at least for integer mode
masks
we cannot expect vcond expanders to exist. We lower a ? b : c
to (b & a) | (c & ~a). */
if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (lhs))
&& !VECTOR_MODE_P (mode))
{
gcc_assert (types_compatible_p (TREE_TYPE (op0), TREE_TYPE (op1)));
gimple_seq stmts = NULL;
tree type = TREE_TYPE (lhs);
location_t loc = gimple_location (stmt);
tree tem0 = gimple_build (, loc, BIT_AND_EXPR, type, op1,
op0);
tree tem1 = gimple_build (, loc, BIT_NOT_EXPR, type, op0);
tree tem2 = gimple_build (, loc, BIT_AND_EXPR, type, op2,
tem1);
tree tem3 = gimple_build (, loc, BIT_IOR_EXPR, type, tem0,
tem2);
gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
return gimple_build_assign (lhs, tem3);
}
that could be a viable expansion strathegy when the rest fails,
but as you can see we need four stmts for this. If you can
think of a smarter, maybe even single-instruction, way for riscv
then yes, handling the above pattern looks good.
I wonder whether SVE/GCN have those.
[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #16 from Michael Matz --- I think -falign-functions=N should simply override any consideration of -Os or coldness or suchlike. Clearly the explicit use of such option is by some intention of the compiler user, and as the compiler can't know _what_ exactly is intended it needs to assume that the alignment needs to hold for all functions. Richis proposal would of course work, but seems a rather awkward workaround for behaviour that actually is surprising.
[Bug target/111370] On Aarch64 4% 511.povray_r regression between g:6cd85273071b5f13 (2023-08-23 00:17) and g:e1f096a3cc96c719 (2023-08-25 22:34)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111370 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org Last reconfirmed||2023-9-12 --- Comment #1 from Tamar Christina --- Ok, I can reproduce this with the generic cost model on Neoverse N1 hardware. The generic cost model is based on a 10+ years old cpu and is no longer fit for modern CPUs. We are planning to replace it this GCC release so the regression should go away then. I've tested with -mcpu=neoverse-n1 and it does go away and gives a much better score.
[Bug target/111381] RISC-V: missed autovec MULH for signed * unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111381 Richard Biener changed: What|Removed |Added Blocks||53947 --- Comment #1 from Richard Biener --- I think the only relevant difference is the result type difference, uint32_t vs int32_t since (int64_t)a[i] * (uint64_t)b[i] should get promoted to a uint64_t multiplication. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
