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

[Alan Cox]

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