[Bug fortran/95196] Assumed-rank incorrect array bounds inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95196 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED CC||sandra at gcc dot gnu.org --- Comment #3 from sandra at gcc dot gnu.org --- I confirmed that the testcase now works, and added it to the testsuite. Closing this issue now.
[Bug fortran/95196] Assumed-rank incorrect array bounds inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95196 --- Comment #2 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:693abdb66aba25f3fb25c3cd8d65dbb64ecd37a0 commit r12-4638-g693abdb66aba25f3fb25c3cd8d65dbb64ecd37a0 Author: Sandra Loosemore Date: Fri Oct 22 17:22:00 2021 -0700 Add testcase for PR fortran/95196 2021-10-22 José Rui Faustino de Sousa Sandra Loosemore gcc/testsuite/ PR fortran/95196 * gfortran.dg/PR95196.f90: New.
[Bug target/102907] aarch64/shrn-combine-[123].c fail with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102907 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-10-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93619, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77635 --- Comment #1 from Andrew Pinski --- The whole testsuite is broken when using either -mcpu=* or -march=* (or defaulting with --with-cpu= or --with-arch=). Confirmed.
[Bug target/102907] New: aarch64/shrn-combine-[123].c fail with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102907 Bug ID: 102907 Summary: aarch64/shrn-combine-[123].c fail with SVE Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Hi Tamar, I have noticed that the new tests shrn-combine-[123].c fail when running the tests with -march=armv8.3-a+sve: PASS: gcc.target/aarch64/shrn-combine-1.c (test for excess errors) gcc.target/aarch64/shrn-combine-1.c: \\tshrn\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-1.c scan-assembler-times \\tshrn\\t 1 gcc.target/aarch64/shrn-combine-1.c: \\tshrn2\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-1.c scan-assembler-times \\tshrn2\\t 1 PASS: gcc.target/aarch64/shrn-combine-2.c (test for excess errors) gcc.target/aarch64/shrn-combine-2.c: \\tshrn\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-2.c scan-assembler-times \\tshrn\\t 1 gcc.target/aarch64/shrn-combine-2.c: \\tshrn2\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-2.c scan-assembler-times \\tshrn2\\t 1 PASS: gcc.target/aarch64/shrn-combine-3.c (test for excess errors) gcc.target/aarch64/shrn-combine-3.c: \\tshrn\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-3.c scan-assembler-times \\tshrn\\t 1 gcc.target/aarch64/shrn-combine-3.c: \\tshrn2\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-3.c scan-assembler-times \\tshrn2\\t 1 (and similarly with -march=armv8.5-a+sve2) I haven't checked the actual generated code.
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #5 from Christophe Lyon --- Sure, I just filed PR 102906 for the ivopts-4.c issue on arm.
[Bug middle-end/102906] New: [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906 Bug ID: 102906 Summary: [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r12-4526 (g:d8edfadfc7a9795b65177a50ce44fd348858e844) I have noticed regressions on some arm targets for gcc.target/arm/ivopts-4.c For instance on arm-none-linux-gnueabihf --with-arch armv7-a+mp+sec+neon-fp16 FAIL: gcc.target/arm/ivopts-4.c object-size text <= 36 But this depends on the actual target & runtestflags, see: https://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844/report-build-info.html
[Bug tree-optimization/102832] [12 Regression] ICE in vect_create_partial_epilog with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102832 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug other/102663] add an install-dvi Makefile target to the toplevel Makefile and all subdirectories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663 Eric Gallager changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=46986 --- Comment #7 from Eric Gallager --- Fixed (for the most part; I couldn't test go due to 46986, and jit will have to be re-checked after 102824 is fixed, but other than that it's good enough.)
[Bug other/102663] add an install-dvi Makefile target to the toplevel Makefile and all subdirectories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663 --- Comment #6 from CVS Commits --- The master branch has been updated by Eric Gallager : https://gcc.gnu.org/g:c3e80a16af287e804b87b8015307085399755cd4 commit r12-4636-gc3e80a16af287e804b87b8015307085399755cd4 Author: Eric Gallager Date: Fri Oct 22 15:24:15 2021 -0700 Add install-dvi Makefile targets. Closes #102663 ChangeLog: PR other/102663 * Makefile.def: Handle install-dvi target. * Makefile.tpl: Likewise. * Makefile.in: Regenerate. c++tools/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. gcc/ChangeLog: PR other/102663 * Makefile.in: Handle dvidir and install-dvi target. * configure: Regenerate. * configure.ac: Add install-dvi to target_list. gcc/ada/ChangeLog: PR other/102663 * gcc-interface/Make-lang.in: Allow dvi-formatted documentation to be installed. gcc/c/ChangeLog: PR other/102663 * Make-lang.in: Add dummy c.install-dvi target. gcc/cp/ChangeLog: PR other/102663 * Make-lang.in: Add dummy c++.install-dvi target. gcc/d/ChangeLog: PR other/102663 * Make-lang.in: Allow dvi-formatted documentation to be installed. gcc/fortran/ChangeLog: PR other/102663 * Make-lang.in: Allow dvi-formatted documentation to be installed. gcc/lto/ChangeLog: PR other/102663 * Make-lang.in: Add dummy lto.install-dvi target. gcc/objc/ChangeLog: PR other/102663 * Make-lang.in: Add dummy objc.install-dvi target. gcc/objcp/ChangeLog: PR other/102663 * Make-lang.in: Add dummy objc++.install-dvi target. gnattools/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. libada/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. libcpp/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. libdecnumber/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. libiberty/ChangeLog: PR other/102663 * Makefile.in: Allow dvi-formatted documentation to be installed.
[Bug middle-end/48580] missed optimization: integer overflow checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #24 from Andrew Pinski --- Mine. I had a patch which improves the "== 0" to just ^1. Let me see if I can finish up.
[Bug libstdc++/102894] make_any is not SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102894 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.4
[Bug libstdc++/102894] make_any is not SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102894 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0c1f737a485f05c591c94b50acfb416c45a4c916 commit r12-4634-g0c1f737a485f05c591c94b50acfb416c45a4c916 Author: Jonathan Wakely Date: Fri Oct 22 22:55:00 2021 +0100 libstdc++: Constrain std::make_any [PR102894] std::make_any should be constrained so it can only be called if the construction of the return value would be valid. libstdc++-v3/ChangeLog: PR libstdc++/102894 * include/std/any (make_any): Add SFINAE constraint. * testsuite/20_util/any/102894.cc: New test.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #24 from Tobias Burnus --- FIXED (GCC 12) - including the follow-up issue. Thanks for the testcases, patches, debugging and patience!
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #23 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:24e99e6ec1cc57f3660c00ff677c7feb16aa94d2 commit r12-4632-g24e99e6ec1cc57f3660c00ff677c7feb16aa94d2 Author: Tobias Burnus Date: Fri Oct 22 23:23:06 2021 +0200 Fortran: Avoid running into assert with -fcheck= + UBSAN PR fortran/92621 gcc/fortran/ * trans-expr.c (gfc_trans_assignment_1): Add STRIP_NOPS. gcc/testsuite/ * gfortran.dg/bind-c-intent-out-2.f90: New test.
[Bug tree-optimization/102829] Redundant null check after atomic load from that address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102829 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/102826] Glibc "--disable-mathvec" configure option fail to disable traces to libmvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826 --- Comment #4 from Andrew Pinski --- (In reply to Haochen Jiang from comment #3) > However, in the gfortran config part of gcc, it should not has the finclude > part for F951 under all circumstances or there should be some option to > control that. This is also a bug I believe. Maybe there should be an option but only to workaround bugs in glibc :).
[Bug middle-end/102810] [11/12 Regression] Bogus Wstringop-overread passing a smaller array to an array parameter without a bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102810 Andrew Pinski changed: What|Removed |Added URL|https://stackoverflow.com/q | |/69583120/5264491 | Target Milestone|--- |11.3 --- Comment #2 from Andrew Pinski --- https://stackoverflow.com/q/69583120/5264491
[Bug libstdc++/102894] make_any is not SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102894 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-10-22 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/102882] [AIX] 23_containers 96088 testsuite failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102882 --- Comment #4 from Jonathan Wakely --- OK, that confirms that the allocations are being done by the std::string objects inside the library. But I really don't want to have to use custom allocators every time we use std::string in such tests.
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 --- Comment #8 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #5) > The object is only destroyed after the destructor finishes, which is never > in this case. But it's still wrong to re-enter the destructor after it starts, even if it hasn't finished yet. And [basic.life] p1 says the lifetime ends when the destructor call *starts*. So the delete expression calls a destructor on an object after its lifetime ends.
[Bug tree-optimization/102794] [12 Regression] missing vrp in evrp dealing with casts and ands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102794 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed most likely by r12-4526.
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899
--- Comment #7 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #5)
> What I see is clang performing checks at a place it shouldn't.
> It can be better seen on
> struct Test {
> constexpr Test() = default;
>
> constexpr ~Test() {
> delete this;
> }
> };
>
> consteval bool test() {
> auto obj = new Test();
> delete obj;
> return true;
> }
>
> static_assert(test());
> where it reports
> destruction of object that is already being destroyed
> which definitely isn't something that happens in the testcase.
> The object is only destroyed after the destructor finishes, which is never
> in this case.
I think clang is right to reject this, because the constexpr destructor can
never be called with arguments that make it a constant expression, so it's
ill-formed; no diagnostic required ([dcl.constexpr]/6).
[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 --- Comment #4 from anlauf at gcc dot gnu.org --- Furthermore the "scalar" variants work: ... type(t), parameter :: u= t(4) ... y = (u%a) ...
[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |testsuite
CC||aldyh at gcc dot gnu.org,
||pinskia at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Keywords|wrong-code |
Last reconfirmed||2021-10-22
Ever confirmed|0 |1
--- Comment #4 from Andrew Pinski ---
/* { dg-final { scan-tree-dump "Jumps threaded: 12" "thread3" } } */
/* { dg-final { scan-tree-dump-not "Jumps threaded" "dom2" } } */
/* aarch64 has the highest CASE_VALUES_THRESHOLD in GCC. It's high enough
to change decisions in switch expansion which in turn can expose new
jump threading opportunities. Skip the later tests on aarch64. */
/* { dg-final { scan-tree-dump-not "Jumps threaded" "dom3" { target { !
aarch64*-*-* } } } } */
/* { dg-final { scan-tree-dump-not "Jumps threaded" "vrp-thread2" { target { !
aarch64*-*-* } } } } */
Someone didn't update this for aarch64 which is why you get:
gcc.dg/tree-ssa/ssa-dom-thread-7.c: dump file does not exist
UNRESOLVED: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump-not vrp-thread2
"Jumps threaded"
On x86_64 also.
Christophe,
Can you file gcc.target/arm/ivopts-4.c seperately? Since it seems unrelated
to others. And this one can be for the ssa-dom-thread-7.c failure only.
[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 --- Comment #3 from anlauf at gcc dot gnu.org --- Strange. We happen to call gfc_free_shape with inconsistent data: (gdb) p rank $84 = 2 (gdb) p shape[1] $85 = (mpz_t *) 0x0 Not good. Interestingly the following works: integer :: z(1,2) = (x(1)%a)
[Bug middle-end/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 Andrew Pinski changed: What|Removed |Added Summary|[12 regression] r12-4526|[12 regression] r12-4526 |caused regressions on |caused regressions on |vect/bb-slp-16.c and|ssa-dom-thread-7.c |ssa-dom-thread-7.c | --- Comment #3 from Andrew Pinski --- I can confirm ssa-dom-thread-7.c FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps threaded: 12"
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 --- Comment #7 from Dominique d'Humieres --- > Has this bug been fully fixed now, so that we can close it? It seems so.
[Bug testsuite/102905] [12 regression] several vector test cases fail on power 7 after r12-4490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102905 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/102902] [12 Regression] wrong code at -O3 on x86_64-linux-gnu (generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |12.0
[Bug fortran/102891] Passing real part of complex type component using w%z%re to a subroutine gives erroneous value of dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2021-10-22 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Interestingly, replacing the line call print_arr(w%z%re) by call print_arr([w%z%re]) works around the issue.
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #6 from sandra at gcc dot gnu.org --- Has this bug been fully fixed now, so that we can close it?
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482 sandra at gcc dot gnu.org changed: What|Removed |Added CC||everythingfunctional@proton ||mail.com --- Comment #11 from sandra at gcc dot gnu.org --- *** Bug 99922 has been marked as a duplicate of this bug. ***
[Bug fortran/99922] Bind(C) with assumed length character should work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99922 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from sandra at gcc dot gnu.org --- This is a duplicate of now-fixed PR 92482. *** This bug has been marked as a duplicate of bug 92482 ***
[Bug rtl-optimization/102627] [11 Regression] wrong code with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from H.J. Lu --- Fixed for GCC 12 and 11.3.
[Bug c++/102508] ICE on coroutine when awaiting inside a statement expression (in transform_local_var_uses, at cp/coroutines.cc:2102)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102508 --- Comment #2 from Iain Sandoe --- thanks for the simplified test case. As noted in pr98935, statement expressions are not handled (I deferred handling them in the initial implementation since they are an extension)... however, it is intended to support them when possible.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #7 from H.J. Lu --- (In reply to kargl from comment #6) > > Another possibility is to revert your patch so that others can bootstrap. The problem won't go away as long as we keep syncing with upstream.
[Bug fortran/102816] [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 since r12-4452-g1e819bd95ebeefc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102816 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Mine. Patch: https://gcc.gnu.org/pipermail/fortran/2021-October/056772.html
[Bug testsuite/102742] ERROR: descriptor 3 still open after tests complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102742 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed.
[Bug testsuite/102742] ERROR: descriptor 3 still open after tests complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102742 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:690180eb4b35df3f4b5def690878ecaeb5492e41 commit r12-4630-g690180eb4b35df3f4b5def690878ecaeb5492e41 Author: Martin Liska Date: Fri Oct 22 10:12:56 2021 +0200 Handle jobserver file descriptors in btest. PR testsuite/102742 libbacktrace/ChangeLog: * btest.c (MIN_DESCRIPTOR): New. (MAX_DESCRIPTOR): Likewise. (check_available_files): Likewise. (check_open_files): Check only file descriptors that were not available at the entry. (main): Call check_available_files.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #6 from kargl at gcc dot gnu.org --- Just ran into this issue. :-((In reply to H.J. Lu from comment #4) > Another possibility is to add a configure test to locate the system > and include it instead of . Another possibility is to revert your patch so that others can bootstrap.
[Bug testsuite/102905] New: [12 regression] several vector test cases fail on power 7 after r12-4490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102905 Bug ID: 102905 Summary: [12 regression] several vector test cases fail on power 7 after r12-4490 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:caab0139761b04226fab14d87c4a4f981d942bbf, r12-4490: 201 failures > FAIL: gcc.dg/vect/vect-multitypes-4.c -flto -ffat-lto-objects > scan-tree-dump-times vect "Alignment of access forced using peeling" 2 > FAIL: gcc.dg/vect/vect-multitypes-4.c -flto -ffat-lto-objects > scan-tree-dump-times vect "Vectorizing an unaligned access" 8 > FAIL: gcc.dg/vect/vect-multitypes-4.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorized 1 loops" 2 > FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "Alignment of > access forced using peeling" 2 > FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "Vectorizing > an unaligned access" 8 > FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "vectorized 1 > loops" 2 > FAIL: gcc.dg/vect/vect-peel-1.c -flto -ffat-lto-objects scan-tree-dump-times > vect "Alignment of access forced using peeling" 1 > FAIL: gcc.dg/vect/vect-peel-1.c -flto -ffat-lto-objects scan-tree-dump-times > vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/vect-peel-1.c scan-tree-dump-times vect "Alignment of > access forced using peeling" 1 > FAIL: gcc.dg/vect/vect-peel-1.c scan-tree-dump-times vect "vectorized 1 > loops" 1 These are probably failing due to limitations in vector stuff on power 7. Perhaps just skip these on power 7? commit caab0139761b04226fab14d87c4a4f981d942bbf (HEAD, refs/bisect/bad) Author: Richard Biener Date: Mon Oct 18 15:55:22 2021 +0200 Remove check_aligned parameter from vect_supportable_dr_alignment
[Bug tree-optimization/102897] [12 Regression] simplify_permutation ICEs on assert since r12-1103-g4a9f2306cb39a3cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102897 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |12.0
[Bug tree-optimization/102902] [12 Regression] wrong code at -O3 on x86_64-linux-gnu (generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902 Andrew Pinski changed: What|Removed |Added Depends on||100810 Last reconfirmed||2021-10-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. -fno-ivopts fixes the issue. I suspect (have not fully looked yet), this is the same issue as PR 100810. Initializing g also fixes the issue which is another sign it is the same issue as PR 100810. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810 [Bug 100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
[Bug c++/102898] declaration of 'using Foo = enum class Foo' changes meaning of 'Foo'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102898 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- GCC is correct in this error message. The (current) C++ standard requires no diagnostic on this though.
[Bug libffi/101208] libffi.call/nested_struct12.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101208 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed when the libffi was synced with the upstream.
[Bug testsuite/102904] New: go testsuite does not always cause a timeout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102904 Bug ID: 102904 Summary: go testsuite does not always cause a timeout Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- I just ran into this on aarch64-linux-gnu. It seems like the gotest timeout mechanism is not working fully. go.test/test/fixedbugs/issue16095.go was running for 298:53.85 (minues:seconds). If I can reproduce it again, I will try to have more data.
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 --- Comment #6 from friedkeenan at protonmail dot com --- Well it says "being destroyed" not "already destroyed", because the object is currently being destroyed
[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from sandra at gcc dot gnu.org --- This is working now. I've committed a slightly cleaned-up version of the testcase (basically just exchanging the print "FAIL!"s with STOPs). I also convinced myself that the testcase is correct. ;-)
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899
--- Comment #5 from Jakub Jelinek ---
What I see is clang performing checks at a place it shouldn't.
It can be better seen on
struct Test {
constexpr Test() = default;
constexpr ~Test() {
delete this;
}
};
consteval bool test() {
auto obj = new Test();
delete obj;
return true;
}
static_assert(test());
where it reports
destruction of object that is already being destroyed
which definitely isn't something that happens in the testcase.
The object is only destroyed after the destructor finishes, which is never in
this case.
[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 --- Comment #5 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:c31d2d14f798dc7ca9cc078200d37113749ec3bd commit r12-4629-gc31d2d14f798dc7ca9cc078200d37113749ec3bd Author: Sandra Loosemore Date: Fri Oct 22 11:08:19 2021 -0700 Add testcase for PR fortran/94289 2021-10-22 José Rui Faustino de Sousa Sandra Loosemore gcc/testsuite/ PR fortran/94289 * gfortran.dg/PR94289.f90: New.
[Bug fortran/102903] New: Invalid gfortran.dg testcases or wrong-code with -fcheck=all -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102903 Bug ID: 102903 Summary: Invalid gfortran.dg testcases or wrong-code with -fcheck=all -fsanitize=undefined Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- With -fcheck=all -fsanitize=undefined the following shows up * Possibly okay (invalid on purpose) * Possibly a testcase bug * Possibly a code gen bug == PR95214.f90 == At line 69 of file PR95214.f90 Fortran runtime error: Actual string length does not match the declared one for dummy argument 'x' (1/77) == PR95331.f90 == PR95331.f90:137:7: runtime error: load of misaligned address 0x7ffcb894801c for type '', which requires 8 byte alignment 0x7ffcb894801c: note: pointer points here 2b 00 00 00 2c 00 00 00 2d 00 00 00 2e 00 00 00 2f 00 00 00 30 00 00 00 31 00 00 00 32 00 00 00 ^ == alloc_comp_class_5.f03 == alloc_comp_class_5.f03:26:57: runtime error: load of misaligned address 0x7ffea4a0384f for type '', which requires 8 byte alignment 0x7ffea4a0384f: note: pointer points here 00 00 00 00 66 6f 6f 62 61 72 62 61 7a 00 00 00 00 00 00 00 00 d0 27 cc 01 00 00 00 00 ff ff ff ^ == alloc_comp_constructor_6.f90 == alloc_comp_constructor_6.f90:26:25: runtime error: signed integer overflow: 5095827452369516032 * 2 cannot be represented in type 'integer(kind=8)' == allocate_with_source_8.f08 == allocate_with_source_8.f08:87:28: runtime error: load of misaligned address 0x7ffc8ce71bc2 for type '', which requires 8 byte alignment 0x7ffc8ce71bc2: note: pointer points here 00 00 00 00 66 6f 6f 62 61 72 04 00 00 00 cd cc 8c 3f cd cc 0c 40 04 00 00 00 cd cc 8c 3f cd cc ^ == alloc_comp_class_5.f03 == alloc_comp_class_5.f03:26:57: runtime error: load of misaligned address 0x7ffea4a0384f for type '', which requires 8 byte alignment 0x7ffea4a0384f: note: pointer points here 00 00 00 00 66 6f 6f 62 61 72 62 61 7a 00 00 00 00 00 00 00 00 d0 27 cc 01 00 00 00 00 ff ff ff ^ == assumed_type_13.f90 == assumed_type_13.f90:63:6: runtime error: load of misaligned address 0x0040b4c2 for type '', which requires 8 byte alignment 0x0040b4c2: note: pointer points here 02 00 03 00 01 00 02 00 03 00 01 00 02 00 03 00 00 00 44 08 00 00 ff 0f 00 00 00 00 00 00 01 00 ^ == auto_char_dummy_array_1.f90 == At line 34 of file auto_char_dummy_array_1.f90 Fortran runtime error: Actual string length does not match the declared one for dummy argument 'p' (12/0) == class_array_20.f03 == class_array_20.f03:44:8: runtime error: load of null pointer of type 'struct foo' class_array_20.f03:45:8: runtime error: load of null pointer of type 'struct foo' == missing_optional_dummy_6.f90 == missing_optional_dummy_6.f90:21:29: runtime error: load of null pointer of type 'integer(kind=4)' == mvbits_1.f90 == mvbits_1.f90:15:29: runtime error: negation of -128 cannot be represented in type 'integer(kind=1)'; cast to an unsigned type to negate this value to itself mvbits_1.f90:15:29: runtime error: signed integer overflow: -128 - 1 cannot be represented in type 'integer(kind=1)' mvbits_1.f90:22:29: runtime error: negation of -32768 cannot be represented in type 'integer(kind=2)'; cast to an unsigned type to negate this value to itself == optional_absent_5.f90 == optional_absent_5.f90:11:39: runtime error: load of null pointer of type 'logical(kind=4)' optional_absent_5.f90:11:39: runtime error: member access within null pointer of type 'struct array02_logical(kind=4)' optional_absent_5.f90:25:42: runtime error: load of null pointer of type 'logical(kind=4)' == power_8.f90 == power_8.f90:36:9: runtime error: signed integer overflow: -128 * -1 cannot be represented in type 'integer(kind=1)' power_8.f90:61:9: runtime error: signed integer overflow: -9223372036854775808 * -1 cannot be represented in type 'integer(kind=8)' == pr17143.f90 == pr17143.f90:10:19: runtime error: signed integer overflow: 4611686018427387904 * 2 cannot be represented in type 'integer(kind=8)' == pr86328.f90 == pr86328.f90:41:37: runtime error: member access within null pointer of type 'struct __vtype__STAR' == pr17143.f90 == pr17143.f90:10:19: runtime error: signed integer overflow: 4611686018427387904 * 2 cannot be represented in type 'integer(kind=8)' == random_7.f90 == random_7.f90:22:36: runtime error: load of null pointer of type 'integer(kind=4)' random_7.f90:22:36: runtime error: load of null pointer of type 'integer(kind=4)' == select_type_49.f90 == select_type_49.f90:13:26: runtime error: load of misaligned address
[Bug tree-optimization/102886] [12 regression] gcc.dg/tree-ssa/sra-18.c fails starting with r12-4607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886 --- Comment #2 from Martin Jambor --- I posted a fix on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582380.html
[Bug fortran/102843] [12 regression] gfortran.dg/deferred_type_param_6.f90 fails after r12-4457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102843 seurer at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from seurer at gcc dot gnu.org --- Yes, it works now for me. Thanks!
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 --- Comment #4 from friedkeenan at protonmail dot com --- (In reply to Jakub Jelinek from comment #3) > Just compile your testcase with additional > -Dconstexpr= -Dconsteval= -D'static_assert(x)=' > to see how it is compiled, there is that infinite recursion with all > compilers I've tried. The difference being that that's runtime which does not have the same heap safety guarantees as constant evaluation. The recursive error, while technically compliant with the standard afaik, is not that great from a figuring out what the issue is perspective.
[Bug fortran/102900] ICE via gfc_class_data_get with alloc_comp_class_4.f03 or proc_ptr_52.f90 using -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900 Tobias Burnus changed: What|Removed |Added Summary|ICE via gfc_class_data_get |ICE via gfc_class_data_get |in alloc_comp_class_4.f03 |with alloc_comp_class_4.f03 |with -fcheck=all|or proc_ptr_52.f90 using ||-fcheck=all --- Comment #1 from Tobias Burnus --- Similar but slightly different ICE for proc_ptr_52.f90 with -fcheck=all: 65 | y = apply (f, x) ! Fixed by first chunk in patch | 1 internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.c:232 0x7c1370 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../repos/gcc/gcc/tree.c:8689 0x662539 tree_check3(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code) ../../repos/gcc/gcc/tree.h:3473 0x662539 gfc_class_data_get(tree_node*) ../../repos/gcc/gcc/fortran/trans-expr.c:232 0xa0f97f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../repos/gcc/gcc/fortran/trans-expr.c:7211
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 --- Comment #3 from Jakub Jelinek --- Just compile your testcase with additional -Dconstexpr= -Dconsteval= -D'static_assert(x)=' to see how it is compiled, there is that infinite recursion with all compilers I've tried.
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 --- Comment #2 from friedkeenan at protonmail dot com --- (In reply to Jakub Jelinek from comment #1) > Why do you think this is a compiler bug? > If you delete this, you invoke the destructor and then the operator delete, > so when you do this in the destructor, it means you do infinite recursion. Because this message is really unhelpful, and Clang handles it as I would expect, where it errors on the second deallocation of `this`, and that's it.
[Bug c++/102899] Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why do you think this is a compiler bug? If you delete this, you invoke the destructor and then the operator delete, so when you do this in the destructor, it means you do infinite recursion.
[Bug tree-optimization/102902] New: wrong code at -O3 on x86_64-linux-gnu (generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902
Bug ID: 102902
Summary: wrong code at -O3 on x86_64-linux-gnu (generated code
hangs)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression.
[575] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211022 (experimental) [master r12-4624-gae5c540662e] (GCC)
[576] %
[576] % gcctk -O2 small.c; ./a.out
[577] %
[577] % gcctk -O3 small.c
[578] % timeout -s 9 10 ./a.out
Killed
[579] %
[579] % cat small.c
int printf (const char *, ...);
int a, b, c, d, e, f;
int main() {
int g;
short h = 1;
for (; e < 2; e++) {
L1:
f = 1;
while (b > 0 || a > 0) {
g++;
h++;
printf("%d", g);
}
L2:
if (!h && (!c || a))
goto L1;
if (c)
goto L2;
}
return 0;
}
[Bug fortran/102901] New: ICE (segfault) when compiling pdt_13.f03 with -fcheck=all in gfc_check_pdt_dummy -> structure_alloc_comps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102901
Bug ID: 102901
Summary: ICE (segfault) when compiling pdt_13.f03 with
-fcheck=all in gfc_check_pdt_dummy ->
structure_alloc_comps
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Existing pdt_13.f03, pdt_14.f03 and pdt_15.f03 fail when compiled with
-fcheck=all
structure_alloc_comps:
9998case CHECK_PDT_DUMMY:
1 comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
10001 decl, cdecl, NULL_TREE);
->
#1 0x00be7ba7 in fold_build3_loc (loc=287456,
code=code@entry=COMPONENT_REF, type=type@entry=0x76fc15e8,
op0=op0@entry=0x766cdd00, op1=op1@entry=0x7719c2f8, op2=op2@entry=0x0)
at ../../repos/gcc-trunk-commit/gcc/fold-const.c:13813
13813 tem = fold_ternary_loc (loc, code, type, op0, op1, op2);
(gdb) p code
$16 = COMPONENT_REF
(gdb) p debug_tree(type)
Cannot access memory at address 0x7bffecef
(gdb) p debug_tree(op0)
Cannot access memory at address 0x7bffecef
(gdb) p debug_tree(op1)
Cannot access memory at address 0x7bffecef
(gdb) p debug_tree(op2)
Cannot access memory at address 0x7bffecef
Going up in the calltree:
10009 tmp = gfc_check_pdt_dummy (c->ts.u.derived, comp,
10010c->as ? c->as->rank : 0,
10011pdt_param_list);
(gdb) p *c->ts.u.derived
$19 = {name = 0x7716ee10 "Pdtlink_8", module = 0x7716ede0 "link_module"
(gdb) p c->as
$20 = (gfc_array_spec *) 0x0
(gdb) p pdt_param_list
$21 = (gfc_actual_arglist *) 0x2a4b070
(gdb) p *pdt_param_list
$22 = {name = 0x7716edf0 "real_kind", label = 0x0, missing_arg_type =
BT_UNKNOWN, spec_type = SPEC_EXPLICIT, expr = 0x2acfce0, next = 0x0}
[Bug fortran/100917] Bind(c): errors handling long double real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from sandra at gcc dot gnu.org --- This is fully fixed now. I think the testcases in the c-interop testsuite are adequate, so nothing more to do here.
[Bug fortran/102900] New: ICE via gfc_class_data_get in alloc_comp_class_4.f03 with -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900 Bug ID: 102900 Summary: ICE via gfc_class_data_get in alloc_comp_class_4.f03 with -fcheck=all Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Compiling the existing alloc_comp_class_4.f03 with -fcheck=all fails with: alloc_comp_class_4.f03:91:29: 91 | call add_class_c(c_init2()) | 1 internal compiler error: Segmentation fault 0xfaae63 crash_signal ../../repos/gcc/gcc/toplev.c:322 0xa050a1 gfc_class_data_get(tree_node*) ../../repos/gcc/gcc/fortran/trans-expr.c:230 0xa0f97f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../repos/gcc/gcc/fortran/trans-expr.c:7211
[Bug fortran/102503] ICE in gfc_conv_array_bound, at fortran/trans-types.c:1224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102503
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
F2018:C837 An assumed-rank entity shall be a dummy data object that does not
have the CODIMENSION or VALUE attribute.
In principle, something like the following should do - but reading the file
shows that there are many more issues of the same kind :-(
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -15623,7 +15623,7 @@ resolve_symbol (gfc_symbol *sym)
return;
}
if (as->type == AS_ASSUMED_RANK
- && (sym->attr.codimension || sym->attr.value))
+ && (class_attr->attr.codimension || sym->attr.value))
{
gfc_error ("Assumed-rank array at %L may not have the VALUE or "
"CODIMENSION attribute", >declared_at);
[Bug c++/102899] New: Performing `delete this` within destructor in constant evaluation results in infinitely recursive error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102899
Bug ID: 102899
Summary: Performing `delete this` within destructor in constant
evaluation results in infinitely recursive error
message
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: friedkeenan at protonmail dot com
Target Milestone: ---
See the following code:
struct Test {
constexpr Test() = default;
constexpr ~Test() {
delete this;
}
};
consteval bool test() {
const auto obj = Test{};
return true;
}
static_assert(test());
Godbolt link: https://godbolt.org/z/fv3dGWsY1
This bug still occurs when `obj` is heap-allocated and destroyed with
`std::destroy_at`.
This issue does not occur if the `delete this` statement is relegated to
another method, including the constructor; it only occurs when `delete this` is
placed within the destructor.
[Bug fortran/100906] Bind(c): failure handling character with len/=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from sandra at gcc dot gnu.org --- This was fixed as part of Tobias's big GFC <-> CFI descriptor re-work, and I've separately committed the testcase for this issue. I think we can close this issue now.
[Bug fortran/100906] Bind(c): failure handling character with len/=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906 --- Comment #6 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:b7cb6d66bd52e884ff33c61e46a9ee9facc2ac60 commit r12-4628-gb7cb6d66bd52e884ff33c61e46a9ee9facc2ac60 Author: Sandra Loosemore Date: Thu Oct 21 19:17:50 2021 -0700 Add testcase for PR fortran/100906 2021-10-21 José Rui Faustino de Sousa Sandra Loosemore gcc/testsuite/ PR fortran/100906 * gfortran.dg/PR100906.f90: New. * gfortran.dg/PR100906.c: New.
[Bug fortran/102843] [12 regression] gfortran.dg/deferred_type_param_6.f90 fails after r12-4457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102843 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- Can you confirm that it is now fixed after the commit: r12-4511-gff0eec94e87dfb7dc387f120ca5ade2707aecf50 ?
[Bug c++/102898] New: declaration of 'using Foo = enum class Foo' changes meaning of 'Foo'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102898
Bug ID: 102898
Summary: declaration of 'using Foo = enum class Foo' changes
meaning of 'Foo'
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roehling at debian dot org
Target Milestone: ---
The following C++ code fails to compile:
enum class Foo { foo };
class Bar
{
using Foo = Foo;
};
The generated error is
:5:11: error: declaration of 'using Foo = enum class Foo' changes
meaning of 'Foo' [-fpermissive]
5 | using Foo = Foo;
| ^~~
:1:12: note: 'Foo' declared here as 'enum class Foo'
1 | enum class Foo { foo };
|^~~
The code does compile with
using Baz = Foo;
or
using Foo = enum Foo;
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 81981, which changed state. Bug 81981 Summary: [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug sanitizer/81981] [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981 Martin Sebor changed: What|Removed |Added Known to fail||12.0 Known to work||10.3.0, 11.2.0, 8.5.0, ||9.4.0 Keywords||xfail Last reconfirmed|2017-08-25 00:00:00 |2021-10-22 CC||msebor at gcc dot gnu.org Status|RESOLVED|REOPENED Resolution|FIXED |--- Blocks||24639 --- Comment #7 from Martin Sebor --- This has come back with r12-4625 (the fix for pr102681). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug fortran/102862] CLASS(*) – various issues, esp. with assumed-rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102862 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 --- Comment #1 from Dominique d'Humieres --- Confirmed from gfortan 10 up to master.
[Bug testsuite/102886] [12 regression] gcc.dg/tree-ssa/sra-18.c fails starting with r12-4607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886 Martin Jambor changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-22 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #1 from Martin Jambor --- Oh, stupid me... mine.
[Bug fortran/100916] Bind(c): CFI_type_other unimplemented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100916 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 Ever confirmed|0 |1
[Bug fortran/100916] Bind(c): CFI_type_other unimplemented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100916
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #6 from Tobias Burnus ---
(In reply to sandra from comment #5)
> Jose's test case for this issue is still failing.
I find the testcase very confusing. For
type(c_other), intent(in) :: a(:)
call check_tk_as(a, t, k, e, 1_c_size_t)
it fails with:
FAIL! type (A): 6 != 255
which is printed by:
printf ("FAIL! type (A): %d != %d\n", auxp->type, type);
gfortran uses the following, which seems to be fine:
#define CFI_type_struct 6
I do not quite understand why the testcase expects 255 as type now how it tries
to generate that number.
Other fails:
FAIL! type (B): 6 != -1
FAIL! type (C): -1 != 6
FAIL! type: -1 != 6
Here the issue is that GCC uses CFI_type_struct (= 6)
while the testcase expects CFI_type_other (= -1).
I think one can argue for either.
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 --- Comment #11 from Dominique d'Humieres --- In both case I get FAIL! chrcmp: 66 != 65281 FAIL! chrcmp: 66 != 65281 FAIL! chrcmp: 67 != 65282 FAIL! chrcmp: 68 != 65283 FAIL! chrcmp: 69 != 65284 FAIL! chrcmp: 70 != 65285 FAIL! chrcmp: 71 != 65286 FAIL! chrcmp: 72 != 65287 FAIL! chrcmp: 73 != 65288 FAIL! chrcmp: 74 != 65289 FAIL! chrcmp: 75 != 65290 FAIL! chrcmp: 0 != 65291 FAIL! char: 75 != 11 Assertion failed: (c_vrfy_character (auxp)), function check_tk, file pr100907_db.c, line 215. Program received signal SIGABRT: Process abort signal.
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #10 from Tobias Burnus --- (In reply to sandra from comment #9) > Jose's test case for this issue is still failing. Which is not surpising: sz = (size_t)auxp->elem_len / sizeof (char); for kind=4 character of len=1 and len=7 gives sz=4 and sz=28. The testcase should have used: sz = (size_t)auxp->elem_len / sizeof (CFI_type_ucs4_char); Or expect 4 and 28 instead of 1 and 7 as result ...
[Bug fortran/102503] ICE in gfc_conv_array_bound, at fortran/trans-types.c:1224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102503 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-22 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug tree-optimization/102893] [9/10/11 Regression] CDDCE does not detect empty infinite nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893 --- Comment #4 from Tamar Christina --- Thanks for the fix! This was reported to us by a user of the arm embedded toolchains that was upgrading from gcc 7. We won't be releasing any new releases for GCC 8 and 9, but may be for 10 and 11 is certain. So a backport to 11 and if possible 10 would be great as it avoids us having to possibly carry the patch in a vendor branch.
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 Martin Liška changed: What|Removed |Added Resolution|--- |MOVED URL||https://github.com/libffi/l ||ibffi/issues/666 Status|WAITING |RESOLVED --- Comment #6 from Martin Liška --- Moved.
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 --- Comment #5 from David Binderman --- (In reply to Martin Liška from comment #4) > Then, please file it here: https://github.com/libffi/libffi/issues. Done. https://github.com/libffi/libffi/issues/666
[Bug fortran/96870] Class name on error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96870 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- Was fixed by r12-4464-g017665f63047ce47b087b0b283548a60e5abf3d2 for PR102745 Close as FIXED. Thanks for the report – and sorry for not reviewing your patch :-/
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 --- Comment #4 from Martin Liška --- Then, please file it here: https://github.com/libffi/libffi/issues.
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 --- Comment #3 from David Binderman --- (In reply to H.J. Lu from comment #2) > Does it happen in libffi upstream? > > https://github.com/libffi/libffi Yes.
[Bug tree-optimization/102890] [12 Regression] ICE in duplicate_and_interleave, at tree-vect-slp.c:6173 since r12-1329-gce670e4faafb296d1f1a7828d20f8c8ba4686797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102890 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #3 from rsandifo at gcc dot gnu.org --- I'll take a look in stage 3 (if not earlier).
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 H.J. Lu changed: What|Removed |Added CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com Status|NEW |WAITING --- Comment #2 from H.J. Lu --- Does it happen in libffi upstream? https://github.com/libffi/libffi
[Bug tree-optimization/102890] [12 Regression] ICE in duplicate_and_interleave, at tree-vect-slp.c:6173 since r12-1329-gce670e4faafb296d1f1a7828d20f8c8ba4686797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102890 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |12.0 Priority|P3 |P2 --- Comment #2 from Richard Biener --- Hum, the function is Richards area, possibly we trigger a latent issue here.
[Bug tree-optimization/102893] [9/10/11 Regression] CDDCE does not detect empty infinite nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||12.0 Summary|[9/10/11/12 Regression] |[9/10/11 Regression] CDDCE |CDDCE does not detect empty |does not detect empty |infinite nested loops |infinite nested loops --- Comment #3 from Richard Biener --- Not sure if worth backporting.
[Bug tree-optimization/102893] [9/10/11/12 Regression] CDDCE does not detect empty infinite nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c2a9a98a369528c8689ecb68db576f8e7dc2fa45 commit r12-4627-gc2a9a98a369528c8689ecb68db576f8e7dc2fa45 Author: Richard Biener Date: Fri Oct 22 12:45:32 2021 +0200 tree-optimization/102893 - properly DCE empty loops inside infinite loops The following fixes the test for an exit edge I put in place for the fix for PR45178 where I somehow misunderstood how the cyclic list works. 2021-10-22 Richard Biener PR tree-optimization/102893 * tree-ssa-dce.c (find_obviously_necessary_stmts): Fix the test for an exit edge. * gcc.dg/tree-ssa/ssa-dce-9.c: New testcase.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #22 from Tobias Burnus --- (In reply to sandra from comment #21) > Tobias, did your big patch fully fix this issue so that we can close it? I checked the examples – and did run into the following ICE. I think we should at some point compile all gfortran testcases with -fcheck= and/or -fsanitize=undefined(,address) and with and without optimization to see whether it triggers some ICE. Additionally, I think we might want to do something likewise for the dg-do run tests. * * * The testcase attachment 47882 of comment 3 still/now fails with: 9 | val = 2 | 1 internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:11732 It works when using 'val(:) = 2' - and only fails when compiled with both: -fcheck=all -fsanitize=undefined The fail is for: 11731 /* We should only get array references here. */ 11732 gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR 11733 || TREE_CODE (tmp) == ARRAY_REF); (gdb) p debug(tmp) (integer(kind=4) *) ((void *) D.4249 + (sizetype) ((S.5 + D.4250) * val->span)) (gdb) p debug_tree(tmp)
[Bug tree-optimization/102897] [12 Regression] simplify_permutation ICEs on assert since r12-1103-g4a9f2306cb39a3cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102897 Martin Liška changed: What|Removed |Added CC||linkw at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 Summary|[12 Regression] |[12 Regression] |simplify_permutation ICEs |simplify_permutation ICEs |on assert |on assert since ||r12-1103-g4a9f2306cb39a3cf Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r12-1103-g4a9f2306cb39a3cf.
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2021-10-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/102897] New: [12 Regression] simplify_permutation ICEs on assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102897
Bug ID: 102897
Summary: [12 Regression] simplify_permutation ICEs on assert
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
The following testcase
typedef __attribute__((vector_size(8))) signed char int8x8_t;
typedef __attribute__((vector_size(8))) unsigned char uint8x8_t;
int8x8_t fn1(int8x8_t val20, char tmp) {
uint8x8_t __trans_tmp_3;
__trans_tmp_3 = (uint8x8_t){tmp};
int8x8_t __a = (int8x8_t)__trans_tmp_3;
return __builtin_shuffle(__a, val20, (uint8x8_t){});
}
ICEs at -O1 and higher with
during GIMPLE pass: forwprop
: In function 'fn1':
:12:1: internal compiler error: in simplify_permutation, at
tree-ssa-forwprop.c:2271
12 | }
| ^
0x1000e00 simplify_permutation
src/gcc/gcc/tree-ssa-forwprop.c:2271
0x1007ae8 execute
src/gcc/gcc/tree-ssa-forwprop.c:3397
That line contains an assert with the comment
tree op2_type = TREE_TYPE (op2);
/* Should have folded this before. */
gcc_assert (op2_type != tgt_type);
[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from rsandifo at gcc dot gnu.org --- Yeah, bootstrap works again too. Thanks for the fix!
[Bug libffi/102896] src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896 David Binderman changed: What|Removed |Added CC||hjl at gcc dot gnu.org --- Comment #1 from David Binderman --- git blame says: 92456a4e5658 (H.J. Lu 2021-08-31 07:14:47 -0700 239) else if (ptr == (char *) _args[7]) Adding HJ for their opinion.
[Bug tree-optimization/102895] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102895 --- Comment #2 from Aldy Hernandez --- (In reply to Richard Biener from comment #1) > There's identical IL before the vrp2 pass (the one after strlen) but on the > GCC 11 branch vrp2 eliminates the call to foo while on trunk it does not. > > On the branch VRP registers > > Registering jump thread: (2, 3) incoming edge; (3, 4) normal; > > which elides the call but vrp-thread2 does not do this: > > Registering value_relation (_5 > a.4_4) (bb5) at _5 = a.4_4 + 1; > Registering value_relation (_19 > a.4_13) (bb4) at _19 = a.4_13 + 1; > [4] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; > Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) > incoming edge; (3, 4) normal; > > on the branch this threading destroys the loop structure It seems there were other threads in play before the loop restriction changes went in. In the branch we have: $ gcc a.c -O2 -fdump-tree-all-details -c abulafia:~/bld/t/gcc$ grep thread a.c.* a.c.124t.dom2: Registering jump thread: (10, 5) incoming edge; (5, 12) normal; a.c.124t.dom2: Registering jump thread: (9, 3) incoming edge; (3, 4) normal; a.c.189t.dom3: Registering jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.192t.vrp2: Registering jump thread: (2, 3) incoming edge; (3, 4) normal; DOM2 was getting 2 threads, but in mainline we have: ./cc1 a.c -O2 -fdump-tree-all-details -quiet abulafia:~/bld/t/gcc$ grep thread a.c.* a.c.128t.dom2:Threading through latch before loop opts would create non-empty latch: Cancelling jump thread: (10, 5) incoming edge; (5, 12) normal; a.c.128t.dom2:Path rotates loop: Cancelling jump thread: (9, 3) incoming edge; (3, 4) normal; a.c.193t.dom3: [3] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.193t.dom3:Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.197t.vrp-thread2: [4] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.197t.vrp-thread2:Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) incoming edge; (3, 4) normal; Those DOM2 threads were cancelled because of the loop restrictions we put in. Since jump threads in one pass open the possibilities of further jump threads by other passes, it could be that the missing DOM2 threads are causing VRP2 to miss out. However, vrp-thread2 *does* find and register the path. It's the block copier that is complaining: a.c.197t.vrp-thread2: [4] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; a.c.197t.vrp-thread2:Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) incoming edge; (3, 4) normal; Note that these "Failure in thread_through_loop_header" messages are new debugging aids in this release, but the cancel_thread was present nevertheless. It was just silent. I would guess it's either the missing DOM threads that has cascading effects, or something in the block copier (fwd_jt_path_registry::). FWIW, there have been no changes in the block copier in this release.
[Bug libffi/102896] New: src/moxie/ffi.c:239:arrayIndexOutOfBounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102896
Bug ID: 102896
Summary: src/moxie/ffi.c:239:arrayIndexOutOfBounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Static analyser cppcheck says:
trunk.git/libffi/src/moxie/ffi.c:239:46: error: Array 'register_args[6]'
accessed at index 7, which is out of bounds. [arrayIndexOutOfBounds]
Source code is
unsigned register_args[6] =
{ arg1, arg2, arg3, arg4, arg5, arg6 };
...
else if (ptr == (char *) _args[7])
[Bug tree-optimization/102893] [9/10/11/12 Regression] CDDCE does not detect empty infinite nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |9.5
Last reconfirmed||2021-10-22
Summary|[8/9/10/11/12 Regression] |[9/10/11/12 Regression]
|CDDCE does not detect empty |CDDCE does not detect empty
|infinite nested loops |infinite nested loops
--- Comment #1 from Richard Biener ---
Hm, there's
/* For loops without an exit do not mark any condition. */
if (loop->exits->next && !finite_loop_p (loop))
but here
(gdb) p loop->exits
$2 = (loop_exit *) 0x76690440
(gdb) p loop->exits->next
$3 = (loop_exit *) 0x76690440
(gdb) p *loop->exits
$5 = {e = , prev = 0x76690440, next = 0x76690440,
next_e = 0x0}
so I suppose I misunderstood how loop->exits works, looks like ->e has to be
non-NULL as well. But that means the testcase I added this check for
somehow did not have loop->exits->next?!
Mine.
[Bug tree-optimization/102895] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102895 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||missed-optimization Ever confirmed|0 |1 CC||aldyh at gcc dot gnu.org Last reconfirmed||2021-10-22 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- There's identical IL before the vrp2 pass (the one after strlen) but on the GCC 11 branch vrp2 eliminates the call to foo while on trunk it does not. On the branch VRP registers Registering jump thread: (2, 3) incoming edge; (3, 4) normal; which elides the call but vrp-thread2 does not do this: Registering value_relation (_5 > a.4_4) (bb5) at _5 = a.4_4 + 1; Registering value_relation (_19 > a.4_13) (bb4) at _19 = a.4_13 + 1; [4] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) incoming edge; (3, 4) normal; on the branch this threading destroys the loop structure
