Messages in this thread | | | Date | Tue, 16 Nov 2010 00:07:31 +0100 | Subject | Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? | From | Richard Guenther <> |
| |
On Mon, Nov 15, 2010 at 11:58 PM, Jeff Law <law@redhat.com> wrote: > On 11/15/10 15:07, Richard Guenther wrote: >> >> On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law<law@redhat.com> wrote: >>> >>> On 11/08/10 03:49, Richard Guenther wrote: >>>> >>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<andi@firstfloor.org> >>>> wrote: >>>>> >>>>> Andreas Schwab<schwab@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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |