[Bug tree-optimization/99971] GCC generates partially vectorized and scalar code at once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-04-09
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Richard Biener ---
Confirmed. While we manage to analyze for the "perfect" solution" we fail
because dependence testing doesn't handle a piece, this throws away half
of the vectorization. We do actually see that we'll retain the scalar
loads and computations but still doing three vector loads and a vector add
seems cheaper than doing four scalar stores:
0x1fdb5a0 x_2(D)->a 1 times unaligned_load (misalign -1) costs 12 in body
0x1fdb5a0 y1_3(D)->a 1 times unaligned_load (misalign -1) costs 12 in body
0x1fdb5a0 _13 + _14 1 times vector_stmt costs 4 in body
0x1fdb5a0 _15 1 times unaligned_store (misalign -1) costs 12 in body
0x1fddcb0 _15 1 times scalar_store costs 12 in body
0x1fddcb0 _18 1 times scalar_store costs 12 in body
0x1fddcb0 _21 1 times scalar_store costs 12 in body
0x1fddcb0 _24 1 times scalar_store costs 12 in body
t.C:28:1: note: Cost model analysis:
Vector inside of basic block cost: 40
Vector prologue cost: 0
Vector epilogue cost: 0
Scalar cost of basic block: 48
t.C:28:1: note: Basic block will be vectorized using SLP
now, fortunately GCC 11 will improve on this [a bit] and we'll produce
_Z4testR1ARKS_S2_:
.LFB2:
.cfi_startproc
movdqu (%rsi), %xmm0
movdqu (%rdi), %xmm1
paddd %xmm1, %xmm0
movups %xmm0, (%rdi)
movd%xmm0, %eax
subl(%rdx), %eax
movl%eax, (%rdi)
pextrd $1, %xmm0, %eax
subl4(%rdx), %eax
movl%eax, 4(%rdi)
pextrd $2, %xmm0, %eax
subl8(%rdx), %eax
movl%eax, 8(%rdi)
pextrd $3, %xmm0, %eax
subl12(%rdx), %eax
movl%eax, 12(%rdi)
ret
which is not re-doing the scalar loads/adds but instead uses the vector
result. Still the same dependence issue is present:
t.C:16:11: missed: can't determine dependence between y1_3(D)->b and
x_2(D)->a
t.C:16:11: note: removing SLP instance operations starting from: x_2(D)->a =
_6;
the scalar code before vectorization looks like
[local count: 1073741824]:
_13 = x_2(D)->a;
_14 = y1_3(D)->a;
_15 = _13 + _14;
x_2(D)->a = _15;
_16 = x_2(D)->b;
_17 = y1_3(D)->b; <---
_18 = _16 + _17;
x_2(D)->b = _18;
_19 = x_2(D)->c;
_20 = y1_3(D)->c;
_21 = _19 + _20;
x_2(D)->c = _21;
_22 = x_2(D)->d;
_23 = y1_3(D)->d;
_24 = _22 + _23;
x_2(D)->d = _24;
_5 = y2_4(D)->a;
_6 = _15 - _5;
x_2(D)->a = _6; <---
_7 = y2_4(D)->b;
_8 = _18 - _7;
x_2(D)->b = _8;
_9 = y2_4(D)->c;
_10 = _21 - _9;
x_2(D)->c = _10;
_11 = y2_4(D)->d;
_12 = _24 - _11;
x_2(D)->d = _12;
return;
Using
void test(A& __restrict x, A const& y1, A const& y2)
{
x += y1;
x -= y2;
}
produces optimal assembly even with GCC 10:
_Z4testR1ARKS_S2_:
.LFB2:
.cfi_startproc
movdqu (%rsi), %xmm0
movdqu (%rdx), %xmm1
movdqu (%rdi), %xmm2
psubd %xmm1, %xmm0
paddd %xmm2, %xmm0
movups %xmm0, (%rdi)
ret
note that I think we should be able to handle the dependences even without
the __restrict annotation.
[Bug bootstrap/99983] [10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4 CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Btw, 10.3.0 bootstrapped fine for me (but using --with-cpu=power8 --with-tune=power9 just in case that makes a diference). How did you configure?
[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 --- Comment #12 from luoxhu at gcc dot gnu.org --- That code was called by combine pass but fail to match. pr newpat (set (reg:DI 125 [ l ]) (xor:DI (and:DI (xor:DI (reg/v:DI 120 [ l ]) (reg:DI 127)) (const_int 267390975 [0xff00fff])) (reg/v:DI 120 [ l ]))) Trying 8, 10 -> 11: 8: r123:DI=r120:DI^r127:DI REG_DEAD r127:DI 10: r118:DI=r123:DI&0xff00fff REG_DEAD r123:DI 11: r125:DI=r118:DI^r120:DI REG_DEAD r120:DI REG_DEAD r118:DI Failed to match this instruction: (set (reg:DI 125 [ l ]) (ior:DI (and:DI (reg/v:DI 120 [ l ]) (const_int -267390976 [0xf00ff000])) (and:DI (reg:DI 127) (const_int 267390975 [0xff00fff] Successfully matched this instruction: (set (reg:DI 118 [ _2 ]) (and:DI (reg:DI 127) (const_int 267390975 [0xff00fff]))) Failed to match this instruction: (set (reg:DI 125 [ l ]) (ior:DI (and:DI (reg/v:DI 120 [ l ]) (const_int -267390976 [0xf00ff000])) (reg:DI 118 [ _2 ])))
[Bug ipa/96825] [11 Regression] Commit r11-2645 degrades CPU2017 548.exchange2_r by 35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Richard Biener --- I believe there have been improvements recently - can you re-assess the magnitude of the problem? The corresponding ARM PR got re-targeted to GCC 12 (for a RA fix), I think Martin has improved the IPA CP parts, maybe not fully though. Martin?
[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Last reconfirmed|2020-11-11 00:00:00 |2021-04-09 Status|UNCONFIRMED |ASSIGNED --- Comment #27 from Richard Biener --- Honza, please have a look at this PR.
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #15 from Richard Biener --- What's the status on this PR?
[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug lto/98504] [11 Regression] bootstrap broken in libgo on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-04-09 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #5 from Richard Biener --- Matthias, what's the state on current trunk?
[Bug pch/98527] [11 Regression] ICE in handle_pragma_pop_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98527 --- Comment #3 from Richard Biener --- Does the problem persist?
[Bug bootstrap/99983] [10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 Maxim Kuvyrkov changed: What|Removed |Added Build|powerpc64*-linux-gnu|powerpc64*-linux-gnu ||x86_64-linux-gnu ||aarch64-linux-gnu ||arm-linux-gnueabihf Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu ||x86_64-linux-gnu ||aarch64-linux-gnu ||arm-linux-gnueabihf CC||fdumont at gcc dot gnu.org, ||mkuvyrkov at gcc dot gnu.org Host|powerpc64*-linux-gnu|powerpc64*-linux-gnu ||x86_64-linux-gnu ||aarch64-linux-gnu ||arm-linux-gnueabihf --- Comment #3 from Maxim Kuvyrkov --- (In reply to seurer from comment #1) > The failures shown were on a power 8 LE system for > g:348fb9db7858b0fe852da3cd1195b90b2211b983, r10-9675. I have something > running to look for what revision started it. It appears to be === commit 1c4e8a96cd695c03ff85299bf2392476feae99bb Author: François Dumont Date: Mon Jan 20 19:15:43 2020 +0100 libstdc++: Fix unordered containers move constructors noexcept qualification _Hashtable move constructor is wrongly qualified as noexcept(true) regardless of _Equal and _H1 copy constructor qualifications. _Hashtable allocator-aware move constructor is missing its noexcept qualification like the depending unordered containers ones. This backport also includes the changes from r11-8062. === And also confirmed on x86_64, aarch64, and aarch32.
[Bug c++/98529] [11 Regression] g++.dg/modules/stdio-1_a.H FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-04-09 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Is the problem still present?
[Bug rtl-optimization/98601] [8/9/10/11 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|11.0|8.5 Priority|P3 |P2
[Bug target/98784] [8/9/10/11 Regression] problematic build of uClibc with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target|sparc |sparc-linux
[Bug rtl-optimization/98973] [11 regression] Wrong code with gcse store motion pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org, ||law at gcc dot gnu.org, ||stevenb.gcc at gmail dot com Status|UNCONFIRMED |NEW Priority|P3 |P2 Ever confirmed|0 |1 Last reconfirmed||2021-04-09 --- Comment #10 from Richard Biener --- Confirmed. P2 because it's surely latent and nobody seems interested in maintaining store-motion (which I think could morph into a more general sinking facility on RTL). I'm not even sure who knows the original gcse code well (it was split up by Steven).
[Bug libgomp/99984] bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99984 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8cc863ca8f48662e9c9339710fa303587479bf71 commit r11-8075-g8cc863ca8f48662e9c9339710fa303587479bf71 Author: Jakub Jelinek Date: Fri Apr 9 10:18:47 2021 +0200 libgomp: Silence false positive -Wmaybe-uninitialized warning [PR99984] pthread_setspecific second argument is const void *, so that one can call it even with pointers to const, but the function only stores the pointer and does nothing else, so the new assumption of -Wmaybe-uninitialized that functions taking such pointers will read from what those pointers will point to is wrong. Maybe it would be useful to have some whitelist of functions that surely don't do that. Anyway, in this case it is easy to workaround the warning by moving the pthread_setspecific call after the initialization without slowing anything down. 2021-04-09 Jakub Jelinek PR libgomp/99984 * team.c (gomp_thread_start): Call pthread_setspecific for !(defined HAVE_TLS || defined USE_EMUTLS) only after local_thr has been initialized to avoid false positive warning.
[Bug libgomp/99984] bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99984 cqwrteur changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from cqwrteur --- Thank you jakub
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
Richard Biener changed:
What|Removed |Added
Target||cris-elf
--- Comment #8 from Richard Biener ---
Just to repeat - we have folding that turns BIT_FIELD_REF into
VIEW_CONVERT_EXPR (bits) if the size of bits is the size of the
extracted
bits which, for cris likely means that sizeof (ubits) is 1. To quote
struct ubits
{
unsigned int b0 : 1;
unsigned int b123 : 3;
unsigned int b456 : 3;
unsigned int b7 : 1;
};
to make the IL the same for both targets it might be enough to insert padding:
struct ubits
{
unsigned int b0 : 1;
unsigned int b123 : 3;
unsigned int b456 : 3;
unsigned int b7 : 1;
unsigned int pad : 24; // or 8
};
xfail/pass depending on sizeof (int) might be possible but as said it might
be that cris doesn't have sizeof (int) == 1 but instead just lays out
struct ubits in a way to have its size being 1.
[Bug c/98852] [10/11 Regression] Conditional expression wrongly rejected for arm_neon.h vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98852 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||10.3.0 Target Milestone|11.0|10.4 Summary|[11 Regression] Conditional |[10/11 Regression] |expression wrongly rejected |Conditional expression |for arm_neon.h vectors |wrongly rejected for ||arm_neon.h vectors Priority|P3 |P2 Last reconfirmed||2021-04-09 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- On the GCC 10 branch I see t.c: In function 'foo': t.c:6:20: error: type mismatch in conditional expression 6 | return c ? x + 1 : y; |^ so the problem is there as well (maybe it was accepted in some earlier GCC 10 release). P2. Please fill out a known-to-work version.
[Bug ada/99360] [11 regression] ICE in generalized iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug rtl-optimization/99469] [8/9/10/11 Regression] ICE: qsort checking failed with selective scheduling on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99469 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/99547] [11 regression] g++.dg/modules/xtreme-header-5_c.C -std=c++2a ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99547 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-04-09 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #2 from Richard Biener --- Is it still occuring?
[Bug bootstrap/99983] [10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 Richard Biener changed: What|Removed |Added Known to work||10.3.0 Last reconfirmed||2021-04-09 Priority|P3 |P1 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Thus confirmed.
[Bug bootstrap/99983] [10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 --- Comment #5 from Richard Biener --- I suggest to revert.
[Bug lto/98504] [11 Regression] bootstrap broken in libgo on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #6 from John Paul Adrian Glaubitz --- (In reply to Richard Biener from comment #5) > Matthias, what's the state on current trunk? I can test this for Matthias on my own machine as the new ia64 porterbox that we set up in Debian is currently having connection issues with the LDAP database. I will try to get the machine fixed over the weekend.
[Bug c++/99985] New: [11 Regression] bits/hashtable.h:483:9: error: body of ‘constexpr’ function ... not a return-statement since g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985
Bug ID: 99985
Summary: [11 Regression] bits/hashtable.h:483:9: error: body of
‘constexpr’ function ... not a return-statement since
g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
I noticed that in botan, inkscape and mariadb packages:
$ cat oid.C
#include
#include
struct OID {};
std::unordered_map< std::string, OID > load_str2oid_map() {
return std::unordered_map< std::string, OID >{};
}
$ cat oid.C
#include
#include
struct OID {};
std::unordered_map< std::string, OID > load_str2oid_map() {
return std::unordered_map< std::string, OID >{};
}
$ g++ oid.C -c -std=c++11
In file included from /home/marxin/bin/gcc/include/c++/11.0.1/unordered_map:46,
from oid.C:2:
/home/marxin/bin/gcc/include/c++/11.0.1/bits/hashtable.h: In instantiation of
‘static constexpr bool std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey,
_Equal, _Hash, _RangeHash, _Unused, _RehashPolicy, _Traits>::_S_nothrow_move()
[with bool _No_realloc = true; _Key = std::__cxx11::basic_string; _Value
= std::pair, OID>; _Alloc =
std::allocator, OID> >;
_ExtractKey = std::__detail::_Select1st; _Equal =
std::equal_to >; _Hash =
std::hash >; _RangeHash =
std::__detail::_Mod_range_hashing; _Unused =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits]’:
oid.C:5:49: recursively required from ‘std::unordered_map<_Key, _Tp, _Hash,
_Pred, _Alloc>::unordered_map(std::unordered_map<_Key, _Tp, _Hash, _Pred,
_Alloc>&&) [with _Key = std::__cxx11::basic_string; _Tp = OID; _Hash =
std::hash >; _Pred =
std::equal_to >; _Alloc =
std::allocator, OID> >]’
oid.C:5:49: required from here
/home/marxin/bin/gcc/include/c++/11.0.1/bits/hashtable.h:483:9: error: body of
‘constexpr’ function ‘static constexpr bool std::_Hashtable<_Key, _Value,
_Alloc, _ExtractKey, _Equal, _Hash, _RangeHash, _Unused, _RehashPolicy,
_Traits>::_S_nothrow_move() [with bool _No_realloc = true; _Key =
std::__cxx11::basic_string; _Value = std::pair, OID>; _Alloc = std::allocator, OID> >; _ExtractKey =
std::__detail::_Select1st; _Equal =
std::equal_to >; _Hash =
std::hash >; _RangeHash =
std::__detail::_Mod_range_hashing; _Unused =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits]’ not a return-statement
483 | }
| ^
/home/marxin/bin/gcc/include/c++/11.0.1/bits/hashtable.h: In instantiation of
‘std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _Hash, _RangeHash,
_Unused, _RehashPolicy, _Traits>::_Hashtable(std::_Hashtable<_Key, _Value,
_Alloc, _ExtractKey, _Equal, _Hash, _RangeHash, _Unused, _RehashPolicy,
_Traits>&&) [with _Key = std::__cxx11::basic_string; _Value =
std::pair, OID>; _Alloc =
std::allocator, OID> >;
_ExtractKey = std::__detail::_Select1st; _Equal =
std::equal_to >; _Hash =
std::hash >; _RangeHash =
std::__detail::_Mod_range_hashing; _Unused =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits]’:
oid.C:5:49: recursively required from ‘std::unordered_map<_Key, _Tp, _Hash,
_Pred, _Alloc>::unordered_map(std::unordered_map<_Key, _Tp, _Hash, _Pred,
_Alloc>&&) [with _Key = std::__cxx11::basic_string; _Tp = OID; _Hash =
std::hash >; _Pred =
std::equal_to >; _Alloc =
std::allocator, OID> >]’
oid.C:5:49: required from here
/home/marxin/bin/gcc/include/c++/11.0.1/bits/hashtable.h:520:33: error: ‘static
constexpr bool std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal,
_Hash, _RangeHash, _Unused, _RehashPolicy, _Traits>::_S_nothrow_move() [with
bool _No_realloc = true; _Key = std::__cxx11::basic_string; _Value =
std::pair, OID>; _Alloc =
std::allocator, OID> >;
_ExtractKey = std::__detail::_Select1st; _Equal =
std::equal_to >; _Hash =
std::hash >; _RangeHash =
std::__detail::_Mod_range_hashing; _Unused =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits]’ called in a constant
expression
520 | noexcept(_S_nothrow_move())
| ~~~^~
/home/marxin/bin/gcc/include/c++/11.0.1/bits/hashtable.h:477:9: note: ‘static
constexpr bool std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal,
_Hash, _RangeHash, _Unused, _RehashPolicy, _Traits>::_S_nothrow_move() [with
bool _No_realloc = true; _Key = std::__cxx11::basic_string; _Value =
std::pair, OID>; _Alloc =
std::allocator, OID> >;
_ExtractKey = std::__detail::_Select1st; _Equal =
std::equal_to >; _Hash =
[Bug c++/99985] [11 Regression] bits/hashtable.h:483:9: error: body of ‘constexpr’ function ... not a return-statement since g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985 Martin Liška changed: What|Removed |Added CC||redi at gcc dot gnu.org Priority|P3 |P1 Known to fail||11.0 Known to work||10.2.0 Target Milestone|--- |11.0
[Bug fortran/99817] [10/11 Regression] ICE in create_function_arglist, at fortran/trans-decl.c:2838 (etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99817 --- Comment #5 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:d31f485dedc86773152d0384bc6ba5583b259a42 commit r11-8076-gd31f485dedc86773152d0384bc6ba5583b259a42 Author: Tobias Burnus Date: Fri Apr 9 10:18:24 2021 +0200 Fortran: Fix fndecl with -fcoarray=lib [PR99817] gcc/fortran/ChangeLog: PR fortran/99817 * trans-types.c (gfc_get_function_type): Also generate hidden coarray argument for character arguments. gcc/testsuite/ChangeLog: PR fortran/99817 * gfortran.dg/coarray/dummy_2.f90: New test.
[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99433
--- Comment #7 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you for the quick analysis!
> views::drop(E, F) is specified to be expression-equivalent to the braced
> init ranges::drop_view{E, F}
Is not completely true, right? As the narrowing warning shows:
```
libstdc++-v3/include/std/ranges:2101:24: warning: narrowing conversion of
‘std::declval()’ from ‘long unsigned int’ to
‘std::ranges::range_difference_t
> >’ {aka ‘long int’} [-Wnarrowing]
```
There is some `std::views::all` involved.
But the following expressions
```
#include
#include
int main()
{
std::list list;
// std::views::drop(list, 0ull); // does not compile
std::ranges::drop_view{list, 0ull}; // does compile without warnings
std::ranges::drop_view{std::views::all(list), 0ull}; // does compile without
warnings
}
```
do compile without any warnings when using `g++-11 -std=c++2a -pedantic -Wall
-Wextra`!
Even when adding `-Wsystem-headers` there is no "narrowing" warning found in
those expressions.
Thank you for your incredible help!
[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99977 Alex Coplan changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org Last reconfirmed||2021-04-09 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #3 from Alex Coplan --- Taking a look at this.
[Bug rtl-optimization/98601] [8/9/10/11 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #5 from Jakub Jelinek ---
See https://gcc.gnu.org/legacy-ml/gcc-patches/2018-03/msg01277.html for more
details.
void
foo (void *p)
{
asm ("" : "=m" (*p));
}
ICEs even on x86_64-linux.
[Bug pch/98527] [11 Regression] ICE in handle_pragma_pop_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98527 Matthias Klose changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Matthias Klose --- can't reproduce this anymore with trunk 20210404.
[Bug ipa/96825] [11 Regression] Commit r11-2645 degrades CPU2017 548.exchange2_r by 35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825 --- Comment #5 from Martin Jambor --- I have not benchmark results from Power, but the reported regression has been fixed/mitigated on Zens, see: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=275.407.0&plot.1=397.407.0&plot.2=294.407.0&; or https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=260.407.0&plot.1=361.407.0&plot.2=33.407.0&; We can still do better even at -Ofast and have an -O2 regression with that benchmark, I hope that both are covered by PR 98782 (which is IMHO quite generic, not ARM specific). So I think this is fixed and we should deal with the existing problems in the other bug (but it would be nice if someone confirmed that Power also no longer regresses this bad).
[Bug rtl-optimization/98601] [8/9/10/11 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601 --- Comment #6 from Jakub Jelinek --- Created attachment 50534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50534&action=edit gcc11-pr98601.patch Untested fix.
[Bug ipa/99986] New: missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99986
Bug ID: 99986
Summary: missed optimization for dead code elimination at -O3
(vs. -O1)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[599] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210409 (experimental) [master revision
96292c3e343:4e14cad25b9:019a922063f26784d5a070d9198a1f937b8a8343] (GCC)
[600] %
[600] % gcctk -O1 -S -o O1.s small.c
[601] % gcctk -O3 -S -o O3.s small.c
[602] %
[602] % wc O1.s O3.s
38 86 669 O1.s
48 107 845 O3.s
86 193 1514 total
[603] %
[603] % grep foo O1.s
[604] % grep foo O3.s
callfoo
[605] %
[605] % cat small.c
extern void foo(void);
static int a, *b[8] = {&a}, **c[8];
static void d() {
int e = 0;
for (; e < 8; e++)
c[e] = &b[1];
if (!c[0])
foo();
}
int main() {
if (a)
d();
return 0;
}
[Bug ipa/99987] New: missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99987
Bug ID: 99987
Summary: missed optimization for dead code elimination at -O3
(vs. -O2)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[748] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210409 (experimental) [master revision
96292c3e343:4e14cad25b9:019a922063f26784d5a070d9198a1f937b8a8343] (GCC)
[749] %
[749] %
[749] % gcctk -O2 -S -o O2.s small.c
[750] % gcctk -O3 -S -o O3.s small.c
[751] %
[751] % wc O2.s O3.s
68 150 961 O2.s
89 195 1278 O3.s
157 345 2239 total
[752] %
[752] % grep foo O2.s
[753] % grep foo O3.s
callfoo
[754] %
[754] % cat small.c
extern void foo(void);
static int a[8] = {0,0,0,0,0,0,0,0};
int b, c, j;
static int *e(int k) {
if (k && b)
j = 0;
while (j)
if (!k)
foo();
return 0;
}
static void d() {
long g;
unsigned h = 8;
if (b)
for (g = 2; 1; g--) {
int i = 0;
h--;
c = (a[g] == (&i != e(h)));
}
}
void f() { d(); }
[Bug bootstrap/99983] [9/10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 Rainer Orth changed: What|Removed |Added Target Milestone|10.4|9.4 Summary|[10 regression] ICE in |[9/10 regression] ICE in |bootstrap while building|bootstrap while building |libstdc++ |libstdc++ CC||ro at gcc dot gnu.org Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu |x86_64-linux-gnu|x86_64-linux-gnu |aarch64-linux-gnu |aarch64-linux-gnu |arm-linux-gnueabihf |arm-linux-gnueabihf, ||*-*-solaris2.* Host|powerpc64*-linux-gnu|powerpc64*-linux-gnu |x86_64-linux-gnu|x86_64-linux-gnu |aarch64-linux-gnu |aarch64-linux-gnu |arm-linux-gnueabihf |arm-linux-gnueabihf, ||*-*-solaris2.* Build|powerpc64*-linux-gnu|powerpc64*-linux-gnu |x86_64-linux-gnu|x86_64-linux-gnu |aarch64-linux-gnu |aarch64-linux-gnu |arm-linux-gnueabihf |arm-linux-gnueabihf, ||*-*-solaris2.* --- Comment #6 from Rainer Orth --- I'm seeing exactly the same ICE on the gcc-9 branch for sparc-sun-solaris2.10 and i386-pc-solaris2.10. The same patch has been backported there, too.
[Bug bootstrap/99983] [9/10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 Richard Biener changed: What|Removed |Added Known to work||9.3.0 --- Comment #7 from Richard Biener --- Yes, the offending rev. was backported to 9 (but not 8, I checked).
[Bug c++/99985] [11 Regression] bits/hashtable.h:483:9: error: body of ‘constexpr’ function ... not a return-statement since g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- So do we need #if __cplusplus < 201402L return _No_realloc && is_nothrow_copy_constructible<_Hash>() && is_nothrow_copy_constructible<_Equal>(); #else if _GLIBCXX17_CONSTEXPR (_No_realloc) if _GLIBCXX17_CONSTEXPR (is_nothrow_copy_constructible<_Hash>()) return is_nothrow_copy_constructible<_Equal>(); #endif ?
[Bug target/99988] New: aarch64: GCC generates excessive consecutive bti j instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99988 Bug ID: 99988 Summary: aarch64: GCC generates excessive consecutive bti j instructions Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: acoplan at gcc dot gnu.org Target Milestone: --- Created attachment 50535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50535&action=edit minimal reproducer For the attached testcase (reduced from the linux kernel), GCC generates multiple redundant sequences of back-to-back bti j instructions, the longest of which is 262 instructions long. To reproduce: $ aarch64-linux-gnu-gcc -c test.c -S -o - -O2 -mbranch-protection=standard | uniq -c | grep "bti j" | sort -nr 262 hint36 // bti j 7 hint36 // bti j 6 hint36 // bti j 4 hint36 // bti j 4 hint36 // bti j 3 hint36 // bti j 2 hint36 // bti j 2 hint36 // bti j 2 hint36 // bti j 2 hint36 // bti j 2 hint36 // bti j 2 hint36 // bti j 2 hint36 // bti j
[Bug middle-end/99989] New: [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 Bug ID: 99989 Summary: [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: hubicka at gcc dot gnu.org Blocks: 24639, 98265 Target Milestone: --- Target: riscv64-*-* In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool ’, inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at ../../gcc/gimple-ssa-warn-alloca.c:295:25: ../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret + offsetof(alloca_type_and_limit, alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::val[0]))’ may be used uninitialized -Werror=maybe-uninitialized] 206 | ret = alloca_type_and_limit (ALLOCA_OK); | ^~~ ../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int pass_walloca::execute(function*)’: ../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here 200 | struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK); |^~~ In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool ’, inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at ../../gcc/gimple-ssa-warn-alloca.c:295:25: ../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret + offsetof(alloca_type_and_limit, alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::val[1]))’ may be used uninitialized -Werror=maybe-uninitialized] 206 | ret = alloca_type_and_limit (ALLOCA_OK); | ^~~ ../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int pass_walloca::execute(function*)’: ../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here 200 | struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK); |^~~ In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool ’, inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at ../../gcc/gimple-ssa-warn-alloca.c:295:25: ../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret + offsetof(alloca_type_and_limit, alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::val[2]))’ may be used uninitialized -Werror=maybe-uninitialized] 206 | ret = alloca_type_and_limit (ALLOCA_OK); | ^~~ ../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int pass_walloca::execute(function*)’: ../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here 200 | struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK); |^~~ In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool ’, inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at ../../gcc/gimple-ssa-warn-alloca.c:295:25: ../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(unsigned int*)((char*)&ret + offsetof(alloca_type_and_limit, alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::len))’ may be used uninitialized [-Werror=maybe-uninitialized] 206 | ret = alloca_type_and_limit (ALLOCA_OK); | ^~~ ../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int pass_walloca::execute(function*)’: ../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here 200 | struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK); |^~~ In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool ’, inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at ../../gcc/gimple-ssa-warn-alloca.c:295:25: ../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(unsigned int*)((char*)&ret + offsetof(alloca_type_and_limit, alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::precision))’ may be used uninitialized [-Werror=maybe-uninitialized] 206 | ret = alloca_type_and_limit (ALLOCA_OK); | ^~~ ../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int pass_walloca::execute(function*)’: ../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here 200 | struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK); |^~~ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:1142
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/99985] [10/11 Regression] bits/hashtable.h:483:9: error: body of ‘constexpr’ function ... not a return-statement since g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985 Jonathan Wakely changed: What|Removed |Added Summary|[11 Regression] |[10/11 Regression] |bits/hashtable.h:483:9: |bits/hashtable.h:483:9: |error: body of ‘constexpr’ |error: body of ‘constexpr’ |function ... not a |function ... not a |return-statement since |return-statement since |g:1cbba49e3417d9b0661e70301 |g:1cbba49e3417d9b0661e70301 |d6fb7a7f52fd360 |d6fb7a7f52fd360 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2021-04-09 Status|UNCONFIRMED |ASSIGNED Target Milestone|11.0|10.4
[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97452 --- Comment #9 from Lewis Baker --- > In terms of the standard do you think this is technically undefined behaviour? Yes, I think this is something that Gor was looking into as a wording issue that could do with some clarification. I think the suggestion was something along the lines of adding some wording to ensure that the evaluation of a an await-expression was sequenced atomically with respect to the evaluation of other expressions in the statement.
[Bug target/99988] aarch64: GCC generates excessive consecutive bti j instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99988 Alex Coplan changed: What|Removed |Added Known to fail||10.3.1, 9.3.1 --- Comment #1 from Alex Coplan --- GCC 10 and 9 are also affected.
[Bug c++/99985] [10/11 Regression] bits/hashtable.h:483:9: error: body of ‘constexpr’ function ... not a return-statement since g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985 --- Comment #2 from Jonathan Wakely --- Aside: is there a good reason those packages use -std=c++11? Did they just add it ten years ago to enable "new" C++ features? Because now they're *disabling* features by not using the compiler's default -std mode. I see -std=c++0x or -std=c++11 in the build for lots of fedora packages.
[Bug c++/99985] [10/11 Regression] bits/hashtable.h:483:9: error: body of ‘constexpr’ function ... not a return-statement since g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985 --- Comment #3 from Jakub Jelinek --- Bet they want C++11 or newer and aren't aware there could be compilers that would default to C++14, C++17 or C++20...
[Bug c++/99985] [10/11 Regression] bits/hashtable.h:483:9: error: body of ‘constexpr’ function ... not a return-statement since g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985 --- Comment #4 from Jonathan Wakely --- We can still make it short circuit (and so not instantiate class templates unnecessarily) like this: #if __cplusplus <= 201402L return __and_<__bool_constant<_No_realloc>, is_nothrow_copy_constructible<_Hash>, is_nothrow_copy_constructible<_Equal>>::value; #else if constexpr (_No_realloc) if constexpr (is_nothrow_copy_constructible<_Hash>()) return is_nothrow_copy_constructible<_Equal>(); return false; #endif I didn't use __and_<> because that has to be instantiated too (although it's cheaper than the is_xxx_constructible ones), and for C++17 the if-constexpr version avoids that. But if we need a #if to work for C++11 anyway, we might as well use __and_ for C++11 and C++14, and if-constexpr for everything later.
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This isn't the first PR where wide_ints are a problem for -W*uninitialized warnings. The primary problem is that generic_wide_int default ctor does nothing and so does wide_int_storage default ctor, so keeps everything uninitialized. Do we want some non-default ctor say with some magic enum or whatever argument that would zero initialize the whole storage?
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 --- Comment #2 from Richard Biener --- (In reply to Jakub Jelinek from comment #1) > This isn't the first PR where wide_ints are a problem for -W*uninitialized > warnings. The primary problem is that generic_wide_int default ctor does > nothing and so does wide_int_storage default ctor, so keeps everything > uninitialized. > Do we want some non-default ctor say with some magic enum or whatever > argument that would zero initialize the whole storage? I don't think we want any initialization unless we invent an explicitely "uninitialized" state. Note that wide-int storage is large - I suppose initializing precision to zero could be done, but I'd avoid initializing the storage.
[Bug ipa/98265] [10 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265 Richard Biener changed: What|Removed |Added Summary|[10/11 Regression] gcc-10 |[10 Regression] gcc-10 has |has significantly worse |significantly worse code |code generated with -O2 |generated with -O2 compared |compared to -O1 (or gcc-9 |to -O1 (or gcc-9 -O2) when |-O2) when using the Eigen |using the Eigen C++ library |C++ library | Status|RESOLVED|ASSIGNED Known to work||11.0 Resolution|FIXED |---
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 --- Comment #3 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > I don't think we want any initialization unless we invent an explicitely > "uninitialized" state. Note that wide-int storage is large - I suppose > initializing precision to zero could be done, but I'd avoid initializing > the storage. FWIW, I agree we shouldn't initialise unless we have a sensible value to initialise to. The problem is that a zero precision has no meaning, but if we initialise to it anyway, it's an extra state that all wide_int accessors have to assert on.
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
--- Comment #4 from Jakub Jelinek ---
So perhaps just:
--- gcc/gimple-ssa-warn-alloca.c.jj 2021-01-04 10:25:38.892233156 +0100
+++ gcc/gimple-ssa-warn-alloca.c2021-04-09 12:46:27.466847728 +0200
@@ -124,9 +124,8 @@ public:
alloca_type_and_limit (enum alloca_type type,
wide_int i) : type(type), limit(i) { }
alloca_type_and_limit (enum alloca_type type) : type(type)
- { if (type == ALLOCA_BOUND_MAYBE_LARGE
- || type == ALLOCA_BOUND_DEFINITELY_LARGE)
- limit = wi::to_wide (integer_zero_node);
+ {
+limit = wi::to_wide (integer_zero_node);
}
};
in this case? Explicitly trying to have limit member conditionally
uninitialized seems like a bad idea to me.
[Bug tree-optimization/99987] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99987 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Version|unknown |11.0 Status|UNCONFIRMED |NEW Keywords||missed-optimization Component|ipa |tree-optimization Last reconfirmed||2021-04-09 --- Comment #1 from Richard Biener --- Confirmed. With -O2 DOM3 removes the call, with -O3 it does not.
[Bug tree-optimization/99986] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99986 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Version|unknown |11.0 Component|ipa |tree-optimization Depends on||99776 Last reconfirmed||2021-04-09 --- Comment #1 from Richard Biener --- I think this is a duplicate of PR99776 since I can't reproduce with this fix in. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99776 [Bug 99776] missed optimization for dead code elimination at -O3 (vs. -O1)
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
--- Comment #5 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> So perhaps just:
> --- gcc/gimple-ssa-warn-alloca.c.jj 2021-01-04 10:25:38.892233156 +0100
> +++ gcc/gimple-ssa-warn-alloca.c 2021-04-09 12:46:27.466847728 +0200
> @@ -124,9 +124,8 @@ public:
>alloca_type_and_limit (enum alloca_type type,
>wide_int i) : type(type), limit(i) { }
>alloca_type_and_limit (enum alloca_type type) : type(type)
> - { if (type == ALLOCA_BOUND_MAYBE_LARGE
> - || type == ALLOCA_BOUND_DEFINITELY_LARGE)
> - limit = wi::to_wide (integer_zero_node);
> + {
> +limit = wi::to_wide (integer_zero_node);
>}
> };
>
> in this case? Explicitly trying to have limit member conditionally
> uninitialized seems like a bad idea to me.
Yes, that looks good - the existing code is definitely odd, but maybe Martin
can clarify.
[Bug tree-optimization/99986] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99986 --- Comment #2 from Zhendong Su --- (In reply to Richard Biener from comment #1) > I think this is a duplicate of PR99776 since I can't reproduce with this fix > in. Thanks for looking into it, Richard! Would you mind also checking the few tests for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862 whenever you get a chance? I'm happy to file them as separate reports if that would be more convenient. Thank you.
[Bug target/99988] aarch64: GCC generates excessive consecutive bti j instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99988 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org Last reconfirmed||2021-04-09 --- Comment #2 from Alex Coplan --- Taking a look at this.
[Bug c/99990] New: Crash in GCC-11/gimplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
Bug ID: 0
Summary: Crash in GCC-11/gimplify
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: k.even-mendoza at imperial dot ac.uk
Target Milestone: ---
In Ubuntu 18, with GCC-11 (gcc (GCC) 11.0.1 20210317 (experimental)), when
trying to compile this code:
#include
void a() {
va_arg(0, long);
void *b[] = 0;
}
GCC-11 crashed with this error:
===
/home/user42/data/gcc-csmith-0/gcc-install/bin/gcc
934d08d3ee1bab940b2f2f2651e06ccaf8d82f87.c
In file included from 934d08d3ee1bab940b2f2f2651e06ccaf8d82f87.c:1:
934d08d3ee1bab940b2f2f2651e06ccaf8d82f87.c: In function ‘a’:
934d08d3ee1bab940b2f2f2651e06ccaf8d82f87.c:3:13: error: first argument to
‘va_arg’ not of type ‘va_list’
3 | va_arg(0, long);
| ^~~~
934d08d3ee1bab940b2f2f2651e06ccaf8d82f87.c:4:15: error: invalid initializer
4 | void *b[] = 0;
| ^
In file included from 934d08d3ee1bab940b2f2f2651e06ccaf8d82f87.c:1:
934d08d3ee1bab940b2f2f2651e06ccaf8d82f87.c:3:13: internal compiler error: in
gimplify_va_arg_expr, at gimplify.c:15594
3 | va_arg(0, long);
| ^
0x6b7b93 gimplify_va_arg_expr(tree_node**, gimple**, gimple**)
.././../gcc-source/gcc/gimplify.c:15594
0xb8e839 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
.././../gcc-source/gcc/gimplify.c:14156
0xb91416 gimplify_stmt(tree_node**, gimple**)
.././../gcc-source/gcc/gimplify.c:6876
0xb8ecbb gimplify_statement_list
.././../gcc-source/gcc/gimplify.c:1879
0xb8ecbb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
.././../gcc-source/gcc/gimplify.c:14526
0xb91416 gimplify_stmt(tree_node**, gimple**)
.././../gcc-source/gcc/gimplify.c:6876
0xb91bd1 gimplify_bind_expr
.././../gcc-source/gcc/gimplify.c:1421
0xb8e1ee gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
.././../gcc-source/gcc/gimplify.c:14283
0xba776f gimplify_stmt(tree_node**, gimple**)
.././../gcc-source/gcc/gimplify.c:6876
0xba776f gimplify_body(tree_node*, bool)
.././../gcc-source/gcc/gimplify.c:15318
0xba7b9d gimplify_function_tree(tree_node*)
.././../gcc-source/gcc/gimplify.c:15472
0x9dc057 cgraph_node::analyze()
.././../gcc-source/gcc/cgraphunit.c:670
0x9debb7 analyze_functions
.././../gcc-source/gcc/cgraphunit.c:1236
0x9df81d symbol_table::finalize_compilation_unit()
.././../gcc-source/gcc/cgraphunit.c:2514
Please submit a full bug report,
===
Before (gcc-10) it would just stop the compilation (with these two errors) and
exit without crashing.
[Bug ipa/99991] New: Missed inlining of IPA SRA clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Bug ID: 1
Summary: Missed inlining of IPA SRA clone
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
extern void foo(void);
static int a, b;
static int c() {
foo();
while (1)
while (b)
foo();
}
void d() {
if (a)
c();
}
int main() {
d();
return 0;
}
optimizes away the call to foo() at -O1 but not at -O3. At -O1 we inline c()
but at -O3 we create an ISRA clone but do not even seem to consider to inline
it?
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862
--- Comment #5 from Richard Biener ---
(In reply to Zhendong Su from comment #0)
> [561] % gcctk -v
> Using built-in specs.
> COLLECT_GCC=gcctk
> COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/
> x86_64-pc-linux-gnu/11.0.1/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-trunk/configure --disable-bootstrap
> --prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
> --disable-werror --enable-multilib --with-system-zlib
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 11.0.1 20210401 (experimental) [master revision
> e4bb1bd60a9:c23a685bf70:95d217ab52d31dc06fda42fc136dea165909e88b] (GCC)
> [562] %
> [562] % gcctk -O1 -S -o O1.s small.c
> [563] % gcctk -O3 -S -o O3.s small.c
> [564] %
> [564] % wc O1.s O3.s
> 23 45 420 O1.s
> 39 74 669 O3.s
> 62 119 1089 total
> [565] %
> [565] % grep foo O1.s
> [566] % grep foo O3.s
> callfoo
> [567] %
> [567] % cat small.c
> extern void foo(void);
> static int a, b;
> static int c() {
> foo();
> while (1)
> while (b)
> foo();
> }
> void d() {
> if (a)
> c();
> }
> int main() {
> d();
> return 0;
> }
I filed this as PR1.
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862
--- Comment #6 from Richard Biener ---
(In reply to Zhendong Su from comment #1)
> [578] % gcctk -O1 -S -o O1.s small.c
> [579] % gcctk -O3 -S -o O3.s small.c
> [580] %
> [580] % wc O1.s O3.s
> 22 43 410 O1.s
> 37 77 682 O3.s
> 59 120 1092 total
> [581] %
> [581] % grep foo O1.s
> [582] % grep foo O3.s
> callfoo
> [583] %
> [583] % cat small.c
> extern void foo(void);
> static int a, b;
> static void c() {
> if (a) {
> foo();
> for (; b < 1; b++)
> ;
> }
> }
> int main() {
> c();
> c();
> return 0;
> }
This is another case of failing to elide a no longer called function. We
end up partially inlining c() at -O3, inlining the if (a) head and thus
we eliminate the calls to c() in main rather than the call to foo in c().
I'd say the -O3 result is superior but still we fail to remove the
c.part() function definition from the assembly. We have duplicates for this
case.
[Bug c++/99992] New: Diagnose C++11 constexpr body that isn't just return even in uninstantiated templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
Bug ID: 2
Summary: Diagnose C++11 constexpr body that isn't just return
even in uninstantiated templates
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: fdumont at gcc dot gnu.org, jakub at gcc dot gnu.org,
marxin at gcc dot gnu.org, redi at gcc dot gnu.org
Depends on: 99985
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #99985 +++
template
constexpr bool
foo (T x)
{
if (x)
return true;
return false;
}
bool x = foo (0);
If I comment the last line, with -std=c++11 we don't diagnose the:
body of ‘constexpr’ function ‘...’ not a return-statement
error. Could we (at least sometimes) diagnose this even on non-instantiated
templates?
That would help to catch the PR99985 libstdc++ bug more quickly.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985
[Bug 99985] [10/11 Regression] bits/hashtable.h:483:9: error: body of
‘constexpr’ function ... not a return-statement since
g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862
--- Comment #7 from Richard Biener ---
(In reply to Zhendong Su from comment #2)
> [659] % gcctk -O1 -S -o O1.s small.c
> [660] % gcctk -O3 -S -o O3.s small.c
> [661] %
> [661] % wc O1.s O3.s
> 40 86 599 O1.s
> 68 138 1047 O3.s
> 108 224 1646 total
> [662] %
> [662] % grep foo O1.s
> [663] % grep foo O3.s
> callfoo
> [664] %
> [664] % cat small.c
> extern void foo(void);
> int a, b, *c;
> static void d(int f) {
> if (f)
> foo();
> }
> static int e(int f) {
> int g[] = {2, 8, 2, 8, 2, 8, 2, 8, 2, 8, 2};
> int h[60];
> h[0] = g != c;
> if (b)
> while (a) {
> int *i[1] = {&h[6]};
> }
> return f;
> }
> static int *j(int *p) { return 0; }
> int main () {
> int m = e(0);
> d(m);
> int l[8];
> if (j(l))
> while (1)
> ;
> return 0;
> }
This is a case similar to PR1, we create a IPA CP clone and fail to inline
that at -O3 while we are happy to IPA inline e() at -O1.
[Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from rsandifo at gcc dot gnu.org --- Fixed. I was going to count r11-8059 against this too, but forgot.
[Bug c/99990] Crash in GCC-11/gimplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-04-09 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING --- Comment #1 from Martin Liška --- Can't reproduce the ICE..
[Bug target/99866] gcc/config/aarch64/aarch64-protos.h: 2 * passing structs ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99866 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED CC||rsandifo at gcc dot gnu.org --- Comment #1 from rsandifo at gcc dot gnu.org --- Thanks for the report. These constructors are only used for static data though, so I think we should keep them as-is.
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 99866, which changed state. Bug 99866 Summary: gcc/config/aarch64/aarch64-protos.h: 2 * passing structs ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99866 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug ipa/99993] New: Inlining limit on stack growth behaves oddly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
Bug ID: 3
Summary: Inlining limit on stack growth behaves oddly
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
extern void foo(void);
int a, b, *c;
static void d(int f) {
if (f)
foo();
}
static int e(int f) {
int g[] = {2, 8, 2, 8, 2, 8, 2, 8, 2, 8, 2};
int h[60];
h[0] = g != c;
if (b)
while (a) {
int *i[1] = {&h[6]};
}
return f;
}
static int *j(int *p) { return 0; }
int main () {
int m = e(0);
d(m);
int l[8];
if (j(l))
while (1)
;
return 0;
}
at -O1 we IPA inline e() while at -O3 we IPA CP the zero but fail to inline
the otherwise identical clone:
t.c:19:11: missed: not inlinable: main/6 -> e.constprop/8, --param
large-stack-frame-growth limit reached
but with -O1 this doesn't seem to be a consideration. There:
IPA function summary for main/6 inlinable
global time: 35.60
self size: 11
global size: 11
min size: 8
self stack: 32
global stack:32
size:0.00, time:0.00
size:3.00, time:0.60, executed if:(not inlined)
calls:
j/5 function not considered for inlining
freq:1.00 loop depth: 0 size: 3 time: 12 callee size: 1 stack: 0
op0 is compile time invariant
op0 points to local or readonly memory
d/3 function not considered for inlining
freq:1.00 loop depth: 0 size: 2 time: 11 callee size: 3 stack: 0
e/4 function not considered for inlining
freq:1.00 loop depth: 0 size: 3 time: 12 callee size:10 stack:284
op0 is compile time invariant
op0 points to local or readonly memory
compared to
IPA function summary for main/6 inlinable
global time: 19.30
self size: 9
global size: 9
min size: 6
self stack: 0
global stack:0
size:2.00, time:2.00
size:3.00, time:2.00, executed if:(not inlined)
calls:
foo/7 function body not available
freq:0.33 loop depth: 0 size: 1 time: 10
e.constprop/8 function not considered for inlining
freq:1.00 loop depth: 0 size: 3 time: 12 callee size:10 stack:284
op0 is compile time invariant
op0 points to local or readonly memory
maybe the issue is that at -O3 main()s self-stack is zero (it has 'l'
early inlined). Indeed the growth limit seems to be zero if the
estimated self size is zero ... but even with forcing a main stack
size of 4 we run into the limit.
Somehow this looks off (esp. considering this is a single call to
e that is inlined so the net effect on the stack is zero?).
Honza?
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #7)
> (In reply to Zhendong Su from comment #2)
> > [659] % gcctk -O1 -S -o O1.s small.c
> > [660] % gcctk -O3 -S -o O3.s small.c
> > [661] %
> > [661] % wc O1.s O3.s
> > 40 86 599 O1.s
> > 68 138 1047 O3.s
> > 108 224 1646 total
> > [662] %
> > [662] % grep foo O1.s
> > [663] % grep foo O3.s
> > callfoo
> > [664] %
> > [664] % cat small.c
> > extern void foo(void);
> > int a, b, *c;
> > static void d(int f) {
> > if (f)
> > foo();
> > }
> > static int e(int f) {
> > int g[] = {2, 8, 2, 8, 2, 8, 2, 8, 2, 8, 2};
> > int h[60];
> > h[0] = g != c;
> > if (b)
> > while (a) {
> > int *i[1] = {&h[6]};
> > }
> > return f;
> > }
> > static int *j(int *p) { return 0; }
> > int main () {
> > int m = e(0);
> > d(m);
> > int l[8];
> > if (j(l))
> > while (1)
> > ;
> > return 0;
> > }
>
> This is a case similar to PR1, we create a IPA CP clone and fail to
> inline
> that at -O3 while we are happy to IPA inline e() at -O1.
I filed PR3 for it.
For the future please open separate bugs for separate testcases.
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862 --- Comment #9 from Zhendong Su --- > For the future please open separate bugs for separate testcases. Thanks, Richard; will do.
[Bug ipa/98265] [10 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Richard Biener --- Indeed fixed everywhere.
[Bug c/99990] Crash in GCC-11/gimplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #2 from Karine EM --- GCC is from GitHub with this version bc21277 (was: Daily bump.) I compiled gcc-11 with gcc-10 (this gcc-10: gcc (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0) With cmake version 3.13.4, gmp-6.1.0, isl-0.18, mpc-1.0.3, mpfr-3.1.4 and configure with these flags: --disable-multilib --disable-bootstrap --enable-targets='X86' --enable-languages='c,c++,lto,objc,obj-c++'
[Bug libstdc++/99985] [9/10/11 Regression] bits/hashtable.h:483:9: error: body of ‘constexpr’ function ... not a return-statement since g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:40ccb47b505b528244ee305923681c0ae3b6f4d5 commit r11-8085-g40ccb47b505b528244ee305923681c0ae3b6f4d5 Author: Jonathan Wakely Date: Fri Apr 9 12:05:39 2021 +0100 libstdc++: Fix invalid constexpr function in C++11 mode [PR 99985] I keep forgetting that a constexpr function in C++11 has to be a single return statement. libstdc++-v3/ChangeLog: PR libstdc++/99985 * include/bits/hashtable.h (_Hashtable::_S_nothrow_move()): Fix to be a valid constexpr function in C++11. * testsuite/23_containers/unordered_set/cons/99985.cc: New test.
[Bug c/99990] Crash in GCC-11/gimplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||jakub at gcc dot gnu.org Status|WAITING |ASSIGNED --- Comment #3 from Jakub Jelinek --- I can reproduce it. The problem seems to be that when handling the void *b[] = 0; error something overwrites TREE_TYPE (error_mark_node) to some other type.
[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830 --- Comment #5 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #3) > In normal insns such clobbers would be rejected by recog, but for > DEBUG_INSNs we don't have strict validity tests, but guess we need to throw > away at least the worst garbage. combine puts clobbers of const0_rtx in instructions precisely because those *should* be rejected; it does it to abort a combination attempt. So it isn't clear to me why we end up with this here? Papering over it (as the proposed patch does) is not a good idea imho.
[Bug c/99990] [8/9/10/11 Regression] ICE in gimplifier on invalid va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |8.5 Summary|Crash in GCC-11/gimplify|[8/9/10/11 Regression] ICE ||in gimplifier on invalid ||va_arg --- Comment #4 from Jakub Jelinek --- Started with r7-2847-gba9bbd6f584afe2939c44c159cbb1c064becad5c
[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830 --- Comment #6 from Jakub Jelinek --- (In reply to Segher Boessenkool from comment #5) > (In reply to Jakub Jelinek from comment #3) > > In normal insns such clobbers would be rejected by recog, but for > > DEBUG_INSNs we don't have strict validity tests, but guess we need to throw > > away at least the worst garbage. > > combine puts clobbers of const0_rtx in instructions precisely because > those *should* be rejected; it does it to abort a combination attempt. > So it isn't clear to me why we end up with this here? Papering over it > (as the proposed patch does) is not a good idea imho. In the end on the actual instruction the clobber is optimized away and we end up with something that is accepted. And the problem is just that the clobber is propagated into debug insns, which don't have any kind of recog, their content is intentionally much less strict that on normal insns, like it can allow e.g. SUBREGs that normally wouldn't be allowed etc. If something is too weird, dwarf2out will punt on it. But clearly the clobber is something LRA isn't able to deal with.
[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830 --- Comment #7 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #6) > In the end on the actual instruction the clobber is optimized away That is a very serious bug.
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #30 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:f44a2713da7ea8f5abde5b3a98ddf1ab97b9175a commit r11-8087-gf44a2713da7ea8f5abde5b3a98ddf1ab97b9175a Author: Richard Sandiford Date: Fri Apr 9 13:43:15 2021 +0100 testsuite: Skip gfortran.dg/ieee/ieee_[68].f90 for Arm targets [PR78314] For the reasons discussed in PR78314, ieee_support_halting doesn't work correctly for arm* and aarch64*. I think the easiest thing is to skip these tests until the PR is fixed. This doesn't mean that the PR is unimportant. It just doesn't seem useful to have the unpredictable failures described in the PR trail given that the problem is known and has been analysed. gcc/testsuite/ PR libfortran/78314 * gfortran.dg/ieee/ieee_6.f90: Skip for arm* and aarch64*. * gfortran.dg/ieee/ieee_8.f90: Likewise.
[Bug rtl-optimization/87763] [9/10/11 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #69 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:9a54db29387c4e936ab99499bf4d3e1649e92800 commit r11-8088-g9a54db29387c4e936ab99499bf4d3e1649e92800 Author: Richard Sandiford Date: Fri Apr 9 13:43:16 2021 +0100 testsuite: XFAIL two insv_1.c tests [PR87763] This patch XFAILs the remaining regressions in PR87763. We should still fix them at some point, but that's not GCC 11 material. gcc/testsuite/ PR target/87763 * gcc.target/aarch64/insv_1.c: XFAIL two scan tests.
[Bug c++/99994] New: internal compiler error: trying to capture 'f' in instantiation of generic lambda within constraints_satisfied_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
Bug ID: 4
Summary: internal compiler error: trying to capture 'f' in
instantiation of generic lambda within
constraints_satisfied_p
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
In godbolt gcc 11.0.1 20210408:
int main() {
auto f = [](int) { return true; };
return [&](auto i) requires (f(sizeof(i))) { return 99; }(12);
}
In substitution of 'template main():: [with
auto:1 = int]':
3:62: required from here
3:35: internal compiler error: trying to capture 'f' in instantiation of
generic lambda
3 | return [&](auto i) requires (f(sizeof(i))) { return 99; }(12);
| ~~^~~~
0x1d00959 internal_error(char const*, ...)
0x800866 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
0x800bfa add_default_capture(tree_node*, tree_node*, tree_node*)
0x73fdda constraints_satisfied_p(tree_node*, tree_node*)
0x955913 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
0x6e2ace build_op_call(tree_node*, vec**, int)
0x981ab5 finish_call_expr(tree_node*, vec**, bool,
bool, int)
0x8e224d c_parse_file()
0xa612e2 c_common_parse_file()
Without the default-capture the program is rejected with
note: constraints not satisfied
[...]
error: 'f' is not captured
which I think is incorrect since `f` is not odr-used; clang and MSVC accept
either way.
[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99857
--- Comment #6 from Jan Hubicka ---
Thanks for a testcase, it makes things easier to debug indeed :)
The problem is that openmp uses declare_vairant_alt on symbols to make them
special definitions, but the definition flag is not set. That makes
free_lang_data to call release_body and since the code depends on references
things gets out of sync.
I am testing.
diff --git a/gcc/tree.c b/gcc/tree.c
index 7c44c226a33..e4e74ac8afc 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -5849,7 +5849,7 @@ free_lang_data_in_decl (tree decl, class free_lang_data_d
*fld)
if (!(node = cgraph_node::get (decl))
|| (!node->definition && !node->clones))
{
- if (node)
+ if (node && !node->declare_variant_alt)
node->release_body ();
else
{
For next stage1 I think we want to set definition bit for them and remove all
the special cases of declare_vairant_alt that makes them to behave as
definitions. We also want to add checking that !definition symbols are extenral
symbols which is missed in the verifier.
[Bug c/99990] [8/9/10/11 Regression] ICE in gimplifier on invalid va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #5 from Jakub Jelinek --- Created attachment 50536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50536&action=edit gcc11-pr0.patch Untested fix.
[Bug bootstrap/99983] [9/10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 --- Comment #8 from Maxim Kuvyrkov --- I'll revert on gcc-10 and then backport the revert to gcc-9.
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #31 from rsandifo at gcc dot gnu.org --- The previous patch skips the affected tests for now, on the basis that this PR is open and tracking the problem. The bug is very much still there though.
[Bug rtl-optimization/87763] [9/10/11 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 rsandifo at gcc dot gnu.org changed: What|Removed |Added Target Milestone|9.4 |12.0 Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #70 from rsandifo at gcc dot gnu.org --- I've XFAILed the remaining two regressions for now, on the basis that this PR is open and tracking the problem. The bug is very much still there though, so the PR shouldn't be closed.
[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99857
--- Comment #7 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #6)
> Thanks for a testcase, it makes things easier to debug indeed :)
> The problem is that openmp uses declare_vairant_alt on symbols to make them
> special definitions, but the definition flag is not set. That makes
> free_lang_data to call release_body and since the code depends on references
> things gets out of sync.
>
> I am testing.
>
> diff --git a/gcc/tree.c b/gcc/tree.c
> index 7c44c226a33..e4e74ac8afc 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -5849,7 +5849,7 @@ free_lang_data_in_decl (tree decl, class
> free_lang_data_d *fld)
>if (!(node = cgraph_node::get (decl))
> || (!node->definition && !node->clones))
> {
> - if (node)
> + if (node && !node->declare_variant_alt)
> node->release_body ();
> else
> {
Or
- || (!node->definition && !node->clones))
+ || (!node->definition && !node->clones &&
!node->declare_variant_alt))
?
[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99433
--- Comment #8 from Patrick Palka ---
(In reply to gcc-bugs from comment #7)
> Thank you for the quick analysis!
>
> > views::drop(E, F) is specified to be expression-equivalent to the braced
> > init ranges::drop_view{E, F}
>
> Is not completely true, right? As the narrowing warning shows:
>
> ```
> libstdc++-v3/include/std/ranges:2101:24: warning: narrowing conversion of
> ‘std::declval()’ from ‘long unsigned int’ to
> ‘std::ranges::range_difference_t list > >’ {aka ‘long int’} [-Wnarrowing]
> ```
>
> There is some `std::views::all` involved.
Yeah, that comes from drop_view's deduction guide
template
drop_view(_Range&&, range_difference_t<_Range>)
-> drop_view>;
>
> But the following expressions
>
> ```
> #include
> #include
>
> int main()
> {
> std::list list;
> // std::views::drop(list, 0ull); // does not compile
> std::ranges::drop_view{list, 0ull}; // does compile without warnings
> std::ranges::drop_view{std::views::all(list), 0ull}; // does compile
> without warnings
> }
> ```
>
> do compile without any warnings when using `g++-11 -std=c++2a -pedantic
> -Wall -Wextra`!
>
> Even when adding `-Wsystem-headers` there is no "narrowing" warning found in
> those expressions.
Ah, I think that's because 0ull is a constant expression, and a narrowing
conversion in a braced init list _is_ allowed if the value is a constant
expression that's representable in the target type. If you replace 0ull with
some non-constant expression of the same type, the narrowing warning reappears.
[Bug libstdc++/99995] New: [11 Regression] FAIL: 17_intro/headers/c++1998/49745.cc with -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Bug ID: 5 Summary: [11 Regression] FAIL: 17_intro/headers/c++1998/49745.cc with -std=gnu++20 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- In C++20 mode includes which includes for SYS_futex, and that means that POSIX truncate is declared, leading to: In file included from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/atomic_wait.h:44, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:41, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr_atomic.h:33, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/memory:78, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu/bits/stdc++.h:82, from : /usr/include/unistd.h:1015: note: previous declaration 'int truncate(const char*, __off_t)' compiler exited with status 1 FAIL: 17_intro/headers/c++1998/49745.cc (test for excess errors) Excess errors: /home/jwakely/src/gcc/libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc:22: error: 'int truncate' redeclared as different kind of entity This is only seen when adding -std=gnu++20 (or similar) to the test flags explicitly, and only when PCH is enabled so that -include bits/stdc++.h is added to the test flags, because otherwise that test doesn't include . But the underlying problem is that including means Bug 49745 has returned: we include from C++ library headers. This is only an issue for C++20 mode, and will fix itself when the code to use futexes moves into libstdc++.so rather than being in headers. In the meantime, we might want to XFAIL that test for c++20 mode.
[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830
--- Comment #8 from Jakub Jelinek ---
So more details. The i2 insn is:
(insn 16 15 17 2 (set (zero_extract:DI (subreg:DI (reg/v:TI 103 [ f ]) 0)
(const_int 8 [0x8])
(const_int 16 [0x10]))
(subreg:DI (reg:SI 96 [ _7 ]) 0)) "pr99830.c":7:3 744 {*insv_regdi}
(expr_list:REG_DEAD (reg:SI 96 [ _7 ])
(nil)))
and can_combine_p makes through the expand_field_assignment call i2src
(ior:TI (and:TI (reg/v:TI 103 [ f ])
(const_int -16711681 [0xff00]))
(ashift:TI (and:TI (clobber:TI (const_int 0 [0]))
(const_int 255 [0xff]))
(const_int 16 [0x10])))
out of this.
i3 is
(insn 20 19 21 2 (set (reg:SI 108 [ f ])
(zero_extend:SI (subreg:QI (reg/v:TI 103 [ f ]) 0))) "pr99830.c":8:9
114 {*zero_extendqisi2_aarch64}
(expr_list:REG_DEAD (reg/v:TI 103 [ f ])
(nil)))
so, I think it is perfectly fine that when i3 only cares about the low 8 bits
of pseudo 103 that it figures out that it is just the low 8 bits of the
original pseudo 103, not ored with anything else, because (unsigned char)
((whatever & 255) << 16) is 0. So, I don't see anything wrong on i2 -> i3
combination turning it into
(insn 20 19 21 2 (set (reg:SI 108 [ f ])
(zero_extend:SI (subreg:QI (reg/v:TI 103 [ f ]) 0))) "pr99830.c":8:9
114 {*zero_extendqisi2_aarch64}
(nil))
In particular, it is combine_simplify_rtx that is called on:
(zero_extend:SI (subreg:QI (ior:TI (and:TI (reg/v:TI 103 [ f ])
(const_int -16711681 [0xff00]))
(ashift:TI (and:TI (clobber:TI (const_int 0 [0]))
(const_int 255 [0xff]))
(const_int 16 [0x10]))) 0))
which simplifies it into
(and:SI (subreg:SI (reg/v:TI 103 [ f ]) 0)
(const_int 255 [0xff]))
But, there is also
(debug_insn 18 17 19 2 (var_location:HI c (subreg:HI (ashiftrt:SI
(sign_extend:SI (subreg:HI (reg/v:SI 100 [ c ]) 0))
(zero_extend:SI (subreg:QI (reg/v:TI 103 [ f ]) 0))) 0))
"pr99830.c":8:5 -1
(nil))
into which that try_combine propagate_for_debug the (reg/v:TI 103 [ f ])
i2dest and replace it with the i2src mentioned above.
In this case it is similarly used in a (subreg:QI ...) so in theory it could
also optimize into just the low bits of older r103. Except that
propagate_for_debug uses only simplify-rtx.c APIs and doesn't have
combine_simplify_rtx for it. But in theory it could also be used in other
contexts in the debug insn too.
[Bug bootstrap/99983] [9/10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- I guess we want in addition to the reversions (if needed) try to cvise reduce a testcase and bisect what if anything fixed it on the trunk and file a PR for that and see if it can be fixed on the branches.
[Bug c++/99992] Diagnose C++11 constexpr body that isn't just return even in uninstantiated templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2 --- Comment #1 from Jakub Jelinek --- C++11 says: "its function-body shall be = delete, = default, or a compound-statement that contains only — null statements, — static_assert-declarations — typedef declarations and alias-declarations that do not define classes or enumerations, — using-declarations, — using-directives, — and exactly one return statement;" so perhaps if we on a constexpr function template see anything other than the above ones, even if it e.g. could be some statement that is using some parameter pack that would for empty pack instantiate to nothing, we could diagnose it?
[Bug c++/90451] [8/9/10/11 Regression] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451 --- Comment #8 from Jason Merrill --- Created attachment 50537 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50537&action=edit WIP Fix Here's an approach that moves the mark_used calls closer to where the functions are actually used. We might also try moving the calls the other way, to as soon as we have a unique result. Either way, this is too risky for a diagnostic issue at this point in the release cycle, so deferring.
[Bug c++/99992] Diagnose C++11 constexpr body that isn't just return even in uninstantiated templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2 --- Comment #2 from Jakub Jelinek --- So perhaps copy and tweak massage_constexpr_body and constexpr_fn_retval such that it doesn't break_out_target_exprs but just return non-NULL/error_mark_node on RETURN_EXPR and does something sensible for DECL_CONSTRUCTORs (or initially handles only non-ctors?)?
[Bug c++/99968] ICE on remove_const_t in requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99968
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #6 from Patrick Palka ---
Reduced:
template using remove_const_t = T;
template
struct is_scoped_enum
{
using type = remove_const_t;
static constexpr bool value = false;
};
enum E { e0 = __is_enum(E), e1 = is_scoped_enum::value };
99968.C:10:51: required from here
99968.C:4:8: error: enum value type is not ‘INTEGER_TYPE’ nor convertible to
the enum
4 | struct is_scoped_enum
|^~
This one seems to have started with r6-598, the same commit that introduced the
sanity check.
[Bug bootstrap/99996] New: [10 Regression] r10-9673 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Bug ID: 6 Summary: [10 Regression] r10-9673 failed to build Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: fdumont at gcc dot gnu.org Target Milestone: --- On Linux/x86-64, r10-9673 failed to build: https://gcc.gnu.org/pipermail/gcc-regression/2021-April/074554.html /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/./gcc/xgcc -shared-libgcc -B/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/./gcc -nostdinc++ -L/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/src -L/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/usr/x86_64-pc-linux-gnu/bin/ -B/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/usr/x86_64-pc-linux-gnu/lib/ -isystem /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/usr/x86_64-pc-linux-gnu/include -isystem /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/usr/x86_64-pc-linux-gnu/sys-include -fno-checking -x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE -I/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include -I/export/project/git/gcc-bisect-bootstrap/releases/gcc-10/gcc/libstdc++-v3/libsupc++ -O2 -g /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/gcc/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch In file included from /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/unordered_map:46, from /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/gcc/libstdc++-v3/include/precompiled/stdc++.h:117: /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1317:56: internal compiler error: in merge_exception_specifiers, at cp/typeck2.c:2564 1317 | std::is_nothrow_copy_constructible<_Equal>::value) |^ In file included from /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/unordered_map:46, from /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/gcc/libstdc++-v3/include/precompiled/stdc++.h:117: /export/project/git/gcc-bisect-bootstrap/releases/gcc-10/r10-9675/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1317:56: internal compiler error: in merge_exception_specifiers, at cp/typeck2.c:2564 1317 | std::is_nothrow_copy_constructible<_Equal>::value) |^ 0xcf184b merge_exception_specifiers(tree_node*, tree_node*) ../../../gcc/gcc/cp/typeck2.c:2564 0xcc15d5 merge_types(tree_node*, tree_node*) ../../../gcc/gcc/cp/typeck.c:873 0xa33be2 duplicate_decls(tree_node*, tree_node*, bool) ../../../gcc/gcc/cp/decl.c:2259 0xa5772b grokfndecl ../../../gcc/gcc/cp/decl.c:9893 0xa63acf grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) ../../../gcc/gcc/cp/decl.c:13622 0xa71a5e start_function(cp_decl_specifier_seq*, cp_declarator const*, tree_node*) ../../../gcc/gcc/cp/decl.c:16541 0xb80df2 cp_parser_function_definition_from_specifiers_and_declarator ../../../gcc/gcc/cp/parser.c:28909 0xb70523 cp_parser_init_declarator ../../../gcc/gcc/cp/parser.c:20694 0xb82675 cp_parser_single_declaration ../../../gcc/gcc/cp/parser.c:29528 0xb812fa cp_parser_template_declaration_after_parameters ../../../gcc/gcc/cp/parser.c:29100 0xb8226e cp_parser_explicit_template_declaration ../../../gcc/gcc/cp/parser.c:29366 0xb822c8 cp_parser_template_declaration_after_export ../../../gcc/gcc/cp/parser.c:29385 0xb67265 cp_parser_template_declaration ../../../gcc/gcc/cp/parser.c:15877 0xb62d67 cp_parser_declaration ../../../gcc/gcc/cp/parser.c:13398 0xb6305c cp_parser_toplevel_declaration ../../../gcc/gcc/cp/parser.c:13477 0xb62ae8 cp_parser_declaration_seq_opt ../../../gcc/gcc/cp/parser.c:13325 0xb6e5c4 cp_parser_namespace_body ../../../gcc/gcc/cp/parser.c:19740 0xb6e56d cp_parser_namespace_definition ../../../gcc/gcc/cp/parser.c:19718 0xb62e7b cp_pa
[Bug c++/99968] ICE on remove_const_t in requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99968
--- Comment #7 from Patrick Palka ---
Slightly more reduced:
template struct A {
using type = T;
static const bool value = false;
};
enum E { e0 = __is_enum(E), e1 = A::value };
Compiled with -std=c++11 -g
[Bug bootstrap/99996] [10 Regression] r10-9673 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 99983 ***
[Bug bootstrap/99983] [9/10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #10 from Martin Liška --- *** Bug 6 has been marked as a duplicate of this bug. ***
[Bug c/99997] New: Missed optimisation with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
Bug ID: 7
Summary: Missed optimisation with -Os
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Created attachment 50538
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50538&action=edit
Test source
Using the Fedora 33 x86_64 compiler:
gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC)
Building the following (see also attached file):
typedef _Bool bool;
#define __always_inline inline __attribute__((__always_inline__))
enum { PG_head = 16 };
struct page {
unsigned long flags;
unsigned long compound_head;/* Bit zero is set */
};
static inline bool constant_test_bit(int nr, const void *addr)
{
const unsigned int *p = (const unsigned int *)addr;
return ((1UL << (nr & 31)) & (p[nr >> 5])) != 0;
}
static __always_inline bool PageTail(struct page *page)
{
return page->compound_head & 1;
}
static __always_inline bool PageCompound(struct page *page)
{
return constant_test_bit(PG_head, &page->flags) || PageTail(page);
}
bool PageTransCompound(struct page *page)
{
return PageCompound(page);
}
with "gcc -Os" I get the following assembly:
PageTransCompound:
.LFB3:
.cfi_startproc
movl(%rdi), %edx
movl$1, %eax
btl $16, %edx
jc .L2
movq8(%rdi), %rax
andl$1, %eax
.L2:
andl$1, %eax
ret
.cfi_endproc
There are two consecutive identical ANDL instructions, one of which is
superfluous. The compile could eliminate the one that's immediately prior to
the .L2 instruction.
