[Bug tree-optimization/50955] New: IVopts incorrectly rewrite the address of a global memory access into a local form.

[Bug tree-optimization/50955] New: IVopts incorrectly rewrite the address of a global memory access into a local form.

[duyuehai at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

             Bug #: 50955
           Summary: IVopts incorrectly rewrite the address of a global
                    memory access into a local form.
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: duyuehai@gmail.com


Created attachment 25686
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25686
testcase

IVopts use a weird IV candidate to rewrite a memory address, after this
transform, a non-local memory access have been changed to a local one, and 
lately it was deleted by pass_cd_dce.
see http://gcc.gnu.org/ml/gcc/2011-11/msg00002.html for more details.

[Bug tree-optimization/50955] IVopts incorrectly rewrite the address of a global memory access into a local form.

[duyuehai at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #1 from Yuehai Du <duyuehai at gmail dot com> 2011-11-02 05:19:24 UTC ---

gcc version r180694

Configured with: /home/croseadu/android/_src/src/gcc-src/configure
--host=i486-linux-gnu --build=i486-linux-gnu
--target=arm-none-linux-gnueabi
--prefix=/home/croseadu/android/_src/install/arm-none-linux-gnueabi
--enable-threads --disable-libmudflap --disable-libssp
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit
--with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}'
--disable-nls --enable-lto
--with-sysroot=/home/croseadu/android/_src/install/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc
--with-build-sysroot=/home/croseadu/android/_src/install/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc
--with-gmp=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--with-mpfr=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--with-ppl=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm'
--with-cloog=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--enable-cloog-backend=isl
--with-mpc=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--enable-poison-system-directories --disable-libquadmath --enable-lto
--enable-libgomp
--with-build-time-tools=/home/croseadu/android/_src/install/arm-none-linux-gnueabi/arm-none-linux-gnueabi/bin
--with-cpu=cortex-a8 --with-float=soft

compile flags:
-O3 -mfpu=neon -mfloat-abi=softfp -mvectorize-with-neon-double

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-11-02
                 CC|                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |4.7.0
            Summary|IVopts incorrectly rewrite  |[4.7 Regression] IVopts
                   |the address of a global     |incorrectly rewrite the
                   |memory access into a local  |address of a global memory
                   |form.                       |access into a local form.
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-02 09:42:23 UTC ---
I think we should prune any candidate that has more than one symbol in its
affine combination (or rather not add such candidates in the first place).

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-02 12:48:23 UTC ---
The candidate

candidate 15
  depends on 3
  var_before ivtmp.161
  var_after ivtmp.161
  incremented before exit test
  type unsigned int
  base (unsigned int) pDst_39(D) - (unsigned int) &p1
  step (unsigned int) (pretmp.28_118 + 1)

is added via

#3  0x0000000000c99c0b in add_derived_ivs_candidates (data=0x7fffffffd990)
    at /space/rguenther/src/svn/trunk/gcc/tree-ssa-loop-ivopts.c:2531
2531              add_iv_value_candidates (data, use->iv, use);

for

$3 = {id = 7, type = USE_NONLINEAR_EXPR, iv = 0x1b3c840, 
  stmt = 0x2aaaad2ed268, op_p = 0x0, related_cands = 0x1b33a10, 
  n_map_members = 0, cost_map = 0x0, selected = 0x0}
(gdb) call debug_gimple_stmt (0x2aaaad2ed268)
D.6700_302 = D.6698_157 - p1.148_301;

which in turn is created by IVOPTs processing the innermost loop to:

<bb 6>:
  vect_pp1.50_189 = &p1;
  vect_pp1.57_199 = &MEM[(void *)&p1 + 1B];
  vect_pp1.66_217 = &MEM[(void *)&p1 + 2B];
  vect_cst_.72_231 = { 2, 2 };
  vect_cst_.74_236 = { 2, 2 };
  D.6600_244 = (sizetype) y_89;
  batmp.78_245 = pDst_88 + D.6600_244;
  vect_p.80_246 = batmp.78_245 + 1;
  ivtmp.127_156 = (unsigned int) &MEM[(void *)&p1 + 8B];

<bb 7>:
  # ivtmp.124_174 = PHI <ivtmp.124_280(17), 0(6)>
  # ivtmp.127_265 = PHI <ivtmp.127_170(17), ivtmp.127_156(6)>
  D.6698_157 = (unsigned int) batmp.78_245;
  p1.148_301 = (unsigned int) &p1;
  D.6700_302 = D.6698_157 - p1.148_301;
  D.6701_303 = D.6700_302 + ivtmp.127_265;
  D.6702_304 = D.6701_303 + 4294967289;
  D.6703_305 = (vector(8) unsigned char *) D.6702_304;
  vect_p.77_247 = D.6703_305;
  D.6693_281 = (void *) ivtmp.127_265;
  vect_var_.51_192 = MEM[base: D.6693_281, offset: 4294967288B];
...
  MEM[(unsigned char *)vect_p.77_247] = vect_var_.75_243;
  ivtmp.124_280 = ivtmp.124_174 + 1;
  ivtmp.127_170 = ivtmp.127_265 + 8;
  if (ivtmp.124_280 < bnd.44_152)
    goto <bb 17>;
  else
    goto <bb 8>;

<bb 17>:
  goto <bb 7>;

thus introducing this bogus pointer difference.


Reduced testcase:

void
foo1(unsigned char* pSrcLeft,
     unsigned char* pSrcAbove,
     unsigned char* pSrcAboveLeft,
     unsigned char* pDst,
     int dstStep,
     int leftStep, signed int y)
{
  signed int x, s;
  unsigned char  p1[5], p2[5],  p3;

  p1[0] = *pSrcAboveLeft;
  p2[0] = p1[0];
  p2[1] = pSrcLeft[0];
  pSrcLeft += leftStep;
  p2[2] = pSrcLeft[0];
  pSrcLeft += leftStep;
  p2[3] = pSrcLeft[0];
  pSrcLeft += leftStep;
  p2[4] = pSrcLeft[0];

  p1[1] = pSrcAbove[0];
  p1[2] = pSrcAbove[1];
  p1[3] = pSrcAbove[2];
  p1[4] = pSrcAbove[3];

  p3 = (unsigned char)(((signed int)p1[1] + (signed int)p2[1]
                        + (signed int)p1[0] +(signed int)p1[0] + 2 ) >> 2 );

  for( x=y+1; x<4; x++ ) {
      s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
      pDst[x] = (unsigned char)s;
  }

  pDst[y] = p3;
}

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-02 13:09:40 UTC ---
It looks like IVOPTs fails to consider a candidate for the use inquestion
and thus, after choosing the final IV set ends up rewriting that use into
this stupid form (instead of using candidate 0).  The use is

use 3
  generic
  in statement vect_p.60_223 = PHI <vect_p.60_224(16), vect_p.63_222(5)>

  at position
  type vector(8) unsigned char *
  base batmp.61_221 + 1
  step 8
  base object (void *) batmp.61_221
  is a biv
  related candidates

but costs say:

Use 3:
  cand  cost    compl.  depends on
  0     8       1        inv_expr:0
  1     4       1        inv_expr:1
  2     4       1        inv_expr:0
  3     4       1        inv_expr:1
  4     4       1        inv_expr:2

Initial set of candidates:
  cost: 24 (complexity 4)
  cand_cost: 10
  cand_use_cost: 10 (complexity 4)
  candidates: 0, 4
   use:0 --> iv_cand:4, cost=(2,1)
   use:1 --> iv_cand:4, cost=(2,1)
   use:2 --> iv_cand:4, cost=(2,1)
   use:3 --> iv_cand:4, cost=(4,1)
   use:4 --> iv_cand:0, cost=(0,0)
  invariants 7

Selected IV set:
candidate 0 (important)
  var_before ivtmp.107_150
  var_after ivtmp.107_256
  incremented before exit test
  type unsigned int
  base 0
  step 1
candidate 4 (important)
  var_before ivtmp.110_241
  var_after ivtmp.110_146
  incremented before exit test
  type unsigned int
  base (unsigned int) (&p1 + 8)
  step 8
  base object (void *) &p1

so expressing use 3 with candidate 4 is cheaper than with candidate 0...

Now, for address-uses we have

  if (address_p)
    {
      /* Do not try to express address of an object with computation based
         on address of a different object.  This may cause problems in rtl
         level alias analysis (that does not expect this to be happening,
         as this is illegal in C), and would be unlikely to be useful
         anyway.  */
      if (use->iv->base_object
          && cand->iv->base_object
          && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
        return infinite_cost;

in cost calculation, but in this case it's a nonlinear use, and we have

(gdb) call debug_generic_expr (use->iv->base_object)
(void *) batmp.61_221
(gdb) call debug_generic_expr (cand->iv->base_object)
(void *) &p1

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at gcc dot gnu.org

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-02 13:33:21 UTC ---
It's not easy to detect this situation from IVOPTs (well, conservatively
at least).  Given that this is another case of alias analysis being
confused (TMR[&p1 + ivtmp] does not refer to object p1), dumbing down
that analysis would seem like a "solution" to this issue ... :/

That's of course not a sustainable approach ...

pointer analysis on MEM[symbol: p1, index: ivtmp.161_200, offset: 0B]
would figure that &p1 + ivtmp.161_200 also points to NONLOCAL, not only
to p1, but we do not have a SSA name to store points-to info in this
case (one more argument against TARGET_MEM_REF and an argument for
more complex address-computation trees instead).  Thus we'd for now
have to assume that a TARGET_MEM_REF points to anything ... that's
pretty bad for RTL optimization, for exactly which we improved alias
analysis for TARGET_MEM_REF in the first place.

Hum.

The issue only pops up because of the ->consider_all_candidates path.
Otherwise we do not apply this awkward choice.

Thus you can avoid the issue by --param iv-consider-all-candidates-bound=1.

Maybe we shouldn't really consider _all_ candidates, but only all bivs?

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[duyuehai at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #6 from Yuehai Du <duyuehai at gmail dot com> 2011-11-03 06:24:58 UTC ---
Let me see if i understand you correctly, you are saying that there isn't an
easy way to fix it without hurting the performance(either consider less IV
candidates or dumb down the alias analysis). 
 so this issue won't be fixed  in trunk now?
if in that case, Avoiding the issue by set PARM isn't an option for me.  i
still want to fix it in our private port even with an ugly patch. can we just
add a new field in MEM_REF which specify it is local or non-nolocal
store(enum{INVALID, LOCAL, NON-LOCAL}),  and only set it in IVOPTS before it
rewrite the address. we will check this in is_hidden_global_store(). do this
work in Gimple level? but i don't know if RTL optimization still delete this
store because we don't keep points-to information.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2011-11-03 07:51:25 UTC ---
On Thu, 3 Nov 2011, duyuehai at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> 
> --- Comment #6 from Yuehai Du <duyuehai at gmail dot com> 2011-11-03 06:24:58 UTC ---
> Let me see if i understand you correctly, you are saying that there isn't an
> easy way to fix it without hurting the performance(either consider less IV
> candidates or dumb down the alias analysis). 

Yes.

>  so this issue won't be fixed  in trunk now?

At least I can't see an easy way out.  What I was considering as _maybe_
a good final solution would be to remove TARGET_MEM_REF and instead
have TARGET_MEM_REF_ADDR, which would produce an SSA name where we
could in turn attach alias info to.  The minor downside of that is
that we lose the ability to directly specify a symbol as the base
for a TARGET_MEM_REF (which is ironically exactly the point where
things wreck in this testcase ...)

> if in that case, Avoiding the issue by set PARM isn't an option for me.  i
> still want to fix it in our private port even with an ugly patch. can we just
> add a new field in MEM_REF which specify it is local or non-nolocal
> store(enum{INVALID, LOCAL, NON-LOCAL}),  and only set it in IVOPTS before it
> rewrite the address. we will check this in is_hidden_global_store(). do this
> work in Gimple level? but i don't know if RTL optimization still delete this
> store because we don't keep points-to information.

The issue is not only in is_hidden_global_store (), but the issue
is that alias analysis thinks the store may only alias the local p1
array.  Thus you may as well get miscompiles from RTL scheduling as well.
You could already paper over the issue in question by checking
if a TARGET_MEM_REF has TMR_OFFSET or TMR_OFFSET2 != NULL_TREE in
is_hidden_global_store ().  Another way would be to make sure we
bias costs enough to make the situation less likely, for example
in get_computation_cost_at, make the address_p code unconditional.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rakdver at kam dot mff.cuni.cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #8 from rakdver at kam dot mff.cuni.cz <rakdver at kam dot mff.cuni.cz> 2011-11-03 08:06:52 UTC ---
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> > 
> > --- Comment #6 from Yuehai Du <duyuehai at gmail dot com> 2011-11-03 06:24:58 UTC ---
> > Let me see if i understand you correctly, you are saying that there isn't an
> > easy way to fix it without hurting the performance(either consider less IV
> > candidates or dumb down the alias analysis). 
> 
> Yes.
> 
> >  so this issue won't be fixed  in trunk now?
> 
> At least I can't see an easy way out.  What I was considering as _maybe_
> a good final solution would be to remove TARGET_MEM_REF and instead
> have TARGET_MEM_REF_ADDR, which would produce an SSA name where we
> could in turn attach alias info to.  The minor downside of that is
> that we lose the ability to directly specify a symbol as the base
> for a TARGET_MEM_REF (which is ironically exactly the point where
> things wreck in this testcase ...)

or we could just start associating alias info with memory references instead
of with pointers.  Either way, this would be a major change.  Anyway, let
me have a look at this, perhaps I can come up with something less intrusive.

> > if in that case, Avoiding the issue by set PARM isn't an option for me.  i
> > still want to fix it in our private port even with an ugly patch. can we just
> > add a new field in MEM_REF which specify it is local or non-nolocal
> > store(enum{INVALID, LOCAL, NON-LOCAL}),  and only set it in IVOPTS before it
> > rewrite the address. we will check this in is_hidden_global_store(). do this
> > work in Gimple level? but i don't know if RTL optimization still delete this
> > store because we don't keep points-to information.
> 
> The issue is not only in is_hidden_global_store (), but the issue
> is that alias analysis thinks the store may only alias the local p1
> array.  Thus you may as well get miscompiles from RTL scheduling as well.
> You could already paper over the issue in question by checking
> if a TARGET_MEM_REF has TMR_OFFSET or TMR_OFFSET2 != NULL_TREE in
> is_hidden_global_store ().  Another way would be to make sure we
> bias costs enough to make the situation less likely, for example
> in get_computation_cost_at, make the address_p code unconditional.

Making a miscompilation "less likely" is really not a good idea; we need to
really fix the problem, even if it means some performance penalty.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-03 08:18:05 UTC ---
(In reply to comment #8)
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> > > 
> > > --- Comment #6 from Yuehai Du <duyuehai at gmail dot com> 2011-11-03 06:24:58 UTC ---
> > > Let me see if i understand you correctly, you are saying that there isn't an
> > > easy way to fix it without hurting the performance(either consider less IV
> > > candidates or dumb down the alias analysis). 
> > 
> > Yes.
> > 
> > >  so this issue won't be fixed  in trunk now?
> > 
> > At least I can't see an easy way out.  What I was considering as _maybe_
> > a good final solution would be to remove TARGET_MEM_REF and instead
> > have TARGET_MEM_REF_ADDR, which would produce an SSA name where we
> > could in turn attach alias info to.  The minor downside of that is
> > that we lose the ability to directly specify a symbol as the base
> > for a TARGET_MEM_REF (which is ironically exactly the point where
> > things wreck in this testcase ...)
> 
> or we could just start associating alias info with memory references instead
> of with pointers.  Either way, this would be a major change.  Anyway, let
> me have a look at this, perhaps I can come up with something less intrusive.
> 
> > > if in that case, Avoiding the issue by set PARM isn't an option for me.  i
> > > still want to fix it in our private port even with an ugly patch. can we just
> > > add a new field in MEM_REF which specify it is local or non-nolocal
> > > store(enum{INVALID, LOCAL, NON-LOCAL}),  and only set it in IVOPTS before it
> > > rewrite the address. we will check this in is_hidden_global_store(). do this
> > > work in Gimple level? but i don't know if RTL optimization still delete this
> > > store because we don't keep points-to information.
> > 
> > The issue is not only in is_hidden_global_store (), but the issue
> > is that alias analysis thinks the store may only alias the local p1
> > array.  Thus you may as well get miscompiles from RTL scheduling as well.
> > You could already paper over the issue in question by checking
> > if a TARGET_MEM_REF has TMR_OFFSET or TMR_OFFSET2 != NULL_TREE in
> > is_hidden_global_store ().  Another way would be to make sure we
> > bias costs enough to make the situation less likely, for example
> > in get_computation_cost_at, make the address_p code unconditional.
> 
> Making a miscompilation "less likely" is really not a good idea; we need to
> really fix the problem, even if it means some performance penalty.

I agree.  I think the main difficulty is to detect this issue reliably
(and not too conservatively) - arranging for the TARGET_MEM_REF to look
ok from an aliasing point of view shouldn't be too difficult then
(simply use a INTEGER_CST zero TMR_BASE and shuffle the real base to
TMR_INDEX2).

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-31 10:41:34 UTC ---
I'll have a look and either fix or downgrade this one ...

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-31 14:02:20 UTC ---
(In reply to comment #4)
> It looks like IVOPTs fails to consider a candidate for the use inquestion
> and thus, after choosing the final IV set ends up rewriting that use into
> this stupid form (instead of using candidate 0).  The use is
> 
> use 3
>   generic
>   in statement vect_p.60_223 = PHI <vect_p.60_224(16), vect_p.63_222(5)>
> 
>   at position
>   type vector(8) unsigned char *
>   base batmp.61_221 + 1
>   step 8
>   base object (void *) batmp.61_221
>   is a biv
>   related candidates
> 
> but costs say:
> 
> Use 3:
>   cand  cost    compl.  depends on
>   0     8       1        inv_expr:0
>   1     4       1        inv_expr:1
>   2     4       1        inv_expr:0
>   3     4       1        inv_expr:1
>   4     4       1        inv_expr:2
> 
> Initial set of candidates:
>   cost: 24 (complexity 4)
>   cand_cost: 10
>   cand_use_cost: 10 (complexity 4)
>   candidates: 0, 4
>    use:0 --> iv_cand:4, cost=(2,1)
>    use:1 --> iv_cand:4, cost=(2,1)
>    use:2 --> iv_cand:4, cost=(2,1)
>    use:3 --> iv_cand:4, cost=(4,1)
>    use:4 --> iv_cand:0, cost=(0,0)
>   invariants 7
> 
> Selected IV set:
> candidate 0 (important)
>   var_before ivtmp.107_150
>   var_after ivtmp.107_256
>   incremented before exit test
>   type unsigned int
>   base 0
>   step 1
> candidate 4 (important)
>   var_before ivtmp.110_241
>   var_after ivtmp.110_146
>   incremented before exit test
>   type unsigned int
>   base (unsigned int) (&p1 + 8)
>   step 8
>   base object (void *) &p1
> 
> so expressing use 3 with candidate 4 is cheaper than with candidate 0...
> 
> Now, for address-uses we have
> 
>   if (address_p)
>     {
>       /* Do not try to express address of an object with computation based
>          on address of a different object.  This may cause problems in rtl
>          level alias analysis (that does not expect this to be happening,
>          as this is illegal in C), and would be unlikely to be useful
>          anyway.  */
>       if (use->iv->base_object
>           && cand->iv->base_object
>           && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
>         return infinite_cost;
> 
> in cost calculation, but in this case it's a nonlinear use, and we have
> 
> (gdb) call debug_generic_expr (use->iv->base_object)
> (void *) batmp.61_221
> (gdb) call debug_generic_expr (cand->iv->base_object)
> (void *) &p1

So one could extend the address_p case to cover all address IVs, like with

Index: gcc/tree-ssa-loop-ivopts.c
===================================================================
--- gcc/tree-ssa-loop-ivopts.c  (revision 183757)
+++ gcc/tree-ssa-loop-ivopts.c  (working copy)
@@ -4048,7 +4048,11 @@ get_computation_cost_at (struct ivopts_d
       return infinite_cost;
     }

-  if (address_p)
+  if (address_p
+      || (use->iv->base_object
+         && cand->iv->base_object
+         && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object))
+         && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object))))
     {
       /* Do not try to express address of an object with computation based
         on address of a different object.  This may cause problems in rtl

which avoids the issue for this testcase at the cost of choosing three
IVs instead of two:

Selected IV set:
candidate 0 (important)
  var_before ivtmp.107_152
  var_after ivtmp.107_258
  incremented before exit test
  type unsigned int
  base 0
  step 1
candidate 4 (important)
  var_before ivtmp.110_243
  var_after ivtmp.110_148
  incremented before exit test
  type unsigned int
  base (unsigned int) (&p1 + 8)
  step 8
  base object (void *) &p1
candidate 11 (important)
  var_before ivtmp.115_259
  var_after ivtmp.115_251
  incremented before exit test
  type unsigned int
  base (unsigned int) (batmp.61_223 + 1)
  step 8
  base object (void *) batmp.61_223

IVOPTs does not consider using candidate 0 for use 3:

Use 3:
  cand  cost    compl.  depends on
  0     8       1        inv_expr:0
  2     4       1        inv_expr:0
  11    0       0
  12    0       0
  13    4       1
  14    8       1        inv_expr:0
  15    8       1        inv_expr:1
  18    4       1        inv_expr:2
  19    4       1        inv_expr:0
  22    4       1        inv_expr:2
  23    4       1        inv_expr:0
  26    4       1        inv_expr:2
  27    4       1        inv_expr:0
  28    4       1

as it seems to favor adding another IV here.

It seems to even generate better code, but it's a pretty big hammer ...

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-06 13:43:06 UTC ---
Author: rguenth
Date: Mon Feb  6 13:43:03 2012
New Revision: 183934

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183934
Log:
2012-02-06  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/50955
    * tree-ssa-loop-ivopts.c (get_computation_cost_at): Artificially
    raise cost of expressions that replace an address with an
    expression based on a different pointer.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-ivopts.c

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-06 13:43:23 UTC ---
Fixed.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am running into a similar situation with a modified 4.7 on mips64-linux-gnu
(configured to use the Octeon2 instructions which has a load instruction which
does base+index [or rather reg+reg]).

<bb 3>:
  D.14164_68 = attr_widths_19(D) + 4;
  ivtmp.70_72 = (unsigned int) D.14164_68;

<bb 4>:
  # tuple_width_54 = PHI <tuple_width_1(13), 0(3)>
  # i_52 = PHI <i_39(13), 1(3)>
  # ivtmp.70_70 = PHI <ivtmp.70_69(13), ivtmp.70_72(3)>
  D.13665_11 = rel_7(D)->rd_att;
  D.13666_12 = D.13665_11->attrs;
  D.14165_73 = (sizetype) attr_widths_19(D);
  D.14166_74 = -4 - D.14165_73;
  D.14167_75 = D.14166_74 + ivtmp.70_70;
  D.13670_16 = D.13666_12 + D.14167_75;
  att_17 = *D.13670_16;
  D.13671_18 = att_17->attisdropped;
  if (D.13671_18 != 0)
    goto <bb 13>;
  else
    goto <bb 5>;

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #14)
> I am running into a similar situation with a modified 4.7 on
> mips64-linux-gnu (configured to use the Octeon2 instructions which has a
> load instruction which does base+index [or rather reg+reg]).

Before IV-OPTS I have this use:
  i.17_13 = (sizetype) i_52;
  D.13668_14 = i.17_13 + -1;
  D.13669_15 = D.13668_14 * 4;
  D.13670_16 = D.13666_12 + D.13669_15;
  att_17 = *D.13670_16;

But we decided that it was not used as an address here though.  We have:
(gdb) p *use->iv
$15 = {base = 0x7ffff77e1c60, base_object = 0x0, step = 0x7ffff77e1c60,
ssa_name = 0x0, biv_p = 0 '\000', 
  have_use_for = 1 '\001', use_id = 0}
(gdb) p *use
$16 = {id = 3, type = USE_NONLINEAR_EXPR, iv = 0x1376bb0, stmt =
0x7ffff727c780, op_p = 0x0, related_cands = 0x0, 
  n_map_members = 10, cost_map = 0x13de580, selected = 0x0}

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 16 Aug 2013, pinskia at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> 
> --- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (In reply to Andrew Pinski from comment #14)
> > I am running into a similar situation with a modified 4.7 on
> > mips64-linux-gnu (configured to use the Octeon2 instructions which has a
> > load instruction which does base+index [or rather reg+reg]).
> 
> Before IV-OPTS I have this use:
>   i.17_13 = (sizetype) i_52;
>   D.13668_14 = i.17_13 + -1;
>   D.13669_15 = D.13668_14 * 4;
>   D.13670_16 = D.13666_12 + D.13669_15;
>   att_17 = *D.13670_16;
> 
> But we decided that it was not used as an address here though.  We have:
> (gdb) p *use->iv
> $15 = {base = 0x7ffff77e1c60, base_object = 0x0, step = 0x7ffff77e1c60,
> ssa_name = 0x0, biv_p = 0 '\000', 
>   have_use_for = 1 '\001', use_id = 0}
> (gdb) p *use
> $16 = {id = 3, type = USE_NONLINEAR_EXPR, iv = 0x1376bb0, stmt =
> 0x7ffff727c780, op_p = 0x0, related_cands = 0x0, 
>   n_map_members = 10, cost_map = 0x13de580, selected = 0x0}

The original fix was supposed to be as small as possible (late in
the release cycle).  So it intentionally wasn't trying to be complete.

If you can provide a reproducer on trunk I'll gladly have a look
again (please open a new bugreport)

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
"amker.cheng at gmail dot com" <gcc-bugzilla@gcc.gnu.org> wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
>
>bin.cheng <amker.cheng at gmail dot com> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>           CC|                            |amker.cheng at gmail dot com
>
>--- Comment #17 from bin.cheng <amker.cheng at gmail dot com> ---
>Hi Richard,
>I am having difficulty in understanding cases if this PR.
>For the reported case with two loops:
>
>  for( y=0; y<4; y++, pDst += dstStep ) {
>    for( x=y+1; x<4; x++ ) {
>            s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
>                    pDst[x] = (unsigned char)s;
>    }
>
>    pDst[y] = p3;
>  }
>
>The dump for statement 'pDst[y] = p3;' before IVOPT is like:
>
><bb 4>:
>Invalid sum of incoming frequencies 1667, should be 278
>  y.2_64 = (sizetype) y_89;
>  D.6421_65 = pDst_88 + y.2_64;
>  *D.6421_65 = p3_37;
>  pDst_69 = pDst_88 + pretmp.21_118;
>  ivtmp.35_116 = ivtmp.35_87 - 1;
>  if (ivtmp.35_116 != 0)
>    goto <bb 18>;
>  else
>    goto <bb 19>;
>
>
>IVOPT chooses candidate 15:
>candidate 15
>  depends on 3
>  var_before ivtmp.154
>  var_after ivtmp.154
>  incremented before exit test
>  type unsigned int
>  base (unsigned int) pDst_39(D) - (unsigned int) &p1
>  step (unsigned int) (pretmp.21_118 + 1)
>for use 1:
>use 1
>  address
>  in statement *D.6421_65 = p3_37;
>
>  at position *D.6421_65
>  type unsigned char *
>  base pDst_39(D)
>  step pretmp.21_118 + 1
>  base object (void *) pDst_39(D)
>  related candidates 
>
>After rewriting, the dump is like:
>
><bb 4>:
>Invalid sum of incoming frequencies 1667, should be 278
>  MEM[symbol: p1, index: ivtmp.154_200, offset: 0B] = p3_37;
>  pDst_69 = pDst_88 + pretmp.21_118;
>  ivtmp.149_218 = ivtmp.149_249 - 1;
>  ivtmp.154_190 = ivtmp.154_200 + D.6617_250;
>  if (x_40 != 4)
>    goto <bb 18>;
>  else
>    goto <bb 19>;
>
>Eventually, the storing to TMR[p1,ivtmp,0] is considered local and
>deleted.
>
>BUT, for your reduced case:
>
>  p3 = (unsigned char)(((signed int)p1[1] + (signed int)p2[1]
>                   + (signed int)p1[0] +(signed int)p1[0] + 2 ) >> 2 );
>
>  for( x=y+1; x<4; x++ ) {
>      s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
>      pDst[x] = (unsigned char)s;
>  }
>
>  pDst[y] = p3;
>
>It is about the the TMR in below dump (before IVOPT):
>
><bb 6>:
>  # vect_pp1.30_166 = PHI <vect_pp1.30_167(16), vect_pp1.33_165(5)>
>  # vect_pp1.37_176 = PHI <vect_pp1.37_177(16), vect_pp1.40_175(5)>
>  # vect_pp1.46_194 = PHI <vect_pp1.46_195(16), vect_pp1.49_193(5)>
>  # vect_p.60_223 = PHI <vect_p.60_224(16), vect_p.63_222(5)>
>  # ivtmp.64_225 = PHI <ivtmp.64_226(16), 0(5)>
>  ...
>  MEM[(unsigned char *)vect_p.60_223] = vect_var_.58_219;
>  vect_pp1.30_167 = vect_pp1.30_166 + 8;
>  vect_pp1.37_177 = vect_pp1.37_176 + 8;
>  vect_pp1.46_195 = vect_pp1.46_194 + 8;
>  vect_p.60_224 = vect_p.60_223 + 8;
>  ivtmp.64_226 = ivtmp.64_225 + 1;
>  if (ivtmp.64_226 < bnd.27_128)
>    goto <bb 16>;
>  else
>    goto <bb 7>;
>
>Your patch prevents IVOPT from choosing cand 4:
>candidate 4 (important)
>  var_before ivtmp.110
>  var_after ivtmp.110
>  incremented before exit test
>  type unsigned int
>  base (unsigned int) (&p1 + 8)
>  step 8
>  base object (void *) &p1
>for use 3:
>use 3
>  generic
> in statement vect_p.60_223 = PHI <vect_p.60_224(16), vect_p.63_222(5)>
>
>  at position 
>  type vector(8) unsigned char *
>  base batmp.61_221 + 1
>  step 8
>  base object (void *) batmp.61_221
>  is a biv
>  related candidates 
>
>To prevent IVOPT from rewriting into:
>
><bb 6>:
>  # ivtmp.107_150 = PHI <ivtmp.107_256(16), 0(5)>
>  # ivtmp.110_241 = PHI <ivtmp.110_146(16), ivtmp.110_132(5)>
>  D.6585_133 = (unsigned int) batmp.61_221;
>  p1.131_277 = (unsigned int) &p1;
>  D.6587_278 = D.6585_133 - p1.131_277;
>  D.6588_279 = D.6587_278 + ivtmp.110_241;
>  D.6589_280 = D.6588_279 + 4294967289;
>  D.6590_281 = (vector(8) unsigned char *) D.6589_280;
>  vect_p.60_223 = D.6590_281;
>  ...
>  MEM[(unsigned char *)vect_p.60_223] = vect_var_.58_219;
>  ivtmp.107_256 = ivtmp.107_150 + 1;
>  ivtmp.110_146 = ivtmp.110_241 + 8;
>  if (ivtmp.107_256 < bnd.27_128)
>    goto <bb 16>;
>  else
>    goto <bb 7>;
>
>Thus prevents IVOPT from generating candidate 15 in outer loop. 
>(Expressing
>use 3 by cand 4 itself is good, right?)
>
>
>-------------------------------
>But,
>It seems because the check:
>
>  if (address_p)
>    {
>   /* Do not try to express address of an object with computation based
>      on address of a different object.  This may cause problems in rtl
>       level alias analysis (that does not expect this to be happening,
>         as this is illegal in C), and would be unlikely to be useful
>         anyway.  */
>      if (use->iv->base_object
>          && cand->iv->base_object
>  && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
>        return infinite_cost;
>
>failed because cand(15)->iv->base_object == NULL.  For the reported
>case, it's
>not about an iv use appearing in memory reference while not marked as
>address_p, and can be fixed by revise the existing check condition, is
>it true?

No, even expressing an address this way is broken as for example dependence
analysis via scev can get confused about the actual base object.

IIRC previously we already avoided the mem-use case and I had to generalize it
to also avoid addresses.

>PS, sorry for replying to a fixed PR, I found it's kind of impossible
>to fix
>PR52272 without fully understanding this one.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #19 from bin.cheng <amker.cheng at gmail dot com> ---
> 
> >not about an iv use appearing in memory reference while not marked as
> >address_p, and can be fixed by revise the existing check condition, is
> >it true?
> 
> No, even expressing an address this way is broken as for example dependence 
> analysis via scev can get confused about the actual base object.
Agree, only I think it's not scev's responsibility since scev only cares base
value initialized for the analyzing loop, rather than the BASE object.

> 
> IIRC previously we already avoided the mem-use case and I had to generalize it 
> to also avoid addresses.
Not all.
For the reported case, use and cand like:
use 3
  generic
  in statement vect_p.70_247 = PHI <vect_p.70_248(17), vect_p.73_246(6)>

  at position 
  type vector(8) unsigned char *
  base batmp.71_245 + 1
  step 8
  base object (void *) batmp.71_245
  is a biv
  related candidates 

candidate 15
  depends on 3
  var_before ivtmp.154
  var_after ivtmp.154
  incremented before exit test
  type unsigned int
  base (unsigned int) pDst_39(D) - (unsigned int) &p1
  step (unsigned int) (pretmp.21_118 + 1)

The check:

  if (address_p
      || (use->iv->base_object
      && cand->iv->base_object
      && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object))
      && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object))))
    {
      /* Do not try to express address of an object with computation based
     on address of a different object.  This may cause problems in rtl
     level alias analysis (that does not expect this to be happening,
     as this is illegal in C), and would be unlikely to be useful
     anyway.  */
      if (use->iv->base_object
      && cand->iv->base_object
      && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
    return infinite_cost;
    }

still evaluates to false because:
   use->iv->base_object != NULL  &&  cand->iv->base_object == NULL
>

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to bin.cheng from comment #19)
> > 
> > >not about an iv use appearing in memory reference while not marked as
> > >address_p, and can be fixed by revise the existing check condition, is
> > >it true?
> > 
> > No, even expressing an address this way is broken as for example dependence 
> > analysis via scev can get confused about the actual base object.
> Agree, only I think it's not scev's responsibility since scev only cares
> base value initialized for the analyzing loop, rather than the BASE object.
> 
> > 
> > IIRC previously we already avoided the mem-use case and I had to generalize it 
> > to also avoid addresses.
> Not all.
> For the reported case, use and cand like:
> use 3
>   generic
>   in statement vect_p.70_247 = PHI <vect_p.70_248(17), vect_p.73_246(6)>
> 
>   at position 
>   type vector(8) unsigned char *
>   base batmp.71_245 + 1
>   step 8
>   base object (void *) batmp.71_245
>   is a biv
>   related candidates 
> 
> candidate 15
>   depends on 3
>   var_before ivtmp.154
>   var_after ivtmp.154
>   incremented before exit test
>   type unsigned int
>   base (unsigned int) pDst_39(D) - (unsigned int) &p1
>   step (unsigned int) (pretmp.21_118 + 1)
> 
> The check:
> 
>   if (address_p
>       || (use->iv->base_object
> 	  && cand->iv->base_object
> 	  && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object))
> 	  && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object))))
>     {
>       /* Do not try to express address of an object with computation based
> 	 on address of a different object.  This may cause problems in rtl
> 	 level alias analysis (that does not expect this to be happening,
> 	 as this is illegal in C), and would be unlikely to be useful
> 	 anyway.  */
>       if (use->iv->base_object
> 	  && cand->iv->base_object
> 	  && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
> 	return infinite_cost;
>     }
> 
> still evaluates to false because:
>    use->iv->base_object != NULL  &&  cand->iv->base_object == NULL
> >

As I said in the PR that was last fixed with change of this code it is a
quick & dirty fix (because we were in stage3 again).

A better fix would be to detect reliably whether we are expressing an IV
with base A using an IV with base B != A (reliably == conservatively
correct) and then use whatever means (read: eventually to be invented)
to avoid the alias code from deriving bogus assumptions.  One "mean" is
to use a non-pointer IV, but that only works for non-mem uses (a TMR
with a NULL TMR_BASE is not valid).
>From gcc-bugs-return-438082-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Dec 19 10:02:55 2013
Return-Path: <gcc-bugs-return-438082-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20578 invoked by alias); 19 Dec 2013 10:02:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20507 invoked by uid 48); 19 Dec 2013 10:02:50 -0000
From: "philipp at marek dot priv.at" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
Date: Thu, 19 Dec 2013 10:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.4.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: philipp at marek dot priv.at
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-40635-4-6BGbtRvn5A@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-40635-4@http.gcc.gnu.org/bugzilla/>
References: <bug-40635-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01737.txt.bz2
Content-length: 650

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635

