[Bug rtl-optimization/99328] New: ICE: in verify_target_availability, at sel-sched.c:1557 with -fselective-scheduling2 on aarch64

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

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

Bug ID: 99328
   Summary: ICE: in verify_target_availability, at
sel-sched.c:1557 with -fselective-scheduling2 on
aarch64
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

gcc11 has the following ICE:

$ cat t.c
long a;
double b, c;
double fn1(double);
void fn2(long *);
void fn3(int p1) {
  fn2(&a);
  if (fn1(0) >= p1)
b = c;
}

$ sh t
/data1/qing/Install/latest/bin/gcc -fprofile-generate -Ofast
-fselective-scheduling -fselective-scheduling2 -c -o t.o t.c
during RTL pass: sched2
t.c: In function 'fn3':
t.c:9:1: internal compiler error: in verify_target_availability, at
sel-sched.c:1557
9 | }
  | ^
0xd86fbb verify_target_availability
../../latest_gcc/gcc/sel-sched.c:1553
0xd86fbb find_best_reg_for_expr
../../latest_gcc/gcc/sel-sched.c:1667
0xd89f33 fill_vec_av_set
../../latest_gcc/gcc/sel-sched.c:3784
0xd89f33 fill_ready_list
../../latest_gcc/gcc/sel-sched.c:4014
0xd89f33 find_best_expr
../../latest_gcc/gcc/sel-sched.c:4374
0xd89f33 fill_insns
../../latest_gcc/gcc/sel-sched.c:5535
0xd8ba17 schedule_on_fences
../../latest_gcc/gcc/sel-sched.c:7353
0xd8ba17 sel_sched_region_2
../../latest_gcc/gcc/sel-sched.c:7491
0xd8c517 sel_sched_region_1
../../latest_gcc/gcc/sel-sched.c:7533
0xd8e573 sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7634
0xd8f1b7 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0xd6a32f rest_of_handle_sched2
../../latest_gcc/gcc/sched-rgn.c:3738
0xd6a32f execute
../../latest_gcc/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

this is a reduced testing case from CPU2017 511.povray.
gcc10 has the same issue.

[Bug rtl-optimization/99332] New: ICE:inreset_sched_cycles_in_current_ebb, at sel-sched.c:7147 with -fprofile-generate -O3 -fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining

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

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

Bug ID: 99332
   Summary: ICE:inreset_sched_cycles_in_current_ebb, at
sel-sched.c:7147 with -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2
-fsel-sched-pipelining
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

This testing case is reduced from CPU2017 511.povray, it appears on aarch64
with both gcc11 and gcc10:

$ cat t.C
class OStream {
public:
  void printf(...);
};
typedef double VECTOR[3];
enum { X, Y, Z };
typedef struct ot_block_struct OT_BLOCK;
typedef int OT_NODE;
struct ot_block_struct {
  OT_BLOCK *next;
  VECTOR Point, S_Normal;
  VECTOR To_Nearest_Surface;
  short Bounce_Depth;
};
bool ot_write_block(OT_BLOCK *, void *);
bool ot_traverse(OT_NODE *, bool function(OT_BLOCK *, void *), void *handle) {
  bool oksofar;
  OT_BLOCK *this_block;
  while (this_block) {
function(this_block, handle);
this_block = this_block->next;
  }
  return oksofar;
}

bool ot_save_tree() {
  int *fd, *root;
  ot_traverse(root, ot_write_block, fd);
}

bool ot_write_block(OT_BLOCK *bl, void *fd) {
  ((OStream *)fd)->printf(
  bl[Z], bl->S_Normal[X] * int(bl->S_Normal[Z] * .5 * 254. + .49),
  bl[Z], int(bl->To_Nearest_Surface[X]),
  int((bl->To_Nearest_Surface[Y] + 1.) * .5 * 254. + .49),
  int((bl->To_Nearest_Surface[Z] + 1.) * .5 * 254. + .49));
  return true;
}

[qzlocal@ca-dev-arm06 bug_2]$ sh t
/data1/qing/Install/latest/bin/g++ -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining -c -o t.o
t.C
t.C: In function 'bool ot_save_tree()':
t.C:29:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   29 | }
  | ^
during RTL pass: sched2
t.C:29:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7147
0x1063387 reset_sched_cycles_in_current_ebb
../../latest_gcc/gcc/sel-sched.c:7147
0x1063387 sel_region_target_finish
../../latest_gcc/gcc/sel-sched.c:7220
0x1063387 sel_region_finish
../../latest_gcc/gcc/sel-sched.c:7276
0x1063387 sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7645
0x1063593 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0x103e70b rest_of_handle_sched2
../../latest_gcc/gcc/sched-rgn.c:3738
0x103e70b execute
../../latest_gcc/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

CPU2017 511.povray cannot be compiled on aarch64 due to this bug.

[Bug rtl-optimization/99421] New: ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64

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

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

Bug ID: 99421
   Summary: ICE:in code_motion_process_successors, at
sel-sched.c:6389 on aarch64
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

with the attached tar file, (from CPU2017 502.gcc_r)
untar it,
cd bug_3
sh t
during RTL pass: sched2
predict.c: In function ‘expr_expected_value_1’:
predict.c:1263:1: internal compiler error: in code_motion_process_successors,
at sel-sched.c:6389
0xd83883 code_motion_process_successors
../../latest_gcc_2/gcc/sel-sched.c:6386
0xd83883 code_motion_path_driver
../../latest_gcc_2/gcc/sel-sched.c:6609
0xd834f7 code_motion_process_successors
../../latest_gcc_2/gcc/sel-sched.c:6343
0xd834f7 code_motion_path_driver
../../latest_gcc_2/gcc/sel-sched.c:6609
0xd8645f move_op
../../latest_gcc_2/gcc/sel-sched.c:6702
0xd8645f move_exprs_to_boundary
../../latest_gcc_2/gcc/sel-sched.c:5224
0xd8645f schedule_expr_on_boundary
../../latest_gcc_2/gcc/sel-sched.c:5436
0xd87be3 fill_insns
../../latest_gcc_2/gcc/sel-sched.c:5578
0xd8a143 schedule_on_fences
../../latest_gcc_2/gcc/sel-sched.c:7353
0xd8a143 sel_sched_region_2
../../latest_gcc_2/gcc/sel-sched.c:7491
0xd8ac43 sel_sched_region_1
../../latest_gcc_2/gcc/sel-sched.c:7533
0xd8cc83 sel_sched_region(int)
../../latest_gcc_2/gcc/sel-sched.c:7634
0xd8d8d7 run_selective_scheduling()
../../latest_gcc_2/gcc/sel-sched.c:7720
0xd68977 rest_of_handle_sched2
../../latest_gcc_2/gcc/sched-rgn.c:3738
0xd68977 execute
../../latest_gcc_2/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


NOTE, this error is repeated with -fprofile-use, and the pre-generated
profiling data file predict.gcda is generated with gcc11 as following:

Target: aarch64-unknown-linux-gnu
Configured with: ../latest_gcc_2/configure
--prefix=/home/qinzhao/Install/latest-2 --enable-languages=c,c++,fortran,lto
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210304 (experimental) (GCC) 

since the error depends on the profiling feedback data, the testing case cannot
be reduced by hand or by tool (Creduce), I have to attach the complete
preprocessed file to repeat the error.

[Bug rtl-optimization/99421] ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
Created attachment 50318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50318&action=edit
tar ball to repeat the failure

[Bug rtl-optimization/99421] ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64

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

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

--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #3)
> Confirmed, reduced test-case:
>
just curious, how did you reduce the testing case with -fprofile-use? (I tried
Creduce, but failed)
another question, how to repeat the failure with this reduced testing case?

[Bug rtl-optimization/99627] New: ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-st

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

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

Bug ID: 99627
   Summary: ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347
with -fprofile-use -fselective-scheduling
-fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops -O3
-fno-strict-aliasing
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

Another selective scheduler's bug with profiling feedback from CPU2017.
reduced testing case attached.

to reproduce:

download the *.tar.xz file;
untar it;
cd bug_4
sh t

qinzhao@gcc113:~/Bugs/bug_4$ sh t
during RTL pass: sched1
cfgloop.h: In function ‘loop_optimizer_finalize’:
cfgloop.h:41:1: internal compiler error: in sel_is_loop_preheader_p, at
sel-sched-ir.c:6347
0xcb24b3 sel_is_loop_preheader_p(basic_block_def*)
../../latest_gcc/gcc/sel-sched-ir.c:6347
0xcc5307 sel_sched_region_1
../../latest_gcc/gcc/sel-sched.c:7588
0xcc68bb sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7634
0xcc68bb sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7619
0xcc6ae7 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0xca511f rest_of_handle_sched
../../latest_gcc/gcc/sched-rgn.c:3724
0xca511f execute
../../latest_gcc/gcc/sched-rgn.c:3834
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/99627] ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-strict-

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

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
Created attachment 50411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50411&action=edit
testing case and script

testing case and script

[Bug rtl-optimization/99627] ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-strict-

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
NOTE, this failure is on aarch64.

[Bug tree-optimization/100053] New: tree-fre incorrectly delete a condition

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

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

Bug ID: 100053
   Summary: tree-fre incorrectly delete a condition
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

hi, this is a bug with tree-fre optimization that caused run-time segmentation
fault. 
the original testing case cannot be posted.

