lkml.org 
[lkml]   [2001]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.055 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site