On Tue, Jul 5, 2011 at 4:25 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Tue, Jul 5, 2011 at 7:15 AM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu <hjl.to...@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 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. Richard.