philipp at marek dot priv.at changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |philipp at marek dot priv.at

--- Comment #4 from philipp at marek dot priv.at ---
I have this or a very similar problem with debian amd64 4:4.8.2-1:

main.c: In function ‘main’:
main.c:1231:23: error: ‘rv’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
  return (rv_main >= 0 && rv_main < 0x70) ? rv_main : 1;
>From gcc-bugs-return-438083-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Dec 19 10:05:10 2013
Return-Path: <gcc-bugs-return-438083-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21969 invoked by alias); 19 Dec 2013 10:05:09 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21936 invoked by uid 48); 19 Dec 2013 10:05:05 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/59545] Signed integer overflow issues
Date: Thu, 19 Dec 2013 10:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-59545-4-If4m3H8W5X@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59545-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59545-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01738.txt.bz2
Content-length: 14014

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY545

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
FWIW here's the list issues clang catches on r206105:

gcc/combine.c:11867:14: runtime error: left shift of negative value -4096
gcc/config/i386/i386.c:21805:37: runtime error: left shift of negative value
-1073807360
gcc/config/i386/i386.c:21805:37: runtime error: left shift of negative value
-65537
gcc/config/i386/i386.c:21805:44: runtime error: left shift of negative value
-140739635838976
gcc/config/i386/i386.c:21805:44: runtime error: left shift of negative value
-2305983746702049280
gcc/cp/error.c:448:7: runtime error: call to function
pp_cxx_type_specifier_seq(cxx_pretty_printer*, tree_node*) through pointer to
incorrect function type 'void (*)(c_pretty
_printer *, tree_node *)'
gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 +
9223372036854775807 cannot be represented in type 'long'
gcc/dce.c:278:16: runtime error: left shift of negative value -1
gcc/double-int.c:141:13: runtime error: negation of -9223372036854775808 cannot
be represented in type 'long'; cast to an unsigned type to negate this value to
itself
gcc/dwarf2out.c:11516:61: runtime error: left shift of negative value -1
gcc/dwarf2out.c:11531:54: runtime error: left shift of negative value -1
gcc/expmed.c:2986:15: runtime error: left shift of negative value -1
gcc/expr.c:3986:17: runtime error: signed integer overflow: 0 -
-9223372036854775808 cannot be represented in type 'long'
gcc/genattrtab.c:622:27: runtime error: signed integer overflow: 4568797 * 613
cannot be represented in type 'int'
gcc/genautomata.c:3497:23: runtime error: shift exponent 64 is too large for
64-bit type 'set_el_t' (aka 'unsigned long')
gcc/ggc-common.c:133:7: runtime error: call to function gt_ggc_m_S(void const*)
through pointer to incorrect function type 'void (*)(void *)'
gcc/ggc-common.c:501:2: runtime error: call to function gt_pch_n_S(void const*)
through pointer to incorrect function type 'void (*)(void *)'
gcc/haifa-sched.c:1160:24: runtime error: left shift of negative value -1
gcc/haifa-sched.c:1423:26: runtime error: left shift of negative value -1
gcc/ipa-split.c:1051:20: runtime error: load of value 100, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 108, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 116, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 124, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 12, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 132, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 140, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 156, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 164, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 172, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 188, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 196, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 204, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 20, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 212, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 220, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 224, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 228, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 236, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 244, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 252, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 28, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 36, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 44, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 4, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 52, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 60, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 76, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 84, which is not a valid
value for type 'bool'
gcc/ipa-split.c:1051:20: runtime error: load of value 92, which is not a valid
value for type 'bool'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -128583990 *
811 cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 *
1000 cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 *
590 cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -17664042 *
500 cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -20495925 *
135 cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -262140400 *
125 cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -28163857 *
191 cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -33685247 * 90
cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -4095937 *
1000 cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -4190144 *
1023 cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -6373278 * 389
cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -8191875 * 500
cannot be represented in type 'int'
gcc/ira-color.c:1508:29: runtime error: signed integer overflow: -8847224 * 270
cannot be represented in type 'int'
gcc/passes.c:1627:8: runtime error: call to function
execute_pass_list(opt_pass*) through pointer to incorrect function type 'void
(*)(void *)'
gcc/postreload.c:1769:44: runtime error: signed integer overflow: 0 -
-9223372036854775808 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
105553116266496 - -9223372036854775808 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow: 11 -
-9223372036854775808 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow: 20 -
-9223372036854775808 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
4611123068473966592 - -9223090561878065153 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
4611404543450677248 - -9223372036854775808 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
7378697629483820646 - -1844674407370955162 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
-8446744073709551617 - 999999999999999999 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
8646911284551352320 - -9223372036854775808 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
-9223090561878065152 - 9223090561878065151 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
-9223372036854775784 - 9223372036854775800 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
9223372036854775807 - -281474976710656 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
9223372036854775807 - -9223090561878065153 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
9223372036854775807 - -9223372036854775808 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
-9223372036854775808 - 8935141660703064064 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
-9223372036854775808 - 9223372036854775807 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
999999999999999 - -9223372036854775808 cannot be represented in type 'long'
gcc/postreload.c:1769:44: runtime error: signed integer overflow:
9999999999999999 - -9223372036854775808 cannot be represented in type 'long'
gcc/real.c:2812:25: runtime error: left shift of negative value -1
gcc/real.c:2812:25: runtime error: left shift of negative value -102
gcc/real.c:2812:25: runtime error: left shift of negative value -1021
gcc/real.c:2812:25: runtime error: left shift of negative value -111
gcc/real.c:2812:25: runtime error: left shift of negative value -113
gcc/real.c:2812:25: runtime error: left shift of negative value -114
gcc/real.c:2812:25: runtime error: left shift of negative value -16277
gcc/real.c:2812:25: runtime error: left shift of negative value -16381
gcc/real.c:2812:25: runtime error: left shift of negative value -19
gcc/real.c:2812:25: runtime error: left shift of negative value -2
gcc/real.c:2812:25: runtime error: left shift of negative value -21
gcc/real.c:2812:25: runtime error: left shift of negative value -225
gcc/real.c:2812:25: runtime error: left shift of negative value -23
gcc/real.c:2812:25: runtime error: left shift of negative value -3
gcc/real.c:2812:25: runtime error: left shift of negative value -30
gcc/real.c:2812:25: runtime error: left shift of negative value -31
gcc/real.c:2812:25: runtime error: left shift of negative value -44
gcc/real.c:2812:25: runtime error: left shift of negative value -48
gcc/real.c:2812:25: runtime error: left shift of negative value -54
gcc/real.c:2812:25: runtime error: left shift of negative value -59
gcc/real.c:2812:25: runtime error: left shift of negative value -6
gcc/real.c:2812:25: runtime error: left shift of negative value -63
gcc/real.c:2812:25: runtime error: left shift of negative value -9
gcc/sched-deps.c:110:20: runtime error: left shift of negative value -1
gcc/simplify-rtx.c:1650:10: runtime error: negation of -9223372036854775808
cannot be represented in type 'long'; cast to an unsigned type to negate this
value to itself
gcc/simplify-rtx.c:4120:16: runtime error: signed integer overflow:
-1844674407370955161 + -9223372036854775808 cannot be represented in type
'long'
gcc/simplify-rtx.c:4124:16: runtime error: signed integer overflow:
1844674407370955161 - -9223372036854775808 cannot be represented in type 'long'
gcc/simplify-rtx.c:4128:16: runtime error: signed integer overflow: 3 *
-6148914691236517205 cannot be represented in type 'long'
gcc/stor-layout.c:2524:45: runtime error: signed integer overflow:
-9223372036854775808 - 1 cannot be represented in type 'long'
gcc/stor-layout.c:2537:34: runtime error: left shift of negative value -1
gcc/stor-layout.c:2539:5: runtime error: left shift of negative value -1
libcpp/files.c:675:30: runtime error: left shift of negative value -1
libcpp/symtab.c:235:6: runtime error: call to function count_defs(cpp_reader*,
cpp_hashnode*, void*) through pointer to incorrect function type 'int
(*)(cpp_reader *, ht_iden
tifier *, const void *)'
libcpp/symtab.c:235:6: runtime error: call to function dump_macro(cpp_reader*,
cpp_hashnode*, void*) through pointer to incorrect function type 'int
(*)(cpp_reader *, ht_iden
tifier *, const void *)'
libcpp/symtab.c:235:6: runtime error: call to function save_idents(cpp_reader*,
cpp_hashnode*, void*) through pointer to incorrect function type 'int
(*)(cpp_reader *, ht_ide
ntifier *, const void *)'
libcpp/symtab.c:235:6: runtime error: call to function
undefine_macros(cpp_reader*, cpp_hashnode*, void*) through pointer to incorrect
function type 'int (*)(cpp_reader *, ht
_identifier *, const void *)'
libcpp/symtab.c:235:6: runtime error: call to function write_defs(cpp_reader*,
cpp_hashnode*, void*) through pointer to incorrect function type 'int
(*)(cpp_reader *, ht_iden
tifier *, const void *)'
libcpp/symtab.c:235:6: runtime error: call to function
write_macdef(cpp_reader*, cpp_hashnode*, void*) through pointer to incorrect
function type 'int (*)(cpp_reader *, ht_id
entifier *, const void *)'
../libiberty/md5.c:336:7: runtime error: load of misaligned address
0x7fff2f8e77da for type 'const md5_uint32' (aka 'const unsigned int'), which
requires 4 byte alignment
...
libiberty/md5.c:351:7: runtime error: load of misaligned address 0x7fffafc1d7f6
for type 'const md5_uint32' (aka 'const unsigned int'), which requires 4 byte
alignment
libiberty/regex.c:6970:11: runtime error: left shift of negative value -1
libiberty/regex.c:7165:4: runtime error: left shift of negative value -1

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amker at gcc dot gnu.org

