Bug 58020 - Code for handling IEEE exceptions
Summary: Code for handling IEEE exceptions
Status: RESOLVED DUPLICATE of bug 29383
Alias: None
Product: gcc
Classification: Unclassified
Component: libfortran (show other bugs)
Version: 4.8.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 59015
Blocks: 29383
  Show dependency treegraph
 
Reported: 2013-07-29 17:05 UTC by Fred Krogh
Modified: 2014-06-07 10:19 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-07-30 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred Krogh 2013-07-29 17:05:18 UTC
Dr. Richard Hanson has written code to provide IEEE exception handling to gfortran.  He is the sole owner of that code and it could be used by gcc as they wish.  The code is on my server at http://mathalacarte.com/hpcconsult
He can be contacted at richard.koolhans@gmail.com.  This feature is one of the oldest language features not available in gfortran, and can be a real impediment portability.
Comment 1 kargl 2013-07-29 19:29:12 UTC
1) Hanson needs to have a copyright assignment on file with FSF
   before the code can be used.

2) More importantly, the code appears to only support the i386
   and amd64 architectures.  gfortran runs are far more processors
   than these.

3) messy_m.f90 includes the statement:

   ! This code is free for noncommercial use as long as this source
   ! file is included.  It is recommended that the test file, tmessy
   ! be included as well.

   I haven't looked at the code to determine if messy_m.f90 is actually
   needed.
Comment 2 Fred Krogh 2013-07-29 21:03:53 UTC
1. Hanson is willing to assign the copyright if you expect to be using this work.  There were thoughts to include this work on a SIAM website where we think SIAM would want the copyright, but if gfortran wants to use this work it could be posted someplace that does not require copyright.  Perhaps you could provide a link that describe how this assignment can be done.  The SIAM publication is still work in progress and the package can be noted as copyrighted in accordance with your standards.

2. There are no plans to support other architectures.  The code is useful for the most prevalent one, and it is hoped would be useful there, as well as helpful to people interested in ports to other platforms.  The Fortran standard says it is ok to *not* implement the IEEE modules, but there should be a module present on non-x86 machines that indicates this lack of support.  Presently there is no support and no IEEE module of any kind.

3. The messy code is code I wrote, and is currently (I think) likely to be published in the Transactions on Mathematical Software.  That code is used only in the testing code and is not used in what should be considered the main submission.  It does nothing more that give pretty output of results.

Please let us know, if given the above, you have an interest in pursuing this further.
Fred
Comment 3 Steve Kargl 2013-07-29 22:01:48 UTC
On Mon, Jul 29, 2013 at 09:03:53PM +0000, fkrogh#gcc at mathalacarte dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
> 
> --- Comment #2 from Fred Krogh <fkrogh#gcc at mathalacarte dot com> ---
> 1. Hanson is willing to assign the copyright if you expect to be using this
> work.  There were thoughts to include this work on a SIAM website where we
> think SIAM would want the copyright, but if gfortran wants to use this work it
> could be posted someplace that does not require copyright.  Perhaps you could
> provide a link that describe how this assignment can be done.  The SIAM
> publication is still work in progress and the package can be noted as
> copyrighted in accordance with your standards.

Given your 2) below, I suspect that the code would not be used
within gfortran.  If the code appears on the SIAM site or some
other (semi-)permanent websire, then adding a link from the 
gfortran wiki under "Using gfortran" may be appropriate.

> 2. There are no plans to support other architectures.

The problem is that gfortran works on a large selection of
architectures.  We cannot simply pick to support i386/x86_64
and ignore all the others.  At the very least, IEEE_FEATURES
should report that IEEE 754 is not supported for these lesser
archs.

> The Fortran standard says it is ok to *not* implement the IEEE modules,

This is sort of true.

> but there should be a module present on non-x86 machines that indicates
> this lack of support.

This is not required by the standard.

> Presently there is no support and no IEEE module of any kind.

Yep, which is permitted by the standard.

The standard actually states:

"Whether the modules are provided is processor dependent."

> 3. The messy code is code I wrote, and is currently (I think) likely
>    to be published in the Transactions on Mathematical Software.  That
>    code is used only in the testing code and is not used in what should
>    be considered the main submission.  It does nothing more that give
>    pretty output of results.

