From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17802 invoked by alias); 14 Jan 2014 17:22:27 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17497 invoked by uid 55); 14 Jan 2014 17:22:22 -0000 From: "nmm1 at cam dot ac.uk" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented) Date: Tue, 14 Jan 2014 17:22:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: nmm1 at cam dot ac.uk X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg01484.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #29 from Nick Maclaren --- On Jan 14 2014, vincent-gcc at vinc17 dot net wrote: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 > >> >The FENV_ACCESS pragma provides a means to inform the implementation whe >n a >> >program might access the floating-point environment to test floating-poi >nt >> >status flags or run under non-default floating-point control modes. > >> I suggest looking up the word "explicit" in a dictionary. > >The above is an explicit definition. Where do you see an undefined behavior >here? It is not an "explicit definition of BEHAVIOR" (my emphasis), and what it implies for any nnon-IEEE system is completely unclear. Of the two countries active during the standardisation of C99, one voted "no" on these grounds (among others). >Note that the C standard doesn't explicitly say how a source file as a sequ >ence >of bytes is to be interpreted as a sequence of character, so that if you ju >st > restrict to the C standard, everything is undefined. Yes, it does - it's implementation-defined in 5.1.1.2 Translation phases, paragraph 1.1: Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters for end-of-line indicators) if necessary. ... You imply that you are also relying on some other standards or specifications. ISO/IEC Directives Part II is quite clear (in 6.2.2) that they shall be referenced in the ISO standard. Which ones are you referring to and why? If you are claiming that C99 and beyond support only systems that conform to IEEE 754, then I can tell you that was not the intention of WG21 at the time and is not a requirement of the standard. To repeat, how many other such systems are you familiar with? The grounds that the UK voted "no" to this aspect was that the whole 'IEEE 754' morass (including "fenv.h") was neither dependent on __STD_IEC_559__ nor implementation-dependent nor sufficiently explicit to be interpreted on any non-IEEE system. > The discussion is going nowhere. Now, at least that is true. Regards, Nick Maclaren.