--- Comment #21 from amker at gcc dot gnu.org ---
For the record, here are some findings for this issue.

1) It isn't well-defined in terms of C standard to do below transformation in
GCC:
     a) convert pointers to unsigned integers;
     b) do arithmetic computations on converted unsigned integers;
        like: (szietype)ptr1 - (sizetype)ptr2 - 1 + (sizetype)ptr2
     c) convert result integer back to pointer;
     d) access memory using the result pointer;

2) GCC may still generates such transformation.  As said it's too conservative
to follow C standard strictly in this aspect.

3) When doing such transformation, we need to guarantee TMR.base is derived
correctly.  Otherwise GCC's alias analysis would be confused and results in
wrong code.

4) The problem with IVOPT is the approach it takes to derive TMR.base. 
Firstly, it depends on iv_cand.base_object to derive correct base for TMR. 
This is why GCC skips candidate with base_object for any iv_use with different
base_object.

5) when approach in 4) fails, it falls back to primitive approach by simply
setting TMR.base to any pointer in the result address expression.  Of course,
it could be wrong.  This is why PR50955 is triggered in the first place.

With these understandings, I can see two possible fixes here.

Fix 1) Just like Richard has committed, we not only check different base_object
on address type iv_uses, but also on generic type iv_uses.  This is too
conservative and we need to resolve performance regressions reported in
PR52272.

Fix 2) We need to improve how TMR.base is derived in IVOPTs.  New approach is
instead of iv_cand.base_object, we can use iv_use.base_object.  That is, check
the result address expression to see if it includes iv_use.base_object.  If
yes, we can set TMR.base to it; otherwise we can reject the iv_cand.  (actually
we can create a temp ssa_var with iv_use.base_object's pointer information
copied)

There is one concern about Fix 2).  The get_computation_cost_at needs to be
re-implemented to compute the result address expression like
get_computation_aff does.

Also Fix 2) doesn't give more benefit comparing to proposal patch in PR52272. 
Though that proposal has its own problem.