Regression of alias analysis in egcs-971225

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Hi John,

Earlier I wrote about a regression with respect to alias analysis  
in the 971225 snapshot of egcs.

I did some more digging into it and came up with what probably is  
the smallest example still showing the symptoms:

      subroutine simple(a,b,n)
      implicit none
      integer i, n
      real a(n),b(n)
      do i = 1, n
         a(i) = b(n-i+1)
      enddo
      end

The compilers' challenge here is to notice that n is a  
loop-invariant (and hence b(n-i+1) a giv) despite the store into a.

Subsequently, I ran this with f771 through the debugger with a  
breakpoint on alias.c:589 (the point in base_alias_check where it is  
decided to proclaim "no dependence" based on the Fortran rules of  
aliasing), and lo and behold - it hit three times, but only for cse  
...  IOW, during strength reduction it either didn't care to check,  
or base_alias_check didn't trigger in this case.

This has worked in the past (before your latest changes) - do you  
have an idea what's going wrong ?

Regards,
Toon.

(gdb) list alias.c:580
575         }
576
577       /* If one address is a stack reference there can be no alias:
578          stack references using different base registers do not  
alias,
579          a stack reference can not alias a parameter, and a  
stack reference
580          can not alias a global.  */
581       if ((GET_CODE (x_base) == ADDRESS && GET_MODE (x_base) ==  
Pmode)
582           || (GET_CODE (y_base) == ADDRESS && GET_MODE (y_base)  
== Pmode))
583         return 0;
584
(gdb) l
585       if (! flag_argument_noalias)
586         return 1;
587
588       if (flag_argument_noalias > 1)
589         return 0;
590
591       /* Weak noalias assertion (arguments are distinct, but  
may match globals). */
592       return ! (GET_MODE (x_base) == VOIDmode && GET_MODE  
(y_base) == VOIDmode);
593     }