[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c

2020-01-24 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|10.0|11.0

--- Comment #4 from Jeffrey A. Law  ---
Yes, the loop PHI is where things start, but the PHI in the latch block is just
as problematical it not more.  It's the use in the latch PHI that uninit.c
considers unguarded.

We could duplicate the latch block (thus creating two backedges to the top of
the loop).   Of course this mucks up the loop structures to some degree, so
it's not a great solution.

We could unroll the loop which ought to untangle things enough, but that's a
codesize regression and just twiddling the loop bounds would be enough to bring
the warning back, so I consider this a non-starter.

Peeling the first iteration has the same effect as unrolling on this specific
test and I think would resolve it.  Peeling the first iteration would also work
if the loop bounds were different.  

Jump threading often has the same effect as peeling off an iteration.  DOM3
discovers the opportunity, but doesn't actually thread the jump presumably
because doing so will muck up the loop structure.

I looked at Bin's recent work hoping it might be enough to help uninit.c
realize the use is guarded, but it isn't.  It may be extendable to handle this
case though.  Unsure.

Given we don't really have a viable path forward yet, I'm going to punt this to
11.

[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c

2019-08-27 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470

--- Comment #3 from rguenther at suse dot de  ---
On Tue, 27 Aug 2019, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>Keywords|needs-reduction |
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2019-08-27
>  CC||marxin at gcc dot gnu.org
>  Ever confirmed|0   |1
> 
> --- Comment #2 from Martin Liška  ---
> There's a reduced test-case:
> 
> $ cat pr91470.ii
> int input_location, global_trees_0, gfc_conv_intrinsic_findloc_body,
> gfc_conv_intrinsic_findloc_loopblock, gfc_conv_intrinsic_findloc_tmp,
> gfc_conv_intrinsic_findloc_found, gfc_conv_intrinsic_findloc_loop;
> enum tree_code { COND_EXPR };
> struct A {};
> struct B {
>   int pre;
>   int expr;
> };
> void fn1(B *, B *);
> void fn2(int *, int *);
> int *fn3(int *);
> void fn4(int, tree_code, int *, int *, int *, int);
> void fn5(B *, int *);
> void fn6() {
>   A array_arg, value_arg, dim_arg, mask_arg, kind_arg, back_arg;
>   int *forward_branch;
>   B arrayse, valuese, maskse, backse;
>   int i;
>   value_arg = array_arg;
>   mask_arg = dim_arg;
>   back_arg = kind_arg;
>   for (i = 0; i < 2; i++) {
> fn5(, _conv_intrinsic_findloc_loop);
> fn1(, __null);
> fn2(_conv_intrinsic_findloc_body, );
> fn4(input_location, COND_EXPR, _trees_0,
> _conv_intrinsic_findloc_tmp, _conv_intrinsic_findloc_found, 
> 0);
> if (i == 0)
>   forward_branch = fn3(_conv_intrinsic_findloc_loopblock);
>   }
>   fn4(input_location, COND_EXPR, _trees_0, , 
> forward_branch,
>   0);
> }

So this is basically

  int x;
  for (int i = 0; i < 2; ++i)
   if (i == 0) x = bar();
  baz(x);

with making sure we do _not_ thread / header copy / unroll this.
The uninit pass warns about the default def flowing into the loop PHI
node here.

[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c

2019-08-27 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-27
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
There's a reduced test-case:

$ cat pr91470.ii
int input_location, global_trees_0, gfc_conv_intrinsic_findloc_body,
gfc_conv_intrinsic_findloc_loopblock, gfc_conv_intrinsic_findloc_tmp,
gfc_conv_intrinsic_findloc_found, gfc_conv_intrinsic_findloc_loop;
enum tree_code { COND_EXPR };
struct A {};
struct B {
  int pre;
  int expr;
};
void fn1(B *, B *);
void fn2(int *, int *);
int *fn3(int *);
void fn4(int, tree_code, int *, int *, int *, int);
void fn5(B *, int *);
void fn6() {
  A array_arg, value_arg, dim_arg, mask_arg, kind_arg, back_arg;
  int *forward_branch;
  B arrayse, valuese, maskse, backse;
  int i;
  value_arg = array_arg;
  mask_arg = dim_arg;
  back_arg = kind_arg;
  for (i = 0; i < 2; i++) {
fn5(, _conv_intrinsic_findloc_loop);
fn1(, __null);
fn2(_conv_intrinsic_findloc_body, );
fn4(input_location, COND_EXPR, _trees_0,
_conv_intrinsic_findloc_tmp, _conv_intrinsic_findloc_found, 0);
if (i == 0)
  forward_branch = fn3(_conv_intrinsic_findloc_loopblock);
  }
  fn4(input_location, COND_EXPR, _trees_0, , forward_branch,
  0);
}

[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c

2019-08-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, needs-reduction
 CC||law at gcc dot gnu.org
 Blocks||24639
   Target Milestone|--- |10.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c

2019-08-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470

--- Comment #1 from Richard Biener  ---
Created attachment 46720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46720=edit
unreduced testcase

A bit reduced testcase from trans-intrinsic.c (in case it goes latent there due
to changes).  Needs more reduction to capture the meat of things.  The code
basically does

int a, b;
for (int i = 0; i < 2; ++i)
  if (i == 0)
a = 1;
  else
b = 2;

use a/b

and we warn on one of the uses.  It's not that simple of course since this
kind of simple testcase is handled well...