This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 14 Oct 2014 09:12:52 +0200
- Subject: Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4ZJwrxFjcHBDgg=zzztQXxSmA3_OjjmkGhYKfEppZ2cxQ at mail dot gmail dot com> <54381DCA dot 10805 at redhat dot com> <CAFULd4aUpzoakgaRkGP24Yy5KV2Le9iQgDM_7bWoX79yfMOTdg at mail dot gmail dot com> <543822E3 dot 60801 at redhat dot com> <CAFULd4YzSnXMENw_Ycb-5QnKd8rRxLXVDwcG4RrhL-uFJEQv=w at mail dot gmail dot com> <CAFULd4Z1bJCqYiwbVpv8uE1BzdGCXgd+OoKZfV3TA=QfEG0=DA at mail dot gmail dot com>
On Sun, Oct 12, 2014 at 7:44 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:
[...]
> It looks to me that the code that handles AND addresses in
> base_alias_check is not prepared to handle VALUES correctly.
The further analysis and proposed patch follows up at [1].
[1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01209.html
Uros.