Date: Sat, 13 May 95 01:17 WET DST From: pete@pelican.com (Pete Carah) To: bugs@FreeBSD.org Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly Message-ID: <m0sACNm-000K2iC@pelican.com> In-Reply-To: <199505120932.TAA20816@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199505120932.TAA20816@godzilla.zeta.org.au> bde writes: > .... >This makes optimizations harder but doesn't stop them. The linker is >allowed to do global optimizations. >The standard also allows entire expressions, function calls and even >accesses to volatile objects to be optimized away if it can be shown >that the side effects are not needed. This is the usual "as if" >rule explictly stated. I've seen *read()* reordered by one global optimizer... Talk about unsafe!! (a major workstation manufacturer under the -O3 option.) (this broke a video application because the serial I/O that moved a video disk pointer got moved around the code outputting the picture :-( I've given up -O3 entirely in that system. Apparently the compiler correctly noticed that the picture's memory and the command's memory didn't physically overlap, and presumed to optimize... (I haven't checked for a couple of years, now; the compiler is several major releases later and this *might* have been fixed. I don't count on it, though...) >The average device driver probably depends on non-reordering in many other >places, but probably has more bugs from not declaring enough variables as >volatile. The old V7 kernel (and later) had to be compiled without even -O... "volatile" was added to improve this. Note that volatile protects things from *any* other threads (e.g. co-routines in multiprocessors), not just interrupt handlers. To make global optimizers safe in the presence of *any* non-memory side effects (I/O) one needs function-attribute flags in the library that the linker and compiler can check. This is not generally possible by just examining memory references in machines with memory-mapped I/O (mips, 68k, even our 'ed0' card, etc). Such flags have to be manually set; this can be forgotten in the rush before code-freeze :-). Standards committees aren't perfect either: Remember that the ansi C committee, at one time, (in)conveniently forgot that floating point addition is _not_ associative when discussing allowable -Ox manipulations, and was going to explicitly allow reordering of such even in the presence of ()... (the actual standard's wording did say "commutative, associative operators"; the examples made it obvious that the committee people weren't used to numerical analysis...) -- Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0sACNm-000K2iC>