Bug 58020 - Code for handling IEEE exceptions
Code for handling IEEE exceptions
 Status: RESOLVED DUPLICATE of bug 29383 None gcc Unclassified libfortran (show other bugs) 4.8.1 P3 normal --- Not yet assigned to anyone 59015 29383 Show dependency tree / graph

 Reported: 2013-07-29 17:05 UTC by Fred Krogh 2014-06-07 10:19 UTC (History) 2 users (show) burnus fxcoudert 2013-07-30 00:00:00

Attachments

 Note You need to log in before you can comment on or make changes to this bug.
 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. 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. 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 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 --- > 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. 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. 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.) 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 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. 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! 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." 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. 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. 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. 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! 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 To: fkrogh#gcc@mathalacarte.com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 Francois-Xavier Coudert changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fxcoudert at gcc dot gnu.org Blocks| |29383 --- Comment #13 from Francois-Xavier Coudert --- 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! 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 changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |fxcoudert at gcc dot gnu.org > Blocks| |29383 > > --- Comment #13 from Francois-Xavier Coudert --- > 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! > 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). 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? 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?) 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 --- > (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. 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. 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 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. 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. kargl 2013-11-25 00:58:56 UTC Remove myself from cc list. 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 ***