Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Richard Guenther]

On Mon, Nov 15, 2010 at 11:58 PM, Jeff Law <law@xxxxxxxxxx> wrote:
> On 11/15/10 15:07, Richard Guenther wrote:
>>
>> On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law<law@xxxxxxxxxx>  wrote:
>>>
>>> On 11/08/10 03:49, Richard Guenther wrote:
>>>>
>>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<andi@xxxxxxxxxxxxxx>
>>>>  wrote:
>>>>>
>>>>> Andreas Schwab<schwab@xxxxxxxxxxxxxx>    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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/