Re: VM-related Oops: 2.4.15pre1

Alan Cox (alan@lxorguk.ukuu.org.uk)
Mon, 19 Nov 2001 10:15:14 +0000 (GMT)


> There's no point being a language lawyer and saying that gcc "could write
> anything to value before it writes the final 2". Tha's not true. A compile
> rthat does that is
>
> (a) buggy as hell from a POSIX standpoint

It would mean someone misdefined sig_atomic_t if it broke for assignment

> And yes, the argument for "page->flags" is _exactly_ the same. Writing
> intermediate values to "page->flags" that were never referenced by the
> programmer is clearly such a violation of QoI that it is a bug even if
> "sig_atomic_t" happens to be "int", and "page->flags" happens to be
> "unsigned int".

If the code execution path is faster why shouldnt the compiler generate
those patterns. You haven't told the variable that its volatile. Therefore
the compiler is supposed to be optimising it.

You can in theory get even stranger effects. Consider

if(!(flag&4))
{
blahblah++;
flag|=4;
}

The compiler is completely at liberty to turn that into

test bit 2
jz 1f
inc blahblah
add #4, flag
1f:

because it knows the bit was clear and it knows the variable is not
volatile.

Having your own personal custom language dialect might be tempting but it is
normally something only the lisp community do.

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/