lkml.org 
[lkml]   [2001]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: VM-related Oops: 2.4.15pre1
On Sat, Nov 17, 2001 at 11:31:15PM -0800, Linus Torvalds wrote:
> No. It would be a _gcc_ bug if gcc did things to "page->flags" that the
> code did not ask it to do. And that is _regardless_ of any notions of
> "strictly conforming C code". The fact is, that if gcc were to clear a
> bit that the code never clears, that is a HUGE AND GAPING GCC BUG.

I see what you mean of course (the usual problem is that we never know
if gcc could make such decision for whatever subtle optimization, asm
optimizations are all but intuitional). But I just giveup also about the
other thing of reading from C variables that can change under us. So I'm ok
assuming gcc does what we expect here too, even if I'd prefer not to.

> The fact is, if we write code that leaves a certain bit unmodified, gcc
> MUST NOT modify that bit. If gcc generated code that temporarily
> modifies the bit, I can show user-level code that would break with
> signals. See "sig_atomic_t" and friends - the compiler simply _has_ to
> guarantee that the semantics you write in C code are actually upheld.

There should be proper macros to handle those userspace sig_atomic_t
because of that. Anyways I certainly believe there is code playing with
those types from C by hand :).

Andrea
-
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.707 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site