Bug 17679 - [4.0 Regression] Aliasing problem with ivopts
Summary: [4.0 Regression] Aliasing problem with ivopts
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.0.0
: P2 critical
Target Milestone: 4.0.0
Assignee: Zdenek Dvorak
URL:
Keywords: alias, wrong-code
Depends on:
Blocks:
 
Reported: 2004-09-26 15:55 UTC by Zdenek Dvorak
Modified: 2004-11-27 20:32 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2004-09-28 11:37:15


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zdenek Dvorak 2004-09-26 15:55:35 UTC
The following testcase is misscompiled with -O2 -ftree-loop-ivcanon.  The
reason is that ivopts rewrite the first loop into (equivalent of)

b[0] = 1;
b[1] = 2;
b[2] = 3;
for (tmp = &a, cnt = 3; cnt != 0; tmp += 4B, cnt--)
  if (*tmp != *(tmp - &a + &b))
    { puts ("ERR 1"); break; }

Rtl alias analysis concludes that "a" is base for the register in that
(tmp - &a + &b) is computed.  Store motion than decides that the stores
to "b" before the loop are not used inside loop and moves them after the loop,
thus causing the error.

Reason for this behavior is that the code above is illegal in C (you cannot
take difference of two different arrays).  However ivopts needs to produce
this type of expressions.

int a[3] = {1,2,3};
int c[3] = {4,5,6};

int main(void)
{
  int b[3];
  int i;

  b[0] = 1;
  b[1] = 2;
  b[2] = 3;

  for (i = 0; i < 3; i++)
    if (a[i] != b[i])
      {
        puts ("ERR 1");
        break;
      }

  b[0] = 4;
  b[1] = 5;
  b[2] = 6;

  for (i = 0; i < 3; i++)
    if (c[i] != b[i])
      {
        puts ("ERR 2");
        break;
      }

  return 0;
}
Comment 1 Andrew Pinski 2004-09-26 17:24:50 UTC
As I said in another bug, this really should not be done with the subtraction at all, on PPC at least it is 
better to have different IV's for the arrays.
Comment 2 Zdenek Dvorak 2004-09-26 17:29:39 UTC
Does not ICE
Comment 3 Andrew Pinski 2004-09-26 17:32:51 UTC
wrong keyword, woops :).
Comment 4 Zdenek Dvorak 2004-09-26 17:33:51 UTC
Subject: Re:  [4.0 Regression] Aliasing problem with ivopts

Hello,

> As I said in another bug, this really should not be done with the
> subtraction at all, on PPC at least it is better to have different
> IV's for the arrays.

I do not think the memory reference would get expressed in this way on
PPC (if it does, it is a bug in cost function for ivopts and please
create a bugreport for it).  However on i686 this seems to be the best
option, taking the register pressure into account.

Zdenek
Comment 5 Zdenek Dvorak 2004-09-28 09:34:40 UTC
Patch:

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02849.html
Comment 6 Andrew Pinski 2004-09-28 11:37:15 UTC
Confirmed.
Comment 7 Andrew Pinski 2004-10-18 03:55:54 UTC
Zdenek are you going to apply the patch, it has been approved?
Comment 8 Zdenek Dvorak 2004-10-18 06:46:41 UTC
Subject: Re:  [4.0 Regression] Aliasing problem with ivopts

> Zdenek are you going to apply the patch, it has been approved?

the patch was approved, but after thinking about it more, I noted that
it works by pure luck only, and that the fix for find_base_value
would need to be more complicated.

However in the meantime the patch to prevent ivopts from producing the
type of expressions that caused the problem was commited, so the PR
should no longer reproduce.

Zdenek
Comment 9 Andrew Pinski 2004-11-27 00:04:27 UTC
Then should we close this bug as fixed or at least move it from being a 4.0 regression?
Comment 10 Giovanni Bajo 2004-11-27 20:09:54 UTC
Zdenek, can you check if this bug still makes sense or close it if it does not 
reproduce anymore? You are the one that knows if there is still an underlying 
problem to fix or not.
Comment 11 Zdenek Dvorak 2004-11-27 20:32:25 UTC
The code in find_base_value very likely is not entirely OK, but I do not know 
about a way how it could cause problems with just the currently used 
optimizations.  Since this code will disappear once we start using results of 
tree alias analysis at rtl level, I think we can consider the bug fixed.