[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #3 from Christoph Reiter --- Wild guess: I see _aligned_malloc() being used in libgomp, but not _aligned_free().
[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #2 from Christoph Reiter --- For "#pragma omp parallel for if (0)": #0 0x7ffacdeac6b3 in ntdll!RtlIsZeroMemory () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7ffacdeb5512 in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #2 0x7ffacdeb57fa in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #3 0x7ffacdebfce5 in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #4 0x7ffacddc8715 in ntdll!RtlGetCurrentServiceSessionId () from C:\WINDOWS\SYSTEM32\ntdll.dll #5 0x7ffacddc79e1 in ntdll!RtlFreeHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll #6 0x7ffacb4e218b in ucrtbase!_free_base () from C:\WINDOWS\System32\ucrtbase.dll #7 0x7ffa7fd3eab6 in free_team (team=team@entry=0x25d609d0fc0) at ../../../gcc-12.1.0/libgomp/team.c:237 #8 0x7ffa7fd3ff8a in gomp_team_end () at ../../../gcc-12.1.0/libgomp/team.c:1005 #9 0x7ffa7fd3899e in GOMP_parallel_end () at ../../../gcc-12.1.0/libgomp/parallel.c:167 #10 0x7ffa7fd38a73 in GOMP_parallel ( fn=fn@entry=0x7ff707941530 , data=data@entry=0x0, num_threads=num_threads@entry=1, flags=flags@entry=0) at ../../../gcc-12.1.0/libgomp/parallel.c:179 #11 0x7ff707941584 in main () at myTest.cpp:2 For "#pragma omp for schedule(dynamic)" #0 0x7ffacdeac6b3 in ntdll!RtlIsZeroMemory () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7ffacdeb5512 in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #2 0x7ffacdeb57fa in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #3 0x7ffacdebfce5 in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #4 0x7ffacddc8715 in ntdll!RtlGetCurrentServiceSessionId () from C:\WINDOWS\SYSTEM32\ntdll.dll #5 0x7ffacddc79e1 in ntdll!RtlFreeHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll #6 0x7ffacb4e218b in ucrtbase!_free_base () from C:\WINDOWS\System32\ucrtbase.dll #7 0x7ffa7eae050e in free_work_share (team=team@entry=0x0, ws=0x2b6040a8480) at ../../../gcc-12.1.0/libgomp/work.c:159 #8 0x7ffa7eae0682 in gomp_work_share_end () at ../../../gcc-12.1.0/libgomp/work.c:238 #9 0x7ffa7ead68b4 in GOMP_loop_end () at ../../../gcc-12.1.0/libgomp/loop.c:958 #10 0x7ff6b18f1593 in main () at myTest.cpp:3
[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.2 Known to work||11.3.0 Summary|Conditional OpenMP |[12/13 Regression] |directive fails with GCC 12 |Conditional OpenMP ||directive fails with GCC 12
[Bug rtl-optimization/105744] [11/12/13 Regression] wrong code with -fexpensive-optimizations -flive-range-shrinkage on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105744 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.4
[Bug c++/105742] [9/10/11/12/13 Regression] accepts-invalid non-dependent call to non-static member function from unrelated class in presence of dependent base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105742 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/105736] [12/13 Regression] ICE in force_gimple_operand_1, at gimplify-me.cc:79 since r13-222-g28896b38fabce818
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Summary|[12 Regression] ICE in |[12/13 Regression] ICE in |force_gimple_operand_1, at |force_gimple_operand_1, at |gimplify-me.cc:79 since |gimplify-me.cc:79 since |r13-222-g28896b38fabce818 |r13-222-g28896b38fabce818 Target Milestone|13.0|12.2
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/105728] dead store to static var not optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728
Richard Biener changed:
What|Removed |Added
Component|c |ipa
Last reconfirmed||2022-05-27
Ever confirmed|0 |1
Keywords||missed-optimization
CC||hubicka at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from Richard Biener ---
the dummy1/dummy2 optimizations could eventually be done by DCE if we knew that
'removeme' is only ever accessed from 'dummy1' / 'dummy2', in that case we
could consider the variable local and since there's no data dependence on it
we could elide it.
Don't we track that already in IPA? I think local passes cannot rely on
IPA references? We also need to consider
void foo (int *);
int dummy1()
{
static int removeme = 0;
static int *p = &removeme;
foo (p);
if (removeme)
{
return 0;
}
removeme = 1;
return 0;
}
thus global CTORs (the above will see the init in dummy1(), but not sure
whether we can rely on that?)
[Bug ipa/105140] [10 Regression] ICE: SIGSEGV in fold_convertible_p with conflicting function redeclaration since r10-5112-gfddcfa5b84bf8a06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105140 Bug 105140 depends on bug 105266, which changed state. Bug 105266 Summary: new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:186fcf8b7a7c17a8a17466bc9149b3ca4ca9dd3e
commit r11-10037-g186fcf8b7a7c17a8a17466bc9149b3ca4ca9dd3e
Author: Kewen Lin
Date: Sun Apr 17 21:34:51 2022 -0500
testsuite: Skip pr105250.c for powerpc and s390 [PR105266]
This test case pr105250.c is like its related pr105140.c, which
suffers the error with message like "{AltiVec,vector} argument
passed to unprototyped" on powerpc and s390. So like commits
r12-8025 and r12-8039, this fix is to add the dg-skip-if for
powerpc*-*-* and s390*-*-*.
gcc/testsuite/ChangeLog:
PR testsuite/105266
* gcc.dg/pr105250.c: Skip for powerpc*-*-* and s390*-*-*.
(cherry picked from commit 021b51814d67bedd8f41ac07edfd05654140c6e5)
[Bug tree-optimization/105736] [12 Regression] ICE in force_gimple_operand_1, at gimplify-me.cc:79 since r13-222-g28896b38fabce818
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736
--- Comment #2 from Siddhesh Poyarekar ---
OK, so the fix is pretty straightforward; error_mark_node escapes through as a
return in ADDR_EXPR object size computations. I want to get a reproducer
independent of ubsan though so that it's verifiable in the general case:
diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index fc062b94d76..f1a699a94db 100644
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -695,19 +695,24 @@ addr_object_size (struct object_size_info *osi,
const_tree ptr,
var_size = pt_var_size;
bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var);
if (bytes != error_mark_node)
- bytes = size_for_offset (var_size, bytes);
- if (var != pt_var
- && pt_var_size
- && TREE_CODE (pt_var) == MEM_REF
- && bytes != error_mark_node)
{
- tree bytes2 = compute_object_offset (TREE_OPERAND (ptr, 0), pt_var);
- if (bytes2 != error_mark_node)
+ bytes = size_for_offset (var_size, bytes);
+ if (var != pt_var
+ && pt_var_size
+ && TREE_CODE (pt_var) == MEM_REF
+ && bytes != error_mark_node)
{
- bytes2 = size_for_offset (pt_var_size, bytes2);
- bytes = size_binop (MIN_EXPR, bytes, bytes2);
+ tree bytes2 = compute_object_offset (TREE_OPERAND (ptr, 0),
+ pt_var);
+ if (bytes2 != error_mark_node)
+ {
+ bytes2 = size_for_offset (pt_var_size, bytes2);
+ bytes = size_binop (MIN_EXPR, bytes, bytes2);
+ }
}
}
+ else
+ bytes = size_unknown (object_size_type);
wholebytes
= object_size_type & OST_SUBOBJECT ? var_size : pt_var_wholesize;
[Bug target/105745] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #1 from Andrew Pinski --- Can you run this under the debugger to see where the crash is? Because there have been almost no changes to the libgomp sources that would effect this.
[Bug c++/105652] [12/13 Regression] ICE: in is_base_type, at dwarf2out.cc:13400 since r12-1937-gc28e1d288ab727de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105652 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734
--- Comment #10 from Jeremy R. ---
One workaround in the general case is
decltype(ns::expression_decomposer(ns::expression_decomposer{} << expr)) =
libassert_decomposer = ns::expression_decomposer(ns::expression_decomposer{} <<
expr);
But this doesn't work if expr is a lambda.
A more general workaround is deferring the destructor to another function:
template void destruct(T& t) {
t.~T();
}
template
void bar() {
auto m = hh::s(hh::s{}.h());
destruct(m);
}
[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 --- Comment #7 from Siddhesh Poyarekar --- I couldn't work on -fstrict-flex-arrays then, sorry. I do have it in my plan for gcc 13, but I'll admit it's not on the very top of my list of things to do this year. If you or anyone else needs a stronger guarantee of this making it into gcc 13 and wants to work on it, I'll be happy to help with reviews.
[Bug c++/105746] New: vector::resize causes Warray-bounds when optimizer uses __builtin_memcpy or __builtin_memmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105746
Bug ID: 105746
Summary: vector::resize causes Warray-bounds when
optimizer uses __builtin_memcpy or __builtin_memmove
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: albrecht.guendel at web dot de
Target Milestone: ---
https://godbolt.org/z/YP5aWjbzM
>From version 10.1 to trunk (both arm-none-eabi, x86-64)
Compiling with: -O3 -Wall -Wextra -Werror
The following code:
#include
union U //works if is struct
{
unsigned char data;
//required to construct from 0xff
U(const unsigned char raw): data(raw) {}
//required by vector::resize
U(const U& other): data(other.data) {}
};
auto bug()
{
std::vector v;
v.resize(100, 0xff);
return v;
}
produces the warning:
void* __builtin_memcpy(void*, const void*, long unsigned int)' offset 100 is
out of the bounds [0, 100]
This is the most minimum example i have found.
Noticeable:
- it only happens when using O3
- it also happens when the compiler decides to use __builtin_memmove instead
(havent found a good minimum example for that; my working-code results in using
memmove)
- replacing the union with a struct/class resolves the issue
- the bug also occurs when resizing with some compile-time known U, instead of
an integer constant (it does not matter which copy-constructor is called by
vector::resize, just that the optimization to __builtin_memcpy is possible).
- clang and other compilers complain about the copy-constructor being
deprecated in this code example. [this one: U(const U& other): data(other.data)
{} ].
And, indeed, replacing it with U(const U& other) = default; actually resolves
the issue. (but maybe the memcpy-optimization is just not triggered?)
I think this is worth investigating because this either hints at some bad
constant propagation or bounds-check. Basically, I dont know, if the warning
triggers erroneously or if the warning has merit due to an optimization bug.
According to other compilers, the code is bad/deprecated.. but gcc does not
warn (and I dont know why other compilers warn here).
In detail, clang says: definition of implicit copy assignment operator for 'U'
is deprecated because it has a user-declared copy constructor
[-Wdeprecated-copy]
[Bug libstdc++/105671] [11/12/13 Regression] Unexplained "undefined reference" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671 Joseph S. Myers changed: What|Removed |Added Summary|Unexplained "undefined |[11/12/13 Regression] |reference" error|Unexplained "undefined ||reference" error CC||jsm28 at gcc dot gnu.org Component|c++ |libstdc++ Target Milestone|--- |11.4 --- Comment #2 from Joseph S. Myers --- I'm seeing the same undefined reference on a customer test case. I haven't reduced it to a self-contained test case either, but as far as I can see this is a libstdc++ issue (rather than a front-end or LTO bug). _M_high_mark (which is new in libstdc++ in GCC 11) isn't exported from libstdc++.so (it's present in libstdc++.a), presumably because the symbol version maps don't include it, so if the compiler decides to inline one of the functions from the header that calls _M_high_mark, without inlining _M_high_mark itself, there is an undefined reference to _M_high_mark. (This selective inlining is what I haven't reproduced in a self-contained test, even when adjusting various inlining parameters, but it would explain the undefined reference.)
[Bug c/90658] [9/10/11/12/13 Regression] ICE in default_conversion, at c/c-typeck.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90658 Marek Polacek changed: What|Removed |Added Summary|[9 Regression] ICE in |[9/10/11/12/13 Regression] |default_conversion, at |ICE in default_conversion, |c/c-typeck.c:2159 |at c/c-typeck.c:2159 Last reconfirmed|2019-05-28 00:00:00 |2022-5-26 --- Comment #8 from Marek Polacek --- Still ICEs.
[Bug libstdc++/105681] [12 Regression] libstdc++-v3 fails to build on msp430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 Jonathan Wakely changed: What|Removed |Added Known to work||11.3.0 Summary|libstdc++-v3 fails to build |[12 Regression] |on msp430 |libstdc++-v3 fails to build ||on msp430 Known to fail||12.1.0 --- Comment #11 from Jonathan Wakely --- Fixed on trunk. Backport to follow.
[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #10 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:367740bf6d3a6627798b3955e5d85efc7549ef50 commit r13-787-g367740bf6d3a6627798b3955e5d85efc7549ef50 Author: Jonathan Wakely Date: Thu May 26 21:32:55 2022 +0100 libstdc++: Fix narrowing conversions for 16-bit size_t [PR105681] On a 16-bit target such as msp430 we get errors about narrowing long values to size_t, which is only 16-bit. When --enable-libstdcxx-pch is used the header breaks the build because of these narrowing errors. libstdc++-v3/ChangeLog: PR libstdc++/105681 * include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp: Limit ga_sizes array to values that fit in size_t. * include/ext/random [__SIZE_WIDTH < 32] (sfmt86243) (sfmt86243_64, sfmt132049, sfmt132049_64, sfmt216091) (sfmt216091_64): Do not declare.
[Bug c++/105569] [12/13 Regression] -Waddress warns on dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105569 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- The warning is correct, but I've improved the diagnostic at least. Not planning to backport such an improvement.
[Bug c++/105569] [12/13 Regression] -Waddress warns on dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105569 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6f56efa94e845db0d5c934ca202295019bf334c1 commit r13-784-g6f56efa94e845db0d5c934ca202295019bf334c1 Author: Marek Polacek Date: Wed May 11 14:38:49 2022 -0400 c++: improve -Waddress warnings with *_cast [PR105569] This patch improves the diagnostic for -Waddress when it warns for if (dynamic_cast(&ref)) // ... where 'ref' is a reference, which cannot be null. In particular, it changes warning: comparing the result of pointer addition '(((A*)ref) + ((sizetype)(*(long int*)((& ref)->B::_vptr.B + -24' and NULL to warning: the compiler can assume that the address of 'ref' will never be NULL PR c++/105569 gcc/cp/ChangeLog: * typeck.cc (warn_for_null_address): Improve the warning when the POINTER_PLUS_EXPR's base is of reference type. gcc/testsuite/ChangeLog: * g++.dg/warn/Waddress-9.C: New test.
[Bug libgomp/105745] New: Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745
Bug ID: 105745
Summary: Conditional OpenMP directive fails with GCC 12
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Downstream issue: https://github.com/msys2/MINGW-packages/issues/11729
The following example crashes with GCC 12.1.0, but works fine with GCC 11.3.0:
// g++ -fopenmp -o broken.exe broken.c; ./broken.exe; echo $?
int main() {
#pragma omp parallel for if (0)
for (int idx = 0; idx < 0; ++idx) { }
return 0;
}
* Removing the "if (0)" condition makes it work again
* Replacing libgomp-1.dll with the one from GCC 11.3 also makes things work
again.
* Another example that crashes is "#pragma omp for schedule(dynamic)"
This is on 32/64 bit Windows.
[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681
--- Comment #9 from Jonathan Wakely ---
Ah, and I didn't see this when building for msp430 because I used
--disable-libstdcxx-pch and that means the build doesn't depend on the
header.
I can now reproduce the build failure, and the patch in comment 6 fixes the
failures in , but then we fail later:
/tmp/msp430/msp430-elf/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:73:32:
error: narrowing conversion of '116731' from 'long unsigned int' to
'std::size_t' {aka 'unsigned int'} [-Wnarrowing]
73 | /* 14*/ 116731ul,
|^~~~
Those are also non-standard extensions. Maybe we should just not install the
precompiled header for on 16-bit targets.
As a workaround until I fix all the problems, you can use
--disable-libstdcxx-pch
[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681
--- Comment #8 from Jonathan Wakely ---
And it was indeed something I asked for, see r12-2355
c++: Don't hide narrowing errors in system headers
Jonathan pointed me at this issue where
constexpr unsigned f() { constexpr int n = -1; return unsigned{n}; }
is accepted in system headers, despite the narrowing conversion from
a constant. I suspect that whereas narrowing warnings should be
disabled, ill-formed narrowing of constants should be a hard error
(which can still be disabled by -Wno-narrowing).
[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #7 from Jonathan Wakely --- (In reply to Richard Biener from comment #4) > possibly the system header diagnostic changes? Yes, the narrowing check here was PR c++/57891 which was fixed for GCC 9. But it was still allowed in system headers until GCC 12.
[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |12.2 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-05-26 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #6 from Jonathan Wakely --- I think the compiler might have got stricter about diagnosing narrowing conversions in non-type template arguments (I think I even reported a bug saying it should do that!) The problem is that size_t is a 16-bit unsigned int, so too small for the values we use in the specializations: template class simd_fast_mersenne_twister_engine // ... typedef simd_fast_mersenne_twister_engine sfmt86243; We could change the size_t there to be a type with at least 32 bits to make it work, but I think the right fix is to simply not defined those typedefs that don't fit in 16 bits: --- a/libstdc++-v3/include/ext/random +++ b/libstdc++-v3/include/ext/random @@ -346,6 +346,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION 0xa3ac4000U, 0xecc1327aU> sfmt44497_64; +#if __SIZE_WIDTH__ >= 32 typedef simd_fast_mersenne_twister_engine sfmt216091_64; +#endif // __SIZE_WIDTH__ >= 32 #endif // __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ Everything in is a non-standard extension, so we're under no obligation to provide any of it for standard conformance.
[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #5 from David Summers --- Yes I can confirm that going back to gcc-11.2.0 - and it works again, that being the only change. It explains how I got the headers, on my first build I used 11.2.0; whilst it was building saw that gcc-12 was available, so downloaded for a second pass (always like to do two passes - to make sure that everything knows what else is set up). So problem is in gcc-12
[Bug c++/105571] Spurious "set but not used" on static constexpr local, used in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105571
--- Comment #2 from Johel Ernesto Guerrero Peña ---
Simplified reproducer from Bug 105743:
See https://godbolt.org/z/xq16xac15.
```C++
void f(auto x) { x(0); }
void g() {
static constexpr auto h = [](...) { };
f([](auto x) { h(x); });
}
```
```
: In function 'void g()':
:3:25: warning: variable 'h' set but not used
[-Wunused-but-set-variable]
3 | static constexpr auto h = [](...) { };
| ^
```
Arguably, `h(x)` could perform ADL on `x`. But perhaps it'd be better to stay
silent, like the other compilers.
[Bug c++/105571] Spurious "set but not used" on static constexpr local, used in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105571 Johel Ernesto Guerrero Peña changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #1 from Johel Ernesto Guerrero Peña --- *** Bug 105743 has been marked as a duplicate of this bug. ***
[Bug c++/105743] Bogus unused but set lambda warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105743 Johel Ernesto Guerrero Peña changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Johel Ernesto Guerrero Peña --- Duplicate of Bug 105571. *** This bug has been marked as a duplicate of bug 105571 ***
[Bug rtl-optimization/105744] New: [11/12/13 Regression] wrong code with -fexpensive-optimizations -flive-range-shrinkage on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105744
Bug ID: 105744
Summary: [11/12/13 Regression] wrong code with
-fexpensive-optimizations -flive-range-shrinkage on
powerpc64le-unknown-linux-gnu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu
Created attachment 53040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53040&action=edit
reduced testcase
Output:
$ powerpc64le-unknown-linux-gnu-gcc -fexpensive-optimizations
-flive-range-shrinkage testcase.c -static
$ qemu-ppc64le -- ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
(gdb) p/x a
$5 = {0x0, 0x0, 0x0, 0x0}
(gdb) p/x b
$6 = {0x0, 0x0, 0x0, 0x0}
(gdb) p/x c
$7 = {0x00, 0x0, 0x0, 0x0}
(gdb) p/x d
$8 = {0x0, 0x0, 0x0, 0x0}
(gdb) p/x e
$9 = {0x0, 0x0, 0x0, 0x0}
(gdb) p/x u
$10 = {0x1 }
$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-771-20220526001630-g3dff965cae6-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/13.0.0/lto-wrapper
Target: powerpc64le-unknown-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
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-771-20220526001630-g3dff965cae6-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220526 (experimental) (GCC)
[Bug target/105738] asan error during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105738 --- Comment #2 from David Binderman --- (In reply to Andrew Pinski from comment #1) > It could be clang/llvm miscompiling stage 2. Can you try with gcc as the > original compiler? Thanks for the suggestion. I did that, and the problem seems to have gone away ;-> 7.5 hours of compilation and not yet finished, though.
[Bug sanitizer/105729] False positive UBsan "reference binding to null pointer of type" when evaluating array indexing which throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105729 --- Comment #3 from Jakub Jelinek --- Created attachment 53039 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53039&action=edit gcc13-pr105729.patch Untested fix.
[Bug c++/105743] New: Bogus unused but set lambda warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105743
Bug ID: 105743
Summary: Bogus unused but set lambda warning
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/xq16xac15.
```C++
void f(auto x) { x(0); }
void g() {
static constexpr auto h = [](...) { };
f([](auto x) { h(x); });
}
```
```
: In function 'void g()':
:3:25: warning: variable 'h' set but not used
[-Wunused-but-set-variable]
3 | static constexpr auto h = [](...) { };
| ^
```
Arguably, `h(x)` could perform ADL on `x`. But perhaps it'd be better to stay
silent, like the other compilers.
[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #6 from qinzhao at gcc dot gnu.org --- (In reply to Siddhesh Poyarekar from comment #5) > I'm updating the patchset to meld the two passes into one and I could add > -fstrict-flex-arrays as one of the patches to make this stricter. The work for __builtin_dynamic_object_size seems has been committed into upstream gcc already, however without -fstrict-flex-arrays. do you have plan to add this new option into gcc in stage1?
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 --- Comment #9 from Jeremy R. --- (In reply to Jonathan Wakely from comment #7) > (In reply to Jeremy R. from comment #1) > > More minimal: https://godbolt.org/z/WcGab4W8T > > The https://gcc.gnu.org/bugs very clearly says to provide the testcase > *here* not only as a URL. Thanks for letting me know
[Bug sanitizer/105729] False positive UBsan "reference binding to null pointer of type" when evaluating array indexing which throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105729 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug other/105729] False positive UBsan "reference binding to null pointer of type" when evaluating array indexing which throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105729 --- Comment #2 from Jakub Jelinek --- I think the problem is that fold_unary optimizes conversion of (const struct Bar *) ((const struct Foo *) this)->data + (sizetype) range_check (x) to const struct Bar & type into conversion of the lhs of the POINTER_PLUS_EXPR to const struct Bar & type followed by POINTER_PLUS_EXPR.
[Bug ipa/105639] [12/13 Regression] ICE in propagate_controlled_uses, at ipa-prop.cc:4195 since r12-7936-gf6d65e803623c7ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105639 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Jambor --- I proposed a fix on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595676.html
[Bug c++/105742] [9/10/11/12/13 Regression] accepts-invalid non-dependent call to non-static member function from unrelated class in presence of dependent base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105742 Patrick Palka changed: What|Removed |Added Known to fail||10.3.0, 11.2.0, 12.1.0, ||13.0, 9.4.0 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105637 Ever confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed||2022-05-26 Summary|accepts-invalid |[9/10/11/12/13 Regression] |non-dependent call to |accepts-invalid |non-static member function |non-dependent call to |from unrelated class in |non-static member function |presence of dependent base |from unrelated class in ||presence of dependent base Known to work||7.5.0 Target Milestone|--- |9.5 --- Comment #1 from Patrick Palka --- Started with r7-755-g23cb72663051cd.
[Bug c++/105742] New: accepts-invalid non-dependent call to non-static member function from unrelated class in presence of dependent base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105742
Bug ID: 105742
Summary: accepts-invalid non-dependent call to non-static
member function from unrelated class in presence of
dependent base
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
struct X {
void g();
};
struct Y { };
template
struct A : T {
void f() {
using type = decltype(X::g());
}
};
template struct A;
The call to the non-static X::g should be rejected at instantiation time
because X isn't a base of A, but instead we resolve the decltype at template
definition time and accept the testcase because we (incorrectly?) deem the call
to be non type dependent (and non instantiation dependent).
[Bug c++/105741] Wrong preprocessor parameter substitution with ##__VA_ARGS__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105741 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Even gcc 3.2 behaves this way. It is a GNU extension, so there is no standard that would cover this except for GCC documentation (and implementation). And clang behaves the same. So I think it would only cause harm to change this. Especially when the extension is there only for backwards compatibility, new code should use __VA_OPT__ which is standard.
[Bug c++/105741] Wrong preprocessor parameter substitution with ##__VA_ARGS__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105741 --- Comment #3 from JFK --- Any idea about how to work around this without the use of VA_OPT ?
[Bug c++/105741] Wrong preprocessor parameter substitution with ##__VA_ARGS__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105741 --- Comment #1 from JFK --- Same problem with 10.2.0
[Bug c++/105741] New: Wrong preprocessor parameter substitution with ##__VA_ARGS__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105741
Bug ID: 105741
Summary: Wrong preprocessor parameter substitution with
##__VA_ARGS__.
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc.gnu.org_bugzilla at jfa dot knudsen.ovh
Target Milestone: ---
This code :
#define CALL2(dummy, p1, ...) "dummy"=dummy, "p1"=p1, "va"=__VA_ARGS__
#define CALL(dummy, ...) CALL2(dummy, ##__VA_ARGS__)
#define CALL_WITHOPT(dummy, ...) CALL2(dummy __VA_OPT__(,) __VA_ARGS__)
#define CALL_ARGS "param1", "param2"
CALL("dum", "param1", "param2");
CALL_WITHOPT("dum", CALL_ARGS);
CALL("dum", CALL_ARGS);
preprocessed gives :
"dummy"="dum", "p1"="param1", "va"="param2";
"dummy"="dum", "p1"="param1", "va"="param2";
"dummy"="dum", "p1"="param1", "param2", "va"=;
We can see that, at the third line, parameter p1 = "param1", "param2" and
__VA_ARGS__ is empty.
It seems that CALL_ARGS expands to "param1", "param2" but is still only one
parameter in the variable list.
Is that the way it is supposed to be ?
Any workaround before it's fixed ?
[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #10 from Jakub Jelinek --- Created attachment 53038 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53038&action=edit gcc13-pr105732.patch Untested fix.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 --- Comment #16 from Jakub Jelinek --- That may be true, but I think only the 1/2/4/8/16 sizes are interesting to handle with special code. And as the function is provably called by a function which can have any size and through LTO can get a constant value, the options are remove the BUILD_BUG(); or ensure that the size is never constant from the mm/kasan/shadow.c (memset) call (hide e.g. through inline asm the exact value from the compiler) or have 2 different implementations, one that has BUILD_BUG() and is used only for those specific sizes and another one which doesn't (either calls just the *_n function or has everything but BUILD_BUG) that can handle arbitrary sizes.
[Bug tree-optimization/105739] [9/10 Regression] Miscompilation of Linux kernel update.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739 Jan Hubicka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-05-26 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #4 from Jan Hubicka --- mine. Looks like another case where ipa and local cprop gets out of sync...
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 --- Comment #15 from hubicka at kam dot mff.cuni.cz --- > No, see c#10. I know it will work if BUILD_BUG call is removed. However the only reason I can see why original author put it there is that he/she wanted to write special case checkers for constants that appears in practice and wanted unhandled constants to turn to compiler errors rather than quietly going the slow path...
[Bug c++/96363] bogus error with multiple constrained partial specialization forward declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96363 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.2 --- Comment #5 from Patrick Palka --- Fixed on trunk so far.
[Bug c++/96363] bogus error with multiple constrained partial specialization forward declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96363 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:97dc78d705a90c1ae83c78a7f2e24942cc3a6257 commit r13-779-g97dc78d705a90c1ae83c78a7f2e24942cc3a6257 Author: Patrick Palka Date: Thu May 26 09:43:14 2022 -0400 c++: constrained partial spec forward decl [PR96363] Here during cp_parser_single_declaration for #2, we were calling associate_classtype_constraints for TPL (the primary template type) before maybe_process_partial_specialization could get a chance to notice that we're in fact declaring a distinct constrained partial spec and not redeclaring the primary template. This caused us to emit a bogus error about differing constraints b/t the primary template and #2's constraints. This patch fixes this by moving the call to associate_classtype_constraints after the call to shadow_tag (which calls maybe_process_partial_specialization) and adjusting shadow_tag to use the return value of m_p_p_s. Moreover, if we later try to define a constrained partial specialization that's been declared earlier (as in the third testcase), then maybe_new_partial_specialization correctly notices it's a redeclaration and returns NULL_TREE. But in this case we also need to update TYPE to point to the redeclared partial spec (it'll otherwise continue pointing to the primary template type, eventually leading to a bogus error). PR c++/96363 gcc/cp/ChangeLog: * decl.cc (shadow_tag): Use the return value of maybe_process_partial_specialization. * parser.cc (cp_parser_single_declaration): Call shadow_tag before associate_classtype_constraints. * pt.cc (maybe_new_partial_specialization): Change return type to bool. Take 'type' argument by mutable reference. Set 'type' to point to the correct constrained specialization when appropriate. (maybe_process_partial_specialization): Adjust accordingly. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-partial-spec12.C: New test. * g++.dg/cpp2a/concepts-partial-spec12a.C: New test. * g++.dg/cpp2a/concepts-partial-spec13.C: New test.
[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- With a slightly modified testcase: #define m1(p1, p2, p3) p3 #define m2(p1, ...) 1 __VA_OPT__() #define M(...) m1(1, 2, m2) #if M(,)(,) #endif it started to ICE already with r8-6791-g60887f8c2df851 aka PR83708 fix. The r12-6155-g5545d1edcbdb17 change just turns that into the same tokens as before, while previously it wasn't. As __VA_OPT__() or __VA_OPT__(foo) in both cases expands to nothing, 1##nothing is still 1 and the avoid_paste token is added afterwards to make sure token after __VA_OPT__() isn't emitted right after it without whitespace. It isn't immediately clear to me what should be eating the padding token so that cpp_parse_expr doesn't see it. Or is this a bug in cpp_parse_expr? I mean, other callers of cpp_get_token_with_location like e.g. in c_lex_with_flags handle CPP_PADDING by calling cpp_get_token_with_location again. Similarly scan_translation_unit when doing -E, token_streamer::stream just remembers there was padding and goes on (and takes that into account whether whitespace should be emitted or not).
[Bug c++/105737] [10/11 only] Incorrect evaluation order in new expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105737 --- Comment #3 from m.cencora at gmail dot com --- FWIW Ordered evaluation of elements in braced-init-list exists since C++11 (it was not a part of P0145).
[Bug tree-optimization/105739] [9/10 Regression] Miscompilation of Linux kernel update.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739
--- Comment #3 from Jakub Jelinek ---
The call is added at:
#0 gimple_set_code (g=, code=GIMPLE_CALL) at
../../gcc/gimple.c:108
#1 0x00bceae1 in gimple_alloc (code=GIMPLE_CALL, num_ops=7) at
../../gcc/gimple.c:140
#2 0x00bd189a in gimple_copy (stmt=) at
../../gcc/gimple.c:1806
#3 0x0109ed79 in remap_gimple_stmt (stmt=,
id=0x7fffd620) at ../../gcc/tree-inline.c:1796
#4 0x0109f39a in copy_bb (id=0x7fffd620, bb=, num=..., den=...) at ../../gcc/tree-inline.c:1950
#5 0x010a223c in copy_cfg_body (id=0x7fffd620,
entry_block_map=, exit_block_map=,
new_entry=) at ../../gcc/tree-inline.c:2884
#6 0x010a2d21 in copy_body (id=0x7fffd620,
entry_block_map=, exit_block_map=,
new_entry=) at ../../gcc/tree-inline.c:3126
#7 0x010a6aa2 in expand_call_inline (bb=, stmt=, id=0x7fffd620,
to_purge=0x7fffd600)
at ../../gcc/tree-inline.c:4867
#8 0x010a76e7 in gimple_expand_calls_inline (bb=, id=0x7fffd620, to_purge=0x7fffd600) at
../../gcc/tree-inline.c:5060
#9 0x010a7da5 in optimize_inline_calls (fn=) at ../../gcc/tree-inline.c:5202
#10 0x01cc06ec in inline_transform (node=) at ../../gcc/ipa-inline-transform.c:682
during inlining of trc_wait_for_one_reader into rcu_tasks_trace_pertask, when
copying
_printk ("\x016%s(P%d/%d) IPI to task still in flight.\n", &__func__, _1, _8);
and later changed to __builtin_unreachable in:
#0 gimple_call_set_fndecl (gs=0x7fffea08a2a0, decl=) at ../../gcc/gimple.h:3058
#1 0x009f8bb2 in cgraph_edge::redirect_call_stmt_to_callee (
this= -> )>)
at ../../gcc/cgraph.c:1489
#2 0x010a1f10 in redirect_all_calls (id=0x7fffd620,
bb=) at ../../gcc/tree-inline.c:2814
#3 0x010a262b in copy_cfg_body (id=0x7fffd620,
entry_block_map=, exit_block_map=,
new_entry=) at ../../gcc/tree-inline.c:2950
#4 0x010a2d21 in copy_body (id=0x7fffd620,
entry_block_map=, exit_block_map=,
new_entry=) at ../../gcc/tree-inline.c:3126
#5 0x010a6aa2 in expand_call_inline (bb=, stmt=, id=0x7fffd620,
to_purge=0x7fffd600)
at ../../gcc/tree-inline.c:4867
#6 0x010a76e7 in gimple_expand_calls_inline (bb=, id=0x7fffd620, to_purge=0x7fffd600) at
../../gcc/tree-inline.c:5060
#7 0x010a7da5 in optimize_inline_calls (fn=) at ../../gcc/tree-inline.c:5202
[Bug tree-optimization/105740] New: missed optimization switch transformation for conditions with duplicate conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740 Bug ID: 105740 Summary: missed optimization switch transformation for conditions with duplicate conditions Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: b.buschinski at googlemail dot com Target Milestone: --- Created attachment 53037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53037&action=edit Attached code + asm from the compiler explorer link Compiler Explorer Link: https://godbolt.org/z/q76s99Gj9 The code on the left does not generate a switch statement. The code on the right does generate a switch statement. The code works similar, the only difference is that the duplicate "f->len > 3" check is moved to the top for the "right" version. The compiler explorer code is actually a minimized version of the code I work on (with way more conditions in a hot code path), where I can not easily move the length check to the top, because the "f-> len > 3 && ..." is done in a very complicated macro, but that's just details. I expected both code versions to generate the same assembler. Tested with GCC-12.1 and 11.3. 10.3 does not generate a switch version for both versions, as only 11 got this nice feature. On x86_64 Linux. Please let me know if you need any additional details or if this report was useful at all.
[Bug tree-optimization/105739] [9/10 Regression] Miscompilation of Linux kernel update.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739 --- Comment #2 from Jakub Jelinek --- Created attachment 53036 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53036&action=edit update.i.xz
[Bug tree-optimization/105739] [9/10 Regression] Miscompilation of Linux kernel update.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |9.5 --- Comment #1 from Jakub Jelinek --- Honza, could you please have a look?
[Bug tree-optimization/105739] New: [9/10 Regression] Miscompilation of Linux kernel update.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739 Bug ID: 105739 Summary: [9/10 Regression] Miscompilation of Linux kernel update.c Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Target: x86_64-linux The attached testcase with -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0 -fstack-protector-strong -fomit-frame-pointer -fno-stack-clash-protection -fno-strict-overflow -fno-stack-check -fconserve-stack options has a call to _printk replaced by __builtin_unreachable () and it isn't obviously clear why. One spot is in the rcu_tasks_trace_pertask function where in assembly one can see: .type rcu_tasks_trace_pertask.cold, @function rcu_tasks_trace_pertask.cold: .L1662: movl20(%rdi), %eax .text .size rcu_tasks_trace_pertask, .-rcu_tasks_trace_pertask The problem went away with r11-5188-g32934a4f45a7214 but it is unclear if that was an actual fix or just made it latent, I don't see a compound literal on that line.
[Bug c++/53281] poor error message for calling a non-const method from a const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281 --- Comment #15 from Jonathan Wakely --- Created attachment 53035 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53035&action=edit Incomplete patch
[Bug target/102218] 128-bit atomic compare and exchange does not honor memory model on AArch64 and Arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102218 Tamar Christina changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-05-26 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org
[Bug tree-optimization/105736] [12 Regression] ICE in force_gimple_operand_1, at gimplify-me.cc:79 since r13-222-g28896b38fabce818
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736 Siddhesh Poyarekar changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot gnu.org Summary|[13 Regression] ICE in |[12 Regression] ICE in |force_gimple_operand_1, at |force_gimple_operand_1, at |gimplify-me.cc:79 since |gimplify-me.cc:79 since |r13-222-g28896b38fabce818 |r13-222-g28896b38fabce818 Version|13.0|12.0 Keywords||ice-on-valid-code --- Comment #1 from Siddhesh Poyarekar --- Also affects gcc 12; it's only that it's more easily visible through the ubsan generated __bdos call like in this reproducer. The valid size check is missing a check to ensure that it's not an error_mark_node.
[Bug target/105738] asan error during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105738 Andrew Pinski changed: What|Removed |Added Keywords||build, wrong-code Component|c |target --- Comment #1 from Andrew Pinski --- It could be clang/llvm miscompiling stage 2. Can you try with gcc as the original compiler?
[Bug c/105738] New: asan error during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105738 Bug ID: 105738 Summary: asan error during bootstrap Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just got the following error during a bootstrap with asan enabled: echo NO_PIE_CFLAGS = "$NO_PIE_CFLAGS" >> tmp-libgcc.mvars mv tmp-libgcc.mvars libgcc.mvars /bin/sh ../../trunk.git/gcc/../move-if-change tmp-fixinc_list fixinc_list echo timestamp > s-fixinc_list = ==46366==ERROR: AddressSanitizer: unknown-crash on address 0x7fe50bb02c10 at pc 0x02bb655b bp 0x7ffe2f90ce00 sp 0x7ffe2f90cdf8 READ of size 8 at 0x7fe50bb02c10 thread T0 #0 0x2bb655a in NEXT_INSN(rtx_insn const*) ../../trunk.git/gcc/rtl.h:1477 #1 0x2bb655a in expensive_function_p(int) ../../trunk.git/gcc/predict.cc:3702 #2 0x3f57001 in ix86_compute_frame_layout ../../trunk.git/gcc/config/i386/i386.cc:6644 #3 0x285d1c6 in update_reg_eliminate ../../trunk.git/gcc/lra-eliminations.cc:1132 This seems to happen late in stage 3: $ egrep "^Config|^==" mk.out ... Configuring stage 3 in ./gcc = ==46366==ERROR: AddressSanitizer: unknown-crash on address 0x7fe50bb02c10 at pc 0x02bb655b bp 0x7ffe2f90ce00 sp 0x7ffe2f90cdf8 ==46366==ABORTING Configure line is CC="clang -Wall" CXX="clang++ -Wall" \ ../trunk.git/configure --prefix=/home/dcb/gcc/$PREFIX \ --with-build-config=bootstrap-ubsan \ --with-build-config=bootstrap-asan \ --disable-multilib \ --disable-werror \ --enable-checking=df,extra,fold,rtl,yes \ --enable-languages=c,c++,fortran sed 's/-O2/-O3 -march=bdver2/' < Makefile > Makefile.tmp mv Makefile.tmp Makefile
[Bug c++/105737] [10/11 only] Incorrect evaluation order in new expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105737 Andrew Pinski changed: What|Removed |Added Summary|Incorrect evaluation order |[10/11 only] Incorrect |in new expression |evaluation order in new ||expression Target Milestone|--- |10.4 --- Comment #2 from Andrew Pinski --- >It was fixed by r12-6325 Right that was a change explictly for this case and I don't know if we want to backport it or not. Note the last release in the 9 series is days away from being released so I doubt it should even be tried to backport to that release.
[Bug libstdc++/105730] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||redi at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-26
[Bug libstdc++/105730] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- g:9e18a25331fa25c3907249fede65a02c6817b06e
[Bug other/105729] False positive UBsan "reference binding to null pointer of type" when evaluating array indexing which throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105729 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-05-26 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- @Jakub, Marek: Can you please take a look?
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 --- Comment #14 from Martin Liška --- (In reply to Martin Liška from comment #13) > > To me it looked like a protection that size is not going to be large > > (or perhaps author wants to add extra special cases as they are needed) > > No, see c#10. comment 10
[Bug c++/105737] Incorrect evaluation order in new expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105737 Jonathan Wakely changed: What|Removed |Added Keywords|needs-bisection | Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-26 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- It was fixed by r12-6325 c++: don't preevaluate new-initializer The preevaluation code was causing trouble with my fix for PR94041, and now I see that it's actually wrong since P0145 was adopted for C++17, mandating order of evaluation for many expressions that were previously unspecified. I don't see a need to preserve the preevaluation code for older standard modes. gcc/cp/ChangeLog: * init.c (build_new_1): Remove preevaluation code. gcc/testsuite/ChangeLog: * g++.old-deja/g++.martin/new1.C: Don't expect preeval. * g++.dg/tree-ssa/stabilize1.C: Removed.
[Bug lto/105727] __builtin_constant_p expansion in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 --- Comment #13 from Martin Liška --- > To me it looked like a protection that size is not going to be large > (or perhaps author wants to add extra special cases as they are needed) No, see c#10.
[Bug target/105731] superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105731 --- Comment #5 from Richard Earnshaw --- The thumb1 rtx-costing function needs a complete rewrite along the lines and style of the Thumb2 and Arm costing routines. Another thing for my copious free time (TM).
[Bug c++/105737] New: Incorrect evaluation order in new expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105737
Bug ID: 105737
Summary: Incorrect evaluation order in new expression
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following program when compiled with -std=c++17 prints 1243, while it should
print 1234.
All gcc < 12 versions are affected.
#include
struct MyStruct
{
};
struct MyTuple
{
int a;
int b;
MyStruct c;
int d;
};
int deserializeInt(const char*s) noexcept
{
std::puts(s);
return 0;
}
MyStruct deserializeStruct(const char*s) noexcept
{
std::puts(s);
return {};
}
int main()
{
#if 0 // this disabled version works fine
MyTuple a = {
deserializeInt("1"),
deserializeInt("2"),
deserializeStruct("3"),
deserializeInt("4")
};
#else
new MyTuple{
deserializeInt("1"),
deserializeInt("2"),
deserializeStruct("3"),
deserializeInt("4")
};
#endif
}
Similar bug exists when placement new is used.
While this problem seems to be fixed in gcc 12, I have not found a bug report
for such a fix, so it may have been fixed by accident, so it would be good to
at least have a test case that this doesn't regress in future.
But the best would be get this fixed in gcc9, 10 and 11.
[Bug tree-optimization/105736] [13 Regression] ICE in force_gimple_operand_1, at gimplify-me.cc:79 since r13-222-g28896b38fabce818
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-05-26 Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW Version|12.0|13.0 Ever confirmed|0 |1
[Bug target/47769] [missed optimization] use of btr (bit test and reset)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47769 Bug 47769 depends on bug 105735, which changed state. Bug 105735 Summary: GCC failed to reduce &= loop_inv in loop. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105735 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/101991] bit_and or bit_ior with an invariant inside loop is not pulled out of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101991 --- Comment #2 from Andrew Pinski --- *** Bug 105735 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/105735] GCC failed to reduce &= loop_inv in loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105735 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Actually this is a dup of bug 101991. *** This bug has been marked as a duplicate of bug 101991 ***
[Bug tree-optimization/105736] New: [13 Regression] ICE in force_gimple_operand_1, at gimplify-me.cc:79 since r13-222-g28896b38fabce818
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736
Bug ID: 105736
Summary: [13 Regression] ICE in force_gimple_operand_1, at
gimplify-me.cc:79 since r13-222-g28896b38fabce818
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
Target Milestone: ---
The following crashes:
$ cat vector.c
struct TV4 {
__attribute__((vector_size(sizeof(int) * 4))) int v;
};
struct TV4 val3;
int *f(struct TV4 *a) { return &a->v[0]; }
int main() { *f(&val3) != 4; }
$ gcc vector.c -fsanitize=object-size -O3 -c
during GIMPLE pass: ccp
In function ‘main’:
cc1: internal compiler error: in force_gimple_operand_1, at gimplify-me.cc:79
0x725bd0 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
/home/marxin/Programming/gcc/gcc/gimplify-me.cc:79
0xc09e78 gimplify_and_update_call_from_tree(gimple_stmt_iterator*, tree_node*)
/home/marxin/Programming/gcc/gcc/gimple-fold.cc:794
0xc197e7 gimple_fold_call
/home/marxin/Programming/gcc/gcc/gimple-fold.cc:5732
0xc1beb3 fold_stmt_1
/home/marxin/Programming/gcc/gcc/gimple-fold.cc:6296
0x1122553 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-ssa-propagate.cc:853
0x1cefb65 dom_walker::walk(basic_block_def*)
/home/marxin/Programming/gcc/gcc/domwalk.cc:309
0x112178b substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-ssa-propagate.cc:987
0x106c388 ccp_finalize
/home/marxin/Programming/gcc/gcc/tree-ssa-ccp.cc:1023
0x106c992 do_ssa_ccp
/home/marxin/Programming/gcc/gcc/tree-ssa-ccp.cc:2961
0x106c992 execute
/home/marxin/Programming/gcc/gcc/tree-ssa-ccp.cc:3004
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8 from Jonathan Wakely --- Regression started with r12-3643 c++: improve lookup of member-qualified names
[Bug tree-optimization/105735] New: GCC failed to reduce &= loop_inv in loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105735
Bug ID: 105735
Summary: GCC failed to reduce &= loop_inv in loop.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
This is another case from 47769, similar like 103462, but a little different.
unsigned long cfunc_one(unsigned long tmp, unsigned long bit2) {
for (unsigned long bit = 0; bit < 64; bit++) {
tmp &= bit2;
}
return tmp;
}
it should be equal to
unsigned long cfunc_one(unsigned long tmp, unsigned long bit2) {
tmp &= bit2;
return tmp;
}
but gcc generates a loop.
cfunc_one(unsigned long, unsigned long):
mov eax, 64
.L2:
and rdi, rsi
dec rax
jne .L2
mov rax, rdi
ret
Similar for |= and ^=.
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 --- Comment #7 from Jonathan Wakely --- (In reply to Jeremy R. from comment #1) > More minimal: https://godbolt.org/z/WcGab4W8T The https://gcc.gnu.org/bugs very clearly says to provide the testcase *here* not only as a URL.
