On Mon, Nov 15, 2010 at 11:58 PM, Jeff Law <l...@redhat.com> wrote: > On 11/15/10 15:07, Richard Guenther wrote: >> >> On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law<l...@redhat.com> wrote: >>> >>> On 11/08/10 03:49, Richard Guenther wrote: >>>> >>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<a...@firstfloor.org> >>>> wrote: >>>>> >>>>> Andreas Schwab<sch...@linux-m68k.org> writes: >>>>>> >>>>>> The asm fails to mention that it modifies *regs. >>>>> >>>>> It has a memory clobber, that should be enough, no? >>>> >>>> No. A memory clobber does not cover automatic storage. >>> >>> A memory clobber should clobber anything in memory, including autos in >>> memory; if it doesn't, then that seems like a major problem. I'd like to >>> see the rationale behind not clobbering autos in memory. >> >> Non-address taken automatic storage. (note that we don't excercise this >> in optimization yet) > > If the address of the auto isn't taken, then why is the object in memory to > begin with (with the obvious exception for aggregates).
Exactly sort of my point. If people pass the address of &x to an asm and modify &x + 8 expecting the "adjacent" stack location to be changed I want to tell them that's not a supported way to get to another stack variable (even if they clobber "memory"). Or consider the C-decl guy who wants to access adjacent parameters by address arithmetic on the address of the first param ... Richard. > Jeff >
