RE: [PATCH] fixes for building kernel 2.5.45 using Intel compiler

From: Alan Cox (alan@lxorguk.ukuu.org.uk)
Date: Thu Oct 31 2002 - 14:13:37 EST


On Thu, 2002-10-31 at 16:37, Nakajima, Jun wrote:
> > Why is this needed ?
>
> Becaues the compiler optimization removes the following code without it.
> regs->eflags = (regs->eflags & 0xffffcfff) | (level << 12);
>
> The compiler provides access to the argument 'unused' in the stack
> (asmlinkage,
> i.e. __attribute__ ((regparm(0))), but it thinks modifying the stack
> more than that is not effective anyway. So it elimites the code under
> optimizations.

The compiler at function entry cannot know anything about the scope of
objects above the return address. It could equally be a valid pointer to
data above the stack with a global context created by a thread library.

I'm curious if the optimisation is actually legal

> > > - IGNLABEL "HmacRxUc",
> > > - IGNLABEL "HmacRxDiscard",
> > > - IGNLABEL "HmacRxAccepted",
> > > + IGNLABEL /* "HmacTxMc", */
> > > + IGNLABEL /* "HmacTxBc", */
> >
> > You seem to be removing fields from the struct - have you
> > tested this ?
> >
> No, it's not removing fields from there. The original definition of IGNLABLE
> is
> #define IGNLABEL 0&(int)
> And
> IGNLABEL "HmacRxUc",
> simpile ends up 0, (in gcc). But this is just causing (a lot of) warnings,
> so I take this out.

You removed the comma in the patch above its gone from IGNLABEL foo, to
IGNLABEL foo. I don't see where your comma is coming back from.
Otherwise I've no problem (although maybe IGNLABEL("HmacRxAccepted")
would be neater since it conveniently lets people put them back.

Alan

-
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/



This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:55 EST