RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

[Uros Bizjak]

On Fri, Oct 10, 2014 at 8:37 PM, Uros Bizjak <ubizjak@gmail.com> wrote:

>> Right.  And my question is what happens if we aren't as aggressive here.
>> What happens if before this check we return nonzero if X or Y is a VALUE?
>> Do we then get into memrefs_conflict_p and does it do the right thing?
>
> Following patch just after AND detection in base_alias_check fixes the
> testcase from PR:
>
> --cut here--
> Index: alias.c
> ===================================================================
> --- alias.c     (revision 216100)
> +++ alias.c     (working copy)
> @@ -1842,6 +1842,8 @@ base_alias_check (rtx x, rtx x_base, rtx y, rtx y_
>           || (int) GET_MODE_UNIT_SIZE (x_mode) < -INTVAL (XEXP (y, 1))))
>      return 1;
>
> +  return 1;
> +
>    /* Differing symbols not accessed via AND never alias.  */
>    if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS)
>      return 0;
> --cut here--
>
> I have started a bootstrap on alpha native with this patch (it will
> take a day or so) and will report back findings

Yes, this "patch" solves the original gfortran problem.

It looks to me that the code that handles AND addresses in
base_alias_check is not prepared to handle VALUES correctly.

Uros.