Thanks for the clarification on the messy code.
Comment 4 Dominique d'Humieres 2013-07-30 12:48:41 UTC
I have tested the code at http://mathalacarte.com/hpcconsult (without reading it).
The files IEEE_ARITHMETIC.f90 and IEEE_tests_gfortran.f90 must be compiled with the -fno-range-check option (for the second file it triggers PR58027). On x86_64-apple-darwin10 the output differs from the one in 'list':

--- tmp	2013-07-30 12:33:24.000000000 +0200
+++ list	2013-07-25 21:27:02.000000000 +0200
@@ -77,7 +77,7 @@
 
  Double precision rounding mode IEEE_DOWN for \pi ~= 3.142 is < value with IEEE_UP.
 
- Double precision rounding mode IEEE_DOWN for \pi ~= 3.141 agrees with IEEE_TO_ZERO.
+ Double precision rounding mode IEEE_DOWN for \pi ~= 3.142 agrees with IEEE_TO_ZERO.
 
  Double precision a=IEEE_REM(4, \pi) correctly satisfies a + \pi==4.
Comment 5 Tobias Burnus 2013-07-30 14:14:39 UTC
Cross-ref: See also PR29383.

(In reply to Fred Krogh from comment #0)
> Dr. Richard Hanson has written code to provide IEEE exception handling to
> gfortran.

Cool! I think it should be linked from the Wiki and somewhat made known. Even prior (or without) inclusion in GCC/gfortran, the code is very useful for users!


(In reply to kargl from comment #1)
> 1) Hanson needs to have a copyright assignment on file with FSF
>    before the code can be used.

Or rather: Before it can be included in GCC/shipped with gfortran.

(In reply to Fred Krogh from comment #2)
> 1. Hanson is willing to assign the copyright if you expect to be using this
> work.  There were thoughts to include this work on a SIAM website where we
> think SIAM would want the copyright

The Free Software Foundation (FSF) only requires a nonexclusive copyright transfer (for inclusion in GCC). Thus, it could be additionally posted to the SIAM webpage - assuming SIAM also is fine with a nonexclusive copyright transfer. See http://gcc.gnu.org/wiki/GettingStarted (Basics, Item 1) for details.


(In reply to kargl from comment #1)
> 2) More importantly, the code appears to only support the i386
>    and amd64 architectures.  gfortran runs are far more processors
>    than these.

My personal long-term plan is to add the necessary bits for IEEE to libgfortran/config/ - and then to use them from there. Currently supported are setting/getting the rounding mode, obtaining the set exceptions flags and setting the exception trapping. That's supported for i386/x86-64, GLIBC, SysV (at least: FreeBSD and Solaris) and AIX; see http://gcc.gnu.org/viewcvs/gcc/trunk/libgfortran/config/

[Note: Those are currently only internally exported. Before making them externally callable, one should ensure that the ABI won't change.]

Additionally, I'd like to generate the IEEE modules "on the fly" - like ISO_C_Binding and Fortran_Dev. That gives some more optimization possibilities and also could be used to honor SH's/Alpha's -mieee compiler flag.


One way forward would be to check whether libgfortran/config/'s function are sufficient - and if not, add more or modify the ABI. Those could then be exported (public ABI).

In principle, one could then also ship the modules - However, the biggest question is how to handle the functions in the module. Those then become part of the public ABI of gfortran and has to continued to be supported, even if we could move some function to the compiler itself (generated code).


> 3) messy_m.f90 includes the statement:
>    I haven't looked at the code to determine if messy_m.f90 is actually
>    needed.

It seems to be only used for testing. (In any case, it would be useful to have some test cases in the testsuite.)
Comment 6 richard.koolhans 2013-07-30 14:36:00 UTC
Bonjour Dominique-
Le reste sera l'anglais! Voilà pour mon cours de français.

I see your bug report. There are two matters to track down here. The first
one is the diagnostic of 'PR58027'. This may require you to report a line
number. That would be great. Testing that I have done is with the gfortran
compiler on Krogh's machine and my own with the Intel compiler. I do not
have access to the machine you are using.

The second matter is the difference in a line of output. That is the
printing of the 4 digit approximation to \pi. The internal constant \pi
itself comes from the stored value in the x87. The output of the number
comes from the routine messy. I expect the hardware value is correct. So
one machine writes 3.141 wit messy, and the other 3.142.

I appreciate the feedback. Hope we can find the issues and clear them up.

Richard
Comment 7 Dominique d'Humieres 2013-07-30 17:31:01 UTC
> I see your bug report. There are two matters to track down here. 
> The first one is the diagnostic of 'PR58027'. This may require you 
> to report a line number. That would be great. Testing that I have 
> done is with the gfortran compiler on Krogh's machine and my own 
> with the Intel compiler. I do not have access to the machine you 
> are using.

The ICE leading to PR58027 is

[macbook] bug/IEEE_1% gfc -c IEEE_tests_gfortran.f90
IEEE_tests_gfortran.f90: In function 'ieee_tests':
IEEE_tests_gfortran.f90:304:0: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:5512
     SA=transfer(ISCLASS(I),SA)

However any use of ISCLASS leads to the ICE because the parameter array is not built. To understand why, I have compiled the following test

    integer, parameter :: isclass = Z'FF800000'
end

and got

isclass_2.f90:1.35:

    integer, parameter :: isclass = Z'FF800000'
                                   1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1). This check can be disabled with the option -fno-range-check

with -m64 and

isclass_2.f90:1.35:

    integer, parameter :: isclass = Z'FF800000'
                                   1
Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This check can be disabled with the option -fno-range-check

with -m32. The gfortran rationale is that Z'FF800000' is converted to the highest integer kind (8 with -m32 or 16 with -m64) as 2**32-8388608, i.e., a positive number larger that huge(1)=2**31-1.

> The second matter is the difference in a line of output. That is the
> printing of the 4 digit approximation to \pi. The internal constant \pi
> itself comes from the stored value in the x87. The output of the number
> comes from the routine messy. I expect the hardware value is correct. So
> one machine writes 3.141 wit messy, and the other 3.142.

Apparently 'CALL IEEE_SET_ROUNDING_MODE(IEEE_TO_ZERO)' propagates into

    call messy(E,'$N Double precision rounding mode IEEE_DOWN&
      & for \pi ~= $R agrees with IEEE_TO_ZERO.',rdat=[DA])

If I add

  CALL IEEE_SET_ROUNDING_MODE(IEEE_NEAREST)

before the line

  IF(DC == DA) THEN ! Round down should agree withround to zero, here.

then my output matches the one in list.
Comment 8 Steve Kargl 2013-07-30 17:37:50 UTC
On Tue, Jul 30, 2013 at 05:31:01PM +0000, dominiq at lps dot ens.fr wrote:
> 
> with -m32. The gfortran rationale is that Z'FF800000' is converted to the
> highest integer kind (8 with -m32 or 16 with -m64) as 2**32-8388608, i.e., a
> positive number larger that huge(1)=2**31-1.

It is not a gfortran rationale.  It is what the Fortran mandates!
Comment 9 Fred Krogh 2013-07-30 17:55:31 UTC
Concering Fortran language standards, our guru is W. Van Snyder a long time member of the Fortran Standards committee.  He has said to me in an email:
"It's OK not to support stuff, but the inquiry functions have to be there to tell you."
Comment 10 richard.koolhans 2013-07-31 17:27:17 UTC
The issues have hopefully been resolved and are now in the package. 
See http://mathalacarte.com/hpcconsult

Thanks for the comments made above.  Give feedback where it makes sense.
Comment 11 Dominique d'Humieres 2013-08-01 12:59:55 UTC
> The issues have hopefully been resolved and are now in the package. 
> See http://mathalacarte.com/hpcconsult

> Thanks for the comments made above.  Give feedback where it makes sense.

When c_control.c is compiled with -O3 or above, IEEE_tests_gfortran.f90 aborts at run time with:

 Computing (w/x87) D=sqrt(A/B+C), D=0., A=0., B=0., C=0., correctly signals 
 IEEE_INVALID using gfortran  

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x1000240c2
#1  0x100025a1e
#2  0x7fff80df91b9
Floating exception

The test runs without problem with -O2.
Comment 12 richard.koolhans 2013-08-01 15:51:31 UTC
Thanks for doing the test with -O3.  That is what I see, also.  My tests show:

With -O0 everything works.
With -O1 everything runs but there are some failures.
With -O2 everything runs but there are some failures.
With -O3 there is a crash, as noted.

I searched and found a suggestion about suppressing optimization within a C code, using the gcc compiler:

http://stackoverflow.com/questions/2219829/how-to-prevent-gcc-optimizing-some-statements-in-c

I gave my local variables the additional *volatile* attribute and that solved the optimization problem. This is preferred to requiring that -O0 be used in the compile line.  That way other optimizations are not suppressed. My understanding ends there.
Comment 13 Francois-Xavier Coudert 2013-11-05 13:54:19 UTC
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).

So, a few questions to Fred and Richard:

 0. Thanks for contributing your work to our open-source effort!
 1. What is the current status of your code w.r.t. the IEEE modules? Do you have full coverage? Full test coverage? Does it depend on 32 vs 64-bit?
 2. Although you don't plan to support other architectures than i386/x86_64, we have to think about it. The current approach does not seem to lend itself to writing new ports easily. How do you think we could better insulate the processor-specific code from the higher-level IEEE modules themselves?

I have started reading the code, but your answers would be very much appreciated!
Comment 14 fkrogh 2013-11-05 14:03:49 UTC
Hi Francois-Xavier --
     I'm sorry, but Richard did all the work on this, and I'm just a 
sorry middle man.  We are both people specializing in computational 
mathematics, and thus not likely to be helpful with respect to your 
question number 2.  With this email I'm asking Richard to give you a 
more detailed response.
Many thanks for looking into this,
     Fred


-------- Original Message --------
Subject: 	[Bug libfortran/58020] Code for handling IEEE exceptions
Date: 	Tue, 05 Nov 2013 13:54:19 +0000
From: 	fxcoudert at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
To: 	fkrogh#gcc@mathalacarte.com



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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

            What    |Removed                     |Added
----------------------------------------------------------------------------
                  CC|                            |fxcoudert at gcc dot gnu.org
              Blocks|                            |29383

--- Comment #13 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
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).

