Date: Sun, 10 Apr 2005 13:49:38 -0400 From: David Schultz <das@FreeBSD.ORG> To: Chuck Swiger <cswiger@mac.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 Message-ID: <20050410174938.GA4842@VARK.MIT.EDU> In-Reply-To: <42595E04.60705@mac.com> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com> <20050410082945.H66651@bowser.eecs.harvard.edu> <42595E04.60705@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 10, 2005, Chuck Swiger wrote:
> Daniel Ellard wrote:
> >On Sun, 10 Apr 2005, Dimitry Andric wrote:
> [ ... ]
> >At least the gcc folk now do detect this old chestnut:
> >
> > {
> > int a;
> >
> > a /= 0;
> > }
> >
> >which was used to provoke arguments in compiler
> >classes for many years. (Optimized, nothing happens.
> >Unoptimized, a division-by-zero error happens...)
>
> Great example.
>
> If the optimized code fails to generate a division-by-zero error here, the
> optimizer is buggy. (I won't quote Aho, Sethi, and Ullman again.... :-)
gcc's optimizer is notoriously bad with side-effects like this,
particularly for floating-point code. The C99 standard requires
that the compiler support the FENV_ACCESS pragma to tell the
compiler that (among other things) it must not optimize away
arithmetic that may generate an exception as a side-effect, but
gcc doesn't implement it. Worse yet, gcc defaults to assuming
that it *is* allowed to optimize such arithmetic operations away,
even in expressions such as '1.0 / 0.0' where it's clear what the
programmer wanted to happen. A number of routines in libm don't
work properly at -O2 as a result of this, and in several places we
play tricks such as declaring variables to be volatile or 'long
double' just to trick the optimizer. IIRC, Steve Moshier wrote
some gcc patches to fix this, but nobody ever committed them...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050410174938.GA4842>