On Sun, 10 Apr 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.... :-) No, the behaviour is undefined. The compiler can do anything. gcc now emits a warning even with -O0. A similar example with "double a;" is more interesting. This also gives undefined behaviour (C99 6.5.5[#5]). However, this is bogus if there is a floating point infinity. C99 has support for IEEE floating point and it is clearly intended that the behaviour of 1.0/0.0 is to give +Inf and raise the divide-by-zero exception, but I couldn't see anywhere in the C99 draft n869.txt where this is spelled out (raising of the divide-by-zero exception is spelled out for lots of math functions but doesn't seem to be mentioned for plain division). Also, in C99 with IEEE FP support, "#pragma STDC FENV_ACCESS *" should affect the behaviour. I'm not sure of the details, but think that programs can only depend on getting the divide-by-zero exception if FENV_ACCESS is ON. gcc still doesn't support this pragma, so it does several wrong things with FENV_ACCESS ON: - for "a = 1.0 / 0.0;", it evaluates 1.0 / 0.0 at compile time (even with -O0) so it never raises a divide-by-zero exception. - "a /= 0.0;" where "a" is not otherwise used is not dead code, since it should have the side effect of raising the exception, but gcc considers this code to be dead. BruceReceived on Sun Apr 10 2005 - 15:55:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:31 UTC