This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?
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
>