the following is the reduced testing case through Creduce. 
ubuntu@qinzhao-ubuntu-x86:~/Bugs/32423691$ cat ksm.i
typedef a;
typedef struct b b;
struct {
  char c
} typedef d;
struct e {
  int f;
  char g
} typedef aa;
struct {
  int ad;
  char ae
} typedef ab;
struct {
  int ac;
  char ah;
  int ai;
  a *h;
  b *ag
} typedef af;
struct b {
  af i;
  struct e *j
} m;
k, o, q, r, s, t, u;
typedef l[];
l n;
*p;
ab al;
v(init) {
  d *aj;
  int ak;
  if (!init) {
w();
aj = q;
if (p[t])
  goto aq;
af am = (&m)->i;
if (_setjmp())
  if ((&m)->i.h) {
a an, ao;
aa *ap = am.h[(&m)->i.ai];
void *au;
if ((&m)->i.ai) {
  if (x())
an += (long)au % (&m)->i.ag->j->f;
  if ((a)__builtin_alloca)
ao = au = an;
  ap->g = "";
}
y(ao);
  }
ak |= z(n[k], ak, init ? 0 : ((int *)o)[t]);
(&al)->ad = (&m)->i.ac & (&m)->i.ah;
(&m)->i.ac = (&al)->ae = &al;
  }
  if (!init)
aj->c = s;
  ar(u, r, s);
aq:
  if (!init)
as(((int *)o)[t]);
}
ubuntu@qinzhao-ubuntu-x86:~/Bugs/32423691$ cat t
/home/ubuntu/Install/latest-debug/bin/gcc ksm.i -c -o ksm.o  -O2 
-fdump-tree-optimized 

ubuntu@qinzhao-ubuntu-x86:~/Bugs/32423691$ sh t


there are quite some warnings during compilation, please ignore them.

check the ksm.i.244t.optimized, you will find that the last "if (!init)" is
completely deleted;

if you add -fno-tree-fre to the compilation line, the last "if (!init)" will
not be deleted anymore.

[Bug tree-optimization/100053] [9/10 Regression] tree-fre incorrectly delete a condition

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

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> It would be nice if the reduced testcase could be sanitized to throw less
> diagnostics with -Wall, likewise if it were a runtime testcase.
> 
> Reduced:
> 
> int __attribute__((returns_twice,noipa)) x() { return 0; }
> void __attribute__((noipa)) ar() {}
> void __attribute__((noipa)) as() { __builtin_abort (); }
> int a1, a2, a3;
> void __attribute__((noipa)) v(int init)
> { 
>   if (!init) {
> as();
> if (a1)
>   goto aq;
> if (x ())
>   if (a2)
> as();
>   }
>   if (!init)
> a3 = 1;
>   ar();
> aq:
>   if (!init)
> as();
> }
> 
> int main()
> {
>   v(1);
>   return 0;
> }

Hi, thanks for the further reduced testing case.
I am wondering whether you did the above further reducing manually?

[Bug tree-optimization/100053] [9/10 Regression] tree-fre incorrectly delete a condition

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

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

--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> Created attachment 50579 [details]
> fix for the issue
> 
> I am testing this patch - maybe you can test it on the original testcase you
> cannot disclose.
>

I tested this patch with the original test case, and it resolved the runtime
error.
thanks.

[Bug middle-end/97357] New: Unable to coalesce ssa_names which are marked as MUST COALESCE.

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

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

Bug ID: 97357
   Summary: Unable to coalesce ssa_names  which are marked as MUST
COALESCE.
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

the latest gcc10.2.1 failed with SSA corruption on multiple c modules of our
important application on O3. disabling -fsplit-loops cures the failure.

I was able to reduce the huge routine to the following simple one to reproduce
the failure:

#include 
#include 

static void * my_malloc (size_t size);

typedef struct glk {
  struct glk *nxt;
} glk;

typedef struct Lock
{
 glk ByteLock;
} Lock;

static Lock *l, *lk;

void bytelocks(glk *rethead, jmp_buf jb)
{
  glk *cur, *cur_lk;

  if (( _setjmp (jb)) == 0) 
for (cur = &l->ByteLock; cur != ((glk *)0) ; cur = (cur)->nxt)
for (cur_lk = &lk->ByteLock; cur_lk != ((glk *)0); cur_lk =
cur_lk->nxt)
  {
glk *retrng;

if(!rethead)
  rethead = (glk *) my_malloc (sizeof(glk));
retrng = (glk *) my_malloc (sizeof(glk));

retrng->nxt = rethead;
  }

 return;
}
/home/qinzhao/Install/latest/bin/gcc -O3 t.c
t.c:4:15: warning: ‘my_malloc’ used but never defined
4 | static void * my_malloc (size_t size);
  |   ^

Unable to coalesce ssa_names 5 and 6 which are marked as MUST COALESCE.
rethead_5(ab) and  rethead_6(ab)
during RTL pass: expand
t.c: In function ‘bytelocks’:
t.c:17:6: internal compiler error: SSA corruption
   17 | void bytelocks(glk *rethead, jmp_buf jb)
  |  ^
0xbcca65 fail_abnormal_edge_coalesce
../../latest_gcc/gcc/tree-ssa-coalesce.c:1003
0xbcca65 coalesce_partitions
../../latest_gcc/gcc/tree-ssa-coalesce.c:1425
0xbcca65 coalesce_ssa_name(_var_map*)
../../latest_gcc/gcc/tree-ssa-coalesce.c:1755
0xb7d597 remove_ssa_form
../../latest_gcc/gcc/tree-outof-ssa.c:1065
0xb7d597 rewrite_out_of_ssa(ssaexpand*)
../../latest_gcc/gcc/tree-outof-ssa.c:1323
0x6fb5d5 execute
../../latest_gcc/gcc/cfgexpand.c:6352
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/97357] Unable to coalesce ssa_names which are marked as MUST COALESCE.

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

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
/home/qinzhao/Install/latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/qinzhao/Install/latest/bin/gcc
COLLECT_LTO_WRAPPER=/home/qinzhao/Install/latest/libexec/gcc/x86_64-pc-linux-gnu/10.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../latest_gcc/configure --prefix=/home/qinzhao/Install/latest
-enable-languages=c,c++,fortran,lto
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20201009 (GCC)

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
as we noticed, when using gcc10.2.1 compile our application, 528 C++ modules
failed with this bug. 

looks like a high priority bug to me.

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/97357] [10 Regression] Unable to coalesce ssa_names which are marked as MUST COALESCE.

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

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
with the patch, all the C modules in our application that failed with this bug
passed without any issue.

