Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Jul 5, 2011 at 7:30 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Jul 5, 2011 at 4:25 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Jul 5, 2011 at 7:15 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> Ping.
>>>
>>> That doesn't look correct without also ensuring we never create a
>>> TARGET_MEM_REF with a base that is not in the default address-space.
>>> In fact, with this patch the address-space argument to addr_for_mem_ref
>>> should go away or we need a hook that provides a non-promoted mode
>>> for address-spaces.
>>>
>>> Uli?
>>>
>>> HJ? ?What testcase does this fix? ?Please add it at least.
>>
>> There are many failures in gcc and glibc builds/tests. ?But
>> they only show up on x32 target. ?There is a simple one at
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47383
>>
>>> That said, this patch seems to paper over a problem that exists elsewhere.
>>
>> This patch tries to deal with MEM_REF which only works in ptr_mode.
>
> TARGET_MEM_REF you mean.
>
> How did it work for other ptr_mode != Pmode targets sofar? ?Why do
> you think it "doesn't work" for you? ?It's definitely the case that

I think x32 is the only zero-extend ptr_mode != Pmode target.

> it assumes to compute (Pmode)((ptr_mode)TMR_BASE + (ptr_mode)TMR_INDEX)
> as address. ?But disregarding the address-space compeltely looks bogus.
> I think you need to convert the result to the proper address-space mode.
>

I will give it a try.

Thanks.

-- 
H.J.