[Bug middle-end/104763] [12 Regression] Generate wrong assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-03-07 Ever confirmed|0 |1 Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Richard Biener --- I think we have a duplicate somewhere involving EH. The key here is that we are missing the VUSE on the "return" - and in this case it's (again) missing the return, just with using an endless loop (the other PR has a EH re-throw or so).
[Bug middle-end/104763] [12 Regression] Generate wrong assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=85803
--- Comment #6 from Richard Biener ---
PR85803 - I'd say this bug is a duplicate (to some extent). Simplified
testcase
that, with the help of alarm() and signal handlers could be turned into a
runtime FAIL.
typedef __SIZE_TYPE__ size_t;
void move_up(void *p)
{
for ( size_t* i=(size_t *)(p); ; )
{
*i=0x0700070007000700;
if (i == (size_t *)(p)+2 )
break;
++i;
}
while (1){}
}
[Bug tree-optimization/85803] [9/10/11/12 Regression] DSE removes live global store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85803 --- Comment #9 from Richard Biener --- One possible mitigation would be to DFS walk the CFG to find the virtual operands "live" at CFG dead-ends (that includes endless loops, see PR104763) and handle those specially, requiring the ref_may_alias_global_p check for those. Note that the case of an endless loop is somewhat special since the store is dead there since there is no way to reach a load from that point with C standard methods.
[Bug middle-end/104763] [12 Regression] Generate wrong assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763 --- Comment #7 from Richard Biener --- Note that the case of an endless loop is somewhat special since the store is dead there since there is no way to reach a load from that point with C standard methods. So one could also argue the optimization is valid and this bug is invalid. How did you end up with this case?
[Bug tree-optimization/104766] (a * even_cst) & CST does not remove the lower bit from the CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104766 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-03-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||missed-optimization
[Bug target/104773] compare with 1 not merged with subtract 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104773 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-03-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Richard Biener --- Confirmed. Depending on how the unsigned <= 1 is represented on RTL this might or might not be "easily" taught to RTL PRE (likely RTL CSE is too local to catch it, but at least the fallthru path might form an EBB)
[Bug debug/104778] [12 Regression] ICE in simplify_subreg, at simplify-rtx.cc:7324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104778 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/101929] [12 Regression] r12-7319 regress x264_r by 4% on CLX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101929
--- Comment #8 from Hongtao.liu ---
(In reply to Richard Biener from comment #7)
> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> index 9188d727e33..7f1f12fb6c6 100644
> --- a/gcc/tree-vect-slp.cc
> +++ b/gcc/tree-vect-slp.cc
> @@ -2374,7 +2375,7 @@ fail:
> n_vector_builds++;
> }
> }
> - if (all_uniform_p
> + if ((all_uniform_p && !two_operators)
> || n_vector_builds > 1
> || (n_vector_builds == children.length ()
> && is_a (stmt_info->stmt)))
>
>
> will re-enable the vectorization - it evades the vect_construct cost bump
> by instead using scalar_to_vec (aka splat) which has not yet been fixed to
> account for a possible gpr to xmm move (so it would be a temporary "solution"
> at best).
>
> Another change to mute the effect somewhat (but not fixing x264) that was
> mentioned is
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index b2bf90576d5..acf2cc977b4 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -22595,7 +22595,7 @@ ix86_builtin_vectorization_cost (enum
> vect_cost_for_stmt type_of_cost,
>case vec_construct:
> {
> /* N element inserts into SSE vectors. */
> - int cost = TYPE_VECTOR_SUBPARTS (vectype) * ix86_cost->sse_op;
> + int cost = (TYPE_VECTOR_SUBPARTS (vectype) - 1) *
> ix86_cost->sse_op;
(In reply to Richard Biener from comment #7)
> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> index 9188d727e33..7f1f12fb6c6 100644
> --- a/gcc/tree-vect-slp.cc
> +++ b/gcc/tree-vect-slp.cc
> @@ -2374,7 +2375,7 @@ fail:
> n_vector_builds++;
> }
> }
> - if (all_uniform_p
> + if ((all_uniform_p && !two_operators)
> || n_vector_builds > 1
> || (n_vector_builds == children.length ()
> && is_a (stmt_info->stmt)))
>
>
> will re-enable the vectorization - it evades the vect_construct cost bump
> by instead using scalar_to_vec (aka splat) which has not yet been fixed to
> account for a possible gpr to xmm move (so it would be a temporary "solution"
> at best).
>
> Another change to mute the effect somewhat (but not fixing x264) that was
> mentioned is
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index b2bf90576d5..acf2cc977b4 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -22595,7 +22595,7 @@ ix86_builtin_vectorization_cost (enum
> vect_cost_for_stmt type_of_cost,
>case vec_construct:
> {
> /* N element inserts into SSE vectors. */
> - int cost = TYPE_VECTOR_SUBPARTS (vectype) * ix86_cost->sse_op;
> + int cost = (TYPE_VECTOR_SUBPARTS (vectype) - 1) *
> ix86_cost->sse_op;
n - 1 is right for 128-bit vector, but for 256-bit vector, shouldn't it be n -
2, since we have a separate cost for vinserti128, and n - 4 for 512-bit one.
[Bug target/104781] [12 regression] SEGV in _Unwind_GetGR during i386 Ada bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/104782] [12 regression] ICE: verify_gimple failed in slp (non-trivial conversion in ‘ssa_name’) with -msve-vector-bits=128 since r12-7359-g6e80c4f1ad9046b0a7c105660cc7b3dcae0fdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104782 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED Priority|P3 |P1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug middle-end/104763] [12 Regression] Generate wrong assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763
--- Comment #8 from 。 <570070308 at qq dot com> ---
(In reply to Richard Biener from comment #7)
> Note that the case of an endless loop is somewhat special since the store
> is dead there since there is no way to reach a load from that point with
> C standard methods. So one could also argue the optimization is valid
> and this bug is invalid.
>
> How did you end up with this case?
I agree with this bug is invaild.
I do something on memory 0xb8000, this is because the 0xb8000 is the video
memory, and can display on screen.
However gcc don't know it, and I think it doesn't need to know it. Gcc can
simply think that all the writing/reading on memory is useless, unless the
writing/reading on memory will affect subsequent function calls or the function
return. This way gcc can better optimize the code.
According to this, the while(1){} will never return or call a function, so gcc
can think that all the writing/reading on 0xb8000 before while(1){} is useless.
A way to tell gcc that writing/reading on 0xb8000 will make an impact is to
change `*i` to `*(volatile size_t *)i`, and it really work.
So I think:
test.c:
```
void move_up()
{
for ( size_t* i=(size_t *)(0xb8000+160*24); ; )
{
*i=0x0700070007000700;
if ( i == (size_t *)(0xb8000+160*24)+2 )
{
break;
}
++i;
}
while (1){}
}
```
compile to
```
move_up:
jmp move_up
```
and test.c:
```
void move_up()
{
for ( size_t* i=(size_t *)(0xb8000+160*24); ; )
{
*(volatile size_t *)i=0x0700070007000700;
if ( i == (size_t *)(0xb8000+160*24)+2 )
{
break;
}
++i;
}
while (1){}
}
```
compile to:
```
move_up:
movabsq $504410854964332288, %rax
movq%rax, 757504
movq%rax, 757512
movq%rax, 757520
.L2:
jmp .L2
```
is the best.
[Bug target/104779] [12 Regression] ICE: in extract_insn, at recog.cc:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104779
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3bd11f791e08a5676f176d632c729d147f12dcaa
commit r12-7509-g3bd11f791e08a5676f176d632c729d147f12dcaa
Author: Jakub Jelinek
Date: Mon Mar 7 09:40:51 2022 +0100
i386: Fix up cond_{and,ior,xor,mul}* [PR104779]
The following testcase ICEs, because the cond_andv* expander
has vector_operand predicates in both of the commutative inputs
and calls gen_andv*_mask which calls ix86_binary_operator_ok
in its condition, but nothing calls ix86_fixup_binary_operands_no_copy
during the expansion, which means cond_* accepts even operands
like 2 MEMs which then can't be matched.
The following patch handles it like most other insns that the other
cond_* patterns use - by having a separate define_expand that calls
ix86_fixup_binary_operands_no_copy and define_ins with
ix86_binary_operator_ok.
2022-03-07 Jakub Jelinek
PR target/104779
* config/i386/sse.md (avx512dq_mul3): New
define_expand pattern. Rename define_insn to ...
(*avx512dq_mul3): ... this.
(3_mask): New any_logic define_expand pattern.
(3): Rename to ...
(*3): ... this.
* gcc.target/i386/pr104779.c: New test.
[Bug target/104779] [12 Regression] ICE: in extract_insn, at recog.cc:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104779 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug middle-end/104800] reodering of potentially trapping operations and volatile stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800 --- Comment #6 from Richard Biener --- Generally GCCs middle-end considers volatile stores (or loads) to not have any side-effects that are not visible in the IL. That includes (synchronous) raise of signals (and thus effects on control flow), effects on other (non-volatile) memory, etc. If a volatile access has to be considered having an effect on control flow then the standard should explicitely mention that, I don't think it does that at the moment, it merely says those statements invoke "changes in the state of the execution environment" So volatile "issues" like this are no different from issues that arise with respect to observability when you consider asynchronous events and the effect of re-ordering of statements. In fact C17 especially notes that objects that are not volatile sig_atomic_t have unspecified value on such events, so that IMHO also covers generating a trap from a volatile access. Volatile accesses are deemed observable but we do not re-order those, this bug is about re-ordering unrelated stmts with respect to such accesses. I don't think the standard requires us to fix this reported behavior. A mitigation in the middle-end requires volatile accesses to behave as possibly altering control flow. That's iffy if they continue to be represented as simple assign statements, the closest would be to always mark them as possibly trapping (something we cannot do right now). The PRE "fix" is just covering up a single place in the compiler that fails to consider volatile accesses as altering control flow.
[Bug c++/104806] Weird error message: did you mean "__dt "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104806 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-03-07 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Version|unknown |12.0
[Bug libstdc++/104807] [12 Regression] x86_64-w64-mingw32 target does not have visibility setting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104807 Richard Biener changed: What|Removed |Added Summary|x86_64-w64-mingw32 target |[12 Regression] |does not have visibility|x86_64-w64-mingw32 target |setting |does not have visibility ||setting Keywords||build Component|target |libstdc++ Target Milestone|--- |12.0
[Bug target/101929] [12 Regression] r12-7319 regress x264_r by 4% on CLX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101929
--- Comment #9 from rguenther at suse dot de ---
On Mon, 7 Mar 2022, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101929
>
> --- Comment #8 from Hongtao.liu ---
> (In reply to Richard Biener from comment #7)
> > Another change to mute the effect somewhat (but not fixing x264) that was
> > mentioned is
> >
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index b2bf90576d5..acf2cc977b4 100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -22595,7 +22595,7 @@ ix86_builtin_vectorization_cost (enum
> > vect_cost_for_stmt type_of_cost,
> >case vec_construct:
> > {
> > /* N element inserts into SSE vectors. */
> > - int cost = TYPE_VECTOR_SUBPARTS (vectype) * ix86_cost->sse_op;
> > + int cost = (TYPE_VECTOR_SUBPARTS (vectype) - 1) *
> > ix86_cost->sse_op;
> n - 1 is right for 128-bit vector, but for 256-bit vector, shouldn't it be n -
> 2, since we have a separate cost for vinserti128, and n - 4 for 512-bit one.
True! Note that without SLP the gpr->xmm move cost is not yet accounted
for (for loops the cases where we will need an actual gpr->xmm move
will be restricted to CTORs emitted in the prologue - in-loop cases
will always come from memory, so it might not be too important to get
that correct for the non-SLP case).
[Bug middle-end/104763] [12 Regression] Generate wrong assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #9 from Richard Biener --- OK, thanks for confirming. There is an issue in DSE but all aspects should be tracked by PR85803 already.
[Bug ipa/104813] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in adjust_references_in_caller, at ipa-cp.cc:4963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104813 Richard Biener changed: What|Removed |Added Version|unknown |12.0 Summary|ICE on valid code at -O3 on |[12 Regression] ICE on |x86_64-linux-gnu: in|valid code at -O3 on |adjust_references_in_caller |x86_64-linux-gnu: in |, at ipa-cp.cc:4963 |adjust_references_in_caller ||, at ipa-cp.cc:4963 Target Milestone|--- |12.0 Keywords||ice-on-valid-code, ||needs-bisection
[Bug target/99297] wrong diagnostic style in rx.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99297 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:024bdd2262c60f35cde8c860040d6d0cbb5c7b6e commit r12-7510-g024bdd2262c60f35cde8c860040d6d0cbb5c7b6e Author: Martin Liska Date: Mon Mar 7 10:33:57 2022 +0100 rx: Fix translation string. PR target/99297 gcc/ChangeLog: * config/rx/rx.cc (rx_expand_builtin_mvtc): Fix translation string.
[Bug target/99297] wrong diagnostic style in rx.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99297 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 99297, which changed state. Bug 99297 Summary: wrong diagnostic style in rx.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99297 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug translation/90148] Closing quote in wrong position in plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148
--- Comment #9 from Martin Liška ---
(In reply to Roland Illig from comment #2)
> From m68k.c:
>
> error ("%<-mpcrel%> %<-fPIC%> is not currently supported on selected
> cpu");
What's bad about this, these are 2 options where we want to quote each of them.
[Bug rtl-optimization/104814] New: [10/11/12 Regression] ifcvt: Deleting live variable in IF-CASE-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814
Bug ID: 104814
Summary: [10/11/12 Regression] ifcvt: Deleting live variable in
IF-CASE-2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390x-*-*
Created attachment 52570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52570&action=edit
dump ce2
short a = 0;
static long b = 0;
int c = 7;
char d = 0;
short *e = &a;
long f = 0;
unsigned long g (unsigned long h, long j) { return j == 0 ? h : h / j; }
int main (void) {
long k = f;
for (; c; --c) {
for (int i = 0; i < 7; ++i)
;
long m = g (f, --b);
d = ((char)m | *e) <= 43165;
}
if (b != -7)
__builtin_abort ();
return 0;
}
Variable b should be decremented in each iteration of the outer loop and thus
equal -7 at the end.
After combine a load, decrement, and store insn exists:
(insn 13 12 14 3 (set (reg:DI 62 [ b_lsm.16 ])
(mem/c:DI (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags
0x182])
(const_int 8 [0x8]))) [1 b+0 S8 A64])) 1469 {*movdi_64}
(nil))
(jump_insn 40 39 46 6 (parallel [
(set (pc)
(if_then_else (ne (reg:DI 62 [ b_lsm.16 ])
(const_int 1 [0x1]))
(label_ref 38)
(pc)))
(set (reg:DI 62 [ b_lsm.16 ])
(plus:DI (reg:DI 62 [ b_lsm.16 ])
(const_int -1 [0x])))
(clobber (scratch:DI))
(clobber (reg:CC 33 %cc))
]) "t.c":8:63 2164 {doloop_di}
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(int_list:REG_BR_PROB 536870916 (nil)))
-> 38)
(insn 48 47 49 7 (set (mem/c:DI (const:DI (plus:DI (symbol_ref:DI
("*.LANCHOR0") [flags 0x182])
(const_int 8 [0x8]))) [1 b+0 S8 A64])
(reg:DI 62 [ b_lsm.16 ])) 1469 {*movdi_64}
(expr_list:REG_DEAD (reg:DI 62 [ b_lsm.16 ])
(nil)))
Pass ce2 deletes jump insn 40 including the decrement of variable b:
IF-CASE-2 found, start 6, else 4
deleting insn with uid = 40.
deleting block 4
Conversion succeeded on pass 1.
Thus variable b equals 0 in the end.
[Bug rtl-optimization/104814] [10/11/12 Regression] ifcvt: Deleting live variable in IF-CASE-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814 --- Comment #1 from Stefan Schulze Frielinghaus --- Created attachment 52571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52571&action=edit dump combine
[Bug translation/90148] Closing quote in wrong position in plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:d73ae7a72a9bcac6a8b031cd902630eaeddf577e commit r12-7511-gd73ae7a72a9bcac6a8b031cd902630eaeddf577e Author: Martin Liska Date: Mon Mar 7 10:41:11 2022 +0100 Fix translation strings. PR translation/90148 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_linux64_override_options): Put quote to a proper place. * plugin.cc (default_plugin_dir_name): Likewise. gcc/fortran/ChangeLog: * intrinsic.cc (gfc_is_intrinsic): Put quote to a proper place.
[Bug translation/90148] Closing quote in wrong position in plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Martin Liška --- Should be fixed now.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 90148, which changed state. Bug 90148 Summary: Closing quote in wrong position in plugin.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/104806] Weird error message: did you mean "__dt "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104806 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 52572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52572&action=edit gcc12-pr104806.patch Untested fix.
[Bug rtl-optimization/104814] [10/11/12 Regression] ifcvt: Deleting live variable in IF-CASE-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4
[Bug translation/90148] Closing quote in wrong position in plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- (In reply to Roland Illig from comment #5) > From fortran/intrinsic.c: > > gfc_warning_now (OPT_Wintrinsics_std, "The intrinsic %qs at %L is not " >"included in the selected standard but %s and %qs will" >" be treated as if declared EXTERNAL. Use an" >" appropriate %<-std=%>* option or define" >" %<-fall-intrinsics%> to allow this intrinsic.", >sym->name, &loc, symstd, sym->name); > > After the "-std=". There is nothing wrong on that. -std= is the literal option name, * is there just a wildcard (anything after it). We don't want users to type -std=* literally.
[Bug translation/90148] Closing quote in wrong position in plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148 --- Comment #13 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:93ecb25cc63f92d12821f8e5186bf165a4f54ab3 commit r12-7512-g93ecb25cc63f92d12821f8e5186bf165a4f54ab3 Author: Martin Liska Date: Mon Mar 7 11:02:15 2022 +0100 translation: small fixes PR translation/90148 gcc/fortran/ChangeLog: * intrinsic.cc (gfc_is_intrinsic): Remove asterisk from error message. gcc/ChangeLog: * plugin.cc (default_plugin_dir_name): Remove from error message.
[Bug target/104775] [9/10/11/12 Regression] Failure to assemble on s390x with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104775 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2472dcaa8cb9e02e902f83d419c3ee7e0f3d9041 commit r12-7513-g2472dcaa8cb9e02e902f83d419c3ee7e0f3d9041 Author: Jakub Jelinek Date: Mon Mar 7 11:14:04 2022 +0100 s390: Fix up *cmp_and_trap_unsigned_int constraints [PR104775] The following testcase fails to assemble due to clgte %r6,0(%r1,%r10) insn not being accepted by assembler. My rough understanding is that in the RSY-b insn format the spot in other formats used for index registers is used instead for M3 what kind of comparison it is, so this patch follows what other similar instructions use for constraint (i.e. one without index register). 2022-03-07 Jakub Jelinek PR target/104775 * config/s390/s390.md (*cmp_and_trap_unsigned_int): Use S constraint instead of T in the last alternative. * gcc.target/s390/pr104775.c: New test.
[Bug target/104775] [9/10/11 Regression] Failure to assemble on s390x with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104775 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2022-03-07 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |Failure to assemble on |Failure to assemble on |s390x with |s390x with |-fsanitize=undefined|-fsanitize=undefined --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/104815] New: [nvptx] Use bitbucket operand when REG_UNUSED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104815
Bug ID: 104815
Summary: [nvptx] Use bitbucket operand when REG_UNUSED
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this source code:
...
enum memmodel
{
MEMMODEL_RELAXED = 0
};
unsigned long long int *p64;
unsigned long long int v64;
int
main()
{
__atomic_fetch_add (p64, v64, MEMMODEL_RELAXED);
return 0;
}
...
It results in this code:
...
{
.reg.u32 %value;
.reg.u64 %r25;
.reg.u64 %r26;
.reg.u64 %r27;
ld.global.u64 %r25, [p64];
ld.global.u64 %r27, [v64];
atom.add.u64%r26, [%r25], %r27;
mov.u32 %value, 0;
st.param.u32[%value_out], %value;
ret;
}
...
We can however do:
...
atom.add.u64_, [%r25], %r27;
...
because %r26 is not used anywhere.
We can detect this situation in the insn by finding a reg-note:
...
/* Identifies a register set in this insn and never used. */
REG_NOTE (UNUSED)
...
Currently testing this code:
...
diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index c6cec0c27c22..c7223737cca5 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -538,7 +538,15 @@ output_reg (FILE *file, unsigned regno, machine_mode
inner_mode,
if (HARD_REGISTER_NUM_P (regno))
fprintf (file, "%s", reg_names[regno]);
else
- fprintf (file, "%%r%d", regno);
+ {
+ rtx reg = regno_reg_rtx[regno];
+ if (current_output_insn
+ && (find_reg_note (current_output_insn, REG_UNUSED, reg)
+ != NULL_RTX))
+ fprintf (file, "_");
+ else
+ fprintf (file, "%%r%d", regno);
+ }
}
else if (subreg_offset >= 0)
{
...
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 --- Comment #6 from Martin Liška --- (In reply to Roland Illig from comment #1) > From arm-builtins.cc: > > "the range of count should be in 0 to 32; > > please check the intrinsic %<_mm_rori_pi16%> in code" > > While here, please double-check whether the "0 to 32" is a typo and should > rather be "0 to 16". That would match the "0 to 64" for _mm_rori_si64 a few > lines further down. I've just sent patch for this and c#0: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591277.html
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-03-07 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug ipa/104813] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in adjust_references_in_caller, at ipa-cp.cc:4963 since r12-2523-g13586172d0b70c9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104813 Martin Liška changed: What|Removed |Added Summary|[12 Regression] ICE on |[12 Regression] ICE on |valid code at -O3 on|valid code at -O3 on |x86_64-linux-gnu: in|x86_64-linux-gnu: in |adjust_references_in_caller |adjust_references_in_caller |, at ipa-cp.cc:4963 |, at ipa-cp.cc:4963 since ||r12-2523-g13586172d0b70c9d Keywords|needs-bisection | Priority|P3 |P1 Ever confirmed|0 |1 CC||jamborm at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-03-07 --- Comment #2 from Martin Liška --- Started with r12-2523-g13586172d0b70c9d.
[Bug target/104796] ABI change is not mentioned in HTML changelog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104796 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-03-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:cfb46c944e8a05653c7eedd79116dae9ce7ad91c commit r12-7514-gcfb46c944e8a05653c7eedd79116dae9ce7ad91c Author: Martin Liska Date: Mon Mar 7 10:56:43 2022 +0100 translation: reuse string and use switch for codes PR target/104794 gcc/ChangeLog: * config/arm/arm-builtins.cc (arm_expand_builtin): Reuse error message. Fix ARM_BUILTIN_WRORHI and ARM_BUILTIN_WRORH that can have only range [0,32].
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:fcc48d2ed6b621f7d0c141afed81a4922c056039 commit r12-7515-gfcc48d2ed6b621f7d0c141afed81a4922c056039 Author: Martin Liska Date: Mon Mar 7 11:25:18 2022 +0100 arm: fix option quoting in error messages. PR target/104794 gcc/ChangeLog: * config/arm/arm.cc (arm_option_override_internal): Fix quoting of options in error messages. (arm_option_reconfigure_globals): Likewise.
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška --- Fixed now.
[Bug target/104795] inconsistent wording in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104795 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-03-07 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW
[Bug target/104795] inconsistent wording in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104795
--- Comment #2 from Jonathan Wakely ---
It's still there, but split across two lines:
../gcc/config/i386/i386-options.cc: error
("%<-mpreferred-stack-boundary%> is not supported "
[Bug target/104796] ABI change is not mentioned in HTML changelog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104796 --- Comment #2 from Jakub Jelinek --- I was waiting if some other target also decides about what to do for PR102024 (that is why that P1 is still open). Because right now it is an ABI change on many targets and it would be nice not to change the ABI again in GCC 13...
[Bug target/104797] too many parentheses in diagnostic for __delay_cycles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104797 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:40c1d4a07e5798c01e4364336c9617550744861d commit r12-7516-g40c1d4a07e5798c01e4364336c9617550744861d Author: Martin Liska Date: Mon Mar 7 11:41:52 2022 +0100 MSP430: fix error message. PR target/104797 gcc/ChangeLog: * config/msp430/msp430.cc (msp430_expand_delay_cycles): Remove parenthesis from built-in name.
[Bug target/104797] too many parentheses in diagnostic for __delay_cycles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104797 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 104797, which changed state. Bug 104797 Summary: too many parentheses in diagnostic for __delay_cycles https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104797 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/104792] Wunused-local-typedefs with typedef/type alias defined in struct that is defined in a function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104792 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jonathan Wakely --- This is PR 61596, specifically PR 61596 comment 5. *** This bug has been marked as a duplicate of bug 61596 ***
[Bug c++/61596] -Wunused-local-typedefs warns incorrectly on a typedef that's referenced indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61596 Jonathan Wakely changed: What|Removed |Added CC||arthur.j.odwyer at gmail dot com --- Comment #7 from Jonathan Wakely --- *** Bug 104792 has been marked as a duplicate of this bug. ***
[Bug c++/104809] Explain ELRoND to translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104809 --- Comment #2 from Jonathan Wakely --- (In reply to Roland Illig from comment #0) > From cp/module.cc: > > not Encapsulated Lazy Records of Named Declarations > > Is this message trying to be funny? Yes. The ELROND format is a pun related to the ELF and DWARF formats. > As the German translator, I got the > abbreviation, but according to a Google search the GCC source code is the > only place where it is used. It's a GCC-specific format for the C++ modules implementation. > I don't think that elves and dwarfs only live in Middle Earth, and that the > diagnostic thus discriminates elves living in other parts of the world of > the universe, whichever is more inclusive. :-) > > Please add a /* TRANSLATORS */ comment above this message, detailing how > close to the words I should translate this message or whether a simple > "There are no elfs in this forest" is enough. No, I don't have humor. This > is GCC, not an RPG, so I strongly prefer clear, actionable diagnostics. I like Andrew's suggestion. I agree with him that those errors will be rarely seen by users. The files are generated and consumed by GCC, it's unlikely anybody will feed invalid files to GCC and see that error.
[Bug tree-optimization/104789] [12 Regression] New -Wstringop-overflow false positive since r12-5863-g9354a7d70caef1c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104789 Rémi Verschelde changed: What|Removed |Added CC||rverschelde at gmail dot com --- Comment #4 from Rémi Verschelde --- I'm not familiar with the term "bounded roo". I reduced the test case as much as I could to focus on the minimal code that would trigger the warning which seems to me like a false positive - is it not one? I can try to include all the relevant code to do marshalling but it seems to me that it will just make the test case more complex - while the minimal one does reproduce an issue with the same symptoms.
[Bug tree-optimization/85803] [9/10/11/12 Regression] DSE removes live global store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85803 --- Comment #10 from Richard Biener --- Created attachment 52573 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52573&action=edit prototype patch The testcase in the description isn't very good, it instead relies on traps being observable as opposed to EH. The attached prototype thus doesn't fix it but it might fix cases where we run into a function ending stmt that lacks virtual operands. It might also help producing a region-based DSE (which suffers from "leakage" unless exit VOPs are speficied and handled).
[Bug tree-optimization/104782] [12 regression] ICE: verify_gimple failed in slp (non-trivial conversion in ‘ssa_name’) with -msve-vector-bits=128 since r12-7359-g6e80c4f1ad9046b0a7c105660cc7b3dcae0fdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104782 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5db1d7f143c77543ae7a6c4649af3e611061e0d9 commit r12-7517-g5db1d7f143c77543ae7a6c4649af3e611061e0d9 Author: Richard Biener Date: Mon Mar 7 11:11:44 2022 +0100 tree-optimization/104782 - adjust PR101636 fix This reverts the reversion of r10-5979 amending the CTOR case with a comment as to why the conversion is not necessary there. It also adds a testcase (but not for the CTOR case). 2022-03-07 Richard Biener PR tree-optimization/104782 * tree-vect-slp.cc (vectorize_slp_instance_root_stmt): Re-instantiate r10-5979 fix, add comment. * gcc.dg/vect/pr104782.c: New testcase.
[Bug libstdc++/104807] [12 Regression] x86_64-w64-mingw32 target does not have visibility setting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104807 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-03-07
[Bug tree-optimization/104782] [12 regression] ICE: verify_gimple failed in slp (non-trivial conversion in ‘ssa_name’) with -msve-vector-bits=128 since r12-7359-g6e80c4f1ad9046b0a7c105660cc7b3dcae0fdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104782 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Blocks||101636 Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101636 [Bug 101636] [11 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr')
[Bug tree-optimization/101636] [11 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101636 Bug 101636 depends on bug 104782, which changed state. Bug 104782 Summary: [12 regression] ICE: verify_gimple failed in slp (non-trivial conversion in ‘ssa_name’) with -msve-vector-bits=128 since r12-7359-g6e80c4f1ad9046b0a7c105660cc7b3dcae0fdb8f https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104782 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/104816] New: -fcf-protection=branch should generate endbr instead of notrack jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816 Bug ID: 104816 Summary: -fcf-protection=branch should generate endbr instead of notrack jumps Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: joao at overdrivepizza dot com Target Milestone: --- When -fcf-protection=branch is used, the compiler will generate jump tables where the indirect jump is prefixed with the NOTRACK prefix, so it can jump to non-ENDBR targets. Yet, for NOTRACK prefixes to work, the NOTRACK specific enable bit must be set, what renders the binary broken on any environment where this is not the case. In fact, having NOTRACK disabled was a design choice for the Linux kernel CET support [https://lkml.org/lkml/2022/3/7/1068]. With the above, the compiler should generate jump tables with ENDBRs, for proper correctness. And, if security regarding the additional ENDBRs is a concern, the code can be explicitly compiled with -fno-jump-tables.
[Bug c++/104788] ICE in stmts_are_full_exprs_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104788
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
CC||marxin at gcc dot gnu.org
--- Comment #2 from Martin Liška ---
Reduced to:
cat pr104788.ii
template
struct integral_constant {
static constexpr int value = __v;
};
using true_type = integral_constant;
using false_type = integral_constant;
template
struct __success_type {
typedef _Tp type;
};
template
using __void_t = void;
template
_Up __declval(int);
template
auto declval() -> decltype(__declval<_Tp>(0));
template
struct remove_cv {
using type = _Tp;
};
template
struct __result_of_impl;
struct __result_of_other_impl {
template
static __success_type _S_test(int);
};
template
struct __result_of_impl
: __result_of_other_impl {
typedef decltype(_S_test<_Functor, _ArgTypes...>(0)) type;
};
template
struct __invoke_result : __result_of_impl::type {};
template
struct __detector {
using type = _Default;
};
template class>
using __detected_or = __detector<_Default>;
template class _Op>
using __detected_or_t = __detected_or<_Default, _Op>::type;
template
struct __is_invocable_impl;
template
struct __is_invocable_impl<_Result, _Ret, __void_t>
: true_type {};
template
using invoke_result_t = __invoke_result<_Fn, _Args...>::type;
template
struct is_invocable
: __is_invocable_impl<__invoke_result<_Fn, _ArgTypes...>, void> {};
template
constexpr bool is_same_v = __is_same(_Tp, _Up);
template
constexpr bool is_invocable_v = is_invocable<_Fn, _Args...>::value;
template
using remove_cvref_t = remove_cv<_Tp>::type;
template
using __cond_res = decltype(declval<_Yp()>()());
template
struct common_reference;
template
using common_reference_t = common_reference<_Tp...>::type;
template
struct common_reference<_Tp1, _Tp2> {
using type = __cond_res;
};
namespace __detail {
template
concept __same_as = is_same_v<_Tp, _Up>;
}
template
concept same_as = __detail::__same_as<_Up, _Tp>;
template
concept common_reference_with =
same_as, common_reference_t<_Tp, _Up>>;
namespace __detail {
template
using __cref = _Tp;
template
concept __weakly_eq_cmp_with = requires(_Tp __t, _Up __u) {
__u != __t;
};
} // namespace __detail
template
concept equality_comparable = __detail::__weakly_eq_cmp_with<_Tp, _Tp>;
template
concept equality_comparable_with =
common_reference_with<__detail::__cref<_Tp>, __detail::__cref<_Up>> &&
equality_comparable<
common_reference_t<__detail::__cref<_Tp>, __detail::__cref<_Up>>>;
template
concept totally_ordered_with = equality_comparable_with<
_Tp, common_reference_t<__detail::__cref<_Tp>, __detail::__cref<_Up>>>;
template
concept invocable = is_invocable_v<_Fn, _Args...>;
template
concept regular_invocable = invocable<_Fn, _Args...>;
template
concept predicate = regular_invocable<_Fn, _Args...>;
template
concept relation = predicate<_Rel, _Up, _Tp>;
template
concept strict_weak_order = relation<_Rel, _Tp, _Up>;
template
struct iterator_traits;
struct identity {
template
_Tp operator()(_Tp);
};
struct less {
template
requires totally_ordered_with<_Tp, _Up>
bool operator()(_Tp, _Up);
};
namespace __detail {
template
concept __dereferenceable = requires(_Tp __t) {
__t;
};
} // namespace __detail
template <__detail::__dereferenceable _Tp>
using iter_reference_t = decltype(*_Tp());
namespace __detail {
template
using __iter_value_t = _Tp ::value_type;
}
template
using iter_value_t = __detail::__iter_value_t<_Tp>;
namespace __detail {
template
concept __indirectly_readable_impl = common_reference_with<_In, _In>;
}
template
concept indirectly_readable = __detail::__indirectly_readable_impl<_In>;
template
using iter_common_reference_t = common_reference_t<_Tp, iter_value_t<_Tp>>;
template
concept random_access_iterator = requires(_Iter __n) {
__n;
};
template
concept indirectly_regular_unary_invocable =
common_reference_with,
invoke_result_t<_Fn, _Iter>>;
template
concept indirect_strict_weak_order =
strict_weak_order<_Fn, iter_common_reference_t<_I1>, _I2>;
template
using indirect_result_t = invoke_result_t<_Fn, iter_reference_t<_Is>...>;
template _Proj>
struct projected {
using value_type = remove_cvref_t>;
};
template
concept sortable = indirect_strict_weak_order<_Rel, projected<_Iter, _Proj>>;
namespace ranges::__cust_access {
template
auto __begin(_Tp __t) {
return __t.begin();
}
} // namespace ranges::__cust_access
namespace __detail {
template
using __range_iter_t = decltype(ranges::__cust_access::__begin(_Tp()));
}
template
struct iterator_traits<_Tp *> {
using reference = _Tp;
};
template
struct __normal_iterator {
iterator_traits<_Iterator>::reference operator*();
};
template
struct allocator {
typedef _Tp value_type;
}
[Bug tree-optimization/104789] [12 Regression] New -Wstringop-overflow false positive since r12-5863-g9354a7d70caef1c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104789 --- Comment #5 from Andrew Pinski --- (In reply to Rémi Verschelde from comment #4) > I'm not familiar with the term "bounded roo". I reduced the test case as > much as I could to focus on the minimal code that would trigger the warning > which seems to me like a false positive - is it not one? roo was a typo for too. The r and t are next to each other on the standard qwerty keyboard. Anyways I think the warning should be reworded to say might be writing instead of a definite. There is another bug talking about the wording too. Also the way I read the code in both the original and reduced testcase, without knowing how components' range, there could be a buffer overflow.
[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816 --- Comment #1 from Joao Moreira --- quick reproducer, just in case: https://godbolt.org/z/EaG3rhrnj
[Bug target/104817] New: mips: ICE with -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817
Bug ID: 104817
Summary: mips: ICE with -fzero-call-used-regs=all
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at mengyan1223 dot wang
Target Milestone: ---
$ echo 'int t() {}' | /home/xry111/git-repos/gcc-test-mips/gcc/cc1 -nostdinc
-fzero-call-used-regs=all
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 1208k} {heap 1208k}
{heap 1208k} {heap 1208k} {heap 1208k}
{heap 1208k} {heap 1208k} {heap
1208k}Streaming LTO
{heap 1208k} {heap 1208k} {heap 1208k}
{heap 1208k} {heap 1208k} {heap
1208k}Assembling functions:
tduring RTL pass: final
: In function ‘t’:
:1:10: internal compiler error: in mips_output_move, at
config/mips/mips.cc:5323
0x1834ac9 mips_output_move(rtx_def*, rtx_def*)
../../gcc/gcc/config/mips/mips.cc:5323
0x1ead799 output_313
../../gcc/gcc/config/mips/mips.md:4771
0xe21260 get_insn_template(int, rtx_insn*)
../../gcc/gcc/final.cc:2047
0xe234ab final_scan_insn_1
../../gcc/gcc/final.cc:2827
0xe23933 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.cc:2940
0xe21086 final_1
../../gcc/gcc/final.cc:1997
0xe264d5 rest_of_handle_final
../../gcc/gcc/final.cc:4285
0xe26834 execute
../../gcc/gcc/final.cc:4363
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/104817] mips: ICE with -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817 --- Comment #1 from Xi Ruoyao --- Not sure if this is an regression: it triggers another ICE with 11.2.0.
[Bug target/104817] mips: ICE with -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817 Xi Ruoyao changed: What|Removed |Added Target||mips64 Known to fail||12.0 --- Comment #2 from Xi Ruoyao --- It seems mips_output_move is called to "move" a const zero to the hi (!) register :(.
[Bug tree-optimization/104789] [12 Regression] New -Wstringop-overflow false positive since r12-5863-g9354a7d70caef1c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104789
--- Comment #6 from Rémi Verschelde ---
Indeed if the warning was reworded to make it clear that it's a risk and not a
certainty would solve this.
Both the reduced test case and the original code are both risky: `components`
is an `uint32_t` that is set to either 1 or 3, so in the context of that code
`header_bytes` would never exceed 8.
But if this was changed to anything higher than 3 then yes, there would be a
buffer overflow. If this is what this warning aims to warn about (the risk of
buffer overflow and not the certainty of one), then there's probably no false
positive.
Adding:
```
if (components > 3) {
return 0;
}
```
to the reduced testcase does prevent the warning.
On the other hand, the same kind of check doesn't seem to solve the warning in
the original Godot case, so you're right about the reduced testcase being too
reduced. I'll dig further and see if I can make a better testcase, or
understand why a check on `components` (or even `header_bytes > 7`) isn't
sufficient in Godot.
[Bug tree-optimization/98335] [9/10/11/12 Regression] Poor code generation for partial struct initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98335 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com Status|NEW |ASSIGNED --- Comment #7 from Roger Sayle --- Patches proposed (one middle-end and one backend). https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591273.html https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591285.html
[Bug c++/96329] [11/12 Regression] ICE : tree check: expected string_cst, have error_mark in cp_parser_linkage_specification, at cp/parser.c:14640
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96329 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED CC||roger at nextmovesoftware dot com Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #4 from Roger Sayle --- Patch proposed. https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591291.html
[Bug c++/96437] [10/11/12 Regression] ICE in tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in synthesize_implicit_template_parm, at cp/parser.c:44246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96437 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED CC||roger at nextmovesoftware dot com Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #3 from Roger Sayle --- Patch proposed. https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591292.html
[Bug c++/96440] [9/10/11/12 Regression] ICE in tree check: expected tree_list, have error_mark in get_attribute_name, at attribs.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96440 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #4 from Roger Sayle --- Patch proposed. https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591293.html
[Bug c++/104803] if consteval error from branch that isn't evaluated anyway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104803 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Sure, the first branch of if consteval is immediate function context and therefore p(i) at line 5 is not an immediate invocation. But the p(i) at line 9 is not in an immediate function context and because it calls an immediate function (operator () of the lambda), it is an immediate invocation and because i at that point is not constant, it should be rejected. This is diagnosed during the instantiation of the function template, not during constant evaluation of the function template. And IMHO it should be diagnosed even if you don't cal none_of at all, just instantiate it (if it wouldn't be a template, even when just parsed). So yes, I agree clang is buggy because it diagnoses it even on line 5. Note, I'm not a C++ lawyer, but the consteval and if consteval implementation was done on the assumption it is like that.
[Bug c++/104798] Regression: [[gnu::always_inline]] ignored on lambda, no warning emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104798 Martin Liška changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93530 Last reconfirmed||2022-03-07 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- The warning is gone since r10-6397-gb817be038d94c987.
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:b1d8198e7df616ea80cb648a2c831e2c21f4319f commit r12-7518-gb1d8198e7df616ea80cb648a2c831e2c21f4319f Author: Martin Liska Date: Mon Mar 7 14:16:21 2022 +0100 arm: add missing space to error. PR target/104794 gcc/ChangeLog: * config/arm/arm.cc (arm_option_override_internal): Add missing space.
[Bug target/104818] Duplicate word "version" in option -mptx description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104818 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||vries at gcc dot gnu.org Last reconfirmed||2022-03-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug fortran/104819] New: Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819
Bug ID: 104819
Summary: Reject NULL without MOLD as actual to an assumed-rank
dummy
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
[Found when looking at PR 104126]
Cf. https://mailman.j3-fortran.org/pipermail/j3/2022-March/013584.html
call foo(null())
contains
subroutine foo(x)
integer, pointer, intent(in) :: x(..)
print *, rank(x)
end subroutine
end
I believe this should be rejected as the rank is not known without a MOLD.
* * *
The following is also invalid because of
"If any type parameters of the contextual entity are assumed, MOLD shall be
present."
("16.9.155 NULL ([MOLD])"):
call foo(null())
contains
subroutine foo(x)
character(len=*), pointer, intent(in) :: x
end subroutine
end
[Bug target/104818] New: Duplicate word "version" in option -mptx description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104818 Bug ID: 104818 Summary: Duplicate word "version" in option -mptx description Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- In `config/nvptx/nvptx.opt` there is an error message Specify the version of the ptx version to use. https://github.com/gcc-mirror/gcc/blob/2472dcaa8cb9e02e902f83d419c3ee7e0f3d9041/gcc/config/nvptx/nvptx.opt#L80 I guess "version of version" is not what was intended.
[Bug tree-optimization/104789] [12 Regression] New -Wstringop-overflow false positive since r12-5863-g9354a7d70caef1c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104789
--- Comment #7 from Rémi Verschelde ---
Took me a while, but I was able to make a proper reduced testcase by cutting
down the Godot case to the very minimal.
It's a bit convoluted (and the code doesn't make any sense anymore), but the
complexity seems to trigger the false positive I intended to report originally.
```
$ cat godot-stringop.cpp
#include
#include
uint32_t components = 3;
void commit_temp_packets() {
// Should be sufficient?
if (components > 3) { return; }
uint8_t header[8];
uint32_t header_bytes = 0;
for (uint32_t i = 0; i < components; i++) {
header_bytes += 2;
}
uint32_t max_shifts[3] = { 0, 0, 0 };
for (uint32_t i = 1; i < 2; i++) {
for (uint32_t j = 0; j < components; j++) {
max_shifts[j] = 1;
}
}
header_bytes += 2;
// Should definitely be sufficient.
if (header_bytes > 7) { return; }
while (header_bytes % 4 != 0) {
header[header_bytes++] = 0;
}
std::vector data;
for (uint32_t i = 0; i < header_bytes; i++) {
data.push_back(header[i]);
}
uint32_t bit_buffer = 0;
uint32_t bits_used = 0;
for (uint32_t i = 1; i < 2; i++) {
for (uint32_t j = 0; j < components; j++) {
bit_buffer |= 1 << bits_used;
bits_used += max_shifts[j] + 1;
while (bits_used >= 8) {
uint8_t byte = bit_buffer & 0xFF;
data.push_back(byte);
bit_buffer >>= 8;
bits_used -= 8;
}
}
}
}
$ g++ godot-stringop.cpp -c -Werror=all -O3
godot-stringop.cpp: In function ‘void commit_temp_packets()’:
godot-stringop.cpp:29:40: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
29 | header[header_bytes++] = 0;
| ~~~^~~
godot-stringop.cpp:10:17: note: at offset 8 into destination object ‘header’ of
size 8
10 | uint8_t header[8];
| ^~
godot-stringop.cpp:29:40: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
29 | header[header_bytes++] = 0;
| ~~~^~~
godot-stringop.cpp:10:17: note: at offset [9, 11] into destination object
‘header’ of size 8
10 | uint8_t header[8];
| ^~
cc1plus: some warnings being treated as errors
```
Interestingly, there are no changes to `header_bytes` or `components` after
line 29, yet the code that follows seems needed to trigger the warning.
[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816 Richard Biener changed: What|Removed |Added Version|unknown |12.0 Severity|normal |enhancement --- Comment #2 from Richard Biener --- Documentation should probably also amended to reflect this limitation (or -fcf-protection=branch should implicitely disable jump-tables).
[Bug fortran/104696] [OpenMP] Implicit mapping breaks struct mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104696
--- Comment #2 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #1)
> Namely:
> test.c--
> struct s { int *d; };
It makes more sense to use 'int d;' to match Fortran. Doing so yields in the
gimple dump:
#pragma omp target num_teams(1) thread_limit(0)
map(struct:x [len: 1]) map(tofrom:x.q.d [len: 4])
#pragma omp target num_teams(1) thread_limit(0)
map(tofrom:x [len: 4194328][implicit]) map(tofrom:x.r[1].d [len: 4])
Thus, C and Fortran show the same issue.
[Bug ipa/104813] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in adjust_references_in_caller, at ipa-cp.cc:4963 since r12-2523-g13586172d0b70c9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104813 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Martin Jambor --- Mine.
[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-03-07 --- Comment #3 from H.J. Lu --- (In reply to Richard Biener from comment #2) > Documentation should probably also amended to reflect this limitation (or > -fcf-protection=branch should implicitely disable jump-tables). We should document this limitation and update -fno-jump-tables documentation: '-fno-jump-tables' Do not use jump tables for switch statements even where it would be more efficient than other code generation strategies. This option is of use in conjunction with '-fpic' or '-fPIC' for building code that forms part of a dynamic linker and cannot reference the address of a jump table. On some targets, jump tables do not require a GOT and this option is not needed.
[Bug target/104820] New: mips: ICE in int_mode_for_mode, at stor-layout.cc:407 with -fzero-call-used-regs=all -mips4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104820
Bug ID: 104820
Summary: mips: ICE in int_mode_for_mode, at stor-layout.cc:407
with -fzero-call-used-regs=all -mips4
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at mengyan1223 dot wang
Target Milestone: ---
May be related to PR104817, but the stack backtrace is different:
echo 'int t() {}' | /home/xry111/git-repos/gcc-test-mips/gcc/cc1 -nostdinc
-fzero-call-used-regs=all -mips4
t
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 1208k} {heap 1208k}
{heap 1208k} {heap 1208k} {heap 1208k}
{heap 1208k} {heap 1208k} {heap
1208k}Streaming LTO
{heap 1208k} {heap 1208k} {heap 1208k}
{heap 1208k} {heap 1208k} {heap
1208k}Assembling functions:
tduring RTL pass: zero_call_used_regs
: In function ‘t’:
:1:10: internal compiler error: in int_mode_for_mode, at
stor-layout.cc:407
0x13498b9 int_mode_for_mode(machine_mode)
../../gcc/gcc/stor-layout.cc:407
0xdf06ea emit_move_via_integer
../../gcc/gcc/expr.cc:3615
0xdf10ea emit_move_ccmode
../../gcc/gcc/expr.cc:3834
0xdf17ff emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc/gcc/expr.cc:3974
0xdf21ab emit_move_insn(rtx_def*, rtx_def*)
../../gcc/gcc/expr.cc:4125
0x135d39b default_zero_call_used_regs(HARD_REG_SET)
../../gcc/gcc/targhooks.cc:1040
0xe98230 gen_call_used_regs_seq
../../gcc/gcc/function.cc:5927
0xe99800 execute
../../gcc/gcc/function.cc:6697
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816 --- Comment #4 from Andrew Cooper --- I've worked around this in Xen with: https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9d4a44380d273de22d5753883cbf5581795ff24d and https://lore.kernel.org/lkml/yixpv0q88paph...@hirez.programming.kicks-ass.net/ is pending for Linux. IMO, it's an error that -fcf-protection=branch is not obeyed for jump tables, and we don't want to end up in a situation where jump tables are unusable with CET.
[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816 --- Comment #5 from H.J. Lu --- (In reply to Andrew Cooper from comment #4) > I've worked around this in Xen with: > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff; > h=9d4a44380d273de22d5753883cbf5581795ff24d and > https://lore.kernel.org/lkml/YiXpv0q88paPHPqF@hirez.programming.kicks-ass. > net/ is pending for Linux. > > IMO, it's an error that -fcf-protection=branch is not obeyed for jump > tables, and we don't want to end up in a situation where jump tables are > unusable with CET. Are you suggesting to add an option to generate jump table with ENDBR?
[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816 --- Comment #6 from peterz at infradead dot org --- (In reply to H.J. Lu from comment #5) > (In reply to Andrew Cooper from comment #4) > > I've worked around this in Xen with: > > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff; > > h=9d4a44380d273de22d5753883cbf5581795ff24d and > > https://lore.kernel.org/lkml/YiXpv0q88paPHPqF@hirez.programming.kicks-ass. > > net/ is pending for Linux. > > > > IMO, it's an error that -fcf-protection=branch is not obeyed for jump > > tables, and we don't want to end up in a situation where jump tables are > > unusable with CET. > > Are you suggesting to add an option to generate jump table with ENDBR? I would suggest having -fcf-protection=branch generate ENDBR for jump-tables and never generate NOTRACK prefix. Then add a mode that allows NOTRACK prefixes, perhaps -fcf-protection=branch,notrack. IBT without NOTRACK is the strongest form; it would be daft to require additional parameters for that.
[Bug target/104815] [nvptx] Use bitbucket operand when REG_UNUSED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104815
--- Comment #1 from Tom de Vries ---
With the tentative patch, I'm running into:
...
ptxas 2224-1.o, line 72; error : Result discard mode is not allowed for
instruction 'ld'
nvptx-as: ptxas terminated with signal 11 [Segmentation fault], core dumped
...
For:
...
{
.param.u32 %value_in;
.param.u64 %out_arg1;
st.param.u64 [%out_arg1], %r61;
call (%value_in), call_critical_lisp_code, (%out_arg1);
ld.param.u32_, [%value_in];
}
...
Now trying a more restrictive approach, using an operand modifier x, only used
on atom operations, like so:
...
- = "%.\\tatom%A1.add%t0\\t%0, %1, %2;";
+ = "%.\\tatom%A1.add%t0\\t%x0, %1, %2;";
...
[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816
--- Comment #7 from Andrew Cooper ---
(In reply to H.J. Lu from comment #5)
> Are you suggesting to add an option to generate jump table with ENDBR?
Jump tables are a legitimate optimisation. NOTRACK is a weakness in CET
protections, and fully hardened userspace (as well as kernels) will want to run
with MSR_{U,S}_CET.NOTRACK_EN=0.
There should be some future where jump tables can be used in combination with
NOTRACK_EN=0.
[Bug rtl-optimization/104814] [10/11/12 Regression] ifcvt: Deleting live variable in IF-CASE-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- What options is this with? Which isa/tuning?
[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 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:111754595cf8d3a8ae7063a42ac4cea18a304711 commit r12-7521-g111754595cf8d3a8ae7063a42ac4cea18a304711 Author: Martin Liska Date: Fri Feb 4 15:50:17 2022 +0100 opts: fix -gtoggle + optimize attribute Note -fvar-tracking is enabled automatically with OPT_LEVELS_1_PLUS and so we need to drop it if we are called from optimize attribute and the option is unset. PR middle-end/104381 gcc/ChangeLog: * opts.cc (finish_options): If debug info is disabled (debug_info_level) and -fvar-tracking is unset, disable it. gcc/testsuite/ChangeLog: * gcc.dg/pr104381.c: New test.
[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 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Liška --- Fixed.
[Bug analyzer/104821] New: RFE: consolidate analyzer leak diagnostics by considering indirect vs direct leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104821 Bug ID: 104821 Summary: RFE: consolidate analyzer leak diagnostics by considering indirect vs direct leaks Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- PR analyzer/101983 reports a pair of -Wanalyzer-malloc-leak warnings at the same program point, where both: *res and *(res->a) are leaked. This is a common case where we have a direct leak (of '*res'), leading to indirect leaks of the things *res is pointing to (of '*(res->a)'). Currently we emit all of these leak warnings, and don't distinguish between them. Idea: report the direct leaks, and consolidate all of indirect leaks as notes on the direct leaks: e.g. warning: leak of 'ptr' [...execution path here...] note: direct leak of 'ptr' leads to indirect leak of 'ptr->foo' [...execution path here? or just show the allocation point of 'ptr->foo'] note: indirect leak of 'ptr->foo' leads to indirect leak of 'ptr->foo->bar' [...etc...] where we can envisage a tree structure of leaks that are reponsible for other leaks. We could even visualize this tree with ASCII art, showing the subgraph of objects and where it becomes unreachable. Doing so could reduce the verbosity of the analyzer, making the report to the end-user a little "higher-level".
[Bug c++/104803] if consteval error from branch that isn't evaluated anyway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104803 --- Comment #6 from Barry Revzin --- Ugh, sorry. You guys are right. gcc is correct to reject the example. Bad bug report.
[Bug analyzer/104821] RFE: consolidate analyzer leak diagnostics by considering indirect vs direct leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104821
--- Comment #1 from David Malcolm ---
Example: https://godbolt.org/z/afvEd99qn
#include
struct s
{
void *m_a;
void *m_b;
void *m_c;
};
struct s *
make_s (size_t sz_a, size_t sz_b, size_t sz_c)
{
struct s *result = calloc (1, sizeof (struct s));
if (!result)
return NULL;
result->m_a = malloc (sz_a);
if (!result->m_a)
goto err;
result->m_b = malloc (sz_b);
if (!result->m_b)
goto err;
result->m_b = malloc (sz_c);
if (!result->m_c)
goto err;
return result;
err:
free (result->m_c);
free (result->m_b);
free (result->m_a);
free (result);
return NULL;
}
void test ()
{
struct s *ptr = make_s (5, 10, 15);
/* now leak ptr. */
}
This emits 4 -Wanalyzer-malloc-leak warnings with almost identical paths,
mostly just varying in the "allocated here" messages.
[Bug analyzer/104821] RFE: consolidate analyzer leak diagnostics by considering indirect vs direct leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104821 --- Comment #2 from David Malcolm --- (In reply to David Malcolm from comment #1) Copy&paste error: result->m_b = malloc (sz_c); should have been: result->m_c = malloc (sz_c);
[Bug c/104822] New: -Wscalar-storage-order warning for initialization from NULL seems useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104822
Bug ID: 104822
Summary: -Wscalar-storage-order warning for initialization from
NULL seems useless
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: ---
#include
struct S {
int i;
} __attribute__((scalar_storage_order("big-endian")));
struct S *p = NULL;
This warns on x86:
sso.c:7:15: warning: initialization of ‘struct S *’ from pointer type ‘void *’
with incompatible scalar storage order [-Wscalar-storage-order]
7 | struct S *p = NULL;
| ^~~~
This doesn't seem useful. A null pointer cannot be derferenced, so there is no
chance of undefined behaviour caused by type punning struct T { int i; } as
struct S or vice versa.
Could the warning be suppressed static init of a pointer using NULL?
[Bug libstdc++/104807] [12 Regression] x86_64-w64-mingw32 target does not have visibility setting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104807 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4cb935cb69f12088975fa7f6907c6ace0580e2dd commit r12-7522-g4cb935cb69f12088975fa7f6907c6ace0580e2dd Author: Jonathan Wakely Date: Mon Mar 7 15:07:05 2022 + libstdc++: Use visibility pragmas instead of attributes [PR104807] The _GLIBCXX_PSEUDO_VISIBILITY macro isn't defined until after including os_defines.h, so we can't use _GLIBCXX_VISIBILITY early in c++config. Replace the uses of that macro with #pragma visibility push(default) instead. libstdc++-v3/ChangeLog: PR libstdc++/104807 * include/bits/c++config (__terminate, __glibcxx_assert_fail): Replace _GLIBCXX_VISIBILITY on function with visibility pragma. (__is_constant_evaluated): Add visibility pragma.
[Bug c++/104803] if consteval error from branch that isn't evaluated anyway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104803 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Jakub Jelinek --- .
[Bug debug/104778] [12 Regression] ICE in simplify_subreg, at simplify-rtx.cc:7324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104778 --- Comment #1 from Jakub Jelinek --- Can't reproduce at least with current trunk, both with gcc configured for powerpc64-linux-gnu and additional -m32, or in a cross to powerpc-e300c3-linux-gnu with the given options.
[Bug fortran/104812] Construct-name with same variable name in scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from kargl at gcc dot gnu.org --- gfortran is correct. See Fortran 2018, 19.4, p 498. Identifiers of entities, other than statement or construct entities (19.4), in the classes (1) named variables, ..., named constructs, ..., Within its scope, a local identifier of one class shall not be the same as another local identifier of the same class,
[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104198 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #17 from Jakub Jelinek --- Is this fixed now?
[Bug c++/104823] New: [12 Regression] narrowing conversion inside non-dependent decltype operand silently accepted ever since r12-6075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104823
Bug ID: 104823
Summary: [12 Regression] narrowing conversion inside
non-dependent decltype operand silently accepted ever
since r12-6075
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
struct S { S(int); };
int id(int v);
double id(double v);
template auto f(double v) -> decltype(S{id(v)});
GCC 11 correctly issues a narrowing conversion warning for this testcase ever
since r11-434:
:6:50: warning: narrowing conversion of ‘id(v)’ from ‘double’ to ‘int’
[-Wnarrowing]
But in GCC 12 the warning is gone.
