[Bug libfortran/58020] Code for handling IEEE exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 Bug 58020 depends on bug 59015, which changed state. Bug 59015 Summary: I/O of PARAMETER derived type with private component is forbidden https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59015 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libfortran/58020] Code for handling IEEE exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #25 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- 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 ***
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 kargl at gcc dot gnu.org changed: What|Removed |Added CC|kargl at gcc dot gnu.org | --- Comment #24 from kargl at gcc dot gnu.org --- Remove myself from cc list.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #23 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. 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.
[Bug libfortran/58020] Code for handling IEEE exceptions
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!
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #14 from fkrogh at mathalacarte dot com --- 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 + From: fxcoudert at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: fkrogh#g...@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!
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #15 from fkrogh at mathalacarte dot com --- 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!
[Bug libfortran/58020] Code for handling IEEE exceptions
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 atois 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).
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- 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?
[Bug libfortran/58020] Code for handling IEEE exceptions
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?)
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #20 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (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.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #19 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Nov 05, 2013 at 04:10:00PM +, 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.
[Bug libfortran/58020] Code for handling IEEE exceptions
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. 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
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #22 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Nov 05, 2013 at 05:03:25PM +, 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.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #12 from richard.koolhans at gmail dot com --- 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.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 richard.koolhans at gmail dot com changed: What|Removed |Added CC||richard.koolhans at gmail dot com --- Comment #10 from richard.koolhans at gmail dot com --- 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.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-30 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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': --- tmp2013-07-30 12:33:24.0 +0200 +++ list2013-07-25 21:27:02.0 +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.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- 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.)
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #6 from richard.koolhans at gmail dot com --- 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
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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'FF80' end and got isclass_2.f90:1.35: integer, parameter :: isclass = Z'FF80' 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'FF80' 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'FF80' 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.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #8 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Jul 30, 2013 at 05:31:01PM +, dominiq at lps dot ens.fr wrote: with -m32. The gfortran rationale is that Z'FF80' 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!
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #9 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- 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.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- 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.
[Bug libfortran/58020] Code for handling IEEE exceptions
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. 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
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Mon, Jul 29, 2013 at 09:03:53PM +, 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.