[Bug testsuite/97680] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors

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

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
(In reply to seurer from comment #0)

> commit d10f3e900b0377b4760a090b0f90371bcef01686
> Author: qing zhao 
> Date:   Fri Oct 30 20:41:38 2020 +0100
> 
> If looks like the errors are all like this:
> 
> FAIL: c-c++-common/zero-scratch-regs-10.c  -std=gnu++98 (test for excess
> errors)
> Excess errors:
> /home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/zero-scratch-regs-
> 10.c:77:1: sorry, unimplemented: '-fzero-call-used_regs' not supported on
> this target

Hi, this is an expected error on this platform since the middle-end
implementation of -fzero-call-used-regs doesn't work for it. Please mark these
testing case as expected failure on this platform, or finish the implementation
on powerpc backend

[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Err, please dg-skip the tests for ! supported targets.  They also fail on
> x86_64 with -m32 btw.

x86_64 with -m32 failure should be already fixed by Uros already.

[Bug testsuite/97699] [11 regression] zero-scratch-regs tests fail on arm

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #2 from qinzhao at gcc dot gnu.org ---
this might be expected behavior since the implementation should work for
aarch64 and x86. 
other platforms either need to skip this testing or finish the implementation
at backend.

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
mode, However, command line option force no 80387 mode, the following insn
generated to zero st registers is not recognized:

(insn 27 67 28 2 (set (reg:XF 8 st)
(const_double:XF 0.0 [0x0.0p+0])) "zero-scratch-regs-10.c":8:1 -1
 (nil))

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #2)
> (In reply to qinzhao from comment #1)
> > for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
> > mode, However, command line option force no 80387 mode, the following insn
> > generated to zero st registers is not recognized:
> > 
> > (insn 27 67 28 2 (set (reg:XF 8 st)
> > (const_double:XF 0.0 [0x0.0p+0])) "zero-scratch-regs-10.c":8:1 -1
> >  (nil))
> 
> You should avoid zeroing fixed registers.

fixed registers should already be excluded from zeroing. 
are ST registers considered FIXED registers when -mno-80387 is specified?

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> ;; Floating-point register constraints.
> (define_register_constraint "f"
>  "TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387 ? FLOAT_REGS : NO_REGS"
>  "Any 80387 floating-point (stack) register.")
> 
> So, zero_all_st_registers really should just
>   if (!TARGET_80387 && !TARGET_FLOAT_RETURNS_IN_80387)
> return false;
> somewhere early.

I can do this to avoid the ICE. however, the st/mm register set will NOT be
zeroed under such situation when user requests to zero them with
-fzero-call-used-regs=all.

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

--- Comment #22 from qinzhao at gcc dot gnu.org ---
proposed patch:

This change fixes a bug in the i386 backend when adding
-fzero-call-used-regs=all on a target that has no x87
registers.

When there is no x87 registers available, we should not
zero stack registers.

gcc/Changelog:

PR target/97715
* config/i386/i386.c (zero_all_st_registers): Return
earlier when the FPU is disabled.

gcc/testsuite/ChnageLog:

PR target/97715
* gcc.target/i386/zero-scratch-regs-32.c: New test.
---
 gcc/config/i386/i386.c   |  5 +
 gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c | 11 +++
 2 files changed, 16 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6fc6228a26e..789ef727cf8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3640,6 +3640,11 @@ zero_all_vector_registers (HARD_REG_SET
need_zeroed_hardregs)
 static bool
 zero_all_st_registers (HARD_REG_SET need_zeroed_hardregs)
 {
+
+  /* If the FPU is disabled, no need to zero all st registers.  */
+  if (! (TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387))
+return false;
+
   unsigned int num_of_st = 0;
   for (unsigned int regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
 if ((STACK_REGNO_P (regno) || MMX_REGNO_P (regno))
diff --git a/gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c
b/gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c
new file mode 100644
index 000..ca3261fe5ea
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c
@@ -0,0 +1,11 @@
+/* { dg-do compile { target *-*-linux* } } */
+/* { dg-options "-O2 -fzero-call-used-regs=all -mno-80387" } */
+
+int
+foo (int x)
+{
+  return (x + 1);
+}
+
+/* { dg-final { scan-assembler-not "fldz" } } */
+
--

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #25 from qinzhao at gcc dot gnu.org ---
fixed in gcc11

[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #2 from qinzhao at gcc dot gnu.org ---
when configured the gcc with --enable-checking=df, I can repeat the failure.
will check what's wrong with the data flow information.

[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
This does not look like a bug in the new -fzero-call-used-regs implemenation.

it's more likely an existing bug in data flow analysis. 

I made the following change in gcc/function.c to make the new pass to do
nothing except a df_analyze:

qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff function.c
diff --git a/gcc/function.c b/gcc/function.c
index 004fa389207..658b08ae215 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -6658,13 +6658,14 @@ pass_zero_call_used_regs::execute (function *fun)
   /* Iterate over the function's return instructions and insert any
  register zeroing required by the -fzero-call-used-regs command-line
  option or the "zero_call_used_regs" function attribute.  */
+#if 0
   FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
 {
   rtx_insn *insn = BB_END (e->src);
   if (JUMP_P (insn) && ANY_RETURN_P (JUMP_LABEL (insn)))
gen_call_used_regs_seq (insn, zero_regs_type);
 }
-
+#endif
   return 0;
 }

with this gcc, the exactly same ICE still there.

[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all

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

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

--- Comment #4 from qinzhao at gcc dot gnu.org ---
this should be a bug in the pass "stack".
if I modify the file "reg-stack.c" as following:
qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff reg-stack.c
diff --git a/gcc/reg-stack.c b/gcc/reg-stack.c
index 8f98bd85750..3d6519c95c9 100644
--- a/gcc/reg-stack.c
+++ b/gcc/reg-stack.c
@@ -3428,6 +3428,7 @@ rest_of_handle_stack_regs (void)
 #ifdef STACK_REGS
   reg_to_stack ();
   regstack_completed = 1;
+  df_analyze ();
 #endif
   return 0;
 }

the testing case will core dump at:
t.c: In function ‘foo’:
t.c:5:1: internal compiler error: in df_refs_verify, at df-scan.c:3991
5 | }
  | ^
0xc3e634 df_refs_verify
../../write_gcc/gcc/df-scan.c:3991
0xc3e8a5 df_insn_refs_verify
../../write_gcc/gcc/df-scan.c:4075
0xc3ea83 df_bb_verify
../../write_gcc/gcc/df-scan.c:4107
0xc3f046 df_scan_verify()
../../write_gcc/gcc/df-scan.c:4228
0xc2576c df_verify()
../../write_gcc/gcc/df-core.c:1818
0xc23fdd df_analyze_1
../../write_gcc/gcc/df-core.c:1214
0xc2439e df_analyze()
../../write_gcc/gcc/df-core.c:1290
0x115d581 rest_of_handle_stack_regs
../../write_gcc/gcc/reg-stack.c:3431
0x115d5d2 execute
../../write_gcc/gcc/reg-stack.c:3461

looks like that the pass reg stack does not maintain the df information
correctly during its transformation.

[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all

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

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

--- Comment #5 from qinzhao at gcc dot gnu.org ---
the following patch in reg-stack.c fixed the failure:

qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff reg-stack.c
diff --git a/gcc/reg-stack.c b/gcc/reg-stack.c
index 8f98bd85750..3dab843f803 100644
--- a/gcc/reg-stack.c
+++ b/gcc/reg-stack.c
@@ -3426,7 +3426,8 @@ static unsigned int
 rest_of_handle_stack_regs (void)
 {
 #ifdef STACK_REGS
-  reg_to_stack ();
+  if (reg_to_stack ())
+df_insn_rescan_all ();
   regstack_completed = 1;
 #endif
   return 0;

[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
fixed in gcc11

[Bug other/97309] New: Improve documentation of -fallow-store-data-races

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

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

Bug ID: 97309
   Summary: Improve documentation of -fallow-store-data-races
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

As of GCC 10, the former --param allow-store-data-races is now 
-fallow-store-data-races.  The default, in both cases, is not to allow them.   

For releases prior to GCC 10, the --param is documented as 

   allow-store-data-races 
   Allow optimizers to introduce new data races on stores.  Set 
to 1 to allow, otherwise to 0. 

The description for GCC 10 is simply: 

   -fallow-store-data-races 
   Allow the compiler to introduce new data races on stores. 
   Enabled at level -Ofast. 

There are three problems with this description. 

(1) The explanation is sparse - basically it just repeats the name of the 
switch.   

(2) It provides no context to explain the circumstances under which it may or 
may not be safe to use. 

(3) Because of the lack of clarity regarding safety, it may be questionable 
as to whether a SPEC CPU user is allowed to use -Ofast 
(http://www.spec.org/cpu2017/Docs/runrules.html#safe) 

Suggested improvement: 

Allow the compiler to perform optimizations that may introduce new data races 
on stores, without proving that the variable cannot be concurrently accessed 
by other threads. Does not affect optimization of local data. It is safe to 
use this option if it is known that global data will not be accessed by 
multiple threads. 

Examples of optimizations enabled by -fallow-store-data-races include 
hoisting or if-conversions that may cause a value that was already in memory 
to be re-written with that same value. Such re-writing is safe in a single 
threaded context but may be unsafe in a multi-threaded context. Note that on 
some processors, if-conversions may be  required in order to enable 
vectorization.

[Bug other/97309] Improve documentation of -fallow-store-data-races

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

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
proposed patch:

Subject: [PATCH] PR97309--improve documentation of -fallow-store-data-races

---
 gcc/doc/invoke.texi | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7c81d7f41bd..926ee1ff28e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -11621,7 +11621,18 @@ Do not remove unused C++ allocations in dead code
elimination.

 @item -fallow-store-data-races
 @opindex fallow-store-data-races
-Allow the compiler to introduce new data races on stores.
+Allow the compiler to perform optimizations that may introduce new data races
+on stores, without proving that the variable cannot be concurrently accessed
+by other threads.  Does not affect optimization of local data.  It is safe to
+use this option if it is known that global data will not be accessed by
+multiple threads.
+
+Examples of optimizations enabled by @option{-fallow-store-data-races} include
+hoisting or if-conversions that may cause a value that was already in memory
+to be re-written with that same value.  Such re-writing is safe in a single
+threaded context but may be unsafe in a multi-threaded context.  Note that on
+some processors, if-conversions may be required in order to enable
+vectorization.

 Enabled at level @option{-Ofast}.

--
2.11.0

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

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

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
when using gcc10.2 to compile our application, we have the same compilation
error.

[Bug other/97309] Improve documentation of -fallow-store-data-races

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
fixed.

[Bug middle-end/98702] New: linker failure with a very simple testing case for gcc10

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

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

Bug ID: 98702
   Summary: linker failure with a very simple testing case for
gcc10
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49980&action=edit
tar file that can repeat the failure

with gcc10.2.1, the following simple testing case failed during linking:

[qinzhao@localhost 32383604]$ cat t.h
int NUMERRS; 
[qinzhao@localhost 32383604]$ cat t.c
#include "t.h"
[qinzhao@localhost 32383604]$ cat t1.c
#include "t.h" 
int main() 
{ 
  NUMERRS = 0;
  return 0; 
} 
[qinzhao@localhost 32383604]$ /home/qinzhao/Install/latest-10/bin/gcc t.c -c -o
t.o  
[qinzhao@localhost 32383604]$ /home/qinzhao/Install/latest-10/bin/gcc t1.c -c
-o t1.o
[qinzhao@localhost 32383604]$ /home/qinzhao/Install/latest-10/bin/gcc t.o t1.o
-o exe.gcc10
t1.o:(.bss+0x0): multiple definition of `NUMERRS'
t.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
[qinzhao@localhost 32383604]$ 

gcc8 and gcc9 do not have this issue.

by examine the object file, I can see gcc10 generate NUMERRS to .bss section,
but gcc8 and gcc9 generate NUMERRS to COM section.

is this a new bug in gcc10?

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

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

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

--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to David Malcolm from comment #15)


> where:
>
> (gdb) call inform (loc_a, "loc_a")
> In file included from
> /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163,
>  from
> /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8,
>  from
> /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69,
>  from
> /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/
> AudioSession.cpp:7,
>  from
> /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/
> Unified_cpp_widget_windows0.cpp:2:
> /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope:
> /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a
>19 |   typedef CONST VOID *PCVOID;

Is the above line the failing point for the testing file?

there is a "CONST" qualifier. I am not sure whether it's helpful or not: we
found that deleting "CONST" from the source code helped the compilation to
succeed.

[Bug preprocessor/96391] [10 Regression] ICE in linemap_compare_locations on "CONST VOID" in large C++ files

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

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

--- Comment #23 from qinzhao at gcc dot gnu.org ---
with the latest gcc11, our application can be compiled without any issue now.
thanks a lot for fixing this bug.

will this patch be added to gcc10?

[Bug c/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
from the standard:

A structure or union shall not contain a member with incomplete or function
type (hence, a structure shall not contain an instance of itself, but may
contain a pointer to an instance of itself), except that the last member of a
structure with more than one named member may have incomplete array type; such
a structure (and any union containing, possibly recursively, a member that is
such a structure) shall not be a member of a structure or an element of an
array.

as a result, if you add -Wpedantic to the compilation line:

[opc@qinzhao-ol8u3-x86 101832]$ sh t
/home/opc/Install/latest-d/bin/gcc -O1 -Wpedantic t.c
t.c:30:18: warning: invalid use of structure with flexible array member
[-Wpedantic]
   30 | struct nlmsg msg;
  |  ^~~


However, looks like that GCC extension allow such usage, but I am not sure
whether there is any documentation on such extension?

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #2)
> The standard does not allow the nesting, but gcc supports it as an extension.

when GCC supports it as an extension, I see two possible situations:

A. the structure with the flexible array member will be the last field of the
outer structure;

B. the structure with the flexible array member will be the middle field of the
outer structure;

I see GCC compile the above 2 cases without any complain (i.e, GCC extension
accepts both A and B) and Adding -Wpedantic issues warnings for both.

My questions:

1. Should GCC extension support the above case B? (it should NOT, right? what's
the point to support it)
2. If GCC extension support the above case A (looks like this is the case, and
some application use this case extensively, for example, Linux Kernel uses this
a lot, See bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832), what's the
clear definition for it? Does it still treat the flexible array member in the
inner structure as a flexible array member in the outer structure? If so, we
might need to clearly document this in GCC's extension, and then user will have
consistent expectation on this.

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> GCC considered this as a flex-array. 

do you mean for the following example:

typedef struct {
  char pad;
  char data[];
} F2;

typedef struct {
  unsigned pad;
  F2 flex;
} S2;

although C standard disallow the above, GCC extension treats S2.flex.data as a
flex-array? 

How about:

typedef struct {
  char pad;
  char data[];
} F2;

typedef struct {
  F2 flex;
  unsigned pad;
} S2;

do we have any documentation on this Gcc extension?

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #16)
> > We might add a new utility routine to determine whether a ref to a struct or
> > union have flexible array?
> 
> It will be useful for __bos/__bdos for sure.

Yes, this new utility routine can be added and used by tree-object-size, then
we can fix the PR 101832 separately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832

[Bug c/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> This is intentional, if you embed an aggregate with flex array into another
> struct and ask not to cross the field boundaries (i.e. bos1), then the size
> of that field is exactly what is the maximum size.

As we discussed in PR 107952
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952):

GCC extension accepts the following two cases:

**Case 1:

struct A { char data[1]; };
struct B { int n; struct A a; };

as if the a.data[] array is a flex-array.  

**Case 2: 

struct C { int n; struct A a; int x; };

as if a.data[] can be up to 4 elements. 

So, what's you mean by "not to cross the field boundaries" is for the above
Case 2? 
For Case 1, we should treat A.data as flexible array, and then B.A as a
structure that has flexible array, therefore B.A's size is flexible too. 

Is my understanding correct?

[Bug c/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
I will add a routine in tree-object-size.cc to check whether a reference to a
structure or union field includes a flexible array member in the inner
structure, such structure or union should be considered as having flexible
size, too. 

then should resolve this bug.

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #19 from qinzhao at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #11)

> > Agreed, usually where these extension should be documented?
> 
> They are usually documented in doc/extend.texi

there is one section on "Zero Length" (Arrays of Length Zero), which mentioned
this a little bit:

"A structure containing a flexible array member, or a union containing
such a structure (possibly recursively), may not be a member of a
structure or an element of an array.  (However, these uses are
permitted by GCC as extensions.)"

We might add one more sub-section inside this section to clarify how GCC
handles the situation when a structure containing a flexible array member
becomes a member of another structure. 

is that a good place to put the documentation?

[Bug c/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #10 from qinzhao at gcc dot gnu.org ---
shall we support the following multi-level nesting?

struct A { int len; char data[]; };
struct B { int n; struct A a; };
struct C { int m, struct B b; };

struct C *outer;

__builtin_object_size (&outer->b, 1);
__builtin_object_size (&outer->b.a, 1);


with the current GCC:

__builtin_object_size(&wrap->b, 1) == 8 
__builtin_object_size(&wrap->b.a, 1) == 4 

We expect both are -1 since the innermost structure A has a trailing flexible
array member.

[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 = &D.2389;
>   _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 = &D.2389;
>   _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 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 #9 from qinzhao at gcc dot gnu.org ---
it's a bug in tree-ssa-uninit.cc actually.

when doing the following:

  /* Ignore the call to .DEFERRED_INIT that define the original
 var itself as the following case:
temp = .DEFERRED_INIT (4, 2, “alt_reloc");
alt_reloc = temp;
 In order to avoid generating warning for the fake usage
 at alt_reloc = temp.
  */

we need to compare the var name inside the .DEFERRED_INIT call (the 3nd
argument) and the name for the left side variable. if they are the same, we
will NOT report the warning. 

there is one issue when we get the name for the left side variable. when the
variable doesn't have a DECL_NAME (it's not a user declared variable, which is
the case for this bug):

>   _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
>   D.2389 = _1;

(in the above example, D.2389 is a variable that doesn't have a DECL_NAME.)

the current checking just ignores this case, and still report the warning. this
is incorrect.

The fix is very simple, when get the var name for the left side variable, we
should consider this case and come up with the name the same way as we
construct the 3rd argument for the call to .DEFERRED_INIT (please refer to the
routine "gimple_add_init_for_auto_var")

[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 #10 from qinzhao at gcc dot gnu.org ---
the following patch fixed this issue:
diff --git a/gcc/tree-ssa-uninit.cc b/gcc/tree-ssa-uninit.cc
index c555cf5cd50..eca727b010a 100644
--- a/gcc/tree-ssa-uninit.cc
+++ b/gcc/tree-ssa-uninit.cc
@@ -113,6 +113,18 @@ uninit_undefined_value_p (tree t)
   return !get_no_uninit_warning (SSA_NAME_VAR (t));
 }

+
+/* Get the name string for the VAR that defined with a call to .DEFERRED_INIT.
+ * Refer to routine gimple_add_init_for_auto_var.  */
+static const char *
+get_var_name (tree var)
+{
+  const char *var_name_str
+= DECL_NAME (var) ? IDENTIFIER_POINTER (DECL_NAME (var))
+  : xasprintf ("D.%u", DECL_UID (var));
+  return var_name_str;
+}
+
 /* Emit warnings for uninitialized variables.  This is done in two passes.

The first pass notices real uses of SSA names with undefined values.
@@ -224,8 +236,6 @@ warn_uninit (opt_code opt, tree t, tree var, gimple
*context,
 at alt_reloc = temp.
  */
  tree lhs_var = NULL_TREE;
- tree lhs_var_name = NULL_TREE;
- const char *lhs_var_name_str = NULL;

  /* Get the variable name from the 3rd argument of call.  */
  tree var_name = gimple_call_arg (var_def_stmt, 2);
@@ -239,11 +249,12 @@ warn_uninit (opt_code opt, tree t, tree var, gimple
*context,
  else if (TREE_CODE (gimple_assign_lhs (context)) == SSA_NAME)
lhs_var = SSA_NAME_VAR (gimple_assign_lhs (context));
}
- if (lhs_var
- && (lhs_var_name = DECL_NAME (lhs_var))
- && (lhs_var_name_str = IDENTIFIER_POINTER (lhs_var_name))
- && (strcmp (lhs_var_name_str, var_name_str) == 0))
-   return;
+ if (lhs_var)
+   {
+ const char *lhs_var_name_str = get_var_name (lhs_var);
+ if (strcmp (lhs_var_name_str, var_name_str) == 0)
+   return;
+   }
  gcc_assert (var_name_str && var_def_stmt);
}
 }

[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 #12 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to qinzhao from comment #10)
> > the following patch fixed this issue:
> 
> This would leak memory.

thank you, I will fix the memory leak issue in the patch.

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> As for whether -fstrict-flex-arrays= should or shouldn't affect
> -fsanitize=bounds, making it gradually equivalent to
> -fsanitize=bounds-strict, that is a question, perhaps if
> -fstrict-flex-arrays= is considered as changing the exactly applicable
> language standard, with that option it might change what is and is not
> undefined behavior.
> Siddhesh/Qing, what do you think?
from the doc:
"
-fsanitize=bounds
This option enables instrumentation of array bounds. Various out of bounds
accesses are detected. Flexible array members, flexible array member-like
arrays, and initializers of variables with static storage are not instrumented.

-fsanitize=bounds-strict
This option enables strict instrumentation of array bounds. Most out of bounds
accesses are detected, including flexible array members and flexible array
member-like arrays. Initializers of variables with static storage are not
instrumented.
"

the situation is very similar to the previous:

-Warray-bounds
-Warray-bounds=2

Per our previous discussion on  -Warray-bounds and -Warray-bounds=2 and
-fstrict-flex-arrays=N, I think it's very reasonable to handle the
-fsanitize=bounds and -fsanitize=bounds-strict + -fstrict-flex-arrays=N
similarly, i.e:

1. let -fstrict-flex-arrays=N to control the behavior of -fsanitize=bounds;
2. -fsanitize=bounds-strict actually is an alias of -fsanitize=bounds
-fstrict-flex-arrays=2,  i.e, it treats [], [0] as flexible array members, but
treat [1], [4], as regular arrays.

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

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

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Well, -fsanitize=bounds-strict certainly shouldn't imply
> -fstrict-flex-arrays=2,
> it should just treat [1] and [4] (but I think it does even [0] right now) as
> regular arrays for the purposes of the sanitization.

with a small example I just tested, with -fsanitize=bounds-strict, I can see,
it treats:
   [], [0] as flexible array members;
but
   [1], [4] as regular arrays

This is the same level as -fstrict-flex-arrays=2. 
should we just keep its default behavior like this, or let it more strictly as
-fstrict-flex-arrays=3?

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

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

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

--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #10)

> I'd keep its current behavior, perhaps except for -fsanitize=bounds-strict
> -fstrict-flex-arrays{,=3} so that -fsanitize=bounds
> -fstrict-flex-arrays{,=3} wouldn't be more strict than the former.
Agreed.

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

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

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

--- Comment #13 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #12)
> Created attachment 54547 [details]
> gcc13-pr108894.patch
> 
> Untested fix.

several comments on the patch:

1. should the documentation of -fsanitize=bounds and -fsanitize=strict-bounds
be updated to reflect the interaction with -fstrict-flex-arrays=N?
2. there are several routines in c-decl.cc:
 static bool  flexible_array_member_type_p (const_tree type);
 static bool  one_element_array_type_p (const_tree type);
 static bool  zero_length_array_type_p (const_tree type);

can they be generalized  as well to be used in the routine 
"ubsan_instrument_bounds" to check for [], [0], or [1]? (in the patch lines
from 405 to 442). 
3. could you add comments for lines (I guess they are for [0])?

370   if (!bound)
371 bound = fold_build2 (PLUS_EXPR, TREE_TYPE (bound), bound,   371
{
372  build_int_cst (TREE_TYPE (bound), 1)); 372
  if (!c_dialect_cxx ()
373   && COMPLETE_TYPE_P (type)
374   && integer_zerop (TYPE_SIZE (type)))
375 bound = build_int_cst (TREE_TYPE (TYPE_MIN_VALUE (domain)),
-1);
376   else
377 return NULL_TREE;
378 }

[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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from qinzhao at gcc dot gnu.org ---
resolved in GCC13

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 107411 Summary: trivial-auto-var-init=zero invalid uninitialized variable 
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411

   What|Removed |Added

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

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Richard Biener from comment #2)
> > Iff only (GNU) C would accept the following ...
> > 
> > struct foo {
> > ...
> > unsigned int count;
> > ...
> > int data[count];
> > };
> 
> Well, that I think conflicts with the variable length structures GNU
> extension, where
> if the array size of a field isn't a constant expression, it is an
> expression evaluated at runtime once (SAVE_EXPR) to determine the field size.

VLA is only legal inside function scopes. 
but this new extension will be legal at file scope.

will this fact be used to distinguish these two?

> Here we are talking about something similar to what Fortran wants with its
> deferred length arrays, essentially to have the size evaluated each time it
> is accessed.
> With the data[count] form even if it would be disambiguated the question is
> if we want to otherwise treat it like normal flexible array member e.g. for
> sizeof etc. and only treat it specially for __bdos, or if it would affect
> say sizeof too.

the immediate purpose of this new extension is used for __bdos.
is there any benefit if it will affect sizeof()?

> I don't see how sizeof (struct foo) could be treated differently from
> flexible array member, because one doesn't have an object on which count can
> be evaluated, but perhaps
> struct foo f;
> f.count = 24;
> sizeof (f.data) could change.

what's the major purpose of enabling this?

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #7)
> An attribute is certainly simpler and should be easy to add.
yes.
> 
> I proposed similar extension for C23 and there was some interest,
> but I did not have time to follow up.
> 
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2660.pdf
very interesting proposal!
are there any discussions on this proposal? if so, can you point me to them?
> 
> 
> Sizeof is not a constant expression in ISO C for a VLA and it is not a
> constant expression if the struct contains a VLA  (GNU extension).  So this
> is already the case and nothing would need to change. It would also 
> potentially  
> avoid mistakes when computing the size of such a struct.
agreed.
However, my understanding is: VLA is only valid inside a function scope. GCC
use a special SAVE_EXPR to record its size expression. and evaluated during
runtime only once. 
when this variable length concept is extended to global scope, not sure how to
implement the size expression? need some study here.

>  But the
> rules for initialization are not so clear.
shall we make this clear?
> 
> I do not think it is a good idea to differentiate between file scope structs
> and others. This would be confusing.
Yes. agreed.

this proposal basically is to extend the VLA concept from function scope to
global scope. is my understanding correct?

> 
> Considering that the GNU extensions is rarely used, one could consider
> redefining the meaning of
> 
> int n = 1;
> struct {
>   int n;
>   char buf[n];
> };
> 
> so that the 'n' refers to the member. Or we add a new syntax similar to
> designators (which intuitively makes sense to me).
designator might be better IMO.

a question here is:

for the following nested structure: 

struct object {
...
char items;
...
struct inner {
...
int flex[];
};
} *ptr;

what kind of syntax is good to represent the upper bound of "flex" in the inner
struct with "items" in the outer structure? any suggestion?

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #9)
> 
> https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
thanks for the info. 
> 
> But we made variably modified types mandatory in C23 to
> help with bounds checking and this already works quite
> nicely with GCC / Clang:
> 
> https://godbolt.org/z/ddfsdWPMj
nice!
can you provide a pointer to the section in C23 that made this change?
> 
> > when this variable length concept is extended to global scope, not sure how 
> > to
> > implement the size expression? need some study here.
> 
> Here, we want to use a member of the struct as a size 
> expression. This could work equally at function and file scope.
> But the semantics need to be worked out.  I have started to work
> on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR,
> but did not get very far.
> 
> The idea is to evaluate the size expression whenever the member
> with the size is accesses. If the size is not set before, this
> would be undefined behavior.
> 
> Other languages such as Ada support this, so in principle this
> should be a piece of cake.
Oh, Ada can support this already?
how does Ada implement this?
then we can just borrow Ada's implementation idea to implement this in C if
this is approved as an GCC extension for C. 

> > this proposal basically is to extend the VLA concept from function scope to
> > global scope. is my understanding correct?
> 
> I would say the idea is to allow size expressions to refer
> to member of a struct instead of only automatic variables.
> 
Okay.

> > a question here is:
> > 
> > for the following nested structure: 
> > 
> > struct object {
> > ...
> > char items;
> > ...
> > struct inner {
> > ...
> > int flex[];
> > };
> > } *ptr;
> > 
> > what kind of syntax is good to represent the upper bound of "flex" in the 
> > inner
> > struct with "items" in the outer structure? any suggestion?
> 
> I would disallow it. At least at first. It also raises some
> questions: For example, one could form a pointer to the inner
> struct, and then it is not clear how 'items' could be accessed
> anymore.
> 
Okay.

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #9)
>
> Here, we want to use a member of the struct as a size 
> expression. This could work equally at function and file scope.
> But the semantics need to be worked out.  I have started to work
> on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR,
> but did not get very far.
what kind of semantics your patch will support?

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #23 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #13)
> 
> VLAs and VM types exist since C99 and were made optional in C11.
> The minimal change we adopted to make support for VM types 
> (but not VLAs) mandatory again was:
> 
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf

So, this will be official in C23? i.e, VM types will be mandatory, but VLA will
be optional (and later might be deprecated?)

> 
> I think using PLACEHOLDER_EXPR that are insert into the size
> expression and then replaced later by the struct being accessed, 
> e.g.
> 
> struct foo {
>  int len;
>  char buf[PLACEHOLDER_EXPR.len]
> };
> 
> and then later when we have
> 
> struct foo x;
> 
> x->buf
> 
> we would replace in the size of the type for x->buf the placeholder
> with x itself.

I see. Yes, this will resolve the implementation difficulty for filling the
size of the FAM field when the size is the previous declared field in the same
structure. 


> Yes, this was what I wanted to do...  My main use case is not flexible
> array members but VM types in struct:
> 
> struct foo {
>   int len;
>   char (*buf)[.len];
> };
> 
> 
> This has less issues because the size of the struct then does not depend
> on the length.

a little confused here:
what's the definition of VM type? it's size will not depend on the ".len" ?

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #24 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #15)
> 
> Yes, but that syntax would be intuitive which I would see
> as an advantage.

Yes, I agree.
> 
> But I am not saying we shouldn't have the attribute first.

both the new attribute and the C's syntax extension might be needed at the same
time, I think.

1. Attribute might be better for changing the existing source code to make them
bound-checking friendly;
2. new code can use the C's syntax change, and hopefully this new syntax
extension can be made into next C language standard.

however, I think that both the new attribute and the new C syntax extension
should support the similar user interface. We might need to decide on this
first.

right now, the user interface we cannot agreed on is:

whether we should support the following nested annotation (either with
attribute or with the C syntax extension):

struct object {
...
unsigned int items;
...
struct inner {
...
int flex[];
};
} *ptr;


My opinion is: No, we should not support this, it will make the implementation
much more complicated both for attribute and for C syntax extension. 

But I am not very sure on this yet. 

Is the PLACEHOLDER_EXPR able to resolve this?

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #17)
> The syntax with the dot would make it not conflict.  But I need
> this for this use case
> 
> struct foo {
>   int count;
>   int (*buf)[.count];
> };
> 
> so that ARRAY_SIZE(*foo->buf) works correctly and also accesses
> to foo->buf are bounds checkked.  So it would make sense to 
> solve to treat flexible array members in the same way.
Yes, I agree. 

then the size of the array type (even though it's not a constant) will be
embedded in the TYPE consistently. therefore simplify compiler's implementation
and make it consistently. 

> 
> But I agree that we should simply add the attribute now also
> because it makes it possible to use it for existing code bases.
Yes.

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #26 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #20)
> 
> I agree. An attribute is simple and extending C will take
> more care (and work).
> 
> The reason I think we should also extend C (together with
> WG14) is because this would allow writing code where the
> bound is never lost because it is encoded in the type,
> while the  __builtin_dynamic_object_size is extremely
> useful to enhance existing code bases, but is best
> effort only.
> 
> So I think we should do both.
> 
Agreed.

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #27 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #22)

> This really should have been the way __access__ was implemented, but we tied
> that attribute to only functions.  Would it be a terrible idea to make
> __element_count__ more general purpose so that it ends up deprecating
> __access__?
I feel that __access__ and __element_count_ have some overlapping, but serve
different purposes, might not be good to merge them?

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #30 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #28)

> The problems with VLA are in my opinion caused by poor
> implementation (e.g. no stack probing etc) and bad
> code generation (Linus was not happy about this) and
> not because anything is fundamentally bad about them
> from the point of language semantics.

you mean gcc's implementation? how about other compilers?

> VM = variably modified.  In C it is a type which is derived from
> a VLA which is not necessarily itself a VLA, e.g. a pointer to
> a VLA. But a VLA is also a VM type.

Okay.
> 
> > struct foo {
> >   int len;
> >   char (*buf)[.len];
> > };
> > 
> > 
> > This has less issues because the size of the struct then does not depend
> > on the length.

but I am still not clear on why "the size of the above struct 'foo' does not
depend on the .len?"  in my opinion, it should depend on .len. do I miss
anything here?

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #31 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #29)
> > however, I think that both the new attribute and the new C syntax extension
> > should support the similar user interface. We might need to decide on this
> > first.
> 
> I think there are some fundamental differences: In one
> case the size is encoded into the type and in the other
> it is just an annotation that can be ignored.

Yes, understood.

I might not make myself clear in the previous message. what I mean by the "the
similar user interfaces" is:

both might support the following:

1. a declared variable as the size:

**C syntax extension:
unsigned int length;
struct object {
   int others;
   char flex[length];  
}

**corresponding attribute:
unsigned int length;
struct object {
   int others;
   char flex[] __attribute__((__element_count__(length)));  
}

2. a declared field of the same structure as the size:
**C syntax extension:
struct object {
   unsigned int length;
   char flex[.length];  
}

**corresponding attribute:
struct object {
   unsigned int length;
   char flex[] __attribute__((__element_count__(.length)));  
}

3. expressions including declared variables and declared fields of the same
structure as the size:

**C syntax extension:
unsigned int item;
struct object {
   unsigned int ratio;
   char flex[item * .ratio];  
}

**corresponding attribute:
unsigned int item;
struct object {
   unsigned int ratio;
   char flex[] __attribute__((__element_count__(item * .ratio)));  
}

Not sure on the following case:

4. a declared field of the containing structure as the size:

**C syntax extension:
struct object {
   unsigned int length;
   struct inner {
     ...
     int flex[..length];
   };
}

**corresponding attribute:
struct object {
   unsigned int length;
   struct inner {
 ...
 char flex[] __attribute__((__element_count__(..length)));
   }  
}

what else from the user's point of view?
> 
> > 
> > right now, the user interface we cannot agreed on is:
> > 
> > whether we should support the following nested annotation (either with
> > attribute or with the C syntax extension):
> > 
> > struct object {
> > ...
> > unsigned int items;
> > ...
> > struct inner {
> > ...
> > int flex[];
> > };
> > } *ptr;
> > 
> I am fine with supporting it, but one needs to decide
> on the semantics in the case where inner is not accessed
> via the outer struct.
Yes, that's right.

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #33 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #32)

> > > > struct foo {
> > > >   int len;
> > > >   char (*buf)[.len];
> > > > };
> Here the last element is not a flexible array member but
> a pointer to an array of size len. The size of the pointer is
> fixed.

Oh, that's right.

then, just curious on how did you embed the '.len' information into IR?

[Bug tree-optimization/109071] -Warray-bounds warning when array index checked via inline

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> Jump threading is happening which is causing some code to be duplicated. I
> am 100% sure there is a dup of this bug already filed too.

Yes, the false positive warning is due to the code duplication by jump
threading. 

***without jump threading (adding fno-thread-jumps), the IR in vrp1 is:

   [local count: 1073741824]:
  if (index_3(D) > 3)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  warn ();

   [local count: 1073741824]:
  *ptr_5(D) = 0;
  _1 = MEM  [(int *)sg_2(D)].vals[index_3(D)];
  if (index_3(D) > 3)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  warn ();

***with jump threading, the "Bad" IR in vrp1 is:

   [local count: 1073741824]:
  if (index_3(D) > 3)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719407024]:
  *ptr_5(D) = 0;
  _14 = MEM  [(int *)sg_2(D)].vals[index_3(D)];
  goto ; [100.00%]

   [local count: 354334800]:
  warn ();
  *ptr_5(D) = 0;
  _17 = MEM  [(int *)sg_2(D)].vals[index_3(D)];
  warn ();

in the above "Bad" IR with jump threading, we can see the problematic part is:

   [local count: 354334800]:
  warn ();
  *ptr_5(D) = 0;
  _17 = MEM  [(int *)sg_2(D)].vals[index_3(D)];
  warn ();

in which the "_17 = MEM  [(int *)sg_2(D)].vals[index_3(D)];" is
the one that was duplicated by jump threading and also is the one that caused
array bound checker to report the false positive warning based on the value
range propagation result in block 4: the value range for "index_3" is > 3,
which is out-of-range of the array "Vals", therefore the warning. 

my though is:

1. the jump threading and code duplication are all correct optimization;
2. but the duplication of the array reference caused the false positive
warning;

So, the following is my proposed solution to this problem:

1. when jump threading applies the code duplication, mark those array
references that are duplicated as ARTIFICIAL (or something else..);
2. during array bound checker, check whether the array references are
ARTIFICIAL, if it's true, do not emit the warning.

is the proposed solution feasible?

[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

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

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

--- Comment #17 from qinzhao at gcc dot gnu.org ---
So, based on the discussion so far, I'd like to take the following steps:

1. In GCC12, I will take a conservative solution to fix this bug, i.e:

mark the load "MEM" as not needing a warning during __builtin_clear_padding
folding phase;

this should resolve this issue and has lowest risk to introduce more issues.

2. In GCC13, seeking a better way to do padding initialization. right now,
based on the discussion so far, there is no conclusion on which way is better
yet.

let me know if you have other comments or suggestions.

[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

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

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

--- Comment #18 from qinzhao at gcc dot gnu.org ---
One question here, for the following testing case:

[opc@qinzhao-ol7u9 104550]$ cat t1.c
struct vx_audio_level {
 int has_monitor_level : 1;
};

void vx_set_monitor_level() {
 struct vx_audio_level info;
 __builtin_clear_padding (&info);
}
[opc@qinzhao-ol7u9 104550]$ sh t
/home/opc/Install/latest/bin/gcc -O -Wuninitialized -Wall t1.c -S
t1.c: In function ‘vx_set_monitor_level’:
t1.c:7:2: warning: ‘info’ is used uninitialized [-Wuninitialized]
7 |  __builtin_clear_padding (&info);
  |  ^~~
t1.c:6:24: note: ‘info’ declared here
6 |  struct vx_audio_level info;
  |^~~~

We can see that the compiler emitted the exactly same warning as with
-ftrivial-auto-var-init=pattern. 

my question is, is the "info" in __builtin_clear_padding(&info) a REAL use of
"info"? is it correct to report the uninitialized use message for it?

[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #22 from qinzhao at gcc dot gnu.org ---
Fixed in gcc12

[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from qinzhao at gcc dot gnu.org ---
Fixed in gcc12

[Bug middle-end/100775] ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used

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

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
fixed in gcc11 too.

[Bug tree-optimization/106457] New: array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

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

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

Bug ID: 106457
   Summary: array_at_struct_end_p returns TRUE for a two-dimension
array which is not inside any structure
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

During my work on updating array_at_struct_end_p with the new
-fstrict-flex-array control, I noticed the following issue in the routine
"array_at_struct_end_p" for the following small testing case:
gcc/testsuite/g++.dg/debug/debug5.C

// { dg-do compile }
// { dg-require-effective-target alloca }

int foo()
{
  int a = 1;
  int b = 1;
  int e[a][b];
  e[0][0] = 0;
  return e[a-1][b-1];
}


when compiled with -O1 with the latest trunk gcc, when I used the gdb to debug
it as:

(gdb) break array_at_struct_end_p
Breakpoint 1 at 0x1d4cdf8: file ../../latest_gcc/gcc/tree.cc, line 12690.
(gdb) run
Starting program: /home/opc/Work/GCC/build/gcc/cc1plus -quiet -iprefix
/home/opc/Work/GCC/build/gcc/../lib/gcc/aarch64-unknown-linux-gnu/13.0.0/
-isystem /home/opc/Work/GCC/build/gcc/testsuite/g++/../../include -isystem
/home/opc/Work/GCC/build/gcc/testsuite/g++/../../include-fixed -D_GNU_SOURCE
t.C -quiet -dumpbase debug5.C -dumpbase-ext .C -mlittle-endian -mabi=lp64 -O1
-o debug5.s
...

Breakpoint 1, array_at_struct_end_p (ref=0xf57a2b88) at
../../latest_gcc/gcc/tree.cc:12690
12690 if (TREE_CODE (ref) == ARRAY_REF
...
(gdb) break 12784
Breakpoint 2 at 0x1d4d50c: file ../../latest_gcc/gcc/tree.cc, line 12784.
(gdb) c
Continuing.

Breakpoint 2, array_at_struct_end_p (ref=0xf5771a70) at
../../latest_gcc/gcc/tree.cc:12784
12784 if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (atype))) != INTEGER_CST
(gdb) n
12786 || TREE_CODE (TYPE_MIN_VALUE (TYPE_DOMAIN (atype))) !=
INTEGER_CST)
(gdb) n
12784 if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (atype))) != INTEGER_CST
(gdb) n
12787   return true;
(gdb) n
12803   }

it's obvious that the array reference " e[0][0]" is NOT an array at the end of
a structure. 

the utility routine "array_at_struct_end_p" should NOT result true for such
array reference.

We should fix this issue in this routine.

[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> Should be fixed.

Just checked this in gdb, still not fixed.

Breakpoint 1, array_at_struct_end_p (ref=0xf57a2bc0) at
../../latest_gcc/gcc/tree.cc:12690
12690 if (TREE_CODE (ref) == ARRAY_REF
(gdb) call debug_tree(ref)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0xf57f05e8 precision:32 min  max

pointer_to_this >
sizes-gimplified type_6 BLK
size 
used unsigned ignored TI t.C:8:7
size 
unit-size 
align:128 warn_if_not_align:0 context >
unit-size 
used unsigned ignored DI t.C:8:7
size 
unit-size 
align:64 warn_if_not_align:0 context >
align:32 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
domain 
sizes-gimplified type_6 DI size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality precision:64 min  max
>>

arg:0 
sizes-gimplified type_6 BLK size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality domain 
pointer_to_this >
nothrow
arg:0 
arg:0 >
arg:1 
t.C:9:9 start: t.C:9:3 finish: t.C:9:9>
arg:1 
constant 0>
arg:3  constant 1>
t.C:9:6 start: t.C:9:3 finish: t.C:9:6>
(gdb) break 12782
Breakpoint 2 at 0x1d519d8: file ../../latest_gcc/gcc/tree.cc, line 12782.
(gdb) c
Continuing.

Breakpoint 2, array_at_struct_end_p (ref=0xf5771a70) at
../../latest_gcc/gcc/tree.cc:12782
12782 if (DECL_P (ref_to_array))
(gdb) call debug_tree(ref)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf59f7f50 precision:8 min  max >
SI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf59f80a0
domain 
DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf59f7ff8 precision:64 min  max >
pointer_to_this >
addressable used ignored SI t.C:8:7 size 
unit-size 
align:32 warn_if_not_align:0 context >
(gdb) call debug_tree(ref_to_array)
 
sizes-gimplified type_6 BLK size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality domain >
sizes-gimplified type_6 BLK
size 
used unsigned ignored TI t.C:8:7
size 
unit-size 
align:128 warn_if_not_align:0 context >
unit-size 
used unsigned ignored DI t.C:8:7
size 
unit-size 
align:64 warn_if_not_align:0 context >
align:32 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
domain 
sizes-gimplified type_6 DI size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality precision:64 min  max
>
pointer_to_this >
nothrow
arg:0 
unsigned DI size  unit-size

align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf59f8d18>

arg:0 
addressable used ignored SI t.C:8:7
size 
unit-size 
align:32 warn_if_not_align:0 context >>
arg:1 
constant 0>
t.C:9:9 start: t.C:9:3 finish: t.C:9:9>
(gdb) n
12787 poly_int64 offset;
(gdb) n
12788 if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (atype))) != INTEGER_CST
(gdb) n
12790 || TREE_CODE (TYPE_MIN_VALUE (TYPE_DOMAIN (atype))) !=
INTEGER_CST)
(gdb) n
12788 if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (atype))) != INTEGER_CST
(gdb) n
12791   return true;
(gdb) n

So, it still return TRUE for this array access.

[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

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

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

--- Comment #5 from qinzhao at gcc dot gnu.org ---
I am wondering whether the following:

12781   /* If the object itself is the array it is not at struct end.  */
12782   if (DECL_P (ref_to_array))
12783 return false;

should be:

12781   /* If the object itself is the array it is not at struct end.  */
12782   if (DECL_P (ref))
12783 return false;

??

[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

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

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
the following patch fixed the issue:

[opc@qinzhao-aarch64-ol8 gcc]$ git diff tree.cc
diff --git a/gcc/tree.cc b/gcc/tree.cc
index fed1434d141d..d04ac121765a 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -12779,7 +12779,7 @@ array_at_struct_end_p (tree ref)
   && TREE_CODE (DECL_SIZE_UNIT (ref)) == INTEGER_CST)
 {
   /* If the object itself is the array it is not at struct end.  */
-  if (DECL_P (ref_to_array))
+  if (TREE_CODE (TREE_TYPE (ref)) == ARRAY_TYPE)
return false;

   /* Check whether the array domain covers all of the available

[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
another testing case failed with the current "array_at_struct_end_p":
gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c
  1 /* { dg-do compile } */
  2 /* { dg-additional-options "-O3 -std=c99" } */
  3 /* { dg-final { check-function-bodies "**" "" "" } } */
  4 
  5 #include 
  6 
  7 #pragma GCC target "+nosve"
  8 
  9 /*
 10 **test:
 11 **  ...
 12 **  addvs0, v0.4s
 13 **  fmovw0, s0
 14 **  and w1, w0, 65535
 15 **  add w0, w1, w0, lsr 16
 16 **  lsr w0, w0, 1
 17 **  ret
 18 */
 19 int test (uint8_t *p, uint32_t t[1][1], int n) {
 20 
 21   int sum = 0;
 22   uint32_t a0;
 23   for (int i = 0; i < 4; i++, p++)
 24 t[i][0] = p[0];
 25 
 26   for (int i = 0; i < 4; i++) {
 27 {
 28   int t0 = t[0][i] + t[0][i];
 29   a0 = t0;
 30 };
 31 sum += a0;
 32   }
 33   return (((uint16_t)sum) + ((uint32_t)sum >> 16)) >> 1;
 34 }

in the above, at line 24, the array_ref t[i][0] was identified as "true" by the
current array_at_struct_end_p:
Breakpoint 1, array_at_struct_end_p (ref=0xf57a2990) at
../../latest_gcc/gcc/tree.cc:12690
12690 if (TREE_CODE (ref) == ARRAY_REF
(gdb) call debug_tree(ref)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf57d0690 precision:32 min  max  context >

arg:0 
SI size  unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf5a70e70 domain 
pointer_to_this >

arg:0 
visited
def_stmt _4 = t_27(D) + _3;
version:4
ptr-info 0xf56c84c0>
arg:1 
t.c:24:6 start: t.c:24:5 finish: t.c:24:8>
arg:1 
constant 0>
t.c:24:9 start: t.c:24:5 finish: t.c:24:11>
...(gdb) n
12774 if (ref
(gdb) n
12806 return true;
(gdb) 

Looks like that the current array_at_struct_end_p cannot handle multi-dimension
array reference correctly.

[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

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

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
another testing case failed with the current array_at_struct_end_p is:
gcc/testsuite/gcc.dg/torture/pr50067-1.c:
  1 /* { dg-do run } */
  2 
  3 /* Make sure data-dependence analysis does not compute a bogus
  4distance vector for the different sized accesses.  */
  5 
  6 extern int memcmp(const void *, const void *, __SIZE_TYPE__);
  7 extern void abort (void);
  8 short a[32] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
  9 short b[32] = { 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, };
 10 int main()
 11 {
 12 #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
 13   int i;
 14   if (sizeof (short) == 2)
 15 {
 16   for (i = 0; i < 32; ++i)
 17 (*((unsigned short(*)[32])&a[0]))[i] =
(*((char(*)[32])&a[0]))[i+8];
 18   if (memcmp (&a, &b, sizeof (a)) != 0)
 19 abort ();
 20 }
 21 #endif
 22   return 0;
 23 }

In the above, the array ref at line 17: (*((char(*)[32])&a[0]))[i+8] was
identified as TRUE by the current array_at_struct_end_p:
12690 if (TREE_CODE (ref) == ARRAY_REF
(gdb) call debug_tree(ref)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf57d03f0 precision:8 min  max 
pointer_to_this >

arg:0 
BLK
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set 0 canonical-type
0xf5994d70 domain 
pointer_to_this >

arg:0 
constant arg:0 >
arg:1 
   
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-1.c:17:42
start:
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-1.c:17:41
finish:
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-1.c:17:63>
arg:1 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf57d05e8 precision:32 min  max

pointer_to_this >
visited
def_stmt _1 = i_13 + 8;
version:1
ptr-info 0xf59fee20>
   
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-1.c:17:64
start:
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-1.c:17:41
finish:
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-1.c:17:68>
(gdb) n
12801   return true;
(gdb)

[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

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

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
one more testing case failed with the current array_at_struct_end_p
is:gcc/testsuite/gcc.dg/torture/pr50067-2.c:
  1 /* { dg-do run } */
  2 
  3 /* Make sure data-dependence analysis does not compute a bogus
  4   distance vector for the different sized accesses.  */
  5 
  6 extern int memcmp(const void *, const void *, __SIZE_TYPE__);
  7 extern void abort (void);
  8 short a[32] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
  9 short b[32] = { 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, };
 10 int main()
 11 {
 12 #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
 13   int i;
 14   if (sizeof (short) == 2)
 15 {
 16   for (i = 0; i < 32; ++i)
 17 {
 18   a[i] = (*((char(*)[32])&a[0]))[i+8];
 19 }
 20   if (memcmp (&a, &b, sizeof (a)) != 0)
 21 abort ();
 22 }
 23 #endif
 24   return 0;
 25 }

In the above, at line 18: (*((char(*)[32])&a[0]))[i+8] was identified as TRUE:
Breakpoint 1, array_at_struct_end_p (ref=0xf57a2b18) at
../../latest_gcc/gcc/tree.cc:12690
12690 if (TREE_CODE (ref) == ARRAY_REF
(gdb) call debug_tree(ref)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf57d03f0 precision:8 min  max 
pointer_to_this >

arg:0 
BLK
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set 0 canonical-type
0xf59950b8 domain 
pointer_to_this >

arg:0 
constant arg:0 >
arg:1 
   
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-2.c:18:12
start:
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-2.c:18:11
finish:
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-2.c:18:33>
arg:1 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf57d05e8 precision:32 min  max

pointer_to_this >
visited
def_stmt _1 = i_5 + 8;
version:1>
   
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-2.c:18:34
start:
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-2.c:18:11
finish:
/home/opc/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/torture/pr50067-2.c:18:38>
...
(gdb) n
12801   return true;

[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #10 from qinzhao at gcc dot gnu.org ---
after discussing with Richard, and agreed on the several bugs mentioned in
comment #7,#8 and #9 are actually not bugs. 
we just need to add more comments for array_at_struct_end_p and change the name
of it later. 
close this bug as fixed.

[Bug c/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> This is intentional, if you embed an aggregate with flex array into another
> struct and ask not to cross the field boundaries (i.e. bos1), then the size
> of that field is exactly what is the maximum size.

don't quite understand here:

why "embedding an aggregate with flex array member into another struct" is
asking not to cross the field boundaries? could you please explain a little bit
on this?

[Bug tree-optimization/103720] bogus warning from -Wuninitialized + -ftrivial-auto-var-init + O2

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
this is fixed with the following commit in gcc12.
https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359118.html

[Bug tree-optimization/103720] bogus warning from -Wuninitialized + -ftrivial-auto-var-init + O2

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from qinzhao at gcc dot gnu.org ---
fixed in GCC12

[Bug target/100775] ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-24

--- Comment #1 from qinzhao at gcc dot gnu.org ---
I can repeat this bug with the latest upstream gcc:

[opc@qinzhao-ol8u3-x86 100775]$ sh t
/home/opc/Install/cross/bin/armv7a-hardfloat-linux-gnueabi-gcc -mthumb
-fzero-call-used-regs=used t.c -S
exit_block_uses =  0 [r0] 3 [r3] 7 [r7] 13 [sp] 14 [lr] 102 [sfp]
df->exit_block_uses =  0 [r0] 7 [r7] 13 [sp] 14 [lr] 102 [sfp]
during RTL pass: mach
t.c: In function 'foo':
t.c:5:1: internal compiler error: in df_exit_block_bitmap_verify, at
df-scan.cc:4178
5 | }
  | ^
0xc6a0bf df_exit_block_bitmap_verify
../../latest-gcc/gcc/df-scan.cc:4178
0xc6a355 df_scan_verify()
../../latest-gcc/gcc/df-scan.cc:4231
0xc501a8 df_verify()
../../latest-gcc/gcc/df-core.cc:1818
0xc4eaa4 df_analyze_1
../../latest-gcc/gcc/df-core.cc:1214
0xc4ee68 df_analyze()
../../latest-gcc/gcc/df-core.cc:1290
0x194675a thumb2_reorg
../../latest-gcc/gcc/config/arm/arm.cc:18999
0x1947d60 arm_reorg
../../latest-gcc/gcc/config/arm/arm.cc:19218
0x1300436 execute
../../latest-gcc/gcc/reorg.cc:3927
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/100775] ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
This is a bug in pass_zero_call_used_regs, when updating df after the zeroing
sequence is added in the epilogue of the function, we should call
"df_update_exit_block_uses" to update the reg use info in the exit block to
include all the regs that have been zeroed.

I think that this is a very general issue, should be fixed into both gcc12 and
gcc11.

[Bug target/100775] ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
the following simple patch resolved the issue:

diff --git a/gcc/function.cc b/gcc/function.cc
index e1d2565f8d9..c8a77c9a624 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -5942,6 +5942,7 @@ gen_call_used_regs_seq (rtx_insn *ret, unsigned int
zero_regs_type)
   /* Update the data flow information.  */
   crtl->must_be_zero_on_return |= zeroed_hardregs;
   df_set_bb_dirty (EXIT_BLOCK_PTR_FOR_FN (cfun));
+  df_update_exit_block_uses ();
 }
 }

will test it.

[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-01-28
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug tree-optimization/101515] [11/12 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #4 from qinzhao at gcc dot gnu.org ---
the latest gcc12 failed with the same issue.

[Bug tree-optimization/101515] [11/12 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1

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

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

--- Comment #5 from qinzhao at gcc dot gnu.org ---
the root cause for this bug is:

1. there is no NAME for the pointer to member function type as the following:
(in cp/decl.cc)

tree
build_ptrmemfunc_type (tree type)
{

10655   finish_builtin_struct (t, "__ptrmemfunc_type", fields, ptr_type_node);
10656 
10657   /* Zap out the name so that the back end will give us the debugging
10658  information for this anonymous RECORD_TYPE.  */
10659   TYPE_NAME (t) = NULL_TREE;
...
}

2. therefore, when printing this ptrmemfun type (which is a RECORD_TYPE), we
should consider that it might not have a TYPE_NAME, however, in the current
handling "pp_cxx_unqualified_id", the TYPE_NAME is assumed to be non-NULL, this
is not correct. 

 126 static void
 127 pp_cxx_unqualified_id (cxx_pretty_printer *pp, tree t)
 128 {
 129   enum tree_code code = TREE_CODE (t);
 130   switch (code)
... 
 169 case RECORD_TYPE:
 170 case UNION_TYPE:
 171 case ENUMERAL_TYPE:
 172 case TYPENAME_TYPE:
 173 case UNBOUND_CLASS_TEMPLATE:
 174   pp_cxx_unqualified_id (pp, TYPE_NAME (t)); ===> the ICE happens here
due to TYPE_NAME is NULL.

[Bug tree-optimization/101515] [11/12 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1

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

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
the following patch fixed this bug:
[opc@qinzhao-aarch64-ol8 latest_gcc]$ git diff
diff --git a/gcc/cp/cxx-pretty-print.cc b/gcc/cp/cxx-pretty-print.cc
index 4f9a090e520d..744ed0add5ba 100644
--- a/gcc/cp/cxx-pretty-print.cc
+++ b/gcc/cp/cxx-pretty-print.cc
@@ -171,7 +171,10 @@ pp_cxx_unqualified_id (cxx_pretty_printer *pp, tree t)
 case ENUMERAL_TYPE:
 case TYPENAME_TYPE:
 case UNBOUND_CLASS_TEMPLATE:
-  pp_cxx_unqualified_id (pp, TYPE_NAME (t));
+  if (TYPE_NAME (t))
+   pp_cxx_unqualified_id (pp, TYPE_NAME (t));
+  else
+   pp_string (pp, "");
   if (tree ti = TYPE_TEMPLATE_INFO_MAYBE_ALIAS (t))
if (PRIMARY_TEMPLATE_P (TI_TEMPLATE (ti)))
  {

[Bug middle-end/100775] ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used

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

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

--- Comment #5 from qinzhao at gcc dot gnu.org ---
fixed in gcc12.

[Bug tree-optimization/101515] [11/12 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
for the following IR:

  struct sp x;
  void (*) (void) _1;
 ...
   [local count: 1073741824]:
  _1 = MEM[(struct ptrmemfunc_U *)&x].ptr;
  _7 = _1 != 8B;


***Before commit r11-6729-gadb520606ce3e1e1.

it reported:

t.cc:19:11: warning: ‘x.ptrmemfunc_U::ptr’ is used uninitialized
[-Wuninitialized]

***After commit r11-6729-gadb520606ce3e1e1.

1. without the patch in comment #6:

ICE. 

2. with the patch in comment #6:

it reported:

t.cc:19:11: warning: ‘*(ptrmemfunc_U*)((char*)&x + offsetof(void
(S::*)(),::__pfn)).ptrmemfunc_U::ptr’ is used uninitialized
[-Wuninitialized]

***The major difference between the message before r11-6729-gadb520606ce3e1e1
and after it is:

in the message after this commit, (if resolved the ICE), the type conversion
from "S::ptrmemfunc" to ptrmemfunc_U is emitted in the message, before this
commit, this type conversion is not emitted at all. 

So, the question is: shall we expose the type conversion from "S::ptrmemfunc"
to "ptrmemfunc_U" to the user?

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #24)
> I bet with the default -flifetime-dse=2 we would then have a
>   var = {};
>   var ={v} {CLOBBER}; // Start of ctor clobber
>   var.whatever = ...; // Ctor content
> and the zero initialization would be optimized away then.
> I guess ideal would be to emit such zero initialization in the complete
> object ctors right after the -flifetime-dse=2 beginning clobber and ideally
> one that clearly says to the gimplifier and rest of middle-end that it must
> initialize even padding bits.
> Because right now gimplification of var = {} will often happily lower that to
>   var.a = 0; var.b = 0; var.c = 0;
> even when there are padding bits,

oh right, I recall that this was the reason why adding "var = {}" to initialize
the whole structure didn't work well for initialize all paddings. therefore we
have to explicitly call __builtin_clear_padding for clear all paddings.

[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

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

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> If we just want to avoid the warning in cases like that (there is nothing
> wrong in the testcases themselves, the warning just warns about an
> implementation detail that a normally uninitialized variable will be really
> uninitialized even despite the -ftrivial-auto-var-init= option), then
> maybe_warn_switch_unreachable
> already has:
>   if (gimple_code (stmt) == GIMPLE_GOTO
>   && TREE_CODE (gimple_goto_dest (stmt)) == LABEL_DECL
>   && DECL_ARTIFICIAL (gimple_goto_dest (stmt)))
> /* Don't warn for compiler-generated gotos.  These occur
>in Duff's devices, for example.  */;
> and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also
> avoid warnings on:
> 1) call to .DEFERRED_INIT
> 2) call to __builtin_clear_padding if the second argument is present and
> non-zero
> 3) I guess we would need not to warn on a gimple assign store right after
> the .DEFERRED_INIT call that has the lhs of .DEFERRED_INIT as rhs
> anything else?
Yes, I think the above 3 should include all the cases.

[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

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

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
having a patch in my local tree, under testing.

[Bug middle-end/104550] New: bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

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

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

Bug ID: 104550
   Summary: bogus warning from -Wuninitialized +
-ftrivial-auto-var-init=pattern
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

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

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
Kees reported the following issue with -ftrivial-auto-var-init=pattern. the
testing case was reduced from Kernel building. 

$ cat warns.i
struct vx_audio_level {
 int has_monitor_level : 1;
};

void vx_set_monitor_level() {
 struct vx_audio_level info;
}
$ gcc -Wall -Wno-unused-variable -ftrivial-auto-var-init=zero -c -o /dev/null
warns.i
$ gcc -Wall -Wno-unused-variable -ftrivial-auto-var-init=pattern -c -o
/dev/null warns.i
warns.i: In function 'vx_set_monitor_level':
warns.i:6:25: warning: 'info' is used uninitialized [-Wuninitialized]
   6 |   struct vx_audio_level info;
 | ^~~~
warns.i:6:25: note: 'info' declared here
   6 |   struct vx_audio_level info;
 | ^~~~

[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-02-15
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from qinzhao at gcc dot gnu.org ---
confirmed with the latest gcc12.

[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

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

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

--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #10)

> I think it definitely makes sense to diagnose that we are not
> following -ftrivial-auto-init-var=X for a decl.  Maybe we should
> do that with -Wtrivial-auto-init-var only though?

currently we don't have -Wtrivial-auto-init-var, do you want to add a new
option -Wtrivial-auto-init-var? what's the purpose of it?

[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

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

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

--- Comment #12 from qinzhao at gcc dot gnu.org ---
I will go with the following solution:

1. avoid emitting switch-unreachable warnings for -ftrivial-auto-var-init;
2. adding a new option -Wtrivial-auto-var-init to emit warnings for the
switch-unreadable cases to suggest the user modify the source code;
3. update documentation of -ftrivial-auto-var-init for the limitation on
switch-unreachable cases and introduce the new option -Wtrivial-auto-var-init

with the above 1, we can resolve the current immediate issue of spurious
warnings of using -ftrivial-auto-var-init to make kernel build succeed;
with the above 2, we provide the user a way to know that
-ftrivial-auto-var-init has limitation on the switch-unreachable cases, and
user should modify the source code to avoid this problem;
with the above 3, we will provide the user a clear documentation of the
-ftrivial-auto-var-init and also provide suggestions how to resolve this issue. 

I will update my current patch with this.

let me know if you have other comments and suggestions.