On Thu, Aug 20, 2009 at 2:33 AM, Jeff Lawl...@redhat.com wrote:
On 08/19/09 17:46, Ian Lance Taylor wrote:
My understanding is that that scenario is supposed to not happen because
update_equiv_regs is only supposed to equate a register and a memory
location in the specific cases where that is
On 08/19/09 18:48, Ian Lance Taylor wrote:
Jeff Lawl...@redhat.com writes:
You're right. This should have been rejected by validate_equiv_mem,
but isn't because the two memory references are in different alias
sets.
You can see this in the mainline sources configured for
On 08/20/09 02:45, Richard Guenther wrote:
It looks indeed bogus. Do you have a testcase at hand?
Compile the attached testcase with -O3 -mopenmp on i686-pc-linux-gnu.
Find MAIN__.omp_fn.2 in the .expand dump.
Within that function, you're looking for this sequence of insns:
;;
On Thu, Aug 20, 2009 at 3:37 PM, Jeff Lawl...@redhat.com wrote:
On 08/20/09 02:45, Richard Guenther wrote:
It looks indeed bogus. Do you have a testcase at hand?
Compile the attached testcase with -O3 -mopenmp on i686-pc-linux-gnu. Find
MAIN__.omp_fn.2 in the .expand dump.
Within that
Somehow I can't help but think I'm missing something here...
Given:
(set (reg X) (mem Y))
(...)
(set (mem Y) (reg Z))
(...)
(use (reg X))
update_equiv_regs can set an equivalence between (reg X) and (mem Y)
which is clearly wrong as (mem Y) is set to (reg Z).
99.99% of the
Jeff Law l...@redhat.com writes:
Somehow I can't help but think I'm missing something here...
Given:
(set (reg X) (mem Y))
(...)
(set (mem Y) (reg Z))
(...)
(use (reg X))
update_equiv_regs can set an equivalence between (reg X) and (mem Y)
which is clearly wrong as
On 08/19/09 17:46, Ian Lance Taylor wrote:
My understanding is that that scenario is supposed to not happen because
update_equiv_regs is only supposed to equate a register and a memory
location in the specific cases where that is OK. It's not no_equiv that
is supposed to fix this, the
Jeff Law l...@redhat.com writes:
You're right. This should have been rejected by validate_equiv_mem,
but isn't because the two memory references are in different alias
sets.
You can see this in the mainline sources configured for
i686-pc-linux-gnu by compiling
