[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

["nmm1 at cam dot ac.uk" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

--- Comment #23 from Nick Maclaren <nmm1 at cam dot ac.uk> ---
(In reply to Vincent Lefèvre from comment #21)
>
> > Richard Biener's approach to the default is the one that matches the C
> > standard and Vincent Lefèvre is mistaken.
> 
> No, I'm correct.
> 
> > Defining it to be 'off' and not setting __STDC_IEC_559__ is very reasonable.
> 
> No, this is really stupid. If the user *decides* to set the STDC FENV_ACCESS
> pragma to "on", then the compiler must not assume that it is "off" (this bug
> is not about the default state). At least it must behave in this way if
> -std=c99 (or c11) has been used. Otherwise a compilation failure may be
> better than getting wrong results.

If __STDC_IEC_559__ is unset or does not have the value 1, setting
STDC FENV_ACCESS to "on" is undefined behaviour (see 6.10.8.3, 7.6 and
Annex F), unless the implementation explicitly chooses to extend the
language to support it.  So the user would get what he so richly
deserves.


(In reply to joseph@codesourcery.com from comment #22)
> 
> So a key part of actually making rounding modes and exceptions work 
> reliably would be working out a definition of GCC's default mode that 
> allows more or less the same optimizations as at present, while allowing 
> users wanting the full support (and consequent optimization cost) to 
> specify the appropriate command-line options or FENV_ACCESS pragma to 
> enable it.

Yes.  That won't deal with the correctness problems of introducing
IEEE 754 support into code not set up to handle it, especially C++,
of course.  I tried to get WG21 to take a stand on that issue, but
failed :-(

Working out what on earth to do in such a case is likely to be a far
fouler task than merely dealing with the performance problems :-(
>From gcc-bugs-return-434297-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 11 17:35:55 2013
Return-Path: <gcc-bugs-return-434297-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28335 invoked by alias); 11 Nov 2013 17:35:55 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28226 invoked by uid 48); 11 Nov 2013 17:35:52 -0000
From: "tromey at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/59075] python pretty printer does not work at OS X
Date: Mon, 11 Nov 2013 17:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.6.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: tromey at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: <bug-59075-4-4XbkH44Mfs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59075-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59075-4@http.gcc.gnu.org/bugzilla/>
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: 2013-11/txt/msg01074.txt.bz2
Content-length: 674

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY075

--- Comment #2 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> Tom, do you know why this would be true on OS X?

Offhand I do not know.  I think there are a few things that
could help us find out, though.

One would be to see the gdb session.  This would tell us
which libstdc++ is being loaded.

Another would be to attach the executable to the bug,
assuming it is small enough (if too large -- write a minimal
reproducer and attach it).  Then I could look at the DWARF.

I'm also curious exactly what options were used to build
the executable.  This can matter sometimes.