On Tue, Jul 5, 2011 at 7:30 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > 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
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.
