[Bug c++/93905] [8 Regression] Cannot use Derived type of Base containing both enum and protected destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93905 --- Comment #9 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f4335f978249a2991620f38e118adf790e677968 commit r8-10082-gf4335f978249a2991620f38e118adf790e677968 Author: Jakub Jelinek Date: Wed Feb 26 09:02:05 2020 +0100 c++: Fix rejects-valid bug in cxx_eval_outermost_constant_expr [PR93905] The following testcase is rejected in 8.3, but was accepted in 8.2 and is in 9.x. This started with my PR87934 * constexpr.c (cxx_eval_constant_expression) : Do re-process TREE_CONSTANT CONSTRUCTORs if they aren't reduced constant expressions. backport, where the NSDMI CONSTRUCTOR that contains CONST_DECLs is now constexpr evaluated so that it doesn't contain them. The difference from 9.x is that 9.x doesn't call get_target_expr if we got a CONSTRUCTOR for a class type for something that has been originally a CONSTRUCTOR too. This patch cherry-picks just that hunk of the r9-3835 change. 2020-02-26 Jakub Jelinek PR c++/93905 Backported from mainline 2018-11-04 Jason Merrill * constexpr.c (cxx_eval_outermost_constant_expr): Don't wrap a CONSTRUCTOR if one was passed in. * g++.dg/cpp0x/pr93905.C: New test.
[Bug middle-end/93939] missing optimization for floating-point expression converted to integer whose result is known at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93939 --- Comment #1 from Marc Glisse --- typedef long T; also generates a comparison with 24. The main issue is that b is used outside of the branch controlled by if(b==8), so a naive substitution misses it. Repeating 3*b in the branch is useless, we CSE it anyway. Still, DOM manages the optimization for int, so there is hope.
[Bug c/29186] optimzation breaks floating point exception flag reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186 --- Comment #24 from Richard Biener --- For the division when GCC doesn't know the divident is not zero I think we actually fixed the bug but yes, in general FP operation reordering wrt FP env access isn't fixed. But GCC needs to consider that feclear/testexcept exit the program and since the division may trap it cannot hoist it before the feclearexcept call. It might move it after the fetestexcept call though (delaying traps is OK). As soon as we start to put more knowledge about feclearexcept into GCC this will break again. Oh - we actually do know this since GCC 8 ... So you're just lucky indeed ...
[Bug c++/93905] [8 Regression] Cannot use Derived type of Base containing both enum and protected destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93905 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5de338f001eb2a821f40e599bd55119d43e0ae7e commit r10-6859-g5de338f001eb2a821f40e599bd55119d43e0ae7e Author: Jakub Jelinek Date: Wed Feb 26 09:04:44 2020 +0100 c++: Fix rejects-valid bug in cxx_eval_outermost_constant_expr [PR93905] Add testcase for a bug that has been just on the 8 branch. 2020-02-26 Jakub Jelinek PR c++/93905 * g++.dg/cpp0x/pr93905.C: New test.
[Bug c++/93905] [8 Regression] Cannot use Derived type of Base containing both enum and protected destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93905 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c6b81c451983f1b9a6e184f137819abf4978eddd commit r9-8280-gc6b81c451983f1b9a6e184f137819abf4978eddd Author: Jakub Jelinek Date: Wed Feb 26 09:04:44 2020 +0100 c++: Fix rejects-valid bug in cxx_eval_outermost_constant_expr [PR93905] Add testcase for a bug that has been just on the 8 branch. 2020-02-26 Jakub Jelinek PR c++/93905 * g++.dg/cpp0x/pr93905.C: New test.
[Bug fortran/93835] [9/10 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93835 markeggleston at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from markeggleston at gcc dot gnu.org --- committed
[Bug c++/93907] [10 Regression] internal compiler error: in hashtab_chk_error, at hash-table.c:137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93907
Jonathan Wakely changed:
What|Removed |Added
Keywords|needs-reduction |
Known to work||9.2.0
Summary|internal compiler error: in |[10 Regression] internal
|hashtab_chk_error, at |compiler error: in
|hash-table.c:137|hashtab_chk_error, at
||hash-table.c:137
Known to fail||10.0
--- Comment #3 from Jonathan Wakely ---
creduce yielded the following, which compiles with gcc 9 and -fconcepts.
ICEs with gcc 10 and -std=gnu++2a
template struct c {
static constexpr int d = a;
typedef c e;
};
template struct f;
template using g = typename f::e;
struct b;
template struct f { using e = b; };
template struct m { typedef g aj; };
template class n { typedef typename m::aj e; };
template using an = typename n::e;
template constexpr bool ao = c::d;
template constexpr bool i = c<1>::d;
template concept bb = i;
using cc = __int128;
template concept cd = bb;
template concept ce = requires { requires cd; };
template concept h = ce;
template concept l = h;
template concept cl = ao;
template concept cp = requires(b j) {
requires h>;
};
struct o {
template requires cp auto operator()(b) {}
};
template using cm = decltype(o{}(b()));
template concept ct = l;
template concept dd = ct>;
template concept de = dd;
struct {
template void operator()(da, b);
} di;
class p {
void begin();
};
template using df = p;
template void q() {
df k;
int d;
di(k, d);
}
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
constrained.cc: In instantiation of ‘void::operator()(da, b)
[with da = p; b = int]’:
constrained.cc:41:10: required from here
constrained.cc:17:57: internal compiler error: in hashtab_chk_error, at
hash-table.c:137
17 | template concept ce = requires { requires cd; };
|~^~
0x8ec130 hashtab_chk_error()
/home/jwakely/src/gcc/gcc/gcc/hash-table.c:137
0x94efd3 hash_table::verify(sat_entry* const&,
unsigned int)
/home/jwakely/src/gcc/gcc/gcc/hash-table.h:1033
0x94f5cf hash_table::find_slot_with_hash(sat_entry* const&, unsigned int,
insert_option)
/home/jwakely/src/gcc/gcc/gcc/hash-table.h:968
0x94b9b3 hash_table::find_slot(sat_entry*
const&, insert_option)
/home/jwakely/src/gcc/gcc/gcc/hash-table.h:435
0x94b9b3 save_satisfaction
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2304
0x94c042 satisfaction_cache::save(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2338
0x94c042 satisfy_atom
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2552
0x94c042 satisfy_constraint_r
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2579
0x94cb38 satisfy_constraint
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2599
0x94ce27 tsubst_nested_requirement
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2006
0x94ce27 tsubst_requirement
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2027
0x94ce27 tsubst_requirement_body
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2043
0x94ce27 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2159
0xa8674a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:20336
0xa794c7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:18597
0x94bdaa satisfy_atom
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2523
0x94bdaa satisfy_constraint_r
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2579
0x94cb38 satisfy_constraint
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2599
0x94e627 satisfy_declaration_constraints
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2698
0x94e627 constraint_satisfaction_value
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2733
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/93820] [8/9/10 Regression] wrong code at -O3 on x86_64-linux-gnu since r9-1732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93820 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4d213bf6011ed2b30b9d0ca70069a5dbc294b5d7 commit r10-6860-g4d213bf6011ed2b30b9d0ca70069a5dbc294b5d7 Author: Jakub Jelinek Date: Wed Feb 26 09:33:48 2020 +0100 store-merging: Fix coalesce_immediate_stores [PR93820] The following testcase is miscompiled in 8+. The problem is that check_no_overlap has a special case for INTEGER_CST marked stores (i.e. stores of constants), if both all currenly merged stores and the one under consideration for merging with them are marked that way, it anticipates that other INTEGER_CST marked stores that overlap with those and precede those (have smaller info->order) could be merged with those and doesn't punt for them. In PR86844 and PR87859 fixes I've then added quite large code that is performed after check_no_overlap and tries to find out if we need and can merge further INTEGER_CST marked stores, or need to punt. Unfortunately, that code is there only in the overlapping case code and the testcase below shows that we really need it even in the adjacent store case. After sort_by_bitpos we have: bitpos width order rhs_code 96 32 3 INTEGER_CST 128 32 1 INTEGER_CST 128 128 2 INTEGER_CST 192 32 0 MEM_REF Because of the missing PR86844/PR87859-ish code in the adjacent store case, we merge the adjacent (memory wise) stores 96/32/3 and 128/32/1, and then we consider the 128-bit store which is in program-order in between them, but in this case we punt, because the merging would extend the merged store region from bitpos 96 and 64-bits to bitpos 96 and 160-bits and that has an overlap with an incompatible store (the MEM_REF one). The problem is that we can't really punt this way, because the 128-bit store is in between those two we've merged already, so either we manage to merge even that one together with the others, or would need to avoid already merging the 96/32/3 and 128/32/1 stores together. Now, rather than copying around the PR86844/PR87859 code to the other spot, we can actually just use the overlapping code, merge_overlapping is really a superset of merge_into, so that is what the patch does. If doing adjacent store merge for rhs_code other than INTEGER_CST, I believe the current code is already fine, check_no_overlap in that case doesn't make the exception and will punt if there is some earlier (smaller order) non-mergeable overlapping store. There is just one case that could be problematic, if the merged_store has BIT_INSERT_EXPRs in them and the new store is a constant store (INTEGER_CST rhs_code), then check_no_overlap would do the exception and still would allow the special case. But we really shouldn't have the special case in that case, so this patch also changes check_no_overlap to just have a bool whether we should have the special case or not. Note, as I said in the PR, for GCC11 we could consider performing some kind of cheap DSE during the store merging (perhaps guarded with flag_tree_dse). And another thing to consider is only consider as problematic non-mergeable stores that not only have order smaller than last_order as currently, but also have order larger than first_order, as in this testcase if we actually ignored (not merged with anything at all) the 192/32/0 store, because it is not in between the other stores we'd merge, it would be fine to merge the other 3 stores, though of course the testcase can be easily adjusted by putting the 192/32 store after the 128/32 store and then this patch would be still needed. Though, I think I'd need more time thinking this over. 2020-02-26 Jakub Jelinek PR tree-optimization/93820 * gimple-ssa-store-merging.c (check_no_overlap): Change RHS_CODE argument to ALL_INTEGER_CST_P boolean. (imm_store_chain_info::try_coalesce_bswap): Adjust caller. (imm_store_chain_info::coalesce_immediate_stores): Likewise. Handle adjacent INTEGER_CST store into merged_store->only_constants like overlapping one. * gcc.dg/pr93820.c: New test.
[Bug tree-optimization/93820] [8/9/10 Regression] wrong code at -O3 on x86_64-linux-gnu since r9-1732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93820 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d0eff1793dc844c2a9532d8ef1a07ba137cfb4e6 commit r9-8281-gd0eff1793dc844c2a9532d8ef1a07ba137cfb4e6 Author: Jakub Jelinek Date: Wed Feb 26 09:33:48 2020 +0100 store-merging: Fix coalesce_immediate_stores [PR93820] The following testcase is miscompiled in 8+. The problem is that check_no_overlap has a special case for INTEGER_CST marked stores (i.e. stores of constants), if both all currenly merged stores and the one under consideration for merging with them are marked that way, it anticipates that other INTEGER_CST marked stores that overlap with those and precede those (have smaller info->order) could be merged with those and doesn't punt for them. In PR86844 and PR87859 fixes I've then added quite large code that is performed after check_no_overlap and tries to find out if we need and can merge further INTEGER_CST marked stores, or need to punt. Unfortunately, that code is there only in the overlapping case code and the testcase below shows that we really need it even in the adjacent store case. After sort_by_bitpos we have: bitpos width order rhs_code 96 32 3 INTEGER_CST 128 32 1 INTEGER_CST 128 128 2 INTEGER_CST 192 32 0 MEM_REF Because of the missing PR86844/PR87859-ish code in the adjacent store case, we merge the adjacent (memory wise) stores 96/32/3 and 128/32/1, and then we consider the 128-bit store which is in program-order in between them, but in this case we punt, because the merging would extend the merged store region from bitpos 96 and 64-bits to bitpos 96 and 160-bits and that has an overlap with an incompatible store (the MEM_REF one). The problem is that we can't really punt this way, because the 128-bit store is in between those two we've merged already, so either we manage to merge even that one together with the others, or would need to avoid already merging the 96/32/3 and 128/32/1 stores together. Now, rather than copying around the PR86844/PR87859 code to the other spot, we can actually just use the overlapping code, merge_overlapping is really a superset of merge_into, so that is what the patch does. If doing adjacent store merge for rhs_code other than INTEGER_CST, I believe the current code is already fine, check_no_overlap in that case doesn't make the exception and will punt if there is some earlier (smaller order) non-mergeable overlapping store. There is just one case that could be problematic, if the merged_store has BIT_INSERT_EXPRs in them and the new store is a constant store (INTEGER_CST rhs_code), then check_no_overlap would do the exception and still would allow the special case. But we really shouldn't have the special case in that case, so this patch also changes check_no_overlap to just have a bool whether we should have the special case or not. Note, as I said in the PR, for GCC11 we could consider performing some kind of cheap DSE during the store merging (perhaps guarded with flag_tree_dse). And another thing to consider is only consider as problematic non-mergeable stores that not only have order smaller than last_order as currently, but also have order larger than first_order, as in this testcase if we actually ignored (not merged with anything at all) the 192/32/0 store, because it is not in between the other stores we'd merge, it would be fine to merge the other 3 stores, though of course the testcase can be easily adjusted by putting the 192/32 store after the 128/32 store and then this patch would be still needed. Though, I think I'd need more time thinking this over. 2020-02-26 Jakub Jelinek PR tree-optimization/93820 * gimple-ssa-store-merging.c (check_no_overlap): Change RHS_CODE argument to ALL_INTEGER_CST_P boolean. (imm_store_chain_info::try_coalesce_bswap): Adjust caller. (imm_store_chain_info::coalesce_immediate_stores): Likewise. Handle adjacent INTEGER_CST store into merged_store->only_constants like overlapping one. * gcc.dg/pr93820.c: New test.
[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amonakov at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Alexander Monakov --- fcmov can only raise an x87 fpu exception on x87 stack underflow, which cannot happen here. Even if it did raise FE_INVALID for SNaNs, note that GCC does not support SNaNs by default; -fsignaling-nans can be specified to request that, but note that documentation says the support is incomplete. No bug here afaict.
[Bug tree-optimization/93820] [8/9/10 Regression] wrong code at -O3 on x86_64-linux-gnu since r9-1732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93820 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8edd406bd7515833905d6bba8fb9195af392008c commit r8-10083-g8edd406bd7515833905d6bba8fb9195af392008c Author: Jakub Jelinek Date: Wed Feb 26 09:33:48 2020 +0100 store-merging: Fix coalesce_immediate_stores [PR93820] The following testcase is miscompiled in 8+. The problem is that check_no_overlap has a special case for INTEGER_CST marked stores (i.e. stores of constants), if both all currenly merged stores and the one under consideration for merging with them are marked that way, it anticipates that other INTEGER_CST marked stores that overlap with those and precede those (have smaller info->order) could be merged with those and doesn't punt for them. In PR86844 and PR87859 fixes I've then added quite large code that is performed after check_no_overlap and tries to find out if we need and can merge further INTEGER_CST marked stores, or need to punt. Unfortunately, that code is there only in the overlapping case code and the testcase below shows that we really need it even in the adjacent store case. After sort_by_bitpos we have: bitpos width order rhs_code 96 32 3 INTEGER_CST 128 32 1 INTEGER_CST 128 128 2 INTEGER_CST 192 32 0 MEM_REF Because of the missing PR86844/PR87859-ish code in the adjacent store case, we merge the adjacent (memory wise) stores 96/32/3 and 128/32/1, and then we consider the 128-bit store which is in program-order in between them, but in this case we punt, because the merging would extend the merged store region from bitpos 96 and 64-bits to bitpos 96 and 160-bits and that has an overlap with an incompatible store (the MEM_REF one). The problem is that we can't really punt this way, because the 128-bit store is in between those two we've merged already, so either we manage to merge even that one together with the others, or would need to avoid already merging the 96/32/3 and 128/32/1 stores together. Now, rather than copying around the PR86844/PR87859 code to the other spot, we can actually just use the overlapping code, merge_overlapping is really a superset of merge_into, so that is what the patch does. If doing adjacent store merge for rhs_code other than INTEGER_CST, I believe the current code is already fine, check_no_overlap in that case doesn't make the exception and will punt if there is some earlier (smaller order) non-mergeable overlapping store. There is just one case that could be problematic, if the merged_store has BIT_INSERT_EXPRs in them and the new store is a constant store (INTEGER_CST rhs_code), then check_no_overlap would do the exception and still would allow the special case. But we really shouldn't have the special case in that case, so this patch also changes check_no_overlap to just have a bool whether we should have the special case or not. Note, as I said in the PR, for GCC11 we could consider performing some kind of cheap DSE during the store merging (perhaps guarded with flag_tree_dse). And another thing to consider is only consider as problematic non-mergeable stores that not only have order smaller than last_order as currently, but also have order larger than first_order, as in this testcase if we actually ignored (not merged with anything at all) the 192/32/0 store, because it is not in between the other stores we'd merge, it would be fine to merge the other 3 stores, though of course the testcase can be easily adjusted by putting the 192/32 store after the 128/32 store and then this patch would be still needed. Though, I think I'd need more time thinking this over. 2020-02-26 Jakub Jelinek PR tree-optimization/93820 * gimple-ssa-store-merging.c (check_no_overlap): Change RHS_CODE argument to ALL_INTEGER_CST_P boolean. (imm_store_chain_info::try_coalesce_bswap): Adjust caller. (imm_store_chain_info::coalesce_immediate_stores): Likewise. Handle adjacent INTEGER_CST store into merged_store->only_constants like overlapping one. * gcc.dg/pr93820.c: New test.
[Bug tree-optimization/93820] [8/9/10 Regression] wrong code at -O3 on x86_64-linux-gnu since r9-1732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93820 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934 Zoltan Vajda changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Zoltan Vajda --- (In reply to Alexander Monakov from comment #2) > fcmov can only raise an x87 fpu exception on x87 stack underflow, which > cannot happen here. > > Even if it did raise FE_INVALID for SNaNs, note that GCC does not support > SNaNs by default; -fsignaling-nans can be specified to request that, but > note that documentation says the support is incomplete. > > No bug here afaict. The problem is not the fcmov instruction, but the "fldl -32(%ebp)". It loads an uninitialized value from the variable result, which may be a SNaN.
[Bug target/93930] [8/9/10 Regression] Unnecessary broadcast instructions for AVX512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93930 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Priority|P3 |P2
[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934 Richard Biener changed: What|Removed |Added Keywords|missed-optimization |wrong-code --- Comment #4 from Richard Biener --- But does the load trap? I would expect fcmov also to not trap on sNaNs since it's a move instruction?
[Bug testsuite/93935] [9/10 regression] gcc.dg/vect/bb-slp-over-widen-2.c fails starting with r262371 (r10-6856)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93935 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |9.3
[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- I'm not going to backport this to gcc-8 so closing as fixed.
[Bug middle-end/93939] missing optimization for floating-point expression converted to integer whose result is known at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93939 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-26 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- It needs "backward propagation" of conditional equivalence information which we do for very limited numbers and sets of operations. In VN the additional issue is that we don't record conditional equivalences at all (we just record known predicates) because that doesn't fit in nicely.
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #21 from Jonathan Wakely --- Fixed for GCC 9, I'm not going to backport it to GCC 8.
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544 --- Comment #22 from Jonathan Wakely --- N.B. in case somebody does want to backport it, the fix for this depends on the fix for PR 78448.
[Bug libstdc++/90281] utf-8 encoded std::filesystem::path can not be converted to utf-16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90281 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #5 from Jonathan Wakely --- I no longer plan to backport this to the gcc-8 branch, so closing as fixed.
[Bug ipa/93940] [8/9/10 Regression] crazy codegen bug on Og with builtin_constant_p, coverage, and pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93940 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- This happens in edge_set_predicate: 271 if (predicate && *predicate == false 272 /* When handling speculative edges, we need to do the redirection 273 just once. Do it always on the direct edge, so we do not 274 attempt to resolve speculation while duplicating the edge. */ 275 && (!e->speculative || e->callee)) 276 e = redirect_to_unreachable (e); I bet the inliner assumes that __builtin_constant_p will evaluate to true, D.2273.b = 0; k = D.2273; ... _8 = k.b; _9 = __builtin_constant_p (_8); but while fre3 with -O2 propagates the 0 into __builtin_constant_p and folds it to 1, with -Og we do fewer optimizations and don't propagate the constant to it. With -O2 -fno-tree-fre it will fail the same way.
[Bug ipa/93940] [8/9/10 Regression] crazy codegen bug on Og with builtin_constant_p, coverage, and pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93940 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/93940] [8/9/10 Regression] crazy codegen bug on Og with builtin_constant_p, coverage, and pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93940 --- Comment #7 from Richard Biener --- (In reply to Andrew Pinski from comment #5) > __atomic_fetch_add_8 (&__gcov0._ZN1g1iE1a[2], 1, 0); > > I wonder what the type of __gcov0._ZN1g1iE1a is. It's correct. unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7682b738 precision:64 min max pointer_to_this > BLK size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76990150 domain DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x769900a8 precision:64 min max >> addressable nothrow static BLK :0:0 size unit-size align:256 warn_if_not_align:0> I think the issue is with inliner predicates. The unreachable is added via #1 0x010e52c3 in redirect_to_unreachable ( e= -> )>) at /space/rguenther/src/gcc-9-branch/gcc/ipa-fnsummary.c:236 #2 0x010e53fe in edge_set_predicate ( e= -> )>, predicate=0x7fffc350) at /space/rguenther/src/gcc-9-branch/gcc/ipa-fnsummary.c:267 #3 0x010ee97b in remap_edge_summaries ( inlined_edge= -> )>, node=, info=0x769917b8, callee_info=0x76991820, operand_map=..., offset_map=..., possible_truths=0, toplev_predicate=0x7fffc490) at /space/rguenther/src/gcc-9-branch/gcc/ipa-fnsummary.c:2951 #4 0x010ef369 in ipa_merge_fn_summary_after_inlining ( edge= -> )>) at /space/rguenther/src/gcc-9-branch/gcc/ipa-fnsummary.c:3101 #5 0x02257d95 in inline_call ( new_edges=0x7fffd6a8, overall_size=0x339e5b0 , update_overall_summary=true, callee_removed=0x0) at /space/rguenther/src/gcc-9-branch/gcc/ipa-inline-transform.c:448 #6 0x02248e5b in inline_small_functions () at /space/rguenther/src/gcc-9-branch/gcc/ipa-inline.c:2074 #7 0x0224a8a0 in ipa_inline () at /space/rguenther/src/gcc-9-branch/gcc/ipa-inline.c:2536 #8 0x0224b74d in (anonymous namespace)::pass_ipa_inline::execute ( this=0x33fa340) at /space/rguenther/src/gcc-9-branch/gcc/ipa-inline.c:2944 for $1 = -> )> and likely the __builtin_constant_p handling. Something for Honza to debug. Honza?
[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934 --- Comment #5 from Alexander Monakov --- Ah, indeed. fld won't raise FE_INVALID for 80-bit long double, but here 'result' is stored on the stack in 64-bit format. So: fcmov and 80-bit fldt don't trap, 32-bit flds and 64-bit fldl do. Somehow RTL if-conversion would have to check "-fsignaling-nans is requested and the target may raise FE_INVALID on loads" among other reason to reject a speculative load. I am afraid though that several other optimizations do not anticipate that x87 fp loads can raise exceptions on SNaNs either, making -fsignaling-nans difficult to implement in full.
[Bug debug/93941] gcc generates wrong debug information at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93941 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-26 CC|rguenther at suse dot de |jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Version|unknown |10.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Bisection is likely wrong (-O2 doesn't do vectorization) and rather it's probably related to # DEBUG i => (int) ((ivtmp.22_29 - (unsigned long) &b) /[ex] 10) + 1 somehow breaking down leaving us with some other choice for i from # DEBUG i => 0 or # DEBUG i => (int) ((ivtmp.22_29 - (unsigned long) &b) /[ex] 10) rather than dropping to a debug reset. GCC 9 had here since we didn't have the above "fancy" debug expression for i.
[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-26 Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- (In reply to Alexander Monakov from comment #5) > Ah, indeed. fld won't raise FE_INVALID for 80-bit long double, but here > 'result' is stored on the stack in 64-bit format. > > So: fcmov and 80-bit fldt don't trap, 32-bit flds and 64-bit fldl do. > > Somehow RTL if-conversion would have to check "-fsignaling-nans is requested > and the target may raise FE_INVALID on loads" among other reason to reject a > speculative load. > > I am afraid though that several other optimizations do not anticipate that > x87 fp loads can raise exceptions on SNaNs either, making -fsignaling-nans > difficult to implement in full. I suppose a fldt followed by "truncation" to 32/64 bit would then trap at the truncation step? But yes, this will be difficult to handle. We'd have to mark all loads from not must-initialized memory as possibly trapping and thus not eligible for if-conversion. And this applies to possibly uninitialized registers as well which might be spilled or allocated to the stack. So confirmed at least. It's also more a middle-end issue affecting a subset of targets only.
[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934 --- Comment #7 from Richard Biener --- Or the issue is in regstack handling all stack vars as 80bit and thus introducing the conversion step in the first place.
[Bug tree-optimization/93820] [8/9/10 Regression] wrong code at -O3 on x86_64-linux-gnu since r9-1732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93820 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ce25177f505ea75b3c0833c3f3f0072b97ee1b44 commit r10-6861-gce25177f505ea75b3c0833c3f3f0072b97ee1b44 Author: Jakub Jelinek Date: Wed Feb 26 10:58:13 2020 +0100 testsuite: Add a -O2 -fgimple testcase next to the -O2 -fno-tree-dse one [PR93820] 2020-02-26 Jakub Jelinek PR tree-optimization/93820 * gcc.dg/pr93820-2.c: New test.
[Bug web/93942] New: [Extended-Asm] Last code snippet in 6.47.2.3 Output Operands is unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93942
Bug ID: 93942
Summary: [Extended-Asm] Last code snippet in 6.47.2.3 Output
Operands is unsafe
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: frederic.recou...@univ-grenoble-alpes.fr
Target Milestone: ---
The following code snippet is wrong because the compiler can choose memory "m"
constraint for both d and *e.
uint32_t c = 1;
uint32_t d;
uint32_t *e = &c;
asm ("mov %[e], %[d]"
: [d] "=rm" (d)
: [e] "rm" (*e));
The correct version should use a multi-alternative and it might be a good place
to introduce this notion.
asm ("movl %[e], %[d]"
: [d] "=r,m" (d)
: [e] "g,ri" (*e));
[Bug inline-asm/93903] invalid input constraint in __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93903 Frédéric Recoules changed: What|Removed |Added CC||frederic.recoules@univ-gren ||oble-alpes.fr --- Comment #1 from Frédéric Recoules --- I am pretty sure the error comes from the space you left in "r ". Yet, in the "Simple-Constraints" documentation, it is said that space are ignored to allow visual alignment but, in fact, I realized a while ago it generates an error. I think it would not be a big change to either update the documentation at https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html#Simple-Constraints or to make the parser ignore the blank.
[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934 --- Comment #8 from Alexander Monakov --- I think regstack is fine as x87 only supports computations in its native 80-bit format and conversions to/from ieee float/double happen only on memory loads/stores. > I suppose a fldt followed by "truncation" to 32/64 bit would then trap at the truncation step? Such "truncation" can only be implemented via a spill/reload on x87, so, yes. > We'd have to mark all loads from not must-initialized memory as possibly > trapping and thus not eligible for if-conversion. (except long double) > And this applies to possibly uninitialized registers > as well which might be spilled or allocated to the stack. Ideally registers should be always spilled in their native 80-bit format, for which the problem does not arise. For C with -fexcess-precision=standard this should already be the case.
[Bug target/93047] frename-registers does not work well with __builtin_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:0ce89ea10d93a583854f02bc115e05cfd9d818e4 commit r9-8282-g0ce89ea10d93a583854f02bc115e05cfd9d818e4 Author: Jiufu Guo Date: Mon Feb 17 10:48:39 2020 +0800 rs6000: mark clobber for registers changed by untpyed_call As PR93047 said, __builtin_apply/__builtin_return does not work well with -frename-registers. This is caused by return register(e.g. r3) is used to rename another register, before return register is stored to stack. This patch fix this issue by emitting clobber for those egisters which maybe changed by untyped call. gcc/ 2020-02-26 Jiufu Guo PR target/93047 * config/rs6000/rs6000.md (untyped_call): Add emit_clobber. gcc/testsuite 2020-02-26 Jiufu Guo PR target/93047 * gcc.dg/torture/stackalign/builtin-return-2.c: New test case.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #123 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #121) > (In reply to John Paul Adrian Glaubitz from comment #120) > > > > That's a huge task which is why I prefer fixing issues on the fly. > > I thought this is almost fully automated? > > You can apply this patch to GCC to enable LRA by default for SH > > --- sh.opt.orig 2019-03-04 10:09:09.244521000 +0900 > +++ sh.opt2020-02-26 10:19:55.414340269 +0900 > @@ -299,5 +299,5 @@ > Enable the use of the fsrra instruction. > > mlra > -Target Report Var(sh_lra_flag) Init(0) Save > +Target Report Var(sh_lra_flag) Init(1) Save > Use LRA instead of reload (transitional). I will just do that for the default kernel now. But I won't trigger a full archive rebuild. Just report issues once I see them.
[Bug inline-asm/93942] [Extended-Asm] Last code snippet in 6.47.2.3 Output Operands is unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93942 Andrew Pinski changed: What|Removed |Added Keywords||documentation Component|web |inline-asm --- Comment #1 from Andrew Pinski --- I don;t think this is wrong per-say. There could be target where mov accepts operands as both mem. The manual in this location says more examples, and not an i386 specific example here.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #124 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #123) > I will just do that for the default kernel now. But I won't trigger a full > archive rebuild. Just report issues once I see them. Compiler, of course. Not kernel.
[Bug inline-asm/93942] [Extended-Asm] Last code snippet in 6.47.2.3 Output Operands is unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93942 --- Comment #2 from Frédéric Recoules --- You are right, it is not strictly speaking wrong per-say but, I would say the context is a little bit misleading. Yet, I may be too x86 oriented... as a matter of personal curiosity, do you known an architecture that allows such dual memory constraint?
[Bug rtl-optimization/93943] New: IRA/LRA happily rematerialize (un-CSEs) loads without register pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93943
Bug ID: 93943
Summary: IRA/LRA happily rematerialize (un-CSEs) loads without
register pressure
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
long a[1024], b[512], c[512];
void foo ()
{
for (int i = 0; i < 256; ++i)
{
b[2*i] = a[4*i];
b[2*i+1] = a[4*i+2];
c[2*i] = a[4*i+1];
c[2*i+1] = a[4*i+3];
}
}
at -O3 is vectorized with SSE2 V2DImode vectors doing two vector loads,
two shuffles and two vector stores. But we then emit
.L2:
movdqa a(%rax,%rax), %xmm0
movdqa %xmm0, %xmm1
punpckhqdq a+16(%rax,%rax), %xmm0
punpcklqdq a+16(%rax,%rax), %xmm1
addq$16, %rax
movaps %xmm1, b-16(%rax)
movaps %xmm0, c-16(%rax)
cmpq$4096, %rax
jne .L2
so took advantage of the memory op variant of the punpck instructions
enlarging the code and using more load uops.
[Bug rtl-optimization/93943] IRA/LRA happily rematerialize (un-CSEs) loads without register pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93943 Richard Biener changed: What|Removed |Added Keywords||missed-optimization, ra Target||x86_64-*-* CC||uros at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #1 from Richard Biener --- To me it looks like IRA allocated memory for r83 here for whatever reason. Well, for a cost reason: a3(r83,l1) costs: SSE_REGS:19800,19800 MEM:11880,11880 not sure why though?
[Bug inline-asm/93944] New: Undocumented side effect in operand evaluations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93944
Bug ID: 93944
Summary: Undocumented side effect in operand evaluations
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: frederic.recou...@univ-grenoble-alpes.fr
Target Milestone: ---
I would have said that I read somewhere that concurrent side effect in the
operands is an undefined behavior, but, I read the documentation
(Extended-Asm.html) again and I did not see any mention of this.
Here is a simple motivation example, it is the worst I can produce:
int *f (int *v, const char m[])
{
puts(m);
return v;
}
int main (int argc, char * argv[])
{
__asm__ ("leal 1(%2), %0" "\n\t"
"leal 2(%3), %1"
: "=&r" (*f(&argc, "0")),
"=r" (*f(&argc, "1"))
: "r" (*f(&argc, "2")),
"r" (*f(&argc, "3")));
return argc;
}
Here is what I could think for stdout:
- the behavior is totally undefined and the compiler will make demon fly out of
my nose
- inputs are evaluated before outputs (it could make sense) such 2 and 3 always
appear before 0 and 1 but the rest is undefined
- evaluation order is well defined and leads to "0123", the actual result with
gcc 9.2 (but I don't like it)
But also, lvalue argc takes "supposedly" the value of %0 and %1. I would think
it is an undefined behavior that will depend on compiler final register
allocation, it is?
[Bug tree-optimization/93945] New: [9/10 Regression] memset of non-zero constant followed by bitfield read big-endian miscompilation since r9-547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93945
Bug ID: 93945
Summary: [9/10 Regression] memset of non-zero constant followed
by bitfield read big-endian miscompilation since
r9-547
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
I think since r9-547-gb72feab889cd7925fab59771269638fcc88bc195 we miscompile
following testcase on big-endian (verified on powerpc64-linux) at -O2:
union U { char a[8]; struct S { unsigned int b : 8, c : 13, d : 11; } e; } u;
__attribute__((noipa)) int
foo (void)
{
__builtin_memset (&u.a, 0xf4, sizeof (u.a));
return u.e.c;
}
__attribute__((noipa)) int
bar (void)
{
asm volatile ("" : : "g" (&u) : "memory");
return u.e.c;
}
int
main ()
{
int a = foo ();
__builtin_memset (&u.a, 0xf4, sizeof (u.a));
int b = bar ();
if (a != b)
__builtin_abort ();
return 0;
}
[Bug inline-asm/93942] [Extended-Asm] Last code snippet in 6.47.2.3 Output Operands is unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93942 --- Comment #3 from Andreas Schwab --- M68K has memory to memory moves.
[Bug tree-optimization/93945] [9/10 Regression] memset of non-zero constant followed by bitfield read big-endian miscompilation since r9-547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93945 Jakub Jelinek changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Target Milestone|--- |9.3 --- Comment #1 from Jakub Jelinek --- For 9.x, I think we need to require for that case that ref->size is a multiple of BITS_PER_UNIT (and I must say I'm a little bit worried that for this native_interpret_expr case we don't require that known_eq (ref->size, maxsize)). For the trunk, I'm actually working on support for arbitrary bitfield reads.
[Bug tree-optimization/93945] [9/10 Regression] memset of non-zero constant followed by bitfield read big-endian miscompilation since r9-547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93945
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-02-26
CC||pinskia at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
My bet is there missing the following somewhere:
+ if (BYTES_BIG_ENDIAN)
+ bitpos = TYPE_PRECISION (type) - bitpos - bitsize;
I have not looked where though. I do know BIT_INSERT_EXPR is broken with that
respect.
The following patch fixes that:
commit 7490f8e4f52d38d1ae265bec50ab518e86a53d19
Author: Andrew Pinski
Date: Tue Dec 17 03:54:46 2019 +
Fix big-endian constant folding of BIT_INSERT_EXPR
Big-endian has a different idea of what bit order
should be compared to little-endian. This fixes
it by correcting the shift/mask to be in the correct
order.
Change-Id: I3e4ba3c27d62a20affd08100083cee5f921edc7d
Signed-off-by: Andrew Pinski
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index aefa91666e2..f515d776c57 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -12506,6 +12506,8 @@ fold_ternary_loc (location_t loc, enum tree_code code,
tree type,
{
unsigned HOST_WIDE_INT bitpos = tree_to_uhwi (op2);
unsigned bitsize = TYPE_PRECISION (TREE_TYPE (arg1));
+ if (BYTES_BIG_ENDIAN)
+ bitpos = TYPE_PRECISION (type) - bitpos - bitsize;
wide_int tem = (wi::to_wide (arg0)
& wi::shifted_mask (bitpos, bitsize, true,
TYPE_PRECISION (type)));
[Bug inline-asm/93942] [Extended-Asm] Last code snippet in 6.47.2.3 Output Operands is unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93942 --- Comment #4 from Andrew Pinski --- (In reply to Frédéric Recoules from comment #2) > Yet, I may be too x86 oriented... as a matter of personal curiosity, do you > known an architecture that allows such dual memory constraint? Yes s390, mvc instruction: http://www.simotime.com/asmins01.htm#MVC Which GCC does emit even.
[Bug inline-asm/93942] [Extended-Asm] Last code snippet in 6.47.2.3 Output Operands is unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93942 Frédéric Recoules changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Frédéric Recoules --- Thank you both.
[Bug tree-optimization/93945] [9/10 Regression] memset of non-zero constant followed by bitfield read big-endian miscompilation since r9-547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93945 --- Comment #3 from Jakub Jelinek --- For 9.x all we need is add && multiple_p (ref->size, BITS_PER_UNIT) because the code doesn't attempt to handle loads or stores that aren't byte aligned and whole byte sized. I found this by code inspection when trying to add trunk support for arbitrary load bit offset or ref->size.
[Bug inline-asm/93944] Undocumented side effect in operand evaluations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93944 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- I think you could say there is no sequence points in the inline-asm; just as there is none with most things in C. There for it is unspecified the order of evulations of the function calls. Therefor the code is undefined. I don't think we need to warn here (it is hard to warn due to the function call). I don't think we need to document this either. The main reason because of the sequence points and concurrent side effects in C is also undefined. Think of an inline-asm as one statement and it goes to the same effect as that.
[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org, ||wilson at gcc dot gnu.org --- Comment #15 from Kito Cheng --- RISC-V got fail after g:26d7a5e690169ac04acde90070b0092c41b71c7e for gfortran.dg/pr45636.f90 It seems like because alignment change cause simplify_builtin_call can't simplify memset to load/store. The story for RISC-V here: - simplify_builtin_call call can_store_by_pieces check it's OK to store by pieces? - can_store_by_pieces call targetm.use_by_pieces_infrastructure_p to ask back-end - targetm.use_by_pieces_infrastructure_p call by_pieces_ninsns to calculate how many instruction needed, it was 1 for RV64*, because alignment is changed to 8 bits from 64 bits for char array due to this patch g:26d7a5e690169ac04acde90070b0092c41b71c7e. - by_pieces_ninsns got 4 instead of 1, and large than MOVE_RATIO, failed to simplify memset to load/store. - ARM (aarch32) seems like same story too. * Configure option for RV64: --target=riscv64-unknown-linux-gnu --with-arch=rv64gc --with-abi=lp64 Analysis: - align_local_variable changed policy, only ask alignment info (SET_DECL_ALIGN) from back-end only when expanding (expand pass). - So that's cause cost measurement changed, because some cost measurement are depend on the alignment.
[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811 --- Comment #16 from Jakub Jelinek --- estimate_stack_frame_size is definitely the wrong spot to change DECL_ALIGN of variables, that is a routine for inlining heuristics and shouldn't have such side-effects. It can be done in some other pass of course, but for offloading to work properly, that needs to be after IPA.
[Bug tree-optimization/93681] Wrong optimization: instability of x87 floating-point results leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681 --- Comment #4 from Vincent Lefèvre --- Instead of "-m32 -march=i686", one can also compile with "-mfpmath=387". This is useful if one does not have the 32-bit libs.
[Bug c/93910] -Waddress-of-packed-member triggered without actual access to a member or the address of a member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93910
--- Comment #10 from stephane.goujet at wanadoo dot fr ---
(In reply to stephane.goujet from comment #9)
> 2. There are inconsistencies in the Warning:
Another inconsistency:
2.c The documentation of the packed attribute says "This attribute, attached to
a struct, [...] is equivalent to specifying the packed attribute on each of the
members." Well, guess what? Waddress-of-packed-member is triggered when the
attribute is at the struct level, but is not triggered when it is at members
level.
Example code:
---
# 1 "indiv2.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "indiv2.c"
struct __attribute__((packed)) Sw {
char a;
int b;
};
struct Si {
char a __attribute__((packed));
int b __attribute__((packed));
};
int main(void) {
struct Sw sw;
struct Si si;
int * pw = (int *) &sw;
int * pi = (int *) &si;
return 0;
}
---
Compilation result (setting aside the Wattributes warning,
Waddress-of-packed-member warns for Sw, not for Si):
---
~/test/c/gcc9packed $LC_ALL=C gcc -Wextra indiv2.c -o indiv2_gcc -save-temps
indiv2.c:10:2: warning: 'packed' attribute ignored for field of type 'char'
[-Wattributes]
10 | char a __attribute__((packed));
| ^~~~
indiv2.c: In function 'main':
indiv2.c:18:2: warning: converting a packed 'struct Sw' pointer (alignment 1)
to a 'int' pointer (alignment 4) may result in an unaligned pointer value
[-Waddress-of-packed-member]
18 | int * pw = (int *) &sw;
| ^~~
indiv2.c:3:32: note: defined here
3 | struct __attribute__((packed)) Sw {
|^~
---
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:b6268016bf46dd63227dcbb73d13c30a3b4b9d2a commit r10-6863-gb6268016bf46dd63227dcbb73d13c30a3b4b9d2a Author: Richard Sandiford Date: Tue Feb 25 19:20:58 2020 + optabs: Don't use scalar conversions for vectors [PR93843] In this PR we had a conversion between two integer vectors that both had scalar integer modes. We then tried to implement the conversion using the scalar optab for those modes, instead of doing the conversion elementwise. I wondered about letting through scalar modes for single-element vectors, but I don't have any evidence that that's useful/necessary, so it seemed better to keep things simple. 2020-02-26 Richard Sandiford gcc/ PR middle-end/93843 * optabs-tree.c (supportable_convert_operation): Reject types with scalar modes. gcc/testsuite/ PR middle-end/93843 * gcc.dg/vect/pr93843-1.c: New test. * gcc.dg/vect/pr93843-2.c: Likewise.
[Bug middle-end/93919] [10 Regression] vectorization of 18 char to char16_t conversion is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93919 Bug 93919 depends on bug 93843, which changed state. Bug 93843 Summary: [10 Regression] wrong code at -O3 on x86_64-linux-gnu https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug inline-asm/93944] Undocumented side effect in operand evaluations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93944 Frédéric Recoules changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Frédéric Recoules --- Let me disagree with you because, except if the documentation is intentionally hard to avoid inexperienced people to use inline assembly, I would think that omitting an "obvious" information despite the fact that somebody ask for it seems to be against the purpose of a documentation. That said, in C, I know 3 operators that introduce a sequence point: logical and (&&), logical or (||) and comma (,). The comma is particularly misleading because it is also used, at least, to separate function parameters or compound values initializer where it don't introduce sequence point. Yet, an inline assembly statement uses both comas (,) and colons (:) and, as far as I know, the latter are not used for a similar purpose in the C. I feel it would be legitimate to ask the question of how they interact between them since it is documented nowhere. But hopefully, it will change, isn't it? Disclaimer: I totally understand your point as I was thinking of it as a function call anyway, but I hope you will forgive me for playing the devil's advocate here.
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/93946] New: Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
Bug ID: 93946
Summary: Bogus redundant store removal
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
union U { long long i; long f; };
struct a {union U u;};
struct aa {struct a a;};
struct b {union U u;};
struct bb {struct b b;};
long
foo (struct bb *bv, void *ptr)
{
struct aa *a = ptr;
struct bb *b = ptr;
bv->b.u.f = 1;
a->a.u.i = 0;
b->b.u.f = 0;
return bv->b.u.f;
}
int
main ()
{
union C {struct aa aa; struct bb bb;} v;
if (foo (&v.bb, &v) != 0)
__builtin_abort ();
return 0;
}
we treat b->b.u.f = 0 as redundant because the alias-set of that and the
a->a.u.i = 0 store are actually the same.
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-26 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0, 4.8.5, 7.5.0, 9.2.0 --- Comment #1 from Richard Biener --- Mine.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #26 from Thomas Henlich --- Created attachment 47914 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47914&action=edit Demonstration of range reduction There is a danger of some inaccuracy in the degree trigonometric functions (sind, cosd, tand, cotand) because a full period of 360 degrees can not be expressed accurately in radians. This can be circumvented by using some trigonometric identities to reduce the range and also place the inaccurate x range to where |dy/dx|→min, and away from y values near zero toward high y values so that the error is mostly cancelled. This is a best effort to still be able to use the standard library functions but also get an increased accuracy expected from the degree functions. Thus: 1. Calculate cosd(x) = sind(90 - x) 2. Calculate cotand(x) = tand(90 - x) 3. Reduce range of sind() argument from (0...360) further to x-360 if it is above 270, and to 180-x if it is above 90 Considering the demonstration program: $ gf10 -fdec-math periods.f90 && ./a.exe cos( 90.000 )= -4.37113883E-08 0. sin( 180.00 )= -8.74227766E-08 0. cos( 270.00 )= 1.19248806E-08 0. sin( -360.00 )= -0. 0. sin( 3600.0 )= 0. 0. sin( 36000180.0 )= -8.74227766E-08 0. cotan( 90.000 )= -4.37113883E-08 0. $ gf10 -fdec-math -fdefault-real-8 periods.f90 && ./a.exe cos( 90.000 )= 6.1230317691118863E-017 0. sin( 180.00 )= 1.2246063538223773E-016 0. cos( 270.00 )= -1.8369095307335659E-016 0. sin( -360.00 )= -0.0. sin( 3600.0 )= 0.0. sin( 36000180.0 )= 1.2246063538223773E-016 0. cotan( 90.000 )= 6.1230317691118863E-017 0. showing that values for all multiples of 90 degrees can be computed to be exactly zero.
[Bug tree-optimization/93945] [9/10 Regression] memset of non-zero constant followed by bitfield read big-endian miscompilation since r9-547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93945 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 47915 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47915&action=edit gcc10-pr93945.patch Untested trunk patch.
[Bug analyzer/93947] New: ICE: Segmentation fault (in symtab_node::ultimate_alias_target)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93947
Bug ID: 93947
Summary: ICE: Segmentation fault (in
symtab_node::ultimate_alias_target)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.0.1-alpha20200223 snapshot (g:3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/arm/thumb1-ual-1.c, w/ -O1 -fanalyzer:
struct pf {
unsigned int iu : 2;
};
enum {
qr, jv, vm, mz,
};
int uh;
void
w9 (struct pf *x2)
{
switch (x2->iu)
{
case qr:
case jv:
case vm:
uh = 0;
break;
case mz:
break;
default:
__builtin_abort ();
}
}
% gcc-10.0.1 -O1 -fanalyzer -c tsdnvtnl.c
during IPA pass: analyzer
tsdnvtnl.c: In function 'w9':
tsdnvtnl.c:25:5: internal compiler error: Segmentation fault
25 | default:
| ^~~
0xd8ba2f crash_signal
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/toplev.c:328
0x110d1c1 symtab_node::ultimate_alias_target(availability*, symtab_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/cgraph.h:3242
0x110d1c1 cgraph_node::ultimate_alias_target(availability*, symtab_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/cgraph.h:3263
0x110d1c1 ana::region_model::get_fndecl_for_call(gcall const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:6713
0x3fb ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:4175
0x10eab58 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::state_change*) const
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:1068
0x10eb0e1 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:2492
0x10eb5ca ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:2310
0x10ebcf9 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:3670
0x10ec79c ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:3727
0x10e1ef8 execute
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/analyzer-pass.cc:84
[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947
--- Comment #21 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:761696abfe0a772315449e3d2b57de76756f5953
commit r8-10085-g761696abfe0a772315449e3d2b57de76756f5953
Author: Jonathan Wakely
Date: Fri Jan 24 11:13:55 2020 +
libstdc++: Simplify makefile rule for largefile-config.h (PR91947)
The previous rule could leave an incomplete file if the build was
interrupted, which would then not be remade if make was run again.
This makes the rule more robust by writing to a temporary file and only
moving it into place as the final step. It also simplifies the rule so
that only the essential macro definitions are written to the file, not
the explanatory comments and commented out #undef lines.
Also, the macro for enabling LFS on Mac OS X 10.5 is now set
unconditionally, which is a bug fix from upstream autoconf.
Backport from mainline
2020-01-23 Jonathan Wakely
PR libstdc++/91947
* include/Makefile.am (${host_builddir}/largefile-config.h): Simplify
rule.
* include/Makefile.in: Regenerate.
[Bug libstdc++/81091] libstdc++ not built with large file support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:56b6c2ba3a45c768a33f726b130a56fc19cca650
commit r8-10084-g56b6c2ba3a45c768a33f726b130a56fc19cca650
Author: Jonathan Wakely
Date: Thu Jan 9 13:38:43 2020 +
Build filesystem library with large file support
Enable AC_SYS_LARGEFILE to set the macros needed for large file APIs to
be used by default. We do not want to define those macros in the
public headers that users include. The values of the macros are copied
to a separate file that is only included by the filesystem sources
during the build, and then the macros in are renamed
so that they don't have any effect in user code including our headers.
Also use larger type for result of filesystem::file_size to avoid
truncation of large values on 32-bit systems (PR 91947).
Backport from mainlne
2019-10-04 Jonathan Wakely
PR libstdc++/81091
PR libstdc++/91947
* configure.ac: Use AC_SYS_LARGEFILE to enable 64-bit file APIs.
* config.h.in: Regenerate:
* configure: Regenerate:
* include/Makefile.am (${host_builddir}/largefile-config.h): New
target to generate config header for filesystem library.
(${host_builddir}/c++config.h): Rename macros for large file support.
* include/Makefile.in: Regenerate.
* src/c++17/fs_dir.cc: Include new config header.
* src/c++17/fs_ops.cc: Likewise.
(filesystem::file_size): Use uintmax_t for size.
* src/filesystem/dir.cc: Include new config header.
* src/filesystem/ops.cc: Likewise.
(experimental::filesystem::file_size): Use uintmax_t for size.
[Bug libstdc++/93936] [ranges] std::ranges::split_view<...>::_OuterIter<...>::__current() is private within this context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93936 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-26 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947
--- Comment #20 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:56b6c2ba3a45c768a33f726b130a56fc19cca650
commit r8-10084-g56b6c2ba3a45c768a33f726b130a56fc19cca650
Author: Jonathan Wakely
Date: Thu Jan 9 13:38:43 2020 +
Build filesystem library with large file support
Enable AC_SYS_LARGEFILE to set the macros needed for large file APIs to
be used by default. We do not want to define those macros in the
public headers that users include. The values of the macros are copied
to a separate file that is only included by the filesystem sources
during the build, and then the macros in are renamed
so that they don't have any effect in user code including our headers.
Also use larger type for result of filesystem::file_size to avoid
truncation of large values on 32-bit systems (PR 91947).
Backport from mainlne
2019-10-04 Jonathan Wakely
PR libstdc++/81091
PR libstdc++/91947
* configure.ac: Use AC_SYS_LARGEFILE to enable 64-bit file APIs.
* config.h.in: Regenerate:
* configure: Regenerate:
* include/Makefile.am (${host_builddir}/largefile-config.h): New
target to generate config header for filesystem library.
(${host_builddir}/c++config.h): Rename macros for large file support.
* include/Makefile.in: Regenerate.
* src/c++17/fs_dir.cc: Include new config header.
* src/c++17/fs_ops.cc: Likewise.
(filesystem::file_size): Use uintmax_t for size.
* src/filesystem/dir.cc: Include new config header.
* src/filesystem/ops.cc: Likewise.
(experimental::filesystem::file_size): Use uintmax_t for size.
[Bug libstdc++/78552] std::locale::classic() Needless Race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78552 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:26b070a3f6e5c7ccee7491fb758dba4c72bd7026 commit r8-10086-g26b070a3f6e5c7ccee7491fb758dba4c72bd7026 Author: Jonathan Wakely Date: Wed Feb 26 09:43:59 2020 + PR libstdc++/78552 only construct std::locale for C locale once Backport from mainline 2019-10-09 Jonathan Wakely PR libstdc++/78552 * src/c++98/locale_init.cc (locale::classic()): Do not construct a new locale object for every call. (locale::_S_initialize_once()): Construct C locale here.
[Bug inline-asm/93944] Undocumented side effect in operand evaluations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93944 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- The way sequence points are defined in C, it needs to be explicitly said where there is a sequence point, and as we don't say anything for the inline asm operands, that means there is no sequence point in between them. It really doesn't matter what token is used to separate the operands, in C/C++ it is the comma operator which has a sequence point in between the two expression.
[Bug fortran/93948] New: Surprising option processing of -fdec and -fdec-math in combination with -std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948 Bug ID: 93948 Summary: Surprising option processing of -fdec and -fdec-math in combination with -std Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich at gcc dot gnu.org Target Milestone: --- It is surprising that the -std option leads to the -fdec-math option to be silently ignored, while the -fdec option is honoured. This makes it hard to enforce standard-compliant code while allowing only the small subset of the DEC math extensions. For example program dec1 print "(g0)", sind(0.) end program $ gf10 -std=f2008 dec1.f90 && ./a.exe cco91hFa.o:dec1.f90:(.text+0x57): undefined reference to `sind_' $ gf10 -std=f2008 -fdec dec1.f90 && ./a.exe 0. $ gf10 -std=f2008 -fdec-math dec1.f90 && ./a.exe cc6E3irl.o:dec1.f90:(.text+0x57): undefined reference to `sind_' collect2.exe: error: ld returned 1 exit status $ gf10 -fdec-math dec1.f90 && ./a.exe 0.
[Bug fortran/93948] Surprising option processing of -fdec and -fdec-math in combination with -std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948 Thomas Henlich changed: What|Removed |Added Severity|normal |minor
[Bug inline-asm/93944] Undocumented side effect in operand evaluations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93944 --- Comment #4 from Frédéric Recoules --- I do apologise for the inconvenience, but I am still really convinced that an explicit note wouldn't hurt so much. At least I've learned something today and I am thankful for that.
[Bug target/92922] [10 regression] [ilp32] FAIL: gcc.target/aarch64/sve/acle/asm/ldnt1_u32.c -std=c90 -O1 -g -DTEST_FULL (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92922 Joel Hutton changed: What|Removed |Added CC||joel.hutton at arm dot com --- Comment #1 from Joel Hutton --- This appears to be fixed on trunk.
[Bug analyzer/93938] ICE in validate, at analyzer/region-model.cc:231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93938 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-26 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed; thanks.
[Bug libstdc++/78552] std::locale::classic() Needless Race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78552 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:84a5534ce2f8233e6fe9c957ec51a2328bfe60e3 commit r9-8283-g84a5534ce2f8233e6fe9c957ec51a2328bfe60e3 Author: Jonathan Wakely Date: Wed Feb 26 14:00:07 2020 + PR libstdc++/78552 only construct std::locale for C locale once Backport from mainline 2019-10-09 Jonathan Wakely PR libstdc++/78552 * src/c++98/locale_init.cc (locale::classic()): Do not construct a new locale object for every call. (locale::_S_initialize_once()): Construct C locale here.
[Bug libstdc++/78552] std::locale::classic() Needless Race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78552 Jonathan Wakely changed: What|Removed |Added Target Milestone|10.0|8.4 --- Comment #7 from Jonathan Wakely --- Also fixed for 8.4 and 9.3
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #24 from Oleg Endo --- Adrian, have you had a chance to apply the test patch in comment #22 and re-run it?
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #25 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #24) > Adrian, have you had a chance to apply the test patch in comment #22 and > re-run it? I hadn't seen this patch, sorry. I will try that tonight.
[Bug libstdc++/92376] [8/9 Regression] bootstrap fails with --disable-hosted-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92376 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1b522a79133037f04c8ffcdfbe6c885ccb3ddcd3 commit r9-8284-g1b522a79133037f04c8ffcdfbe6c885ccb3ddcd3 Author: Jonathan Wakely Date: Wed Feb 26 14:20:55 2020 + libstdc++: Fix freestanding build (PR 92376) In a freestanding library we don't install the header, so don't try to include it unless it exists. Explicitly declare aligned alloc functions for freestanding, because doesn't declare them. Backport from mainline 2020-01-17 Jonathan Wakely PR libstdc++/92376 * include/bits/c++config: Only do PSTL config when the header is present, to fix freestanding. * libsupc++/new_opa.cc [!_GLIBCXX_HOSTED]: Declare allocation functions if they were detected by configure.
[Bug c++/89831] [8 Regression] passing 'const ...' as 'this' argument discards qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89831 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 8.4.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #125 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #122) > > The build process is. Fixing broken packages isn't. > > Everything is around 13.000 source packages. > > And, finally, the buildd capacity is limited on sh4. If this was POWER or > SPARC, we would have plenty of resources for a complete rebuild. Can you at least please try to check if the kernel builds & runs OK? As for the other packages, is there a way to let it just try to rebuild everything and get a list of the packages that failed to build. We don't need to sit down and fix all issues one by one for now. At least we can compare the list against the current list of non-building packages. If the difference is not too big, we can consider turning on LRA by default from GCC 10 on.
[Bug c++/93905] [8 Regression] Cannot use Derived type of Base containing both enum and protected destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93905 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed for 8.4+.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #35 from Jonathan Wakely ---
(In reply to Bernd Edlinger from comment #26)
> (In reply to fdlbxtqi from comment #2)
> > Also find a bug of __memmove
> >
> > /*
> >* A constexpr wrapper for __builtin_memmove.
> >* @param __num The number of elements of type _Tp (not bytes).
> >*/
> > template
> > _GLIBCXX14_CONSTEXPR
> > inline void*
> > __memmove(_Tp* __dst, const _Tp* __src, size_t __num)
> > {
> > #ifdef __cpp_lib_is_constant_evaluated
> > if (std::is_constant_evaluated())
> > {
> > for(; __num > 0; --__num)
> > {
> > if constexpr (_IsMove)
> > *__dst = std::move(*__src);
> > else
> > *__dst = *__src;
> > ++__src;
> > ++__dst;
> > }
> > return __dst;
> > }
> > else
> > #endif
> > return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
> > return __dst;
> > }
> >
> > The last 2nd line return __dst is wrong. It should not exist.
>
> Sorry, I don't know what this function is all about.
> But to me the code in the ifdef looks totally bogus.
> First it returns __dst+__num, while memmove is sopposed
> to return __dst, and is is somehow clear that
> __dst and __src do not overlap?
Yes, it was only used by std::copy and std::move and they require that __dst is
not in the range [__src, __src+__num). It's allowed for __dst+__num to be in
that range, but the function works correctly in that case anyway.
The return value wasn't used.
But I've removed the entire function, so it doesn't matter now.
[Bug analyzer/93947] ICE: Segmentation fault (in symtab_node::ultimate_alias_target)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93947 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-26 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed; thanks.
[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #10 from Oleg Endo --- I can't reproduce the first case with a standalone sh-elf compiler (GCC 9). The compile flags mention -specs=/usr/share/dpkg/pie-compile.specs ... what's in that specs file?
[Bug libstdc++/92376] [8/9 Regression] bootstrap fails with --disable-hosted-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92376 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- Fixed for 8.4 and 9.3 too.
[Bug libstdc++/92376] [8/9 Regression] bootstrap fails with --disable-hosted-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92376 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:499ea2e31fba0ff6e4492f0a62e3ffb2bdba465e commit r8-10087-g499ea2e31fba0ff6e4492f0a62e3ffb2bdba465e Author: Jonathan Wakely Date: Wed Feb 26 14:20:55 2020 + libstdc++: Fix freestanding build (PR 92376) Explicitly declare aligned alloc functions for freestanding, because doesn't declare them. Backport from mainline 2020-01-17 Jonathan Wakely PR libstdc++/92376 * libsupc++/new_opa.cc [!_GLIBCXX_HOSTED]: Declare allocation functions if they were detected by configure.
[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #11 from James Clarke ---
(In reply to Oleg Endo from comment #10)
> I can't reproduce the first case with a standalone sh-elf compiler (GCC 9).
>
> The compile flags mention
>
> -specs=/usr/share/dpkg/pie-compile.specs
>
> ... what's in that specs file?
(sid-sh4-sbuild)root@sh4-gandi-02:~# cat /usr/share/dpkg/pie-compile.specs
*self_spec:
+
%{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:%{!fno-PIE:%{!no-pie:-fPIE
So, since -fPIC is provided on the command line already, it shouldn't be doing
anything.
[Bug c/93812] [9/10 Regression] ICE in get_constant, at c-family/c-format.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93812
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
__attribute__((__format__(__printf__, 1, 2))) void foo ();
void foo (void);
void
bar (void)
{
foo ();
}
ICEs too, no need for nested prototypes or recursive calls.
[Bug c++/90546] [9/10 Regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 Bug 90546 depends on bug 86521, which changed state. Bug 86521 Summary: [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/86521] [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Jason Merrill --- Fixed for 8.4+.
[Bug c++/88380] [8 Regression] Sequence of not-explicitly initialised, initialised, variable length generates no initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88380 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed for 8.4+.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 Jonathan Wakely changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-26 Ever confirmed|0 |1 --- Comment #36 from Jonathan Wakely --- Patches should be sent to the mailing list, and a copyright assignment (or public domain disclaimer) would be needed for a patch of this size. Otherwise, leave it to me to do once we start the GCC 11 dev phase. Adding checks for types satisfying contiguous_iterator looks worthwhile, but should be a separate patch. I think the condition for using memmove should be something like: __are_same<_ValueTypeI, _ValueTypeO>::__value || (__is_integer<_ValueTypeI>::__value && __is_integer<_ValueTypeo>::__value && sizeof(_ValueTypeI) == sizeof(_ValueTypeO))
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 Jonathan Wakely changed: What|Removed |Added Target|gcc 10.0| Target Milestone|--- |11.0
[Bug c++/93803] [10 Regression] ICE: segmentation fault with constant initialization of class having a [[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93803
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:d6ff22074126d38829f25981de9d6940cd2a234c
commit r10-6865-gd6ff22074126d38829f25981de9d6940cd2a234c
Author: Marek Polacek
Date: Mon Feb 24 09:19:01 2020 -0500
c++: Fix ICE with constexpr init and [[no_unique_address]] [PR93803]
Here we crash when constexpr-initializing a class member of empty class
type with [[no_unique_address]]. Without the attribute we would have
a ctor (that initializes bar) of the form
{ .D.2173 = { .x = {} } }
but with the attribute reduced_constant_expression_p gets
{ .x = {} }
That means that "idx != field" is true for the latter and we see that
foo, the base class of bar, is an empty class, so we want to look at
the next initializable field (since empty class fields may not have an
initializer). But in this case there are no more, therefore accessing
DECL_CHAIN (field) crashes. Long story short, we need to avoid a crash
on a null field when we're initializing a class that only contains an
empty base class.
While poking into this I discovered c++/93898, but that's a different
problem.
2020-02-26 Marek Polacek
PR c++/93803 - ICE with constexpr init and [[no_unique_address]].
* constexpr.c (reduced_constant_expression_p): Don't crash on a null
field.
* g++.dg/cpp2a/constexpr-init16.C: New test.
* g++.dg/cpp2a/constexpr-init17.C: New test.
[Bug c++/93803] [10 Regression] ICE: segmentation fault with constant initialization of class having a [[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93803 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
Oleg Endo changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #12 from Oleg Endo ---
This looks to be an LRA related issue (checking with GCC 10). Without -mlra it
actually compiles fine. Adding -mlra causes some issues:
sh-elf-g++ -m4 -ml -matomic-model=soft-gusa -O2 -fno-strict-aliasing
-fno-exceptions -fno-rtti -fPIC -fstack-protector-strong -std=c++17 -mlra
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp: In static
member function 'static sh::TConstantUnion*
sh::TIntermConstantUnion::FoldAggregateBuiltIn(sh::TIntermAggregate*,
sh::TDiagnostics*)':
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
error: insn does not satisfy its constraints:
(insn 9652 9651 3240 388 (parallel [
(set (reg:SF 66 fr2 [orig:662 _764 ] [662])
(reg:SF 0 r0 [3347]))
(use (reg:SI 154 fpscr0))
(clobber (scratch:SI))
])
"../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp":3568:60 214
{movsf_ie}
(expr_list:REG_DEAD (reg:SF 0 r0 [3347])
(nil)))
during RTL pass: cprop_hardreg
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
internal compiler error: in extract_constrain_insn, at recog.c:2195
0x5dee99 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x5deec2 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:118
0xe46907 extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.c:2195
0xe4a204 copyprop_hardreg_forward_1
../../gcc/gcc/regcprop.c:802
0xe4b212 execute
../../gcc/gcc/regcprop.c:1367
sh-elf-g++ -m4 -ml -matomic-model=soft-gusa -O2 -std=c++17 -mlra
during RTL pass: reload
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp: In member
function 'sh::TConstantUnion*
sh::TIntermConstantUnion::foldUnaryComponentWise(TOperator,
sh::TDiagnostics*)':
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3047:1:
internal compiler error: in lra_set_insn_recog_data, at lra.c:1000
0xd1f5f1 lra_set_insn_recog_data(rtx_insn*)
../../gcc/gcc/lra.c:998
0xd2218f lra_get_insn_recog_data
../../gcc/gcc/lra-int.h:488
0xd2218f remove_scratches_1
../../gcc/gcc/lra.c:2058
0xd22247 lra_emit_move(rtx_def*, rtx_def*)
../../gcc/gcc/lra.c:503
0xd399bb curr_insn_transform
../../gcc/gcc/lra-constraints.c:4434
0xd3b20d lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:5025
0xd227d4 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2437
0xcd20c9 do_reload
../../gcc/gcc/ira.c:5523
0xcd20c9 execute
../../gcc/gcc/ira.c:5709
Vlad, maybe you have some hint where to look?
[Bug c/93812] [9/10 Regression] ICE in get_constant, at c-family/c-format.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93812 --- Comment #3 from Jakub Jelinek --- The problem is that c-format.c assumes that when the "format" attribute is present, handle_format_attribute has already verified it and it was ok. Unfortunately, that is not the case, because if the attribute appears on a !prototype_p function declaration, then fewer checks are performed on it compared to when it appears on a prototype_p function, and if the !prototype_p function decl is then merged with a prototype_p function decl, nothing performs the checking. So, one way out of this is drop the validated_p stuff and always validate,, it will then behave similarly to how: __attribute__((nonnull(2))) void foo (void); warns and doesn't add the attribute, but __attribute__((nonnull(2))) void bar (); void bar (void); adds it silently (but in this case I believe it doesn't ICE when actually using the attribute). Another possibility would be to repeat the checking of the attributes which need positional_argument (nonnull, format*, alloc_size, alloc_align) when merging a !prototype_p decl with prototype_p one.
[Bug c++/93862] [10 Regression] ICE on static_cast of rvalue-reference-to-array of unknown bound [P0338] to its known static bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93862 --- Comment #4 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:4a305fa2fd4c9d553b26efa00f868aa1e4416a9f commit r10-6867-g4a305fa2fd4c9d553b26efa00f868aa1e4416a9f Author: Marek Polacek Date: Mon Feb 24 14:43:48 2020 -0500 c++: Fix ICE with static_cast when converting from int[] [PR93862] This ICEs since my patch for P0388, which allowed conversions to arrays of unknown bound, but not the reverse, so these two static_casts are ill-formed. [expr.static.cast]/3 says that "cv1 T1" and "cv2 T2" have to be reference-compatible and the comment in build_static_cast_1 says it too but then we actually use reference_related_p... Fixed thus. 2020-02-26 Marek Polacek PR c++/93862 - ICE with static_cast when converting from int[]. * call.c (reference_compatible_p): No longer static. * cp-tree.h (reference_compatible_p): Declare. * typeck.c (build_static_cast_1): Use reference_compatible_p instead of reference_related_p. * g++.dg/cpp0x/rv-cast7.C: New test.
[Bug libstdc++/93562] [8/9 Regression] unique_ptr::swap incorrectly uses generic std::swap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93562 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:30cb4c78ea6563177c43f897e480d9993c38c0ed commit r9-8285-g30cb4c78ea6563177c43f897e480d9993c38c0ed Author: Jonathan Wakely Date: Wed Feb 26 15:04:53 2020 + libstdc++: Fix regressions in unique_ptr::swap (PR 93562) The requirements for this function are only that the deleter is swappable, but we incorrectly require that the element type is complete and that the deleter can be swapped using std::swap (which requires it to be move cosntructible and move assignable). The fix is to add __uniq_ptr_impl::swap which swaps the pointer and deleter individually, instead of using the generic std::swap on the tuple containing them. PR libstdc++/93562 * include/bits/unique_ptr.h (__uniq_ptr_impl::swap): Define. (unique_ptr::swap, unique_ptr::swap): Call it. * testsuite/20_util/unique_ptr/modifiers/93562.cc: New test.
[Bug c/93949] New: Register const local var will not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93949
Bug ID: 93949
Summary: Register const local var will not compile
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
This valid code will not compile.
int main(void){
register const double d[3] = { 0., 1., 2. };
return 0;
}
[Bug c++/93862] [10 Regression] ICE on static_cast of rvalue-reference-to-array of unknown bound [P0338] to its known static bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93862 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
