[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #20 from ktkachov at gcc dot gnu.org ---
Closing as fixed then.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[ktkachov at gcc dot gnu.org]

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

--- Comment #19 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Jan 12 17:02:38 2017
New Revision: 244372

URL: https://gcc.gnu.org/viewcvs?rev=244372=gcc=rev
Log:
Add Cortex-A15 tuning to gcc.dg/uninit-pred-8_a.c

PR tree-optimization/78319
* gcc.dg/uninit-pred-8_a.c: Add -mtune=cortex-a15 for arm.
Remove xfail.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/uninit-pred-8_a.c

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Richard Earnshaw from comment #17)
> (In reply to Jakub Jelinek from comment #15)
> 
> > Unless people commonly use
> > RUNTESTFLAGS='--target_board=unix\{-mtune=cortex-a15,-mtune=cortex-m7\}' or
> > something similar, that might work well.  The amount of tests that use
> > -mtune= in dg-options or dg-additional-options across all arches is big, so
> > most likely such RUNTESTFLAGS wouldn't be a very good idea.
> 
> 
> I think you're confusing ARM's use of -mtune with x86's.  The x86 equivalent
> of -mtune on ARM is -mcpu: it is rare to see -mtune in testsuite runs.
> 
> (On ARM there are two main options here -- -march and -mtune: -march selects
> the permitted instructions; -mtune controls how to pick from within the
> permitted set.  -mcpu is a convenience option that controls both options at
> the same time).

>From your description x86 -mtune is exactly what arm -mtune is, select CPU to
tune for within the ISA chosen by other options (so something that affects
scheduling choices, costs etc.).  My comment has been mainly about the flags
comming from --target_board being appended after dg-options, i.e. that if
-mtune= would be commonly used in --target_board, then it wouldn't work well.
If it is not used and people use -march= or -mcpu= there instead, then using
/* { dg-additional-options "-mtune=..." { target ... } } */
is fine.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[rearnsha at gcc dot gnu.org]

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

--- Comment #17 from Richard Earnshaw  ---
(In reply to Jakub Jelinek from comment #15)

> Unless people commonly use
> RUNTESTFLAGS='--target_board=unix\{-mtune=cortex-a15,-mtune=cortex-m7\}' or
> something similar, that might work well.  The amount of tests that use
> -mtune= in dg-options or dg-additional-options across all arches is big, so
> most likely such RUNTESTFLAGS wouldn't be a very good idea.


I think you're confusing ARM's use of -mtune with x86's.  The x86 equivalent of
-mtune on ARM is -mcpu: it is rare to see -mtune in testsuite runs.

(On ARM there are two main options here -- -march and -mtune: -march selects
the permitted instructions; -mtune controls how to pick from within the
permitted set.  -mcpu is a convenience option that controls both options at the
same time).

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[thopre01 at gcc dot gnu.org]

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

--- Comment #16 from Thomas Preud'homme  ---
FYI: -mtune=cortex-a15 works for an arm-none-eabi toolchain targetting
Cortex-M7

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to ktkachov from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > So do you want something like:
> > /* { dg-skip-if "avoid conflicts with multilib options" { arm*-*-* } {
> > "-mcpu=*" } { "-mcpu=cortex-a15" } } */
> > /* { dg-additional-options "-mcpu=cortex-a15" { target arm*-*-* } } */
> > and remove the xfail?
> > cortex-a15 is randomly chosen non-cortex-m7 CPU, I don't know anything about
> > the ARM CPUs and what branch costs they have.
> > In any case, please resolve this soon, for a small testsuite glitch
> > (occassional XFAIL) keeping open P3 regression for so long is wasteful.
> 
> I'd be happy with any tuning that makes this pass. I'll check with
> cortex-a15.
> Also, I suggest just using
> /* { dg-additional-options "-mtune=cortex-a15" { target arm*-*-* } } */
> That will use the cortex-a15 tuning (including BRANCH_COST) but will not
> enforce any architectural features, so should avoid the need for the
> multilib stuff

Unless people commonly use
RUNTESTFLAGS='--target_board=unix\{-mtune=cortex-a15,-mtune=cortex-m7\}' or
something similar, that might work well.  The amount of tests that use -mtune=
in dg-options or dg-additional-options across all arches is big, so most likely
such RUNTESTFLAGS wouldn't be a very good idea.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #14 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #13)
> So do you want something like:
> /* { dg-skip-if "avoid conflicts with multilib options" { arm*-*-* } {
> "-mcpu=*" } { "-mcpu=cortex-a15" } } */
> /* { dg-additional-options "-mcpu=cortex-a15" { target arm*-*-* } } */
> and remove the xfail?
> cortex-a15 is randomly chosen non-cortex-m7 CPU, I don't know anything about
> the ARM CPUs and what branch costs they have.
> In any case, please resolve this soon, for a small testsuite glitch
> (occassional XFAIL) keeping open P3 regression for so long is wasteful.

I'd be happy with any tuning that makes this pass. I'll check with cortex-a15.
Also, I suggest just using
/* { dg-additional-options "-mtune=cortex-a15" { target arm*-*-* } } */
That will use the cortex-a15 tuning (including BRANCH_COST) but will not
enforce any architectural features, so should avoid the need for the multilib
stuff

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
So do you want something like:
/* { dg-skip-if "avoid conflicts with multilib options" { arm*-*-* } {
"-mcpu=*" } { "-mcpu=cortex-a15" } } */
/* { dg-additional-options "-mcpu=cortex-a15" { target arm*-*-* } } */
and remove the xfail?
cortex-a15 is randomly chosen non-cortex-m7 CPU, I don't know anything about
the ARM CPUs and what branch costs they have.
In any case, please resolve this soon, for a small testsuite glitch
(occassional XFAIL) keeping open P3 regression for so long is wasteful.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #12 from James Greenhalgh  ---
Probably the easiest thing to do would be to force the dg-options to something
we know has the correct costs on ARM. Like most cost-based transformations in
GCC there is probably no good answer to make the transform apply across all
targets.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #11 from prathamesh3492 at gcc dot gnu.org ---
(In reply to amker from comment #10)
> Hi Prathamesh,
> I saw it starting XPASS on arm-none-eabi in test now:
> 
> spawn /.../gcc/xgcc -B/.../gcc/
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c -fno-diagnostics-show-caret
> -fdiagnostics-color=never -Wuninitialized -O2 -S -o uninit-pred-8_a.s
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c: In function 'foo_2':
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c:43:7: warning: 'v' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
> output is:
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c: In function 'foo_2':
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c:43:7: warning: 'v' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
> 
> XPASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
> 21)
> PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
> 24)
> PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
> 27)
> PASS: gcc.dg/uninit-pred-8_a.c warning (test for warnings, line 43)
> PASS: gcc.dg/uninit-pred-8_a.c (test for excess errors)
> 
> The gcc is configured as:
> /.../gcc/configure --target=arm-none-eabi --prefix=/.../install
> --with-gmp=... --with-mpfr=... --with-mpc=... --with-isl=...
> --with-pkgversion=unknown --disable-shared --disable-nls --disable-threads
> --disable-tls --enable-checking=yes --enable-languages=c,c++ --with-newlib

The test should ideally be XFAIL'd only for cortex-m7 subtarget of
arm-none-eabi.
However I am not sure if that's possible, so XFAIL'd for arm-none-eabi.
With cortex-m7 I am still seeing the XFAIL:

XFAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
21)
PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 24)
PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 27)
PASS: gcc.dg/uninit-pred-8_a.c warning (test for warnings, line 43)
PASS: gcc.dg/uninit-pred-8_a.c (test for excess errors)

