[Bug target/108807] [11 regression] gcc.target/powerpc/vsx-builtin-10d.c fails after b29225597584b697762585e0b707b7cb4b427650 on power 9 BE

[linkw at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807

Kewen Lin  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 CC||linkw at gcc dot gnu.org
   Last reconfirmed||2023-02-16

--- Comment #1 from Kewen Lin  ---
Confirmed.

It's likely an endianess issue, I'll have a look first.

[Bug rtl-optimization/108805] [13 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7400 at -O and above

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108805

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|NEW |ASSIGNED

--- Comment #2 from Uroš Bizjak  ---
Patch in testing:

--cut here--
diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index 0a1dd88b0a8..281bc418df0 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -7664,7 +7664,7 @@ simplify_context::simplify_subreg (machine_mode
outermode, rtx op,
0).exists (_outermode))
 {
   rtx tem = simplify_subreg (int_outermode, op, innermode, byte);
-  if (tem)
+  if (tem && GET_MODE (tem) != VOIDmode)
return simplify_gen_subreg (outermode, tem, GET_MODE (tem), 0);
 }

--cut here--

[Bug tree-optimization/108791] [12 Regression] ICE: verify_gimple failed

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108791

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
   Priority|P3  |P2
Summary|[12/13 Regression] ICE: |[12 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   Keywords||ice-checking
 Status|ASSIGNED|NEW

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 15 Feb 2023, qinzhao at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
> 
> --- Comment #6 from qinzhao at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #2)
> > 
> > The gimplifier instead of
> > 
> >   _1 = t ();
> >   D.2389 = _1;
> >   e = 
> >   _2 = *e;
> >   f (_2);
> > 
> > produces
> > 
> >   _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
> >   D.2389 = _1;
> >   e = .DEFERRED_INIT (8, 2, &"e"[0]);
> >   _2 = t ();
> >   D.2389 = _2;
> >   e = 
> >   _3 = *e;
> >   f (_3);
> > 
> > which is odd and sub-optimal at least.  Doing such things makes us rely
> > on DSE to elide the uninit "inits".
> 
> actually, this is because, The simplifier sees the following  IR from FE
> (.original)
> 
> const int D.2768;
> const int & e;
>   < (void) (e = D.2768 = t ();, (const int &) ) >;
>   < f ((int) *e) >;
> }
> 
> i.e, it sees two DECL_EXPR "D.2768" and "e" without any initialization first,
> and then see the "CLEANUP_POINT_EXPR" which include the initializations to "e"
> and "D.2768". since it doesn't see any connections between these two 
> DECL_EXPRs
> and the initializations inside "CLEANUP_POINT_EXPR", it just treats the two
> DECL_EXPRs as not initialized, therefore add the .DEFERED_INIT to them.
> 
> the best approach to resolve this issue is:
> 
> if there is any connection  between DECL_EXPR "D.2768","e" and their
> initializations inside "CLEANUP_POINT_EXPR" that can be checked from IR, then
> during "gimplify_decl_expr", we can avoid generating .DEFERRED_INIT to them;
> 
> my question is: in the current IR from C++ FE, is there any bit I can check to
> make sure that the DECL_EXPR "D.2768" and "e" already have initialization
> inside "CLEANUP_POINT_EXPR"?

Hmm, I don't think so.  So this is indeed expected behavior since the
frontend IL doesn't have variable definitions with initializers but
instead just (immediately following) assignments.

[Bug tree-optimization/108791] [12/13 Regression] ICE: verify_gimple failed

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108791

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:441c466fd4d8b9afd99f585f7c4bfade911c4652

commit r13-6073-g441c466fd4d8b9afd99f585f7c4bfade911c4652
Author: Richard Biener 
Date:   Wed Feb 15 14:00:21 2023 +0100

tree-optimization/108791 - checking ICE with sloppy ADDR_EXPR

The following fixes a checking ICE by choosing a more appropriate
type for an ADDR_EXPR built by forwprop.

PR tree-optimization/108791
* tree-ssa-forwprop.cc (optimize_vector_load): Build
the ADDR_EXPR of a TARGET_MEM_REF using a more meaningful
type.

* gcc.dg/torture/pr108791.c: New testcase.

[Bug middle-end/108778] Missing optimization with direct register access instead of structure mapping

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108778

--- Comment #3 from Wilhelm M  ---
This problem is not reproducible with avr-gcc 4.5.4.

But from avr-gcc 4.6.4. the problem exists.

[Bug target/108816] New: ICE in operator[], at vec.h:889

[asolokha at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108816

Bug ID: 108816
   Summary: ICE in operator[], at vec.h:889
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gcc 13.0.1 20230212 snapshot (g:06ca0c9abb260266b688e2c2154c72214bb47076) ICEs
when compiling the following testcase w/ -mcpu=cortex-x3 -O2
-fvect-cost-model=dynamic:

int m;

void
foo (int p[][16], unsigned int x)
{
  while (x < 4)
{
  int j;

  for (j = x * 4; j < (x + 1) * 4 - 2; j++)
p[0][j] = p[m][j];

  ++x;
}
}

% aarch64-linux-gnu-gcc-13 -mcpu=cortex-x3 -O2 -fvect-cost-model=dynamic -c
ck0pb2mc.c
during GIMPLE pass: vect
ck0pb2mc.c: In function 'foo':
ck0pb2mc.c:4:1: internal compiler error: in operator[], at vec.h:889
4 | foo (int p[][16], unsigned int x)
  | ^~~
0x77eef2 vec::operator[](unsigned int)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/vec.h:889
0x77eef8 vec::operator[](unsigned int)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-cfg.cc:9409
0x77eef8 extract_true_false_edges_from_block(basic_block_def*, edge_def**,
edge_def**)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-cfg.cc:9410
0x11e6cdb vect_loop_versioning(_loop_vec_info*, gimple*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vect-loop-manip.cc:3724
0x11da221 vect_transform_loop(_loop_vec_info*, gimple*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vect-loop.cc:10767
0x121f2cf vect_transform_loops
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vectorizer.cc:1007
0x121f94c try_vectorize_loop_1
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vectorizer.cc:1153
0x121f94c try_vectorize_loop
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vectorizer.cc:1183
0x121fcf4 execute
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vectorizer.cc:1299

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096

--- Comment #13 from Hongtao.liu  ---
(In reply to rguent...@suse.de from comment #12)
> On Wed, 15 Feb 2023, crazylht at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
> > 
> > --- Comment #11 from Hongtao.liu  ---
> > 
> > > 
> > > There's no other way to do N bit to two N/2 bit hi/lo (un)packing
> > > (there's a 2x N/2 bit -> N bit operation, for whatever reason).
> > > There's also no way to transform the d rgroup mask into the
> > > f rgroup mask for the first example aka duplicate bits in place,
> > > { b0, b1, b2, ... bN } -> { b0, b0, b1, b1, b2, b2, ... bN, bN },
> > > nor the reverse.
> > > 
> > 
> > Can we just do VIEW_CONVERT_EXPR for vectype instead of mask_type.
> > .i.e
> > we can do VCE to tranform V8SI to V16HI, then use mask_load for V16HI with 
> > same
> > mask {b0, b0, b1, b1, b2, b2, .}, then VCE it to back to V8SI, it should be 
> > ok
> > as long as duplicated bits in place.(or VCE V16HI to V8SI then use mask {b0,
> > b1, b2, ..., bN}, and VCE V8SI back to V16HI after masked load/move).
> 
> Hmm, yes, if we arrange for the larger mask to be available that would
> work for loads and stores I guess.  It wouldn't work for arithmetic
> cond_* IFNs though.  It's also going to be a bit tricky within the
> masking framework - I'm going to see whether that works though, it might
> be a nice way to avoid an excessive number of masks for integer code
> at least.

There could be some limitation for nV(it should be power of 2 for VCE?)
.i.e.
There's no suitable vectype for VCE of src1 vectype to resure loop mask.
void
foo (int* __restrict dest, int* src1, int* src2)
{
for (int i = 0; i != 1; i++)
  dest[i] = src1[3*i] + src1[3*i + 1] + src1[3*i + 2];
}


Maybe AVX512 could use gather instruction for .MASK_LOAD_LANES to use
LOOP_MASK?

[Bug c++/108811] add enum annotation for switch statements

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108811

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-02-15
 Status|UNCONFIRMED |NEW

[Bug c/108375] [10/11/12/13 Regression] Some variably modified types not detected as such

[muecker at gwdg dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375

Martin Uecker  changed:

   What|Removed |Added

  Attachment #54458|0   |1
is obsolete||

--- Comment #7 from Martin Uecker  ---
Created attachment 54473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54473=edit
patch against trunk


This patch should be better. It is a FE only change. It stores uses a LANG_FLAG
for each type to store whether it is a VM type which is set during
construction. This should be very efficient. The existing (previously useless)
lang hook then also communicates this information to the middle end. The
variably_modified_p function in tree.cc now does unnecessary work for C, maybe
this could be avoided.

[Bug target/97795] internal compiler error: in i386_pe_seh_unwind_emit

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97795
Bug 97795 depends on bug 90458, which changed state.

Bug 90458 Summary: [10/11/12/13 Regression] mingw64: ICE in 
i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with 
-fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/90458] [10/11/12/13 Regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|10.5|11.4
 Resolution|--- |FIXED

--- Comment #12 from Eric Botcazou  ---
Fixed on mainline, 12 and 11 branches.

[Bug target/90458] [10/11/12/13 Regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:20c12f40f9b10eb290fcfe4d02f3367842be573a

commit r11-10527-g20c12f40f9b10eb290fcfe4d02f3367842be573a
Author: Eric Botcazou 
Date:   Wed Feb 15 23:32:12 2023 +0100

Fix PR target/90458

This is the incompatibility of -fstack-clash-protection with Windows SEH.
Now the Windows ports always enable TARGET_STACK_PROBE, which means that
the stack is always probed (out of line) so -fstack-clash-protection does
nothing more.

gcc/
PR target/90458
* config/i386/i386.c (ix86_compute_frame_layout): Disable the
effects of -fstack-clash-protection for TARGET_STACK_PROBE.
(ix86_expand_prologue): Likewise.

[Bug target/90458] [10/11/12/13 Regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:25b80834e2ce6725e676ef33fbf0d009b3173955

commit r12-9177-g25b80834e2ce6725e676ef33fbf0d009b3173955
Author: Eric Botcazou 
Date:   Wed Feb 15 23:32:12 2023 +0100

Fix PR target/90458

This is the incompatibility of -fstack-clash-protection with Windows SEH.
Now the Windows ports always enable TARGET_STACK_PROBE, which means that
the stack is always probed (out of line) so -fstack-clash-protection does
nothing more.

gcc/
PR target/90458
* config/i386/i386.cc (ix86_compute_frame_layout): Disable the
effects of -fstack-clash-protection for TARGET_STACK_PROBE.
(ix86_expand_prologue): Likewise.

[Bug target/90458] [10/11/12/13 Regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:a5dd99f7ef4fa5f9542851431bdd149a22b87fd2

commit r13-6069-ga5dd99f7ef4fa5f9542851431bdd149a22b87fd2
Author: Eric Botcazou 
Date:   Wed Feb 15 23:32:12 2023 +0100

Fix PR target/90458

This is the incompatibility of -fstack-clash-protection with Windows SEH.
Now the Windows ports always enable TARGET_STACK_PROBE, which means that
the stack is always probed (out of line) so -fstack-clash-protection does
nothing more.

gcc/
PR target/90458
* config/i386/i386.cc (ix86_compute_frame_layout): Disable the
effects of -fstack-clash-protection for TARGET_STACK_PROBE.
(ix86_expand_prologue): Likewise.

[Bug target/108815] New: gcc.target/powerpc/pr83677.c fails on power 9 BE

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108815

Bug ID: 108815
   Summary: gcc.target/powerpc/pr83677.c fails on power 9 BE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
powerpc.exp=gcc.target/powerpc/pr83677.c"
FAIL: gcc.target/powerpc/pr83677.c execution test
# of expected passes1
# of expected passes1
# of unexpected failures1
# of unexpected failures1
# of unsupported tests  1
# of unsupported tests  1

This fails on power 9 BE (only) and fails for trunk as well as gcc 12, 11, and
10.  

I get a bunch of linker errors when I try to compile this for debug.  So no
traceback, sorry!

[Bug target/108814] New: gcc.target/powerpc/pr79251-run.p9.c fails on power 9 BE

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108814

Bug ID: 108814
   Summary: gcc.target/powerpc/pr79251-run.p9.c fails on power 9
BE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
powerpc.exp=gcc.target/powerpc/pr79251-run.p9.c"
FAIL: gcc.target/powerpc/pr79251-run.p9.c execution test
# of expected passes2
# of expected passes1
# of expected passes3
# of unexpected failures1
# of unexpected failures1


This fails on power 9 BE (only) and fails for trunk as well as gcc 12 and 11.  

I couldn't get this to compile properly for debugging so no traceback, sorry!

[Bug target/108813] New: gcc.target/powerpc/pr101384-2.c fails on power 9 BE

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108813

Bug ID: 108813
   Summary: gcc.target/powerpc/pr101384-2.c fails on power 9 BE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pr101384-2.c"
FAIL: gcc.target/powerpc/pr101384-2.c scan-assembler-times \\mvspltis[whb]
[^\\n\\r]*,-1\\M 9
# of expected passes4
# of unexpected failures1

This fails on power 9 BE (only) and fails for trunk as well as gcc 12.

[Bug target/108812] New: gcc.target/powerpc/p9-sign_extend-runnable.c fails on power 9 BE

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108812

Bug ID: 108812
   Summary: gcc.target/powerpc/p9-sign_extend-runnable.c fails on
power 9 BE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make  -k check-gcc
RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/p9-sign_extend-runnable.c"
FAIL: gcc.target/powerpc/p9-sign_extend-runnable.c execution test
# of expected passes6
# of unexpected failures1

This fails on power 9 BE (only) and fails for trunk as well as gcc 12 and 11.  


(gdb) run
Starting program:
/home/seurer/gcc/git/build/gcc-test/p9-sign_extend-runnable.exe 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=,
no_tid=) at pthread_kill.c:44
44  pthread_kill.c: No such file or directory.
(gdb) where
#0  __pthread_kill_implementation (threadid=, signo=, no_tid=) at pthread_kill.c:44
#1  0x77c90cb4 in __GI_raise (sig=) at
../sysdeps/posix/raise.c:26
#2  0x77c749ec in __GI_abort () at abort.c:79
#3  0x1654 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-sign_extend-runnable.c:50

[Bug c++/108811] New: add enum annotation for switch statements

[tromey at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108811

Bug ID: 108811
   Summary: add enum annotation for switch statements
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

In gdb we don't generally want -Wswitch-enum, because there are many
switches where it's not appropriate.  However, for a subset of switch
statements, it is nice to have -- it means we can make them "future
proof" against things like adding a new type code.

Right now we can do this by pushing and popping diagnostics.
However, this relies on remembering to surround the switch with
some macros.

It would be nice, instead, to have an attribute we could apply to the
switch statement itself.  Then we'd only have to mark a single spot,
like:

[[gnu::switch_enum]] switch (...)

[Bug target/108810] New: gcc.target/powerpc/fold-vec-extract-double.p9.c fails on power 9 BE

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108810

Bug ID: 108810
   Summary: gcc.target/powerpc/fold-vec-extract-double.p9.c fails
on power 9 BE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make  -k check-gcc
RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/fold-vec-extract-double.p9.c"
FAIL: gcc.target/powerpc/fold-vec-extract-double.p9.c scan-assembler-times
\\mxxlor\\M 2
# of expected passes4
# of unexpected failures1

This fails on power 9 BE (only) and fails for trunk as well as gcc 12, 11, and
10.

[Bug target/108809] New: gcc.target/powerpc/builtins-5-p9-runnable.c fails on power 9 BE

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809

Bug ID: 108809
   Summary: gcc.target/powerpc/builtins-5-p9-runnable.c fails on
power 9 BE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
powerpc.exp=gcc.target/powerpc/builtins-5-p9-runnable.c"
FAIL: gcc.target/powerpc/builtins-5-p9-runnable.c execution test
FAIL: gcc.target/powerpc/builtins-5-p9-runnable.c  -O0  execution test
FAIL: gcc.target/powerpc/builtins-5-p9-runnable.c  -Os  execution test
FAIL: gcc.target/powerpc/builtins-5-p9-runnable.c  -O1  execution test
FAIL: gcc.target/powerpc/builtins-5-p9-runnable.c  -O2  execution test
FAIL: gcc.target/powerpc/builtins-5-p9-runnable.c  -O3  execution test

This fails on power 9 BE (only) and fails for trunk as well as gcc 12, 11, and
10.  

(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-10/builtins-5-p9-runnable.exe 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=,
no_tid=) at pthread_kill.c:44
44  pthread_kill.c: No such file or directory.
(gdb) where
#0  __pthread_kill_implementation (threadid=, signo=, no_tid=) at pthread_kill.c:44
#1  0x77c90cb4 in __GI_raise (sig=) at
../sysdeps/posix/raise.c:26
#2  0x77c749ec in __GI_abort () at abort.c:79
#3  0x15e8 in main () at
/home/seurer/gcc/git/gcc-10/gcc/testsuite/gcc.target/powerpc/builtins-5-p9-runnable.c:71

If I run it with DEBUG defined I get

seurer@perfzep2:~/gcc/git/build/gcc-10$ ./builtins-5-p9-runnable.exe 
Error: result does not match expected result
vec_xl_len_r(8): vec_uc_expected1[0] to vec_uc_expected1[15]
 8, 7, 6, 5, 4, 3, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0,
vec_xl_len_r(8): vec_uc_result1[0] to vec_uc_result1[15]
 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8,

Error: result does not match expected result
vec_xl_len_r(4): vec_uc_expected1[0] to vec_uc_expected1[15]
 4, 3, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
vec_xl_len_r(4): vec_uc_result1[0] to vec_uc_result1[15]
 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 3, 4,

Error: result does not match expected result
vec_xl_len_r(2): vec_uc_expected1[0] to vec_uc_expected1[15]
 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
vec_xl_len_r(2) vec_uc_result1[0] to vec_uc_result1[15]
 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2,

Error: result does not match expected result
vec_xst_len_r(16) vec_uc_expected1[0] to vec_uc_expected1[15]
 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1,
vec_xst_len_r(16) result[0] to result[15]
 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,

Error: result does not match expected result
vec_xst_len_r(2) vec_uc_expected1[0] to vec_uc_expected1[15]
 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
vec_xst_len_r(2) result[0] to result[15]
 15, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

Error: result does not match expected result
vec_xst_len_r(16) vec_uc_expected1[0] to vec_uc_expected1[15]
 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1,
vec_xst_len_r(16) result[0] to result[15]
 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,

Error: result does not match expected result
vec_xst_len_r(14) vec_uc_expected1[0] to vec_uc_expected1[15]
 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, 0,
vec_xst_len_r(14) result[0] to result[15]
 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 0, 0,

[Bug fortran/103608] ICE in do_intent, at fortran/frontend-passes.c:3035

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103608

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |13.0

--- Comment #4 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug fortran/103608] ICE in do_intent, at fortran/frontend-passes.c:3035

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103608

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:c75cbeba81e5b4737a9ab7dd28cce650965535a9

commit r13-6067-gc75cbeba81e5b4737a9ab7dd28cce650965535a9
Author: Steve Kargl 
Date:   Wed Feb 15 22:40:37 2023 +0100

Fortran: error recovery on checking procedure argument intent [PR103608]

gcc/fortran/ChangeLog:

PR fortran/103608
* frontend-passes.cc (do_intent): Catch NULL pointer dereference on
reference to invalid formal argument.

gcc/testsuite/ChangeLog:

PR fortran/103608
* gfortran.dg/pr103608.f90: New test.

[Bug fortran/104554] ICE in check_assumed_size_reference, at fortran/resolve.cc:1650

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104554

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:a418129273725fd02e881e6fb5e0877287a1356c

commit r13-6066-ga418129273725fd02e881e6fb5e0877287a1356c
Author: Steve Kargl 
Date:   Wed Feb 15 22:20:22 2023 +0100

Fortran: error recovery on invalid assumed size reference [PR104554]

gcc/fortran/ChangeLog:

PR fortran/104554
* resolve.cc (check_assumed_size_reference): Avoid NULL pointer
dereference.

gcc/testsuite/ChangeLog:

PR fortran/104554
* gfortran.dg/pr104554.f90: New test.

[Bug c++/108808] G++ -O2 incorrectly bypasses an infinite loop

[zhihan.yue at foxmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108808

--- Comment #3 from Zhihan Yue  ---
(In reply to Andrew Pinski from comment #1)
> >This shows that the infinite loop was skipped.
> 
> 
> Correct. There is a requirement in the C++17 standard that requires forward
> process and therefor infinite loops can be removed.
> 
> 
> "The implementation may assume that any thread will eventually do one of
> the following:
>   — terminate,
>   — make a call to a library I/O function,
>   — perform an access through a volatile glvalue, or
>   — perform a synchronization operation or an atomic operation.
> [Note: This is intended to allow compiler transformations such as
> removal of empty loops, even when termination cannot be proven. — end note]"

I get it! Thank you for your explanation.

[Bug c++/108808] G++ -O2 incorrectly bypasses an infinite loop

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108808

--- Comment #2 from Andrew Pinski  ---
C++11 has "Implementations should ensure that all unblocked threads
eventually make progress."

[Bug c++/108808] G++ -O2 incorrectly bypasses an infinite loop

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108808

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
>This shows that the infinite loop was skipped.


Correct. There is a requirement in the C++17 standard that requires forward
process and therefor infinite loops can be removed.


"The implementation may assume that any thread will eventually do one of
the following:
  — terminate,
  — make a call to a library I/O function,
  — perform an access through a volatile glvalue, or
  — perform a synchronization operation or an atomic operation.
[Note: This is intended to allow compiler transformations such as
removal of empty loops, even when termination cannot be proven. — end note]"

[Bug c/108796] Can't intermix C2x and GNU style attributes

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796

--- Comment #6 from joseph at codesourcery dot com  ---
The logic is that GNU attributes are declaration specifiers (and can mix 
anywhere with other declaration specifiers), but standard attributes 
aren't declaration specifiers; rather, they come in specified positions 
relative to declaration specifiers (the semantics before and after the 
declaration specifiers are different), and in the middle isn't such a 
position.

[Bug c++/108808] New: G++ -O2 incorrectly bypasses an infinite loop

[zhihan.yue at foxmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108808

Bug ID: 108808
   Summary: G++ -O2 incorrectly bypasses an infinite loop
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhihan.yue at foxmail dot com
  Target Milestone: ---

Compile the following code with G++ -O2:

#include 
#include 

struct Test {
bool a = false;
std::string b;
};

int main() {
Test test;
test.a = false;
std::cout << "enter" << std::endl;
while(! test.a);
std::cout << "passed" << std::endl;
return 0;
}

Executing the program, the output will be:
enter
passed

This shows that the infinite loop was skipped.

Tested versions: (x64)
- Problem happens on GCC V10.1-10.4, V11.1-11.3, V12.1-12.2
- No such problem on GCC V9.5, V8.5, V7.5
Seems like a bug introduced in V10.1

[Bug target/108804] missed vectorization in presence of conversion from uint64_t to float

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108804

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |target
   Severity|normal  |enhancement

[Bug tree-optimization/108804] missed vectorization in presence of conversion from uint64_t to float

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108804

--- Comment #1 from Andrew Pinski  ---
  _16 = (signed long) x_10;

[Bug fortran/103608] ICE in do_intent, at fortran/frontend-passes.c:3035

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103608

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 CC||anlauf at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from anlauf at gcc dot gnu.org ---
Pretty obvious.  Will take care of it.

[Bug analyzer/108725] -Wanalyzer-use-of-uninitialized-value on ternary pointer access seen in qemu-7.2.0's dump/win_dump.c

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108725

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from David Malcolm  ---
Should be fixed on trunk by the above patch.

I don't plan to backport the patch to GCC 12 (doing so would be nontrivial), so
marking this as resolved.

[Bug fortran/104554] ICE in check_assumed_size_reference, at fortran/resolve.cc:1650

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104554

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Will commit Steve's patch as obvious.

[Bug analyzer/108666] -Wanalyzer-use-of-uninitialized-value false positives seen in coreutils's sum.c: bsd_sum_stream

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108666

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from David Malcolm  ---
Should be fixed by the above patch.

[Bug analyzer/108664] -Wanalyzer-use-of-uninitialized-value false positive seen in coreutils's cksum.c: cksum_slice8

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108664

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from David Malcolm  ---
Should be fixed by the above patch.

[Bug analyzer/108725] -Wanalyzer-use-of-uninitialized-value on ternary pointer access seen in qemu-7.2.0's dump/win_dump.c

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108725

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:b03a10b0b25cef4928ccead4c8a461d3674dbe86

commit r13-6064-gb03a10b0b25cef4928ccead4c8a461d3674dbe86
Author: David Malcolm 
Date:   Wed Feb 15 14:52:02 2023 -0500

analyzer: fix uninit false +ves [PR108664,PR108666,PR108725]

This patch updates poisoned_value_diagnostic so that, where possible,
it checks to see if the value is still poisoned along the execution
path seen during feasibility analysis, rather than just that seen
in the exploded graph.

Integration testing shows this reduction in the number of
false positives:
  -Wanalyzer-use-of-uninitialized-value: 191 -> 153 (-38)
where the changes happen in:
  coreutils-9.1: 34 -> 20 (-14)
 qemu-7.2.0: 78 -> 54 (-24)

gcc/analyzer/ChangeLog:
PR analyzer/108664
PR analyzer/108666
PR analyzer/108725
* diagnostic-manager.cc (epath_finder::get_best_epath): Add
"target_stmt" param.
(epath_finder::explore_feasible_paths): Likewise.
(epath_finder::process_worklist_item): Likewise.
(saved_diagnostic::calc_best_epath): Pass m_stmt to
epath_finder::get_best_epath.
* engine.cc (feasibility_state::maybe_update_for_edge): Move
per-stmt logic to...
(feasibility_state::update_for_stmt): ...this new function.
* exploded-graph.h (feasibility_state::update_for_stmt): New decl.
* feasible-graph.cc (feasible_node::get_state_at_stmt): New.
* feasible-graph.h: Include "analyzer/exploded-graph.h".
(feasible_node::get_state_at_stmt): New decl.
* infinite-recursion.cc
(infinite_recursion_diagnostic::check_valid_fpath_p): Update for
vfunc signature change.
* pending-diagnostic.h (pending_diagnostic::check_valid_fpath_p):
Convert first param to a reference.  Add stmt param.
* region-model.cc: Include "analyzer/feasible-graph.h".
(poisoned_value_diagnostic::poisoned_value_diagnostic): Add
"check_expr" param.
(poisoned_value_diagnostic::check_valid_fpath_p): New.
(poisoned_value_diagnostic::m_check_expr): New field.
(region_model::check_for_poison): Attempt to supply a check_expr
to the diagnostic
(region_model::deref_rvalue): Add NULL for new check_expr param
of poisoned_value_diagnostic.
(region_model::get_or_create_region_for_heap_alloc): Don't reuse
regions that are marked as TOUCHED.

gcc/testsuite/ChangeLog:
PR analyzer/108664
PR analyzer/108666
PR analyzer/108725
* gcc.dg/analyzer/coreutils-cksum-pr108664.c: New test.
* gcc.dg/analyzer/coreutils-sum-pr108666.c: New test.
* gcc.dg/analyzer/torture/uninit-pr108725.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/108666] -Wanalyzer-use-of-uninitialized-value false positives seen in coreutils's sum.c: bsd_sum_stream

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108666

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:b03a10b0b25cef4928ccead4c8a461d3674dbe86

commit r13-6064-gb03a10b0b25cef4928ccead4c8a461d3674dbe86
Author: David Malcolm 
Date:   Wed Feb 15 14:52:02 2023 -0500

analyzer: fix uninit false +ves [PR108664,PR108666,PR108725]

This patch updates poisoned_value_diagnostic so that, where possible,
it checks to see if the value is still poisoned along the execution
path seen during feasibility analysis, rather than just that seen
in the exploded graph.

Integration testing shows this reduction in the number of
false positives:
  -Wanalyzer-use-of-uninitialized-value: 191 -> 153 (-38)
where the changes happen in:
  coreutils-9.1: 34 -> 20 (-14)
 qemu-7.2.0: 78 -> 54 (-24)

gcc/analyzer/ChangeLog:
PR analyzer/108664
PR analyzer/108666
PR analyzer/108725
* diagnostic-manager.cc (epath_finder::get_best_epath): Add
"target_stmt" param.
(epath_finder::explore_feasible_paths): Likewise.
(epath_finder::process_worklist_item): Likewise.
(saved_diagnostic::calc_best_epath): Pass m_stmt to
epath_finder::get_best_epath.
* engine.cc (feasibility_state::maybe_update_for_edge): Move
per-stmt logic to...
(feasibility_state::update_for_stmt): ...this new function.
* exploded-graph.h (feasibility_state::update_for_stmt): New decl.
* feasible-graph.cc (feasible_node::get_state_at_stmt): New.
* feasible-graph.h: Include "analyzer/exploded-graph.h".
(feasible_node::get_state_at_stmt): New decl.
* infinite-recursion.cc
(infinite_recursion_diagnostic::check_valid_fpath_p): Update for
vfunc signature change.
* pending-diagnostic.h (pending_diagnostic::check_valid_fpath_p):
Convert first param to a reference.  Add stmt param.
* region-model.cc: Include "analyzer/feasible-graph.h".
(poisoned_value_diagnostic::poisoned_value_diagnostic): Add
"check_expr" param.
(poisoned_value_diagnostic::check_valid_fpath_p): New.
(poisoned_value_diagnostic::m_check_expr): New field.
(region_model::check_for_poison): Attempt to supply a check_expr
to the diagnostic
(region_model::deref_rvalue): Add NULL for new check_expr param
of poisoned_value_diagnostic.
(region_model::get_or_create_region_for_heap_alloc): Don't reuse
regions that are marked as TOUCHED.

gcc/testsuite/ChangeLog:
PR analyzer/108664
PR analyzer/108666
PR analyzer/108725
* gcc.dg/analyzer/coreutils-cksum-pr108664.c: New test.
* gcc.dg/analyzer/coreutils-sum-pr108666.c: New test.
* gcc.dg/analyzer/torture/uninit-pr108725.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/108664] -Wanalyzer-use-of-uninitialized-value false positive seen in coreutils's cksum.c: cksum_slice8

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108664

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:b03a10b0b25cef4928ccead4c8a461d3674dbe86

commit r13-6064-gb03a10b0b25cef4928ccead4c8a461d3674dbe86
Author: David Malcolm 
Date:   Wed Feb 15 14:52:02 2023 -0500

analyzer: fix uninit false +ves [PR108664,PR108666,PR108725]

This patch updates poisoned_value_diagnostic so that, where possible,
it checks to see if the value is still poisoned along the execution
path seen during feasibility analysis, rather than just that seen
in the exploded graph.

Integration testing shows this reduction in the number of
false positives:
  -Wanalyzer-use-of-uninitialized-value: 191 -> 153 (-38)
where the changes happen in:
  coreutils-9.1: 34 -> 20 (-14)
 qemu-7.2.0: 78 -> 54 (-24)

gcc/analyzer/ChangeLog:
PR analyzer/108664
PR analyzer/108666
PR analyzer/108725
* diagnostic-manager.cc (epath_finder::get_best_epath): Add
"target_stmt" param.
(epath_finder::explore_feasible_paths): Likewise.
(epath_finder::process_worklist_item): Likewise.
(saved_diagnostic::calc_best_epath): Pass m_stmt to
epath_finder::get_best_epath.
* engine.cc (feasibility_state::maybe_update_for_edge): Move
per-stmt logic to...
(feasibility_state::update_for_stmt): ...this new function.
* exploded-graph.h (feasibility_state::update_for_stmt): New decl.
* feasible-graph.cc (feasible_node::get_state_at_stmt): New.
* feasible-graph.h: Include "analyzer/exploded-graph.h".
(feasible_node::get_state_at_stmt): New decl.
* infinite-recursion.cc
(infinite_recursion_diagnostic::check_valid_fpath_p): Update for
vfunc signature change.
* pending-diagnostic.h (pending_diagnostic::check_valid_fpath_p):
Convert first param to a reference.  Add stmt param.
* region-model.cc: Include "analyzer/feasible-graph.h".
(poisoned_value_diagnostic::poisoned_value_diagnostic): Add
"check_expr" param.
(poisoned_value_diagnostic::check_valid_fpath_p): New.
(poisoned_value_diagnostic::m_check_expr): New field.
(region_model::check_for_poison): Attempt to supply a check_expr
to the diagnostic
(region_model::deref_rvalue): Add NULL for new check_expr param
of poisoned_value_diagnostic.
(region_model::get_or_create_region_for_heap_alloc): Don't reuse
regions that are marked as TOUCHED.

gcc/testsuite/ChangeLog:
PR analyzer/108664
PR analyzer/108666
PR analyzer/108725
* gcc.dg/analyzer/coreutils-cksum-pr108664.c: New test.
* gcc.dg/analyzer/coreutils-sum-pr108666.c: New test.
* gcc.dg/analyzer/torture/uninit-pr108725.c: New test.

Signed-off-by: David Malcolm 

[Bug fortran/104346] Problem with overloaded assignment when LHS is allocatable array

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104346

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Vivek Rao from comment #1)
> It is explained at
> https://community.intel.com/t5/Intel-Fortran-Compiler/Problem-with-
> overloaded-assignment-when-LHS-is-allocatable-array/m-p/1356757/highlight/
> true#M159812 that the code is not conforming, so this issue can be closed.

Thanks for following up.

This is also confirmed by checking with e.g. NAG.  Thus closing.

[Bug rtl-optimization/108805] [13 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7400 at -O and above

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108805

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-15
  Component|target  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Confirmed, combine chokes itself with the RTX it cannot chew:

(gdb) bt
#0  internal_error (gmsgid=gmsgid@entry=0x2614840 "in %s, at %s:%d") at
../../git/gcc/gcc/diagnostic.cc:2138
#1  0x00891812 in fancy_abort (file=file@entry=0x20b75d8
"../../git/gcc/gcc/simplify-rtx.cc", line=line@entry=7400, 
function=function@entry=0x20b74e8 "simplify_subreg") at
../../git/gcc/gcc/diagnostic.cc:2242
#2  0x007653cb in simplify_context::simplify_subreg
(this=0x7fffd2a8, outermode=, op=, 
innermode=, byte=...) at
../../git/gcc/gcc/simplify-rtx.cc:7400
#3  0x00ecfee9 in simplify_context::simplify_gen_subreg
(this=, outermode=E_V4QImode, op=0x7fffea209480, 
innermode=E_VOIDmode, byte=...) at ../../git/gcc/gcc/simplify-rtx.cc:7694
#4  0x00ecfee9 in simplify_context::simplify_gen_subreg
(this=this@entry=0x7fffd2a8, 
outermode=outermode@entry=E_V4QImode, op=0x7fffea3e4b58,
innermode=E_DImode, byte=...) at ../../git/gcc/gcc/simplify-rtx.cc:7694
#5  0x01c92bde in simplify_gen_subreg (byte=..., innermode=, op=, outermode=E_V4QImode)
at ../../git/gcc/gcc/rtl.h:3408
#6  if_then_else_cond (x=x@entry=0x7fffea3e4558,
ptrue=ptrue@entry=0x7fffd328, pfalse=pfalse@entry=0x7fffd338)
at ../../git/gcc/gcc/combine.cc:9375
#7  0x01c929b1 in if_then_else_cond (x=x@entry=0x7fffea3e42b8,
ptrue=ptrue@entry=0x7fffd400, 
pfalse=pfalse@entry=0x7fffd408) at ../../git/gcc/gcc/combine.cc:9240
#8  0x01c9de0a in combine_simplify_rtx (x=0x7fffea3e42b8,
op0_mode=E_V4QImode, in_dest=0, in_cond=0)
at ../../git/gcc/gcc/combine.cc:5723

(gdb) f 3
#3  0x00ecfee9 in simplify_context::simplify_gen_subreg
(this=, outermode=E_V4QImode, op=0x7fffea209480, 
innermode=E_VOIDmode, byte=...) at ../../git/gcc/gcc/simplify-rtx.cc:7694
7694  newx = simplify_subreg (outermode, op, innermode, byte);
(gdb) p debug_rtx (op)
(const_int -1 [0x])

[Bug fortran/104321] Dead code since r12-4467-g64f9623765da33

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104321

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
> I think it is not only dead code but it should be also removed:
> 
> Glancing at the code, the 'data = NULL;' does not make sense (cf.
> 'memcpy(lhs, rhs)' above, lhs is data+offset) – and also does not match the
> comment.
> Besides, all testcases seem to be happy with that line being dead code

So we can just remove this dead code as obvious and finally close the PR?

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Keywords|needs-reduction |

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[qinzhao at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411

--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> 
> The gimplifier instead of
> 
>   _1 = t ();
>   D.2389 = _1;
>   e = 
>   _2 = *e;
>   f (_2);
> 
> produces
> 
>   _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
>   D.2389 = _1;
>   e = .DEFERRED_INIT (8, 2, &"e"[0]);
>   _2 = t ();
>   D.2389 = _2;
>   e = 
>   _3 = *e;
>   f (_3);
> 
> which is odd and sub-optimal at least.  Doing such things makes us rely
> on DSE to elide the uninit "inits".

actually, this is because, The simplifier sees the following  IR from FE
(.original)

const int D.2768;
const int & e;
  <;
  <;
}

i.e, it sees two DECL_EXPR "D.2768" and "e" without any initialization first,
and then see the "CLEANUP_POINT_EXPR" which include the initializations to "e"
and "D.2768". since it doesn't see any connections between these two DECL_EXPRs
and the initializations inside "CLEANUP_POINT_EXPR", it just treats the two
DECL_EXPRs as not initialized, therefore add the .DEFERED_INIT to them.

the best approach to resolve this issue is:

if there is any connection  between DECL_EXPR "D.2768","e" and their
initializations inside "CLEANUP_POINT_EXPR" that can be checked from IR, then
during "gimplify_decl_expr", we can avoid generating .DEFERRED_INIT to them;

my question is: in the current IR from C++ FE, is there any bit I can check to
make sure that the DECL_EXPR "D.2768" and "e" already have initialization
inside "CLEANUP_POINT_EXPR"?

[Bug target/108807] New: [11 regression] gcc.target/powerpc/vsx-builtin-10d.c fails after b29225597584b697762585e0b707b7cb4b427650 on power 9 BE

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807

Bug ID: 108807
   Summary: [11 regression] gcc.target/powerpc/vsx-builtin-10d.c
fails after b29225597584b697762585e0b707b7cb4b427650
on power 9 BE
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:b29225597584b697762585e0b707b7cb4b427650
make  -k check-gcc
RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/vsx-builtin-10d.c"
FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test
# of expected passes1
# of unexpected failures1

This fails on power 9 BE (only) and fails for trunk as well as gcc 12 and 11. 
It works with gcc 10.  It started with this commit in gcc 11.

seurer@perfzep2:~/gcc/git/build/gcc-test$ gdb ./vsx-builtin-10d.exe 
(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/vsx-builtin-10d.exe 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=,
no_tid=) at pthread_kill.c:44
44  pthread_kill.c: No such file or directory.
(gdb) where
#0  __pthread_kill_implementation (threadid=, signo=, no_tid=) at pthread_kill.c:44
#1  0x77c90cb4 in __GI_raise (sig=) at
../sysdeps/posix/raise.c:26
#2  0x77c749ec in __GI_abort () at abort.c:79
#3  0x1670 in main (argc=, argv=) at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10d.c:124


  sv = ci (sv, 5, CONST6);
  if (sv [5] != CONST6)
abort (); // line 124


There are actually a bunch of similar failures

FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-11d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-11d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-14d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-14d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-16d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-16d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-18d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-18d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-9d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-9d.c execution test


commit b29225597584b697762585e0b707b7cb4b427650 (HEAD)
Author: Xionghu Luo 
Date:   Thu Jan 21 21:01:24 2021 -0600

rs6000: Support variable insert and Expand vec_insert in expander [PR79251]

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657

--- Comment #21 from Jakub Jelinek  ---
Created attachment 54472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54472=edit
gcc13-pr108657.patch

Untested fix.  This one fixes the DSE bug which caused the .DEFERRED_INIT calls
not to be DSEd.  Though, I wonder if we still don't have a bug in FRE...

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657

--- Comment #20 from Jakub Jelinek  ---
Looking at the r13-1778 change, perhaps it wasn't intended that it changed
behavior for all internal functions that return non-SSA_NAME result.
--- gcc/tree-ssa-dse.cc.jj  2023-01-11 10:29:08.651161134 +0100
+++ gcc/tree-ssa-dse.cc 2023-02-15 20:03:33.647684713 +0100
@@ -177,7 +177,7 @@ initialize_ao_ref_for_dse (gimple *stmt,
default:;
}
 }
-  else if (tree lhs = gimple_get_lhs (stmt))
+  if (tree lhs = gimple_get_lhs (stmt))
 {
   if (TREE_CODE (lhs) != SSA_NAME)
{
fixes this.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657

--- Comment #19 from Jakub Jelinek  ---
With the deferred stuff (why don't we DCE it for variables which are otherwise
not used?), all looks fine until fre5.
In fre4 we have
  k ={v} {CLOBBER(eol)};
  c = -1;
  c = 1;
  foo ();
  return 0;
at the end which is reasonable, the outer loop iterates c = 1, c = 0 and c = -1
and then c = 1 is stored, dse4 optimizes it to:
  k ={v} {CLOBBER(eol)};
  c = 1;
  foo ();
  return 0;
in split-path, we have in bb2
  c = 1;
then in one of the conditionalized bbs
  c = 0;
and finally still
   [local count: 38651690]:
  k ={v} {CLOBBER(eol)};
  c = 1;
  foo ();
  return 0;
at the end, but fre5 keeps those c = 1; and c = 0; early stores and drops the
last one.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657

--- Comment #18 from Andrew Pinski  ---
fre5 deletes it:
Deleted redundant store c = 1;
Value numbering stmt = foo ();
Setting value number of .MEM_14 to .MEM_14 (changed)
Value numbering stmt = return 0;
RPO iteration over 7 blocks visited 7 blocks in total discovering 7 executable
blocks iterating 1.0 times, a block was visited max. 1 times
RPO tracked 20 values available at 1 locations and 20 lattice elements
Removing dead stmt c = 1;

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-15

--- Comment #17 from Jakub Jelinek  ---
In the assembly, the important difference is that with just -O3 c is assigned 1
before calling the first bar, while -O3 -ftrivial-auto-var-init=zero it is
assigned 0.  This is visible already in optimized dump, which for the latter
stores first c = 1; and then twice c = 0; among the various DEFERRED_INITs.

Even further reduced:
int c, e, f;
static int *d = 

__attribute__((noipa)) void
foo (void)
{
  if (c != 1)
__builtin_abort ();
}

int
main ()
{
  for (c = 1; c >= 0; c--)
{
  e = 0;
  for (int j = 0; j <= 2; j++)
{
  short k[1];
  if (e)
break;
  e ^= f;
}
}
  *d = 1;
  foo ();
}

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657

--- Comment #16 from Jakub Jelinek  ---
Slightly more reduced:

int a = -8, c, e, f, g, i;
short b;
static int *d = 
int m[256];
unsigned n = ~0U;

void
foo (int b)
{
  n = (n >> 8) ^ m[(n ^ b) & 255];
}

void
bar (long x)
{
  n = (n >> 8) ^ m[(n ^ x) & 255];
  foo (x >> 8);
  foo (x >> 16);
}

int
main ()
{
  if (__CHAR_BIT__ != 8 || __SIZEOF_SHORT__ != 2 || __SIZEOF_INT__ != 4)
return 0;
  for (g = 0; g < 256; g++)
m[g] = g;
  b = 53935 & a;
  a = -18;
  for (c = 1; c >= 0; c--)
{
  e = 0;
  for (int j = 0; j <= 3; j++)
{
  short k[1];
  if (e)
break;
  e ^= f;
}
}
  *d = 8 || 0;
  bar (a);
  bar (b);
  bar (2185655400);
  bar (c);
  if (n != 0x30)
__builtin_abort ();
}

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
Slightly cleaned up; aborts with -O3 -ftrivial-auto-var-init=zero,
doesn't abort with -O0, -O3 or -O0 -ftrivial-auto-var-init=zero.

int m[256];
unsigned n = 4294967295;

void
foo (int b)
{
  n = (n >> 8) ^ m[(n ^ b) & 255];
}

void
bar (long x)
{
  n = (n >> 8) ^ m[(n ^ x) & 255];
  foo (x >> 8);
  foo (x >> 16);
  foo (x >> 24);
  foo (x >> 32);
  foo (x >> 40);
  foo (x >> 48);
  foo (x >> 56);
}

int a = -8, c, e, f, g, i;
short b;
static int *d = 
unsigned h;

int
main ()
{
  if (__CHAR_BIT__ != 8 || __SIZEOF_SHORT__ != 2 || __SIZEOF_INT__ != 4)
return 0;
  for (; g < 256; g++)
{
  h = g;
  for (i = 8; i; i--)
if (h & 1)
  h = (h >> 1) ^ 3988292384;
else
  h >>= 1;
  m[g] = h;
}
  b = 53935 & a;
  a = -18;
  for (c = 1; c >= 0; c -= 1)
{
  e = 0;
  for (int j = 0; j <= 3; j++)
{
  short k[1];
  if (e)
break;
  e ^= f;
}
}
  *d = 8 || 0;
  bar (a);
  bar (b);
  bar (2185655400);
  bar (c);
  if (n != 0xbd51857cU)
__builtin_abort ();
}

The only difference between -O3 and -O3 -ftrivial-auto-var-init=zero in gimple
dump
is the addition of
k = .DEFERRED_INIT (2, 2, &"k"[0]);
where k is otherwise unused variable.

[Bug middle-end/108799] Improper deprecation diagnostic for rsp clobber

[andrew.cooper3 at citrix dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799

--- Comment #2 from Andrew Cooper  ---
Adding a memory clobber doesn't make any difference that I can see, and I'm not
aware of any reason why it ought to make a difference.

I suppose that my real request here is to figure out what is the correct way to
indicate that the redzone is clobbered, and to document it.

[Bug middle-end/108799] Improper deprecation diagnostic for rsp clobber

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||documentation

--- Comment #1 from Andrew Pinski  ---
I suspect:

  asm volatile ("pushf; popq %[fl]"
: [fl] "=r" (fl)
   , "+r" (rsp)
:
: "memory"
  );

Will fix the issue in the inline-asm; this is just a documentation issue I
think.

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106080

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #13 from Marek Polacek  ---
Fixed.

[Bug middle-end/104077] [meta-bug] bogus/missing -Wdangling-pointer

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077
Bug 104077 depends on bug 106080, which changed state.

Bug 106080 Summary: Labels as values triggering -Wdangling-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106080

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106080

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:825a47f1bb9a42df65157d4dc0a11b2c054e97cc

commit r12-9176-g825a47f1bb9a42df65157d4dc0a11b2c054e97cc
Author: Marek Polacek 
Date:   Tue Feb 14 17:05:44 2023 -0500

warn-access: wrong -Wdangling-pointer with labels [PR106080]

-Wdangling-pointer warns when the address of a label escapes.  This
causes grief in OCaml () as
well as in the kernel:
 because it uses

  #define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here;
})

to get the PC.  -Wdangling-pointer is documented to warn about pointers
to objects.  However, it uses is_auto_decl which checks DECL_P, but DECL_P
is also true for a label/enumerator/function declaration, none of which is
an object.  Rather, it should use auto_var_p which correctly checks VAR_P
and PARM_DECL.

PR middle-end/106080

gcc/ChangeLog:

* gimple-ssa-warn-access.cc (is_auto_decl): Remove.  Use auto_var_p
instead.

gcc/testsuite/ChangeLog:

* c-c++-common/Wdangling-pointer-10.c: New test.
* c-c++-common/Wdangling-pointer-9.c: New test.

(cherry picked from commit d482b20fd346482635a770281a164a09d608b058)

[Bug middle-end/108721] [10/11/12/13 Regression] csmith: really old bug with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108721

--- Comment #3 from David Binderman  ---
Created attachment 54471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54471=edit
C source code

After a short reduction.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718

--- Comment #11 from David Binderman  ---
(In reply to Martin Liška from comment #10)
> However, I see a segfault that happens for the code snippet now.

In the compiler or the generated code ?

No crashes here. Are you running an asan+ubsan gcc build on x86_64, perhaps ?

[Bug analyzer/108806] New: -Wanalyzer-null-dereference false positives due to not handling bitmasks

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108806

Bug ID: 108806
   Summary: -Wanalyzer-null-dereference false positives due to not
handling bitmasks
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 108562
  Target Milestone: ---

Created attachment 54470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54470=edit
Reproducer

Trunk:https://godbolt.org/z/77EbbPEW5
GCC 12.2: https://godbolt.org/z/o8bbMhPxW
GCC 11.3: https://godbolt.org/z/o4dK3zn3b
GCC 10.4: https://godbolt.org/z/GzEqzMMjW

Lots of false positives of the form:

: In function 'omap2_inth_read':
:75:18: warning: dereference of NULL 'bank' [CWE-476]
[-Wanalyzer-null-dereference]
   75 |   return bank->inputs;
  |  ^~~~
  'omap2_inth_read': events 1-6
|
|   40 |   struct omap_intr_handler_bank_s* bank = NULL;
|  |^~~~
|  ||
|  |(1) 'bank' is NULL
|   41 | 
|   42 |   if ((offset & 0xf80) == 0x80) {
|  |  ~  
|  |  |
|  |  (2) following 'false' branch...
|..
|   52 |   switch (offset) {
|  |   ~~
|  |   |
|  |   (3) ...to here
|  |   (4) following 'case 128:' branch...
|..
|   74 | case 0x80:
|  | 
|  | |
|  | (5) ...to here
|   75 |   return bank->inputs;
|  |     
|  |  |
|  |  (6) dereference of NULL 'bank'
|

where if offset == 128, then the:

|   42 |   if ((offset & 0xf80) == 0x80) {
|  |  ~  
|  |  |
|  |  (2) following 'false' branch...
|..
|   52 |   switch (offset) {
|  |   ~~
|  |   |
|  |   (3) ...to here

edge is impossible, and "bank" will have been properly initialized.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562
[Bug 108562] [meta-bug] tracker bug for issues with -Wanalyzer-null-dereference

[Bug ipa/108802] [10/11/12/13 Regression] missed inlining of call via pointer to member function

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
Summary|missed inlining of call via |[10/11/12/13 Regression]
   |pointer to member function  |missed inlining of call via
   ||pointer to member function

[Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685

--- Comment #5 from Jakub Jelinek  ---
Though, we have such code already:
  if (broken_loop)
{
  int i;
  for (i = fd->collapse; i < fd->ordered; i++)
{
  tree type = TREE_TYPE (fd->loops[i].v);
  tree this_cond
= fold_build2 (fd->loops[i].cond_code, boolean_type_node,
   fold_convert (type, fd->loops[i].n1),
   fold_convert (type, fd->loops[i].n2));
  if (!integer_onep (this_cond))
break;
}
  if (i < fd->ordered)
{
  cont_bb
= create_empty_bb (EXIT_BLOCK_PTR_FOR_FN (cfun)->prev_bb);
  add_bb_to_loop (cont_bb, l1_bb->loop_father);
  gimple_stmt_iterator gsi = gsi_after_labels (cont_bb);
  gimple *g = gimple_build_omp_continue (fd->loop.v, fd->loop.v);
  gsi_insert_before (, g, GSI_SAME_STMT);
  make_edge (cont_bb, l3_bb, EDGE_FALLTHRU);
  make_edge (cont_bb, l1_bb, 0);
  l2_bb = create_empty_bb (cont_bb);
  broken_loop = false;
}
}
and at least when the outermost for (;;) is missing, it works fine.

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688

--- Comment #33 from Segher Boessenkool  ---
Yes, exactly.  It was the X server I think?  I try to forget such horrors :-)

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688

--- Comment #32 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #31)
> Yes, there was a user who incorrectly used memcpy on non-memory memory.
>From what I remember (it was also reported about aarch64 at one point too), one
of the graphics libraries would call memcpy from normal memory to GPU Memory
(over PCIe) and memcpy will sometimes use unaligned accesses which causes a
fault to the GPU memory.

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688

--- Comment #31 from Segher Boessenkool  ---
Yes, there was a user who incorrectly used memcpy on non-memory memory.

This is not valid, and never has been.

[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517

Martin Jambor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #8 from Martin Jambor  ---
(In reply to Jakub Jelinek from comment #6)
> Somehow this constprop function is kept in the IL but not really called by
> anything once IPA passes are done.

This is discovered only when performing inlining on GIMPLE bodies, I
guess during folding of the conditions.  At this point, with LTO, the
constprop functions could theoretically be in another partition so
generally it is too late to remove them as unreachable.

(In reply to Jakub Jelinek from comment #7)
> Or perhaps when considering the constprop see that for __first_5(D) being 0B
> there would be pointer arithmetics on NULL (the __first_5(D) p+ 16) and so
> would invoke UB or likely invoke UB and so not worth constant propagation.

Only when unguarded.  Being able to eliminate these when they are
guarded by a NULL check is something that IPA-CP should do.  And NULL
checks can be non-obvious at IPA time, in this case this is
essentially done by the check that

  if (__first_4(D) != __last_5(D))

where we manage to prove that __first is zero but __last can be either
zero or zero pointer_plus 16 and therefore we fail to propagate (for
all contexts).

I'm afraid I don't have any good ideas that might not lead to adverse
effects in other situations.  Perhaps we could specifically track such
comparisons in a bitmap and then do some "likely invalid pointer"
propagation for pointer arithmetics and then avoid cloning for zero
value in presence of such comparisons...

[Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685

--- Comment #4 from Jakub Jelinek  ---
expand_omp_for_generic like other ompexp functions has the notion of
broken_loop for
loops where the body doesn't fall through to the artificial #pragma omp
continue.
This works fine even for doacross loops if they have ordered equals collapse or
all the loops between ordered (inclusive) and collapse (exclusive) have compile
time constant non-zero number of iterations.
The problem is when they could have zero iterations (as in the testcase) or do
have those provably - say if l < a above is replaced with l < -2, in that case
while the ultimate body is a broken loop, either conditionally or always that
ultimate body will not be encountered at runtime at all, and the loop will do
nothing at all.  In that case
the loop is no longer a non-loop (broken_loop) because in some cases or all it
can actually loop.
We can I think detect that after the expand_omp_for_init_counts call in
expand_omp_for_generic.  The question is if we at that point can add an
artificial cont_bb somewhere, set broken_loop to false and do whatever is
needed to make the rest of the function work as if it wasn't a broken loop.

[Bug target/108805] New: [13 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7400 at -O and above

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108805

Bug ID: 108805
   Summary: [13 Regression] ICE: in simplify_subreg, at
simplify-rtx.cc:7400 at -O and above
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 54469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54469=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
during RTL pass: combine
testcase.c: In function 'foo':
testcase.c:16:1: internal compiler error: in simplify_subreg, at
simplify-rtx.cc:7400
   16 | }
  | ^
0x79d82a simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.cc:7400
0x13a9438 simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.cc:7694
0x13a9438 simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.cc:7694
0x23c8a32 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode,
poly_int<1u, unsigned long>)
/repo/gcc-trunk/gcc/rtl.h:3535
0x23c8a32 if_then_else_cond
/repo/gcc-trunk/gcc/combine.cc:9375
0x23c8535 if_then_else_cond
/repo/gcc-trunk/gcc/combine.cc:9240
0x23ddd0c combine_simplify_rtx
/repo/gcc-trunk/gcc/combine.cc:5723
0x23e01eb subst
/repo/gcc-trunk/gcc/combine.cc:5605
0x23e00e8 subst
/repo/gcc-trunk/gcc/combine.cc:5532
0x23e3831 try_combine
/repo/gcc-trunk/gcc/combine.cc:3336
0x23ebca0 combine_instructions
/repo/gcc-trunk/gcc/combine.cc:1287
0x23ebca0 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.cc:14978
0x23ebca0 execute
/repo/gcc-trunk/gcc/combine.cc:15023
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/108804] New: missed vectorization in presence of conversion from uint64_t to float

[vincenzo.innocente at cern dot ch via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108804

Bug ID: 108804
   Summary: missed vectorization in presence of conversion from
uint64_t to float
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

in the following code [1] foo does not vectorize, bar doos
compiled with -march=haswell -Ofast --no-math-errno -Wall
see
https://godbolt.org/z/E6xzfavxc

clang seems do do better

[1]
#include



uint64_t d[512];
//uint32_t f[1024];
float f[1024];

void foo() {
for (int i=0; i<512; ++i) {
uint64_t k = d[i];
auto x  = (k & 0x007F) |  0x3F80;
k = k >> 23;
auto y  = (k & 0x007F) |  0x3F80;
f[i]=x; f[128+i] = y;

}
}

void bar() {
for (int i=0; i<512; ++i) {
uint64_t k = d[i];
uint32_t x  = (k & 0x007F);
x |= 0x3F80;
uint32_t y  = k >> 23;
y  = (y & 0x007F) |  0x3F80;
f[i]=x; f[128+i] = y;

}  
}

[Bug target/108803] New: [10/11/12/13 Regression] wrong code for 128bit rotate on aarch64-unknown-linux-gnu with -Og

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108803

Bug ID: 108803
   Summary: [10/11/12/13 Regression] wrong code for 128bit rotate
on aarch64-unknown-linux-gnu with -Og
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 54468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54468=edit
reduced testcase

Output:
$ aarch64-unknown-linux-gnu-gcc -Og testcase.c -static
$ qemu-aarch64 -- ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

The value is "63 << 64 | 63" instead of just "63".

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-5999-20230215101300-g3f71b82596e-checking-yes-rtl-df-extra-nobootstrap-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-5999-20230215101300-g3f71b82596e-checking-yes-rtl-df-extra-nobootstrap-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230215 (experimental) (GCC)

[Bug tree-optimization/26854] Inordinate compile times on large routines

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854

--- Comment #151 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:053d4dda0a205aba6af85fd9662118dd8109df9f

commit r13-6061-g053d4dda0a205aba6af85fd9662118dd8109df9f
Author: Richard Biener 
Date:   Tue Feb 14 14:46:47 2023 +0100

Speedup DF dataflow solver

The following makes sure to process blocks that follow the current
block in the iteration order in the same iteration and only postpone
blocks that would be visited earlier to the next iteration.

For the all.i testcase in PR26854 at -O2 this shaves off 50% of
the time to solve the DF RD problem, other problems also improve
but not as drastically.

PR middle-end/26854
* df-core.cc (df_worklist_propagate_forward): Put later
blocks on worklist and only earlier blocks on pending.
(df_worklist_propagate_backward): Likewise.
(df_worklist_dataflow_doublequeue): Change the iteration
to process new blocks in the same iteration if that
maintains the iteration order.

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106080

--- Comment #11 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:d482b20fd346482635a770281a164a09d608b058

commit r13-6060-gd482b20fd346482635a770281a164a09d608b058
Author: Marek Polacek 
Date:   Tue Feb 14 17:05:44 2023 -0500

warn-access: wrong -Wdangling-pointer with labels [PR106080]

-Wdangling-pointer warns when the address of a label escapes.  This
causes grief in OCaml () as
well as in the kernel:
 because it uses

  #define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here;
})

to get the PC.  -Wdangling-pointer is documented to warn about pointers
to objects.  However, it uses is_auto_decl which checks DECL_P, but DECL_P
is also true for a label/enumerator/function declaration, none of which is
an object.  Rather, it should use auto_var_p which correctly checks VAR_P
and PARM_DECL.

PR middle-end/106080

gcc/ChangeLog:

* gimple-ssa-warn-access.cc (is_auto_decl): Remove.  Use auto_var_p
instead.

gcc/testsuite/ChangeLog:

* c-c++-common/Wdangling-pointer-10.c: New test.
* c-c++-common/Wdangling-pointer-9.c: New test.

[Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-02-15
 Status|UNCONFIRMED |NEW
Summary|[13 Regression] ICE in  |[10/11/12/13 Regression]
   |verify_loop_structure, at   |ICE in
   |cfgloop.cc:1748 since   |verify_loop_structure, at
   |r13-2388-ga651e6d59188da|cfgloop.cc:1748 since
   ||r13-2388-ga651e6d59188da
   Target Milestone|13.0|10.5

--- Comment #3 from Jakub Jelinek  ---
This actually ICEs all the way to r6-3899-gd9a6bd32adc40a7e1e5c7269 if you use
depend (source) instead of doacross (source:).

[Bug tree-optimization/108791] [12/13 Regression] ICE: verify_gimple failed

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108791

--- Comment #4 from Richard Biener  ---
Created attachment 54467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54467=edit
patch

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

[fw at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688

--- Comment #30 from Florian Weimer  ---
(In reply to Segher Boessenkool from comment #29)
> (In reply to Florian Weimer from comment #28)
> > Maybe this belongs in the ABI manual? For example, the POWER ABI says that
> > memcpy needs to work on device memory.
> 
> Huh?!
> 
> Where do you see this?  The way you state it it is trivially impossible to
> implement, so if we really say that it needs fixing asap.

I thought I had an explicit documented reference somewhere, but for now, all we
have is an undocumented requirement (so not a good example in the context of
this bug at all):

[PATCH] powerpc: Use aligned stores in memset


(There's also a CPU quirk in this area, but I think this wasn't about that.)

[Bug ipa/108802] missed inlining of call via pointer to member function

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This changed with r10-3542-g0b92cf305dcf34387a8e2564e55ca8948df3b47a

[Bug tree-optimization/108783] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 3)

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108783

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #54465|0   |1
is obsolete||

--- Comment #5 from Jakub Jelinek  ---
Created attachment 54466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54466=edit
gcc13-pr108783.patch

Better patch.  In the original testcase, a && a can be simplified to a despite
being (ab), and generally, there is no need to build_and_add_sum if t is the
same comparison as curr->op.

[Bug ipa/108800] Missed optimization: IPA-SRA keeps a single-field structure formal parameter even when IPA-CP knows its contents

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108800

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-15
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug ipa/108802] missed inlining of call via pointer to member function

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |ipa
 CC||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
t.ii:7:49: missed:   will not early inline: int
f1()/2->f1():: [with auto:1 = int (A::*)(int)]/1, growth 14
exceeds --param early-inlining-insns

the lambda is only IPA inlined which is then too late to figure the member
function inlining.  Maybe this is sth for IPA-CP?

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688

--- Comment #29 from Segher Boessenkool  ---
(In reply to Florian Weimer from comment #28)
> Maybe this belongs in the ABI manual? For example, the POWER ABI says that
> memcpy needs to work on device memory.

Huh?!

Where do you see this?  The way you state it it is trivially impossible to
implement, so if we really say that it needs fixing asap.

[Bug tree-optimization/108802] New: missed inlining of call via pointer to member function

[pobrn at protonmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

Bug ID: 108802
   Summary: missed inlining of call via pointer to member function
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pobrn at protonmail dot com
  Target Milestone: ---

See https://gcc.godbolt.org/z/j833EGfGY

struct A {
int f(int x) { return 2 * x; }
};

int f1() {
A a;
return [&](auto&& f) { return (a.*f)(42); } (::f);
}

clang optimizes `f1()` to `return 84`, but gcc does not do so. This seems to
have been changed somewhere between gcc 9 and 10 because 9.5 does the inlining
but 10.1 does not do it.

[Bug tree-optimization/108783] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 3)

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108783

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #4 from Jakub Jelinek  ---
Created attachment 54465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54465=edit
gcc13-pr108783.patch

Untested fix.

[Bug ada/108801] New: ICE, task’s secondary_stack_size from parent discriminant

[simon at pushface dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108801

Bug ID: 108801
   Summary: ICE, task’s secondary_stack_size from parent
discriminant
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54464=edit
Reproducer

An instance of a task type is declared in a record with a discriminant
Secondary_Storage_Size. The task’s Secondary_Storage_Size is specified using
the record’s corresponding discriminant, like so:

package Demo is

   type Event_Queue_Base (Secondary_Stack_Size : Natural)
  is tagged limited private;

private

   task type Dispatcher (The_Queue: access Event_Queue_Base'Class;
 Secondary_Stack_Size : Natural)
 with Secondary_Stack_Size => Secondary_Stack_Size;

   type Event_Queue_Base (Secondary_Stack_Size : Natural)
  is tagged limited record
 The_Dispatcher : Dispatcher
   (Event_Queue_Base'Access,
Secondary_Stack_Size => Secondary_Stack_Size);
  end record;

end Demo;

All is fine in a normal compilation, but under the Ravenscar profile (or,
indeed, just pragma Restrictions (No_Implicit_Heap_Allocations)) this happens:

$ gnatmake -c -u -f demo.ads
gcc -c demo.ads
+===GNAT BUG DETECTED==+
| 12.2.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access  |
| Error detected at demo.ads:14:9  |
| Compiling demo.ads   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

demo.ads

compilation abandoned
gnatmake: "demo.ads" compilation error

This also happens with 10.1, 11.2, but not with 9.1.

[Bug tree-optimization/108783] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 3)

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108783

--- Comment #3 from Jakub Jelinek  ---
Though, the optimization that does this has been added in
r0-99848-g844381e5bc6eb515df838279 for PR28685.

[Bug tree-optimization/108783] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 3)

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108783

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #2 from Jakub Jelinek  ---
ICEs since r13-1754-g7a158a5776f5ca95a318 when the check has been added.
Anyway, looking just at dumps, reassoc1 does this since
r5-4662-gd5e254e19c59fcc49265dda
That commit looks unrelated, but it actually changes quite a lot the generated
IL for some reason already starting with ssa dump.

[Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
See PR104688

[Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64

[balder at yahooinc dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649

--- Comment #5 from Henning Baldersheim  ---
Are there any next steps here.
This is still an issue at least with gcc-12. It would be nice to get rid of the
hacks we have to avoid it.

[Bug ipa/108800] New: Missed optimization: IPA-SRA keeps a single-field structure formal parameter even when IPA-CP knows its contents

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108800

Bug ID: 108800
   Summary: Missed optimization: IPA-SRA keeps a single-field
structure formal parameter even when IPA-CP knows its
contents
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This is a follow-up from PR 108679.  In testcase gcc.dg/ipa/pr108679.c
IPA-SRA replaces a bigger structure with a smaller one, containing
just one field, even though IPA-CP knows the contents of the single
scalar in it at compile time.

The problem is that removing it confuses call-redirection which is
unable to re-construct the single-field structure in a local variable
to pass it as an argument in a call to a different (external)
function.

[Bug ipa/108679] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:656 since r13-4685-g4834e9360f7bf42f

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679

Martin Jambor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Martin Jambor  ---
Fixed, thanks for reporting and reducing the testcase.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718

--- Comment #10 from Martin Liška  ---
(In reply to David Binderman from comment #9)
> Created attachment 54463 [details]
> C source code
> 
> After a further hour of reduction, a partially reduced program.
> 
> cvise doesn't seem able to make much further progress with it.

However, I see a segfault that happens for the code snippet now.

[Bug ipa/108679] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:656 since r13-4685-g4834e9360f7bf42f

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:8b1b1b2d691d5cee4ebc40a01974ad5bccab22f9

commit r13-6003-g8b1b1b2d691d5cee4ebc40a01974ad5bccab22f9
Author: Martin Jambor 
Date:   Wed Feb 15 11:38:01 2023 +0100

ipa: Avoid IPA confusing scalar values and single-field aggregates (PR
108679)

PR 108679 testcase shows a situation when IPA-CP is able to track a
scalar constant in a single-field structure that is part of a bigger
structure.  This smaller structure is however also passed in a few
calls to other functions, but the two same-but-different entities,
originally placed at the same offset and with the same size, confuse
the mechanism that takes care of handling call statements after
IPA-SRA.

I think that in stage 4 it is best to revert to GCC 12 behavior in this
particular case (when IPA-CP detects a constant in a single-field
structure or a single element array that is part of a bigger aggregate)
and the patch below does that.  If accepted, I plan to file a
missed-optimization bug to track that we could use the IPA-CP propagated
value to re-construct the small aggregate arguments.

gcc/ChangeLog:

2023-02-13  Martin Jambor  

PR ipa/108679
* ipa-sra.cc (push_param_adjustments_for_index): Do not omit
creation of non-scalar replacements even if IPA-CP knows their
contents.

gcc/testsuite/ChangeLog:

2023-02-13  Martin Jambor  

PR ipa/108679
* gcc.dg/ipa/pr108679.c: New test.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718

--- Comment #9 from David Binderman  ---
Created attachment 54463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54463=edit
C source code

After a further hour of reduction, a partially reduced program.

cvise doesn't seem able to make much further progress with it.

[Bug c/108799] New: Improper deprecation diagnostic for rsp clobber

[andrew.cooper3 at citrix dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799

Bug ID: 108799
   Summary: Improper deprecation diagnostic for rsp clobber
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.cooper3 at citrix dot com
  Target Milestone: ---

Originally from LKML. 
https://lore.kernel.org/lkml/y9lfmq%2fr1%2fpep...@biznet-home.integral.gnuweeb.org/

Slightly modified example: https://godbolt.org/z/xx76nEvKM

Given:
  static void clobber_redzone_buggy(void)
  {
  register unsigned long rsp asm("rsp");
  unsigned long fl;

  asm volatile ("pushf; popq %[fl]"
: [fl] "=r" (fl)
   , "+r" (rsp)
:
: //"rsp"
  );
  }

  static void set_red_zone(long *mem, long val)
  {
  __asm__ volatile ("movq %[val], %[mem]"
: [mem] "=m" (*mem)
: [val] "r" (val));
  }

  static long get_red_zone(long *mem)
  {
  long ret;

  __asm__ volatile ("movq %[in], %[out]"
: [out] "=r" (ret)
: [in] "m" (*mem));
  return ret;
  }

  long a_leaf_func_with_red_zone(void)
  {
  long x;

  set_red_zone(, 1);
  clobber_redzone_buggy();
  /* The correct retval is 1 */
  return get_red_zone();
  }

gcc generates:

  a_leaf_func_with_red_zone:
  movl$1, %eax
  movq%rax, -8(%rsp)
  pushf
  popq%rax
  movq-8(%rsp), %rax
  ret

which is buggy because the asm clobbers the same redzone slot as `x` occupies.

Swapping the "+r"(rsp) constraint for an explicit "rsp" clobber generates:

  a_leaf_func_with_red_zone:
  pushq   %rbp
  movl$1, %eax
  movq%rsp, %rbp
  subq$16, %rsp
  movq%rax, -8(%rbp)
  pushf
  popq%rax
  movq-8(%rbp), %rax
  leave
  ret

which seems to do the right thing.  It sets up a full stack frame and avoids
using the redzone.

However, doing so yields:

  warning: listing the stack pointer register 'rsp' in a clobber list is
deprecated [-Wdeprecated]
  note: the value of the stack pointer after an 'asm' statement must be the
same as it was before the statement

The note is incorrect.  For ABIs with a redzone, the requirement is stricter
than simply preserving the value of the stack pointer.

The warning suggests that there ought to be a different way to express "this
clobbers the redzone", but there doesn't appear to be any other way.  If this
is the case, why is it deprecated?

[Bug fortran/108512] [13 Regression][OpenMP] ICE for valid loop data-sharing clauses

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108512

Tobias Burnus  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Tobias Burnus  ---
FIXED on mainline (= GCC 13).

[Bug fortran/108512] [13 Regression][OpenMP] ICE for valid loop data-sharing clauses

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108512

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:7a8cada824c5e45ea729c112f3d1d29956067b7b

commit r13-6002-g7a8cada824c5e45ea729c112f3d1d29956067b7b
Author: Tobias Burnus 
Date:   Wed Feb 15 11:23:31 2023 +0100

OpenMP/Fortran: Fix loop-iter var privatization with !$OMP LOOP [PR108512]

For 'parallel', loop-iteration variables are marked are marked as
'private',
unless they either appear in an omp do/simd loop or an data-sharing clause
already exists for those on 'parallel'. 'omp loop' wasn't handled, leading
to (potentially) multiple data-sharing clauses in gfc_resolve_do_iterator
as omp_current_ctx pointed to the 'parallel' directive, ignoring the
in-betwen 'loop' directive.

The latter lead to a bogus diagnostic - or rather an ICE as the source
location var contained only '\0'.

Additionally, several 'case EXEC_OMP...LOOP' have been added to call the
right resolution function and likewise for '{masked,master} taskloop'.

gcc/fortran/ChangeLog:

PR fortran/108512
* openmp.cc (gfc_resolve_omp_parallel_blocks): Handle combined
'loop'
directives.
(gfc_resolve_do_iterator): Set a source location for added
'private'-clause arguments.
* resolve.cc (gfc_resolve_code): Call gfc_resolve_omp_do_blocks
also for EXEC_OMP_LOOP and gfc_resolve_omp_parallel_blocks for
combined directives with loop + '{masked,master} taskloop (simd)'.

gcc/testsuite/ChangeLog:

PR fortran/108512
* gfortran.dg/gomp/loop-5.f90: New test.
* gfortran.dg/gomp/loop-2.f90: Update dg-error.
* gfortran.dg/gomp/taskloop-2.f90: Update dg-error.

[Bug fortran/108693] Update shared character array inside OpenMP critical section causes internal compiler error

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108693

Tobias Burnus  changed:

   What|Removed |Added

 Depends on||97977
 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
Pre-remark: Allocatable scalar character variables consists of a pointer to the
actual data ('mask') and a hidden variable ('.mask') which contains the string
length.

 * * *

lower_omp_taskreg calls lower_rec_input_clauses which has:


6199  x = build_outer_var_ref (var, ctx);

(gdb) p debug(x)
.omp_data_i->mask


So far so good, but when calling

6329   x = lang_hooks.decls.omp_clause_copy_ctor
6330   (c, unshare_expr (new_var), x);

But that causes too much code to be generated and that code
also has an error_mark_node:


(gdb) p debug(x)
{
  void * D.4350;

  if ((void *) .omp_data_i->mask != 0B)
{
  mask = (character(kind=1)[1:D.4340] *) .omp_data_i->mask;
  D.4350 = __builtin_malloc (MAX_EXPR <(unsigned long) SAVE_EXPR
<(sizetype) NON_LVALUE_EXPR  error >, 1>);

* * *

I think one issue is that there is no 'shared(.mask)' to make the string
available. — We had a similar discussion elsewhere. -> PR97977.

I vaguely recall some IRC discussion about this that the solution is
non-trivial in general (for implicit mapping). However, here we have an
explicit 'share(mask)', where adding an implicit 'share(.mask)' could be
easier.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97977
[Bug 97977] Fortran deferred length strings incompatible with OMP

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108787

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[yinyuefengyi at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351

--- Comment #4 from Xionghu Luo (luoxhu at gcc dot gnu.org)  ---

> early inline pass inlines the two calls with C front-end but fails to inline
> them with C++ front-end due to "growth 8 exceeds --param
> early-inlining-insns  divided by number of calls". 
> 

Swap C and C++ here...

[Bug target/103109] madd not used for multiply add on POWER9

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103109

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:3f71b82596e992eb6e53fe9bbd70a4b52bc908e8

commit r13-5999-g3f71b82596e992eb6e53fe9bbd70a4b52bc908e8
Author: Jakub Jelinek 
Date:   Wed Feb 15 09:56:47 2023 +0100

powerpc: Fix up expansion for WIDEN_MULT_PLUS_EXPR [PR108787]

WIDEN_MULT_PLUS_EXPR as documented has the factor operands with
the same precision and the addend and result another one at least twice
as wide.
Similarly, {,u}maddMN4 is documented as
'maddMN4'
 Multiply operands 1 and 2, sign-extend them to mode N, add operand
 3, and store the result in operand 0.  Operands 1 and 2 have mode M
 and operands 0 and 3 have mode N.  Both modes must be integer or
 fixed-point modes and N must be twice the size of M.

 In other words, 'maddMN4' is like 'mulMN3' except that it also adds
 operand 3.

 These instructions are not allowed to 'FAIL'.

'umaddMN4'
 Like 'maddMN4', but zero-extend the multiplication operands instead
 of sign-extending them.
The PR103109 addition of these expanders to rs6000 didn't handle this
correctly though, it treated the last argument as also having mode M
sign or zero extended into N.  Unfortunately this means incorrect code
generation whenever the last operand isn't really sign or zero extended
from DImode to TImode.

The following patch removes maddditi4 expander altogether from rs6000.md,
because we'd need
maddhd 9,3,4,5
sradi 10,5,63
maddld 3,3,4,5
sub 9,9,10
add 4,9,6
which is longer than
mulld 9,3,4
mulhd 4,3,4
addc 3,9,5
adde 4,4,6
and nothing would be able to optimize the case of last operand already
sign-extended from DImode to TImode into just
mr 9,3
maddld 3,3,4,5
maddhd 4,9,4,5
or so.  And fixes umaddditi4, so that it emits an add at the end to add
the high half of the last operand, fortunately in this case if the high
half of the last operand is known to be zero (i.e. last operand is zero
extended from DImode to TImode) then combine will drop the useless add.

If we wanted to get back the signed op1 * op2 + op3 all in the DImode
into TImode op0, we'd need to introduce a new tree code next to
WIDEN_MULT_PLUS_EXPR and maddMN4 expander, because I'm afraid it can't
be done at expansion time in maddMN4 expander to detect whether the
operand is sign extended especially because of SUBREGs and the awkwardness
of looking at earlier emitted instructions, and combine would need 5
instruction combination.

2023-02-15  Jakub Jelinek  

PR target/108787
PR target/103109
* config/rs6000/rs6000.md (maddditi4): Change into umaddditi4
only
expander, change operand 3 to be TImode, emit maddlddi4 and
umadddi4_highpart{,_le} with its low half and finally add the high
half to the result.

* gcc.dg/pr108787.c: New test.
* gcc.target/powerpc/pr108787.c: New test.
* gcc.target/powerpc/pr103109-1.c: Adjust expected instruction
counts.