Messages in this thread | | | Date | Wed, 21 Nov 2001 02:31:37 +0000 | From | Pavel Machek <> | Subject | Re: VM-related Oops: 2.4.15pre1 |
| |
Hi!
> > Why is it a compiler bug. You've not declared that variable to be volatile > > therefore it is only touched in the code flow the compiler is analysing. > > Even without volatile, the compiler is very arguably buggy if it writes > values to your variables that were never supposed to be there. > > Take this, for example: > > sig_atomic_t value = 1; > > int fn() > { > value = 2; > } > > And a signal comes in. Even without the volatile, if gcc has written > _anything_ else than 1 or 2 into the variable, gcc is BROKEN.
imagine
typedef volatile int sig_atomic_t;
> 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 > (b) even apart from POSIX, from a Q-of-I standpoint complete and utter > crap.
Imagine this:
if (likely(foo)) c = 1 else c = 2
I could see it optimized as
c = 1 if (unlikely(foo)) c = 2
Given enough register pressure.... I've seen similar optimalizations proposed in "advanced compilers" book. Pavel PS: but wrapping access to current->flags in macro is probably okay for now. I just wanted to show that writing unwanted value is not as broken as you think.
-- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
- 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/
| |