Thanks,
Prathamesh

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #10 from amker at gcc dot gnu.org ---
Hi Prathamesh,
I saw it starting XPASS on arm-none-eabi in test now:

spawn /.../gcc/xgcc -B/.../gcc/ /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -Wuninitialized -O2 -S -o
uninit-pred-8_a.s
/.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c: In function 'foo_2':
/.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c:43:7: warning: 'v' may be used
uninitialized in this function [-Wmaybe-uninitialized]
output is:
/.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c: In function 'foo_2':
/.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c:43:7: warning: 'v' may be used
uninitialized in this function [-Wmaybe-uninitialized]

XPASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
21)
PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 24)
PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 27)
PASS: gcc.dg/uninit-pred-8_a.c warning (test for warnings, line 43)
PASS: gcc.dg/uninit-pred-8_a.c (test for excess errors)

The gcc is configured as:
/.../gcc/configure --target=arm-none-eabi --prefix=/.../install --with-gmp=...
--with-mpfr=... --with-mpc=... --with-isl=... --with-pkgversion=unknown
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++ --with-newlib

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #9 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Thu Nov 17 09:48:34 2016
New Revision: 242540

URL: https://gcc.gnu.org/viewcvs?rev=242540=gcc=rev
Log:
2016-11-17  Prathamesh Kulkarni  

