[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #8 from Rui Ueyama --- Sure, I agree with that. But would there be any problem if gcc, after failing to find `-mold` and `mold` in the embedded toolchain's directory, looks for `ld.mold` in the $PATH?"
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #7 from Andrew Pinski --- (In reply to Rui Ueyama from comment #6) > Since mold supports all targets by a single executable, it doesn't make much > sense to install one mold executable for each embedded toolchain. You are wrong for support reasons. Especially when it comes to companies providing toolchain support. Most don't want to be based on what is installed on the system. > > All in all, the problem wouldn't exist at all if gcc just looks for > `ld.mold`? (I'm not suggesting making a change to the default behavior; I'd > do that only if `-fuse-ld=mold` or `-fuse-ld=lld` is givne.) This might be useful for a distro which provides all binaries but when it comes to supporting embedded a target tighting control is better and not depending on the installed version is always better.
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #6 from Rui Ueyama --- Since mold supports all targets by a single executable, it doesn't make much sense to install one mold executable for each embedded toolchain. So if we want to keep the current gcc's lookup mechanism for `ld` executable, we want to install mold somewhere in the system and install a symlink for each target, and that's not compatible with relocatable emddeded toolchain directory. We need to adjust the realpath of a symlink to point to the mold executable file. All in all, the problem wouldn't exist at all if gcc just looks for `ld.mold`? (I'm not suggesting making a change to the default behavior; I'd do that only if `-fuse-ld=mold` or `-fuse-ld=lld` is givne.)
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #5 from Andrew Pinski --- (In reply to Rui Ueyama from comment #4) > > More likely the scripts which build the full toolchains directories should > > be creating the symbolic links instead of mold itself. > > So the package manager create a `-ld.mold` as a symlink to `mold` if > mold is installed? Or, should it create a `-ld.mold` unconditionally > as a symlink to `/usr/bin/mold`? If the latter, what if the user build mold > themselves and install it under `/usr/local/bin`? Most will not install it in /usr/* but for embedded toolchains will be relocatable and installed in the same directory as the parts.
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #4 from Rui Ueyama --- > More likely the scripts which build the full toolchains directories should be > creating the symbolic links instead of mold itself. So the package manager create a `-ld.mold` as a symlink to `mold` if mold is installed? Or, should it create a `-ld.mold` unconditionally as a symlink to `/usr/bin/mold`? If the latter, what if the user build mold themselves and install it under `/usr/local/bin`?
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #3 from Andrew Pinski --- (In reply to Rui Ueyama from comment #2) > I can make a change to the `make install` rule of the mold linker to install > bunch of symbolic links, but can we enumerate all possible triples? For > example, I wasn't aware that `arm-none-eabi` was a valid triple. If I > enumerate _all_ possible triples, wouldn't I end up with installing hundreds > of symlinks? There are way too many (valid) triplets to list really and also the vendor could be different and still be valid. > > And the tons of symbolic links wouldn't serve any meaningful purpose because > mold just ignores argv[0]. More likely the scripts which build the full toolchains directories should be creating the symbolic links instead of mold itself.
[Bug target/111343] [SH] Including in C++23 causes an ICE with -m4-single-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111343 Oleg Endo changed: What|Removed |Added Target|SH4 |sh*-*-* CC||olegendo at gcc dot gnu.org --- Comment #2 from Oleg Endo --- I think this would be a problem on all targets where DF is forced to be SF, which I think is not a good thing at all. It's also causing problems with Fortan. I'm not sure if it makes sense to add support for DF == SF in the libraries. Perhaps at least on SH4 the -m4-single-only option shouldn't be used generally to build whole projects, but rather only a few files where it's really needed.
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #2 from Rui Ueyama --- I can make a change to the `make install` rule of the mold linker to install bunch of symbolic links, but can we enumerate all possible triples? For example, I wasn't aware that `arm-none-eabi` was a valid triple. If I enumerate _all_ possible triples, wouldn't I end up with installing hundreds of symlinks? And the tons of symbolic links wouldn't serve any meaningful purpose because mold just ignores argv[0].
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #1 from Andrew Pinski --- I think this is by design. You can always just add a symbolic link in the right location for ld.mold and it will work.
[Bug c++/111605] New: Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 Bug ID: 111605 Summary: Cross compilation doesn't work with `-fuse-ld=mold` Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- When I pass `-fuse-ld=mold` to a gcc cross compiler, gcc searches for `ld.mold` from the crosstool's bin directories and then looks for `-ld.mold` from $PATH. Here is a gcc's strace when invoked with `-fuse-ld=mold`. [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/11/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/11/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/11/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/11/../../../../riscv64-linux-gnu/bin/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/.cargo/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/.local/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/.cabal/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/prefix/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/qemu/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/ccache/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/golang/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/.mozbuild/node/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/depot_tools/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/local/sbin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/local/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/sbin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/sbin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/games/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/local/games/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/snap/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) This behavior is appropriate for BFD linker which has one executable for each cross target. However, it's incorrect for the mold linker because mold supports all targets by a single executable. Therefore, when gcc searches mold from $PATH, it should look for just `ld.mold`, without the triple. The same is true for LLD. The link to the upstream bug: https://github.com/rui314/mold/issues/1114
[Bug tree-optimization/109088] GCC does not always vectorize conditional reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088 --- Comment #8 from JuzheZhong --- It's because the order of the operations we are doing: For code as follows: result += mask ? a[i] + x : 0; GCC: result_ssa_1 = PHI ... STMT 1. tmp = a[i] + x; STMT 2. tmp2 = tmp + result_ssa_1; STMT 3. result_ssa_2 = mask ? tmp2 : result_ssa_1; Here we can see both STMT 2 and STMT 3 are using 'result_ssa_1', we end up with 2 uses of the PHI result. Then, we failed to vectorize. Wheras LLVM: result_ssa_1 = PHI ... IR 1. tmp = a[i] + x; IR 2. tmp2 = mask ? tmp : 0; IR 3. result_ssa_2 = tmp2 + result_ssa_1. LLVM only has 1 use. Is it reasonable to swap the order in match.pd ?
[Bug c++/109963] ABI: unexpected layout ordering of `this` pointer in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109963 Justin Lebar changed: What|Removed |Added CC||justin.lebar+bug at gmail dot com --- Comment #2 from Justin Lebar --- I rediscovered this in https://github.com/openai/triton/issues/2398 (along with Mehdi, coincidentally). I'm really not sure how we fix this, though. If gcc changes their ABI, then new GCC binaries will not be compatible with old ones. OTOH if nobody changes their ABI, then we can't pass lambdas between binaries created by the different compilers.
[Bug tree-optimization/109088] GCC does not always vectorize conditional reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088 --- Comment #7 from JuzheZhong --- Update the analysis: We failed to recognize it as reduction because, the PHI result has 2 uses: # result_20 = PHI ... _11 = result_20 + 10; > first use result_17 = _4 + _11; _23 = _4 > _7; result_9 = _23 ? result_17 : result_20; -> second use It seems that it is the if-conversion issue which makes loop vectorizer failed to vectorize it. I have checked LLVM implementation, their "result" ssa always has single use no matter how I modify the codes (for example, result += a[i] + b[i] + c[i]).
[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 #7 from James Y Knight --- On the libc++ side, a suggestion was given that instead of making this an _error_, we could instead emit a warning if "a constexpr or constinit object is a basic_string or contains a basic_string subobject, or the definition of a constexpr or constinit variable extends the lifetime of a temporary object that meets the previous condition." I think that was a really great suggestion -- diagnosing via a warning is a nicer solution than putting is_constant_evaluated hacks into the library (as MSVC had, and libc++ currently has but will likely remove). One could either hardcode std::basic_string for the diagnostic, or add a new type-attribute to permit any type to opt-in to such a warning. You'd want to use it if you have a type where you don't _intend_ to support constant-initialization, but where it may sometimes be possible as an implementation detail, and you want to tell users not to rely on that implementation detail.
[Bug target/107567] __atomic_test_and_set generates non-atomic code on armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107567 --- Comment #3 from Chris Copeland --- Fantastic! Thank you for looking into it.
[Bug c/111604] bogus warning: '#' flag used with ‘%m’ gnu_printf format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111604 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88270 --- Comment #2 from Eric Gallager --- related to bug 88270?
[Bug c++/111512] GCC's __builtin_memcpy can trigger ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111512 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:685a8c45d8e2c8c10171e672888484ea2c50662e commit r12-9894-g685a8c45d8e2c8c10171e672888484ea2c50662e Author: Jonathan Wakely Date: Thu Sep 21 09:14:57 2023 +0100 libstdc++: Prevent unwanted ADL in std::to_array [PR111512] Qualify the calls to the __to_array helper to prevent ADL, so we don't try to complete associated classes. libstdc++-v3/ChangeLog: PR libstdc++/111511 PR c++/111512 * include/std/array (to_array): Qualify calls to __to_array. * testsuite/23_containers/array/creation/111512.cc: New test. (cherry picked from commit 77cf3773021b0a20d89623e09d620747a05588ec)
[Bug libstdc++/111511] Incorrect ADL in std::to_array in GCC 11/12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111511 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:685a8c45d8e2c8c10171e672888484ea2c50662e commit r12-9894-g685a8c45d8e2c8c10171e672888484ea2c50662e Author: Jonathan Wakely Date: Thu Sep 21 09:14:57 2023 +0100 libstdc++: Prevent unwanted ADL in std::to_array [PR111512] Qualify the calls to the __to_array helper to prevent ADL, so we don't try to complete associated classes. libstdc++-v3/ChangeLog: PR libstdc++/111511 PR c++/111512 * include/std/array (to_array): Qualify calls to __to_array. * testsuite/23_containers/array/creation/111512.cc: New test. (cherry picked from commit 77cf3773021b0a20d89623e09d620747a05588ec)
[Bug target/107567] __atomic_test_and_set generates non-atomic code on armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107567 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED CC||hp at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson --- As gcc will, in the next release (gcc-14), with the program and options in the description, emit a call to __atomic_test_and_set along the expectations in the description, I believe this issue is resolved. Thanks for the report, sorry it took so long for someone to fix it.
[Bug c/111604] bogus warning: '#' flag used with ‘%m’ gnu_printf format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111604 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- https://inbox.sourceware.org/libc-alpha/87tuf7i4lk@oldenburg.str.redhat.com/ Hmm, I am not 100% sure gcc can make to know about this for a few more years since gcc supports much older glibc and the *-linux-gnu triplets are not versioned ...
[Bug c/111604] New: bogus warning: '#' flag used with ‘%m’ gnu_printf format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111604
Bug ID: 111604
Summary: bogus warning: '#' flag used with ‘%m’ gnu_printf
format
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: crrodriguez at opensuse dot org
Target Milestone: ---
errno = EINVAL;
printf("%#m");
Causes warning: '#' flag used with ‘%m’ gnu_printf format [-Wformat=]
It is a perfectly valid format string in glibc 2.35 or later where %#m ==
strerrorname_np(errno)
[Bug testsuite/111603] new test case gcc.dg/tree-ssa/pr111456-1.c in r14-4280-gc3c6f30496d945 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111603 Andrew Pinski changed: What|Removed |Added Keywords|missed-optimization |testsuite-fail Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed. Sorry for forgetting about plain char being unsigned for some targets.
[Bug testsuite/111603] new test case gcc.dg/tree-ssa/pr111456-1.c in r14-4280-gc3c6f30496d945 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111603 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:12039c9f40a81605e59951f80007827bc0413573 commit r14-4287-g12039c9f40a81605e59951f80007827bc0413573 Author: Andrew Pinski Date: Tue Sep 26 15:00:38 2023 -0700 Fix pr111456-1.c for targets that use unsigned char by default This fixes the testcase to use an explicit `signed char` instead of plain `char`. Committed as obvious after a test with a cross to powerpc64-linux-gnu and x86_64-linux-gnu. gcc/testsuite/ChangeLog: PR testsuite/111603 * gcc.dg/tree-ssa/pr111456-1.c: Use `signed char` instead of plain `char`.
[Bug testsuite/111603] new test case gcc.dg/tree-ssa/pr111456-1.c in r14-4280-gc3c6f30496d945 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111603 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-09-26 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Oh it is char being unsigned instead. I have a quick fix.
[Bug testsuite/111603] new test case gcc.dg/tree-ssa/pr111456-1.c in r14-4280-gc3c6f30496d945 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111603 Andrew Pinski changed: What|Removed |Added Summary|[14 regression] new test|new test case |case|gcc.dg/tree-ssa/pr111456-1. |gcc.dg/tree-ssa/pr111456-1. |c in |c in|r14-4280-gc3c6f30496d945 |r14-4280-gc3c6f30496d945|fails |fails | Component|gcov-profile|testsuite Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- I need to look into why --param=logical-op-non-short-circuit=0 is no longer working like it was before ...
[Bug gcov-profile/111603] New: [14 regression] new test case gcc.dg/tree-ssa/pr111456-1.c in r14-4280-gc3c6f30496d945 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111603 Bug ID: 111603 Summary: [14 regression] new test case gcc.dg/tree-ssa/pr111456-1.c in r14-4280-gc3c6f30496d945 fails Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- g:c3c6f30496d945b77dcb7f4ad8c3f8094f5a64a4, r14-4280-gc3c6f30496d945 make -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr111456-1.c" FAIL: gcc.dg/tree-ssa/pr111456-1.c scan-tree-dump-not optimized "foo " # of expected passes2 # of unexpected failures1 commit c3c6f30496d945b77dcb7f4ad8c3f8094f5a64a4 (HEAD) Author: Andrew Pinski Date: Wed Sep 20 14:54:31 2023 -0700 MATCH: Simplify `(A ==/!= B) &/| (((cast)A) CMP C)`
[Bug target/109166] Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166 --- Comment #10 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:8e6757b30d0f3f13d47d0f842801a751ba6293c2 commit r14-4286-g8e6757b30d0f3f13d47d0f842801a751ba6293c2 Author: Hans-Peter Nilsson Date: Sat Sep 23 05:06:52 2023 +0200 __atomic_test_and_set: Fall back to library, not non-atomic code Make __atomic_test_and_set consistent with other __atomic_ and __sync_ builtins: call a matching library function instead of emitting non-atomic code when the target has no direct insn support. There's special-case code handling targetm.atomic_test_and_set_trueval != 1 trying a modified maybe_emit_sync_lock_test_and_set. Previously, if that worked but its matching emit_store_flag_force returned NULL, we'd segfault later on. Now that the caller handles NULL, gcc_assert here instead. While the referenced PR:s are ARM-specific, the issue is general. PR target/107567 PR target/109166 * builtins.cc (expand_builtin) : Handle failure from expand_builtin_atomic_test_and_set. * optabs.cc (expand_atomic_test_and_set): When all attempts fail to generate atomic code through target support, return NULL instead of emitting non-atomic code. Also, for code handling targetm.atomic_test_and_set_trueval != 1, gcc_assert result from calling emit_store_flag_force instead of returning NULL.
[Bug target/107567] __atomic_test_and_set generates non-atomic code on armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107567 --- Comment #1 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:8e6757b30d0f3f13d47d0f842801a751ba6293c2 commit r14-4286-g8e6757b30d0f3f13d47d0f842801a751ba6293c2 Author: Hans-Peter Nilsson Date: Sat Sep 23 05:06:52 2023 +0200 __atomic_test_and_set: Fall back to library, not non-atomic code Make __atomic_test_and_set consistent with other __atomic_ and __sync_ builtins: call a matching library function instead of emitting non-atomic code when the target has no direct insn support. There's special-case code handling targetm.atomic_test_and_set_trueval != 1 trying a modified maybe_emit_sync_lock_test_and_set. Previously, if that worked but its matching emit_store_flag_force returned NULL, we'd segfault later on. Now that the caller handles NULL, gcc_assert here instead. While the referenced PR:s are ARM-specific, the issue is general. PR target/107567 PR target/109166 * builtins.cc (expand_builtin) : Handle failure from expand_builtin_atomic_test_and_set. * optabs.cc (expand_atomic_test_and_set): When all attempts fail to generate atomic code through target support, return NULL instead of emitting non-atomic code. Also, for code handling targetm.atomic_test_and_set_trueval != 1, gcc_assert result from calling emit_store_flag_force instead of returning NULL.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code --- Comment #6 from anlauf at gcc dot gnu.org --- Extending the testcase in comment#4: program test2 implicit none character(len=10), allocatable, target :: s(:) character(len=:), pointer :: sptr(:) type :: pointer_typec0_t character(len=:), pointer :: data1(:) end type pointer_typec0_t type(pointer_typec0_t) :: co ! allocate(s(3)) s(1) = '1234567890' s(2) = 'qwertyuio ' s(3) = 'asdfghjk ' ! sptr => s print *, sptr ! OK co%data1 => s print *, co%data1 ! not OK ! print *,len(co%data1(1)),len_trim(co%data1(1)),co%data1(1) print *,len(co%data1(2)),len_trim(co%data1(2)),co%data1(2) print *,len(co%data1(3)),len_trim(co%data1(3)),co%data1(3) end program test2 The tree-dump has: .sptr = 10; sptr = s; sptr.span = s.span; but co.data1 = s; co.data1.span = s.span; so we don't set the character length in the association.
[Bug libstdc++/111511] Incorrect ADL in std::to_array in GCC 11/12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111511 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:161a477f0ce93de1d083d379247d0770d4ef96af commit r13-7844-g161a477f0ce93de1d083d379247d0770d4ef96af Author: Jonathan Wakely Date: Thu Sep 21 09:14:57 2023 +0100 libstdc++: Prevent unwanted ADL in std::to_array [PR111512] Qualify the calls to the __to_array helper to prevent ADL, so we don't try to complete associated classes. libstdc++-v3/ChangeLog: PR libstdc++/111511 PR c++/111512 * include/std/array (to_array): Qualify calls to __to_array. * testsuite/23_containers/array/creation/111512.cc: New test. (cherry picked from commit 77cf3773021b0a20d89623e09d620747a05588ec)
[Bug c++/111512] GCC's __builtin_memcpy can trigger ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111512 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:161a477f0ce93de1d083d379247d0770d4ef96af commit r13-7844-g161a477f0ce93de1d083d379247d0770d4ef96af Author: Jonathan Wakely Date: Thu Sep 21 09:14:57 2023 +0100 libstdc++: Prevent unwanted ADL in std::to_array [PR111512] Qualify the calls to the __to_array helper to prevent ADL, so we don't try to complete associated classes. libstdc++-v3/ChangeLog: PR libstdc++/111511 PR c++/111512 * include/std/array (to_array): Qualify calls to __to_array. * testsuite/23_containers/array/creation/111512.cc: New test. (cherry picked from commit 77cf3773021b0a20d89623e09d620747a05588ec)
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Created attachment 55998 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55998=edit Testcase for scalar pointer The original testcase from comment#0 failed with 9.5.0, but works with 10.5.0 and newer. An extended deja-gnuified testcase for this is attached. The variant with array-valued pointers in comment#4 still fails.
[Bug c++/111602] [11/12/13/14 Regression] "Error: symbol is already defined" for variable template dependent on default argument lambda of class dependent on local type used in sfinae and non-sfinae c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111602
--- Comment #2 from Ed Catmur ---
(In reply to Andrew Pinski from comment #1)
> The local type of f() is not needed.
Thanks! I was confused since the local type is required in this similar
example:
template struct P
{
static constexpr bool value = true;
};
template constexpr bool P::value;
template struct E {};
struct F
{
template::value>>
F(T) {}
};
template struct C
{
C(F = []{}) {}
};
auto f()
{
struct T {} t;
return t;
}
template
decltype(T()) g()
{
return T();
}
int main()
{
g>();
}
[Bug modula2/111510] Modula-2 runtime ICE on arm-linux-gnueabihf: iso/RTentity.mod:245:in findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111510 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Gaius Mulley --- Closing now that the patches have been applied.
[Bug modula2/111510] Modula-2 runtime ICE on arm-linux-gnueabihf: iso/RTentity.mod:245:in findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111510 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:b92cddb94874df4b9451d9cea3efa88f0654981b commit r13-7842-gb92cddb94874df4b9451d9cea3efa88f0654981b Author: Gaius Mulley Date: Tue Sep 26 19:39:59 2023 +0100 PR modula2/111510 runtime ICE findChildAndParent has caused internal runtime error This patch fixes the runtime bug above. The full runtime message is: findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage has not been initialized yet. The bug is due to a non nul terminated string determining the module initialization order. This results in modules being uninitialized and the above crash. The bug manifests itself on 32 bit systems - but obviously is latent on all targets and the fix should be applied to both gcc-14 and gcc-13. gcc/m2/ChangeLog: PR modula2/111510 * gm2-compiler/M2GenGCC.mod (IsExportedGcc): Minor spacing changes. (BuildTrashTreeFromInterface): Minor spacing changes. * gm2-compiler/M2Options.mod (GetRuntimeModuleOverride): Call string to generate a nul terminated C style string. * gm2-compiler/M2Quads.mod (BuildStringAdrParam): New procedure. (BuildM2InitFunction): Replace inline parameter generation with calls to BuildStringAdrParam. (cherry picked from commit 53daf67fd55e005e37cb3ab33ac0783a71761de9) Signed-off-by: Gaius Mulley
[Bug tree-optimization/111599] [14 Regression] ICE: Segmentation fault in VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111599 Andrew Macleod changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Macleod --- fixed.
[Bug tree-optimization/111599] [14 Regression] ICE: Segmentation fault in VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111599 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:c9dbace008e60255b10891f0c966b44a0225d7ab commit r14-4283-gc9dbace008e60255b10891f0c966b44a0225d7ab Author: Andrew MacLeod Date: Tue Sep 26 09:27:52 2023 -0400 Ensure ssa_name is still valid. When the IL changes, an equivalence set may contain ssa_names that no longer exist. Ensure names are still valid and not in the free list. PR tree-optimization/111599 gcc/ * value-relation.cc (relation_oracle::valid_equivs): Ensure ssa_name is valid. gcc/testsuite/ * gcc.dg/pr111599.c: New.
[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Andrew Macleod --- fixed.
[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315 --- Comment #12 from CVS Commits --- The releases/gcc-13 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:70639014a69cf50fe11dc1adbfe1db4c7760ce69 commit r13-7841-g70639014a69cf50fe11dc1adbfe1db4c7760ce69 Author: Andrew MacLeod Date: Tue Sep 26 09:44:39 2023 -0400 Reduce the initial size of int_range_max. This patch adds the ability to resize ranges as needed, defaulting to no resizing. int_range_max now defaults to 3 sub-ranges (instead of 255) and grows to 255 when the range being calculated does not fit. PR tree-optimization/110315 * value-range-storage.h (vrange_allocator::alloc_irange): Adjust new params. * value-range.cc (irange::operator=): Resize range. (irange::irange_union): Same. (irange::irange_intersect): Same. (irange::invert): Same. * value-range.h (irange::maybe_resize): New. (~int_range): New. (int_range_max): Default to 3 sub-ranges and resize as needed. (int_range::int_range): Adjust for resizing. (int_range::operator=): Same.
[Bug target/111600] [14.0 regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #1 from Andrew Pinski --- The new (target) builtins could cause increased compile time ...
[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817 Andrew Pinski changed: What|Removed |Added CC||Hi-Angel at yandex dot ru --- Comment #21 from Andrew Pinski --- *** Bug 111598 has been marked as a duplicate of this bug. ***
[Bug c/111598] Wimplicit-fallthrough print for a code that is not compiled in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111598 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 77817. *** This bug has been marked as a duplicate of bug 77817 ***
[Bug c++/111602] [11/12/13/14 Regression] "Error: symbol is already defined" for variable template dependent on default argument lambda of class dependent on local type used in sfinae and non-sfinae c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111602 Andrew Pinski changed: What|Removed |Added Summary|"Error: symbol is already |[11/12/13/14 Regression] |defined" for variable |"Error: symbol is already |template dependent on |defined" for variable |default argument lambda of |template dependent on |class dependent on local|default argument lambda of |type used in sfinae and |class dependent on local |non-sfinae contexts |type used in sfinae and ||non-sfinae contexts Target Milestone|--- |11.5 Known to fail||8.1.0 Known to work||7.1.0
[Bug c++/111602] "Error: symbol is already defined" for variable template dependent on default argument lambda of class dependent on local type used in sfinae and non-sfinae contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111602
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-09-26
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Slightly reduced:
```
template constexpr bool V = true;
struct F
{
template>
F(T) {}
};
template struct C
{
C(F = []{}) {}
};
template
decltype(T()) g()
{
return T();
}
int main()
{
g>();
}
```
The local type of f() is not needed.
[Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||build, ice-on-valid-code
[Bug c++/111602] New: "Error: symbol is already defined" for variable template dependent on default argument lambda used in sfinae and non-sfinae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111602
Bug ID: 111602
Summary: "Error: symbol is already defined" for variable
template dependent on default argument lambda used in
sfinae and non-sfinae
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
Since gcc 8.1,
template constexpr bool V = true;
struct F { template> F(T) {} };
template struct C { C(F = []{}) {} };
template decltype(T()) g() { return T(); }
auto f() { struct T {} t; return t; };
int main() { g>(); }
compiled at -O0 (and -std=c++14 or above) causes assembler error:
/tmp/cccVZwwU.s: Assembler messages:
/tmp/cccVZwwU.s:106: Error: symbol `_Z1VIZN1CIZ1fvE1TEC4E1FEd_UlvE_E' is
already defined
The symbol demangles as 'V::C(F)::{default arg#1}::{lambda()#1}>'.
[Bug c++/111596] ICE on iostream as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111596 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 108245. *** This bug has been marked as a duplicate of bug 108245 ***
[Bug c++/108245] ICE with invalid variable auto arguments and supplying an extra type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108245 Andrew Pinski changed: What|Removed |Added CC||stevenxia990430 at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 111596 has been marked as a duplicate of this bug. ***
[Bug modula2/111510] Modula-2 runtime ICE on arm-linux-gnueabihf: iso/RTentity.mod:245:in findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111510 --- Comment #3 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:53daf67fd55e005e37cb3ab33ac0783a71761de9 commit r14-4282-g53daf67fd55e005e37cb3ab33ac0783a71761de9 Author: Gaius Mulley Date: Tue Sep 26 18:08:37 2023 +0100 PR modula2/111510 runtime ICE findChildAndParent has caused internal runtime error This patch fixes the runtime bug above. The full runtime message is: findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage has not been initialized yet. The bug is due to a non nul terminated string determining the module initialization order. This results in modules being uninitialized and the above crash. The bug manifests itself on 32 bit systems - but obviously is latent on all targets and the fix should be applied to both gcc-14 and gcc-13. gcc/m2/ChangeLog: PR modula2/111510 * gm2-compiler/M2GenGCC.mod (IsExportedGcc): Minor spacing changes. (BuildTrashTreeFromInterface): Minor spacing changes. * gm2-compiler/M2Options.mod (GetRuntimeModuleOverride): Call string to generate a nul terminated C style string. * gm2-compiler/M2Quads.mod (BuildStringAdrParam): New procedure. (BuildM2InitFunction): Replace inline parameter generation with calls to BuildStringAdrParam. Signed-off-by: Gaius Mulley
[Bug tree-optimization/111599] [14 Regression] ICE: Segmentation fault in VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111599 --- Comment #3 from Andrew Macleod --- patch in testing
[Bug tree-optimization/111599] [14 Regression] ICE: Segmentation fault in VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111599 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Summary|ICE: Segmentation fault |[14 Regression] ICE: ||Segmentation fault in VRP
[Bug tree-optimization/111599] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111599 --- Comment #2 from Andrew Pinski --- Created attachment 55997 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55997=edit Reduced testcase Still need: `-O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-tree-dce -fno-tree-forwprop -fno-tree-fre ` to get the ICE though.
[Bug ada/110488] [13/14 regression] deferred constant wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110488 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- Fixed on the mainline and 13 branch.
[Bug ada/110488] [13/14 regression] deferred constant wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110488 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:35787c3093fa611ba46008e94f329000d6042be4 commit r13-7840-g35787c3093fa611ba46008e94f329000d6042be4 Author: Eric Botcazou Date: Sat Sep 16 20:29:20 2023 +0200 ada: Fix deferred constant wrongly rejected This recent regression occurs when the nominal subtype of the constant is a discriminated record type with default discriminants. gcc/ada/ PR ada/110488 * sem_ch3.adb (Analyze_Object_Declaration): Do not build a default subtype for a deferred constant in the definite case too.
[Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Bug ID: 111601
Summary: [14 Regression] bootstrap fails in stagestrain in
libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with trunk 20230917 and 20230926 on both x86_64-linux-gnu and
powerpc64le-linux-gnu with a profiled lto build. last successful build with
this configuration was 20230907.
not seen on aarch64, s390x, riscv64.
build/libcody/config.log just shows:
onfigure:2143: checking whether the C++ compiler works
configure:2165:
/home/packages/gcc/snap/gcc-snapshot-20230917/build/./prev-gcc/xg++
-B/home/packages/gcc/snap/gcc-snapshot-20230917/build/./prev-gcc/
-B/usr/lib/gcc-snapshot/x86_64-linux-gnu/bin/ -nostdinc++
-B/home/packages/gcc/snap/gcc-snapshot-20230917/build/prev-x86_64-linux-gnu/libstdc++-v3/src/.libs
-B/home/packages/gcc/snap/gcc-snapshot-20230917/build/prev-x86_64-linux-gnu/libstdc++-v3/libsupc++/.libs
-isystem
/home/packages/gcc/snap/gcc-snapshot-20230917/build/prev-x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu
-isystem
/home/packages/gcc/snap/gcc-snapshot-20230917/build/prev-x86_64-linux-gnu/libstdc++-v3/include
-isystem
/home/packages/gcc/snap/gcc-snapshot-20230917/src/libstdc++-v3/libsupc++
-L/home/packages/gcc/snap/gcc-snapshot-20230917/build/prev-x86_64-linux-gnu/libstdc++-v3/src/.libs
-L/home/packages/gcc/snap/gcc-snapshot-20230917/build/prev-x86_64-linux-gnu/libstdc++-v3/libsupc++/.libs
-g -O2 -static-libstdc++ -static-libgcc -Wl,-z,relro conftest.cpp >&5
xg++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See for instructions.
configure:2169: $? = 4
configure:2207: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "codylib"
| #define PACKAGE_TARNAME "codylib"
| #define PACKAGE_VERSION "0.0"
| #define PACKAGE_STRING "codylib 0.0"
| #define PACKAGE_BUGREPORT "github.com/urnathan/libcody"
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2212: error: in
`/home/packages/gcc/snap/gcc-snapshot-20230917/build/libcody':
configure:2214: error: C++ compiler cannot create executables
GCC is configured with
Configured with: -v
--with-pkgversion='Debian 20230926-1'
--with-bugurl='file:///usr/share/doc/gcc-snapshot/README.Bugs'
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
--prefix=/usr/lib/gcc-snapshot
--with-gcc-major-version-only
--program-prefix=
--enable-shared
--enable-linker-build-id
--disable-nls
--enable-bootstrap
--enable-clocale=gnu
--enable-libstdcxx-debug
--enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new
--enable-gnu-unique-object
--disable-vtable-verify
--enable-plugin
--with-system-zlib
--enable-libphobos-checking=release
--with-target-system-zlib=auto
--enable-objc-gc=auto
--enable-multiarch
--disable-werror
--enable-cet
--with-arch-32=i686
--with-abi=m64
--with-multilib-list=m32,m64,mx32
--enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/<>/debian/tmp-nvptx/usr/lib/gcc-snapshot,amdgcn-amdhsa=/<>/debian/tmp-gcn/usr/lib/gcc-snapshot
--enable-offload-defaulted
--without-cuda-driver
--enable-checking=yes,extra,rtl
--build=x86_64-linux-gnu
--host=x86_64-linux-gnu
--target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean
--enable-link-serialization=3
and running make profiledbootstrap-lean
[Bug middle-end/110148] [14 Regression] TSVC s242 regression between g:c0df96b3cda5738afbba3a65bb054183c5cd5530 and g:e4c986fde56a6248f8fbe6cf0704e1da34b055d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Jambor --- (In reply to cuilili from comment #7) > (In reply to Martin Jambor from comment #6) > > I believe this has been fixed? > > Yes. Closing the bug then.
[Bug tree-optimization/111456] [14 Regression] Dead Code Elimination Regression since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111456 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:c3c6f30496d945b77dcb7f4ad8c3f8094f5a64a4 commit r14-4280-gc3c6f30496d945b77dcb7f4ad8c3f8094f5a64a4 Author: Andrew Pinski Date: Wed Sep 20 14:54:31 2023 -0700 MATCH: Simplify `(A ==/!= B) &/| (((cast)A) CMP C)` This patch adds support to the pattern for `(A == B) &/| (A CMP C)` where the second A could be casted to a different type. Some were handled correctly if using seperate `if` statements but not if combined with BIT_AND/BIT_IOR. In the case of pr111456-1.c, the testcase would pass if `--param=logical-op-non-short-circuit=0` was used but now can be optimized always. OK? Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/106164 PR tree-optimization/111456 gcc/ChangeLog: * match.pd (`(A ==/!= B) & (A CMP C)`): Support an optional cast on the second A. (`(A ==/!= B) | (A CMP C)`): Likewise. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/cmpbit-6.c: New test. * gcc.dg/tree-ssa/cmpbit-7.c: New test. * gcc.dg/tree-ssa/pr111456-1.c: New test.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 110148, which changed state. Bug 110148 Summary: [14 Regression] TSVC s242 regression between g:c0df96b3cda5738afbba3a65bb054183c5cd5530 and g:e4c986fde56a6248f8fbe6cf0704e1da34b055d8 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164 --- Comment #22 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:c3c6f30496d945b77dcb7f4ad8c3f8094f5a64a4 commit r14-4280-gc3c6f30496d945b77dcb7f4ad8c3f8094f5a64a4 Author: Andrew Pinski Date: Wed Sep 20 14:54:31 2023 -0700 MATCH: Simplify `(A ==/!= B) &/| (((cast)A) CMP C)` This patch adds support to the pattern for `(A == B) &/| (A CMP C)` where the second A could be casted to a different type. Some were handled correctly if using seperate `if` statements but not if combined with BIT_AND/BIT_IOR. In the case of pr111456-1.c, the testcase would pass if `--param=logical-op-non-short-circuit=0` was used but now can be optimized always. OK? Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/106164 PR tree-optimization/111456 gcc/ChangeLog: * match.pd (`(A ==/!= B) & (A CMP C)`): Support an optional cast on the second A. (`(A ==/!= B) | (A CMP C)`): Likewise. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/cmpbit-6.c: New test. * gcc.dg/tree-ssa/cmpbit-7.c: New test. * gcc.dg/tree-ssa/pr111456-1.c: New test.
[Bug tree-optimization/111456] [14 Regression] Dead Code Elimination Regression since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111456 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Andrew Pinski --- Fixed.
[Bug tree-optimization/111469] [14 Regression] Wrong code at -Os on x86_64-linux-gnu since r14-573-g69f1a8af45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111469 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Andrew Pinski --- Fixed.
[Bug tree-optimization/111469] [14 Regression] Wrong code at -Os on x86_64-linux-gnu since r14-573-g69f1a8af45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111469 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:68fa82e2d8f868a233103102dff2449a416bc566 commit r14-4279-g68fa82e2d8f868a233103102dff2449a416bc566 Author: Andrew Pinski Date: Thu Sep 21 03:05:17 2023 + PHIOPT: Fix minmax_replacement for three way So when diamond bb support was added to minmax_replacement in r13-1950-g9bb19e143cfe, the code was not expecting the alt_middle_bb not to exist if it was empty (for threeway_p). So when factor_out_conditional_conversion was used to factor out conversions, it turns out the assumption for alt_middle_bb to be wrong and we ended up with threeway_p being true but having middle_bb being empty but alt_middle_bb not being empty which causes wrong code in many cases. This patch fixes the issue by adding a test for the 2 cases where the assumption on threeway_p case having the other bb being empty. Changes made: v2: Fix test for `(a <= u) b = MAX(a, d) else b = u`. Note my plan for GCC 15 is remove minmax_replacement as match.pd will catch all cases at that point. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/111469 gcc/ChangeLog: * tree-ssa-phiopt.cc (minmax_replacement): Fix the assumption for the `non-diamond` handling cases of diamond code. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/pr111469-1.c: New test.
[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 --- Comment #11 from Iain Sandoe --- (In reply to Michael Duggan from comment #9) > More data: > The coroutine actor is marked as artificial in > coro_build_actor_or_destroy_function. As a result, it is completely ignored > by gcov. In gcov's process_all_functions function, artificial functions are > removed from the set of functions to consider. This may not be the only > problem, but this will definitely prevent things from working. > > The marking is not incorrect. The actor function is artificial. But, > unlike most artificial functions, it is built using the body of an actual > function. I'm not certain how that should be dealt with. right, so I wonder what happens: 1. if you temporarily patch the C++ FE to make the "actor" function non-artificial (it is actually a combination of compiler-generated, artificial, code and the outlined user's function body). 2. if we reorganised things to have a non-artificial outlined actor but have that called via two 'shim' functions (one for resume() and one for destroy()) - and have those two functions as artificial. 3. if an artificial function is inlined into a non-artificial one? 4. if a non-artificial function is inlined into an artificial one? (I am not too familiar with how the coverage code interacts with other things)
[Bug modula2/111510] Modula-2 runtime ICE on arm-linux-gnueabihf: iso/RTentity.mod:245:in findChildAndParent has caused internal runtime error, RTentity is either corrupt or the module storage has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111510 --- Comment #2 from Gaius Mulley --- Created attachment 55996 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55996=edit Proposed fix Here is a proposed fix - the bug was the lack of a nul terminated string - resulting in garbled init order of modules. This affects all targets and is present in gcc-13 and gcc-14. When (if) it bootstraps (on both gcc-14 and gcc-13) - I'll apply the patch. Thanks for the bug report!
[Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 Bug ID: 111600 Summary: [14.0 regression] RISC-V bootstrap time regression Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target Milestone: --- Target: riscv*-*-* Between 20230915 and 20230922 the total bootstrap time (all languages enabled) has increased from 127309 to 156925 seconds. Bootstrap times for weekly builds of the last two months: 2023071499353 2023072295286 +4.3% 2023072896453 +1.2% 2023080497106 +0.7% 20230811107889 +11.1% 20230818108573 +0.6% 20230825110850 +2.1% 20230901111338 +0.4% 20230908120820 +8.5% 20230915127309 +5.4% 20230922156925 +23.3% Compiling dwarf2out.cc (preprocessed from the 20230714 tree) with the stage3 compilers, -O2 -g: 20230714417.455 20230722417.031 20230728416.201 20230804419.312 20230811418.617 20230818419.281 20230825419.950 20230901421.329 20230908425.063 20230915426.305 20230922430.378
[Bug rtl-optimization/111558] RISCV: shrink-wrapper optimization question
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111558 --- Comment #3 from Xiao Ma --- (In reply to Xiao Ma from comment #2) > For this piece of code, LLVM seems to be a bit concise: during the pass of > Prologue/Epilogue Insertion & Frame Finalization, it only inserts sd/ld > blocks in the entry and exit BB: > > https://godbolt.org/z/qxdrMKc46 On the contrary, GCC emits sd/ld blocks for each of BB, in the pro_and_epilogue pass: https://godbolt.org/z/vY4M71snz
[Bug rtl-optimization/111558] RISCV: shrink-wrapper optimization question
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111558 Xiao Ma changed: What|Removed |Added CC||mxlol233 at outlook dot com --- Comment #2 from Xiao Ma --- For this piece of code, LLVM seems to be a bit concise: during the pass of Prologue/Epilogue Insertion & Frame Finalization, it only inserts sd/ld blocks in the entry and exit BB: https://godbolt.org/z/qxdrMKc46
[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315 --- Comment #11 from Andrew Macleod --- (In reply to Richard Biener from comment #10) > (In reply to Andrew Macleod from comment #7) > > Created attachment 55591 [details] > > potental patch > > > > I've attached Aldy's patch for PR109695 which he had backported to GCC13 > > back in May. > > This does resolve the issue.. Assuming we want to apply it GCC13. The > > original variant has been in trunk for a while now. Im running this thru a > > bootstrap/regression run now. > > > > I don't know if there is anything further you want to try it with? > > Can we consider this please? sure. OK for gcc 13 after another round of regressions?
[Bug middle-end/111594] RISC-V: Failed to fold VEC_COND_EXPR and COND_LEN_ADD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111594 JuzheZhong changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from JuzheZhong --- Fixed
[Bug middle-end/110660] conditional length reduction optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110660 JuzheZhong changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from JuzheZhong --- Fixed
[Bug middle-end/111594] RISC-V: Failed to fold VEC_COND_EXPR and COND_LEN_ADD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111594
--- Comment #5 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:dd0197fb4cdee8cd5f78fea9a965c96d7ca47229
commit r14-4277-gdd0197fb4cdee8cd5f78fea9a965c96d7ca47229
Author: Juzhe-Zhong
Date: Tue Sep 26 17:50:37 2023 +0800
MATCH: Optimize COND_ADD_LEN reduction pattern
This patch leverage this commit:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=62b505a4d5fc89
to optimize COND_LEN_ADD reduction pattern.
We are doing optimization of VEC_COND_EXPR + COND_LEN_ADD -> COND_LEN_ADD.
Consider thsi following case:
void
pr11594 (uint64_t *restrict a, uint64_t *restrict b, int loop_size)
{
uint64_t result = 0;
for (int i = 0; i < loop_size; i++)
{
if (b[i] <= a[i])
{
result += a[i];
}
}
a[0] = result;
}
Before this patch:
vsetvli a7,zero,e64,m1,ta,ma
vmv.v.i v2,0
vmv1r.v v3,v2--- redundant
.L3:
vsetvli a5,a2,e64,m1,ta,ma
vle64.v v1,0(a3)
vle64.v v0,0(a1)
sllia6,a5,3
vsetvli a7,zero,e64,m1,ta,ma
sub a2,a2,a5
vmsleu.vv v0,v0,v1
add a1,a1,a6
vmerge.vvm v1,v3,v1,v0 redundant.
add a3,a3,a6
vsetvli zero,a5,e64,m1,tu,ma
vadd.vv v2,v2,v1
bne a2,zero,.L3
li a5,0
vsetvli a4,zero,e64,m1,ta,ma
vmv.s.x v1,a5
vredsum.vs v2,v2,v1
vmv.x.s a5,v2
sd a5,0(a0)
ret
After this patch:
vsetvli a6,zero,e64,m1,ta,ma
vmv.v.i v1,0
.L3:
vsetvli a5,a2,e64,m1,ta,ma
vle64.v v2,0(a4)
vle64.v v0,0(a1)
sllia3,a5,3
vsetvli a6,zero,e64,m1,ta,ma
sub a2,a2,a5
vmsleu.vv v0,v0,v2
add a1,a1,a3
vsetvli zero,a5,e64,m1,tu,mu
add a4,a4,a3
vadd.vv v1,v1,v2,v0.t
bne a2,zero,.L3
li a5,0
vsetivlizero,1,e64,m1,ta,ma
vmv.s.x v2,a5
vsetvli a5,zero,e64,m1,ta,ma
vredsum.vs v1,v1,v2
vmv.x.s a5,v1
sd a5,0(a0)
ret
Bootstrap && Regression is running.
Ok for trunk when testing passes ?
PR tree-optimization/111594
PR tree-optimization/110660
gcc/ChangeLog:
* match.pd: Optimize COND_LEN_ADD reduction.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/cond/cond_reduc-1.c: New test.
* gcc.target/riscv/rvv/autovec/cond/pr111594.c: New test.
[Bug middle-end/110660] conditional length reduction optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110660
--- Comment #4 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:dd0197fb4cdee8cd5f78fea9a965c96d7ca47229
commit r14-4277-gdd0197fb4cdee8cd5f78fea9a965c96d7ca47229
Author: Juzhe-Zhong
Date: Tue Sep 26 17:50:37 2023 +0800
MATCH: Optimize COND_ADD_LEN reduction pattern
This patch leverage this commit:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=62b505a4d5fc89
to optimize COND_LEN_ADD reduction pattern.
We are doing optimization of VEC_COND_EXPR + COND_LEN_ADD -> COND_LEN_ADD.
Consider thsi following case:
void
pr11594 (uint64_t *restrict a, uint64_t *restrict b, int loop_size)
{
uint64_t result = 0;
for (int i = 0; i < loop_size; i++)
{
if (b[i] <= a[i])
{
result += a[i];
}
}
a[0] = result;
}
Before this patch:
vsetvli a7,zero,e64,m1,ta,ma
vmv.v.i v2,0
vmv1r.v v3,v2--- redundant
.L3:
vsetvli a5,a2,e64,m1,ta,ma
vle64.v v1,0(a3)
vle64.v v0,0(a1)
sllia6,a5,3
vsetvli a7,zero,e64,m1,ta,ma
sub a2,a2,a5
vmsleu.vv v0,v0,v1
add a1,a1,a6
vmerge.vvm v1,v3,v1,v0 redundant.
add a3,a3,a6
vsetvli zero,a5,e64,m1,tu,ma
vadd.vv v2,v2,v1
bne a2,zero,.L3
li a5,0
vsetvli a4,zero,e64,m1,ta,ma
vmv.s.x v1,a5
vredsum.vs v2,v2,v1
vmv.x.s a5,v2
sd a5,0(a0)
ret
After this patch:
vsetvli a6,zero,e64,m1,ta,ma
vmv.v.i v1,0
.L3:
vsetvli a5,a2,e64,m1,ta,ma
vle64.v v2,0(a4)
vle64.v v0,0(a1)
sllia3,a5,3
vsetvli a6,zero,e64,m1,ta,ma
sub a2,a2,a5
vmsleu.vv v0,v0,v2
add a1,a1,a3
vsetvli zero,a5,e64,m1,tu,mu
add a4,a4,a3
vadd.vv v1,v1,v2,v0.t
bne a2,zero,.L3
li a5,0
vsetivlizero,1,e64,m1,ta,ma
vmv.s.x v2,a5
vsetvli a5,zero,e64,m1,ta,ma
vredsum.vs v1,v1,v2
vmv.x.s a5,v1
sd a5,0(a0)
ret
Bootstrap && Regression is running.
Ok for trunk when testing passes ?
PR tree-optimization/111594
PR tree-optimization/110660
gcc/ChangeLog:
* match.pd: Optimize COND_LEN_ADD reduction.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/cond/cond_reduc-1.c: New test.
* gcc.target/riscv/rvv/autovec/cond/pr111594.c: New test.
[Bug tree-optimization/109088] GCC does not always vectorize conditional reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #6 from JuzheZhong ---
After investigations:
GCC failed to vectorize reduction with multiple conditional operations:
ifcvt dump:
# result_20 = PHI
...
_11 = result_20 + 10;
result_17 = _4 + _11;
_23 = _4 > _7;
result_9 = _23 ? result_17 : result_20;
It's odd that GCC failed to vectorize it since they are not complicate
statements.
In LLVM, it will vectorize them into:
vector_ssa_2 =
...
vector_ssa_1 = vector_ssa_2 + 10;
vector_ssa_3 = vector_ssa_1 + 10;
mask_ssa_1 = vector_ssa_4 > vector_ssa_5;
vector_ssa_result = select
I think GCC should be able to vectorize it like LLVM:
vector_ssa_2 =
...
vector_ssa_1 = vector_ssa_2 + 10;
vector_ssa_3 = vector_ssa_1 + 10;
mask_ssa_1 = vector_ssa_4 > vector_ssa_5;
vector_ssa_result = VCOND_MASK
I saw this code disable the vectorization:
else if (!bbs.is_empty ()
&& bb->loop_father->header == bb
&& bb->loop_father->dont_vectorize)
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
"splitting region at dont-vectorize loop %d "
"entry at bb%d\n",
bb->loop_father->num, bb->index);
split = true;
}
I am not familiar with these codes, any ideas ? Thanks.
[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175 --- Comment #8 from Mathieu Malaterre --- (In reply to Andrew Pinski from comment #6) > Notice how there is no check for null on aq. Do you want to keep this one open or should we close it as invalid ?
[Bug ada/110488] [13/14 regression] deferred constant wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110488 --- Comment #3 from CVS Commits --- The master branch has been updated by Marc Poulhi?s : https://gcc.gnu.org/g:f6367fc211e52b3f7f8d0f2c481e20cb69839071 commit r14-4275-gf6367fc211e52b3f7f8d0f2c481e20cb69839071 Author: Eric Botcazou Date: Sat Sep 16 20:29:20 2023 +0200 ada: Fix deferred constant wrongly rejected This recent regression occurs when the nominal subtype of the constant is a discriminated record type with default discriminants. gcc/ada/ PR ada/110488 * sem_ch3.adb (Analyze_Object_Declaration): Do not build a default subtype for a deferred constant in the definite case too.
[Bug c/111599] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111599 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55995 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55995=edit The compiler output
[Bug c/111599] New: ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111599 Bug ID: 111599 Summary: ICE: Segmentation fault Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 19373742 at buaa dot edu.cn Target Milestone: --- Created attachment 55994 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55994=edit The preprocessed file *** OS and Platform: Ubuntu 20.04.4 LTS *** gcc version: $ gcc -v Using built-in specs. COLLECT_GCC=/home/cuisk/ctc/gcc-releases/gcc-14/bin/gcc COLLECT_LTO_WRAPPER=/home/cuisk/ctc/gcc-releases/gcc-14/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/cuisk/ctc/gcc-releases/gcc-14 --disable-multilib --enable-language=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230924 (experimental) (GCC) *** Command Lines: $ gcc -I /home/cuisk/ctc/csmith/include/csmith-2.3.0 -O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-tree-dce -fno-tree-forwprop -fno-tree-fre /home/cuisk/gcc/tmp/a.c -o w 2>ce.txt during GIMPLE pass: vrp /home/cuisk/gcc/tmp/a.c: In function ‘func_56.constprop’: /home/cuisk/gcc/tmp/a.c:1807:16: internal compiler error: Segmentation fault 1807 | static int32_t func_56(int32_t p_57, uint32_t p_58, union U0 p_59) |^~~ 0x1023e4f crash_signal ../.././gcc/toplev.cc:314 0x7f10480b508f ??? /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x1358cea tree_check(tree_node*, char const*, int, char const*, tree_code) ../.././gcc/tree.h:3596 0x1358cea equiv_oracle::find_equiv_dom(tree_node*, basic_block_def*) const ../.././gcc/value-relation.cc:531 0x135ae6e equiv_oracle::equiv_set(tree_node*, basic_block_def*) ../.././gcc/value-relation.cc:471 0x1358b07 relation_oracle::valid_equivs(bitmap_head*, bitmap_head const*, basic_block_def*) ../.././gcc/value-relation.cc:277 0x1358e9e equiv_oracle::register_equiv(basic_block_def*, equiv_chain*, equiv_chain*) ../.././gcc/value-relation.cc:584 0x135934e equiv_oracle::register_relation(basic_block_def*, relation_kind_t, tree_node*, tree_node*) ../.././gcc/value-relation.cc:684 0x1dd5609 fold_using_range::range_of_range_op(vrange&, gimple_range_op_handler&, fur_source&) ../.././gcc/gimple-range-fold.cc:684 0x1dd5d60 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&, tree_node*) ../.././gcc/gimple-range-fold.cc:599 0x1dc59a0 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*) ../.././gcc/gimple-range.cc:265 0x1dc59a0 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*) ../.././gcc/gimple-range.cc:326 0x133c459 range_query::value_of_stmt(gimple*, tree_node*) ../.././gcc/value-query.cc:113 0x11f7d5f substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) ../.././gcc/tree-ssa-propagate.cc:820 0x1d77cde dom_walker::walk(basic_block_def*) ../.././gcc/domwalk.cc:311 0x11f6dd5 substitute_and_fold_engine::substitute_and_fold(basic_block_def*) ../.././gcc/tree-ssa-propagate.cc:999 0x13074fe execute_ranger_vrp(function*, bool, bool) ../.././gcc/tree-vrp.cc:1062 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report.
[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315 --- Comment #10 from Richard Biener --- (In reply to Andrew Macleod from comment #7) > Created attachment 55591 [details] > potental patch > > I've attached Aldy's patch for PR109695 which he had backported to GCC13 > back in May. > This does resolve the issue.. Assuming we want to apply it GCC13. The > original variant has been in trunk for a while now. Im running this thru a > bootstrap/regression run now. > > I don't know if there is anything further you want to try it with? Can we consider this please?
[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 --- Comment #12 from Mathieu Malaterre --- For reference malat@perotto ~/pr2 % g++-11 --version g++-11 (Debian 11.4.0-4) 11.4.0 malat@perotto ~/pr2 % g++-12 --version g++-12 (Debian 12.3.0-9) 12.3.0
[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 --- Comment #11 from Mathieu Malaterre --- (In reply to Kewen Lin from comment #6) > Confirmed, thanks for reporting. > > I noticed that the reduced test case in #c1 can make gcc-13 complain with: > > test.cc:67:16: error: expected type-specifier before ‘__remove_reference’ >67 | using type = __remove_reference(_Tp); > |^~ > > Also gcc-12, gcc-11 build. > > Is it expected? If yes, could we have a reduced test case to survive for > gcc-12 and gcc-11 compilation? I think it would help bisection. `__remove_reference` must be something new in g++-13. Anyway I started a cvise regression using g++-11 against g++-12. You can try on your side: g++-11 -std=c++11 -o works -maltivec -mcpu=power8 -mstrict-align -g -O3 widen_mul_test.cc foo.cc -Wall -Wextra -Werror -Wfatal-errors vs g++-12 -std=c++11 -o fails -maltivec -mcpu=power8 -mstrict-align -g -O3 widen_mul_test.cc foo.cc -Wall -Wextra -Werror -Wfatal-errors For some reason if I copy/paste foo.cc into the main cc file (gnu::noipa) I can not reproduce the issue. So you'll have to download both *.cc files. Thanks !
[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 --- Comment #10 from Mathieu Malaterre --- Created attachment 55993 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55993=edit widen_mul_test.cc
[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 --- Comment #9 from Mathieu Malaterre --- Created attachment 55992 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55992=edit foo.cc
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #12 from Xi Ruoyao --- (In reply to Mathieu Malaterre from comment #10) > I could not reduce to a single *.cc file. The function needs to be in an alt > file 'foo.cc'. Can you try copying the functions provided in foo.cc into the test case but and noipa attribute for them?
[Bug c/111598] New: Wimplicit-fallthrough print for a code that is not compiled in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111598
Bug ID: 111598
Summary: Wimplicit-fallthrough print for a code that is not
compiled in
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
When a switch-case has a "fallthrough" case that is surrounded by an `#ifdef`
and is not compiled in, GCC does not recognize the `// fallthrough` comment and
prints a `this statement may fall through` warning.
# Steps to reproduce
$ cat test2.c
#include
int main() {
enum {Field1, Field2} e = 0;
switch (e) {
case Field1:
puts("field1");
// fallthrough
#ifdef SOME_UNDEFINED_MACRO
case Field2:
puts("field2");
// fallthrough
#endif
default:
puts("default");
}
}
$ gcc test2.c -o /dev/null -Wimplicit-fallthrough
test2.c: In function ‘main’:
test2.c:7:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
7 | puts("field1");
| ^~
test2.c:14:9: note: here
14 | default:
| ^~~
## Expected
No warning, because every case ends with a fallthrough comment
## Actual
There's a warning
[Bug target/111597] pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597
--- Comment #3 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #0)
> In match.pd there is a pattern:
> /* ((T)(A)) + CST -> (T)(A + CST) */
> #if GIMPLE
> (simplify
>(plus (convert:s SSA_NAME@0) INTEGER_CST@1)
> (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
> && TREE_CODE (type) == INTEGER_TYPE
> && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
> && int_fits_type_p (@1, TREE_TYPE (@0)))
> /* Perform binary operation inside the cast if the constant fits
> and (A + CST)'s range does not overflow. *
>
> But this pattern seems not in favor of all targets.
> For example, the below code hits this pattern,
>
> long foo1 (int x)
> {
> if (x>1000)
> return 0;
> int x1 = x +1;
> return (long) x1 + 40;
>
> }
For this code, without the pattern "((T)(A)) + CST -> (T)(A + CST)",
the final gimple code is:
x1_4 = x_3(D) + 1;
_1 = (long int) x1_4;
_5 = _1 + 40;
With the pattern,
the final gimple code is:
_4 = x_2(D) + 41;
_3 = (long int) _4;
So, this pattern would be "reasonable".
[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 --- Comment #8 from Kewen Lin --- (In reply to Richard Biener from comment #7) > I suppose it works with -fno-tree-vectorize ontop of the flags? Appending -fno-tree-vectorize at the end of the given flags in #c1 (-mstrict-align version), it still fails.
[Bug middle-end/111547] [OpenMP] -fopenmp omp::decl update missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111547 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tobias Burnus --- FIXED on mainline/GCC 14
[Bug middle-end/111547] [OpenMP] -fopenmp omp::decl update missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111547 --- Comment #1 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:1fab441d6cce836e08db516c0fdac407872c6990 commit r14-4261-g1fab441d6cce836e08db516c0fdac407872c6990 Author: Tobias Burnus Date: Tue Sep 26 10:07:26 2023 +0200 invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic gcc/ChangeLog: PR middle-end/111547 * doc/invoke.texi (-fopenmp): Mention C++11 [[omp::decl(...)]] syntax. (-fopenmp-simd): Likewise. Clarify 'loop' directive semantic.
[Bug target/111597] pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- So it's only because the incoming x is sign-extended to long due to the ABI? Seems to be a quite "localized" issue. Btw, it was ppc folks requesting this pattern as a building block for a larger transform. It's always difficult to use canonicalizations to do simplifications.
[Bug target/111597] pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597 --- Comment #1 from Jiu Fu Guo --- While, even without this pattern in match.pd, the generated the sign extend(extsw) is still there. So, just wondering if this sub-optimal asm code would be fixed in another way.
[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- I suppose it works with -fno-tree-vectorize ontop of the flags?
[Bug target/111597] New: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597
Bug ID: 111597
Summary: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal
for ppc64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
In match.pd there is a pattern:
/* ((T)(A)) + CST -> (T)(A + CST) */
#if GIMPLE
(simplify
(plus (convert:s SSA_NAME@0) INTEGER_CST@1)
(if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
&& TREE_CODE (type) == INTEGER_TYPE
&& TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
&& int_fits_type_p (@1, TREE_TYPE (@0)))
/* Perform binary operation inside the cast if the constant fits
and (A + CST)'s range does not overflow. *
But this pattern seems not in favor of all targets.
For example, the below code hits this pattern,
long foo1 (int x)
{
if (x>1000)
return 0;
int x1 = x +1;
return (long) x1 + 40;
}
Compile with "-O2 -S", on ppc64le, the generated asm is:
cmpwi 0,3,1000
bgt 0,.L3
addi 3,3,41
extsw 3,3 ;; this is suboptimal
blr
.p2align 4,,15
.L3:
li 3,0
blr
--
But for the below code, the generated asm seems better: without
long foo1 (int x)
{
if (x>1000)
return 0;
return (long) x + 40;
}
cmpwi 0,3,1000
bgt 0,.L3
addi 3,3,40
blr
.p2align 4,,15
.L3:
li 3,0
blr
[Bug middle-end/94267] Missed folding of _MEM_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94267 --- Comment #5 from Richard Biener --- Well, yes .. _MEM_REF is a LEA with a specific addressing mode. Folding *_MEM_REF would require us to verify the target can handle it (and avoid PR110702 where it's fix was really the only sensible thing I could think of). We _might_ want to fold _MEM_REF[0 + ..] to '..', but the whole point of [&]TARGET_MEM_REF is to keep it until RTL expansion. Unless the folding is degenerate of course.
[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 Kewen Lin changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||linkw at gcc dot gnu.org, ||segher at gcc dot gnu.org Last reconfirmed||2023-09-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from Kewen Lin --- Confirmed, thanks for reporting. I noticed that the reduced test case in #c1 can make gcc-13 complain with: test.cc:67:16: error: expected type-specifier before ‘__remove_reference’ 67 | using type = __remove_reference(_Tp); |^~ Also gcc-12, gcc-11 build. Is it expected? If yes, could we have a reduced test case to survive for gcc-12 and gcc-11 compilation? I think it would help bisection.
[Bug c++/111596] New: ICE on iostream as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111596
Bug ID: 111596
Summary: ICE on iostream as argument
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stevenxia990430 at gmail dot com
Target Milestone: ---
The following invalid program reports an internal compiler error: Segmentation
fault. Failed on gcc-trunk.
To quickly reproduce: https://gcc.godbolt.org/z/bxEcPW5hE
```
#include
void println(std::iostream auto const &... args)
{
return;
}
```
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 --- Comment #11 from Mathieu Malaterre --- For reference: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-linux-gnueabihf/13/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-4' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --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-sjlj-exceptions --with-arch=armv7-a+fp --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.2.0 (Debian 13.2.0-4) COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 'fails' '-O2' '-g' '-Wfatal-errors' '-D' 'NDEBUG' '-fno-exceptions' '-mfpu=neon-vfpv4' '-mfloat-abi=hard' '-mfp16-format=ieee' '-Wno-psabi' '-shared-libgcc' '-mtls-dialect=gnu' '-mthumb' '-mlibarch=armv7-a+neon-vfpv4' '-march=armv7-a+neon-vfpv4' '-dumpdir' 'fails-' /usr/libexec/gcc/arm-linux-gnueabihf/13/cc1plus -quiet -v -imultilib . -imultiarch arm-linux-gnueabihf -D_GNU_SOURCE -D NDEBUG widen_mul_test.cc -quiet -dumpdir fails- -dumpbase widen_mul_test.cc -dumpbase-ext .cc -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee -mtls-dialect=gnu -mthumb -mlibarch=armv7-a+neon-vfpv4 -march=armv7-a+neon-vfpv4 -g -O2 -Wfatal-errors -Wno-psabi -std=c++11 -version -fno-exceptions -o /tmp/ccGJymG4.s GNU C++11 (Debian 13.2.0-4) version 13.2.0 (arm-linux-gnueabihf) compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "/usr/include/arm-linux-gnueabihf/c++/13" ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf" ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabihf/13/include-fixed/arm-linux-gnueabihf" ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabihf/13/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabihf/13/../../../../arm-linux-gnueabihf/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/13 /usr/include/arm-linux-gnueabihf/c++/13 /usr/include/c++/13/backward /usr/lib/gcc/arm-linux-gnueabihf/13/include /usr/local/include /usr/include/arm-linux-gnueabihf /usr/include End of search list. Compiler executable checksum: 613e27b019f0c34e86771fffeca58c78 COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 'fails' '-O2' '-g' '-Wfatal-errors' '-D' 'NDEBUG' '-fno-exceptions' '-mfpu=neon-vfpv4' '-mfloat-abi=hard' '-mfp16-format=ieee' '-Wno-psabi' '-shared-libgcc' '-mtls-dialect=gnu' '-mthumb' '-mlibarch=armv7-a+neon-vfpv4' '-march=armv7-a+neon-vfpv4' '-dumpdir' 'fails-' as -v -march=armv7-a+neon-vfpv4 -mfloat-abi=hard -mfpu=neon-vfpv4 -meabi=5 -o /tmp/ccUMFDCj.o /tmp/ccGJymG4.s GNU assembler version 2.41 (arm-linux-gnueabihf) using BFD version (GNU Binutils for Debian) 2.41 COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 'fails' '-O2' '-g' '-Wfatal-errors' '-D' 'NDEBUG' '-fno-exceptions' '-mfpu=neon-vfpv4' '-mfloat-abi=hard' '-mfp16-format=ieee' '-Wno-psabi' '-shared-libgcc' '-mtls-dialect=gnu' '-mthumb' '-mlibarch=armv7-a+neon-vfpv4' '-march=armv7-a+neon-vfpv4' '-dumpdir' 'fails-' /usr/libexec/gcc/arm-linux-gnueabihf/13/cc1plus -quiet -v -imultilib . -imultiarch arm-linux-gnueabihf -D_GNU_SOURCE -D NDEBUG foo.cc -quiet -dumpdir fails- -dumpbase foo.cc -dumpbase-ext .cc -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee -mtls-dialect=gnu -mthumb -mlibarch=armv7-a+neon-vfpv4 -march=armv7-a+neon-vfpv4 -g -O2 -Wfatal-errors -Wno-psabi -std=c++11 -version -fno-exceptions -o /tmp/ccGJymG4.s GNU C++11 (Debian 13.2.0-4) version 13.2.0 (arm-linux-gnueabihf) compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "/usr/include/arm-linux-gnueabihf/c++/13" ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf" ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabihf/13/include-fixed/arm-linux-gnueabihf" ignoring nonexistent directory
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 --- Comment #10 from Mathieu Malaterre --- I could not reduce to a single *.cc file. The function needs to be in an alt file 'foo.cc'. So could someone please compare: g++ -std=c++11 -o works -O2 -g -Wfatal-errors -Werror -Wall -Wextra -Wconversion -DNDEBUG -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee -Wno-psabi widen_mul_test.cc foo.cc with: g++ -std=c++11 -o fails -O2 -g -Wfatal-errors -DNDEBUG -fno-exceptions -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee -Wno-psabi widen_mul_test.cc foo.cc
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 --- Comment #9 from Mathieu Malaterre --- Created attachment 55991 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55991=edit widen_mul_test.cc
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 --- Comment #8 from Mathieu Malaterre --- Created attachment 55990 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55990=edit foo.cc
[Bug middle-end/111427] [14 regression] gfortran.dg/vect/pr60510.f fails after r14-3999-g3c834d85f2ec42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427 Kewen Lin changed: What|Removed |Added Last reconfirmed||2023-09-26 Keywords|ra, wrong-code |testsuite-fail Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org CC||linkw at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Kewen Lin --- I found it can be reproduced on Power8 but not on Power9 (BE since only BE supports -m32). The option can be reduced to: opts="-m32 -funroll-loops -O2 -mcpu=power8" Looking into the affected test case, IMHO this is a test issue: subroutine foo(a,x,y,n) implicit none integer n,i real*8 y(n),x(n),a do i=1,n a=a+x(i)*y(i)+x(i) enddo return end program test real*8 x(1024),y(1024),a===> line A do i=1,1024 x(i) = i y(i) = i+1 enddo call foo(a,x,y,1024) if (a.ne.359488000.0) STOP 1 end The variable a in line A is an uninitialized variable. Without the culprit commit, the address of the passed a is 0xfffeec30: Dump of assembler code for function MAIN__: 0x18b0 <+0>: stwur1,-16416(r1) ... 0x19f4 <+324>: lis r12,4096 0x19f8 <+328>: addir5,r1,16 0x19fc <+332>: addir4,r1,8208 0x1a00 <+336>: addir3,r1,16400 0x1a04 <+340>: addir6,r12,3160 => 0x1a08 <+344>: bl 0x1620 (gdb) i r r3 r3 0xfffeec30 4294896688 (gdb) x /2x 0xfffeec30 0xfffeec30: 0x1524 0x the random value of "a" is 0x1524, a tiny float value (1.289846527864432e-231) and doesn't cause the comparison to fail. With the culprit commit, the address of the passed a is 0xfffeec20: 18b0 : 18b0: 94 21 bf d0 stwur1,-16432(r1) 18b4: 3d 20 10 00 lis r9,4096 ... (gdb) x /2x 0xfffeec20 0xfffeec20: 0xfffeec40 0x0fddd03c (gdb) i r r3 r3 0xfffeec20 4294896672 the random value of "a" is 0xfffeec400fddd03c, which is NAN, so it causes the comparison to fail. I'm not sure why this doesn't get exposed before (so lucky), but an explicit initialization for a should fix this.
