public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/58020] Code for handling IEEE exceptions Date: Tue, 05 Nov 2013 15:52:00 -0000 [thread overview] Message-ID: <bug-58020-4-dhGAAeMmEM@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-58020-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 Tobias Burnus <burnus at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus at gcc dot gnu.org --- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> --- (In reply to Francois-Xavier Coudert from comment #13) > I may have a bit of time in November and December to look at this. I > actually had started implementing the IEEE modules in gfortran back in > 2008-2009, but never got too far (I was unclear, back then, on the exact > requirements for things like constant folding… some interps have made clear > that our job is actually easier than I thought back then). One problem is that behaviour changes when a module is loaded. Related: - Similar issue in C/C++, cf. "#pragma STDC FENV_ACCESS ON" and also http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01131.html - Changes required for the new ISO/IEC/IEEE 60559:2011 standard (http://www.iso.org/iso/catalogue_detail.htm?csnumber=57469): http://j3-fortran.org/doc/year/13/13-356.txt > 2. Although you don't plan to support other architectures than i386/x86_64, > we have to think about it. I want to mention that there is now some additional support for IEEE in libgfortran/config. None of those functions is exported, yet - that permits to tweak their ABI. All work on x86 hardware, glibc, sysv (= Solaris, FreeBSD), AIX - which should cover most systems. a) Enable trapping: set_fpu (invalid, denormal, zero, overflow, underflow, inexact) [Used by -ffpe-trap=...] b) get_fpu_except_flags - returns which exception have been raised by the CPU. [New in 4.9; used to print those with STOP/ERROR STOP; -ffpe-summary=...] c) set_fpu_rounding_mode/get_fpu_rounding_mode [New in 4.9; used for I/O rounding on *input*, only works with "atoi"s which honour the rounding mode, such as very recent GLIBCs.] - Note that Fortran's required rounding mode "compatible" is not supported ("nearest" comes close but has different results for a tie). >From gcc-bugs-return-433626-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 05 16:02:19 2013 Return-Path: <gcc-bugs-return-433626-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 32106 invoked by alias); 5 Nov 2013 16:02:19 -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 30754 invoked by uid 48); 5 Nov 2013 16:00:17 -0000 From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/58020] Code for handling IEEE exceptions Date: Tue, 05 Nov 2013 16:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fxcoudert at gcc dot gnu.org 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: <bug-58020-4-0Ch7AnjadK@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-58020-4@http.gcc.gnu.org/bugzilla/> References: <bug-58020-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/msg00403.txt.bz2 Content-length: 1467 http://gcc.gnu.org/bugzilla/show_bug.cgi?idX020 --- Comment #17 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- (In reply to Tobias Burnus from comment #16) > I want to mention that there is now some additional support for IEEE in > libgfortran/config. Yes, I see that this has grown since I first introduced it (in 2005! it's a while back). That's good, and we can use this (possibly modified) interface to the hardware/OS-specific function calls. Another issue I wanted to get your opinion on, Tobias: we can't implement the IEEE modules fully on the library side, because of three things: 1. Changes in behavior when the modules are loaded: I'm not sure I understand the full extent of these changes. Comment #11 in PR29383 seems to imply that there are no such changes. 2. Some IEEE functions are allowed in constant or specification expressions, thus requiring front-end cooperation: IEEE_SELECTED_REAL_KIND is allowed in constant expressions; IEEE_SUPPORT_* functions are allowed in specification expressions. 3. Library-side implementation of some functions (IEEE_IS_NAN, to give only one example) will require a function call, while emitting code from the front-end (like we do for our own ISNAN) will not incur that penalty. However, for the rest of it, library-side implementation is easier. So, do you think we can implement the module in libgfortran, and add only minimal front-end tweaking to "catch" the necessary cases?
next prev parent reply other threads:[~2013-11-05 15:52 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-29 17:05 [Bug libfortran/58020] New: " fkrogh#gcc at mathalacarte dot com 2013-07-29 19:29 ` [Bug libfortran/58020] " kargl at gcc dot gnu.org 2013-07-29 21:03 ` fkrogh#gcc at mathalacarte dot com 2013-07-29 22:01 ` sgk at troutmask dot apl.washington.edu 2013-07-30 12:48 ` dominiq at lps dot ens.fr 2013-07-30 14:14 ` burnus at gcc dot gnu.org 2013-07-30 14:36 ` richard.koolhans at gmail dot com 2013-07-30 17:31 ` dominiq at lps dot ens.fr 2013-07-30 17:37 ` sgk at troutmask dot apl.washington.edu 2013-07-30 17:55 ` fkrogh#gcc at mathalacarte dot com 2013-07-31 17:27 ` richard.koolhans at gmail dot com 2013-08-01 13:00 ` dominiq at lps dot ens.fr 2013-08-01 15:51 ` richard.koolhans at gmail dot com 2013-11-05 13:56 ` fxcoudert at gcc dot gnu.org 2013-11-05 14:05 ` fkrogh at mathalacarte dot com 2013-11-05 14:08 ` fkrogh at mathalacarte dot com 2013-11-05 15:52 ` burnus at gcc dot gnu.org [this message] 2013-11-05 16:12 ` fxcoudert at gcc dot gnu.org 2013-11-05 16:27 ` sgk at troutmask dot apl.washington.edu 2013-11-05 16:37 ` fxcoudert at gcc dot gnu.org 2013-11-05 17:05 ` richard.koolhans at gmail dot com 2013-11-05 17:43 ` sgk at troutmask dot apl.washington.edu 2013-11-06 12:28 ` fxcoudert at gcc dot gnu.org 2013-11-25 0:59 ` kargl at gcc dot gnu.org 2014-06-07 10:19 ` fxcoudert at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-58020-4-dhGAAeMmEM@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).