PR tree-optimization/78319

testsuite/
* gcc.dg/uninit-pred-8_a.c (foo): Mark dg-bogus test to xfail on
arm-none-eabi.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/uninit-pred-8_a.c

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #8 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #7)
> (In reply to prathamesh3492 from comment #6)
> > (In reply to Richard Biener from comment #5)
> > > It's a matter of costs (here BRANCH_COST and its uses in fold and 
> > > ifcombine).
> > > 
> > > You don't mention what IL differences your patch causes (I'll check soon
> > > myself).
> > The difference caused by r249195 is the following in forwprop dump on
> > cortex-m7:
> > 
> > before:
> > :
> >   _1 = n_20(D) != 0;
> >   _2 = m_21(D) != 0;
> >   _3 = _1 | _2;
> >   if (_3 != 0)
> > goto ;
> >   else
> > goto ;
> > 
> > after:
> > :
> >   _1 = n_20(D) != 0;
> >   _2 = m_21(D) != 0;
> >   _25 = n_20(D) | m_21(D);
> >   if (_25 != 0)
> > goto ;
> >   else
> > goto ;
> > 
> > _3 = _1 | _2 is replaced by _25 = n_20(D) | m_21(D)
> 
> But there are still uses of _1 (or _2) left, right?
> 
> So it might be that tree-ssa-uninit.c simply needs to be taught
> that X | Y != 0 means X != 0 || Y != 0.  I think this is done
> in normalize_preds though it looks like it is already handled
> to some extent.  But I see
> 
> [BEFORE NORMALIZATION --[USE]:
> blah (v_30);
> is guarded by :
> 
>  (.NOT.) _1 != 0 (.AND.) _5 != 0
> 
> 
> [AFTER NORMALIZATION -- [USE]:
> blah (v_30);
> is guarded by :
> 
> _5 != 0 (.AND.)  (.NOT.) _1 != 0
> 
> while
> 
> [BEFORE NORMALIZATION --[DEF]:
> v_30 = PHI 
> is guarded by :
> 
> m_11(D) != 0
> (.OR.)
> _1 != 0
> (.OR.)
> _2 != 0
> 
> 
> [AFTER NORMALIZATION -- [DEF]:
> v_30 = PHI 
> is guarded by :
> 
> m_11(D) != 0
> (.OR.)
> m_11(D) != 0
> (.OR.)
> n_10(D) != 0
> (.OR.)
> l_13(D) != 0
> (.OR.)
> r_12(D) != 0
> 
> so somehow it expands it in one case but not in the other.
> 
> Can you investigate?
I will give a try.
> 
> > forwprop dump before:
> > http://pastebin.com/vdTs1B0V
> > 
> > forwprop dump after:
> > http://pastebin.com/XuYVGG0z
> > > For the issue at hand I suggest to XFAIL for affected architectures.
> > Ok thanks, I will xfail this test on arm-none-eabi.
> > Ideally I would like to xfail only for cortex-m7 (and not other 
> > sub-targets).
> > Is it possible to check which sub-target is in effect with dejagnu ?
> 
> I don't think so.
Ok thanks, in that case I will XFAIL it on arm-none-eabi.

Thanks,
Prathamesh
> 
> > Thanks,
> > Prathamesh
> > > 
> > > Generally the late uninit pass needs a rewrite to be conservative (make 
> > > its
> > > data-flow compute must-be-may-uninitialized rather than erring on the 
> > > false
> > > positive side when its analysis gives up).
> > > 
> > > A good research project would be to write an IPA static analysis pass that
> > > performs at least some trivial "optimization" itself (constant folding
> > > and propagation) but does not do any IL changes.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-16
 Ever confirmed|0   |1

--- Comment #7 from Richard Biener  ---
(In reply to prathamesh3492 from comment #6)
> (In reply to Richard Biener from comment #5)
> > It's a matter of costs (here BRANCH_COST and its uses in fold and 
> > ifcombine).
> > 
> > You don't mention what IL differences your patch causes (I'll check soon
> > myself).
> The difference caused by r249195 is the following in forwprop dump on
> cortex-m7:
> 
> before:
> :
>   _1 = n_20(D) != 0;
>   _2 = m_21(D) != 0;
>   _3 = _1 | _2;
>   if (_3 != 0)
> goto ;
>   else
> goto ;
> 
> after:
> :
>   _1 = n_20(D) != 0;
>   _2 = m_21(D) != 0;
>   _25 = n_20(D) | m_21(D);
>   if (_25 != 0)
> goto ;
>   else
> goto ;
> 
> _3 = _1 | _2 is replaced by _25 = n_20(D) | m_21(D)

But there are still uses of _1 (or _2) left, right?

So it might be that tree-ssa-uninit.c simply needs to be taught
that X | Y != 0 means X != 0 || Y != 0.  I think this is done
in normalize_preds though it looks like it is already handled
to some extent.  But I see

[BEFORE NORMALIZATION --[USE]:
blah (v_30);
is guarded by :

 (.NOT.) _1 != 0 (.AND.) _5 != 0


[AFTER NORMALIZATION -- [USE]:
blah (v_30);
is guarded by :

_5 != 0 (.AND.)  (.NOT.) _1 != 0

while

[BEFORE NORMALIZATION --[DEF]:
v_30 = PHI 
is guarded by :

m_11(D) != 0
(.OR.)
_1 != 0
(.OR.)
_2 != 0


[AFTER NORMALIZATION -- [DEF]:
v_30 = PHI 
is guarded by :

m_11(D) != 0
(.OR.)
m_11(D) != 0
(.OR.)
n_10(D) != 0
(.OR.)
l_13(D) != 0
(.OR.)
r_12(D) != 0

so somehow it expands it in one case but not in the other.

Can you investigate?

> forwprop dump before:
> http://pastebin.com/vdTs1B0V
> 
> forwprop dump after:
> http://pastebin.com/XuYVGG0z
> > For the issue at hand I suggest to XFAIL for affected architectures.
> Ok thanks, I will xfail this test on arm-none-eabi.
> Ideally I would like to xfail only for cortex-m7 (and not other sub-targets).
> Is it possible to check which sub-target is in effect with dejagnu ?

I don't think so.

> Thanks,
> Prathamesh
> > 
> > Generally the late uninit pass needs a rewrite to be conservative (make its
> > data-flow compute must-be-may-uninitialized rather than erring on the false
> > positive side when its analysis gives up).
> > 
> > A good research project would be to write an IPA static analysis pass that
> > performs at least some trivial "optimization" itself (constant folding
> > and propagation) but does not do any IL changes.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> It's a matter of costs (here BRANCH_COST and its uses in fold and ifcombine).
> 
> You don't mention what IL differences your patch causes (I'll check soon
> myself).
The difference caused by r249195 is the following in forwprop dump on
cortex-m7:

before:
:
  _1 = n_20(D) != 0;
  _2 = m_21(D) != 0;
  _3 = _1 | _2;
  if (_3 != 0)
goto ;
  else
goto ;

after:
:
  _1 = n_20(D) != 0;
  _2 = m_21(D) != 0;
  _25 = n_20(D) | m_21(D);
  if (_25 != 0)
goto ;
  else
goto ;

_3 = _1 | _2 is replaced by _25 = n_20(D) | m_21(D)

forwprop dump before:
http://pastebin.com/vdTs1B0V

forwprop dump after:
http://pastebin.com/XuYVGG0z
> For the issue at hand I suggest to XFAIL for affected architectures.
Ok thanks, I will xfail this test on arm-none-eabi.
Ideally I would like to xfail only for cortex-m7 (and not other sub-targets).
Is it possible to check which sub-target is in effect with dejagnu ?

Thanks,
Prathamesh
> 
> Generally the late uninit pass needs a rewrite to be conservative (make its
> data-flow compute must-be-may-uninitialized rather than erring on the false
> positive side when its analysis gives up).
> 
> A good research project would be to write an IPA static analysis pass that
> performs at least some trivial "optimization" itself (constant folding
> and propagation) but does not do any IL changes.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
It's a matter of costs (here BRANCH_COST and its uses in fold and ifcombine).

You don't mention what IL differences your patch causes (I'll check soon
myself).
For the issue at hand I suggest to XFAIL for affected architectures.

Generally the late uninit pass needs a rewrite to be conservative (make its
data-flow compute must-be-may-uninitialized rather than erring on the false
positive side when its analysis gives up).

A good research project would be to write an IPA static analysis pass that
performs at least some trivial "optimization" itself (constant folding
and propagation) but does not do any IL changes.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #4 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I think this seems to be an issue with uninit pass.
The same behavior can be observed for following test-case on
x86_64-unknown-linux-gnu regardless of r241915.
(test-case is a slight modification of foo() defined in uninit-pred-8_a.c to
generate same CFG on x86_64 as on cortex-m7):

int f(int n, int m, int l, int r)
{
  int t1, t2, t3, t4, v;
  extern int g;
  void bar();
  void blah(int);

  if ((n || m) || (r || l))
v = r;

  if (m != 0)
g++;
  else
bar (); 

  if ((n || m) || (r || l))
blah (v);

  if (n != 0)
blah (v);

  if (l != 0)
blah (v);

  return 0;
}

-O2 -Wuninitialized gives:
foo2.c: In function ‘f’:
foo2.c:17:5: warning: ‘v’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 blah (v);
 ^~~~

Input to uninit pass (dump of crited2 pass):
http://pastebin.com/wJBak3tS

v is assigned the value of r if either _1 is true or _2 is true in above cfg.

The warning at uninitialized use of v is for:
if ((n || m) || (r || l))
  blah(v);

IIUC, the above call to blah(v) is duplicated in two blocks: bb10 and bb16.

bb10 has only one predecessor bb7.
Looking at:
  :
  # v_32 = PHI 
  bar ();

  :
  # v_33 = PHI 
  if (_1 != 0)
goto ;
  else
goto ;

v is uninitialized if the control reaches to bb6 from bb17, ie 
the following path is taken: bb2 -> bb3 -> bb17 -> bb6 -> bb7
This path would be taken only if both _1 and _2 are 0.
Since control goes from bb7 to bb10 only if _1 is nonzero, we can never reach
bb10 if v is uninitialized.

Similarly bb16 has only one predecessor bb8 and bb8 has only one predecessor
bb7.
We reach bb8 from "false edge" of bb7, ie, if _1 is 0.

:
_5 = r_13(D) | l_14(D);
if (_5 != 0)
  goto ;
else
  goto ;

_5 is same as _2. I wonder why r_13(D) | l_14(D) is re-computed here instead of
using _2, which is assigned the same value ?
So if _5 is false, we should never reach bb16 and hence I think the warning is
a false positive.
Does this sound reasonable ?

Btw the warning isn't given if vrp is disabled.
Input to uninit pass after disabling vrp:
http://pastebin.com/index.php

IIC after disabling vrp, the cfg has only one block bb10 representing
the blah(v) call unlike in the first case of enabled vrp, which duplicated
bb10 and bb16 both containing calls to blah(v).

There's another strange issue I noticed about folding:
Consider following test-case:

int f(int n, int m, int l, int r)
{
  if (n || m || r || l)
return 1;
  else
return 0;
}

On x86_64,
ssa pass dump shows:
http://pastebin.com/Fuy6dGX1

truth_orif_expr's are converted to sequence of bit_ior_exprs:
  :
  _1 = n_5(D) | m_6(D);
  _2 = l_7(D) | _1;
  _3 = r_8(D) | _2;
  if (_3 != 0)
goto ;
  else
goto ;


However if the expression is parenthesized as:
if ((n || m) || (r || l)) then truth_orif_expr is not converted to sequence of
bit_ior_exprs as above.

x86_64 ssa dump for parenthesized expression:
http://pastebin.com/AsQ5qLFu

:
  _1 = n_4(D) | m_5(D);
  if (_1 != 0)
goto ;
  else
goto ;

  :
  _2 = l_6(D) | r_7(D);
  if (_2 != 0)
goto ;
  else
goto ;

Why should parenthesizing the sub-expressions make a difference ?

Thanks,
Prathamesh

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
(In reply to prathamesh3492 from comment #2)
> Hi Thomas,
> I am trying to cross-build for cortex-m4 to reproduce the issue locally.
> Could you please share the configure opts you used ?
> 
> Thanks,
> Prathamesh

Hi Prathamesh,

Only --target=arm-none-eabi is necessary to reproduce as long as you pass
-mcpu=cortex-m7 -mthumb on the command line.

Here's what I used to reproduce:

$SRC/configure --prefix=$PWD/../install --target=arm-none-eabi
make all-gcc
make install-gcc
export PATH=$PWD/../install:$PATH
arm-none-eabi-gcc -S -O2 -Wuninitialized -mcpu=cortex-m7 -mthumb
$SRC/gcc/testsuite/gcc.dg/uninit-pred-8_a.c

Thanks for working on this!

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Hi Thomas,
I am trying to cross-build for cortex-m4 to reproduce the issue locally.
Could you please share the configure opts you used ?

Thanks,
Prathamesh

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|PASS->FAIL: |[7 Regression] PASS->FAIL:
   |gcc.dg/uninit-pred-8_a.c|gcc.dg/uninit-pred-8_a.c
   |bogus warning (test for |bogus warning (test for
   |bogus messages, line 20)|bogus messages, line 20)