[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 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 --- 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 --- 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
