[Bug c++/84695] Missed opportunity to issue warning about override [-Winconsistent-missing-override]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84695 Eric Gallager changed: What|Removed |Added Summary|Missed opportunity to issue |Missed opportunity to issue |warning about override |warning about override ||[-Winconsistent-missing-ove ||rride] CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- adding suggested name for the warning to the title
[Bug target/104371] [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0xFFFF pattern to ptest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371
--- Comment #1 from Richard Biener ---
[local count: 1073741824]:
_2 = VIEW_CONVERT_EXPR<__v16qi>(x_3(D));
_6 = _2 == { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
_7 = VIEW_CONVERT_EXPR(_6);
_4 = __builtin_ia32_pmovmskb128 (_7);
_5 = _4 == 65535;
return _5;
so likely one reason is the builtin and later UNSPEC for the movemask
operation.
combine does try the following though
Trying 8, 11, 13 -> 14:
8: r92:V16QI=r89:V16QI==r96:V2DI#0
REG_DEAD r96:V2DI
REG_DEAD r89:V16QI
11: r88:SI=unspec[r92:V16QI] 44
REG_DEAD r92:V16QI
13: flags:CCZ=cmp(r88:SI,0x)
REG_DEAD r88:SI
14: r95:QI=flags:CCZ==0
REG_DEAD flags:CCZ
Failed to match this instruction:
(set (reg:QI 95)
(eq:QI (unspec:SI [
(eq:V16QI (reg:V16QI 89)
(subreg:V16QI (reg:V2DI 96) 0))
] UNSPEC_MOVMSK)
(const_int 65535 [0x])))
of course I have my doubts the pattern is a useful one to optimize.
[Bug c/103920] No warning for large structs passed by value ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103920 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=59552, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70047 CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- related to bug 59552 and/or bug 70047 perhaps?
[Bug middle-end/104092] [12 Regression] Invalid -Wdangling-pointer warning after writes by calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104092 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:5b6370295d1efaa563f6d8c45f1fb779c3db452e commit r12-7045-g5b6370295d1efaa563f6d8c45f1fb779c3db452e Author: Richard Sandiford Date: Fri Feb 4 08:08:59 2022 + aarch64: Add test for PR104092 gcc/testsuite/ PR middle-end/104092 * gcc.target/aarch64/sve/acle/general/pr104092.c: New test.
[Bug c++/104365] Overload ambiguity not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104365 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #10 from Eric Gallager --- (In reply to Jonathan Wakely from comment #8) > (In reply to Andris Pavenis from comment #6) > > 20220203-1.cpp:19:24: warning: call of overloaded 'Test(const char [4], > > unsigned > > char[4])' is ambiguous > > > "is ambiguous" is incorrect though, so it would have to be clear that there > is no ambiguity in C++ terms, just potential for confusion. maybe "could appear ambiguous to a human reader" instead?
[Bug tree-optimization/104373] [12 regression] bogus -Wmaybe-uninitialized warning with array new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104373 --- Comment #2 from Richard Biener --- When not optimizing we intentionally warn about only conditionally executed cases early - and not optimizing means we do not detect trivially unreachable paths like this. I don't know whether we have good enough infrastructure now to have a way to determine that after discovering a possible uninit but it would be possible to fix this particular instance by walking BBs in RPO order and keeping a very simple const/copy lattice to avoid traversing along unreachable edges. The non-iterative VN algorithm does this for example. In theory you could also use that, you can specify eliminate == false so it doesn't modify the IL and if you then add a callback per reachable stmt (or BB) you'd get even more fancy cases handled (at compile-time cost of course). The other early diagnostic passes might also benefit from that. Alternatively you could just initialize EDGE_EXECUTABLE/BB_REACHABLE from it before the early diagnostic passes and then rely on that during those. Note it's all non-IPA though and the early diagnostic passes should maybe run from the local optimization pipeline, before early_inline (maybe after inlining always-inline though?), so they can benefit from local IPA analysis done on called functions.
[Bug c++/104365] Overload ambiguity not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104365
--- Comment #11 from Andris Pavenis ---
OK. New version:
20220203-1.cpp: In function 'int main()':
20220203-1.cpp:19:24: warning: suspicious use of overloaded 'Test(const char
[4], const char[4])'
21 | Test test("foo", "bar");
| ^
20220203-1.cpp:12:5: note: chosen candidate: 'Test::Test(const string&, bool)'
12 | Test(const std::string&, bool)
| ^~~~
20220203-1.cpp:7:5: note: candidate: 'Test::Test(const string&, const
std::string&)'
7 | Test(const std::string&, const std::string&)
| ^~~~
[tag] [reply] [−]Comment 7
Also suggestion 'could appear ambiguous ...' instead of 'suspicious use ...' is
OK for me. I have no special preferences here.
[Bug c/82283] Wrong warning with -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #12 from rsandifo at gcc dot gnu.org
---
Here's another example, from Alexey Neyman
[https://gcc.gnu.org/pipermail/gcc-help/2022-February/141197.html]:
struct foo {
const char *a1;
const char * const *a2;
void *a3;
void *a4;
};
const char *aux[] = { "y", 0 };
struct foo a = {
.a1 = "x",
#if defined(CASE1)
.a2 = (const char * const []){ "y", 0 },
#elif defined(CASE2)
.a2 = aux,
#elif defined(CASE3)
.a2 = 0,
#elif defined(CASE4)
/* .a2 not initialized */
#elif defined(CASE5)
.a2 = (const char * const []){ "y", 0 },
.a3 = 0,
#endif
};
struct foo b = {
.a2 = (const char * const []){ "y", 0 },
.a1 = "x",
};
Only CASE1 of a warns; the others are (correctly) accepted
without warnings.
[Bug tree-optimization/104373] [12 regression] bogus -Wmaybe-uninitialized warning with array new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104373 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Created attachment 52347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52347&action=edit patch Like this, just convering uninit diagnostics and not exercising the other idea of local IPA or always-inline.
[Bug tree-optimization/104378] (N - x) ^ N should be optimized to x if x <= N (unsigned) and N is a pow2 - 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104378 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-02-04
[Bug rtl-optimization/101885] [10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101885 --- Comment #13 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:49365d511ac9b64009b1de11ef8a941f59407f67 commit r12-7046-g49365d511ac9b64009b1de11ef8a941f59407f67 Author: Roger Sayle Date: Fri Feb 4 09:32:21 2022 + [PATCH] PR rtl-optimization/101885: Prevent combine from clobbering flags This patch addresses PR rtl-optimization/101885 which is a P2 wrong code regression. In combine, if the resulting fused instruction is a parallel of two sets which fails to be recognized by the backend, combine tries to emit these as two sequential set instructions (known as split_i2i3). As each set is recognized the backend may add any necessary "clobbers". The code currently checks that any clobbers added to the first "set" don't interfere with the second set, but doesn't currently handle the case that clobbers added to the second set may interfere/kill the destination of the first set (which must be live at this point). The solution is to cut'n'paste the "clobber" logic from just a few lines earlier, suitably adjusted for the second instruction. One minor nit that may confuse a reviewer is that at this point in the code we've lost track of which set was first and which was second (combine chooses dynamically, and the recog processes that adds the clobbers may have obfuscated the original SET_DEST) so the actual test below is to confirm that any newly added clobbers (on the second set instruction) don't overlap either set0's or set1's destination. 2022-02-04 Roger Sayle gcc/ChangeLog PR rtl-optimization/101885 * combine.cc (try_combine): When splitting a parallel into two sequential sets, check not only that the first doesn't clobber the second but also that the second doesn't clobber the first. gcc/testsuite/ChangeLog PR rtl-optimization/101885 * gcc.dg/pr101885.c: New test case.
[Bug debug/104366] [12 Regression] Regression: infinite loop in add_sibling_attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104366 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Fixing.
[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #42 from Eric Botcazou --- Fixing.
[Bug middle-end/103641] [11/12 regression] Severe compile time regression in SLP vectorize step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641 --- Comment #27 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:876e70d4681332a600492173af0c7259e5a438c6 commit r12-7047-g876e70d4681332a600492173af0c7259e5a438c6 Author: Richard Biener Date: Fri Feb 4 09:26:57 2022 +0100 tree-optimization/103641 - improve vect_synth_mult_by_constant The following happens to improve compile-time of the PR103641 testcase on aarch64 significantly. I did not investigate the effect on the generated code but at least in theory choose_mult_variant should do a better job when we tell it the actual mode we are going to use for the operations it synthesizes. 2022-02-04 Richard Biener PR tree-optimization/103641 * tree-vect-patterns.cc (vect_synth_mult_by_constant): Pass the vector mode to choose_mult_variant.
[Bug middle-end/103641] [11/12 regression] Severe compile time regression in SLP vectorize step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641 --- Comment #28 from Richard Biener --- I'm not removing the regression marker yet - can ARM folks please update the trunk numbers with a fully built compiler (w/o checking)?
[Bug libstdc++/102994] std::atomic::wait is not marked const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|SUSPENDED Resolution|FIXED |--- --- Comment #13 from Jonathan Wakely --- Please don't close it. It was already explained it's suspended pending a response from the committee. Either libstdc++ will change or the standard will change, you just have to be a bit more patient.
[Bug c++/12341] Request for additional warning for variable shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12341 --- Comment #6 from Jonathan Wakely --- This inheritance case is "name hiding" and we have other requests for warnings about it. I think it should be distinct from -Wshadow.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #9 from Richard Earnshaw --- I've seen things like this with other structures passed as parameters. Part of the problem here is that the gimple expansion does not see the argument unpacking or understand how the parameters are passed; so this is only exposed after lowering to RTL and we are then reliant on the less powerful RTL optimations to get good code.
[Bug middle-end/104132] OpenACC 'kernels' decomposition: internal compiler error: verify_gimple failed, error: non-register as LHS of binary operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104132
Thomas Schwinge changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-02-04
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Schwinge ---
Even simpler:
void
f1 (void)
{
#pragma acc kernels
{
int k = -1;
#pragma acc loop
for (k = 0; k < 2; k++)
;
if (k != -1)
__builtin_abort ();
}
}
... does ICE in the very same way.
The following fix fell out of me analyzing PR102330:
--- gcc/omp-expand.cc
+++ gcc/omp-expand.cc
@@ -7776,7 +7776,9 @@ expand_oacc_for (struct omp_region *region, struct
omp_for_data *fd)
expr = build2 (plus_code, iter_type, b,
fold_convert (plus_type, offset));
- expr = force_gimple_operand_gsi (&gsi, expr, false, NULL_TREE,
+ expr = force_gimple_operand_gsi (&gsi, expr,
+ DECL_P (v) && TREE_ADDRESSABLE (v),
+ NULL_TREE,
true, GSI_SAME_STMT);
ass = gimple_build_assign (v, expr);
gsi_insert_before (&gsi, ass, GSI_SAME_STMT);
@@ -7966,7 +7968,9 @@ expand_oacc_for (struct omp_region *region, struct
omp_for_data *fd)
expr = fold_build2 (TRUNC_DIV_EXPR, diff_type, expr, s);
expr = fold_build2 (MULT_EXPR, diff_type, expr, s);
expr = build2 (plus_code, iter_type, b, fold_convert (plus_type,
expr));
- expr = force_gimple_operand_gsi (&gsi, expr, false, NULL_TREE,
+ expr = force_gimple_operand_gsi (&gsi, expr,
+ DECL_P (v) && TREE_ADDRESSABLE (v),
+ NULL_TREE,
true, GSI_SAME_STMT);
ass = gimple_build_assign (v, expr);
gsi_insert_before (&gsi, ass, GSI_SAME_STMT);
... as used in a number of other similar places (when they're not using
'expand_omp_build_assign').
That change seems correct, right? (Jakub?)
[Bug middle-end/103641] [11/12 regression] Severe compile time regression in SLP vectorize step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641 --- Comment #29 from Tamar Christina --- (In reply to Richard Biener from comment #28) > I'm not removing the regression marker yet - can ARM folks please update the > trunk numbers with a fully built compiler (w/o checking)? Sure, I'll come back on Monday when it's gathered data in the CI.
[Bug c++/56556] Wshadow warns for private members in base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56556
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|RESOLVED|NEW
Resolution|INVALID |---
Last reconfirmed||2022-02-04
Severity|normal |enhancement
Keywords||diagnostic
--- Comment #3 from Jonathan Wakely ---
The problem with -Wshadow=local is that it doesn't warn about this either:
class Derived {
int x;
Derived(int x) {}
};
And you might want a warning there, just not for the case where 'x' is a
private member in some base.
I think I agree with David that this shouldn't warn in the first place, you
shouldn't need to work around it.
I understand Andrew's explanation, but that's the reason GCC behaves like this
today, not a reason it *should* behave like this.
[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356 --- Comment #43 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:bd14cdceb9c6f4800e25a9fbca635a1d4c06fd32 commit r12-7048-gbd14cdceb9c6f4800e25a9fbca635a1d4c06fd32 Author: Eric Botcazou Date: Fri Feb 4 12:03:49 2022 +0100 Disable new 1/X optimization with -fnon-call-exceptions The trapping behavior of the operation needs to be preserved when the -fnon-call-exceptions switch is in effect. This also adds the same guards to similar optimizations. gcc/ PR tree-optimization/104356 * match.pd (X / bool_range_Y is X): Add guard. (X / X is one): Likewise. (X / abs (X) is X < 0 ? -1 : 1): Likewise. (X / -X is -1): Likewise. (1 / X -> X == 1): Likewise.
[Bug debug/104366] [12 Regression] Regression: infinite loop in add_sibling_attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104366 --- Comment #5 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:38948b77dbc16f4c6cf6cff8661bab699b306f03 commit r12-7049-g38948b77dbc16f4c6cf6cff8661bab699b306f03 Author: Eric Botcazou Date: Fri Feb 4 12:07:46 2022 +0100 Empty the base_types vector before (re)populating it Otherwise Bad Things happen when it is populated several times. gcc/ PR debug/104366 * dwarf2out.cc (dwarf2out_finish): Empty base_types. (dwarf2out_early_finish): Likewise.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #10 from Andrew Pinski --- (In reply to Richard Earnshaw from comment #9) > Part of the problem here is that the gimple expansion does not see the > argument unpacking or understand how the parameters are passed; so this is > only exposed after lowering to RTL and we are then reliant on the less > powerful RTL optimations to get good code. Right, i was thinking about how we expose so of it like having a late pass which does the splitting if it is possible. This is part of the reason why I created the meta bug to record all of these issues in one place to make it easier to start working on a pass like that (maybe for gcc 13 but I have so much stuff on my plate right now).
[Bug c++/104379] New: [p/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379
Bug ID: 104379
Summary: [p/10/11/12 Regression] -Wshadow warning given three
times
Product: gcc
Version: 11.2.1
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: ---
struct S {
int x;
S(int x) { (void)x; }
};
shad.C: In constructor 'S::S(int)':
shad.C:3:12: warning: declaration of 'x' shadows a member of 'S' [-Wshadow]
3 | S(int x) { (void)x; }
|^
shad.C:2:7: note: shadowed declaration is here
2 | int x;
| ^
shad.C: In constructor 'S::S(int)':
shad.C:3:23: warning: declaration of 'x' shadows a member of 'S' [-Wshadow]
3 | S(int x) { (void)x; }
| ^
shad.C:2:7: note: shadowed declaration is here
2 | int x;
| ^
shad.C: In constructor 'S::S(int)':
shad.C:3:23: warning: declaration of 'x' shadows a member of 'S' [-Wshadow]
3 | S(int x) { (void)x; }
| ^
shad.C:2:7: note: shadowed declaration is here
2 | int x;
| ^
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 Jonathan Wakely changed: What|Removed |Added Known to work||8.4.0 Last reconfirmed||2022-02-04 Summary|[p/10/11/12 Regression] |[9/10/11/12 Regression] |-Wshadow warning given |-Wshadow warning given |three times |three times Status|UNCONFIRMED |NEW Known to fail||10.3.0, 11.2.0, 12.0, 9.1.0 Ever confirmed|0 |1
[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147 --- Comment #6 from Jonathan Wakely --- (In reply to Tillmann Karras from comment #5) > This warning is useful, but as was pointed out in comment #2, it currently > triggers three times for each parameter. That's a separate issue, now reported as PR 104379
[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #44 from Eric Botcazou --- I'll create a separate PR for the VRP issue.
[Bug debug/104366] [12 Regression] Regression: infinite loop in add_sibling_attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104366 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Botcazou --- Thanks for reporting the problem.
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 Jonathan Wakely changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Started with r264779 c-decl.c (warn_if_shadowing): Do not test DECL_FROM_INLINE.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883
--- Comment #11 from Richard Biener ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Richard Earnshaw from comment #9)
> > Part of the problem here is that the gimple expansion does not see the
> > argument unpacking or understand how the parameters are passed; so this is
> > only exposed after lowering to RTL and we are then reliant on the less
> > powerful RTL optimations to get good code.
>
> Right, i was thinking about how we expose so of it like having a late pass
> which does the splitting if it is possible. This is part of the reason why I
> created the meta bug to record all of these issues in one place to make it
> easier to start working on a pass like that (maybe for gcc 13 but I have so
> much stuff on my plate right now).
Btw, I thought about this issue quite extensively together with Michael Matz
and it's going to be a mess, in particular on the call side. Representing
things on GIMPLE will also be fun. The idea for incoming arguments was
to make the "default definitions" explicit. For aggregates that would mean
having sth like
struct S { double x; double y; };
void foo (struct S s)
{
register double s$x __asm__("%xmm0");
register double s$y __asm__("%xmm1");
s.x = s$x;
s.y = s$y;
}
or for registers (ick)
void foo (_Complex double z)
{
register double z$r __asm__("%xmm0");
register double z$i __asm__("%xmm1");
z_1(D) = COMPLEX_EXPR ;
}
but it's unclear how exactly this will help if it's just done right before
RTL expansion. It will also be fun when an aggregate is passed partly
on the stack and partly in registers.
A similar approach could work for the return.
For calls we have representational issues, esp. for the return. Some
cases could be improved but it might also result in for example too
large lifetime of return slots if the expose those.
[Bug target/104380] New: -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c* wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104380
Bug ID: 104380
Summary: -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c*
wrong-code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
With -O2 -D_FORTIFY_SOURCE=2 -mabi=ieeelongdouble -std=c11 (or some other
-std=c* mode), the following testcase fails on powerpc64le-linux:
#include
#include
static char buf[4096];
static char gfmt[] = "%Lg";
static int __attribute__ ((noinline))
foo (char *str, const char *fmt, ...)
{
int ret;
va_list ap;
va_start (ap, fmt);
ret = vsnprintf (str, 4096, fmt, ap);
va_end (ap);
return ret;
}
int
main ()
{
long double dval = 128;
int ret = foo (buf, gfmt, dval);
if (ret != 3 || __builtin_strcmp (buf, "128") != 0)
__builtin_abort ();
return 0;
}
It works without -D_FORTIFY_SOURCE*, or with the GNU standard modes (-std=gnu99
etc.).
Preprocessed and reduced it is:
extern int vsnprintf (char *__restrict __s, size_t __maxlen, const char
*__restrict __format, __builtin_va_list __arg)
__attribute__ ((__nothrow__)) __attribute__ ((__format__ (__printf__, 3,
0)));
extern int __vsnprintf_chk (char *__restrict __s, size_t __n, int __flag,
size_t __slen, const char *__restrict __format, __builtin_va_list __ap)
__attribute__ ((__nothrow__ , __leaf__));
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) __attribute__ ((__artificial__)) int
__attribute__ ((__nothrow__ , __leaf__)) vsnprintf (char *__restrict __s,
size_t __n, const char *__restrict __fmt, __builtin_va_list __ap)
{
return __builtin___vsnprintf_chk (__s, __n, 2 - 1, __builtin_object_size
(__s, 2 > 1), __fmt, __ap);
}
extern __typeof (vsnprintf) vsnprintf __asm ("__vsnprintfieee128");
extern __typeof (__vsnprintf_chk) __vsnprintf_chk __asm
("__vsnprintf_chkieee128");
static char buf[4096];
static char gfmt[] = "%Lg";
static int __attribute__ ((noinline))
foo (char *str, const char *fmt, ...)
{
int ret;
__builtin_va_list ap;
__builtin_va_start (ap, fmt);
ret = vsnprintf (str, 4096, fmt, ap);
__builtin_va_end (ap);
return ret;
}
int
main ()
{
long double dval = 128;
int ret = foo (buf, gfmt, dval);
if (ret != 3 || __builtin_strcmp (buf, "128") != 0)
__builtin_abort ();
return 0;
}
[Bug target/104380] -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c* wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104380
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |12.0
CC||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Seems for non-_FORTIFY_SOURCE rs6000.cc deals with this in:
size_t printf_len = strlen ("printf");
size_t scanf_len = strlen ("scanf");
if (len >= printf_len
&& strcmp (name + len - printf_len, "printf") == 0)
newname = xasprintf ("__%sieee128", name);
else if (len >= scanf_len
&& strcmp (name + len - scanf_len, "scanf") == 0)
newname = xasprintf ("__isoc99_%sieee128", name);
but we need to deal also with printf_chk.
[Bug target/104380] -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c* wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104380 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-02-04 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 52348 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52348&action=edit gcc12-pr104380.patch Untested fix.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #12 from Eric Botcazou --- > Btw, I thought about this issue quite extensively together with Michael Matz > and it's going to be a mess, in particular on the call side. Representing > things on GIMPLE will also be fun. Is it really worth the hassle though for real-world code, i.e. as opposed to toy examples, now that we have IPA-SRA and the like?
[Bug fortran/102330] [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 since r12-980-g29a2f51806c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102330 Thomas Schwinge changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- Posting my current status here, in case anybody feels like verifying my thoughts. :-) So I'm looking into Jakub's last, simplest reproducer: (In reply to Jakub Jelinek from comment #7) > program p > i = 0 > !$omp task shared(i) > i = 1 > !$omp end task > !$omp taskwait > !$acc parallel loop > do i = 1, 8 > end do > end > > also ICEs ACK. > it just needs the iterator that is marked addressable during > omp-low.c which has code to regimplify statements that access such > variables, but it seems the problematic stmts are emitted only during > omp-expand.c. ACK, 'gcc/omp-expand.cc:expand_oacc_for'. > The various expand_omp_* loop expansions have DECL_P (...) && > TREE_ADDRESSABLE (...) conditions in various spots, but perhaps OpenACC loop > expansion doesn't. (Thanks, that has help me with PR104132!) However, that doesn't seem to be the problem here: we get reported "non-register as LHS of binary operation", but we've got in 'gcc/omp-expand.cc:expand_oacc_for': 7868 ass = gimple_build_assign (v, expr); (gdb) n 7869 gsi_insert_before (&gsi, ass, GSI_SAME_STMT); (gdb) call debug_gimple_stmt(ass) i = 1 + .offset.8; (gdb) call debug_tree(v) unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77e8 precision:32 min max pointer_to_this > used SI source-gcc/gcc/testsuite/gfortran.dg/goacc-gomp/pr102330-3.f90:9:3 size unit-size align:32 warn_if_not_align:0 context > (gdb) call is_gimple_lvalue(v) $4 = true (gdb) call is_gimple_reg(v) $5 = true (gdb) print v.base.addressable_flag $6 = 0 So, 'i' is not 'TREE_ADDRESSABLE'. Is the problem rather, that we earlier have done wrong, as Richard pointed out: (In reply to Richard Biener from comment #1) > Confirmed. omp expansion seems to introudce this non-gimple code and likely > also makes 'i' not a register (for OACC): > > .data_dep.5D.4044 = .UNIQUE (OACC_PRIVATE, .data_dep.5D.4044, -1, &iD.4045); That's built in 'gcc/omp-low.cc:lower_oacc_private_marker'. It's not marked 'TREE_ADDRESSABLE' (per debug log above), but the address of 'i' has been taken (here). > but > > iD.4045 = 1 + .offset.9D.4049; > > and > > iD.4045 = 1 + 8; > > (which is also unfolded) Assuming 'TREE_ADDRESSABLE', that last item is resolved via my proposed PR104132 change: [...] +gimple_simplified to D.4257 = 9; [...] - iD.4257 = 1 + 8; + D.4266 = 9; + iD.4259 = D.4266; [...] So if in 'gcc/omp-expand.cc:expand_oacc_for' I force 'TREE_ADDRESSABLE', then the ICE goes away, and we get valid GIMPLE generated, per my understanding. So, something like this maybe (untested)? --- gcc/omp-low.cc +++ gcc/omp-low.cc @@ -11513,6 +11513,7 @@ lower_oacc_private_marker (omp_context *ctx) } gcc_checking_assert (decl); + TREE_ADDRESSABLE (decl) = 1; tree addr = build_fold_addr_expr (decl); args.safe_push (addr); } However: given that the '#pragma acc loop' has an implicit 'private(i)' -- why does the 'gcc/omp-expand.cc:expand_oacc_for' even bother about the "outer 'i'"? The loop variable 'i' should be a completely separate, local, register-like temporary. Amy I misunderstanding something, or what's going wrong, elsewhere?
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 --- Comment #2 from Richard Biener --- I suspect we warn once for each CTOR clone, whilst with checking DECL_FROM_INLINE we excluded all but the master clone. "from inline" is of course misleading here. I suppose the same issue might happen with templates where we'd warn once per instantiation? There's for sure a better way to exclude the CTOR/DTOR clones than checking DECL_ABSTRACT_ORIGIN. DECL_FROM_INLINE is nearly dead, it should probably be removed.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #13 from rguenther at suse dot de --- On Fri, 4 Feb 2022, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 > > Eric Botcazou changed: > >What|Removed |Added > > CC||ebotcazou at gcc dot gnu.org > > --- Comment #12 from Eric Botcazou --- > > Btw, I thought about this issue quite extensively together with Michael Matz > > and it's going to be a mess, in particular on the call side. Representing > > things on GIMPLE will also be fun. > > Is it really worth the hassle though for real-world code, i.e. as opposed to > toy examples, now that we have IPA-SRA and the like? I've looked at this in the context of BB vectorization which can cause awful code when parameters / return vars are participating and GIMPLE represents things as memory but RTL not. But no, I don't remember any case from SPEC where it makes a difference in the end. Judging from the amount of duplicates we get around parameter / return issues people do run into this.
[Bug fortran/102330] [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 since r12-980-g29a2f51806c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102330
--- Comment #9 from Jakub Jelinek ---
If you need to mark some var as addressable during omp lowering, then you need
to treat it similarly to the task shared case, so during scan phase of that
pass
do something like:
/* Taking address of OUTER in lower_send_shared_vars
might need regimplification of everything that uses the
variable. */
if (!task_shared_vars)
task_shared_vars = BITMAP_ALLOC (NULL);
bitmap_set_bit (task_shared_vars, DECL_UID (outer));
TREE_ADDRESSABLE (outer) = 1;
which will then make sure that the lowering phase of the pass will try to
regimplify all statements refering to such vars. Note, this should be only
done if the var isn't already TREE_ADDRESSABLE.
We then do:
static tree
lower_omp_regimplify_p (tree *tp, int *walk_subtrees,
void *data)
{
tree t = *tp;
...
if (task_shared_vars
&& DECL_P (t)
&& bitmap_bit_p (task_shared_vars, DECL_UID (t)))
return t;
Whether you can use the same bitmap or need to add another bitmap next to
task_shared_vars is something hard to guess without diving into it deeply.
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> I suppose the same issue might happen with templates where we'd warn
> once per instantiation?
Yes indeed. Once for the primary template, and then again for each
specialization generated from it:
template
struct S
{
int i;
int f(int i) { return i; }
};
int i = S().f(1);
int j = S().f(1);
shad2.C: In member function ‘int S::f(int)’:
shad2.C:5:13: warning: declaration of ‘i’ shadows a member of ‘S’ [-Wshadow]
5 | int f(int i) { return i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C: In instantiation of ‘int S::f(int) [with T = int]’:
shad2.C:8:19: required from here
shad2.C:5:13: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | int f(int i) { return i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C: In instantiation of ‘int S::f(int) [with T = long int]’:
shad2.C:9:20: required from here
shad2.C:5:13: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | int f(int i) { return i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
[Bug fortran/102330] [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 since r12-980-g29a2f51806c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102330 --- Comment #10 from Jakub Jelinek --- Of course exceptions would be vars that certainly don't appear in the IL yet, what I wrote about are vars that may appear there already. Generally, vars should be marked as addressable before gimplification and gimplification will then take the addressability into consideration, it is wrong to mark vars as addressable in the middle of gimplification if they could be already referenced earlier in the IL. And similarly in omp-low.cc we perform regimplifications and so stuff is fixable there too, but it needs to know it should fix it up.
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379
--- Comment #4 from Jonathan Wakely ---
So you can imagine what happens if you combine constructor clones with
templates! :-D
template
struct S
{
int i;
S(int i) { (void) i; }
};
S i(1);
S j(1);
whe!
shad2.C: In constructor ‘S::S(int)’:
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’ [-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C: In instantiation of ‘S::S(int) [with T = int]’:
shad2.C:8:11: required from here
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C: In instantiation of ‘S::S(int) [with T = long int]’:
shad2.C:9:12: required from here
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
[Bug ipa/104377] Unreachable code in create_specialized_node of ipa-prop.c?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104377 --- Comment #1 from Feng Xue --- (In reply to Feng Xue from comment #0) > For function create_specialized_node(), the "node" to operated on seems > always to be an original cgraph node, never a clone node. From call graph > related to the function, we know that ipcp_decision_stage () only passes raw > cgraph node downwards to its callees. Then, "node" reaching > create_specialized_node() would not be a clone, so the code enclosed by "if > (old_adjustments)" might be of no use. But I am not sure sure if there is > some thing that I missed. > > ipcp_driver > | > '--> ipcp_decision_stage >| >'--> decide_whether_version_node > | > |--> decide_about_value > | | > '-'--> create_specialized_node OK. I does missed something. Here we could not hold assumption that ipcp_decision_stage() only sees raw cgraph node, since sometime in the future some new ipa pass may be added prior to ipa-cp, and this pass introduces clone node. However, there is a questionable point about the code snippet if (!node->can_change_signature || old_adj->op != IPA_PARAM_OP_COPY || (!known_csts[old_adj->base_index] && ipa_is_param_used (info, old_adj->base_index))) In ipa-cp, known_csts is for the node, has no relation to the node's origin node, but here it is accessed via index of the latter (old_adj->base_index), will this cause out-of-bound error?
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #14 from Eric Botcazou --- > But no, I don't remember any case from SPEC where it makes a difference > in the end. Judging from the amount of duplicates we get around > parameter / return issues people do run into this. Yes, but I'd think on smallish/toy examples with e.g. Compiler Explorer.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #15 from Richard Earnshaw --- Even if the performance impact is low, it does matter when optimizing for size.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #16 from Richard Earnshaw --- And there are also cases where we end up with dead stack slots which can't be removed, so there's a stack size impact as well.
[Bug middle-end/104381] New: [12 Regression] -gtoggle no longer applied when using optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104381
Bug ID: 104381
Summary: [12 Regression] -gtoggle no longer applied when using
optimize attribute
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
int foo (int x)
{
int tem = x + 1;
int tem2 = tem - 1;
return tem2;
}
int __attribute__((optimize("no-tree-pre"))) bar (int x)
{
int tem = x + 1;
int tem2 = tem - 1;
return tem2;
}
with
> ./xgcc -B. t.c -O2 -g -gtoggle -fdump-tree-optimized -c
I get
;; Function foo (foo, funcdef_no=0, decl_uid=1979, cgraph_uid=1,
symbol_order=0)
int foo (int x)
{
[local count: 1073741824]:
return x_1(D);
}
;; Function bar (bar, funcdef_no=1, decl_uid=1984, cgraph_uid=2,
symbol_order=1)
__attribute__((optimize ("no-tree-pre")))
int bar (int x)
{
[local count: 1073741824]:
# DEBUG tem => x_1(D) + 1
# DEBUG tem2 => x_1(D)
return x_1(D);
}
so -gtoggle is not applied to 'bar'. This works fine with GCC 11.
[Bug middle-end/104381] [12 Regression] -gtoggle no longer applied when using optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104381 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 CC||marxin at gcc dot gnu.org
[Bug middle-end/104381] [12 Regression] -gtoggle no longer applied when using optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104381
--- Comment #1 from Richard Biener ---
Err, it's worse(?)
> ./xgcc -B. t.c -O2 -fdump-tree-optimized -c
;; Function foo (foo, funcdef_no=0, decl_uid=1979, cgraph_uid=1,
symbol_order=0)
int foo (int x)
{
[local count: 1073741824]:
return x_1(D);
}
;; Function bar (bar, funcdef_no=1, decl_uid=1984, cgraph_uid=2,
symbol_order=1)
__attribute__((optimize ("no-tree-pre")))
int bar (int x)
{
[local count: 1073741824]:
# DEBUG tem => x_1(D) + 1
# DEBUG tem2 => x_1(D)
return x_1(D);
}
so it either applies -gtoggle or somehow enables at least
var-tracking-assignments (no .debug_info generated).
[Bug fortran/104382] New: Finalization of parent components not compliant with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 Bug ID: 104382 Summary: Finalization of parent components not compliant with standard Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Created attachment 52349 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52349&action=edit Testcase for the problems With all branches that feature finalization, the attached testcase outputs: final_count after assignment =0 destructor4(complicated) 4. 5. destructor5 (simple2) -1 destructor5 (simple2) -2 destructor2(simple) 3 4 final_count after deallocation =4 Ifort, on the other hand, outputs: destructor4(complicated) 2.00 2.00 destructor5 (simple2) 5 destructor5 (simple2) 6 destructor1(simple) 1 destructor1(simple) 1 final_count after assignment =5 destructor4(complicated) 4.00 5.00 destructor5 (simple2) -1 destructor5 (simple2) -2 destructor1(simple) 3 destructor1(simple) 4 final_count after deallocation = 10 There are two problems: (i) The finalization of 'var' prior to reallocation is not ocurring. This is fixed by the patch that I posted to the list yesterday. (ii) The parent component is not being treated as a component, as mandated by F2018 7.5.6.2/1(3). Ifort is behaving correctly. Paul
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #17 from Eric Botcazou --- > Even if the performance impact is low, it does matter when optimizing for > size. Worth addressing for sure, but IMO not at expense of exposing calling conventions and other low-level stuff in GIMPLE.
[Bug middle-end/104381] [12 Regression] -gtoggle no longer applied when using optimize attribute since r12-4608-gb4702276615ff8d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104381 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-02-04 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Summary|[12 Regression] -gtoggle no |[12 Regression] -gtoggle no |longer applied when using |longer applied when using |optimize attribute |optimize attribute since ||r12-4608-gb4702276615ff8d4 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Started with r12-4608-gb4702276615ff8d4, working on that.
[Bug rtl-optimization/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu by r7-7101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103006 --- Comment #14 from Richard Biener --- There's an interesting case, a = BIRTH loop: b = DEATH a = DEATH b = BIRTH goto loop; where we end up having both a and b in the live-in set at the loop label but a is removed before we see the BIRTH of b which is where we add conflicts based on the current set of active vars. In the case I'm running into this I have tail-recursion do a = BIRTH b = BIRTH ... a = DEATH b = DEATH into loop: a = BIRTH b = BIRTH goto loop; a = DEATH b = DEATH leading to a similar issue. The issue above can for example arise from loop rotation. In all cases live from backedges confuse the "optimization" done to only record conflicts when we add a var to the live set (and it is not already set). The previous code had /* If this is the first real instruction in this BB we need to add conflicts for everything live at this point now. Unlike classical liveness for named objects we can't rely on seeing a def/use of the names we're interested in. There might merely be indirect loads/stores. We'd not add any conflicts for such partitions. */ and the easiest is to do the same here (we don't see the backedge "use"), but we could possibly improve by noting which vars are only live from a backedge here.
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379
--- Comment #5 from rguenther at suse dot de ---
On Fri, 4 Feb 2022, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379
>
> --- Comment #4 from Jonathan Wakely ---
> So you can imagine what happens if you combine constructor clones with
> templates! :-D
>
> template
> struct S
> {
> int i;
> S(int i) { (void) i; }
> };
>
> S i(1);
> S j(1);
>
> whe!
It's just really insisting on you to fix it! ;) Somehow it feels
the shadow stuff runs at the wrong place - it should run at _parsing_,
not at instantiation [of ctor/dtor clones].
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 --- Comment #6 from Richard Biener --- Oh, btw - we'd also warn N times for an uninitialized variable use for example unless the location-based diagnostic suppression gets this right now - tree or GIMPLE no-warning flags definitely don't.
[Bug tree-optimization/100499] [9/10/11/12 Regression] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #40 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0898049ad9bf6c46e510b18aaafca4946802749f commit r12-7052-g0898049ad9bf6c46e510b18aaafca4946802749f Author: Richard Biener Date: Wed Jan 26 09:35:57 2022 +0100 tree-optimization/100499 - niter analysis and multiple_of_p niter analysis uses multiple_of_p which currently assumes operations like MULT_EXPR do not wrap. We've got to rely on this for optimizing size expressions like those in DECL_SIZE and those generally use unsigned arithmetic with no indication that they are not expected to wrap. To preserve that the following adds a parameter to multiple_of_p, defaulted to true, indicating that the TOP expression is not expected to wrap for outer computations in TYPE. This mostly follows a patch proposed by Bin last year with the conversion behavior added. Applying to all users the new effect is that upon type conversions in the TOP expression the behavior will switch to honor TYPE_OVERFLOW_UNDEFINED for the converted sub-expressions. The patch also changes the occurance in niter analysis that we know is problematic and we have testcases for to pass false to multiple_of_p. The patch also contains a change to the PR72817 fix from Bin to avoid regressing gcc.dg/tree-ssa/loop-42.c. The intent for stage1 is to introduce a size_multiple_of_p and internalize the added parameter so all multiple_of_p users will honor TYPE_OVERFLOW_UNDEFINED and users dealing with size expressions need to be switched to size_multiple_of_p. 2022-01-26 Richard Biener PR tree-optimization/100499 * fold-const.h (multiple_of_p): Add nowrap parameter, defaulted to true. * fold-const.cc (multiple_of_p): Likewise. Honor it for MULT_EXPR, PLUS_EXPR and MINUS_EXPR and pass it along, switching to false for conversions. * tree-ssa-loop-niter.cc (number_of_iterations_ne): Do not claim the outermost expression does not wrap when calling multiple_of_p. Refactor the check done to check the original IV, avoiding a bias that might wrap. * gcc.dg/torture/pr100499-1.c: New testcase. * gcc.dg/torture/pr100499-2.c: Likewise. * gcc.dg/torture/pr100499-3.c: Likewise. Co-authored-by: Bin Cheng
[Bug tree-optimization/100499] [9/10/11 Regression] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 Richard Biener changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |Different results with |Different results with |-fpeel-loops|-fpeel-loops |-ftree-loop-vectorize |-ftree-loop-vectorize |options |options Known to work||12.0 --- Comment #41 from Richard Biener --- This series, also g:24c72fb0eedfe7c67f9b15aa31b474a999cc4723, fixes the known cases of miscompiles. Thanks for reporting!
[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356 --- Comment #45 from Andrew Macleod --- > > That said, range-ops, from say > > [0,1] = [0,2] / y; > > may _not_ reason that 'y' is not 0 when non-call EH. That is, you need to be > careful on the reverse ops but I think not on the forward ops. We do not currently try to figure anything via reverse ops for general divide operations. For exact_divide we try if Y is a non-zero singleton, but that's about it.
[Bug c++/104383] New: User-defined conversion is preferred over standard-one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104383
Bug ID: 104383
Summary: User-defined conversion is preferred over standard-one
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This example
```
#include
struct IntSimilar { constexpr IntSimilar(int) {} };
constexpr int f(int) { return 1; }
constexpr int f(std::initializer_list) { return 2; }
int main() {
static_assert( f({0}) == 1 );
}
```
is accepted by Clang and MSVC. It looks right according to the standard saying
"a standard conversion sequence is a better conversion sequence than a
user-defined conversion sequence"
https://timsong-cpp.github.io/cppwp/n4861/over.ics.rank#2.1
But GCC selects the other overload. Demo: https://gcc.godbolt.org/z/3Ghvn98xr
[Bug c++/104383] User-defined conversion is preferred over standard-one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104383 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- dup, I think *** This bug has been marked as a duplicate of bug 99273 ***
[Bug c++/99273] List initialization prefers initializer_list a little too strongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99273 Patrick Palka changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #2 from Patrick Palka --- *** Bug 104383 has been marked as a duplicate of this bug. ***
[Bug middle-end/103642] [12 Regression] ICE in lower_omp_target: omp-low.c:12977 (fold_convert_loc) for omp target map(from: t.s->a[:N]) since r12-5835-g0ab29cf0bb68960c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103642 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tobias Burnus --- In my understanding, this patch is now FIXED. In particular, also the longer testcases works. Thanks ChungLin for fixing it!
[Bug c++/80951] Deducing noexcept only works when also deducing something else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80951 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/69778] Bogus "qualifiers cannot be applied" error with redundant (but legal) 'typename'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69778 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Patrick Palka --- Fixed for GCC 12 by r12-4051 *** This bug has been marked as a duplicate of bug 101783 ***
[Bug c++/101783] unnecessary error when top level cv qualifier is dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783 Patrick Palka changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #12 from Patrick Palka --- *** Bug 69778 has been marked as a duplicate of this bug. ***
[Bug c++/90816] -finstrument-functions-exclude-function-list improperly handles namespace/class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90816 Thomas De Schampheleire changed: What|Removed |Added CC||patrickdepinguin at gmail dot com --- Comment #3 from Thomas De Schampheleire --- A fix for this issue seems to have been applied as (git) commit efab3e3a7326ad503532955ccd31f953851e388a. This bug can thus be closed.
[Bug c++/90809] -finstrument-functions-exclude-function-list mishandles comma escaping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90809 Thomas De Schampheleire changed: What|Removed |Added CC||patrickdepinguin at gmail dot com --- Comment #3 from Thomas De Schampheleire --- A fix for this issue seems to have been applied as (git) commit efab3e3a7326ad503532955ccd31f953851e388a. This bug can thus be closed.
[Bug c++/104384] New: Heap corruption when initializing struct with co_await
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104384
Bug ID: 104384
Summary: Heap corruption when initializing struct with co_await
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: max at duempel dot org
Target Milestone: ---
Created attachment 52350
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52350&action=edit
Crashing demo program
When initializing struct members, and one struct member gets initialized with a
co_awaited values, the following struct members can be corrupted.
Tested with:
- gcc version 10.2.1 20210110 (Debian 10.2.1-6)
- gcc version 11.2.0 (Debian 11.2.0-16)
- gcc version 12.0.1 20220126 (experimental) [master r12-6872-gf3e6ef7d873]
(Debian 12-20220126-1)
clang ("Debian clang version 11.0.1-2") is fine.
My demo program crashes like this:
$ g++ -o cocrash2 cocrash2.cxx -fcoroutines -std=c++20 && valgrind ./cocrash2
==1947496== Memcheck, a memory error detector
==1947496== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1947496== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==1947496== Command: ./cocrash2
==1947496==
==1947496== Invalid free() / delete / delete[] / realloc()
==1947496==at 0x484008B: operator delete(void*, unsigned long) (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1947496==by 0x10C438: __gnu_cxx::new_allocator::deallocate(char*,
unsigned long) (in /tmp/cocrash2)
==1947496==by 0x10C0EC: std::allocator_traits
>::deallocate(std::allocator&, char*, unsigned long) (in /tmp/cocrash2)
==1947496==by 0x10BE29: std::__cxx11::basic_string, std::allocator >::_M_destroy(unsigned long) (in
/tmp/cocrash2)
==1947496==by 0x10B973: std::__cxx11::basic_string, std::allocator >::_M_dispose() (in /tmp/cocrash2)
==1947496==by 0x10B167: std::__cxx11::basic_string, std::allocator >::~basic_string() (in
/tmp/cocrash2)
==1947496==by 0x10AE5F: Foo::~Foo() (in /tmp/cocrash2)
==1947496==by 0x10AA61: main (in /tmp/cocrash2)
==1947496== Address 0x4db6d20 is 160 bytes inside a block of size 200 alloc'd
==1947496==at 0x483EDEF: operator new(unsigned long) (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1947496==by 0x10A593: MakeFoo(bool) (in /tmp/cocrash2)
==1947496==by 0x10A9F3: main (in /tmp/cocrash2)
==1947496==
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883
--- Comment #18 from Sebastian Huber ---
clang 11 produces this code for the attached test case:
clang -O2 -S -o - pr50883.c -target arm
clang-11.0: warning: unknown platform, assuming -mfloat-abi=soft
clang-11.0: warning: unknown platform, assuming -mfloat-abi=soft
.text
.syntax unified
.eabi_attribute 67, "2.09" @ Tag_conformance
.cpuarm7tdmi
.eabi_attribute 6, 2@ Tag_CPU_arch
.eabi_attribute 8, 1@ Tag_ARM_ISA_use
.eabi_attribute 9, 1@ Tag_THUMB_ISA_use
.eabi_attribute 34, 0 @ Tag_CPU_unaligned_access
.eabi_attribute 17, 1 @ Tag_ABI_PCS_GOT_use
.eabi_attribute 20, 1 @ Tag_ABI_FP_denormal
.eabi_attribute 21, 0 @ Tag_ABI_FP_exceptions
.eabi_attribute 23, 3 @ Tag_ABI_FP_number_model
.eabi_attribute 24, 1 @ Tag_ABI_align_needed
.eabi_attribute 25, 1 @ Tag_ABI_align_preserved
.eabi_attribute 38, 1 @ Tag_ABI_FP_16bit_format
.eabi_attribute 18, 4 @ Tag_ABI_PCS_wchar_t
.eabi_attribute 26, 2 @ Tag_ABI_enum_size
.eabi_attribute 14, 0 @ Tag_ABI_PCS_R9_use
.file "pr50883.c"
.globl f @ -- Begin function f
.p2align2
.type f,%function
.code 32 @ @f
f:
.fnstart
@ %bb.0:
mov r0, r1
bx lr
.Lfunc_end0:
.size f, .Lfunc_end0-f
.cantunwind
.fnend
@ -- End function
.globl g @ -- Begin function g
.p2align2
.type g,%function
.code 32 @ @g
g:
.fnstart
@ %bb.0:
mov r0, r1
bx lr
.Lfunc_end1:
.size g, .Lfunc_end1-g
.cantunwind
.fnend
@ -- End function
.globl h @ -- Begin function h
.p2align2
.type h,%function
.code 32 @ @h
h:
.fnstart
@ %bb.0:
ldr r1, .LCPI2_0
ldm r1, {r0, r1}
b j
.p2align2
@ %bb.1:
.LCPI2_0:
.long ss
.Lfunc_end2:
.size h, .Lfunc_end2-h
.cantunwind
.fnend
@ -- End function
.globl i @ -- Begin function i
.p2align2
.type i,%function
.code 32 @ @i
i:
.fnstart
@ %bb.0:
ldr r1, .LCPI3_0
ldm r1, {r0, r1}
b k
.p2align2
@ %bb.1:
.LCPI3_0:
.long tt
.Lfunc_end3:
.size i, .Lfunc_end3-i
.cantunwind
.fnend
@ -- End function
.ident "clang version 11.0.1"
.section".note.GNU-stack","",%progbits
.addrsig
[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356 --- Comment #46 from Eric Botcazou --- > I meant something like: > with System.Unsigned_Types; use System.Unsigned_Types; > > function F (X, Y : Unsigned) return Unsigned is > Z : Unsigned; > begin > if X >=2 then > return 0; > end if; > Z := Y; > if X = 1 then > Z := Y + 4; > end if; > return Z / X; > end; > and there evrp does with -O2 -gnatp optimize away the division. My bad. I forgot that -gnatp now disables -fnon-call-exceptions too (in order to make the mode mimic C++) so the testcase must be written: with System.Unsigned_Types; use System.Unsigned_Types; function Opt97 (X, Y : Unsigned) return Unsigned is pragma Suppress (All_Checks); Z : Unsigned; begin if X >= 2 then return 0; end if; Z := Y; if X = 1 then Z := Y + 4; end if; return Z / X; end; and there is still the divide at -O2 and above on mainline.
[Bug libgomp/104385] New: Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385 Bug ID: 104385 Summary: Segmentation fault when using nested dependent tasks Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: wacrenier at labri dot fr CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 52351 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52351&action=edit simple openmp code that leads to a segfault Hello, The attached code leads to SIGSEV when executing. Best regards, P.A. Wacrenier Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/lto-wrapper Target: x86_64-apple-darwin21 Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc11/gcc11/work/gcc-11.2.0/configure --prefix=/opt/local --build=x86_64-apple-darwin21 --enable-languages=c,c++,objc,obj-c++,lto,fortran,jit --libdir=/opt/local/lib/gcc11 --includedir=/opt/local/include/gcc11 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-11 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-11 --with-gxx-include-dir=/opt/local/include/gcc11/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-bugurl=https://trac.macports.org/newticket --enable-host-shared --disable-tls --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-pkgversion='MacPorts gcc11 11.2.0_3' --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.0 (MacPorts gcc11 11.2.0_3) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0' '-asm_macosx_version_min=12.1' '-mtune=core2' '-dumpdir' 'a-' /opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/cc1 -E -quiet -v -D__DYNAMIC__ ici.c -fPIC -mmacosx-version-min=12.1.0 -mtune=core2 -fopenmp -fpch-preprocess -o a-ici.i ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/opt/local/include" ignoring nonexistent directory "/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/../../../../../x86_64-apple-darwin21/include" ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/include /opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/include-fixed /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0' '-asm_macosx_version_min=12.1' '-mtune=core2' '-dumpdir' 'a-' /opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/cc1 -fpreprocessed a-ici.i -fPIC -quiet -dumpdir a- -dumpbase ici.c -dumpbase-ext .c -mmacosx-version-min=12.1.0 -mtune=core2 -version -fopenmp -o a-ici.s GNU C17 (MacPorts gcc11 11.2.0_3) version 11.2.0 (x86_64-apple-darwin21) compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C17 (MacPorts gcc11 11.2.0_3) version 11.2.0 (x86_64-apple-darwin21) compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: f32d7bc7d3a774eacf5c9650a419dd5f COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0' '-mtune=core2' '-dumpdir' 'a-' /opt/local/bin/as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=12.1 -o a-ici.o a-ici.s Apple clang version 13.0.0 (clang-1300.0.29.30) Target: x86_64-apple-darwin21.2.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple x86_64-apple-macosx12.1.0 -filetype obj -main-file-name a-ici.s -target-cpu penryn -fdebug-compilation-dir /tmp -dwarf-debug-producer "Apple clang version 13.0.0 (clang-1300.0.29.30)" -dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm -disable-aligned-alloc-awareness=1 -mllvm -enable-dse-memoryssa=0 -o a-ici.o a-ici.s COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin21/:/opt/local/lib/gcc11/gcc/x86_64-apple-darwin2
[Bug analyzer/101081] analyzer testsuite failures seen with new glibc due to malloc attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101081 Joel Teichroeb changed: What|Removed |Added CC||joel at teichroeb dot net --- Comment #1 from Joel Teichroeb --- I've submitted a patch to the mailing list which fixes this issue. https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589886.html
[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356 --- Comment #47 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:1f722e35ab3805de6eeace770508a9085944e93e commit r12-7058-g1f722e35ab3805de6eeace770508a9085944e93e Author: Eric Botcazou Date: Fri Feb 4 17:41:55 2022 +0100 Add optmization testcase for incorrect optimization in Ada gcc/testsuite/ PR tree-optimization/104356 * gnat.dg/opt97.adb: New test.
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-02-04 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #4 from Bill Schmidt --- Confirmed, I'll clean it up.
[Bug target/104380] -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c* wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104380 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8d6fffc4bcd4afa0beb0efad4f3b95394aa15618 commit r12-7059-g8d6fffc4bcd4afa0beb0efad4f3b95394aa15618 Author: Jakub Jelinek Date: Fri Feb 4 18:30:59 2022 +0100 rs6000: Fix up -D_FORTIFY_SOURCE* with -mabi=ieeelongdouble [PR104380] The following testcase FAILs when configured with --with-long-double-format=ieee . Only happens in the -std=c* modes, not the GNU modes; while the glibc headers have __asm redirects of vsnprintf and __vsnprinf_chk to __vsnprintfieee128 and __vsnprintf_chkieee128, the vsnprintf fortification extern inline gnu_inline always_inline wrapper calls __builtin_vsnprintf_chk and we actually emit a call to __vsnprinf_chk (i.e. with IBM extended long double) instead of __vsnprintf_chkieee128. rs6000_mangle_decl_assembler_name already had cases for *printf and *scanf, so this just adds another case for *printf_chk. *scanf_chk doesn't exist. __ prefixing isn't done because *printf_chk already starts with __. 2022-02-04 Jakub Jelinek PR target/104380 * config/rs6000/rs6000.cc (rs6000_mangle_decl_assembler_name): Also adjust mangling of __builtin*printf_chk. * gcc.dg/pr104380.c: New test.
[Bug target/104380] -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c* wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104380 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/104386] New: no_unique_address causes invalid member alignment of pod struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104386
Bug ID: 104386
Summary: no_unique_address causes invalid member alignment of
pod struct
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at ebasoft dot com.pl
Target Milestone: ---
struct base
{ [[no_unique_address]]
uint32_t x; std::byte v;
};
struct foo : public base
{ std::byte z; };
gcc sizeof(foo) == 8 https://godbolt.org/z/G4Mo3PdKT
clang sizeof(foo) == 12 https://godbolt.org/z/bdzvaMn9c
As I was told it is gcc bug
https://www.reddit.com/r/cpp/comments/sjx2mk/no_unique_addres_where_can_in_c_standard_instead/
[orbital1337]"Your class base is a POD but its not a POD for the purpose of
layout (since it has potentially overlapping data members). Thus the Itanium
ABI specifies that it's size without padding (dsize) should be set to its size
with padding (sizeof). The first datamember of your class foo is put at
dsize(base). clang does the right thing and puts it at an offset of 8 bytes
whereas gcc ignores that one line of the specification and puts it at an offset
of 5 bytes instead."
[Bug rtl-optimization/104387] New: aarch64: Redundant SXTH for “bag of bits” moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104387
Bug ID: 104387
Summary: aarch64: Redundant SXTH for “bag of bits” moves
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
This PR is about another case in which we generate a redundant SXTH.
Specifically:
void f(short *x, short y)
{
x[0] = y;
x[1] = y;
}
generates:
sxthw1, w1
strhw1, [x0]
strhw1, [x0, 2]
even though the RTL makes it clear that the upper 16 bits of the
promoted “y” are unused.
This is related to PR64537, but I think it's worth keeping as a
separate PR since the fix isn't necessarily the same.
[Bug fortran/103828] Type generated for CHARACTER(C_CHAR), VALUE arguments is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828 --- Comment #8 from Francois-Xavier Coudert --- I'm not sure if it really counts as an ABI change, given that I know no existing target where this resulted in an actual change in the argument passing convention. (i.e., where that test actually failed).
[Bug c++/104388] New: Request: A builtin to mark an object as invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104388 Bug ID: 104388 Summary: Request: A builtin to mark an object as invalid Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Darrell.Wright at gmail dot com Target Milestone: --- Would it be possible to get a builtin that marks an object as invalid until it is overwritten and make it IF if the object is used other than destruction, assignment or taking its address/ref. I am naive on the compiler internals here, but this could allow for the safety of destructive moves without the changes to the object model around destruction ordering.
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 pc at gcc dot gnu.org changed: What|Removed |Added CC||pc at gcc dot gnu.org --- Comment #27 from pc at gcc dot gnu.org --- There was a commit related to this bug, but it is still in ASSIGNED state, so I'm not sure if this was to be considered "fixed", but... Chip discovered that, with a build of today's trunk, the original test case, and at least gcc.target/powerpc/pr102059-1.c still fail (I didn't try others), and it seems to be related to the presence of "-flto": -- $ gcc -c gcc/testsuite/gcc.target/powerpc/pr102059-1.c -O2 -mcpu=power8 -Wno-attributes -flto gcc/testsuite/gcc.target/powerpc/pr102059-1.c: In function 'bar': gcc/testsuite/gcc.target/powerpc/pr102059-1.c:8:1: error: inlining failed in call to 'always_inline' 'foo': target specific option mismatch 8 | foo (int *b) | ^~~ gcc/testsuite/gcc.target/powerpc/pr102059-1.c:18:8: note: called from here 18 | *a = foo (a); |^~~ $ gcc -c gcc/testsuite/gcc.target/powerpc/pr102059-1.c -O2 -mcpu=power8 -Wno-attributes $ -- The testcases included with the commit do not use "-flto", so these tests are PASSing.
[Bug c/104389] New: HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389
Bug ID: 104389
Summary: HUGE_VAL * 0.0 is no longer a NaN
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vstinner at redhat dot com
Target Milestone: ---
Created attachment 52352
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52352&action=edit
Reproducer: huge_val_0_nan.c
The Python project uses "HUGE_VAL * 0" to get a Not-a-Number (NaN) double
value. Pseudo-code:
#define Py_NAN (Py_HUGE_VAL * 0.)
double my_nan(void)
{ return Py_NAN; }
Until Fedora gcc-12.0.1-0.4.fc36.x86_64
(03182470d2d2b272f06500184acab6b8ed78d8ad), it worked well.
With Fedora gcc-12.0.1-0.5.fc36.x86_64
(fb6057a2be99e071993fb54a5d338ab0febba8ff), my_nan() now returns zero (0.0).
Try attached huge_val_0_nan.c.
gcc-12.0.1-0.5.fc36.x86_64 output:
---
(1) Compute HUGE_VAL * 0 in the C compiler
isnan? 0
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]
(2) Compute HUGE_VAL * 0 at runtime
isnan? 1
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfff8, 0x]
---
gcc-11.2.1-7.fc35.x86_64 output:
---
(1) Compute HUGE_VAL * 0 in the C compiler
isnan? 1
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfff8, 0x7f]
(2) Compute HUGE_VAL * 0 at runtime
isnan? 1
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfff8, 0x]
---
In Python, Py_NAN is defined as "#define Py_NAN (Py_HUGE_VAL * 0.)" at:
https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Include/pymath.h#L60
FYI diff of the Fedora package between -4 and -5, the most important part if
the Git commit which changed ;-)
https://src.fedoraproject.org/rpms/gcc/c/398138b5f3809856b98eb4241b3c9f70da3fce9b?branch=rawhide
[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P1 Target Milestone|--- |10.4 Summary|HUGE_VAL * 0.0 is no longer |[10/11/12 Regression] |a NaN |HUGE_VAL * 0.0 is no longer ||a NaN --- Comment #1 from Jakub Jelinek --- Started with r12-6959-g34afa19d29c5bf0b0f504e4d0aca4e9a8bc82c5c which has been backported to 10/11 as well.
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7a0fab4bddce549380b2713a910127332a091e19 commit r11-9539-g7a0fab4bddce549380b2713a910127332a091e19 Author: Harald Anlauf Date: Tue Feb 1 23:33:24 2022 +0100 Fortran: reject simplifying TRANSFER for MOLD with storage size 0 gcc/fortran/ChangeLog: PR fortran/104311 * check.c (gfc_calculate_transfer_sizes): Checks for case when storage size of SOURCE is greater than zero while the storage size of MOLD is zero and MOLD is an array shall not depend on SIZE. gcc/testsuite/ChangeLog: PR fortran/104311 * gfortran.dg/transfer_simplify_15.f90: New test. (cherry picked from commit 4e4252db0348a7274663a892c3a96d3ed7702aff)
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:837ad03ad4a95629a0d17108f5258568bebbf13f commit r10-10437-g837ad03ad4a95629a0d17108f5258568bebbf13f Author: Harald Anlauf Date: Tue Feb 1 23:33:24 2022 +0100 Fortran: reject simplifying TRANSFER for MOLD with storage size 0 gcc/fortran/ChangeLog: PR fortran/104311 * check.c (gfc_calculate_transfer_sizes): Checks for case when storage size of SOURCE is greater than zero while the storage size of MOLD is zero and MOLD is an array shall not depend on SIZE. gcc/testsuite/ChangeLog: PR fortran/104311 * gfortran.dg/transfer_simplify_15.f90: New test. (cherry picked from commit 4e4252db0348a7274663a892c3a96d3ed7702aff)
[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-02-04
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
double foo (void) { return __builtin_huge_val () * 0.0; }
folds since r12-6959 to return 0.0 instead of return NAN; already in original
dump.
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2953e3d1b9b36b441f5a33d696760ed56742ee1e commit r9-9939-g2953e3d1b9b36b441f5a33d696760ed56742ee1e Author: Harald Anlauf Date: Tue Feb 1 23:33:24 2022 +0100 Fortran: reject simplifying TRANSFER for MOLD with storage size 0 gcc/fortran/ChangeLog: PR fortran/104311 * check.c (gfc_calculate_transfer_sizes): Checks for case when storage size of SOURCE is greater than zero while the storage size of MOLD is zero and MOLD is an array shall not depend on SIZE. gcc/testsuite/ChangeLog: PR fortran/104311 * gfortran.dg/transfer_simplify_15.f90: New test. (cherry picked from commit 4e4252db0348a7274663a892c3a96d3ed7702aff)
[Bug target/104371] [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0xFFFF pattern to ptest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371 --- Comment #2 from Gabriel Ravier --- Although I agree the pattern doesn't seem that useful at first, I've seen it crop up in several places, such as: - in pixman: https://github.com/servo/pixman/blob/master/pixman/pixman-sse2.c on line 181 - in an simd mandelbrot implementation: https://github.com/huonw/mandel-simd/blob/master/mandel_sse2.c on line 47 - in this article: http://0x80.pl/notesen/2021-02-02-all-bytes-in-reg-are-equal.html - in boost::uuid (although this one will detect if compiling on a platform with SSE4.1): https://github.com/boostorg/uuid/blob/develop/include/boost/uuid/detail/uuid_x86.ipp - in this other article: https://mischasan.wordpress.com/2011/11/09/the-generic-sse2-loop/ - in a research paper's accompanying github repo: https://github.com/GameTechDev/MaskedOcclusionCulling/blob/master/MaskedOcclusionCulling.cpp on line 333 - in ClickHouse: https://clickhouse.com/codebrowser/html_report/ClickHouse/src/Common/memcmpSmall.h.html on line 241 And this is just what I found in a few minutes, so I would personally think there are many more occurences of that pattern.
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389
--- Comment #3 from Jakub Jelinek ---
Changing it to
double
foo (void)
{
double a = __builtin_huge_val ();
return a * 0.0;
}
shows ccp1 applies
/* Maybe fold x * 0 to 0. The expressions aren't the same
when x is NaN, since x * 0 is also NaN. Nor are they the
same in modes with signed zeros, since multiplying a
negative value by 0 gives -0, not +0. */
(simplify
(mult @0 real_zerop@1)
(if (!tree_expr_maybe_nan_p (@0)
&& !tree_expr_maybe_real_minus_zero_p (@0)
&& !tree_expr_maybe_real_minus_zero_p (@1))
@1))
So the question is why tree_expr_maybe_nan_p isn't true.
[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 --- Comment #4 from Jakub Jelinek --- Ah, of course it isn't NAN, it is infinity, but +-Inf * 0 is still NAN.
[Bug c++/104390] New: Tree check ICE for valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104390
Bug ID: 104390
Summary: Tree check ICE for valid code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: colavitam at gmail dot com
Target Milestone: ---
The following code produces an ICE (-std=c++17):
template
struct A {};
struct B {
long v;
};
template
struct C {
template
static void f(const A& src) {}
};
void g() {
C::f<&B::v>({});
}
---
: In function 'void g()':
:15:25: internal compiler error: tree check: accessed elt 2 of
'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.cc:13125
15 | C::f<&B::v>({});
| ^~~~
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 --- Comment #5 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:8cb748a31cd8c7ac9c88b6abc38ce077dd462a7a commit r12-7060-g8cb748a31cd8c7ac9c88b6abc38ce077dd462a7a Author: Bill Schmidt Date: Fri Feb 4 13:26:44 2022 -0600 rs6000: Clean up ISA 3.1 documentation [PR100808] Due to a pasto error in the documentation, vec_replace_unaligned was implemented with the same function prototypes as vec_replace_elt. It was intended that vec_replace_unaligned always specify output vectors as having type vector unsigned char, to emphasize that elements are potentially misaligned by this built-in function. This patch corrects the misimplementation. 2022-02-04 Bill Schmidt gcc/ PR target/100808 * doc/extend.texi (Basic PowerPC Built-in Functions Available on ISA 3.1): Provide consistent type names. Remove unnecessary semicolons. Fix bad line breaks.
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #28 from Dan Horák --- comment #27 matches our experience in Fedora, still a build issue in Eigen with gcc12 and LTO
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Bill Schmidt --- Ugh, bad commit message... but fixed.
[Bug tree-optimization/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 52353 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52353&action=edit gcc12-pr104389.patch Untested fix.
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 Peter Bergner changed: What|Removed |Added Known to fail||12.0 Known to work|12.0| --- Comment #29 from Peter Bergner --- Since this is still broken when using trunk, I'm moving GCC 12.0 from Known to Work back to Known to Fail.
[Bug fortran/104391] New: Gfortran 9 regression with bind(C) and allocatable or pointer attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104391 Bug ID: 104391 Summary: Gfortran 9 regression with bind(C) and allocatable or pointer attribute Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: michael at scivision dot dev Target Milestone: --- The `bind(C)` on a procedure appears to break `pointer` and `allocatable` attributes of a variable with regard to index start. Specifically, on exiting a procedure with `bind(c)`, the variable(s) have their indices shifted to zero-based. example that works with GCC <= 8.5 and GCC 12 (broken for GCC 9, 10, 11). ``` program test_bounds use iso_fortran_env, only : error_unit implicit none real, allocatable :: a(:) integer :: L1,L2, U1,U2 allocate(a(1:2)) L1 = lbound(a,1) U1 = ubound(a,1) call c_bounder(a) L2 = lbound(a,1) U2 = ubound(a,1) if (L1 /= L2 .or. U1 /= U2) then write(error_unit, '(a,2i2,a,2i2)') 'FAIL: bounds changed before/after lower:', L1,L2, " upper: ", U1,U2 error stop endif print '(a)', "bounds check OK" contains subroutine c_bounder(a) bind(c) real, intent(inout) :: a(:) end subroutine c_bounder end program ```
[Bug c++/104392] New: Unexpected Narrowing Warning when spaceship comparison of unsigned bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104392
Bug ID: 104392
Summary: Unexpected Narrowing Warning when spaceship comparison
of unsigned bit field
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bieri.hp at gmail dot com
Target Milestone: ---
struct A
{
unsigned int a:5;
};
constexpr std::strong_ordering operator<=>(const A & left, const A & right )
{
return left.a <=> right.a;
}
results in the unexpected warnings
: In function 'constexpr std::strong_ordering operator<=>(const A&,
const A&)':
:15:21: warning: narrowing conversion of 'left.A::a' from 'const
unsigned int' to 'int' [-Wnarrowing]
15 | return left.a <=> right.a;
|~^
:15:33: warning: narrowing conversion of 'right.A::a' from 'const
unsigned int' to 'int' [-Wnarrowing]
15 | return left.a <=> right.a;
| ~~^
it seems to choose the int comparison operator although the type is unsigned
