[Bug libfortran/58020] New: Code for handling IEEE exceptions

[Bug libfortran/58020] New: Code for handling IEEE exceptions

[fkrogh#gcc at mathalacarte dot com]

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

            Bug ID: 58020
           Summary: Code for handling IEEE exceptions
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fkrogh#gcc at mathalacarte dot com

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.

[Bug libfortran/58020] Code for handling IEEE exceptions

[kargl at gcc dot gnu.org]

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

[fkrogh#gcc at mathalacarte dot com]

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

[sgk at troutmask dot apl.washington.edu]

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 +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.

[Bug libfortran/58020] Code for handling IEEE exceptions

[dominiq at lps dot ens.fr]

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':

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

[Bug libfortran/58020] Code for handling IEEE exceptions

[burnus at gcc dot gnu.org]

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

[richard.koolhans at gmail dot com]

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
>From gcc-bugs-return-426984-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 30 14:50:51 2013
Return-Path: <gcc-bugs-return-426984-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21691 invoked by alias); 30 Jul 2013 14:50:51 -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 21628 invoked by uid 48); 30 Jul 2013 14:50:48 -0000
From: "bluescarni at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/58030] New: Mismatched tags in std::hash friends
Date: Tue, 30 Jul 2013 14:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: bluescarni at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-58030-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-07/txt/msg01491.txt.bz2
Content-length: 1668

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX030

            Bug ID: 58030
           Summary: Mismatched tags in std::hash friends
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bluescarni at gmail dot com

I am testing out clang in conjunction with GCC 4.8.1's libstdc++ in c++11 mode.
I routinely get these warnings when compiling with -Wall and -Wextra:

---

/home/yardbird/repos/piranha/src/rational.hpp:1753:1: warning: 'hash' defined
as a struct template here but previously declared as
      a class template [-Wmismatched-tags]
struct hash<piranha::rational>
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bits/stl_bvector.h:523:31:
note: did you mean struct here?
    template<typename> friend class hash;
                              ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bitset:763:33:
note: did you mean struct here?
      template<typename> friend class hash;
                                ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bits/stl_bvector.h:523:31:
note: did you mean struct here?
    template<typename> friend class hash;
                              ^

---

Indeed, these friendship declarations in bitset and stl_bvector.h use 'class'
instead of 'struct' when referring to std::hash. It is my understanding that
this behaviour does not constitute a violation of the standard... still it irks
my compiler warnings OCD :)

Any chance this could be fixed sometimes?

[Bug libfortran/58020] Code for handling IEEE exceptions

[dominiq at lps dot ens.fr]

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'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.

[Bug libfortran/58020] Code for handling IEEE exceptions

[sgk at troutmask dot apl.washington.edu]

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 +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!

[Bug libfortran/58020] Code for handling IEEE exceptions

[fkrogh#gcc at mathalacarte dot com]

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

[richard.koolhans at gmail dot com]

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

[dominiq at lps dot ens.fr]

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

[richard.koolhans at gmail dot com]

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

[fxcoudert at gcc dot gnu.org]

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!
>From gcc-bugs-return-433568-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 05 13:57:11 2013
Return-Path: <gcc-bugs-return-433568-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7948 invoked by alias); 5 Nov 2013 13:57:11 -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 3252 invoked by uid 48); 5 Nov 2013 13:55:09 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/58479] [4.9 Regression] slow var-tracking on x86_64-linux at -O1 (and above) with -g, but checking disabled
Date: Tue, 05 Nov 2013 13:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: compile-time-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority
Message-ID: <bug-58479-4-bxGbXsLIS1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58479-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58479-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/msg00345.txt.bz2
Content-length: 290

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX479

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug libfortran/58020] Code for handling IEEE exceptions

[fkrogh at mathalacarte dot com]

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 +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!
>From gcc-bugs-return-433571-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 05 14:08:27 2013
Return-Path: <gcc-bugs-return-433571-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27079 invoked by alias); 5 Nov 2013 14:08:26 -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 25940 invoked by uid 48); 5 Nov 2013 14:06:24 -0000
From: "p.micolet at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59005] Having designated inits in C++ with -std=c++11 does not cause any errors
Date: Tue, 05 Nov 2013 14:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: p.micolet at gmail dot com
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-59005-4-SzBzRU08rI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59005-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59005-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/msg00348.txt.bz2
Content-length: 178

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY005

--- Comment #1 from p.micolet at gmail dot com ---
Also saw this issue using GCC 4.7.0, same target, same flags and same code

[Bug libfortran/58020] Code for handling IEEE exceptions

[fkrogh at mathalacarte dot com]

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!
>
>From gcc-bugs-return-433573-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 05 14:19:43 2013
Return-Path: <gcc-bugs-return-433573-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7808 invoked by alias); 5 Nov 2013 14:19:43 -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 5528 invoked by uid 55); 5 Nov 2013 14:17:39 -0000
From: "hjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/58981] movmem/setmem use mode wider than Pmode for size
Date: Tue, 05 Nov 2013 14:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl 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: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58981-4-va3vuD4zZ8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58981-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58981-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/msg00350.txt.bz2
Content-length: 815

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX981

--- Comment #8 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
Author: hjl
Date: Tue Nov  5 14:17:33 2013
New Revision: 204394

URL: http://gcc.gnu.org/viewcvs?rev 4394&root=gcc&view=rev
Log:
Don't use mode wider than Pmode for size in movmem/setmem

gcc/

    PR middle-end/58981
    * doc/md.texi (@code{movmem@var{m}}): Specify Pmode as mode of
    pattern, instead of word_mode.

    * expr.c (emit_block_move_via_movmem): Don't use mode wider than
    Pmode for size.
    (set_storage_via_setmem): Likewise.

gcc/testsuite/

    PR middle-end/58981
    * gcc.dg/pr58981.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr58981.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/md.texi
    trunk/gcc/expr.c
    trunk/gcc/testsuite/ChangeLog

[Bug libfortran/58020] Code for handling IEEE exceptions

[burnus at gcc dot gnu.org]

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?

[Bug libfortran/58020] Code for handling IEEE exceptions

[fxcoudert at gcc dot gnu.org]

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

[sgk at troutmask dot apl.washington.edu]

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 +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.

[Bug libfortran/58020] Code for handling IEEE exceptions

[fxcoudert at gcc dot gnu.org]

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

[richard.koolhans at gmail dot com]

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
>From gcc-bugs-return-433636-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 05 17:09:55 2013
Return-Path: <gcc-bugs-return-433636-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8917 invoked by alias); 5 Nov 2013 17:09:55 -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 6159 invoked by uid 48); 5 Nov 2013 17:07:53 -0000
From: "kcc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/58718] Invalid check in libsanitizer
Date: Tue, 05 Nov 2013 17:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kcc at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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-58718-4-dotJu3ghgM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58718-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58718-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/msg00413.txt.bz2
Content-length: 251

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX718

--- Comment #6 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Can we keep this bug in one place, please?
Let https://code.google.com/p/address-sanitizer/issues/detail?id#9 be the
primary one

[Bug libfortran/58020] Code for handling IEEE exceptions

[sgk at troutmask dot apl.washington.edu]

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 +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.

[Bug libfortran/58020] Code for handling IEEE exceptions

[fxcoudert at gcc dot gnu.org]

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

[kargl at gcc dot gnu.org]

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

[fxcoudert at gcc dot gnu.org]

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