[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #11 from Richard Biener ---
With some hand-waving we could generate
void square(unsigned t, int *tt)
{
if (t<=4) __builtin_abort();
tt[0] = 0;
tt[1] = 0;
tt[2] = 0;
tt[3] = 0;
tt[4] = 0;
}
but I don't see how it fits any existing transform? The "hand-waving"
would be that __builtin_abort () since it's a known function cannot
observe the dropped side-effects like tt[0] = 0 when t > 0.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #10 from Richard Biener ---
(In reply to cqwrteur from comment #9)
> (In reply to Richard Biener from comment #8)
> > I don't see what we can optimize for the reduced testcases.
>
> void square(unsigned t, int *tt)
> {
> if (t<=0) __builtin_abort();
> tt[0] = 0;
> if (t<=1) __builtin_abort();
> tt[1] = 0;
> if (t<=2) __builtin_abort();
> tt[2] = 0;
> if (t<=3) __builtin_abort();
> tt[3] = 0;
> if (t<=4) __builtin_abort();
> tt[4] = 0;
> }
>
> but this should be able to optimize.
How? Can you show the desired result?
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #9 from cqwrteur ---
(In reply to Richard Biener from comment #8)
> I don't see what we can optimize for the reduced testcases.
void square(unsigned t, int *tt)
{
if (t<=0) __builtin_abort();
tt[0] = 0;
if (t<=1) __builtin_abort();
tt[1] = 0;
if (t<=2) __builtin_abort();
tt[2] = 0;
if (t<=3) __builtin_abort();
tt[3] = 0;
if (t<=4) __builtin_abort();
tt[4] = 0;
}
but this should be able to optimize.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener --- I don't see what we can optimize for the reduced testcases.
[Bug target/101464] Replace zveroupper with vpxor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101464 --- Comment #3 from Richard Biener --- But in the long discussion involving vzeroupper and HTM aborts in glibc memory functions it came up that vpxor is _not_ properly clearing the upper state and thus does _not_ remove the penalty that following non-VEX SSE instructions get?
[Bug tree-optimization/101462] [12 regression] ICE on aarch64 after r12-2292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101462 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-07-16 Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Version|9.0 |12.0 --- Comment #1 from Richard Biener --- I will have a look.
[Bug testsuite/101461] [12 regression] gcc.target/powerpc/fold-vec-load-builtin_vec_xl test cases fail after r12-2266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101461 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/101110] [12 regression] gcc.c-torture/execute/950704-1.c fails after r12-1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110 --- Comment #5 from Xi Ruoyao --- (In reply to Andrew Macleod from comment #4) > Does this still fail? When i look at a cross compiler listing I do not see > any differences from ranger in the listing. Should be fixed at d48320083c9a2bdf0ddac693f9d523755b8b29ec. Sorry for forgetting to mention the PR number in the commit.
[Bug target/61032] rs6000 code gen suffers from lack of address_cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61032 Alan Modra changed: What|Removed |Added Assignee|amodra at gmail dot com|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #2 from Alan Modra --- Deassigning myself, since it is clear that the rtx_costs patches are going nowhere.
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 Alan Modra changed: What|Removed |Added Status|ASSIGNED|NEW URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-October ||/555760.html Assignee|amodra at gmail dot com|unassigned at gcc dot gnu.org --- Comment #8 from Alan Modra --- Patch posted at given URL above. I'm taking myself off as assignee because it is clear to me the patch is going nowhere. Someone more capable than me will need to take up the task, sorry.
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 --- Comment #7 from Kevin Zhao --- Hi Richard, Thanks for your clarification. Really appreciated! I think that should be the root cause.
[Bug c/101453] ICE on compilable code: *** buffer overflow detected ***: terminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101453 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-July/57 ||5387.html Keywords||patch --- Comment #2 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575387.html
[Bug target/101464] Replace zveroupper with vpxor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101464 --- Comment #2 from H.J. Lu --- Created attachment 51159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51159&action=edit A patch
[Bug target/101464] Replace zveroupper with vpxor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101464 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- >From the implementation perspective, we need to record all usage of sse registers which is AVX_U128_DIRTY and clear them all.
[Bug other/101459] Mismatch in description of option "-falign-functions" between source code and documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101459 --- Comment #5 from ashimida --- (In reply to Andrew Pinski from comment #4) > (In reply to ashimida from comment #3) > > (In reply to Richard Biener from comment #2) > > > The flag, -falign-functions is only enabled at -O2+ (but not -Os), but the > > > actual alignment is recorded in the 'align_functions' data which is only > > > populated when -falign-functions is specified so I think it works as > > > documented. > > > > so I think this flag is also worked at -O0 > > I think you are misunderstanding the documentation. The documentation is > saying it is enabled by default at -O2 and above (but not -Os); not that it > will only work at -O2 and above. okey, now I understand, I have misunderstood this option, thank you very much!
[Bug other/101459] Mismatch in description of option "-falign-functions" between source code and documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101459 --- Comment #4 from Andrew Pinski --- (In reply to ashimida from comment #3) > (In reply to Richard Biener from comment #2) > > The flag, -falign-functions is only enabled at -O2+ (but not -Os), but the > > actual alignment is recorded in the 'align_functions' data which is only > > populated when -falign-functions is specified so I think it works as > > documented. > > so I think this flag is also worked at -O0 I think you are misunderstanding the documentation. The documentation is saying it is enabled by default at -O2 and above (but not -Os); not that it will only work at -O2 and above.
[Bug tree-optimization/101110] [12 regression] gcc.c-torture/execute/950704-1.c fails after r12-1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110 --- Comment #4 from Andrew Macleod --- Does this still fail? When i look at a cross compiler listing I do not see any differences from ranger in the listing.
[Bug c++/50462] poor diagnostics for missing parenthesis in call to method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
--- Comment #7 from Jonathan Wakely ---
Oh, it's the overloaded function thjat makes the difference between saying
"invalid use of non-static member function" and trying to do overload
resolution with an .
Reduced example that actually reproduces the original problem:
struct ostream { };
void operator<<(ostream, int) { }
void operator<<(ostream, void*) { }
void operator<<(ostream, char*) { }
struct V
{
int size() { return 0; };
int size() const { return 0; };
};
void print(V v)
{ ostream() << v.size; }
Which prints this with current trunk:
50462.C: In function 'void print(V)':
50462.C:14:13: error: no match for 'operator<<' (operand types are 'ostream'
and '')
14 | { ostream() << v.size; }
| ~ ^~ ~~
| | |
| ostream
50462.C:3:6: note: candidate: 'void operator<<(ostream, int)'
3 | void operator<<(ostream, int) { }
| ^~~~
50462.C:3:26: note: no known conversion for argument 2 from '' to 'int'
3 | void operator<<(ostream, int) { }
| ^~~
50462.C:4:6: note: candidate: 'void operator<<(ostream, void*)'
4 | void operator<<(ostream, void*) { }
| ^~~~
50462.C:4:26: note: no known conversion for argument 2 from '' to 'void*'
4 | void operator<<(ostream, void*) { }
| ^
50462.C:5:6: note: candidate: 'void operator<<(ostream, char*)'
5 | void operator<<(ostream, char*) { }
| ^~~~
50462.C:5:26: note: no known conversion for argument 2 from '' to 'char*'
5 | void operator<<(ostream, char*) { }
| ^
I don't see why we should treat v.size any differently whether it's overloaded
or not. It's invalid either way, so we should fail similarly.
[Bug c++/101465] Poorly worded error from a call to a pointer-to-member function not wrapped in parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101465 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-07-15 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- And we should issue a fix-it suggestion too. I thought this was a dup of an existing bug, but I can't find one, so confirmed.
[Bug c++/50462] poor diagnostics for missing parenthesis in call to method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > Since GCC 4.9 we don't perform overload resolution, so I think this is fixed: Huh, that's true for the reduced example in comment 4, but the original one from Chris still prints a wall of errors.
[Bug c++/50462] poor diagnostics for missing parenthesis in call to method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
--- Comment #5 from Jonathan Wakely ---
Since GCC 4.9 we don't perform overload resolution, so I think this is fixed:
50462.C: In function 'void print(V)':
50462.C:13:13: error: invalid use of non-static member function 'int V::size()'
13 | { ostream() << v.size; }
| ~~^
50462.C:9:13: note: declared here
9 | int size() { return 0; };
| ^~~~
[Bug target/101346] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101346 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:f364cdffa47af574f90f671b2dcf5afa91442741 commit r12-2340-gf364cdffa47af574f90f671b2dcf5afa91442741 Author: Uros Bizjak Date: Thu Jul 15 22:34:25 2021 +0200 i386: Fix ix86_hard_regno_mode_ok for TDmode on 32bit targets [PR101346] General regs on 32bit targets do not support 128bit modes, including TDmode. gcc/ 2021-07-15 Uroš Bizjak PR target/101346 * config/i386/i386.h (VALID_SSE_REG_MODE): Add TDmode. (VALID_INT_MODE_P): Add SDmode and DDmode. Add TDmode for TARGET_64BIT. (VALID_DFP_MODE_P): Remove. * config/i386/i386.c (ix86_hard_regno_mode_ok): Do not use VALID_DFP_MODE_P. gcc/testsuite/ 2021-07-15 Uroš Bizjak PR target/101346 * gcc.target/i386/pr101346.c: New test.
[Bug c++/17459] Spurious message when forgetting parentheses on call of member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17459 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2005-06-13 00:43:47 |2021-7-15 --- Comment #6 from Jonathan Wakely --- (In reply to Manuel López-Ibáñez from comment #5) > The first error could be a bit nicer if it said why it is invalid. Clang > does: > > test.cc:3:16: error: reference to non-static member function must be called; > did you mean to call it with no arguments? I think we should just add a fix-it hint suggesting to add the () > but the thing is that this is not even a valid reference, so the error could > clarify a bit more the problem, no? I don't think mentioning "reference" here is a good idea at all, because that means something specific in C++ (and completely unrelated to this). I prefer GCC's "invalid use" wording. With a fix-it to add the () the error would be fine. If the function can't be called with no arguments, the fix-it would be wrong. I'm not sure what we want to do in that case. Suggest the fix-it anyway, and let the user figure out the next step? Clang just says: 17459-c3.C:3:16: error: reference to non-static member function must be called i.e. it omits the "did you mean to call it with no arguments?" part. So we could do the same and just not provide a fix-it in that case. > ISO C++ forbids taking the address of an unqualified non-static member > function, say ‘&S::foo’ instead; or did you mean to call 'foo()'? Maybe we should remove the -fpermissive extension that allows &foo as a non-standard way to form a pointer-to-member. That simplifies the handling of &foo, because we can just reject it instead of using a permerror. It's more than 20 years since that was acceptable syntax. And that could use a fix-it hint too, to suggest turning &foo into &S::foo. > The last error is bogus, it should be the same as the first one. Agreed.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 71690, which changed state. Bug 71690 Summary: some integer conversions defeat memcpy optimizaton https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/71690] some integer conversions defeat memcpy optimizaton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 Andrew Macleod changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Macleod --- Not sure how to create a test case for this that isn't super dependent on debugging output formatting. regardless, the correct ranges are available if you are using ranger, so I will close this PR as "use ranger in your pass" :-) details here: https://gcc.gnu.org/pipermail/gcc/2021-June/236363.html it boils down to replacing your get_range_info calls (or SSA_NAME_RANGE_INFO or whatever is being used) with get_range_query ()->range_of_expr ()
[Bug c++/83596] ['17] can't use member pointer result of a constexpr function as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83596 Jonathan Wakely changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #2 from Jonathan Wakely --- Fixed for GCC 9.1 by Jakub's patch: re PR c++/89285 (ICE after casting the this pointer in the constructor in C++17 mode) PR c++/89285 * builtins.c (fold_builtin_arith_overflow): If first two args are INTEGER_CSTs, set intres and ovfres to constants rather than calls to ifn. * constexpr.c (struct constexpr_fundef): Add parms and result members. (retrieve_constexpr_fundef): Adjust for the above change. (register_constexpr_fundef): Save constexpr body with copy_fn, temporarily set DECL_CONTEXT on DECL_RESULT before that. (get_fundef_copy): Change FUN argument to FUNDEF with constexpr_fundef * type, grab body and parms/result out of constexpr_fundef struct and temporarily change it for copy_fn calls too. (cxx_eval_builtin_function_call): For __builtin_FUNCTION temporarily adjust current_function_decl from ctx->call context. Test !potential_constant_expression instead of !is_constant_expression. (cxx_bind_parameters_in_call): Grab parameters from new_call. Undo convert_for_arg_passing changes for TREE_ADDRESSABLE type passing. (cxx_eval_call_expression): Adjust get_fundef_copy caller. (cxx_eval_conditional_expression): For IF_STMT, allow then or else operands to be NULL. (label_matches): Handle BREAK_STMT and CONTINUE_STMT. (cxx_eval_loop_expr): Add support for FOR_STMT, WHILE_STMT and DO_STMT. (cxx_eval_switch_expr): Add support for SWITCH_STMT. (cxx_eval_constant_expression): Handle IF_STMT, FOR_STMT, WHILE_STMT, DO_STMT, CONTINUE_STMT, SWITCH_STMT, BREAK_STMT and CONTINUE_STMT. For SIZEOF_EXPR, recurse on the result of fold_sizeof_expr. Ignore DECL_EXPR with USING_DECL operand. * lambda.c (maybe_add_lambda_conv_op): Build thisarg using build_int_cst to make it a valid constant expression. * g++.dg/ubsan/vptr-4.C: Expect reinterpret_cast errors. * g++.dg/cpp1y/constexpr-84192.C (f2): Adjust expected diagnostics. * g++.dg/cpp1y/constexpr-70265-2.C (foo): Adjust expected line of diagnostics. * g++.dg/cpp1y/constexpr-89285.C: New test. * g++.dg/cpp0x/constexpr-arith-overflow.C (add, sub, mul): Ifdef out for C++11. (TEST_ADD, TEST_SUB, TEST_MUL): Define to Assert (true) for C++11. * g++.dg/cpp0x/constexpr-arith-overflow2.C: New test. From-SVN: r269078 We should add the testcase before closing the bug.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #7 from Andrew Pinski ---
(In reply to cqwrteur from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > Reduced testcase:
> > extern void g() __attribute__((noreturn));
> >
> > void square(int t, int *tt)
> > {
> > if (t == 0) g();
> > tt[0] = 0;
> > if (t == 1) g();
> > tt[1] = 0;
> > if (t == 2) g();
> > tt[2] = 0;
> > if (t == 3) g();
> > tt[3] = 0;
> > if (t == 4) g();
> > tt[4] = 0;
> > }
>
> I think the reduced testcase should be
>
> extern void g() __attribute__((noreturn));
>
> void square(unsigned t, int *tt)
> {
> if (t<=0) g();
> tt[0] = 0;
> if (t<=1) g();
> tt[1] = 0;
> if (t<=2) g();
> tt[2] = 0;
> if (t<=3) g();
> tt[3] = 0;
> if (t<=4) g();
> tt[4] = 0;
> }
Yes obvious t should be unsigned. But the <= will become == due to VRP
figuring that out :). So it is either way.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #6 from cqwrteur ---
(In reply to Andrew Pinski from comment #4)
> Reduced testcase:
> extern void g() __attribute__((noreturn));
>
> void square(int t, int *tt)
> {
> if (t == 0) g();
> tt[0] = 0;
> if (t == 1) g();
> tt[1] = 0;
> if (t == 2) g();
> tt[2] = 0;
> if (t == 3) g();
> tt[3] = 0;
> if (t == 4) g();
> tt[4] = 0;
> }
I think the reduced testcase should be
extern void g() __attribute__((noreturn));
void square(unsigned t, int *tt)
{
if (t<=0) g();
tt[0] = 0;
if (t<=1) g();
tt[1] = 0;
if (t<=2) g();
tt[2] = 0;
if (t<=3) g();
tt[3] = 0;
if (t<=4) g();
tt[4] = 0;
}
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 --- Comment #5 from Andrew Pinski --- (In reply to cqwrteur from comment #2) > The --enable-libstdcxx-verbose has side effects, not optimizing to > vectorization code is correct, although Those can be merged still since the arguments to __replacement_assert are all the same, you can change my reduced testcase to do something similar as __replacement_assert really. The problem is the merging of the if don't happen if there is an statement inbetween.
[Bug analyzer/95006] RFE: Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed on trunk for gcc 12 by the above patch.
[Bug analyzer/95006] RFE: Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 Bug 95006 depends on bug 94714, which changed state. Bug 94714 Summary: Analyzer: no warning on access of an uninitialized variable of automatic storage duration https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/94714] Analyzer: no warning on access of an uninitialized variable of automatic storage duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed on trunk for gcc 12 by the above patch.
[Bug analyzer/95006] RFE: Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 Bug 95006 depends on bug 94713, which changed state. Bug 94713 Summary: Analyzer is buggy on uninitialized pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/94713] Analyzer is buggy on uninitialized pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed on trunk for gcc 12 by the above patch.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-07-15
Status|UNCONFIRMED |NEW
Severity|normal |enhancement
Keywords||missed-optimization
Summary|Optimizers should fold |Optimizers should fold
|bounds checking for |bounds checking for
|-D_GLIBCXX_ASSERTIONS=1 + |-D_GLIBCXX_ASSERTIONS=1
|--disable-libstdcxx-verbose |
Ever confirmed|0 |1
--- Comment #4 from Andrew Pinski ---
Reduced testcase:
extern void g() __attribute__((noreturn));
void square(int t, int *tt)
{
if (t == 0) g();
tt[0] = 0;
if (t == 1) g();
tt[1] = 0;
if (t == 2) g();
tt[2] = 0;
if (t == 3) g();
tt[3] = 0;
if (t == 4) g();
tt[4] = 0;
}
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1 + --disable-libstdcxx-verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 --- Comment #3 from cqwrteur --- > > However, the __builtin_abort() case can be merged together without any issue > I believe. And optimize to vectorized code.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1 + --disable-libstdcxx-verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 --- Comment #2 from cqwrteur --- The --enable-libstdcxx-verbose has side effects, not optimizing to vectorization code is correct, although .L12: mov ecx, OFFSET FLAT:.LC1 mov edx, OFFSET FLAT:.LC2 mov esi, 276 mov edi, OFFSET FLAT:.LC3 callstd::__replacement_assert(char const*, int, char const*, char const*) .L13: mov ecx, OFFSET FLAT:.LC1 mov edx, OFFSET FLAT:.LC2 mov esi, 276 mov edi, OFFSET FLAT:.LC3 callstd::__replacement_assert(char const*, int, char const*, char const*) may be merged. However, the __builtin_abort() case can be merged together without any issue I believe.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 --- Comment #1 from cqwrteur --- Created attachment 51158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51158&action=edit this is the assembly generated from --disable-libstdcxx-verbose The bounds checking is still not folding together, even with this naive case.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 97027, which changed state. Bug 97027 Summary: missing warning on buffer overflow storing a larger scalar into a smaller array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Sebor --- With r12-2338 Wstringop-overflow-47.c passes on aarch64, arm, as well as x86_64, so this can now be fully resolved.
[Bug tree-optimization/101466] New: Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 Bug ID: 101466 Summary: Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- https://godbolt.org/z/fPdGeKMYM Should fold together and optimize to something like this https://godbolt.org/z/6cooP81xc
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:f0500db3692276f60e0562c17c87a0cb03e34398 commit r12-2338-gf0500db3692276f60e0562c17c87a0cb03e34398 Author: Martin Sebor Date: Thu Jul 15 13:15:03 2021 -0600 Detect buffer overflow by aggregate and vector stores [PR97027]. Resolves: PR middle-end/97027 - missing warning on buffer overflow storing a larger scalar into a smaller array gcc/ChangeLog: PR middle-end/97027 * tree-ssa-strlen.c (handle_assign): New function. (maybe_warn_overflow): Add argument. (nonzero_bytes_for_type): New function. (count_nonzero_bytes): Handle more tree types. Call nonzero_bytes_for_tye. (count_nonzero_bytes): Handle types. (handle_store): Handle stores from function calls. (strlen_check_and_optimize_call): Move code to handle_assign. Call it for assignments from function calls. gcc/testsuite/ChangeLog: PR middle-end/97027 * gcc.dg/Wstringop-overflow-15.c: Remove an xfail. * gcc.dg/Wstringop-overflow-47.c: Adjust xfails. * gcc.dg/torture/pr69170.c: Avoid valid warnings. * gcc.dg/torture/pr70025.c: Prune out a false positive. * gcc.dg/vect/pr97769.c: Initialize a loop control variable. * gcc.target/i386/pr92658-avx512bw-trunc.c: Increase buffer size to avoid overflow. * gcc.target/i386/pr92658-avx512f.c: Same. * gcc.dg/Wstringop-overflow-68.c: New test. * gcc.dg/Wstringop-overflow-69.c: New test. * gcc.dg/Wstringop-overflow-70.c: New test. * gcc.dg/Wstringop-overflow-71.c: New test. * gcc.dg/strlenopt-95.c: New test.
[Bug analyzer/94714] Analyzer: no warning on access of an uninitialized variable of automatic storage duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:33255ad3ac14e3953750fe0f2d82b901c2852ff6 commit r12-2337-g33255ad3ac14e3953750fe0f2d82b901c2852ff6 Author: David Malcolm Date: Thu Jul 15 15:07:07 2021 -0400 analyzer: reimplement -Wanalyzer-use-of-uninitialized-value [PR95006 et al] The initial gcc 10 era commit of the analyzer (in 757bf1dff5e8cee34c0a75d06140ca972bfecfa7) had an implementation of -Wanalyzer-use-of-uninitialized-value, but was sufficiently buggy that I removed it in 78b9783774bfd3540f38f5b1e3c7fc9f719653d7 before the release of gcc 10.1 This patch reintroduces the warning, heavily rewritten, with (I hope) a less buggy implementation this time, for GCC 12. gcc/analyzer/ChangeLog: PR analyzer/95006 PR analyzer/94713 PR analyzer/94714 * analyzer.cc (maybe_reconstruct_from_def_stmt): Split out GIMPLE_ASSIGN case into... (get_diagnostic_tree_for_gassign_1): New. (get_diagnostic_tree_for_gassign): New. * analyzer.h (get_diagnostic_tree_for_gassign): New decl. * analyzer.opt (Wanalyzer-write-to-string-literal): New. * constraint-manager.cc (class svalue_purger): New. (constraint_manager::purge_state_involving): New. * constraint-manager.h (constraint_manager::purge_state_involving): New. * diagnostic-manager.cc (saved_diagnostic::supercedes_p): New. (dedupe_winners::handle_interactions): New. (diagnostic_manager::emit_saved_diagnostics): Call it. * diagnostic-manager.h (saved_diagnostic::supercedes_p): New decl. * engine.cc (impl_region_model_context::warn): Convert return type to bool. Return false if the diagnostic isn't saved. (impl_region_model_context::purge_state_involving): New. (impl_sm_context::get_state): Use NULL ctxt when querying old rvalue. (impl_sm_context::set_next_state): Use new sval when querying old state. (class dump_path_diagnostic): Move to region-model.cc (exploded_node::on_stmt): Move to on_stmt_pre and on_stmt_post. Remove call to purge_state_involving. (exploded_node::on_stmt_pre): New, based on the above. Move most of it to region_model::on_stmt_pre. (exploded_node::on_stmt_post): Likewise, moving to region_model::on_stmt_post. (class stale_jmp_buf): Fix parent class to use curiously recurring template pattern. (feasibility_state::maybe_update_for_edge): Call on_call_pre and on_call_post on gcalls. * exploded-graph.h (impl_region_model_context::warn): Return bool. (impl_region_model_context::purge_state_involving): New decl. (exploded_node::on_stmt_pre): New decl. (exploded_node::on_stmt_post): New decl. * pending-diagnostic.h (pending_diagnostic::use_of_uninit_p): New. (pending_diagnostic::supercedes_p): New. * program-state.cc (sm_state_map::get_state): Inherit state for conjured_svalue as well as initial_svalue. (sm_state_map::purge_state_involving): Also support SK_CONJURED. * region-model-impl-calls.cc (call_details::get_uncertainty): Handle m_ctxt being NULL. (call_details::get_or_create_conjured_svalue): New. (region_model::impl_call_fgets): New. (region_model::impl_call_fread): New. * region-model-manager.cc (region_model_manager::get_or_create_initial_value): Return an uninitialized poisoned value for regions that can't have initial values. * region-model-reachability.cc (reachable_regions::mark_escaped_clusters): Handle ctxt being NULL. * region-model.cc (region_to_value_map::purge_state_involving): New. (poisoned_value_diagnostic::use_of_uninit_p): New. (poisoned_value_diagnostic::emit): Handle POISON_KIND_UNINIT. (poisoned_value_diagnostic::describe_final_event): Likewise. (region_model::check_for_poison): New. (region_model::on_assignment): Call it. (class dump_path_diagnostic): Move here from engine.cc. (region_model::on_stmt_pre): New, based on exploded_node::on_stmt. (region_model::on_call_pre): Move the setting of the LHS to a conjured svalue to before the checks for specific functions. Handle "fgets", "fgets_unlocked", and "fread". (region_model::purge_state_involving): New. (region_model::handle_unrecognized_call): Handle ctxt being NULL. (region_model::get_rvalue): C
[Bug analyzer/95006] RFE: Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:33255ad3ac14e3953750fe0f2d82b901c2852ff6 commit r12-2337-g33255ad3ac14e3953750fe0f2d82b901c2852ff6 Author: David Malcolm Date: Thu Jul 15 15:07:07 2021 -0400 analyzer: reimplement -Wanalyzer-use-of-uninitialized-value [PR95006 et al] The initial gcc 10 era commit of the analyzer (in 757bf1dff5e8cee34c0a75d06140ca972bfecfa7) had an implementation of -Wanalyzer-use-of-uninitialized-value, but was sufficiently buggy that I removed it in 78b9783774bfd3540f38f5b1e3c7fc9f719653d7 before the release of gcc 10.1 This patch reintroduces the warning, heavily rewritten, with (I hope) a less buggy implementation this time, for GCC 12. gcc/analyzer/ChangeLog: PR analyzer/95006 PR analyzer/94713 PR analyzer/94714 * analyzer.cc (maybe_reconstruct_from_def_stmt): Split out GIMPLE_ASSIGN case into... (get_diagnostic_tree_for_gassign_1): New. (get_diagnostic_tree_for_gassign): New. * analyzer.h (get_diagnostic_tree_for_gassign): New decl. * analyzer.opt (Wanalyzer-write-to-string-literal): New. * constraint-manager.cc (class svalue_purger): New. (constraint_manager::purge_state_involving): New. * constraint-manager.h (constraint_manager::purge_state_involving): New. * diagnostic-manager.cc (saved_diagnostic::supercedes_p): New. (dedupe_winners::handle_interactions): New. (diagnostic_manager::emit_saved_diagnostics): Call it. * diagnostic-manager.h (saved_diagnostic::supercedes_p): New decl. * engine.cc (impl_region_model_context::warn): Convert return type to bool. Return false if the diagnostic isn't saved. (impl_region_model_context::purge_state_involving): New. (impl_sm_context::get_state): Use NULL ctxt when querying old rvalue. (impl_sm_context::set_next_state): Use new sval when querying old state. (class dump_path_diagnostic): Move to region-model.cc (exploded_node::on_stmt): Move to on_stmt_pre and on_stmt_post. Remove call to purge_state_involving. (exploded_node::on_stmt_pre): New, based on the above. Move most of it to region_model::on_stmt_pre. (exploded_node::on_stmt_post): Likewise, moving to region_model::on_stmt_post. (class stale_jmp_buf): Fix parent class to use curiously recurring template pattern. (feasibility_state::maybe_update_for_edge): Call on_call_pre and on_call_post on gcalls. * exploded-graph.h (impl_region_model_context::warn): Return bool. (impl_region_model_context::purge_state_involving): New decl. (exploded_node::on_stmt_pre): New decl. (exploded_node::on_stmt_post): New decl. * pending-diagnostic.h (pending_diagnostic::use_of_uninit_p): New. (pending_diagnostic::supercedes_p): New. * program-state.cc (sm_state_map::get_state): Inherit state for conjured_svalue as well as initial_svalue. (sm_state_map::purge_state_involving): Also support SK_CONJURED. * region-model-impl-calls.cc (call_details::get_uncertainty): Handle m_ctxt being NULL. (call_details::get_or_create_conjured_svalue): New. (region_model::impl_call_fgets): New. (region_model::impl_call_fread): New. * region-model-manager.cc (region_model_manager::get_or_create_initial_value): Return an uninitialized poisoned value for regions that can't have initial values. * region-model-reachability.cc (reachable_regions::mark_escaped_clusters): Handle ctxt being NULL. * region-model.cc (region_to_value_map::purge_state_involving): New. (poisoned_value_diagnostic::use_of_uninit_p): New. (poisoned_value_diagnostic::emit): Handle POISON_KIND_UNINIT. (poisoned_value_diagnostic::describe_final_event): Likewise. (region_model::check_for_poison): New. (region_model::on_assignment): Call it. (class dump_path_diagnostic): Move here from engine.cc. (region_model::on_stmt_pre): New, based on exploded_node::on_stmt. (region_model::on_call_pre): Move the setting of the LHS to a conjured svalue to before the checks for specific functions. Handle "fgets", "fgets_unlocked", and "fread". (region_model::purge_state_involving): New. (region_model::handle_unrecognized_call): Handle ctxt being NULL. (region_model::get_rvalue): C
[Bug analyzer/94713] Analyzer is buggy on uninitialized pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:33255ad3ac14e3953750fe0f2d82b901c2852ff6 commit r12-2337-g33255ad3ac14e3953750fe0f2d82b901c2852ff6 Author: David Malcolm Date: Thu Jul 15 15:07:07 2021 -0400 analyzer: reimplement -Wanalyzer-use-of-uninitialized-value [PR95006 et al] The initial gcc 10 era commit of the analyzer (in 757bf1dff5e8cee34c0a75d06140ca972bfecfa7) had an implementation of -Wanalyzer-use-of-uninitialized-value, but was sufficiently buggy that I removed it in 78b9783774bfd3540f38f5b1e3c7fc9f719653d7 before the release of gcc 10.1 This patch reintroduces the warning, heavily rewritten, with (I hope) a less buggy implementation this time, for GCC 12. gcc/analyzer/ChangeLog: PR analyzer/95006 PR analyzer/94713 PR analyzer/94714 * analyzer.cc (maybe_reconstruct_from_def_stmt): Split out GIMPLE_ASSIGN case into... (get_diagnostic_tree_for_gassign_1): New. (get_diagnostic_tree_for_gassign): New. * analyzer.h (get_diagnostic_tree_for_gassign): New decl. * analyzer.opt (Wanalyzer-write-to-string-literal): New. * constraint-manager.cc (class svalue_purger): New. (constraint_manager::purge_state_involving): New. * constraint-manager.h (constraint_manager::purge_state_involving): New. * diagnostic-manager.cc (saved_diagnostic::supercedes_p): New. (dedupe_winners::handle_interactions): New. (diagnostic_manager::emit_saved_diagnostics): Call it. * diagnostic-manager.h (saved_diagnostic::supercedes_p): New decl. * engine.cc (impl_region_model_context::warn): Convert return type to bool. Return false if the diagnostic isn't saved. (impl_region_model_context::purge_state_involving): New. (impl_sm_context::get_state): Use NULL ctxt when querying old rvalue. (impl_sm_context::set_next_state): Use new sval when querying old state. (class dump_path_diagnostic): Move to region-model.cc (exploded_node::on_stmt): Move to on_stmt_pre and on_stmt_post. Remove call to purge_state_involving. (exploded_node::on_stmt_pre): New, based on the above. Move most of it to region_model::on_stmt_pre. (exploded_node::on_stmt_post): Likewise, moving to region_model::on_stmt_post. (class stale_jmp_buf): Fix parent class to use curiously recurring template pattern. (feasibility_state::maybe_update_for_edge): Call on_call_pre and on_call_post on gcalls. * exploded-graph.h (impl_region_model_context::warn): Return bool. (impl_region_model_context::purge_state_involving): New decl. (exploded_node::on_stmt_pre): New decl. (exploded_node::on_stmt_post): New decl. * pending-diagnostic.h (pending_diagnostic::use_of_uninit_p): New. (pending_diagnostic::supercedes_p): New. * program-state.cc (sm_state_map::get_state): Inherit state for conjured_svalue as well as initial_svalue. (sm_state_map::purge_state_involving): Also support SK_CONJURED. * region-model-impl-calls.cc (call_details::get_uncertainty): Handle m_ctxt being NULL. (call_details::get_or_create_conjured_svalue): New. (region_model::impl_call_fgets): New. (region_model::impl_call_fread): New. * region-model-manager.cc (region_model_manager::get_or_create_initial_value): Return an uninitialized poisoned value for regions that can't have initial values. * region-model-reachability.cc (reachable_regions::mark_escaped_clusters): Handle ctxt being NULL. * region-model.cc (region_to_value_map::purge_state_involving): New. (poisoned_value_diagnostic::use_of_uninit_p): New. (poisoned_value_diagnostic::emit): Handle POISON_KIND_UNINIT. (poisoned_value_diagnostic::describe_final_event): Likewise. (region_model::check_for_poison): New. (region_model::on_assignment): Call it. (class dump_path_diagnostic): Move here from engine.cc. (region_model::on_stmt_pre): New, based on exploded_node::on_stmt. (region_model::on_call_pre): Move the setting of the LHS to a conjured svalue to before the checks for specific functions. Handle "fgets", "fgets_unlocked", and "fread". (region_model::purge_state_involving): New. (region_model::handle_unrecognized_call): Handle ctxt being NULL. (region_model::get_rvalue): C
[Bug c++/101465] New: Poorly worded error from a call to a pointer-to-member function not wrapped in parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101465
Bug ID: 101465
Summary: Poorly worded error from a call to a pointer-to-member
function not wrapped in parentheses
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: josephcsible at gmail dot com
Target Milestone: ---
Consider this C++ code:
struct foo *x;
void (foo::*myfuncptr)();
void f() {
x->*myfuncptr();
}
This fails to compile, as it should. The problem is that the error I get says I
"must use '.*' or '->*' to call pointer-to-member function", even though I'm
already using '->*'. The actual change I need to make is to add parentheses,
like this: "(x->*myfuncptr)();" We should make the error say this instead.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #243 from The Written Word --- (In reply to John Buddery from comment #238) > It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and > later require a 64 bit build for 64 bit objects to work reliably. I can build up to and including 2.32 with the HP C compiler. Starting with 2.33.1, they add -std=gnu99. Might be possible to fix this but I might retry with 2.32.
[Bug target/101464] New: Replace zveroupper with vpxor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101464
Bug ID: 101464
Summary: Replace zveroupper with vpxor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: i386, x86-64
[hjl@gnu-cfl-2 pr101456]$ cat y.c
#include
extern __m256d x, y;
void
foo (void)
{
x = y;
}
[hjl@gnu-cfl-2 pr101456]$ gcc -S -O2 -mavx2 y.c
[hjl@gnu-cfl-2 pr101456]$ cat y.s
.file "y.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB5667:
.cfi_startproc
vmovapd y(%rip), %ymm0
vmovapd %ymm0, x(%rip)
vzeroupper
ret
.cfi_endproc
.LFE5667:
.size foo, .-foo
.ident "GCC: (GNU) 11.1.1 20210531 (Red Hat 11.1.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 pr101456]$
vzeroupper can be replaced by a single pxor.
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 --- Comment #6 from Richard Earnshaw --- (In reply to Kevin Zhao from comment #5) > Hi Richard, > > Thanks for your info. > Previously it is built without any -O parameters, so it should be -O0 by > default. > > I've tried to use the "-Og" to link, it is quite interesting that use -Og we > can link success > > Also, use -O1, -O2 and -Os, Linking works quite well. -O0 generates *very* poor (and large) code. I wouldn't recommend using at all except for basic syntax checking of your application. -Og is pretty minimal optimization and should still be suitable for debugging an application if needed. So I think this is simply a case of you exceeded the limits of the system.
[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.4 --- Comment #22 from H.J. Lu --- Fix for GCC 10 and GCC 9.4.
[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667 H.J. Lu changed: What|Removed |Added Target Milestone|--- |11.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from H.J. Lu --- Fixed for GCC 11.
[Bug c++/101443] [9/10/11 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |internal compiler error: in |internal compiler error: in |wide_int_to_tree_1, at |wide_int_to_tree_1, at |tree.c:1519 |tree.c:1519 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far. The accepts-invalid case is already tracked in PR99701
[Bug c++/101443] [9/10/11/12 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7094a69bd62a14dfa311eaa2fea468f221c7c9f3
commit r12-2331-g7094a69bd62a14dfa311eaa2fea468f221c7c9f3
Author: Jakub Jelinek
Date: Thu Jul 15 18:53:20 2021 +0200
c++: Optimize away NULLPTR_TYPE comparisons [PR101443]
Comparisons of NULLPTR_TYPE operands cause all kinds of problems in the
middle-end and in fold-const.c, various optimizations assume that if they
see e.g. a non-equality comparison with one of the operands being
INTEGER_CST and it is not INTEGRAL_TYPE_P (which has TYPE_{MIN,MAX}_VALUE),
they can build_int_cst (type, 1) to find a successor.
The following patch fixes it by making sure they don't appear in the IL,
optimize them away at cp_fold time as all can be folded.
Though, I've just noticed that clang++ rejects the non-equality comparisons
instead, foo () > 0 with
invalid operands to binary expression ('decltype(nullptr)' (aka
'nullptr_t') and 'int')
and foo () > nullptr with
invalid operands to binary expression ('decltype(nullptr)' (aka
'nullptr_t') and 'nullptr_t')
Shall we reject those too, in addition or instead of parts of this patch?
If so, wouldn't this patch be still useful for backports, I bet we don't
want to start reject it on the release branches when we used to accept it.
2021-07-15 Jakub Jelinek
PR c++/101443
* cp-gimplify.c (cp_fold): For comparisons with NULLPTR_TYPE
operands, fold them right away to true or false.
* g++.dg/cpp0x/nullptr46.C: New test.
[Bug middle-end/101457] [12 regression] new test cases in r12-2300 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tamar Christina --- Should be fixed now.
[Bug middle-end/101457] [12 regression] new test cases in r12-2300 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457 --- Comment #2 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:b25edf6e6feeadc6a5aa337b8c725786227162dd commit r12-2330-gb25edf6e6feeadc6a5aa337b8c725786227162dd Author: Tamar Christina Date: Thu Jul 15 17:42:10 2021 +0100 testsuite: Fix testisms in scalar tests PR101457 These testcases accidentally contain the wrong signs for the expected values for the scalar code. The vector code however is correct. Committed as a trivial fix. gcc/testsuite/ChangeLog: PR middle-end/101457 * gcc.dg/vect/vect-reduc-dot-17.c: Fix signs of scalar code. * gcc.dg/vect/vect-reduc-dot-18.c: Likewise. * gcc.dg/vect/vect-reduc-dot-22.c: Likewise. * gcc.dg/vect/vect-reduc-dot-9.c: Likewise.
[Bug c/97548] bogus -Wvla-parameter on a bound expression involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548 --- Comment #4 from Martin Sebor --- Fixed for GCC 12.0.
[Bug c/101289] bogus -Wvla-paramater warning when using const for vla param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101289 Martin Sebor changed: What|Removed |Added Known to fail|12.0| --- Comment #4 from Martin Sebor --- Fixed for GCC 12.0.
[Bug c/101289] bogus -Wvla-paramater warning when using const for vla param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101289 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:98f1f9f38c45218c06200feb1939c9433a2ab6ca commit r12-2329-g98f1f9f38c45218c06200feb1939c9433a2ab6ca Author: Martin Sebor Date: Thu Jul 15 10:11:23 2021 -0600 Avoid -Wvla-parameter for nontrivial bounds [PR97548]. Resolves: PR c/101289 - bogus -Wvla-paramater warning when using const for vla param PR c/97548 - bogus -Wvla-parameter on a bound expression involving a parameter gcc/c-family/ChangeLog: PR c/101289 PR c/97548 * c-warn.c (warn_parm_array_mismatch): Use OEP_DECL_NAME. gcc/c/ChangeLog: PR c/101289 PR c/97548 * c-decl.c (get_parm_array_spec): Strip nops. gcc/ChangeLog: PR c/101289 PR c/97548 * fold-const.c (operand_compare::operand_equal_p): Handle OEP_DECL_NAME. (operand_compare::verify_hash_value): Same. * tree-core.h (OEP_DECL_NAME): New. gcc/testsuite/ChangeLog: * gcc.dg/Wvla-parameter-12.c: New test.
[Bug c/97548] bogus -Wvla-parameter on a bound expression involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:98f1f9f38c45218c06200feb1939c9433a2ab6ca commit r12-2329-g98f1f9f38c45218c06200feb1939c9433a2ab6ca Author: Martin Sebor Date: Thu Jul 15 10:11:23 2021 -0600 Avoid -Wvla-parameter for nontrivial bounds [PR97548]. Resolves: PR c/101289 - bogus -Wvla-paramater warning when using const for vla param PR c/97548 - bogus -Wvla-parameter on a bound expression involving a parameter gcc/c-family/ChangeLog: PR c/101289 PR c/97548 * c-warn.c (warn_parm_array_mismatch): Use OEP_DECL_NAME. gcc/c/ChangeLog: PR c/101289 PR c/97548 * c-decl.c (get_parm_array_spec): Strip nops. gcc/ChangeLog: PR c/101289 PR c/97548 * fold-const.c (operand_compare::operand_equal_p): Handle OEP_DECL_NAME. (operand_compare::verify_hash_value): Same. * tree-core.h (OEP_DECL_NAME): New. gcc/testsuite/ChangeLog: * gcc.dg/Wvla-parameter-12.c: New test.
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 --- Comment #6 from Jonathan Wakely --- (In reply to Patrick Palka from comment #5) > but one needs to include > as well (for pmr::polymorphic_allocator). For libstdc++ the header only declares the pmr::vector alias, without defining prm::polymorphic_allocator. That means pmr::vector is an incomplete type unless you also include . This is permitted by the standard, and avoids paying to include if you don't plan to use the pmr types.
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233
--- Comment #5 from Patrick Palka ---
Looks like the original testcase is indeed valid, but one needs to include
as well (for pmr::polymorphic_allocator).
Reduced:
template
struct A { A(T, U); };
template
using B = A;
using type = decltype(B{0, 0});
[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100949 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:ba66193c2966ff7106245e23d6b359f7d30bcff7 commit r11-8756-gba66193c2966ff7106245e23d6b359f7d30bcff7 Author: Harald Anlauf Date: Wed Jul 14 17:25:29 2021 +0200 Fortran - ICE in gfc_conv_expr_present initializing non-dummy class variable gcc/fortran/ChangeLog: PR fortran/100949 * trans-expr.c (gfc_trans_class_init_assign): Call gfc_conv_expr_present only for dummy variables. gcc/testsuite/ChangeLog: PR fortran/100949 * gfortran.dg/pr100949.f90: New test. (cherry picked from commit 269ca408e2839d7f3554a91515d73d4d95352f68)
[Bug libstdc++/101307] Variable templates for type traits—corrections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101307 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-07-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- (In reply to Christopher Yeleighton from comment #0) > 2. The general description (is_foovalue) should be (is_foo ::value) This is another doxygen bug, the :: is present in the source.
[Bug c++/101463] New: Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101463
Bug ID: 101463
Summary: Using a constexpr variable template specialization as
default argument for non-type template parameter of
reference type leads gcc to reject function call
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
The following code will reproduce the issue:
extern const int a;
template
constexpr const int& blub = a;
template >
void f() {}
int main()
{
f(); // error: no matching function for call to
'f()'
f>(); // ok
}
Note: gcc will accept the function call when the exact same template argument
is explicitly specified instead.
godbolt link: https://godbolt.org/z/jd3EGWEfo
[Bug libstdc++/101427] [11 Regression] std::get should refuse to compile if type is provided and it is duplicated in std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101427 Jonathan Wakely changed: What|Removed |Added Summary|[11/12 Regression] std::get |[11 Regression] std::get |should refuse to compile if |should refuse to compile if |type is provided and it is |type is provided and it is |duplicated in std::tuple|duplicated in std::tuple --- Comment #3 from Jonathan Wakely --- Fixed on trunk for now.
[Bug libstdc++/101429] __replacement_assert should be marked as noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101429 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed on trunk. I've just notice the changelog is wrong, as I used __builtin_abort not __builtin_trap.
[Bug libstdc++/101427] [11/12 Regression] std::get should refuse to compile if type is provided and it is duplicated in std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101427 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:17855eed7fc76b2cee7fbbc26f84d3c8b99be13c commit r12-2327-g17855eed7fc76b2cee7fbbc26f84d3c8b99be13c Author: Jonathan Wakely Date: Wed Jul 14 20:14:14 2021 +0100 libstdc++: Fix std::get for std::tuple [PR101427] The std::get functions relied on deduction failing if more than one base class existed for the type T. However the implementation of Core DR 2303 (in r11-4693) made deduction succeed (and select the more-derived base class). This rewrites the implementation of std::get to explicitly check for more than one occurrence of T in the tuple elements, making it ill-formed again. Additionally, the large wall of overload resolution errors described in PR c++/101460 is avoided by making std::get use __get_helper directly instead of calling std::get, and by adding a deleted overload of __get_helper for out-of-range N. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101427 * include/std/tuple (tuple_element): Improve static_assert text. (__get_helper): Add deleted overload. (get(tuple&&), get(const tuple&&)): Use __get_helper directly. (__get_helper2): Remove. (__find_uniq_type_in_pack): New constexpr helper function. (get): Use __find_uniq_type_in_pack and __get_helper instead of __get_helper2. * testsuite/20_util/tuple/element_access/get_neg.cc: Adjust expected errors. * testsuite/20_util/tuple/element_access/101427.cc: New test.
[Bug c++/101460] Useless cascade of overload resolution errors for invalid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:17855eed7fc76b2cee7fbbc26f84d3c8b99be13c commit r12-2327-g17855eed7fc76b2cee7fbbc26f84d3c8b99be13c Author: Jonathan Wakely Date: Wed Jul 14 20:14:14 2021 +0100 libstdc++: Fix std::get for std::tuple [PR101427] The std::get functions relied on deduction failing if more than one base class existed for the type T. However the implementation of Core DR 2303 (in r11-4693) made deduction succeed (and select the more-derived base class). This rewrites the implementation of std::get to explicitly check for more than one occurrence of T in the tuple elements, making it ill-formed again. Additionally, the large wall of overload resolution errors described in PR c++/101460 is avoided by making std::get use __get_helper directly instead of calling std::get, and by adding a deleted overload of __get_helper for out-of-range N. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101427 * include/std/tuple (tuple_element): Improve static_assert text. (__get_helper): Add deleted overload. (get(tuple&&), get(const tuple&&)): Use __get_helper directly. (__get_helper2): Remove. (__find_uniq_type_in_pack): New constexpr helper function. (get): Use __find_uniq_type_in_pack and __get_helper instead of __get_helper2. * testsuite/20_util/tuple/element_access/get_neg.cc: Adjust expected errors. * testsuite/20_util/tuple/element_access/101427.cc: New test.
[Bug libstdc++/101429] __replacement_assert should be marked as noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101429 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1f7182d68c24985dace2a94422c671ff987c262c commit r12-2326-g1f7182d68c24985dace2a94422c671ff987c262c Author: Jonathan Wakely Date: Wed Jul 14 12:25:11 2021 +0100 libstdc++: Add noexcept to __replacement_assert [PR101429] This results in slightly smaller code when assertions are enabled when either using Clang (because it adds code to call std::terminate when potentially-throwing functions are called in a noexcept function) or a freestanding or non-verbose build (because it doesn't use printf). Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101429 * include/bits/c++config (__replacement_assert): Add noexcept. [!_GLIBCXX_VERBOSE] (__glibcxx_assert_impl): Use __builtin_trap instead of __replacement_assert.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #242 from dave.anglin at bell dot net --- On 2021-07-15 11:01 a.m., bugzilla-gcc at thewrittenword dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #241 from The Written Word com> --- > (In reply to John Buddery from comment #240) >> One question about PR66319 - it's marked as resolved, so is this committed >> as a patch in the trunk ? > It's resolved for HP-UX/PA but my HP-UX/IA patch was never committed. Patch for PR66319 needs submission to gcc-patches list with cc to ia64 and/or hpux maintainer. Patch must be submitted by someone with copyright assignment or DOC. See: https://gcc.gnu.org/contribute.html
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 Bill Schmidt changed: What|Removed |Added Known to fail|12.0| Known to work||12.0 --- Comment #10 from Bill Schmidt --- Fixed on trunk, but will require backports.
[Bug tree-optimization/101462] New: [12 regression] ICE on aarch64 after r12-2292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101462
Bug ID: 101462
Summary: [12 regression] ICE on aarch64 after r12-2292
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After r12-2292 we have an ICE on aarch64:
FAIL: gcc.dg/vect/pr92324-4.c (test for excess errors)
Excess errors:
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/gcc.dg/vect/pr92324-4.c:7:1:
error: incompatible types in 'PHI' argument 1
vector(2) unsigned int
vector(2) int
_91 = PHI <_90(17), _83(11)>
during GIMPLE pass: vect
dump file: ./pr92324-4.c.167t.vect
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/gcc.dg/vect/pr92324-4.c:7:1:
internal compiler error: verify_gimple failed
0x142fe6f verify_gimple_in_cfg(function*, bool)
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/tree-cfg.c:5536
0x12701fa execute_function_todo
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/passes.c:2042
0x126f132 do_per_function
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/passes.c:1687
0x12703ee execute_todo
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/passes.c:2096
gcc is configured --target=aarch64-none-linux-gnu
cc1 is invoked with:
cc1 -fpreprocessed ./pr92324-4.i -quiet -dumpdir ./ -dumpbase pr92324-4.c
-dumpbase-ext .c -mlittle-endian -mabi=lp64 -O2 -version
-fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-urls=never
-fdiagnostics-path-format=separate-events -flto -ffat-lto-objects
-ftree-vectorize -fno-tree-loop-distribute-patterns -fvect-cost-model=unlimited
-fno-common -fdump-tree-vect-details -o ./pr92324-4.s
There is another regression which does not ICE:
FAIL: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fminnmv
FAIL: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fmaxnmv
Before the patch:
maxv_f32:
.LFB0:
.cfi_startproc
ldr q1, [x0, 4]
ld1r{v3.4s}, [x0]
ldr d0, [x0, 20]
ldr s2, [x0, 28]
fmaxnm v1.4s, v1.4s, v3.4s
fmaxnmv s1, v1.4s
dup v1.2s, v1.s[0]
fmaxnm v0.2s, v0.2s, v1.2s
fmaxnmp s0, v0.2s
fmaxnm s0, s2, s0
ret
After the patch:
maxv_f32:
.LFB0:
.cfi_startproc
ldr q1, [x0, 4]
ld1r{v3.4s}, [x0]
ldr d2, [x0, 20]
ldr s0, [x0, 28]
fmaxnm v1.4s, v1.4s, v3.4s
dup d3, v1.d[1]
fmaxnm v1.2s, v1.2s, v3.2s
fmaxnm v1.2s, v1.2s, v2.2s
fmaxnmp s1, v1.2s
fmaxnm s0, s0, s1
ret
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 --- Comment #9 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0 commit r12-2325-gad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0 Author: Bill Schmidt Date: Thu Jul 15 10:16:17 2021 -0500 rs6000: Don't let swaps pass break multiply low-part (PR101129) 2021-07-15 Bill Schmidt gcc/ PR target/101129 * config/rs6000/rs6000-p8swap.c (has_part_mult): New. (rs6000_analyze_swaps): Insns containing a subreg of a mult are not swappable. gcc/testsuite/ PR target/101129 * gcc.target/powerpc/pr101129.c: New.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #241 from The Written Word --- (In reply to John Buddery from comment #240) > One question about PR66319 - it's marked as resolved, so is this committed > as a patch in the trunk ? It's resolved for HP-UX/PA but my HP-UX/IA patch was never committed.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #240 from John Buddery --- Yeah, it sure eats up the space. One question about PR66319 - it's marked as resolved, so is this committed as a patch in the trunk ? I'm hoping that eventually there will be a way to get all the edits here committed so that future versions will build out of the box.
[Bug c++/99664] Overriding virtual function with different return type (and not covariant) is allowed to compile, when it shouldn’t be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99664 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #239 from The Written Word --- (In reply to John Buddery from comment #238) > Thanks, I'll give it a go. > > It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and > later require a 64 bit build for 64 bit objects to work reliably. > > Was your 11.1 build successful ? Ran out of disk space so had to restart :(
[Bug target/101456] Unnecessary vzeroupper when upper bits of YMM registers already zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101456 H.J. Lu changed: What|Removed |Added Attachment #51153|0 |1 is obsolete|| --- Comment #4 from H.J. Lu --- Created attachment 51157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51157&action=edit A new patch
[Bug testsuite/101461] New: [12 regression] gcc.target/powerpc/fold-vec-load-builtin_vec_xl test cases fail after r12-2266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101461 Bug ID: 101461 Summary: [12 regression] gcc.target/powerpc/fold-vec-load-builtin_vec_xl test cases fail after r12-2266 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:063eba7ca73030139a3bf822ed127cf09b2fc226, r12-2266 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c scan-assembler-times \\mlxvw4x\\M|\\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 12 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-double.c scan-assembler-times \\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 6 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-float.c scan-assembler-times \\mlxvw4x\\M|\\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 6 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-int.c scan-assembler-times \\mlxvw4x\\M|\\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 12 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-longlong.c scan-assembler-times \\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 12 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-short.c scan-assembler-times \\mlxvw4x\\M|\\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 12 These failed previously on power 10 too but the patterns were changed in this revision and they still fail. commit 063eba7ca73030139a3bf822ed127cf09b2fc226 (HEAD) Author: Michael Meissner Date: Tue Jul 13 00:36:43 2021 -0400 Deal with prefixed loads/stores in tests, PR testsuite/100166
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #238 from John Buddery --- Thanks, I'll give it a go. It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and later require a 64 bit build for 64 bit objects to work reliably. Was your 11.1 build successful ?
[Bug driver/101447] Remove legacy external declarations in toplev.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101447 ashimida changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from ashimida --- Submitted at https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575252.html
[Bug demangler/100968] libiberty: stuck in infinite loop in nm-new while demangling rust symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100968 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Nick Clifton --- Created attachment 51156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51156&action=edit Proposed patch I think that this PR is a duplicate of 99935. The patch for that PR (attached here) also fixes this problem.
[Bug libstdc++/101427] [11/12 Regression] std::get should refuse to compile if type is provided and it is duplicated in std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101427 --- Comment #1 from Jonathan Wakely --- The std::get code stopped working as a result of r11-4693 which implemented a core language change: c++: DR2303, ambiguous base deduction [PR97453] When there are two possible matches and one is a base of the other, choose the derived class rather than fail. We should have had a libstdc++ test verifying the expected error, so that we'd have noticed the library regression. I will push the fix soon.
[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from H.J. Lu --- Fixed for GCC 12 and 11.2.
[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:ba3b30cf70990f4aadb393b64b76ff490bb0bd0f commit r11-8755-gba3b30cf70990f4aadb393b64b76ff490bb0bd0f Author: H.J. Lu Date: Fri Jun 11 07:31:29 2021 -0700 x86: Replace ix86_red_zone_size with ix86_red_zone_used Add red_zone_used to machine_function to track if red zone is used. When expanding function prologue, set red_zone_used to true if red zone is used. gcc/ PR target/101023 * config/i386/i386.c (ix86_expand_prologue): Set red_zone_used to true if red zone is used. (ix86_output_indirect_jmp): Replace ix86_red_zone_size with ix86_red_zone_used. * config/i386/i386.h (machine_function): Add red_zone_used. (ix86_red_zone_size): Removed. (ix86_red_zone_used): New. * config/i386/i386.md (peephole2 patterns): Replace ix86_red_zone_size with ix86_red_zone_used. gcc/testsuite/ PR target/101023 * g++.target/i386/pr101023a.C: New test. * g++.target/i386/pr101023b.C: Likewise. (cherry picked from commit 3f04e3782536ad2f9cfbb8cfe6630e9f9dd8af4c)
[Bug c++/99664] Overriding virtual function with different return type (and not covariant) is allowed to compile, when it shouldn’t be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99664 Jonathan Wakely changed: What|Removed |Added CC||xmh970252187 at gmail dot com --- Comment #3 from Jonathan Wakely --- *** Bug 101458 has been marked as a duplicate of this bug. ***
[Bug c++/101458] An invalid covaraint return type is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101458 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 99664 ***
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from H.J. Lu --- Fixed for GCC 12 and 11.2.
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:a0128f11e9dadc3cc3ed0ad0edb36593b16f72e8 commit r11-8754-ga0128f11e9dadc3cc3ed0ad0edb36593b16f72e8 Author: H.J. Lu Date: Fri Jul 9 09:16:01 2021 -0700 x86: Don't enable UINTR in 32-bit mode UINTR is available only in 64-bit mode. Since the codegen target is unknown when the the gcc driver is processing -march=native, to properly handle UINTR for -march=native: 1. Pass "arch [32|64]" and "tune [32|64]" to host_detect_local_cpu to indicate 32-bit and 64-bit codegen. 2. Change ix86_option_override_internal to enable UINTR only in 64-bit mode for -march=CPU when PTA_CPU includes PTA_UINTR. gcc/ PR target/101395 * config/i386/driver-i386.c (host_detect_local_cpu): Check "arch [32|64]" and "tune [32|64]" for 32-bit and 64-bit codegen. Enable UINTR only for 64-bit codegen. * config/i386/i386-options.c (ix86_option_override_internal::DEF_PTA): Skip PTA_UINTR if not in 64-bit mode. * config/i386/i386.h (ARCH_ARG): New. (CC1_CPU_SPEC): Pass "[arch|tune] 32" for 32-bit codegen and "[arch|tune] 64" for 64-bit codegen. gcc/testsuite/ PR target/101395 * gcc.target/i386/pr101395-1.c: New test. * gcc.target/i386/pr101395-2.c: Likewise. * gcc.target/i386/pr101395-3.c: Likewise. (cherry picked from commit cc11b924bfe7752edbba052ca71653f46a60887a)
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #237 from The Written Word --- (In reply to John Buddery from comment #228) > gcov-tool.c avoids build errors from ftwbuf differences on HP, apply if you > hit errors but may need tidying up. Instead of this patch, try the patch for PR66319 instead.
[Bug c++/101460] Useless cascade of overload resolution errors for invalid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460 --- Comment #2 from Jonathan Wakely --- I know that attempting to continue compiling can be very useful, so that additional errors in the code can still be diagnosed. But in this case, maybe we should mark 'n' as "tainted" so that we don't keep showing diagnostics caused by trying to use it as if it was valid.
[Bug c++/101460] Useless cascade of overload resolution errors for invalid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-07-15
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
I suppose the problem here is that the failed constant evaluation of frob<-1>()
only happens as a result of trying to use it as a template argument (where a
constant expression is required) which doesn't happen until overload resolution
is performed. So we have to at least being doing OR before we get a problem.
But maybe we can remember that it failed once, and so stop trying. If it's not
a valid constant expression, *that* is the error, not the fact that none of the
get overloads can be called with an invalid constant expression.
Even if I change the code to do this it keeps trying overload resolution for
get:
template void get_n(tuple& t) {
constexpr unsigned n = frob();
get(t);
}
The constexpr initialization of 'n' failed with a static_assert *and* a
non-constant narrowing conversion, so why do we continue and even attempt
overload resolution for 'get'?
[Bug inline-asm/101422] register variable uninitialised before passing to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101422
--- Comment #8 from Simon Willcocks ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Simon Willcocks from comment #2)
> > That's not an accurate description of the problem; the value of the variable
> > is being passed, not its address. As a register variable, it doesn't have an
> > address.
>
> It is the address of the array that is being passed (I was copying and
> pasting from another bug).
> register uint32_t *cap_and_join asm( "r5" ) = cap_and_join_style;
> Is the same as:
> register uint32_t *cap_and_join asm( "r5" ) = &cap_and_join_style[0];
>
> Because array decays to pointers :).
And, of course, I later came up against this precise problem, at least I knew
what I was looking for, and thanks to you, how to fix it. The final solution is
as follows. I really think that passing a pointer type into an asm should
indicate that the object pointed to is used, though.
void Draw_Stroke( uint32_t *path )
{
// Keep this declaration before the first register variable declaration, or
// -Os will cause the compiler to forget the preceding registers.
// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101422
uint32_t cap_and_join_style[5] = { 0x0001 }; // Round joints
register uint32_t *draw_path asm( "r0" ) = path;
register uint32_t fill_style asm( "r1" ) = 0x3f;
register uint32_t *matrix asm( "r2" ) = 0;
register uint32_t flatness asm( "r3" ) = 0;
register uint32_t thickness asm( "r4" ) = 8;
register uint32_t *cap_and_join asm( "r5" ) = cap_and_join_style;
register uint32_t dashes asm( "r6" ) = 0;
asm ( "swi 0x60704" :
: "r" (draw_path)
, "r" (fill_style)
, "r" (matrix)
, "r" (flatness)
, "r" (thickness)
, "r" (cap_and_join)
, "r" (dashes)
, "m" (cap_and_join_style) ); // Without this, array is not initialised
}
I wanted to correct the record and thank you (both). I'll shut up, now.
[Bug c++/96286] Unhelpful errors after a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96286 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > Why is the compiler even doing overload resolution for std::get if I is > an invalid constant expression?! It's not going to match any overload! This part is now PR 101460
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 --- Comment #5 from Kevin Zhao --- Hi Richard, Thanks for your info. Previously it is built without any -O parameters, so it should be -O0 by default. I've tried to use the "-Og" to link, it is quite interesting that use -Og we can link success Also, use -O1, -O2 and -Os, Linking works quite well.
[Bug c++/101460] New: Useless cascade of overload resolution errors for invalid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460
Bug ID: 101460
Summary: Useless cascade of overload resolution errors for
invalid expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template struct enable_if { };
template<> struct enable_if { using type = void; };
template
using enable_if_t = typename enable_if::type;
struct tuple { };
struct pair { };
template enable_if_t get(tuple&) { }
template enable_if_t get(const tuple&) { }
template enable_if_t get(pair&) { }
template enable_if_t get(const pair&) { }
template
constexpr unsigned
frob()
{
static_assert(N == 1, "user-friendly diagnostic");
return unsigned{N}; // narrowing check, reject negative values
}
template void get_n(tuple& t) { get()>(t); }
int main()
{
tuple t;
get_n<-1>(t);
}
This prints a wall of errors:
stupid.C: In instantiation of 'constexpr unsigned int frob() [with int N =
-1]':
stupid.C:23:51: required from 'void get_n(tuple&) [with int N = -1]'
stupid.C:28:12: required from here
stupid.C:19:19: error: static assertion failed: user-friendly diagnostic
19 | static_assert(N == 1, "user-friendly diagnostic");
| ~~^~~~
stupid.C:19:19: note: '(-1 == 1)' evaluates to false
stupid.C:20:20: error: narrowing conversion of '-1' from 'int' to 'unsigned
int' [-Wnarrowing]
20 | return unsigned{N}; // narrowing check, reject negative values
|^
stupid.C:21:1: error: body of 'constexpr' function 'constexpr unsigned int
frob() [with int N = -1]' not a return-statement
21 | }
| ^
stupid.C: In instantiation of 'void get_n(tuple&) [with int N = -1]':
stupid.C:28:12: required from here
stupid.C:23:54: error: no matching function for call to
'get()>(tuple&)'
23 | template void get_n(tuple& t) { get()>(t); }
|~~^~~
stupid.C:10:42: note: candidate: 'template enable_if_t<(N ==
1)> get(tuple&)'
10 | template enable_if_t get(tuple&) { }
| ^~~
stupid.C:10:42: note: template argument deduction/substitution failed:
stupid.C:23:51: error: 'constexpr unsigned int frob() [with int N = -1]' called
in a constant expression
23 | template void get_n(tuple& t) { get()>(t); }
|~~~^~
stupid.C:17:1: note: 'constexpr unsigned int frob() [with int N = -1]' is not
usable as a 'constexpr' function because:
17 | frob()
| ^~~~
stupid.C:23:51: note: in template argument for type 'unsigned int'
23 | template void get_n(tuple& t) { get()>(t); }
|~~~^~
stupid.C:11:42: note: candidate: 'template enable_if_t<(N ==
1)> get(const tuple&)'
11 | template enable_if_t get(const tuple&) { }
| ^~~
stupid.C:11:42: note: template argument deduction/substitution failed:
stupid.C:23:51: error: 'constexpr unsigned int frob() [with int N = -1]' called
in a constant expression
23 | template void get_n(tuple& t) { get()>(t); }
|~~~^~
stupid.C:23:51: note: in template argument for type 'unsigned int'
stupid.C:12:42: note: candidate: 'template enable_if_t<(N ==
1)> get(pair&)'
12 | template enable_if_t get(pair&) { }
| ^~~
stupid.C:12:42: note: template argument deduction/substitution failed:
stupid.C:23:51: error: 'constexpr unsigned int frob() [with int N = -1]' called
in a constant expression
23 | template void get_n(tuple& t) { get()>(t); }
|~~~^~
stupid.C:23:51: note: in template argument for type 'unsigned int'
stupid.C:13:42: note: candidate: 'template enable_if_t<(N ==
1)> get(const pair&)'
13 | template enable_if_t get(const pair&) { }
| ^~~
stupid.C:13:42: note: substitution of deduced template arguments resulted in
errors seen above
This is reduced from libstdc++ where there are more overloads of get and all
of them get tried, and all of them print exactly the same error.
Why are we even attempting overload resolution when the expression is invalid?
Is the invalid non-constant frob<-1>() call going to suddenly become valid if
we keep trying hard enough?
If PR 96286 gets fixed then the static_assert in frob should stop compilation,
but if we remove that from the code above then we'll still get a wall of
unhelpful errors. Constant evaluation of frob<-1>() failed, so stop trying to
use it as a template argument.
[Bug c++/96286] Unhelpful errors after a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96286
--- Comment #2 from Jonathan Wakely ---
It also doesn't help that the compiler thwarts my attempt to trigger errors
earlier like so:
// Return index of _Tp in _Types.
// Ill-formed if _Tp doesn't occur exactly once in _Types.
template
constexpr size_t
__find_uniq_type_in_pack()
{
constexpr ptrdiff_t __idx = std::__find_type_in_pack<_Tp, _Types...>();
static_assert(__idx >= 0,
"the type T in std::get must occur exactly once in the tuple");
return size_t{__idx};
}
The return statement *should* be an ill-formed narrowing conversion, but G++
(and Clang) think that because I'm in a system header we probably wanted to
ignore that, so we return a huge value and get 200 lines of errors again.
Maybe this will work?
{
constexpr ptrdiff_t __idx = std::__find_type_in_pack<_Tp, _Types...>();
static_assert(__idx >= 0,
"the type T in std::get must occur exactly once in the tuple");
if (__idx >= 0)
return __idx;
__builtin_unreachable();
}
No, now I get 200 lines telling me that the I in std::get is not a constant
expression because of __builtin_unreachable.
OK, let's try return enable_if_t<__idx >= 0, size_t>{__idx};
This prints "error: no type named 'type' in 'struct std::enable_if'" as
expected, but then 200 lines telling me std::get is not a constant
expression because it flows off the end of the function.
Why is the compiler even doing overload resolution for std::get if I is an
invalid constant expression?! It's not going to match any overload!
It shouldn't be this hard. Just stop compiling already.
[Bug c++/96286] Unhelpful errors after a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96286
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-07-15
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
This is a major pain the backside for trying to give good diagnostics for
std::get(tuple&). I want to stop with a "clear" static assertion
like:
In file included from
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/tuple/element_access/101427.cc:3:
/home/jwakely/gcc/12/include/c++/12.0.0/tuple: In instantiation of 'constexpr
std::size_t std::__find_uniq_type_in_pack() [with _Tp = long int; _Types =
{float, int, int}; std::size_t = long unsigned int]':
/home/jwakely/gcc/12/include/c++/12.0.0/tuple:1452:63: required from
'constexpr _Tp& std::get(std::tuple<_UTypes ...>&) [with _Tp = long int; _Types
= {float, int, int}]'
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/tuple/element_access/101427.cc:7:22:
required from here
/home/jwakely/gcc/12/include/c++/12.0.0/tuple:1441:27: error: static assertion
failed: the type T in std::get must occur exactly once in the tuple
1441 | static_assert(__idx >= 0,
| ~~^~~~
But G++ insists on continuing past that point, returning an out-of-range index
which causes 200 lines of errors because std::get(t) is invalid.
I know it's invalid, that's why I made the static assertion fail. Just stop.
I now have to jump through ridiculous hoops to add additional code to munge the
invalid value into some other value to stop the 200 lines of noise.
[Bug target/101346] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101346 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 Last reconfirmed||2021-07-15 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Uroš Bizjak --- Created attachment 51155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51155&action=edit Proposed patch ix86_hard_regno_mode_ok allows TDmode values in general registers, but 32bit targets do not support 128bit values in general registers natively. Also allow TDmode values in SSE registers.
