[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 --- Comment #4 from Jerry DeLisle --- I think the patch works fine as is as far as I can tell. There will be a similar fix for writing files with encoding='utf8'
[Bug testsuite/100407] New: New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 Bug ID: 100407 Summary: New test cases attr-retain-*.c fail after their introduction in r11-7284 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:6347f4a0904fce17eedf5c071be6f3c118680290, r11-7284 These attr-retain-*.c test cases fail on powerpc64 BE. FAIL: gcc.c-torture/compile/attr-retain-1.c -O0 scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O1 scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O3 -g scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -Os scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O0 scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O0 scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O1 scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O1 scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O3 -g scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O3 -g scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -Os scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -Os scan-assembler .rodata.used_rodata2,"aR" I thought I saw some other ones earlier but these are the ones failing now in trunk and gcc 11. Author: H.J. Lu Date: Mon Feb 15 11:31:12 2021 -0800 Add retain attribute to place symbols in SHF_GNU_RETAIN section
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Keywords||patch --- Comment #8 from Thomas Rodgers --- Candidate patch submitted to mailing list - https://gcc.gnu.org/pipermail/libstdc++/2021-May/052464.html
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Status|WAITING |ASSIGNED
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 91914, which changed state. Bug 91914 Summary: [9 Regression] Invalid strlen optimization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/91914] [9 Regression] Invalid strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Martin Sebor --- (In reply to Richard Biener from comment #7) > It's not clear to me which rev. fixed this for GCC 10, but we should > backport the fix to GCC 9 please. It was fixed in r274837. The change isn't completely isolated and affects warnings which is why I suggested the much more targeted fix in comment #2. I committed it in r9-9501.
[Bug tree-optimization/91914] [9 Regression] Invalid strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:176e7fa198dd50aca4c882c74fc8f4386a3f9131 commit r9-9501-g176e7fa198dd50aca4c882c74fc8f4386a3f9131 Author: Martin Sebor Date: Mon May 3 18:10:03 2021 -0600 Minimal change to avoid incorrect strlen constant folding (PR 91914). gcc/ChangeLog: PR tree-optimization/91914 * expr.c (string_constant): Pass argument type to fold_ctor_reference to guide it. gcc/testsuite/ChangeLog: PR tree-optimization/91914 * gcc.dg/strlenopt-79.c: New test.
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug c++/100405] Add implicit 'return *this;' in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- That is already supported with -fsanitize-undefined-trap-on-error -fsanitize=unreachable or -fsanitize=unreachable. It isn't always the best choice though, e.g. for functions with switches or ifs where the compiler can't prove it doesn't fallthru into end of function but the user is certain, having __builtin_trap or __ubsan_handle_builtin_unreachable is certainly more expensive than __builtin_unreachable.
[Bug c++/100405] Add implicit 'return *this;' in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405 --- Comment #3 from Jonathan Wakely --- Another option would be to add an implicit __builtin_trap() there. Failing hard is probably preferable to the kind of surprising behaviour you get from the optimizers today.
[Bug testsuite/100355] gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100355 --- Comment #2 from Christophe Lyon --- Tried that, but it's not taken into account. ieee.exp uses c-torture-execute, maybe that function does not honor dg directives? (none of the tests under ieee/ has a dg- directive)
[Bug c++/46224] Enhancement: Issue warning when matching placement delete operator is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46224 Martin Sebor changed: What|Removed |Added Last reconfirmed|2018-10-01 00:00:00 |2021-5-3 Blocks|87403 |100406 --- Comment #5 from Martin Sebor --- Reconfirming with GCC 11. The release has added -Wmismatched-new-delete. It doesn't detect the problems in any of the test cases but doing so sounds like a useful enhancement to the warning. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 [Bug 100406] bogus/missing -Wmismatched-new-delete
[Bug middle-end/100406] bogus/missing -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-05-03 Keywords||diagnostic Alias||Wmismatched-new-delete Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- -Wmismatched-new-delete was first introduced in GCC 11.1.0.
[Bug middle-end/100406] New: bogus/missing -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 Bug ID: 100406 Summary: bogus/missing -Wmismatched-new-delete Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is a meta bug for false positives and negatives in and enhancements for -Wmismatched-new-delete.
[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100180 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Christophe Lyon --- Fixed.
[Bug libstdc++/100286] experimental/net/internet/socket/opt.cc fails on arm-eabi (r12-137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100286 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Christophe Lyon --- Fixed.
[Bug c++/70834] Incorrect warning for placement new when conditionally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834 Martin Sebor changed: What|Removed |Added Last reconfirmed|2017-01-03 00:00:00 |2021-5-3 Blocks||100399 Known to fail|8.0 |11.1.0, 12.0, 8.4.0 --- Comment #7 from Martin Sebor --- No change in GCC 11. This false positive too will be avoided by running -Wplacement-new later, when the program is in SSA form, rather than in the front end. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399 [Bug 100399] bogus/missing -Wplacement-new
[Bug libstdc++/100351] experimental/net/internet/tcp.cc fails on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100351 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Christophe Lyon --- Fixed
[Bug target/100321] [OpenMP][nvptx, SIMT] (Con't) Reduction fails with optimization and 'loop'/'for simd' but not with 'for'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #7 from Tom de Vries --- Patch committed, marking resolved-fixed.
[Bug target/100321] [OpenMP][nvptx, SIMT] (Con't) Reduction fails with optimization and 'loop'/'for simd' but not with 'for'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321 --- Comment #6 from CVS Commits --- The master branch has been updated by Tom de Vries : https://gcc.gnu.org/g:f87990a2a8fc9e20d30462a0a4c9047582af0cd9 commit r12-395-gf87990a2a8fc9e20d30462a0a4c9047582af0cd9 Author: Tom de Vries Date: Mon May 3 11:36:14 2021 +0200 [openmp, simt] Disable SIMT for user-defined reduction The test-case included in this patch contains this target region: ... for (int i0 = 0 ; i0 < N0 ; i0++ ) counter_N0.i += 1; ... When running with nvptx accelerator, the counter variable is expected to be N0 after the region, but instead is N0 / 32. The problem is that rather than getting the result for all warp lanes, we get it for just one lane. This is caused by the implementation of SIMT being incomplete. It handles regular reductions, but appearantly not user-defined reductions. For now, handle this by disabling SIMT in this case, specifically by setting sctx->max_vf to 1. Tested libgomp on x86_64-linux with nvptx accelerator. gcc/ChangeLog: 2021-05-03 Tom de Vries PR target/100321 * omp-low.c (lower_rec_input_clauses): Disable SIMT for user-defined reduction. libgomp/ChangeLog: 2021-05-03 Tom de Vries PR target/100321 * testsuite/libgomp.c/target-44.c: New test.
[Bug tree-optimization/100366] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366 --- Comment #3 from Sam Varshavchik --- If the warning is justified then something else isn't adding up. I double-checked (with cppreference.com) something that I was pretty sure of: and an insert() at the end() iterator is valid. The insert()ed range is valid. If the C++ code is UB, or even potentially UB, I don't see it.
[Bug middle-end/100403] Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91227 --- Comment #4 from Martin Sebor --- The pointer limitation is discussed in more detail in pr91227.
[Bug middle-end/100403] Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Component|c |middle-end
CC||msebor at gcc dot gnu.org
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Martin Sebor ---
The warning behaves as designed. There's no way for it tell from the IL that
the function cannot return the address of x:
[local count: 375809640]:
# msg_21 = PHI <"Error w/code"(6), msg_19(10)>
if ( [(void *) + 128B] > msg_21)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 187904820]:
[local count: 1073741824]:
# err_3 = PHI
x ={v} {CLOBBER};
return err_3; <<< -Wreturn-local-addr
[local count: 375809641]:
# msg_19 = PHI <(5), (3)> <<< x is on stack
__builtin_puts (msg_19);
goto ; [100.00%]
}
As Andrew explained, the pointer relational expression is undefined if msg
points to the string literal (changing it to equality avoids the warning). In
addition, and arguably more important, GCC's ability to extract useful
information from pointer relationships is quite limited so it doesn't "see
through" the expression. The underlying problem (and the limitation) can be
reduced to the failure to fold and the false positive for the much simpler test
case below. For a + n to be valid n must be zero or one, and so the function
must return null. If GCC used that to fold the function the warning wouldn't
trigger.
With that, I think the report can be resolved as invalid (I'm sure the pointer
range optimization has its own bug.)
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-isolate-paths=/dev/stdout z.c
void* f (int n)
{
char a[1], *p = a + n;
if (p <= a + 1)
p = 0;
return p;
}
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
z.c: In function ‘f’:
z.c:6:10: warning: function may return address of local variable
[-Wreturn-local-addr]
6 | return p;
| ^
z.c:3:8: note: declared here
3 | char a[1], *p = a + n;
|^
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
p_7 -> { p_2 }
.MEM_8 -> { .MEM_6 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 2 ( 33%)
Removing basic block 3
void * f (int n)
{
char * p;
char a[1];
sizetype _1;
[local count: 1073741824]:
_1 = (sizetype) n_3(D);
p_4 = + _1;
if ( [(void *) + 1B] >= p_4)
goto ; [100.00%]
else
goto ; [0.00%]
[local count: 311385128]:
# p_2 = PHI <0B(2)>
a ={v} {CLOBBER};
return p_2;
[count: 0]:
# p_7 = PHI
a ={v} {CLOBBER};
return 0B;
}
[Bug c++/100405] Add implicit 'return *this;' in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405
Jonathan Wakely changed:
What|Removed |Added
Summary|missing return assignment |Add implicit 'return
||*this;' in assignment
||operators
Resolution|INVALID |---
Severity|normal |enhancement
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=85523
Last reconfirmed||2021-05-03
Ever confirmed|0 |1
Status|RESOLVED|NEW
--- Comment #2 from Jonathan Wakely ---
It would be nice if G++ would Do The Right Thing here:
struct T
{
T& operator=(const T& t)
{
i = t.i;
/* forgot to write return *this; */
}
int i = 0;
};
If the user forgets to write 'return *this;' in an assignment operator the
results can be quite unpleasant (after optimization).
Similar to the implicit 'return 0;' in main it would be nice to add an implicit
return *this to assignment operators. It could be done in cases where
-Wreturn-type warns (e.g. there isn't a throw or a call to a noreturn function
before the end of the function) and if the return type is decltype(*this).
G++ does give a -Wreturn-type warning for the example above (and since gcc 9 it
adds a fix-it hint, thanks to PR 85523) but for a template it doesn't warn
until it's instantiated:
template
struct T
{
T& operator=(const T& t)
{
i = t.i;
/* forgot to write return *this; */
}
int i = 0;
};
This compiles without a warning (which is PR 48586).
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/100405] missing return assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Oops, I hit enter in the Summary field and submitted this too soon. Please ignore (for now).
[Bug c++/100405] New: missing return assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405 Bug ID: 100405 Summary: missing return assignment Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: ---
[Bug c/100403] Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- > undefined if msg is not in the range of x.rec[0]...x.rec[RECLEN] Indeed for the segmented data address space. But in most systems it's linear, and the warning is then architecture dependent, and is only expected on those, where the comparison cannot be safely made. Besides, the warning then should be about that fact, not the return address being of a local variable -- that's misleading, at best.
[Bug libstdc++/100290] join_view::_Iterator::operator++ copies _M_parent->_M_inner when _S_ref_is_glvalue is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100290 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed.
[Bug libstdc++/100290] join_view::_Iterator::operator++ copies _M_parent->_M_inner when _S_ref_is_glvalue is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100290 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b81834eaf85d5c4e0df8e4fc2307cbdd083dea6c commit r10-9789-gb81834eaf85d5c4e0df8e4fc2307cbdd083dea6c Author: Patrick Palka Date: Tue Apr 27 14:07:46 2021 -0400 libstdc++: Fix up lambda in join_view::_Iterator::operator++ [PR100290] Currently, the return type of this lambda is decltype(auto), so the lambda ends up returning a copy of _M_parent->_M_inner rather than a reference to it when _S_ref_glvalue is false. This means _M_inner and ranges::end(__inner_range) are respectively an iterator and sentinel for different ranges, so comparing them is undefined. libstdc++-v3/ChangeLog: PR libstdc++/100290 * include/std/ranges (join_view::_Iterator::operator++): Correct the return type of the lambda to avoid returning a copy of _M_parent->_M_inner. * testsuite/std/ranges/adaptors/join.cc (test10): New test. (cherry picked from commit 85ef4b8d4eb3313a48b79c7e752891f9646bb246)
[Bug middle-end/100401] Bogus -Wformat-overflow for a trailing zero-length array of a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- > GCC warnings are designed to "report constructions that are not inherently > erroneous but that are risky or suggest there may have been an error." Certainly, but the [0] size trailing member arrays were specifically devised to be such constructions, TBH. So the warning in this case is like shooting yourself in the foot... Especially when the boundaries are well observed.
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384
Jonathan Wakely changed:
What|Removed |Added
Resolution|INVALID |---
Ever confirmed|0 |1
Last reconfirmed||2021-05-03
Status|RESOLVED|NEW
--- Comment #6 from Jonathan Wakely ---
Yes, we can fix this easily without the rest of P2162 (and can backport it):
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1248,7 +1248,8 @@ namespace __variant
#endif
template
-constexpr decltype(auto) visit(_Visitor&&, _Variants&&...);
+constexpr invoke_result_t<_Visitor, variant_alternative_t<0,
_Variants>...>
+visit(_Visitor&&, _Variants&&...);
template
inline enable_if_t<(is_move_constructible_v<_Types> && ...)
@@ -1736,7 +1737,7 @@ namespace __variant
template
-constexpr decltype(auto)
+constexpr invoke_result_t<_Visitor, variant_alternative_t<0,
_Variants>...>
visit(_Visitor&& __visitor, _Variants&&... __variants)
{
if ((__variants.valueless_by_exception() || ...))
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 --- Comment #5 from Jonathan Wakely --- Possibly, but it needs to be constrained for p2162 anyway, which I'm doing via the return type.
[Bug tree-optimization/100404] Unable to disable removal of null pointer checks for nonnull function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100404
--- Comment #1 from Jonathan Wakely ---
I'm pretty sure what the docs mean is that the compiler will not optimise the
caller to assume that anything passed to the function is non-null. Inside the
function it will still assume the parameter is never null.
So by default the null check here can be removed:
void f(char* p) {
isnull(p);
if (p)
puts(p);
}
The puts call will be done unconditionally, because using p as the argument to
isnull implies it is not null, so the check is redundant.
The option prevents the if (p) check being removed.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #16 from Andrew Pinski --- (In reply to Vineet Gupta from comment #15) > The problem is is indeed gone. I need to analyze the assembly fully how it > prevents the bad case. e.g. I'm still not comfortable seeing the loop > entered with following and it doing 8 byte ldd/std when we know it should > only do 2 at a time. Why? It is called a "vectorization" optimization. Where we are vectorizing the 2 byte load/stores into a 4x2 vector load/stores.
[Bug middle-end/100401] Bogus -Wformat-overflow for a trailing zero-length array of a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.1.0 Summary|Bogus -Wformat-overflow |Bogus -Wformat-overflow for |warning |a trailing zero-length ||array of a union CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Component|c |middle-end Last reconfirmed||2021-05-03 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed with GCC 10. The warning is avoided in GCC 11 (since r11-5622). The change is too intrusive to backport and it's seems that the warning doesn't trigger anymore might be incidental to it. It can still be reproduced on trunk but only in C++. I would suggest to expect warnings for tricks like in the test case (writing past subobject boundaries). GCC warnings are designed to "report constructions that are not inherently erroneous but that are risky or suggest there may have been an error." Access warnings like -Warray-bounds, -Wformat-overflow, and -Wstringop-overflow try to accommodate code they have been taught is likely safe but the logic is secondary to helping find bugs, and not foolproof.
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a32b7d03210f1763a5ccd017181ad88bd95b07d1 commit r11-8344-ga32b7d03210f1763a5ccd017181ad88bd95b07d1 Author: Patrick Palka Date: Mon May 3 13:35:37 2021 -0400 c++: base-clause parsing and implicit 'this' [PR100362] My r11-6815 change to defer access checking when processing a base-clause removed a pair of pushclass / popclass calls that seemed to be unnecessary now that we'd also defer access checking while parsing the base-clause. But it turns out these calls make a difference in the below testcase, where we have a local class whose base-clause implicitly uses the 'this' of the enclosing class. Before r11-6815, while parsing the base-clause of the local class, maybe_resolve_dummy would fail to resolve the dummy 'this' object because the current scope would be the local class. Now, since the current scope is the lambda, maybe_resolve_dummy succeeds and returns the 'this' for the enclosing class Qux. Later, during deferred instantiation of the local class, we get confused trying to resolve the access of 'a_' through this non-dummy 'this'. So this patch just reinstates the calls to pushclass / popclass that were removed in r11-6815. gcc/cp/ChangeLog: PR c++/100362 * parser.c (cp_parser_class_head): Reinstate calls to pushclass and popclass when parsing the base-clause that were removed in r11-6815. gcc/testsuite/ChangeLog: PR c++/100362 * g++.dg/cpp1y/lambda-generic-100362.C: New test. (cherry picked from commit 2a6fc19e655e696bf0df9b7aaedf9848b23f07f3)
[Bug c/100404] New: Unable to disable removal of null pointer checks for nonnull function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100404
Bug ID: 100404
Summary: Unable to disable removal of null pointer checks for
nonnull function arguments
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gccgc at bithub dot de
Target Milestone: ---
Based on the documentation of the "nonnull" function attribute
"-fno-delete-null-pointer-checks" may be used to disable compiler optimizations
based on the knowledge that a function argument cannot be null ([1]).
However, on GCC 10.2 with optimization level 1 (and also on earlier versions
with optimization level 2) the NULL check is eliminated from the following
sample program:
int __attribute__ ((nonnull)) isnull(char *ptr) {
if (ptr == 0)
return 0;
return 1;
}
int main(void) {
return isnull(0);
}
Compiling this sample without optimizations and "-fdelete-null-pointer-checks"
does not eliminate the check so the optimization seems to be triggered by
another optimization.
[1]
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-nonnull-function-attribute
[Bug c/100403] Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403 --- Comment #1 from Andrew Pinski --- Note, the following condition in the if statement if (x.rec <= msg && msg < x.rec + sizeof(x)) Is undefined if msg is not in the range of x.rec[0]...x.rec[RECLEN] .
[Bug c++/86355] [8/9/10/11/12 Regression] Internal compiler error with pack expansion and fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86355
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Known to fail||5.2.0, 6.4.0
Target Milestone|--- |8.5
Known to work||5.1.0
Summary|Internal compiler error |[8/9/10/11/12 Regression]
|with pack expansion and |Internal compiler error
|fold expression |with pack expansion and
||fold expression
--- Comment #5 from Patrick Palka ---
A reduced valid C++11 testcase:
template struct integral_constant {
static const int value = 1;
};
template using mp_all = integral_constant;
template using check2 = mp_all>>;
check2<> x;
We started ICEing on this one after r6-1487.
[Bug c/100403] New: Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403
Bug ID: 100403
Summary: Bogus "function may return address of local variable"
warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat test.c
#include
#include
#define RECLEN 128
struct R {
int head;
int code;
char text[1];
};
const char* fun(int n, const struct R* p)
{
union {
struct R r;
char rec[RECLEN];
} x;
const char* err = 0;
memset(, 0, sizeof(x));
if (p)
memcpy(, p, sizeof(*p));
else
err = "Invalid argument";
if (!err) {
static const char magic[] = "MAGIC";
const char* msg;
if (memcmp(x.rec, magic, sizeof(magic)-1) == 0)
msg = x.rec;
else if (x.r.text[0])
msg = x.r.text;
else
msg = "Error w/code";
if (msg)
printf("%s\n", msg);
if (x.rec <= msg && msg < x.rec + sizeof(x))
err = "Error detected";
else
err = msg;
} else
printf("%s\n", err);
return err;
}
$ gcc -Wall -O2 -c test.c
test.c: In function ‘fun’:
test.c:45:12: warning: function may return address of local variable
[-Wreturn-local-addr]
45 | return err;
|^~~
test.c:19:7: note: declared here
19 | } x;
| ^
test.c:19:7: note: declared here
Noted that does not matter whether "sizeof(x)" or "sizeof(x.rec)" is used at
the end of the "if()" statement on line 39.
[Bug tree-optimization/100391] 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100391 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|target |tree-optimization Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. There is a missed optimization at the tree level in the first place. The cast to uint32_t is not prograded back through the PHI node. _1 = kt_4 >> 60; if (_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: kt_5 = kt_4 & 1152921504606846975; [local count: 1073741824]: # kt_2 = PHI _6 = (uint32_t) kt_2; If it was then the above would have became just: _6 = (uint32_t) kt_4;
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #15 from Vineet Gupta --- (In reply to Linus Torvalds from comment #14) > (In reply to Vineet Gupta from comment #13) > > Sorry the workaround proposed by Alexander doesn't seem to cure it (patch > > attached), outcome is the same > > Vineet - it's not the ldd/std that is necessarily buggy, it's the earlier > tests of the address that guard that vectorized path. > > So your quoted parts of the code generation aren't necessarily the > problematic ones. /me slaps myself. How can I be so stupid. > Did you actually test the code and check whether it has the same issue? > Maybe it changed the address limit guards before that ldd/std? The problem is is indeed gone. I need to analyze the assembly fully how it prevents the bad case. e.g. I'm still not comfortable seeing the loop entered with following and it doing 8 byte ldd/std when we know it should only do 2 at a time. r21 = 0xbf178036 (pre-increment so 0x3e will be first src) r22 = 0xbf1780b2 LPC = 4 80d9a360: lp 12 ;80d9a36c 80d9a364: ldd.a r18r19,[r21,8] 80d9a368: std.ab r18r19,[r22,8] > I also sent you a separate patch to test if just upgrading to a newer > version of the zlib code helps. Although that may be buggy for other > reasons, it's not like I actually tested the end result.. But it would be > interesting to hear if that one works for you (again, ldd/std might be a > valid end result of trying to vectorize that code assuming the aliasing > tests are done correctly in the vectorized loop headers). Thx for that. And this seems to boot as well.
[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Thanks for the bug report, confirmed. Started with r11-7931. Reduced reproducer: template using enable_if_t = int; template bool has_P_match_v; template class... List> enable_if_t> a;
[Bug c++/100396] [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396
--- Comment #3 from Patrick Palka ---
(In reply to vopl from comment #2)
> Please, try this, also failed
>
> /0/1/2/3/4/5/6///
> //7
> template struct Checker
> {
> using Some = decltype(F{}(Args{}...));
> };
>
> template concept valid =
> requires { typename Checker::Some; };
>
> /0/1/2/3/4/5/6///
> //7
> template auto ovr(F f, Args... args)
> requires valid
> {
> return ovr(int{}, f, args...); // a second ovr is expected
> to be called, but the compiler tries to call this ovr again. Collision
> between 'int' and 'F' is ignored, extra Args provided to call
> }
>
> template auto ovr(int, F f, Args... args)
> {
> return f(args...);
> }
>
> /0/1/2/3/4/5/6///
> //7
> void use()
> {
> ovr([]{});
> }
>
>
> $ g++-11.1.0 -std=c++20 -c src.cpp
> src.cpp: In instantiation of 'struct Checker,
> use():: >':
> src.cpp:8:25: required by substitution of 'template Args> auto ovr(F, Args ...) requires valid [with F =
> use()::; Args = {use()::}]'
> src.cpp:14:27: required from 'auto ovr(F, Args ...) requires valid Args ...> [with F = use()::; Args = {}]'
> src.cpp:25:8: required from here
> src.cpp:4:30: error: no match for call to '(use()::)
> (use()::)'
> 4 | using Some = decltype(F{}(Args{}...));
> | ~~~^~~
> src.cpp:4:30: note: candidate: 'void (*)()' (conversion)
> src.cpp:4:30: note: candidate expects 1 argument, 2 provided
> src.cpp:25:9: note: candidate: 'use()::'
>25 | ovr([]{});
> | ^
> src.cpp:25:9: note: candidate expects 0 arguments, 1 provided
>
> --
> IMHO, the problem is not caused by concepts, but caused by corrupted
> overloading selection mechanic. Please, take a look at the collision between
> argument 'int{}' and first template parameter specified as 'F'. Next, no
> SFINAE expected in this case due to correct overloading, but overloading
> failed and SFINAE happens. Thanks.
Although the collision between 'int{}' and the template argument for 'F' does
mean that the first overload ultimately isn't viable, the compiler as per
CWG2369 first needs to check the overload's constraints (using the
provided/deduced template arguments) _before_ checking whether 'int' is
convertible to 'F', and it's during this constraint checking we hit the hard
error. So as far as I can tell, the compiler is behaving as specified. See
also PR99599 and its related PRs.
[Bug tree-optimization/100366] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
The warning is issued during expansion of the memcpy call. It seems fishy that
although it mentions __builtin_memcpy it points to __builtin_memmove:
error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ writing
1 or more bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ~^~~
The IL looks like the warning is justified:
void func (struct vector & vec)
{
const ptrdiff_t _Num;
char * _6;
char * _7;
char * prephitmp_16;
char * _21;
long int _23;
long unsigned int _24;
sizetype prephitmp_31;
char * _36;
char * _38;
char * prephitmp_42;
char * _50;
long unsigned int _Num.10_52;
char * _54;
char * _61;
char * pretmp_67;
long int _69;
char * pretmp_70;
long int _71;
unsigned int pretmp_72;
unsigned int _89;
char * _90;
char * _98;
char * _101;
long unsigned int _112;
char * _116;
long unsigned int _144;
long int _146;
char * _147;
char * _155;
sizetype _157;
char * _158;
[local count: 1073741824]:
_6 = vec_2(D)->D.33449._M_impl.D.32762._M_start;
_7 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
if (_6 != _7)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 322122544]:
_21 = vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage;
_23 = _21 - _7;
_24 = (long unsigned int) _23;
if (_24 > 3)
goto ; [67.00%]
else
goto ; [33.00%]
[local count: 751619281]:
vec_2(D)->D.33449._M_impl.D.32762._M_finish = _6;
_147 = vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage;
_146 = _147 - _6;
_144 = (long unsigned int) _146;
if (_144 > 3)
goto ; [67.00%]
else
goto ; [33.00%]
[local count: 237404317]:
# prephitmp_16 = PHI <_7(3), _6(4)>
_89 = MEM [(char * {ref-all})];
MEM [(char * {ref-all})prephitmp_16] = _89;
_36 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
_38 = _36 + 4;
vec_2(D)->D.33449._M_impl.D.32762._M_finish = _38;
goto ; [100.00%]
[local count: 108584968]:
__builtin_memmove (_90, pretmp_67, _157);
MEM [(char * {ref-all})_155] = pretmp_72;
_116 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
_Num_117 = _116 - prephitmp_42;
if (_Num_117 != 0)
goto ; [33.00%] >>> _Num_117 != 0
else
goto ; [67.00%]
[local count: 220460391]:
MEM [(char * {ref-all})_155] = pretmp_72;
_50 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
_Num_51 = _50 - prephitmp_42;
if (_Num_51 != 0)
goto ; [33.00%] >>> _Num_51 != 0
else
goto ; [67.00%]
[local count: 108584968]:
# _Num_119 = PHI <_Num_51(7), _Num_117(6)> <<< _Num_119 != 0
_Num.10_52 = (long unsigned int) _Num_119;
__builtin_memcpy (_61, prephitmp_42, _Num.10_52); <<< -Wstringop-overflow
[local count: 256293430]:
# prephitmp_31 = PHI <0(7), _Num.10_52(8)>
_54 = _61 + prephitmp_31;
if (pretmp_67 != 0B)
goto ; [40.26%]
else
goto ; [59.74%]
[local count: 175940553]:
# _98 = PHI <_54(9), _61(6)>
_71 = pretmp_70 - pretmp_67;
_112 = (long unsigned int) _71;
operator delete (pretmp_67, _112);
[local count: 329045359]:
# _101 = PHI <_54(9), _98(10)>
vec_2(D)->D.33449._M_impl.D.32762._M_start = _90;
vec_2(D)->D.33449._M_impl.D.32762._M_finish = _101;
vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage = _158;
[local count: 1048452384]:
return;
[local count: 230225493]:
# prephitmp_42 = PHI <_6(4), _7(3)>
_90 = operator new (4); <<< _90 is 4 bytes
pretmp_67 = vec_2(D)->D.33449._M_impl.D.32762._M_start;
_69 = prephitmp_42 - pretmp_67;
_157 = (sizetype) _69;
_158 = _90 + 4;
pretmp_70 = vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage;
_155 = _90 + _157; <<< _155 is in [_90, _90
+ 4]
_61 = _155 + 4; <<< _61 = _90 + 4
pretmp_72 = MEM [(char * {ref-all})];
if (_69 != 0)
goto ; [58.89%]
else
goto ; [41.11%]
}
In the translation unit the warning is triggered by a call to the __copy_m()
function below:
template
struct __copy_move<_IsMove, true, random_access_iterator_tag>
{
template
static _Tp*
__copy_m(const _Tp* __first, const _Tp* __last, _Tp* __result)
{
using __assignable = conditional<_IsMove,
is_move_assignable<_Tp>,
is_copy_assignable<_Tp>>;
static_assert( __assignable::type::value, "type is not assignable" );
const ptrdiff_t _Num = __last - __first;
if (_Num)
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #14 from Linus Torvalds --- (In reply to Vineet Gupta from comment #13) > Sorry the workaround proposed by Alexander doesn't seem to cure it (patch > attached), outcome is the same Vineet - it's not the ldd/std that is necessarily buggy, it's the earlier tests of the address that guard that vectorized path. So your quoted parts of the code generation aren't necessarily the problematic ones. Did you actually test the code and check whether it has the same issue? Maybe it changed the address limit guards before that ldd/std? I also sent you a separate patch to test if just upgrading to a newer version of the zlib code helps. Although that may be buggy for other reasons, it's not like I actually tested the end result.. But it would be interesting to hear if that one works for you (again, ldd/std might be a valid end result of trying to vectorize that code assuming the aliasing tests are done correctly in the vectorized loop headers).
[Bug c++/100344] [12 Regression] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Patrick Palka --- Fixed.
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #3 from Hannes Domani --- Created attachment 50745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50745=edit output of -fdump-tree-optimized
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #2 from Hannes Domani --- Created attachment 50744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50744=edit assembly (-S)
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #1 from Hannes Domani --- Created attachment 50743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50743=edit preprocessed code (-E)
[Bug target/100402] New: Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402
Bug ID: 100402
Summary: Crash in longjmp
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ssbssa at yahoo dot de
Target Milestone: ---
The following example:
-- >8 --
// gcc -O1 test.c
#include
static jmp_buf buf;
static bool stop = false;
void call_func(void(*func)(void))
{
func();
}
void func()
{
stop = true;
longjmp(buf, 1);
}
int main()
{
setjmp(buf);
while (!stop)
call_func(func);
return 0;
}
-- >8 --
Crashes deep in longjmp():
Starting program: C:\src\tests\a.exe
gdb: unknown target exception 0xc028 at 0x779dd7e8
Program received signal ?, Unknown signal.
0x779dd7e8 in ntdll!RtlRaiseStatus () from
C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0 0x779dd7e8 in ntdll!RtlRaiseStatus () from
C:\Windows\SYSTEM32\ntdll.dll
#1 0x7797f4ec in ntdll!RtlIsDosDeviceName_U () from
C:\Windows\SYSTEM32\ntdll.dll
#2 0x07fefe11e5a3 in msvcrt!longjmp () from C:\Windows\system32\msvcrt.dll
#3 0x00013fe61620 in func ()
#4 0x00013fe61627 in call_func ()
#5 0x00013fe61664 in main ()
#6 0x00013fe61431 in __tmainCRTStartup () at
C:/gcc/src/mingw-w64-v8.0.0/mingw-w64-crt/crt/crtexe.c:345
#7 0x00013fe615b6 in mainCRTStartup () at
C:/gcc/src/mingw-w64-v8.0.0/mingw-w64-crt/crt/crtexe.c:220
Note: Doesn't crash with -O0, or if I change `while (!stop)` to `if (!stop)`.
And it also works fine with gcc-10.2, or if I revert both fixes [1] [2] of
PR99234.
[1]
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=49a714e59194a7c549aa6657676a1b4be4520650
[2]
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=2939b358936bb824330888def98ad848dea41483
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2a6fc19e655e696bf0df9b7aaedf9848b23f07f3 commit r12-392-g2a6fc19e655e696bf0df9b7aaedf9848b23f07f3 Author: Patrick Palka Date: Mon May 3 13:35:37 2021 -0400 c++: base-clause parsing and implicit 'this' [PR100362] My r11-6815 change to defer access checking when processing a base-clause removed a pair of pushclass / popclass calls that seemed to be unnecessary now that we'd also defer access checking while parsing the base-clause. But it turns out these calls make a difference in the below testcase, where we have a local class whose base-clause implicitly uses the 'this' of the enclosing class. Before r11-6815, while parsing the base-clause of the local class, maybe_resolve_dummy would fail to resolve the dummy 'this' object because the current scope would be the local class. Now, since the current scope is the lambda, maybe_resolve_dummy succeeds and returns the 'this' for the enclosing class Qux. Later, during deferred instantiation of the local class, we get confused trying to resolve the access of 'a_' through this non-dummy 'this'. So this patch just reinstates the calls to pushclass / popclass that were removed in r11-6815. gcc/cp/ChangeLog: PR c++/100362 * parser.c (cp_parser_class_head): Reinstate calls to pushclass and popclass when parsing the base-clause that were removed in r11-6815. gcc/testsuite/ChangeLog: PR c++/100362 * g++.dg/cpp1y/lambda-generic-100362.C: New test.
[Bug c++/100344] [12 Regression] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344 --- Comment #11 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:eef4fa6968ae0682679c27dae06409db3d113d5d commit r12-391-geef4fa6968ae0682679c27dae06409db3d113d5d Author: Patrick Palka Date: Mon May 3 13:35:26 2021 -0400 c++: mark_used and ADL with template-id [PR100344] My r11-295 patch for PR68942 didn't consider that the callee of an ADL-eligible function call can be a TEMPLATE_ID_EXPR, and we don't want to disable mark_used when substituting into the template arguments of this TEMPLATE_ID_EXPR because the arguments are clearly used regardless of the outcome of ADL. In the first testcase below, this oversight causes us to trip over the assert in build_call_a for the call to find_index because the function no longer had its TREE_USED bit set from mark_used. So this patch restricts the original fix to disable mark_used only when the callee is a FUNCTION_DECL, which seems to be the only case that matters for PR68942. For instance, in the second testcase below we already don't mark_used the deleted function specialization even before r11-295. gcc/cp/ChangeLog: PR c++/68942 PR c++/100344 * pt.c (tsubst_copy_and_build) : Set tf_conv only when the callee is a FUNCTION_DECL. gcc/testsuite/ChangeLog: PR c++/68942 PR c++/100344 * g++.dg/template/call8.C: New test. * g++.dg/template/koenig12a.C: New test.
[Bug c++/68942] overly strict use of deleted function before argument-dependent lookup (ADL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68942 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:eef4fa6968ae0682679c27dae06409db3d113d5d commit r12-391-geef4fa6968ae0682679c27dae06409db3d113d5d Author: Patrick Palka Date: Mon May 3 13:35:26 2021 -0400 c++: mark_used and ADL with template-id [PR100344] My r11-295 patch for PR68942 didn't consider that the callee of an ADL-eligible function call can be a TEMPLATE_ID_EXPR, and we don't want to disable mark_used when substituting into the template arguments of this TEMPLATE_ID_EXPR because the arguments are clearly used regardless of the outcome of ADL. In the first testcase below, this oversight causes us to trip over the assert in build_call_a for the call to find_index because the function no longer had its TREE_USED bit set from mark_used. So this patch restricts the original fix to disable mark_used only when the callee is a FUNCTION_DECL, which seems to be the only case that matters for PR68942. For instance, in the second testcase below we already don't mark_used the deleted function specialization even before r11-295. gcc/cp/ChangeLog: PR c++/68942 PR c++/100344 * pt.c (tsubst_copy_and_build) : Set tf_conv only when the callee is a FUNCTION_DECL. gcc/testsuite/ChangeLog: PR c++/68942 PR c++/100344 * g++.dg/template/call8.C: New test. * g++.dg/template/koenig12a.C: New test.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #13 from Vineet Gupta --- Sorry the workaround proposed by Alexander doesn't seem to cure it (patch attached), outcome is the same mov lp_count,r13;5 #, bnd.65 lp @.L201 ; lp_count:@.L50->@.L201#, .align 2 .L50: # ../lib/zlib_inflate/inffast.c:288: PUP(sout) = PUP(sfrom); ldd.a r18,[r21,8] # MEM[base: _496, offset: 0B], MEM[base: _496, offset: 0B] # ../lib/zlib_inflate/inffast.c:288: PUP(sout) = PUP(sfrom); std.ab r18,[r22,8] # MEM[base: vectp_prephitmp.73_741, offset: 0B], MEM[base: _496, offset: 0B] .align 2 .L201: ; ZOL_END, begins @.L50 #
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #12 from Vineet Gupta --- Created attachment 50742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50742=edit kernel patch as proposed on comment #7
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 Jakub Jelinek changed: What|Removed |Added Attachment #50719|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #19 from Jakub Jelinek --- Created attachment 50741 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50741=edit gcc12-pr94589.patch Full untested patch.
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2021-05-03 Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Richard Biener --- OK, with standard C++ GCC 3.4 doesn't work at -O0 while GCC 4.3+ do but with -O1+ it breaks even with trunk. And the posted patches fix it.
[Bug c/100401] New: Bogus -Wformat-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401
Bug ID: 100401
Summary: Bogus -Wformat-overflow warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat bogus.c
#include
#define RECLEN 128
struct S {
int code;
char text[0];
};
const void fun(int n)
{
union {
struct S s;
char rec[RECLEN];
} x;
const char* err;
if (!n) {
err = "No error";
} else {
sprintf(x.s.text, "Error %d", n);
err = x.s.text;
}
printf("%s\n", err);
}
int main(int argc, const char* argv[])
{
fun(argc);
return 0;
}
$ gcc -Wall -O2 bogus.c
bogus.c: In function ‘fun’:
bogus.c:22:28: warning: ‘Error ’ directive writing 6 bytes into a region of
size 0 [-Wformat-overflow=]
22 | sprintf(x.s.text, "Error %d", n);
|^~
bogus.c:22:9: note: ‘sprintf’ output between 8 and 18 bytes into a destination
of size 0
22 | sprintf(x.s.text, "Error %d", n);
| ^~~~
[Bug tree-optimization/100400] New: ICE in visit_loops_in_gang_single_region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100400
Bug ID: 100400
Summary: ICE in visit_loops_in_gang_single_region
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openacc
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-12.0.0-alpha20210502 snapshot (g:92f59e47f5a468b96b12b15233a6729904b1a1ee)
ICEs when compiling the following testcase, reduced from
libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c, w/ -O1
-fopenacc -g --param openacc-kernels=decompose:
int *p;
void
foo (void)
{
#pragma acc kernels
{
int c;
p =
#pragma acc loop independent
for (c = 0; c < 1; ++c)
;
}
}
% g++-12.0.0 -O1 -fopenacc -g --param openacc-kernels=decompose -c uupipzvt.c
during GIMPLE pass: omp_oacc_kernels_decompose
uupipzvt.c: In function 'void foo()':
uupipzvt.c:14:7: internal compiler error: in visit_loops_in_gang_single_region,
at omp-oacc-kernels-decompose.cc:242
14 | ;
| ^
0x8b682a visit_loops_in_gang_single_region
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:242
0x8b682a visit_loops_in_gang_single_region
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:230
0xe16a2a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:578
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0xe16b39 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:641
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0xe16d03 walk_gimple_seq(gimple*, tree_node* (*)(gimple_stmt_iterator*, bool*,
walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:81
0x1bf9048 make_loops_gang_single
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:290
0x1bf9048 make_region_seq
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:331
0x1bfb60c decompose_kernels_region_body
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1336
0x1bfb60c omp_oacc_kernels_decompose_1
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1453
0x1bfb60c omp_oacc_kernels_decompose_callback_stmt
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1478
0xe16a2a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:578
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0xe16b15 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:685
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0x1bf89d6 omp_oacc_kernels_decompose
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1495
0x1bf89d6 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1534
[Bug c++/100055] [10/11/12 Regression] ICE on invalid requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100055 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Fixed for GCC 12.
[Bug c++/100370] [11/12 Regression] Incorrect warning for placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100370
Martin Sebor changed:
What|Removed |Added
Blocks||100399
Last reconfirmed||2021-05-03
Known to fail||11.1.0
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed. The false positive here is the result of trying to avoid other
false positives for unions and not considering that the pointer might point to
space that's larger than that. Like the false negative in pr100307 comment 2
(AKA pr100325), this would also be prevented by running -Wplacement-new later,
when the program is in SSA form, rather than from the front end.
if (code == COMPONENT_REF)
{
tree ref = TREE_OPERAND (ptr, 0);
if (TREE_CODE (TREE_TYPE (ref)) == UNION_TYPE)
/* In accesses through union types consider the entire unions
rather than just their members. */
ostype = 0;
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399
[Bug 100399] bogus/missing -Wplacement-new
[Bug c++/100055] [10/11/12 Regression] ICE on invalid requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100055 --- Comment #5 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:c9b6890d0b6aa030b307fdb620f8c53ed59ca3b5 commit r12-389-gc9b6890d0b6aa030b307fdb620f8c53ed59ca3b5 Author: Marek Polacek Date: Thu Apr 22 17:32:01 2021 -0400 c++: Fix ICE with invalid requires-expression [PR100055] This fixes a crash on invalid requires-expression: in this test, current_template_parms is null so accessing TEMPLATE_PARMS_CONSTRAINTS is going to fail. So don't crash, but make sure we've complained already. gcc/cp/ChangeLog: PR c++/100055 * decl.c (grokfndecl): Check current_template_parms. gcc/testsuite/ChangeLog: PR c++/100055 * g++.dg/concepts/diagnostic18.C: New test.
[Bug c++/100399] bogus/missing -Wplacement-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW Alias||Wplacement-new Keywords||diagnostic, meta-bug Version|11.1.0 |6.1.0 --- Comment #1 from Martin Sebor --- -Wplacement-new was added in GCC 6.1.
[Bug c++/100399] New: bogus/missing -Wplacement-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399 Bug ID: 100399 Summary: bogus/missing -Wplacement-new Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is a meta-bug to track -Wplacement-new false positives, negatives, and enhancements to the warning.
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Attachment #50728|0 |1 is obsolete|| --- Comment #7 from Thomas Rodgers --- Created attachment 50740 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50740=edit Fix wrong thread getting notification, take 2 This should fix the issue, submitting patch to mailing list.
[Bug tree-optimization/100398] New: [12 Regression] ICE in gimple_redirect_edge_and_branch, at tree-cfg.c:6082
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100398
Bug ID: 100398
Summary: [12 Regression] ICE in
gimple_redirect_edge_and_branch, at tree-cfg.c:6082
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-12.0.0-alpha20210502 snapshot (g:92f59e47f5a468b96b12b15233a6729904b1a1ee)
ICEs when compiling the following testcase, reduced from
test/CodeGen/asm-goto.c from the clang 11.1.0 test suite, w/ -O1:
int
test5_limit (void)
{
int addr;
asm goto ("" : "+r" (addr) : : : t_err);
return 0;
t_err:
return 1;
}
% x86_64-unknown-linux-gnu-gcc-12.0.0 -O1 -c xttz2qcb.c
during GIMPLE pass: veclower2
xttz2qcb.c: In function 'test5_limit':
xttz2qcb.c:2:1: internal compiler error: in gimple_redirect_edge_and_branch, at
tree-cfg.c:6082
2 | test5_limit (void)
| ^~~
0x6cfa49 gimple_redirect_edge_and_branch
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfg.c:6082
0x9701e9 redirect_edge_and_branch(edge_def*, basic_block_def*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/cfghooks.c:373
0xe610a6 remove_forwarder_block
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:585
0xe610a6 cleanup_tree_cfg_bb
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:754
0xe61808 cleanup_tree_cfg_noloop
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:1103
0xe61808 cleanup_tree_cfg(unsigned int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:1187
0xd2bf64 execute_function_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/passes.c:2008
0xd2c89b execute_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/passes.c:2096
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 100395, which changed state. Bug 100395 Summary: Bogus -Wstringop-overflow warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/100395] Bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395 Martin Sebor changed: What|Removed |Added Blocks||88443 Component|c |middle-end Resolution|--- |FIXED Known to fail||10.3.0 Keywords||diagnostic CC||msebor at gcc dot gnu.org Last reconfirmed||2021-5-3 Known to work||11.1.0, 9.3.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Sebor --- Fixed in r11-1183. The fix is not suitable for backporting to GCC 10. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #11 from Linus Torvalds --- (In reply to Linus Torvalds from comment #10) > > This particular code comes > from some old version of zlib, and I can't test because I don't have the ARC > background to make any sense of the generated code. Heh. We upgraded to a "recent version" of zlib back in 2006: "Upgrade the zlib_inflate implementation in the kernel from a patched version 1.1.3/4 to a patched 1.2.3" but it turns out that the "do things a 16-bit word at a time" was a kernel-local optimization for some very slow old PowerPC microcontroller. The code in upstream zlib actually looks rather better (which is not saying much, admittedly), doesn't have any 16-bit accesses, and we probably should just try to synchronize with that instead.
[Bug c++/100396] [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396
--- Comment #2 from vopl at bk dot ru ---
Please, try this, also failed
/0/1/2/3/4/5/6/7
template struct Checker
{
using Some = decltype(F{}(Args{}...));
};
template concept valid =
requires { typename Checker::Some; };
/0/1/2/3/4/5/6/7
template auto ovr(F f, Args... args)
requires valid
{
return ovr(int{}, f, args...); // a second ovr is expected to
be called, but the compiler tries to call this ovr again. Collision between
'int' and 'F' is ignored, extra Args provided to call
}
template auto ovr(int, F f, Args... args)
{
return f(args...);
}
/0/1/2/3/4/5/6/7
void use()
{
ovr([]{});
}
$ g++-11.1.0 -std=c++20 -c src.cpp
src.cpp: In instantiation of 'struct Checker,
use():: >':
src.cpp:8:25: required by substitution of 'template
auto ovr(F, Args ...) requires valid [with F = use()::;
Args = {use()::}]'
src.cpp:14:27: required from 'auto ovr(F, Args ...) requires valid [with F = use()::; Args = {}]'
src.cpp:25:8: required from here
src.cpp:4:30: error: no match for call to '(use()::)
(use()::)'
4 | using Some = decltype(F{}(Args{}...));
| ~~~^~~
src.cpp:4:30: note: candidate: 'void (*)()' (conversion)
src.cpp:4:30: note: candidate expects 1 argument, 2 provided
src.cpp:25:9: note: candidate: 'use()::'
25 | ovr([]{});
| ^
src.cpp:25:9: note: candidate expects 0 arguments, 1 provided
--
IMHO, the problem is not caused by concepts, but caused by corrupted
overloading selection mechanic. Please, take a look at the collision between
argument 'int{}' and first template parameter specified as 'F'. Next, no SFINAE
expected in this case due to correct overloading, but overloading failed and
SFINAE happens. Thanks.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #10 from Linus Torvalds --- (In reply to Richard Biener from comment #9) > > Note alignment has nothing to do with strict-aliasing (-fno-strict-aliasing > you mean btw). I obviously meant -fno-strict-aliasing, yes. But I think it's actually essentially the same issue, just in a different guise: > One thing we do is (I'm not 50% sure this explains the observed issue) assume > that if you have two accesses with type 'short' and they are aligned > according to this type then they will not partly overlap. Note this has > nothing to do with C strict aliasing rules but is basic pointer math when > you know lower zero bits. Well, the thing is, you have two situations: (a) you can statically see that the two do not alias, because the offset arithmetic is either constant or you have some range logic that can tell that they are sufficiently far apart. (b) you can't. Now, everybody is ok with the static aliasing situation in (a). If you can tell that two addresses don't alias, your'e done, they are independent, there's no question about it. But that's not the situation here. So we're in (b). And what I find personally so annoying is that gcc has actually *done* that distance check, but apparently intentionally done it badly based on type information. And the reason I think this is similar to -fno-strict-aliasing is that it's that same (b) case, and it looks like a very similar "do a bad job of doing actual run-time alias analysis based on type information". It seems to be literally an off-by-one error, not because it generates better code, but because the compiler has decided to pointlessly make a bad range comparison based on type. But I've never worked with the gcc IR dumps, so Andrew Pinski's debug output in #c5 doesn't actually make me go "ahh, there". Maybe it's that 8 vs 6 that he pointed out. Did somebody notice that "offset > 8" was off-by-one, and should have been "offset >= 8"? And then changed it to "offset > 6" which is off-by-one in the other direction instead? > I suggest to try the fix suggested in comment#7 and report back if that > fixes the observed issue. Vineet? I still think gcc is doing the wrong thing, exactly because of that "pointlessly using the wrong range check" issue. This particular code comes from some old version of zlib, and I can't test because I don't have the ARC background to make any sense of the generated code.
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362
--- Comment #4 from Patrick Palka ---
If we remove the unneeded 'this' capture, then it's a rejects-valid bug:
template
struct Qux {
struct A { } a_;
void AsyncOp() {
[](auto) {
struct Grault : decltype(a_) {};
Grault ptr;
}(0);
}
};
void corge() {
Qux qux;
qux.AsyncOp();
}
: In instantiation of ‘struct
Qux::AsyncOp()Grault’:
:11:14: required from ‘Qux::AsyncOp():: [with
auto:1 = int]’
:12:6: required from ‘void Qux< >::AsyncOp()
[with = int]’
:18:14: required from here
:10:32: error: invalid use of non-static data member ‘Qux::a_’
:10:32: error: ‘Qux::A Qux::a_’ is inaccessible within this
context
:6:16: note: declared here
[Bug testsuite/100397] New: New test case libgomp.fortran/depobj-1.f90 fails erratically since its introduction in r12-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100397 Bug ID: 100397 Summary: New test case libgomp.fortran/depobj-1.f90 fails erratically since its introduction in r12-20 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:a61c4964cd71446232d62ec9b10a7d45b440dd9f, r12-20 This test case fails erratically (ever few runs) on powerpc64 since its introduction. I have seen it fail on power 7 BE and power 9 LE machines. make -k check-target-libgomp RUNTESTFLAGS="fortran.exp=libgomp.fortran/depobj-1.f90" FAIL: libgomp.fortran/depobj-1.f90 -O execution test # of expected passes1 # of unexpected failures1 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include exceptions_enabled48342.cc -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/../../include -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs/ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs -S -o exceptions_enabled48342.s PASS: libgomp.fortran/depobj-1.f90 -O (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/./gcc:/home/seurer/gcc/git/build/gcc-test/./gcc/32:.:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/./gcc:/home/seurer/gcc/git/build/gcc-test/./gcc/32:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-8.3.0/lib64 Execution timeout is: 300 spawn [open ...] STOP 2 FAIL: libgomp.fortran/depobj-1.f90 -O execution test Author: Tobias Burnus Date: Wed Apr 21 10:58:29 2021 +0200 Fortran/OpenMP: Add 'omp depobj' and 'depend(mutexinoutset:'
[Bug c++/100374] Type-constraints of member function templates should not be substituted into during implicit instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100374 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-03 --- Comment #1 from Patrick Palka --- Confirmed.
[Bug c++/100368] Missing guaranteed elision in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100368 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Last reconfirmed||2021-05-03 --- Comment #1 from Patrick Palka --- Confirmed, looks like this never worked.
[Bug c++/100396] [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Thanks for the bug report. It looks like we started rejecting this after r11-2774. The testcase is invalid, I think. You need to declare 'valid' as a concept instead of a constexpr variable so that substitution failure during constraint checking of the first overload of 'ovr' is a SFINAE error.
[Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031 --- Comment #7 from Alexander Monakov --- In comment #2 I touched upon a potentially more practical way to offer -fno-strict-alignment: Run early work with ABI alignments: compute __alignof correctly, lay out composite types as required by ABI, and assign alignments to variables (including stack variables and function parameters). Then make a pass over types and reduce their alignment. This way, optimizations see a universe where types have alignment 1, and variables are defined as if they had an explicit attribute-align with increased alignment (and likewise for structure fields).
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Hmm, isn't problem here ultimately that std::visit is specified to have a concrete SFINAE-friendly return type, but our implementation uses a deduced return type?
[Bug c++/100396] New: [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396
Bug ID: 100396
Summary: [11.1 regression] The template function overload is
not selected correctly
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vopl at bk dot ru
Target Milestone: ---
Regression in 11.1.0
$ cat src.cpp && echo EOFFF
/0/1/2/3/4/5/6/7
template
constexpr bool valid = (0 < sizeof(F{}(Args{}...)));
/0/1/2/3/4/5/6/7
template
void ovr(F f, Args... args)
requires valid // external checker - fail, wrong Args formed
//requires (0 < sizeof(F{}(Args{}...))) // inline checker - ok (are wrong Args
compensated by SFINAE?)
{
return ovr(int{}, f, args...); // a second ovr is expected to
be called, but the compiler tries to call this ovr again. Collision between
'int' and 'F' is ignored, extra Args appended from 'f'
}
template void ovr(int, F, Args...){}
/0/1/2/3/4/5/6/7
void use()
{
ovr([]{return 'c';});
}
EOFFF
$ g++-11.1.0 -std=c++20 -c src.cpp
src.cpp: In instantiation of 'constexpr const bool valid,
use():: >':
src.cpp:8:10: required by substitution of 'template
void ovr(F, Args ...) requires valid [with F = use()::;
Args = {use()::}]'
src.cpp:11:27: required from 'void ovr(F, Args ...) requires valid [with F = use()::; Args = {}]'
src.cpp:19:8: required from here
src.cpp:3:39: error: no match for call to '(use()::)
(use()::)'
3 | constexpr bool valid = (0 < sizeof(F{}(Args{}...)));
| ^~~~
src.cpp:3:39: note: candidate: 'char (*)()' (conversion)
src.cpp:3:39: note: candidate expects 1 argument, 2 provided
src.cpp:19:9: note: candidate: 'use()::'
19 | ovr([]{return 'c';});
| ^
src.cpp:19:9: note: candidate expects 0 arguments, 1 provided
$ g++-11.1.0 -v
Using built-in specs.
COLLECT_GCC=g++-11.1.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.1.0/work/gcc-11.1.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.1.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.1.0 p1'
--disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
--disable-libada --enable-systemtap --disable-valgrind-annotations
--enable-vtable-verify --with-zstd --enable-lto --with-isl
--disable-isl-version-check --enable-default-pie --disable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Gentoo 11.1.0 p1)
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
--- Comment #3 from Patrick Palka ---
Further reduced:
template
struct Qux {
struct A { } a_;
void AsyncOp() {
[this](auto) {
decltype(a_) x;
struct Grault : decltype(a_) {};
Grault ptr;
}(0);
}
};
void corge() {
Qux qux;
qux.AsyncOp();
}
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394
--- Comment #4 from Michael Matz ---
That then still shows problems with the pure function and -O2, but with
standard
C++ this then works:
struct S {
int foo(int i) const { if (i) throw 42; return 0; }
};
int __attribute__((noinline)) bar2()
{
S s;
int a[2];
try {
int res = s.foo (1);
a[0] = res;
} catch (...) {
return 0;
}
return 1;
}
int main()
{
if (bar2 ())
__builtin_abort ();
return 0;
}
[Bug c++/100367] [11/12 Regression] Internal compiler error when std::lexicographical_compare_three_way third and fourth argument are reverse iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100367
Patrick Palka changed:
What|Removed |Added
Summary|Internal compiler error |[11/12 Regression] Internal
|when|compiler error when
|std::lexicographical_compar |std::lexicographical_compar
|e_three_way third and |e_three_way third and
|fourth argument are reverse |fourth argument are reverse
|iterators |iterators
Ever confirmed|0 |1
Target Milestone|--- |11.2
Component|libstdc++ |c++
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-05-03
--- Comment #1 from Patrick Palka ---
Seems to be a frontend issue, started with r11-5866. Reduced:
#include
struct iter {
bool current;
iter(iter &);
};
constexpr bool operator==(const iter &, const iter &__y) {
return __y.current;
}
void lexicographical_compare_three_way(iter a) {
(a == a) <=> true;
}
[Bug c/100395] New: Bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395
Bug ID: 100395
Summary: Bogus -Wstringop-overflow warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat test.c
#include
#include
int main(int argc, const char* argv[])
{
size_t len0 = strlen(argv[0]), len1 = strlen(argv[1]);
char buf[444];
char* s;
s = buf + sizeof(buf) - len0;
memcpy(s, argv[0], len0);
s -= len1;
memcpy(--s, argv[1], len1);
s[len1++] = ' ';
printf("%.*s\n", (int)(len0 + len1), s);
return 0;
}
$ gcc -O2 -Wall test.c
test.c: In function ‘main’:
test.c:14:15: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
14 | s[len1++] = ' ';
| ~~^
test.c:7:10: note: at offset -1 to object ‘buf’ with size 444 declared here
7 | char buf[444];
| ^~~
The offset shown in the message is wrong, which most likely was the reason to
emit the warning altogether.
The test code above mocks up a situation where the lengths of both strings,
which are being copied in the reverse order into "buf", are known and small,
i.e. both fit (a few times, actually) together into the buffer, including the
separator and terminator.
[Bug middle-end/93644] [10/11/12 Regression] spurious -Wreturn-local-addr with PHI of PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 Jochen Roemmler changed: What|Removed |Added CC||jochen447 at concept dot de --- Comment #16 from Jochen Roemmler --- Created attachment 50739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50739=edit another minimal example to demonstrate the false alarm This is another instance of the test case. A senseless, yet perfectly valid piece of C code. It creates the false positive warning if compiled like this: gcc -Wreturn-local-addr -O1 -fisolate-erroneous-paths-dereference -c pr93644_2.c pr93644_2.c: In function ‘buildVname’: pr93644_2.c:28:12: warning: function may return address of local variable [-Wreturn-local-addr] 28 | return vname; |^ pr93644_2.c:18:17: note: declared here 18 | charbuf[256]; | ^~~ I'm using gcc version 11.1.1 20210428 (Red Hat 11.1.1-1) (GCC) However, I can silence the warning using # pragma GCC diagnostic ignored "-Wreturn-local-addr"
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394
Michael Matz changed:
What|Removed |Added
Known to fail|3.4.6, 4.3.5|
CC||matz at gcc dot gnu.org
--- Comment #3 from Michael Matz ---
That's simply invalid C++. A rethrow (which is what a 'throw' without value
is)
can only be done from within a catch. You need to throw a value:
...
int __attribute__((pure,noinline)) foo () { if (x) throw 42; return y; }
...
[Bug target/100375] [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 --- Comment #7 from Jonathan Wakely --- I need to fix libstdc++ to accept the code with a deprecated warning, rather than reject it. I think it only rejects it with -pedantic but it should still be fixed to work until the deprecated constructor is removed.
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394 --- Comment #2 from Richard Biener --- Classically it needs two DCE passes, the first removes the call LHS, the second then no longer considers the call necessary because of EH. But even with that fixed there are subsequent passes breaking things.
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394 --- Comment #1 from Richard Biener --- See also https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569429.html
[Bug middle-end/100394] New: wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394
Bug ID: 100394
Summary: wrong-code with EH and pure/const functions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
// { dg-do run }
// { dg-options "-O2" }
int x, y;
int __attribute__((pure,noinline)) foo () { if (x) throw; return y; }
int __attribute__((noinline)) bar()
{
int a[2];
x = 1;
try {
int res = foo ();
a[0] = res;
} catch (...) {
return 0;
}
return 1;
}
int main()
{
if (bar ())
__builtin_abort ();
return 0;
}
aborts at all (non-)optimization levels. In an unpatched tree the call to
foo() is elided.
> g++-10 t.C
> ./a.out
terminate called without an active exception
Aborted (core dumped)
[Bug c++/100335] Using statement of a ref-qualified method from base class: method not callable on derived object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335 --- Comment #8 from Jonathan Wakely --- Like I already suggested in comment 3: Either the overloads should conflict because of [over.load]/2.3 (and the definition of Derived should be ill-formed) or they should be hidden and not visible in Derived (so the call to test.method() should be ill-formed).
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- Not a bug. PR 90943 already exists for the P2162R3 support.
[Bug libstdc++/100387] ranges::minmax compares moved-out value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100387 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED CC||ppalka at gcc dot gnu.org Last reconfirmed||2021-05-03 --- Comment #2 from Patrick Palka --- Confirmed.
[Bug c++/100288] [11/12 Regression] g++-11 internal error and fails to precompile a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288
--- Comment #5 from Patrick Palka ---
(In reply to Frank B. Brokken from comment #4)
> Dear ppalka at gcc dot gnu.org, you wrote:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288
> >
> > Patrick Palka changed:
> >
> >What|Removed |Added
> >
> >Keywords||ice-on-invalid-code
> >See Also||https://gcc.gnu.org/bugzill
> >||a/show_bug.cgi?id=99599
> >
> > --- Comment #3 from Patrick Palka ---
> > Agreed, the testcase looks invalid much like PR99599. One workaround for
> > avoiding the constraint recursion here would be to change the signature of
> >
> > template
> > inline void operator<<(CSVTabIns &, Type const )
> >
> > to something like
> >
> > template > U,
> > OstreamInsertable
> > Type>
> > inline void operator<<(U &, Type const )
> >
> > so that the constraint OstreamInsertable is checked on this overload
> > only
> > if the first argument to << has the expected type.
> >
> > --
> > You are receiving this mail because:
> > You reported the bug.
>
> Hi Patrick,
>
> Thanks for your e-mail.
>
> Since (AFAICS) you directly and only sent your e-mail to me I'm wondering
> whether you want me to comment on your e-mail. It's getting kind of late
> here,
> but I could send a more extensive reply tomorrow. Let me know if that's what
> you want.
Oh sorry, that was just an automated email for the comment I posted to the
bugzilla PR, which gets sent to everyone on the CC list of the PR. I wasn't
expecting any sort of reply :)
>
> I tried your suggestion, and it seems to solve the issue. But at the same
> time
> it puzzles me why
>
> template
> inline void operator<<(CSVTabIns &, Type const )
> {}
>
> won't be instantiated for FMT in
>
> inline void operator<<(CSVTabIns , FMT::FMTHline hline)
> {
> tab << (*hline)(1); // insert hline in the next column
> }
>
> when FMT defines FMTHline as 'typedef FMT (*FMTHline)(unsigned)' and
>
> std::ostream <<(std::ostream , FMT const )
>
> is declared. I would have expected that
>
> tab << (*hline)(1); // insert hline in the next column
>
> would cause the compiler to instantiate
>
> template
> inline void operator<<(CSVTabIns &, Type const )
> {}
>
> for Type = FMT.
>
The compiler does try to instantiate that overload for Type = FMT there, but
when checking the constraint OstreamInsertable on this overload it needs
to resolve the << in
requires(std::ostream , Type value)
{
out << value;
};
for Type = FMT, during which it considers that same operator<< overload. And
CWG2369 says we now first check constraints before non-dependent conversions,
but we're in the middle of checking the constraints on this overload, so we
enter a constraint loop.
> Maybe I'm missing something here? And it's also not something that caused the
> compiler's internal error.
Yeah, we shouldn't be seeing an internal error even on an invalid testcase.
This needs to be fixed.
[Bug tree-optimization/100393] [9/10/11/12 Regression] Very slow compilation of switch statement with thousands of cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100393
--- Comment #4 from Richard Biener ---
I guess that's already done, so it has to be fixed in other ways, like by
keeping the partial sum when decreasing the size in
for (unsigned j = 0; j < i; j++)
{
if (min[j].m_count + 1 < min[i].m_count
&& can_be_handled (clusters, j, i - 1))
min[i] = min_cluster_item (min[j].m_count + 1, j, INT_MAX);
}
maybe "simply" binary search j in [0, i-1] rather than doing a linear
search here.
[Bug tree-optimization/100393] [9/10/11/12 Regression] Very slow compilation of switch statement with thousands of cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100393
--- Comment #3 from Richard Biener ---
Samples: 847K of event 'cycles:u', Event count (approx.): 839745061761
Overhead Samples Command Shared Object Symbol
95.05%804298 cc1 cc1 [.]
tree_switch_conversion::jump_table_cluster::can_be_handled
1.69% 14493 cc1 cc1 [.]
tree_switch_conversion::cluster::get_range
0.86% 7291 cc1 cc1 [.]
optimize_function_for_size_p
looks like there's obvious quadraticness here when doing the summing:
bool
jump_table_cluster::can_be_handled (const vec ,
unsigned start, unsigned end)
{
..
for (unsigned i = start; i <= end; i++)
{
simple_cluster *sc = static_cast (clusters[i]);
comparison_count += sc->m_range_p ? 2 : 1;
}
and we're almost trying all possible clusters in
jump_table_cluster::find_jump_tables
Now, there's the possibility of doing a quick guess before doing this
loop, once via using (end - start) and once via using 2 * (end - start).
Only if the first can be handled and the second not we have to compute.
Martin?
[Bug tree-optimization/100393] [9/10/11/12 Regression] Very slow compilation of switch statement with thousands of cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100393 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Last reconfirmed||2021-05-03 Keywords||compile-time-hog Component|c |tree-optimization Summary|Very slow compilation of|[9/10/11/12 Regression] |switch statement with |Very slow compilation of |thousands of cases |switch statement with ||thousands of cases Known to work||8.4.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||11.1.0, 9.3.1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |9.4 --- Comment #2 from Richard Biener --- Confirmed at -O0 and -O1+.
[Bug libgomp/100352] [11/12 Regression] libgomp.fortran/async_io_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352 --- Comment #9 from Tobias Burnus --- (In reply to CVS Commits from comment #8) > Follow up to PR100352, That's this PR and not the one which caused it. Correct is (comment #6): > Issue introduced for PR99529 in > r11-7647-ga6e9633ccb593937fceec67fafc2afe5d518d735 * * * Close as FIXED (in GCC 12 and 11). Thanks for the report! See PR100371 for follow ups.
