From owner-freebsd-bugs Sat May 13 01:59:53 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA12334 for bugs-outgoing; Sat, 13 May 1995 01:59:53 -0700 Received: from netcom19.netcom.com (bakul@netcom19.netcom.com [192.100.81.132]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA12324 for ; Sat, 13 May 1995 01:59:50 -0700 Received: from localhost by netcom19.netcom.com (8.6.12/Netcom) id BAA28730; Sat, 13 May 1995 01:59:31 -0700 Message-Id: <199505130859.BAA28730@netcom19.netcom.com> To: bugs@FreeBSD.org Subject: Re: i386/395: CRITICAL PROBLEM: spl functions implemented incorrectly In-reply-to: Your message of "Sat, 13 May 95 01:17:00 +0700." Date: Sat, 13 May 95 01:59:30 -0700 From: Bakul Shah Sender: bugs-owner@FreeBSD.org Precedence: bulk Bruce Evans wrote: >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. Except that w.r.t. volatile the compiler has *no* way of knowing the side effects of external entities. The original intent of volatilve was precisely for preventing such `optimizations'. A more reasonable notation would've been _shared_ instead of _volatile_. It is easy to see that a shared variable can change behind your back. Unfortunately, `shared' nowadays connotes something much more specific. I agree with the rest of what Bruce said. This is why in general hiding things away in a function is not safe enough (though, usually, in practise it is). Making driver globals etc. volatile is the way to go (this problem has already been encountered and solved in a similar way by a number of commercial systems, especially multi- processor ones). This seems to work because a compiler must not reorder volatile accesses w.r.t. *other* volatile accesses and it must not optimize away such references. Though, I don't know if gcc handles them right in all cases. If you want to temporarily lose volatility for performance (and where you know this is safe), you can manually copy such values to registers or perhaps, typecasting will work. Pete Carah wrote: > To make global optimizers safe in the presence of *any* non-memory > side effects (I/O) one needs function-attribute flags in the library I think GNU extension of volatile attribute for a function deals with this well, when used with an asm() `function'. --bakul