[Bug libstdc++/83662] std::aligned_alloc() not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83662 --- Comment #11 from Andrew Pinski --- (In reply to Sergey Fedorov from comment #10) > I just got the same error with gcc 12.3.0: > https://github.com/kokkos/kokkos/issues/6367 This should be filed seperately as it is a darwin target specific issue; most likely just powerpc darwin (Mac OS X) which is likely not as well supported as x86_64 darwin ...
[Bug libstdc++/83662] std::aligned_alloc() not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83662 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #10 from Sergey Fedorov --- I just got the same error with gcc 12.3.0: https://github.com/kokkos/kokkos/issues/6367 /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_kokkos/kokkos-devel/work/kokkos-ca3687e637c12225e824ee626e69fc9fea8cebd2/core/src/impl/Kokkos_HostSpace.cpp: In member function 'void* Kokkos::HostSpace::impl_allocate(const char*, size_t, size_t, Kokkos::Tools::SpaceHandle) const': /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_kokkos/kokkos-devel/work/kokkos-ca3687e637c12225e824ee626e69fc9fea8cebd2/core/src/impl/Kokkos_HostSpace.cpp:95:16: error: 'aligned_alloc' is not a member of 'std'; did you mean 'aligned_union'? 95 | ptr = std::aligned_alloc(alignment, size); |^ |aligned_union make[2]: *** [core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_HostSpace.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs Passing -std=c++17 does not help.
[Bug tree-optimization/100082] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100082 --- Comment #3 from Andrew Pinski --- Looks like it is jump threading differences between GCC 11 and GCC 12 which fixes this.
[Bug ipa/101813] -O3 does worse at dead code elimination than -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101813 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- GCC considers main as called once only so it inlines less into it (without being inside a loop). So changing main to f (and adding a `return 0;` at the end), GCC is also able to optimize the code. Also on the trunk GCC is able to optmize the code out even without changing the name due to improvements to the inlining heuristics. So closing as fixed for GCC 14. (and could have been closed as won't fix for before GCC 13 too before too).
[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051 --- Comment #2 from Haochen Jiang --- It is caused by when including immintrin.h, since the pragma is removed, there will be no AVX support, which makes _mm256_setzero_pd invisible. Adding a AVX2 pragma instead of removing it should solve the problem. I am working a patch on that.
[Bug target/93176] PPC: inefficient 64-bit constant consecutive ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176 Peter Bergner changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org, ||linkw at gcc dot gnu.org --- Comment #9 from Peter Bergner --- Jeff, none of your constant generation patches covers this, correct? If not, maybe given your recent work on improving the code gen for contents, maybe you could pick up the patch and shepherd it to approval? I would like to see this work finally committed.
[Bug ipa/100314] missed optimization for dead code elimination at -O3 (vs. -O1) (inlining differences due to missed dse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100314 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100188 --- Comment #5 from Andrew Pinski --- (In reply to Richard Biener from comment #2) > the key is to notice that 'a' is not modified and thus zero and propagate > that to 'd'. With -O3 IPA figures out 'a' is not modified but that isn't > taken into And that is the same issue as PR 100188 (and maybe others).
[Bug ipa/100220] missed optimization for dead code elimination at -O3 (vs. -O1, -Os, -O2) (inlining differences)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100220 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||13.1.0 --- Comment #4 from Andrew Pinski --- Seems to be fixed in GCC 13.1.0.
[Bug tree-optimization/100113] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100113 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106922 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Looks to be fixed in GCC 12.3.0 and GCC 13.1.0 . A change in PRE which causes the IR to be different and allowed to be optimized away in DOM3
[Bug tree-optimization/100113] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100113 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to fail||12.2.0 Known to work||12.3.0, 13.1.0 --- Comment #2 from Andrew Pinski --- Looks to be fixed in GCC 12.3.0 and GCC 13.1.0 .
[Bug ipa/100191] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100191 Andrew Pinski changed: What|Removed |Added Known to work||12.1.0 Known to fail||11.4.0 Keywords||needs-bisection --- Comment #2 from Andrew Pinski --- Looks to be fixed in GCC 12.1.0.
[Bug ipa/100188] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100188 --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > At -O3 we inline less, keeping the call to d() in main(). We then fail to > constant propagate the const promoted 'b'. So yes we do inline less kinda of. At -O3, we inline a into main in einline (but not at -O1) and this somehow allows us to inline d into main during the IPA inline phase. > Not sure why IPA CP doesn't get it (promotion happens too late?). Yes promotion to constant of b happens after IPA CP. I wonder if could run static-var twice once before even eiline ...
[Bug sanitizer/111057] [11/12/13 only] build error: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10: fatal error: crypt.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057 --- Comment #5 from Chris Packham --- Created attachment 55751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55751=edit Remove crypt and crypt_r interceptors Attached is the patch derived from https://github.com/llvm/llvm-project/commit/d7bead833631486e337e541e692d9b4a1ca14edd which we'll be carrying in crosstool-ng. I've kept the upstream authors and commit message. It should apply cleanly to the releases/gcc-13 branch but is not necessary for 14.x.
[Bug ipa/78790] Disable IPA-VRP for noclone functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78790 --- Comment #2 from Andrew Pinski --- noipa was added in GCC 8, which fixes the testsuite writing issue so maybe this can be closed as won't fix ...
[Bug ipa/99834] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99834 --- Comment #3 from Andrew Pinski --- The other way of optimizing this is to see that the return value of d is 0 (even early on) and do a const prop of that ... IN a sense an IPA-CCP for return values rather than for argument passing.
[Bug tree-optimization/99788] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99788 Andrew Pinski changed: What|Removed |Added Known to work||12.1.0 Keywords||needs-bisection --- Comment #3 from Andrew Pinski --- Looks to be fixed in gcc 12
[Bug sanitizer/111057] [11/12/13 only] build error: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10: fatal error: crypt.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057 --- Comment #4 from Chris Packham --- (In reply to Andrew Pinski from comment #1) > What version of glibc is being built with here? glibc-2.38 > Most likely could backport: > > https://github.com/llvm/llvm-project/commit/d7bead833631486e337e541e692d9b4a1ca14edd Yes looks as though that'd do it. I'll try and whip that up for ct-ng to carry. Do you want me to try for a proper GCC patch as well?
[Bug sanitizer/111057] [11/12/13 only] build error: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10: fatal error: crypt.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- .
[Bug sanitizer/111057] [11/12/13 only] build error: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10: fatal error: crypt.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057 Andrew Pinski changed: What|Removed |Added Summary|build error:|[11/12/13 only] build |libsanitizer/sanitizer_comm |error: |on/sanitizer_platform_limit |libsanitizer/sanitizer_comm |s_posix.cpp:180:10: fatal |on/sanitizer_platform_limit |error: crypt.h: No such |s_posix.cpp:180:10: fatal |file or directory |error: crypt.h: No such ||file or directory Known to work||14.0 Target Milestone|--- |11.5
[Bug sanitizer/111057] build error: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10: fatal error: crypt.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057 --- Comment #2 from Andrew Pinski --- Most likely could backport: https://github.com/llvm/llvm-project/commit/d7bead833631486e337e541e692d9b4a1ca14edd
[Bug sanitizer/111057] build error: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10: fatal error: crypt.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057 --- Comment #1 from Andrew Pinski --- What version of glibc is being built with here?
[Bug sanitizer/111057] New: build error: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10: fatal error: crypt.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057
Bug ID: 111057
Summary: build error:
libsanitizer/sanitizer_common/sanitizer_platform_limit
s_posix.cpp:180:10: fatal error: crypt.h: No such file
or directory
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: judge.packham at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hi from crosstool-ng,
I've had a user report a build error for GCC 13.2.0 with and aarch64 config
with libsanitizer enabled
(https://github.com/crosstool-ng/crosstool-ng/issues/2010).
[ERROR]
/home/ctng/crosstool-ng/.build/aarch64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10:
fatal error: crypt.h: No such file or directory
[ALL ] 180 | #include
[ALL ] | ^
[ALL ]compilation terminated.
[ERROR]make[5]: *** [Makefile:614: sanitizer_platform_limits_posix.lo]
Error 1
[ERROR]make[5]: *** Waiting for unfinished jobs
It looks like this may have already been fixed in master by commit d96e14ceb947
("libsanitizer: merge from upstream (87e6e490e79384a5)"). Is that the kind of
thing that might end up in the 13.x branch? Alternatively is there a lower
impact change that might be back-ported?
Thanks,
Chris
[Bug c/111056] Missing -Wsign-compare warning with enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111056 --- Comment #4 from Andrew Pinski --- (In reply to Alex Henrie from comment #3) > I imagine that it would be difficult to change GCC's behavior to match > Clang's in this case. Except GCC does not warn at -O1 and above (there are a few other bug reports about the difference at -O0 and -O1 already, e.g. PR 92507)
[Bug target/93176] PPC: inefficient 64-bit constant consecutive ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176 Alan Modra changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|amodra at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #8 from Alan Modra --- Nothing happened. The patch wasn't reviewed. I didn't ping the patch. I'm not working on gcc any more, so should remove myself as assignee for this bug.
[Bug c/111056] Missing -Wsign-compare warning with enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111056
--- Comment #3 from Alex Henrie ---
By the way, thanks for pointing out that using constexpr suppresses the warning
on GCC. Although Clang does not support constexpr in C yet, it is interesting
that Clang is smart enough to not warn about a plain const:
const int a = 1;
unsigned int b = 2;
if (a < b) // warning here on GCC, but not on Clang
puts("a < b");
I imagine that it would be difficult to change GCC's behavior to match Clang's
in this case.
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #9 from David Malcolm --- (In reply to David Malcolm from comment #4) > Some ideas of projects we could analyze: https://github.com/fedora-python/python-ethtool (Although deprecated, it's relatively small and has been ported to Python 3)
[Bug c/111056] Missing -Wsign-compare warning with enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111056 Alex Henrie changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Alex Henrie --- You're right, the second warning is unnecessary because the behavior there is not counterintuitive (although it would have been more clear if I had written `c = UINT32_MAX` instead of `c = -1`). It's a bad example, sorry for the noise. GCC does warn about legitimately counterintuitive comparisons involving enums.
[Bug c/111056] Missing -Wsign-compare warning with enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111056
--- Comment #1 from Andrew Pinski ---
We don't warn for the same reason as we don't warn for `constexpr` because the
value is known at compile time.
That is:
```
#include
int main()
{
signed int a = 1;
enum : signed int { b = 1 }d = b;
constexpr int t = 1;
unsigned int c = -1;
if (a < c) // condition is true, -Wsign-compare warns about it
puts("a < c");
if (t < c) // condition is true, but no warning
puts("t < c");
if (b < c) // condition is true, but no warning
puts("b < c");
if (d < c) // condition is true, -Wsign-compare warns about it
puts("d < c");
return 0;
}
```
`t` and `b` here are replaced with 1. But with a variable that is declared as
the enum type we do warn.
I think this is correct behavior really.
clang has the same behavior (well they don't yet support constexpr though).
[Bug middle-end/111054] [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug c/111056] New: Missing -Wsign-compare warning with enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111056
Bug ID: 111056
Summary: Missing -Wsign-compare warning with enum values
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alexhenrie24 at gmail dot com
Target Milestone: ---
#include
int main()
{
signed int a = 1;
enum : signed int { b = 1 };
unsigned int c = -1;
if (a < c) // condition is true, -Wsign-compare warns about it
puts("a < c");
if (b < c) // condition is true, but no warning
puts("b < c");
return 0;
}
The compiler should warn about both if statements.
$ gcc --version
gcc (GCC) 13.2.1 20230801
[Bug target/96233] XGCC-10.1.0 for Target RX: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96233 --- Comment #1 from Hans-Peter Beständig --- Created attachment 55750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55750=edit Bugreport as proposed by using -freport-bug
[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Blocks||111053 Last reconfirmed||2023-08-17 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111053 [Bug 111053] std::ranges::copy is missing important optimizations
[Bug libstdc++/111055] New: [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 Bug ID: 111055 Summary: [C++23] Implement P1206R7, Conversions from ranges to containers Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 106749 Target Milestone: --- https://wg21.link/P1206R7 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 [Bug 106749] Implement C++23 library features
[Bug target/111045] PCREL should not be supported on BE ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111045 Peter Bergner changed: What|Removed |Added CC||linkw at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #2 from Peter Bergner --- Technically, the only ABI that officially supports it is our 64-bit LE ELFv2 ABI. I'm sure it could work on others, but I'm not sure all the i's have been dotted and the t's crossed to say for sure that it does, so it's probably safest to just disable it everywhere other than 64-bit LE ELFv2.
[Bug middle-end/111054] New: [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054 Bug ID: 111054 Summary: [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 55749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55749=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O3 -fno-guess-branch-probability testcase.c during GIMPLE pass: lsplit testcase.c: In function 'foo': testcase.c:5:1: internal compiler error: in to_sreal, at profile-count.cc:472 5 | foo (void) | ^~~ 0x7c20ad profile_probability::to_sreal() const /repo/gcc-trunk/gcc/profile-count.cc:472 0x16112e2 split_loop /repo/gcc-trunk/gcc/tree-ssa-loop-split.cc:716 0x1611d89 tree_ssa_split_loops /repo/gcc-trunk/gcc/tree-ssa-loop-split.cc:1773 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-3275-20230817153757-gc6259c4975e-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-3275-20230817153757-gc6259c4975e-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230817 (experimental) (GCC)
[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051
--- Comment #1 from Sergei Trofimovich ---
Found this difference, looks reasonable?
// $ cat a.cc
#include
#pragma GCC target("avx512vl,avx512dq")
void bug(__m256i i) {
volatile auto v1 = _mm256_cvtepi64_pd(i);
}
Difference:
$ g++-13 -c a.cc
# ok
$ g++-14 -c a.cc
In file included from
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/immintrin.h:71,
from a.cc:1:
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:
In function '__m256d _mm256_cvtepi64_pd(__m256i)':
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:910:1:
note: the ABI for passing parameters with 32-byte alignment has changed in GCC
4.6
910 | _mm256_cvtepi64_pd (__m256i __A)
| ^~
a.cc:7:1: warning: AVX vector return without AVX enabled changes the ABI
[-Wpsabi]
7 | }
| ^
In file included from
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/immintrin.h:43:
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1:
error: inlining failed in call to 'always_inline' '__m256d
_mm256_setzero_pd()': target specific option mismatch
1238 | _mm256_setzero_pd (void)
| ^
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:912:10:
note: called from here
912 | return (__m256d) __builtin_ia32_cvtqq2pd256_mask ((__v4di) __A,
| ^~~~
913 | (__v4df)
|
914 | _mm256_setzero_pd
(),
|
~
915 | (__mmask8) -1);
| ~~
[Bug libstdc++/111053] New: std::ranges::copy is missing important optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111053
Bug ID: 111053
Summary: std::ranges::copy is missing important optimizations
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 111052
Target Milestone: ---
std::copy is overloaded for a few special cases, like deque iterators and
ostreambuf_iterators. std::ranges::copy is missing these optimizations.
__copy_or_move(_Iter __first, _Sent __last, _Out __result)
{
// TODO: implement more specializations to be at least on par with
// std::copy/std::move.
We should optimize copying a range to an ostreambuf_iterator, as we do for
std::copy.
We should optimize copying to/from a deque, by working on a whole page at a
time.
As mentioned in Bug 111052 comment 1 we could optimize copying a range to
back_insert_iterator by calling C::insert to insert the whole range at once
(this might need ranges::to support first, so it
isn't limited to Cpp17Iterators). Similarly for insert iterators.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111052
[Bug 111052] std::format_to(std::back_inserter(str), "") should write directly
to the string
[Bug libstdc++/111052] std::format_to(std::back_inserter(str), "") should write directly to the string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111052 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-17 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Alternatively, we could add a special case to ranges::copy so that copying a range to a back_insert_iterator uses string::append instead of writing one element at a time. That would benefit more than just std::format_to. But we might still want to do extract a back_insert_iterator's string into a _Seq_sink, because that would allow us to write directly to the string instead of buffering and then copying to it on overflow. We should also make ranges::copy implement the std::copy optimization for copying to ostreambuf_iterator, which is an important performance enhancement. That will benefit: std::format_to(std::ostreambuf_iterator(std::cout), ""); The _Iter_sink<_CharT, _Iter> could recognise an ostreambuf_iterator and use std::copy, but we should really just make ranges::copy do those optimizations.
[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Severity|normal |blocker Keywords||rejects-valid
[Bug libstdc++/111052] New: std::format_to(std::back_inserter(str), "") should write directly to the string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111052 Bug ID: 111052 Summary: std::format_to(std::back_inserter(str), "") should write directly to the string Product: gcc Version: 13.1.1 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- fmt::format_to has a nice optimization where it recognizes a back_insert_iterator and extracts the contained string so that it can format directly to the string, instead of writing one character at a time through the output iterator. We could get the string, move it into a _Seq_sink to format into it, then move assign (or swap) the populated string back to the original one that the iterator referred to.
[Bug target/111051] New: [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051
Bug ID: 111051
Summary: [14 Regression] highway-1.0.6 fails to build as
gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/inc
lude/avxintrin.h:1238:1: error: inlining failed in
call to 'always_inline' '__m256d _mm256_setzero_pd()':
target specific option mismatch
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Observed build failure on today's gcc from r14-3296-gdc48d1d1d44587 against
highway-1.0.6 ( https://github.com/google/highway ).
I have not managed to extract nice example ot of it yet, but maybe it's obvious
to you?
The (somewhat big) reproducer is:
$ git clone https://github.com/google/highway
$ cd highway
$ mkdir b
$ cd b
$ cmake .. -DCMAKE_BUILD_TYPE=Release
$ make
...
LANG=C /nix/store/vmrxs83fhqs6d3gsyg97hh0lbfzhk9jl-gcc-wrapper-14.0.0/bin/g++
-DHWY_STATIC_DEFINE -DTOOLCHAIN_MISS_ASM_HWCAP_H -I/home/slyfox/dev/git/highway
-isystem /home/slyfox/dev/git/highway/b/googletest-src/googletest/include
-isystem /home/slyfox/dev/git/highway/b/googletest-src/googletest -O3 -DNDEBUG
-fPIE -fvisibility=hidden -fvisibility-inlines-hidden
-Wno-builtin-macro-redefined -D__DATE__=\"redacted\"
-D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants
-Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor
-fmath-errno -fno-exceptions -DHWY_IS_TEST=1 -MD -MT
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o -MF
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o.d -o
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o -c
/home/slyfox/dev/git/highway/hwy/contrib/math/math_test.cc
In file included from
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/immintrin.h:71,
from /home/slyfox/dev/git/highway/hwy/ops/x86_256-inl.h:36,
from /home/slyfox/dev/git/highway/hwy/highway.h:407,
from
/home/slyfox/dev/git/highway/hwy/contrib/math/math_test.cc:25,
from /home/slyfox/dev/git/highway/hwy/foreach_target.h:94,
from
/home/slyfox/dev/git/highway/hwy/contrib/math/math_test.cc:24:
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:
In function '__m256 _mm256_mask_xor_ps(__m256, __mmask8, __m256, __m256)':
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:1154:1:
note: the ABI for passing parameters with 32-byte alignment has changed in GCC
4.6
1154 | _mm256_mask_xor_ps (__m256 __W, __mmask8 __U, __m256 __A, __m256 __B)
| ^~
/home/slyfox/dev/git/highway/hwy/contrib/math/math_test.cc:439:1: warning: AVX
vector return without AVX enabled changes the ABI [-Wpsabi]
439 | } // namespace hwy
| ^
In file included from
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/immintrin.h:43:
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:
In function '__m256d _mm256_cvtepi64_pd(__m256i)':
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1:
error: inlining failed in call to 'always_inline' '__m256d
_mm256_setzero_pd()': target specific option mismatch
1238 | _mm256_setzero_pd (void)
| ^
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:912:10:
note: called from here
912 | return (__m256d) __builtin_ia32_cvtqq2pd256_mask ((__v4di) __A,
| ^~~~
913 | (__v4df)
|
914 | _mm256_setzero_pd
(),
|
~
915 | (__mmask8) -1);
| ~~
I have a suspiction it's related to AVX10 changes, like
r14-3268-g0b20e0f17b47a8 which remove `#pragma GCC
target("avx512vl,avx512dq")`. Probably not that one specifically though.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.0
[Bug libstdc++/110945] std::basic_string::assign dramatically slower than other means of copying memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945 --- Comment #16 from Jonathan Wakely --- Fixed on trunk. This seems worth considering for backports later though.
[Bug libstdc++/110945] std::basic_string::assign dramatically slower than other means of copying memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945 --- Comment #15 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cc3d7baf2741777e99567d4301802c99f5775619 commit r14-3306-gcc3d7baf2741777e99567d4301802c99f5775619 Author: Jonathan Wakely Date: Tue Aug 8 16:31:42 2023 +0100 libstdc++: Optimize std::string::assign(Iter, Iter) [PR110945] Calling string::assign(Iter, Iter) with "foreign" iterators (not the string's own iterator or pointer types) currently constructs a temporary string and then calls replace to copy the characters from it. That means we copy from the iterators twice, and if the replace operation has to grow the string then we also allocate twice. By using *this = basic_string(first, last, get_allocator()) we only perform a single allocation+copy and then do a cheap move assignment instead of a second copy (and possible allocation). But that alternative has to be done conditionally, so that we don't pessimize the native iterator case (the string's own iterator and pointer types) which currently select efficient overloads of replace which will not allocate at all if the string already has sufficient capacity. For C++20 we can extend that efficient case to work for any contiguous iterator with the right value type, not just for the string's native iterators. So the change is to inline the code that decides whether to work in place or to allocate+copy (instead of deciding that via overload resolution for replace), and for the allocate+copy case do a move assignment instead of another call to replace. For C++98 there is no change, as we can't do an efficient move assignment anyway, so keep the current code. We can also simplify assign(initializer_list) because the backing array for an initializer_list is always disjunct with *this, so most of the code in _M_replace is not needed. libstdc++-v3/ChangeLog: PR libstdc++/110945 * include/bits/basic_string.h (basic_string::assign(Iter, Iter)): Dispatch to _M_replace or move assignment from a temporary, based on the iterator type.
[Bug fortran/110825] TYPE(*) dummy argument to generate an unused hidden argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110825 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |13.3 --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing.
[Bug other/58312] libssp configure check for "usable vsnprintf" is broken on cross-compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #11 from Eric Gallager --- Created attachment 55748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55748=edit rejects file for libssp/configure
[Bug other/58312] libssp configure check for "usable vsnprintf" is broken on cross-compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #10 from Eric Gallager --- Created attachment 55747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55747=edit rejects file for libssp/configure.ac
[Bug other/58312] libssp configure check for "usable vsnprintf" is broken on cross-compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #9 from Eric Gallager --- (In reply to Eric Gallager from comment #8) > So I tried applying the patch against current gcc sources, and got these > results: > > $ patch < /Users/ericgallager/Downloads/2013-09-03_libssp-configure.diff > patching file configure.ac > Hunk #1 FAILED at 125. > 1 out of 1 hunk FAILED -- saving rejects to file configure.ac.rej > patching file configure > Hunk #1 FAILED at 4505. > Hunk #2 FAILED at 10620. > Hunk #3 FAILED at 10726. > 3 out of 3 hunks FAILED -- saving rejects to file configure.rej > $ > > I'll attach my rejects files next. oh wait I'm stupid, I was applying it from the wrong directory... trying applying it to libssp specifically still fails, though: $ patch < /Users/ericgallager/Downloads/2013-09-03_libssp-configure.diff patching file configure.ac Hunk #1 FAILED at 125. 1 out of 1 hunk FAILED -- saving rejects to file configure.ac.rej patching file configure Hunk #1 succeeded at 4836 (offset 331 lines). Hunk #2 FAILED at 10951. Hunk #3 FAILED at 11057. 2 out of 3 hunks FAILED -- saving rejects to file configure.rej $
[Bug other/58312] libssp configure check for "usable vsnprintf" is broken on cross-compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #8 from Eric Gallager --- So I tried applying the patch against current gcc sources, and got these results: $ patch < /Users/ericgallager/Downloads/2013-09-03_libssp-configure.diff patching file configure.ac Hunk #1 FAILED at 125. 1 out of 1 hunk FAILED -- saving rejects to file configure.ac.rej patching file configure Hunk #1 FAILED at 4505. Hunk #2 FAILED at 10620. Hunk #3 FAILED at 10726. 3 out of 3 hunks FAILED -- saving rejects to file configure.rej $ I'll attach my rejects files next.
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 Mikael Morin changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-17 CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- Confirmed on the reduced example from comment #2. The problem arises because of the bogus subroutine statement: SUBROUTINE c(d) e This is rejected and symbols C and D should be released (no symbol has been built for E at the time the statement is rejected). D is released, but C is not, and it keeps a pointer to D through it's formal field. BOOM. The reason C is not released is its reference count is 2 and the condition to break cycles at the beginning of gfc_release_symbol doesn't hold: 3118 if (sym->formal_ns != NULL && sym->refs == 2 && sym->formal_ns != sym->ns 3119 && (!sym->attr.entry || !sym->module)) Here sym->formal_ns is NULL because the symbol C has not been completely setup.
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-08-17 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug middle-end/111009] [12/13/14 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009 --- Comment #12 from Sergei Trofimovich --- I confirm the change fixed `perf` startup for me. Thank you!
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 Eric Gallager changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-August/ ||627793.html Keywords||patch --- Comment #34 from Eric Gallager --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627793.html
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #8 from David Malcolm --- (In reply to David Malcolm from comment #4) > Some ideas of projects we could analyze: * https://pypi.org/project/mercurial/ ; see: https://repo.mercurial-scm.org/hg-stable/file/tip/mercurial/cext
[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77517 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||10.5.0, 11.4.1, 12.3.1, ||13.2.1, 14.0, 9.5.0 Known to fail||7.5.0, 8.5.0 Status|NEW |WAITING --- Comment #9 from anlauf at gcc dot gnu.org --- It appears that all testcases in this PR give more or less meaningful error messages for >= 9.5.0, and error recovery is clean under valgrind. I think this one can be closed.
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #7 from David Malcolm --- (In reply to David Malcolm from comment #6) > (In reply to David Malcolm from comment #5) > Some attribute ideas: > > extern int PyDict_SetItem(PyObject *p, PyObject *key, PyObject *val) > __attribute__((cpython_param_must_be_hashable (key)) ...though this implies supporting parameter names in attributes (is there a BZ for this?)
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #6 from David Malcolm --- (In reply to David Malcolm from comment #5) > How precisely to track behavior of API entrypoints? We can’t implement > known_functions that precisely model every entrypoint. > > Consider: > https://docs.python.org/3/c-api/dict.html#c.PyDict_SetItem Some attribute ideas: extern int PyDict_SetItem(PyObject *p, PyObject *key, PyObject *val) __attribute__((cpython_param_must_be_hashable (key)) __attribute__((return_val_on_success (0)) __attribute__((return_val_on_failure (-1)) __attribute__((cpython_param_incremented_on_success (key)) __attribute__((cpython_param_untouched_on_success (val)) ;
[Bug tree-optimization/111049] spurious stringop-overflow depending on structure pointer arithmetic with certain sized structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111049 --- Comment #1 from Andrew Pinski --- Looks like this is fixed for GCC 11.
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #5 from David Malcolm --- How precisely to track behavior of API entrypoints? We can’t implement known_functions that precisely model every entrypoint. Consider: https://docs.python.org/3/c-api/dict.html#c.PyDict_SetItem which has: Insert val into the dictionary p with a key of key. key must be hashable; if it isn’t, TypeError will be raised. Return 0 on success or -1 on failure. This function does not steal a reference to val. How much of this could be expressed via function attributes, rather than known_function subclasses? List of 20 most commonly used CPython API entrypoints from my 2013 survey: https://fedorapeople.org/~dmalcolm/presentations/PyCon-US-2013/PyCon-US-2013-dmalcolm-StaticAnalysis.html#(25)
[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Component|middle-end |tree-optimization
Last reconfirmed||2023-08-17
--- Comment #2 from Andrew Pinski ---
Setting value number of vect__4.12_36 to { 255, 63, 15, 3, 255, 63, 15, 3, 255,
63, 15, 3, 255, 63, 15, 3 } (changed)
Match-and-simplified VEC_PERM_EXPR <{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 }, vect__4.12_36, { 0, 16, 1, 17, 2, 18, 3, 19, 4, 20, 5, 21, 6, 22, 7, 23
}> to { 0, 255, 0, 63, 0, 15, 0, 3, 0, 255, 0, 63, 0, 239, 0, 123 }
Confirmed that is definitely wrong. I don't even know where 239 and 123 came
from ...
[Bug fortran/110995] segfault for function in declaration of module function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110995 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=58157 --- Comment #2 from anlauf at gcc dot gnu.org --- PR58157 is likely related.
[Bug middle-end/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||wrong-code Target||x86_64-linux-gnu Component|target |middle-end
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #4 from David Malcolm --- Some ideas of projects we could analyze: - minimal Cython-generated C file - https://pypi.org/project/psycopg2/ - https://pypi.org/project/numpy
[Bug middle-end/111009] [12/13/14 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009 --- Comment #11 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:dc48d1d1d4458773f89f21b2f019f66ddf88f2e5 commit r14-3296-gdc48d1d1d4458773f89f21b2f019f66ddf88f2e5 Author: Andrew MacLeod Date: Thu Aug 17 11:13:14 2023 -0400 Fix range-ops operator_addr. Lack of symbolic information prevents op1_range from beig able to draw the same conclusions as fold_range can. PR tree-optimization/111009 gcc/ * range-op.cc (operator_addr_expr::op1_range): Be more restrictive. gcc/testsuite/ * gcc.dg/pr111009.c: New.
[Bug libstdc++/110801] std::format code runs slower than equivalent {fmt} code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110801
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Created attachment 55739 [details]
> Add special case for format("{}", integer)
The _Seq_sink::_M_get_pointer and _Iter_sink::_M_get_pointer overrides in this
patch are broken. They assume that no other output has already been done to the
sink, but that isn't true if you have a formatter that writes some output then
uses format("{}", i) to write some more (e.g. chrono formatters). The
format("{}", i) call will use the new fast path and call _M_get_pointer which
currently gives a pointer to the start of the buffer, but that overwrites
anything already written there.
I have a fix for that.
[Bug target/108790] bpf: gcc emits malformed ldxdw instruction at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108790 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||jemarch at gcc dot gnu.org --- Comment #2 from Jose E. Marchesi --- Fixed by the commit above.
[Bug target/110782] bpf: make use of the V4 sign-extended load instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110782 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed by the commit above.
[Bug target/110784] bpf: make use of the V4 sign-extended move instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110784 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed by the commit above.
[Bug target/110770] bpf: add pseudoc assembly dialect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110770 Jose E. Marchesi changed: What|Removed |Added CC||jemarch at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed by commit above.
[Bug target/111029] bpf: GCC generates invalid instructions wN = (s8) rM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111029 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed by the commit above.
[Bug target/111047] Un-silenceable note for ABI parameters 64-byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111047 --- Comment #3 from gnzlbg --- Thank you both. > should probably output "[-Wpsabi]" to make this clear. +1
[Bug libstdc++/108827] [C++23] Implement P2387R3, Pipe support for user-defined range adaptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108827 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4a6f3676e7dd9e73a822f4da634b037299f0d482 commit r14-3293-g4a6f3676e7dd9e73a822f4da634b037299f0d482 Author: Patrick Palka Date: Thu Aug 17 12:40:04 2023 -0400 libstdc++: Convert _RangeAdaptorClosure into a CRTP base [PR108827] Using the CRTP idiom for this base class avoids bloating the size of a pipeline when adding distinct empty range adaptor closure objects to it, as detailed in section 4.1 of P2387R3. But it means we can no longer define its operator| overloads as hidden friends, since it'd mean each instantiation of _RangeAdaptorClosure introduces its own distinct set of hidden friends. So e.g. for the outer | in x | (views::reverse | views::join) ADL would find 6 distinct hidden operator| friends: two from _RangeAdaptorClosure<_Reverse> two from _RangeAdaptorClosure<_Join> two from _RangeAdaptorClosure<_Pipe<_Reverse, _Join>> but we really only want to consider the last two. We avoid this issue by instead defining the operator| overloads at namespace scope alongside _RangeAdaptorClosure. This should be fine because the only types defined in this namespace are _RangeAdaptorClosure, _RangeAdaptor, _Pipe and _Partial, so we don't have to worry about unintentional ADL. Reviewed-by: Jonathan Wakely PR libstdc++/108827 libstdc++-v3/ChangeLog: * include/std/ranges (__adaptor::_RangeAdaptorClosure): Convert into a CRTP class template. Move hidden operator| friends into namespace scope and adjust their constraints. (__closure::__is_range_adaptor_closure_fn): Define. (__closure::__is_range_adaptor_closure): Define. (__adaptor::_Partial): Adjust use of _RangeAdaptorClosure. (__adaptor::_Pipe): Likewise. (views::_All): Likewise. (views::_Join): Likewise. (views::_Common): Likewise. (views::_Reverse): Likewise. (views::_Elements): Likewise. (views::_Adjacent): Likewise. (views::_AsRvalue): Likewise. (views::_Enumerate): Likewise. (views::_AsConst): Likewise. * testsuite/std/ranges/adaptors/all.cc: Reinstate assertion expecting that adding empty range adaptor closure objects to a pipeline doesn't increase the size of a pipeline.
[Bug c++/109751] [13/14 Regression] boost iterator_interface fails concept check starting in gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-08-17 Ever confirmed|0 |1
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 Bug 44209 depends on bug 106537, which changed state. Bug 106537 Summary: GCC doesn't support -W[no-]compare-distinct-pointer-types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/111009] [12/13/14 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009 --- Comment #10 from Andrew Macleod --- > At the hazard of stating the obvious: it's a wrong-code when you execute it > (not a gcc ICE). > doh. of course. test is in progress. Richi was correct. Although the code in range-ops for fold_range is correct, op1_range cannot make the same assumptions that fold_range does because it has no concept of the symbolic values on the RHS. I am making op1_range more restrictive.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jose E. Marchesi --- Fixed in the commit above.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jose E. Marchesi :
https://gcc.gnu.org/g:e1f45bea2741c271efbc4c2f9dfad93cbcd644c0
commit r14-3291-ge1f45bea2741c271efbc4c2f9dfad93cbcd644c0
Author: Jose E. Marchesi
Date: Thu Aug 17 15:36:26 2023 +0200
Add warning options -W[no-]compare-distinct-pointer-types
GCC emits pedwarns unconditionally when comparing pointers of
different types, for example:
int xdp_context (struct xdp_md *xdp)
{
void *data = (void *)(long)xdp->data;
__u32 *metadata = (void *)(long)xdp->data_meta;
__u32 ret;
if (metadata + 1 > data)
return 0;
return 1;
}
/home/jemarch/foo.c: In function âxdp_contextâ:
/home/jemarch/foo.c:15:20: warning: comparison of distinct pointer types
lacks a cast
15 | if (metadata + 1 > data)
|^
LLVM supports an option -W[no-]compare-distinct-pointer-types that can
be used in order to enable or disable the emission of such warnings.
It is enabled by default.
This patch adds the same options to GCC.
Documentation and testsuite updated included.
Regtested in x86_64-linu-gnu.
No regressions observed.
gcc/ChangeLog:
PR c/106537
* doc/invoke.texi (Option Summary): Mention
-Wcompare-distinct-pointer-types under `Warning Options'.
(Warning Options): Document -Wcompare-distinct-pointer-types.
gcc/c-family/ChangeLog:
PR c/106537
* c.opt (Wcompare-distinct-pointer-types): New option.
gcc/c/ChangeLog:
PR c/106537
* c-typeck.cc (build_binary_op): Warning on comparing distinct
pointer types only when -Wcompare-distinct-pointer-types.
gcc/testsuite/ChangeLog:
PR c/106537
* gcc.c-torture/compile/pr106537-1.c: New test.
* gcc.c-torture/compile/pr106537-2.c: Likewise.
* gcc.c-torture/compile/pr106537-3.c: Likewise.
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-08-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
--- Comment #6 from Jan Hubicka ---
The mismatch happens on:
void foo (unsigned int x)
{
if (x != 0x800 && x != 0x810)
abort ();
}
It is bug in reassoc turning:
void foo (unsigned int x)
{
;; basic block 2, loop depth 0, count 1073741824 (estimated locally, freq
1.), maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
;;pred: ENTRY [always] count:1073741824 (estimated locally, freq
1.) (FALLTHRU,EXECUTABLE)
if (x_1(D) != 2048)
goto ; [66.00%]
else
goto ; [34.00%]
;;succ: 3 [66.0% (guessed)] count:708669600 (estimated locally, freq
0.6600) (TRUE_VALUE,EXECUTABLE)
;;5 [34.0% (guessed)] count:365072224 (estimated locally, freq
0.3400) (FALSE_VALUE,EXECUTABLE)
;; basic block 3, loop depth 0, count 708669600 (estimated locally, freq
0.6600), maybe hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred: 2 [66.0% (guessed)] count:708669600 (estimated locally, freq
0.6600) (TRUE_VALUE,EXECUTABLE)
if (x_1(D) != 2064)
goto ; [0.00%]
else
goto ; [100.00%]
;;succ: 4 [never] count:0 (precise, freq 0.)
(TRUE_VALUE,EXECUTABLE)
;;5 [always] count:708669600 (estimated locally, freq 0.6600)
(FALSE_VALUE,EXECUTABLE)
;; basic block 4, loop depth 0, count 0 (precise, freq 0.), probably
never executed
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred: 3 [never] count:0 (precise, freq 0.)
(TRUE_VALUE,EXECUTABLE)
abort ();
;;succ:
to:
void foo (unsigned int x)
{
unsigned int _4;
_Bool _5;
;; basic block 2, loop depth 0, count 1073741824 (estimated locally, freq
1.), maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
;;pred: ENTRY [always] count:1073741824 (estimated locally, freq
1.) (FALLTHRU,EXECUTABLE)
_4 = x_1(D) & 4294967279;
_5 = _4 != 2048;
if (_5 != 0)
goto ; [66.00%]
else
goto ; [34.00%]
;;succ: 3 [66.0% (guessed)] count:708669600 (estimated locally, freq
0.6600) (TRUE_VALUE,EXECUTABLE)
;;4 [34.0% (guessed)] count:365072224 (estimated locally, freq
0.3400) (FALSE_VALUE,EXECUTABLE)
;; basic block 3, loop depth 0, count 0 (precise, freq 0.), probably
never executed
;; Invalid sum of incoming counts 708669600 (estimated locally, freq 0.6600),
should be 0 (precise, freq 0.)
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred: 2 [66.0% (guessed)] count:708669600 (estimated locally, freq
0.6600) (TRUE_VALUE,EXECUTABLE)
abort ();
;;succ:
;; basic block 4, loop depth 0, count 1073741824 (estimated locally, freq
1.), maybe hot
;; Invalid sum of incoming counts 365072224 (estimated locally, freq 0.3400),
should be 1073741824 (estimated locally, freq 1.)
;;prev block 3, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred: 2 [34.0% (guessed)] count:365072224 (estimated locally, freq
0.3400) (FALSE_VALUE,EXECUTABLE)
return;
So it combines two conditionals together but does not update the
outgoing probabilitis of the conditional.
On x86-64 we have already in cfg dump:
_1 = x != 2048;
_2 = x != 2064;
_3 = _1 & _2;
if (_3 != 0)
goto ; [INV]
else
I wonder why optimization diverges here?
[Bug libstdc++/111050] New: [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 Bug ID: 111050 Summary: [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ABI Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d changed _Hash_node_value_base to no longer derive from _Hash_node_base, which means that its member functions expect _M_storage to be at a different offset. So explosions result if an out-of-line definition is emitted for any of the member functions (say, in a non-optimized build) and the resulting object file is then linked with code built using older version of GCC/libstdc++.
[Bug c/111049] New: spurious stringop-overflow depending on structure pointer arithmetic with certain sized structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111049 Bug ID: 111049 Summary: spurious stringop-overflow depending on structure pointer arithmetic with certain sized structures Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mark at infocomm dot com Target Milestone: --- Created attachment 55746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55746=edit C source that demonstrates the problem These warnings are incorrectly reported and have somewhat meaningless content: In function ‘xxx_set_array’, inlined from ‘xxx_b’ at ptr_diff_err.c:177:5: ptr_diff_err.c:189:23: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 189 | xxx_array[u][l++] = (code >> i) & 1; | ~~^ ptr_diff_err.c: In function ‘xxx_b’: ptr_diff_err.c:94:16: note: at offset [-10324440, 10324440] to object ‘xxx_array’ with size 3192 declared here 94 | static uint8_t xxx_array[2][1596]; |^ In function ‘xxx_set_array’, inlined from ‘xxx_b’ at ptr_diff_err.c:177:5: ptr_diff_err.c:189:23: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 189 | xxx_array[u][l++] = (code >> i) & 1; | ~~^ ptr_diff_err.c: In function ‘xxx_b’: ptr_diff_err.c:94:16: note: at offset 0 to object ‘xxx_array’ with size 3192 declared here 94 | static uint8_t xxx_array[2][1596]; |^ In function ‘xxx_set_array’, inlined from ‘xxx_b’ at ptr_diff_err.c:177:5: ptr_diff_err.c:189:23: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 189 | xxx_array[u][l++] = (code >> i) & 1; | ~~^ ptr_diff_err.c: In function ‘xxx_b’: What does "offset [-10324440, 10324440] to object" mean? What does "a region of size 0" mean? This occurs with: gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110 On: Linux raspberrypi 6.1.21-v7+ #1642 SMP Mon Apr 3 17:20:52 BST 2023 armv7l GNU/Linux These warnings only happen when compiling with -O2 These warnings only happen when the value u mentioned on line 189 is produced by simple pointer arithmetic between elements of the same array of structures. They ONLY happen when the structure has certain sizes and not when that structure has other sizes. The attached source file can be compiled to demonstrate the problem with different sized structures. See comments at the top of the attach example file which describe how to change the compile time structure size with -DSTR_EXTRAS= and which values generate the messages and which values do not.
[Bug tree-optimization/111039] [11/12/13 Regression] Unable to coalesce ssa_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039 Richard Biener changed: What|Removed |Added Known to work||14.0 Priority|P3 |P2 Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |Unable to coalesce |Unable to coalesce |ssa_names |ssa_names
[Bug c++/111047] Un-silenceable note for ABI parameters 64-byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111047 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-08-17 Keywords||diagnostic Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- More specifically, -Wno-psabi (which is a subset of -Wabi). The various 'inform' notes in i386.cc that depend on warn_psabi should probably output "[-Wpsabi]" to make this clear.
[Bug tree-optimization/111039] [11/12/13/14 Regression] Unable to coalesce ssa_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:482551a79a3d3f107f6239679ee74655cfe8707e commit r14-3288-g482551a79a3d3f107f6239679ee74655cfe8707e Author: Richard Biener Date: Thu Aug 17 13:10:14 2023 +0200 tree-optimization/111039 - abnormals and bit test merging The following guards the bit test merging code in if-combine against the appearance of SSA names used in abnormal PHIs. PR tree-optimization/111039 * tree-ssa-ifcombine.cc (ifcombine_ifandif): Check for SSA_NAME_OCCURS_IN_ABNORMAL_PHI. * gcc.dg/pr111039.c: New testcase.
[Bug c++/111019] [12/13/14 Regression] Optimizer incorrectly assumes variable is not changed while change happens through another pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019 --- Comment #9 from Richard Biener --- (In reply to Richard Biener from comment #8) > So really caused by r9-4993-g1c852d1d7096a8 plus all the followups that went > into this code. One triggering fact is that operand_equal_p > of MEM[(struct Target *)_26].D.43475.next with itself is false ... Ah, because one has BASE/CLIQUE and one does not.
[Bug libgomp/111024] libgomp: FAILs with oldish libnuma/libmemkind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111024 --- Comment #3 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:8f3c4517b1fff965f2bdedcf376dcfd91cda422b commit r14-3287-g8f3c4517b1fff965f2bdedcf376dcfd91cda422b Author: Tobias Burnus Date: Thu Aug 17 15:20:55 2023 +0200 libgomp: call numa_available first when using libnuma The documentation requires that numa_available() is called and only when successful, other libnuma function may be called. Internally, it does a syscall to get_mempolicy with flag=0 (which would return the default policy if mode were not NULL). If this returns -1 (and not 0) and errno == ENOSYS, the Linux kernel does not have the get_mempolicy syscall function; if so, numa_available() returns -1 (otherwise: 0). libgomp/ PR libgomp/111024 * allocator.c (gomp_init_libnuma): Call numa_available; if not available or not returning 0, disable libnuma usage.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #59 from Roman Krotov --- (In reply to Ed Catmur from comment #58) > (In reply to Roman Krotov from comment #57) I already addressed all of it in my previous 2 comments... I'll write more clearly then. > > But I don't see any reasons not to implement the switch right now... > Making [[gnu::warn_unused_result]] mean the same as [[nodiscard]] would be a > reduction in expressivity. All, what I'm asking for, is to make something like -Wno-void-unused, which would suppress the warnings only for the (void) casted calls. This is desperately needed by the projects like systemd (see the first link in my first comment) as a less severe variant than -Wno-unused-result, so that they won't get punished with less diagnostics. In fact, gcc already has a "not recommended non-default" switch model: -Wno-coverage-mismatch <...> -Wno-coverage-mismatch can be used to disable the warning <...> disabling the warning is not recommended. I don't see any reason not to implement -Wno-void-unused with the similar description (stating that it's not recommended, if you want) to help the projects like systemd. It won't change the meaning of the wur attribute, bacause it will be a non-default switch. > > what about the projects > > what don't agree with the distinction of these 2 attributes? Or just want to > > be more compatible with clang? > They can use [[nodiscard]]. > > > Or they just may not agree with the choice of a library, that decided to put > > wur instead of nodiscard for a specific function. > Then they can write their own wrappers using [[nodiscard]]. What about libraries and programs that will prefer to stay on C99/C11 (without C2x extensions), especially if they use -pedantic? Even if there will be something like __attribute__(nodiscard), What about programs and libraries that will not prefer to update? That's why we shouldn't rely on the future and should implement the solution now.
[Bug libgomp/69046] gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1 validation test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69046 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- Regarding the testsuite mentioned here. It is at: http://web.archive.org/web/2016071500*/http://web.cs.uh.edu/~openuh/download/packages/OpenMP3.1_Validation.tar.gz And before running, all *.pl shebang require an addition of '-I.' as perl argument to find the *.pm perl modules. * * * Just dumping the result below. I do note that 'omp_task_untied' fails with GCC but not with llvm/Clang. The test checks whether a task has at least once switched the thread - with clang, it is 12 to 18 times the same thread - with num_tasks 25; with GCC it is always the same thread, i.e. no task switched. And for 'task_final', the testcase looks bogus. Except for, possibly, untied or checking why some (but only) 'orphaned' testcases fail in Fortran, nothing seems to be done here. * * * Test results with clang-14: Testing for "omp_taskyield": + orphaned mode: Running test with 8 threads . failed 85% of the tests Testing for "omp_task_final": Running test with 8 threads . failed 100% of the tests + orphaned mode: Running test with 8 threads . failed 100% of the tests Result with GCC mainline: Testing for "omp_task_untied": Running test with 8 threads . failed 100% of the tests + orphaned mode: Running test with 8 threads . failed 100% of the tests Testing for "omp_taskyield": + orphaned mode: Running test with 8 threads . failed 90% of the tests Testing for "omp_task_final": Running test with 8 threads . failed 100% of the tests + orphaned mode: Running test with 8 threads . failed 100% of the tests Result for gfortran/mainline: Testing for "do_firstprivate": + orphaned mode: Running test with 8 threads . failed 100% of the tests Testing for "do_private": + orphaned mode: Running test with 8 threads . failed 100% of the tests Testing for "do_schedule_static": + orphaned mode: Running test with 8 threads . failed 100% of the tests Testing for "omp_get_num_threads": + orphaned mode: Running test with 8 threads . failed 100% of the tests bin/fortran/orph_test_omp_in_parallel.f:108:15 108 | serial=omp_in_parallel() | 1 Error: Cannot convert REAL(4) to LOGICAL(4) at (1) (implicit typing seemingly gets it wrong - a 'use omp_lib' would also have worked.) Testing for "omp_master": + orphaned mode: Running test with 8 threads . failed 100% of the tests Testing for "omp_num_threads": + orphaned mode: Running test with 8 threads . failed 100% of the tests Testing for "par_do_ordered": + orphaned mode: Running test with 8 threads . failed 100% of the tests Testing for "omp_master_3": + orphaned mode: Running test with 8 threads . failed 100% of the tests Testing for "omp_task_untied": + orphaned mode: Running test with 8 threads . failed 100% of the tests
[Bug c++/111019] [12/13/14 Regression] Optimizer incorrectly assumes variable is not changed while change happens through another pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019 --- Comment #8 from Richard Biener --- So really caused by r9-4993-g1c852d1d7096a8 plus all the followups that went into this code. One triggering fact is that operand_equal_p of MEM[(struct Target *)_26].D.43475.next with itself is false ...
[Bug c++/111019] [12/13/14 Regression] Optimizer incorrectly assumes variable is not changed while change happens through another pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #7 from Richard Biener --- And what in the end disambiguates this in LIM is aliasing_component_refs_p. Note that LIM feeds it canonicalized __MEM ((struct Target *)_26).D_43475.next, it instead uses MEM[(struct Base * *)_26 + 8B]. I think it goes wrong because LIM canonicalizes _26->...next which is a ref at offset 8 to MEM[_26 + 8] _at offset 8_, the base is actually recorded as MEM[_26] but get_ref_base_and_extent wouldn't get 8 out of MEM[_26 + 8] and aliasing_matching_component_refs_p re-does that to adjust the offset which in the end leads to some inconsistency. What LIM tries to do is find a canonical representation for the ref which is MEM[_26 + 8B], it also tries to preserve the base which is MEM[_26], but that's somewhat in conflict here. It works for LIMs purposes but as can be seen it doesn't work here. The bad thing is that there isn't a consistent representation for this, but also aliasing_matching_component_refs_p relying on this is bad?
[Bug target/111046] bpf: support naked functions in BPF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111046 Jose E. Marchesi changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jose E. Marchesi --- Fixed with the above commit.
[Bug target/111046] bpf: support naked functions in BPF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111046 --- Comment #1 from CVS Commits --- The master branch has been updated by Jose E. Marchesi : https://gcc.gnu.org/g:b7c50f68f26146e7038e9793b6c623ff4c4895d3 commit r14-3284-gb7c50f68f26146e7038e9793b6c623ff4c4895d3 Author: Jose E. Marchesi Date: Thu Aug 17 14:19:15 2023 +0200 bpf: support `naked' function attributes in BPF targets The kernel selftests and other BPF programs make extensive use of the `naked' function attribute with bodies written using basic inline assembly. This patch adds support for the attribute to bpf-unkonwn-none, makes it to inhibit warnings due to lack of explicit `return' statement, and updates documentation and testsuite accordingly. Tested in x86_64-linux-gnu host and bpf-unknown-none target. gcc/ChangeLog PR target/111046 * config/bpf/bpf.cc (bpf_attribute_table): Add entry for the `naked' function attribute. (bpf_warn_func_return): New function. (TARGET_WARN_FUNC_RETURN): Define. (bpf_expand_prologue): Add preventive comment. (bpf_expand_epilogue): Likewise. * doc/extend.texi (BPF Function Attributes): Document the `naked' function attribute. gcc/testsuite/ChangeLog * gcc.target/bpf/naked-1.c: New test.
[Bug target/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048 Sergei Trofimovich changed: What|Removed |Added CC||richard.sandiford at arm dot com --- Comment #1 from Sergei Trofimovich --- `git bisect` points at r14-3243-ga7dba4a1c05a76: commit a7dba4a1c05a76026d88d0b519cf83bff9a2 Date: Wed Aug 16 16:51:44 2023 +0530 Extend fold_vec_perm to handle VLA vector_cst.
[Bug target/111045] PCREL should not be supported on BE ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111045 --- Comment #1 from Jeevitha --- TARGET_PCREL was enabled on the Big Endian machine. However, the Big Endian ABI does not support PCREL. Therefore, TARGET_PCREL needs to be disabled here.
[Bug c++/111019] [12/13/14 Regression] Optimizer incorrectly assumes variable is not changed while change happens through another pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
--- Comment #6 from Richard Biener ---
(In reply to rguent...@suse.de from comment #3)
> On Tue, 15 Aug 2023, ppalka at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
> >
> > Patrick Palka changed:
> >
> >What|Removed |Added
> >
> > CC||ppalka at gcc dot gnu.org
> >Keywords|needs-bisection |
> >
> > --- Comment #2 from Patrick Palka ---
> > Bisection points to r12-4319-g09a0affdb0598a
>
> Huh, that should make us optimize less ... (it was also backported
> to GCC 11). Having a good/bad rev should make it easier to analyze
> though - thanks.
Indeed it does, optimizing more simply avoids the bug somehow.
The bug is that we think this->next is invariant in the loop, thus
n->next = nullptr cannot possibly clobber it. LIM2 hoists it out of
the loop.
The accesses are
[t.C:18:18] # PT = nonlocal escaped null { D.43517 D.43765 D.53227 D.53358
D.53446 } (escaped, escaped heap)
_77 = [t.C:18:18] __MEM ((struct Target *)_26).D_43475.next;
vs.
[t.C:27:15] [t.C:27:10] _170->next = _Literal (struct Base *) 0;
where _170 is of type (struct Base *). and
# PT = nonlocal escaped null { D.43517 D.43765 D.53227 D.53358 D.53446 }
(escaped, escaped heap)
_170 = __PHI ([t.C:18:18] __BB46: _77, [t.C:18:18] __BB45: _20);
-fno-tree-loop-im fixes this at any optimization level.
[Bug target/111048] New: [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048
Bug ID: 111048
Summary: [14 Regression] Wrong AVX2 code on highway-1.0.6 on
-O2 and above
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed wrong code with r14-3259-g24f7b20bbd87eb when running tests on
highway-1.0.6. Extracted example:
// $ cat bug.cc.cc
typedef unsigned char u8;
__attribute__((noipa))
static void check(const u8 * v) {
if (*v != 15) __builtin_trap();
}
__attribute__((noipa))
static void bug(void) {
u8 in_lanes[32];
for (unsigned i = 0; i < 32; i += 2) {
in_lanes[i + 0] = 0;
in_lanes[i + 1] = ((u8)0xff) >> (i & 7);
}
check(_lanes[13]);
}
int main() {
bug();
}
Triggering:
$ g++ bug.cc.cc -mavx2 -O2 -o bug2 && ./bug2
Illegal
$ g++ bug.cc.cc -mavx2 -O1 -o bug1 && ./bug1
$ g++ -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.0
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.0-12-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.0-12/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.38-dev/include
--with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 (experimental) (GCC)
[Bug c++/111047] Un-silenceable note for ABI parameters 64-byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111047 --- Comment #1 from Andreas Schwab --- -Wno-abi
[Bug c++/102775] Error recovery in the C++ parser should use fix-it hints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102775 --- Comment #2 from Jonathan Wakely --- Here's another example: #include int i = numeric_limits::digits10; lim.cc:2:9: error: 'numeric_limits' was not declared in this scope; did you mean 'std::numeric_limits'? 2 | int i = numeric_limits::digits10; | ^~ | std::numeric_limits In file included from lim.cc:1: /home/jwakely/gcc/14/include/c++/14.0.0/limits:312:12: note: 'std::numeric_limits' declared here 312 | struct numeric_limits : public __numeric_limits_base |^~ lim.cc:2:24: error: expected primary-expression before 'double' 2 | int i = numeric_limits::digits10; |^~ The "expected primary-expression before 'double'" part is just noise. There's only one problem in the code, and if you add the suggested "std::" qualification then the code is valid. If we treated "numeric_limits" as an alias for "std::numeric_limits" after the first error, then the rest of the file would compile successfully. We'd still give an error and the code would be ill-formed, but we'd only complain about the one location that actually has a bug. Presumably to make this work we would need to make the result of the "did you mean" lookup available to the compiler (not just to the diagnostic machinery). If there's a match, like std::numeric_limits in this case, then do name lookup for that and if it's found and is a type then act as though we'd seen a using-declaration/typedef for that name to make it available as just "numeric_limits". For a name where the match is the same name but with a namespace qualification, a using-declaration would suffice to make it available with the unqualified name. For a misspelled name where the match is spelled differently, we could introduce a typedef (for types) or reference (for objects and functions) to make the name usable with the misspelled name. Sometimes doing this might make the code even more invalid and produce additional diagnostics that wouldn't be present today. I think it would need to be tried and tested on a variety of code to see whether it's usually an improvement or makes things worse. I suspect that for the majority of code with a single mistake (like using a name unqualified) it would help. Introducing these aliases for unqualified/misspelled names could potentially also change the meaning of the following code to make it something different from what was really intended, e.g. a fix-it for "foo()" suggests "Foo()" but the user actually meant to call "food()". The code has already hit an error and so we'll never generate wrong code, so this can only result in additional spurious diagnostics that wouldn't be emitted today.
[Bug c++/111047] New: Un-silenceable note for ABI parameters 64-byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111047
Bug ID: 111047
Summary: Un-silenceable note for ABI parameters 64-byte
alignment
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalo.gadeschi at gmail dot com
Target Milestone: ---
Reproducer (https://godbolt.org/z/jvedoeK9E):
struct alignas(64) big_t{int x;};
void f(big_t b) { return; }
outputs:
: In function 'void f(big_t)':
:2:6: note: the ABI for passing parameters with 64-byte alignment has
changed in GCC 4.6
2 | void f(big_t b) { return; }
| ^
We are hitting this "note" throughout our code base, which is confusing many of
our developers, and we cannot find a way to silence it.
It would be really helpful to have a flag to disable this "note".
[Bug tree-optimization/111039] [11/12/13/14 Regression] Unable to coalesce ssa_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529 --- Comment #14 from Jonathan Wakely --- Ah that's pretty much what Manu suggested in comment 5 but without the whitespace handling, as Jakub pointed out in comment 6. Still, Manu's patch is a good start. (In reply to Manuel López-Ibáñez from comment #8) > (In reply to Axel Naumann from comment #2) > > You asked for it, so here is my wish list: > > - for C++ < 1z, do not support hexfloats, neither with "unsigned" not > > negative exponents. You can use -pedantic or -pedantic-errors for that. It might be nice if the pedantic "warning: use of C++17 hexadecimal floating constant" was controlled by -Wc++17-extensions but I'm not sure if that's possible for a preprocessor warning. It might also be nice if it called it a "hexadecimal floating-point literal", since "floating constant" is only used in C, not C++, so there's no such thing as a "C++17 hexadecimal floating constant". > Since "unsigned" exponents are supported by standard C++11, g++ has to > support them. No, as stated 0x123p1 is not valid in C++11, which is why it's a pedwarn.
