From owner-freebsd-bugs Sat May 13 01:17:21 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA09033 for bugs-outgoing; Sat, 13 May 1995 01:17:21 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA09017 for ; Sat, 13 May 1995 01:17:13 -0700 Received: by pelican.com (Smail3.1.28.1 #5) id m0sACNm-000K2iC; Sat, 13 May 95 01:17 WET DST Message-Id: 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 In-Reply-To: <199505120932.TAA20816@godzilla.zeta.org.au> Organization: Pelican Consulting Sender: bugs-owner@FreeBSD.org Precedence: bulk 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