From owner-freebsd-bugs Mon May 22 04:32:45 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA22406 for bugs-outgoing; Mon, 22 May 1995 04:32:45 -0700 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id EAA22400 ; Mon, 22 May 1995 04:32:38 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA26415 (5.65c8/HUTCS-S 1.4); Mon, 22 May 1995 14:32:09 +0300 Received: (ylo@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id OAA18301; Mon, 22 May 1995 14:32:10 +0300 Date: Mon, 22 May 1995 14:32:10 +0300 Message-Id: <199505221132.OAA18301@shadows.cs.hut.fi> From: Tatu Ylonen To: davidg@freefall.cdrom.com Cc: freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505220956.CAA19666@freefall.cdrom.com> (davidg@freefall.cdrom.com) Subject: Re: Changed information for PR i386/395 Organization: Helsinki University of Technology, Finland Sender: bugs-owner@FreeBSD.org Precedence: bulk > Bruce says that gcc's behavior for inlined functions isn't any > different than it is for real functions WRT caching of variables > or intermediates...and an analysis of the generated code seems > to confirm this. It appears to be a non-problem with the current > gcc. Well, code like ... some code using variable/expression foo ... x = spl*(); ... more code using variable/expression foo ... does not recompute foo if spl* is an inline function, and does recompute it if it is not (because then the function might have unknown side-effects changing foo). While I am not sure if spl functions are really used in a way that this would cause problems, I think it would be much safer to eliminate this possibility of erroneus (or at least very unexpected) code. The problem does not appear to be as severe with current compilers and standardized semantics as I thought, but in my opinion there still is a problem. There is a simple way to play safe; I wouldn't consider the current code that safe. Tatu Ylonen