So, a few questions to Fred and Richard:

  0. Thanks for contributing your work to our open-source effort!
  1. What is the current status of your code w.r.t. the IEEE modules? Do you
have full coverage? Full test coverage? Does it depend on 32 vs 64-bit?
  2. Although you don't plan to support other architectures than i386/x86_64, we
have to think about it. The current approach does not seem to lend itself to
writing new ports easily. How do you think we could better insulate the
processor-specific code from the higher-level IEEE modules themselves?

I have started reading the code, but your answers would be very much
appreciated!
Comment 15 fkrogh 2013-11-05 14:06:53 UTC
Hi Francois-Xavier --
      I'm sorry, but Richard did all the work on this, and I'm just a
sorry middle man.  We are both people specializing in computational
mathematics, and thus not likely to be helpful with respect to your
question number 2.  With this email I'm asking Richard to give you a
more detailed response.
Many thanks for looking into this,
      Fred



On 11/05/2013 05:54 AM, fxcoudert at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
>
> Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |fxcoudert at gcc dot gnu.org
>               Blocks|                            |29383
>
> --- Comment #13 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> 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).
>
> So, a few questions to Fred and Richard:
>
>   0. Thanks for contributing your work to our open-source effort!
>   1. What is the current status of your code w.r.t. the IEEE modules? Do you
> have full coverage? Full test coverage? Does it depend on 32 vs 64-bit?
>   2. Although you don't plan to support other architectures than i386/x86_64, we
> have to think about it. The current approach does not seem to lend itself to
> writing new ports easily. How do you think we could better insulate the
> processor-specific code from the higher-level IEEE modules themselves?
>
> I have started reading the code, but your answers would be very much
> appreciated!
>
Comment 16 Tobias Burnus 2013-11-05 15:50:13 UTC
(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).
Comment 17 Francois-Xavier Coudert 2013-11-05 16:00:17 UTC
(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?
Comment 18 Francois-Xavier Coudert 2013-11-05 16:10:00 UTC
(In reply to Francois-Xavier Coudert from comment #17)
> IEEE_SUPPORT_* functions are allowed in specification expressions

On second thought, I think we can handle these on the library side (PURE functions in modules are allowed in specification expressions, right?)
Comment 19 Steve Kargl 2013-11-05 16:25:14 UTC
On Tue, Nov 05, 2013 at 04:10:00PM +0000, fxcoudert at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
> 
> --- Comment #18 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> (In reply to Francois-Xavier Coudert from comment #17)
> > IEEE_SUPPORT_* functions are allowed in specification expressions
> 
> On second thought, I think we can handle these on the library side (PURE
> functions in modules are allowed in specification expressions, right?)

There's a long list in F2008, 7.1.11 on what is permitted in a
specification expression.  Item (10) is

(10) a reference to any other standard intrinsic function where each
     argument is a restricted expression,

All intrinsic functions are PURE unless otherwise specifically stated
in the description of a given intrinsic function.

This differs tremendously from the short list of intrinsic functions
that were permitted by F95.
Comment 20 Francois-Xavier Coudert 2013-11-05 16:35:38 UTC
(In reply to Steve Kargl from comment #19)
> (10) a reference to any other standard intrinsic function where each
>      argument is a restricted expression

Yes, but the procedures of the intrinsic modules IEEE_* are not themselves intrinsic procedures (note 14.1 of F2008).

The IEEE_SUPPORT_* functions are allowed under item 9 of the same list ("specification inquiry"), because of item 4.3 on the same page: "A specification inquiry is a reference to (3) an inquiry function from the intrinsic modules IEEE ARITHMETIC and IEEE EXCEPTIONS".

But, as I noted, this can be handled by a library-side module. The only tricky case remaining, I think, is the IEEE_SELECTED_REAL_KIND, which will have to be specifically handled by the front-end.
Comment 21 richard.koolhans 2013-11-05 17:03:25 UTC
I'm not really an expert on any architecture.  But there is an important point that I think should not be missed.  According to Van Snyder, a long-time member of the Fortran standards committee, if there is no support for the IEEE exceptions, a module must be provided that enables a program to query whether such support is provided.  I strongly recommend that such an intrinsic module be provided for architectures that are not supported.  

In the test driver I've attempted to have full coverage.  In particular the status flags from the FPU and SSE units are "or-ed" or “and-ed” together to catch or clear exceptions that may occur in either place.  Since there are no 64 bit status registers, I don't see any difference in code for 32 vs 64-bit.  Little use of the FPU is made in the machine code these days.  But this feature was important because an assembly code could use the FPU, have an exception, and only dealing with the SSE flags would miss it.

Your question in 2. was not answered, but I don’t understand  these issues.  There is a document IEEE.pdf in the distributed package that has some discussion about decisions made to deal with threads.

Richard J. Hanson
Comment 22 Steve Kargl 2013-11-05 17:41:14 UTC
On Tue, Nov 05, 2013 at 05:03:25PM +0000, richard.koolhans at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
> 
> --- Comment #21 from richard.koolhans at gmail dot com ---
> 
> I'm not really an expert on any architecture.  But there is an important
> point that I think should not be missed.  According to Van Snyder, a
> long-time member of the Fortran standards committee, if there is no
> support for the IEEE exceptions, a module must be provided that enables
> a program to query whether such support is provided.  I strongly
> recommend that such an intrinsic module be provided for architectures
> that are not supported.  

I suspect that you are not recalling what Van said correctly.  
The first 2 sentences of Fortran 2008, Sec. 14 are

   The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and
   IEEE_FEATURES provide support for the facilities defined by IEC
   60559:1989*.  Whether the modules are provided is processor
   dependent.

This clearly means that a processeor is not required by the
standard to provide these modules.  There is no other module
defined in Sec. 14.  AFAICT, the only way to tell if one or
more of these modules is present it to read the documentation
that comes with the processor or simply try compiling a
program that USEs them.
Comment 23 Francois-Xavier Coudert 2013-11-06 12:25:55 UTC
(In reply to Tobias Burnus from comment #16)
> 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.

Yes. After thinking about it some more, we'll need to add two "save/restore FPU state" functions.
Comment 24 kargl 2013-11-25 00:58:56 UTC
Remove myself from cc list.
Comment 25 Francois-Xavier Coudert 2014-06-07 10:19:17 UTC
Thanks for the suggestion and code. I have decided to follow up a different route to achieve support of the IEEE intrinsic modules in gfortran (patch currently submitted for review here: https://gcc.gnu.org/ml/fortran/2014-06/msg00038.html). I am thus closing this PR, and marking it as a duplicate of PR29383, so we retain a link between the two.

*** This bug has been marked as a duplicate of bug 29383 ***