From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7270 invoked by alias); 23 Sep 2006 21:41:39 -0000 Received: (qmail 7238 invoked by uid 48); 23 Sep 2006 21:41:32 -0000 Date: Sat, 23 Sep 2006 21:41:00 -0000 Message-ID: <20060923214132.7237.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c/29186] optimzation breaks floating point exception flag reading In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "kreckel at ginac dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-09/txt/msg02256.txt.bz2 List-Id: ------- Comment #5 from kreckel at ginac dot de 2006-09-23 21:41 ------- (In reply to comment #3) > So this is not a bug except for the fact GCC does not implement "#pragma STDC > FENV_ACCESS " According to C99, 7.6.1, you are technically right. But still: an implementation that does not allow access to floating point flags irritates me. Couldn't that be outright dangerous, in certain circumstances? Consider a hypothetical train control unit: #define FE_CRITICAL (FE_DIVBYZERO|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW) double compute_speed(double measurement) { return -1./(measurement); // in reality, some rather hairy computation } // Adjusts speed towards nominal speed, given measurement of speed sensor. // May decelerate, in unforeseen cases. void control(double nominal_v, double measurement) { #pragma STDC FENV_ACCESS on feclearexcept(FE_CRITICAL); double v = compute_speed(measurement); if (fetestexcept(FE_CRITICAL)) { // Unexpected error: should not trust the computed speed. decelerate(); return; } if (v > nominal_v*1.001) { printf("v==%f\n",v); decelerate(); return; } if (v < nominal_v*0.999) { accelerate(); return; } } Would you board that train if the train control unit were compiled with GCC? The function decelerates the train if something unforeseen happens inside the speed computation. At least it did that when it was compiled with GCC 3.3.x, 3.4.x, or 4.0.x. Now, with GCC 4.1.x, all bets are off. Also, no compiler version seems to care to print a warning. Having the users lulled in a false sense of safety for so long, this changed behavior with a allusion to the standard ("we need not return something meaningful") strikes me as, excuse me, somewhat careless. Maybe somehone can provide other suggestions how to program defensively? In principle, the functionality used above (testing floating point flags) has been promised since two decades (it's IEEE 754) and has been implemented in almost every major hardware since as long. Can GNU-C not be used for such simple things? -- kreckel at ginac dot de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pinskia at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186