[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2022-09-10 Thread vital.had at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

Sergey Fedorov  changed:

   What|Removed |Added

 CC||vital.had at gmail dot com

--- Comment #20 from Sergey Fedorov  ---
I just got the same error when building OpenCoarrays on 10.6.8 for ppc32:

/opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/OpenCoarrays-2.10.0/src/tests/integration/pde_solvers/coarrayBurgers/main.F90:3:20:

3 |   use, intrinsic :: ieee_arithmetic, only : ieee_is_nan
  |1
Fatal Error: Cannot find an intrinsic module named 'ieee_arithmetic' at (1)
compilation terminated.
Error: command:
   `/opt/local/bin/mpif90-mpich-gcc12
-I/opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/build/include/OpenCoarrays-2.10.0_GNU-12.2.0
-fcoarray=lib -DGCC_GE_7 -DGCC_GE_8 -DHAVE_MPI -DMPI_WORKING_MODULE
-DPREFIX_NAME=_gfortran_caf_
-I/opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/build/src/tests/integration/pde_solvers/coarrayBurgers/library
-pipe -Os -m32 -mmacosx-version-min=10.6 -c
/opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/OpenCoarrays-2.10.0/src/tests/integration/pde_solvers/coarrayBurgers/main.F90
-o CMakeFiles/coarray_burgers_pde.dir/main.F90.o`
failed to compile.

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

--- Comment #18 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 18:57:39 2019
New Revision: 269846

URL: https://gcc.gnu.org/viewcvs?rev=269846=gcc=rev
Log:
[testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'

In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.

All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'.  Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.

gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.

trunk r269845

Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/ieee/ieee.exp

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

--- Comment #19 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 18:57:56 2019
New Revision: 269847

URL: https://gcc.gnu.org/viewcvs?rev=269847=gcc=rev
Log:
[testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'

In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.

All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'.  Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.

gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.

trunk r269845

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/ieee/ieee.exp

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

--- Comment #17 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 18:54:50 2019
New Revision: 269845

URL: https://gcc.gnu.org/viewcvs?rev=269845=gcc=rev
Log:
[testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'

In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.

All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'.  Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.

gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ieee/ieee.exp

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-28 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

--- Comment #15 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
Author: fxcoudert
Date: Sat Jun 28 14:17:41 2014
New Revision: 212102

URL: https://gcc.gnu.org/viewcvs?rev=212102root=gccview=rev
Log:
PR fortran/29383

gcc/fortran/
* gfortran.h (gfc_simplify_ieee_selected_real_kind): New prototype.
* libgfortran.h (GFC_FPE_*): Use simple integer values, valid in
both C and Fortran.
* expr.c (gfc_check_init_expr): Simplify IEEE_SELECTED_REAL_KIND.
* simplify.c (gfc_simplify_ieee_selected_real_kind): New function.
* module.c (mio_symbol): Keep track of symbols which came from
intrinsic modules.
(gfc_use_module): Keep track of the IEEE modules.
* trans-decl.c (gfc_get_symbol_decl): Adjust code since
we have new intrinsic modules.
(gfc_build_builtin_function_decls): Build decls for
ieee_procedure_entry and ieee_procedure_exit.
(is_from_ieee_module, is_ieee_module_used, save_fp_state,
restore_fp_state): New functions.
(gfc_generate_function_code): Save and restore floating-point
state on procedure entry/exit, when IEEE modules are used.
* intrinsic.texi: Document the IEEE modules.

libgfortran/
* configure.host: Add checks for IEEE support, rework priorities.
* configure.ac: Define IEEE_SUPPORT, check for fpsetsticky and
fpresetsticky.
* configure: Regenerate.
* Makefile.am: Build new ieee files, install IEEE_* modules.
* Makefile.in: Regenerate.
* gfortran.map (GFORTRAN_1.6): Add new symbols.
* libgfortran.h (get_fpu_trap_exceptions, set_fpu_trap_exceptions,
support_fpu_trap, set_fpu_except_flags, support_fpu_flag,
support_fpu_rounding_mode, get_fpu_state, set_fpu_state): New
prototypes.
* config/fpu-*.h (get_fpu_trap_exceptions,
set_fpu_trap_exceptions, support_fpu_trap, set_fpu_except_flags,
support_fpu_flag, support_fpu_rounding_mode, get_fpu_state,
set_fpu_state): New functions.
* ieee/ieee_features.F90: New file.
* ieee/ieee_exceptions.F90: New file.
* ieee/ieee_arithmetic.F90: New file.
* ieee/ieee_helper.c: New file.

gcc/testsuite/
* lib/target-supports.exp (check_effective_target_fortran_ieee): 
New function.
* gfortran.dg/ieee/ieee.exp: New file.
* gfortran.dg/ieee/ieee_1.F90: New file.
* gfortran.dg/ieee/ieee_2.f90: New file.
* gfortran.dg/ieee/ieee_3.f90: New file.
* gfortran.dg/ieee/ieee_4.f90: New file.
* gfortran.dg/ieee/ieee_5.f90: New file.
* gfortran.dg/ieee/ieee_6.f90: New file.
* gfortran.dg/ieee/ieee_7.f90: New file.
* gfortran.dg/ieee/ieee_rounding_1.f90: New file.


Added:
trunk/gcc/testsuite/gfortran.dg/ieee/
trunk/gcc/testsuite/gfortran.dg/ieee/ieee.exp
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_1.F90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_2.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_3.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_4.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_5.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_6.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_7.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_rounding_1.f90
trunk/libgfortran/ieee/
trunk/libgfortran/ieee/ieee_arithmetic.F90
trunk/libgfortran/ieee/ieee_exceptions.F90
trunk/libgfortran/ieee/ieee_features.F90
trunk/libgfortran/ieee/ieee_helper.c
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/libgfortran.h
trunk/gcc/fortran/module.c
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in
trunk/libgfortran/config/fpu-387.h
trunk/libgfortran/config/fpu-aix.h
trunk/libgfortran/config/fpu-generic.h
trunk/libgfortran/config/fpu-glibc.h
trunk/libgfortran/config/fpu-sysv.h
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/configure.host
trunk/libgfortran/gfortran.map
trunk/libgfortran/libgfortran.h


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-28 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

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

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.10.0

--- Comment #16 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
This has now been fixed on trunk (4.10). Hurray!


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-15 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

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

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |fxcoudert at gcc dot 
gnu.org


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-07 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

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

   What|Removed |Added

 CC||fkrogh#gcc at mathalacarte dot 
com

--- Comment #13 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
*** Bug 58020 has been marked as a duplicate of this bug. ***


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-07 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
Bug 29383 depends on bug 58020, which changed state.

Bug 58020 Summary: Code for handling IEEE exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-07 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
Bug 29383 depends on bug 59026, which changed state.

Bug 59026 Summary: ELEMENTAL procedure with VALUE arguments emits wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59026

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-07 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

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

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #14 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
I posted a patch adding a rather complete IEEE support here:
https://gcc.gnu.org/ml/fortran/2014-06/msg00038.html


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-03 Thread w6ws at earthlink dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

Walter Spector w6ws at earthlink dot net changed:

   What|Removed |Added

 CC||w6ws at earthlink dot net

--- Comment #12 from Walter Spector w6ws at earthlink dot net ---
Adding myself to the CC list, sympathizing with comment #5. Just
IEEE_ARITHMETIC intrinsic functions for basic setting (e.g., IEEE_VALUE) and
testing (e.g., IEEE_IS_NAN) with the default rounding mode, roughly equivalent
to what g95 supports, would be very useful.  I don't need fancy rounding modes.


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-01-06 Thread janus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

Bug 29383 depends on bug 59023, which changed state.

Bug 59023 Summary: [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2013-04-14 Thread quantheory at gmail dot com


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



--- Comment #11 from Sean Santos quantheory at gmail dot com 2013-04-14 
20:08:59 UTC ---

I'm doing a bit of research because I'm considering trying to tackle part of

this soon.



I believe that the Fortran standard does not require the rounding mode to apply

to operations performed during constant folding, so point 4 above is moot.



Please see the collected interpretations of F2003:



http://j3-fortran.org/doc/standing/links/016.txt



Particularly see F03/0040 and F03/0078. In combination they guarantee that the

compiler is allowed to transform expressions at compile time according to the

mathematical equivalence rule regardless of the rounding mode. In any case,

the rounding mode cannot always be established at compile time; if the

committee had not decided upon this behavior, then constant folding would often

be impossible, period.



The Fortran 2003 and 2008 standards also give examples where constant folding

and propagation are allowed to influence whether or not an IEEE exception is

signaled.


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2012-12-04 Thread quantheory at gmail dot com


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



Sean Santos quantheory at gmail dot com changed:



   What|Removed |Added



 CC||quantheory at gmail dot com



--- Comment #10 from Sean Santos quantheory at gmail dot com 2012-12-04 
19:28:19 UTC ---

Comment 9 seems a bit too pessimistic to me.



For one, returning .false. for ieee_supports_* doesn't seem like a sidestep,

but more like the correct behavior in an environment that lacks IEEE support

(maybe even if the only reason is because the compiler has not implemented it).



For another, as noted above, one important use of the ieee_arithmetic module is

to test for NaN/Inf in a standard-conforming way, rather than using

compiler-specific extensions. (AFAIK, gfortran is the only F2003 compiler that

forces you to use a non-portable extension to do this.)



For that functionality, the only likely problem I can see is in deciding when

e.g. ieee_support_nan should return .true..



Of course this is only a fraction of what needs to be done (presumably the

easiest part), but it's much better than nothing, particularly to address what

I would expect to be one of the most common uses of this module.


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2012-10-09 Thread andy.nelson at lanl dot gov


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



--- Comment #8 from Andy Nelson andy.nelson at lanl dot gov 2012-10-09 
15:19:36 UTC ---

Interesting. Didn't see this dup originally in my search.



In response to your other email (that it is very very hard), can you explain

a bit why if you've got the time/inclination? My first thought was that it 

would be a fairly simple pass through/reimplementation of the fpclassify 

functionality of c.



Thanks,



Andy Nelson



On Oct 6, 2012, at 6:08 PM, kargl at gcc dot gnu.org wrote:



 

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

 

 kargl at gcc dot gnu.org changed:

 

   What|Removed |Added

 

 CC||andy.nelson at lanl dot gov

 

 --- Comment #7 from kargl at gcc dot gnu.org 2012-10-07 00:08:49 UTC ---

 *** Bug 54840 has been marked as a duplicate of this bug. ***

 

 -- 

 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

 --- You are receiving this mail because: ---

 You are on the CC list for the bug.


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2012-10-09 Thread kargl at gcc dot gnu.org


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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 CC||kargl at gcc dot gnu.org



--- Comment #9 from kargl at gcc dot gnu.org 2012-10-09 17:00:42 UTC ---

(In reply to comment #8)



 In response to your other email (that it is very very hard), can you explain

 a bit why if you've got the time/inclination? My first thought was that it 

 would be a fairly simple pass through/reimplementation of the fpclassify 

 functionality of c.



There are a few reason (and this is just my opinion).



1) gcc runs on numerous cpu architectures (i386, x86_64,

   arm, sparc, powerpc, etc).  Some (many? all?) do not

   have hardware support for IEEE754.  An implementation

   needs to be able to work on most (all?) of these cpus.



2) gcc runs on numerous operating systems.  The operating

   systems may or may not have sufficient support to allow

   an efficient IEEE754 implementation (a software

   implementation of IEEE754 will be slow).



3) Using C interoperability to access the fenv.h facility

   seems appealing, but gcc would need to deal with systems

   that do not have fenv.h.



4) gcc performs constant folding with mpfr, and in gfortran

   this constant folding is performed in round-to-nearest mode.

   gfortran would need to be update to delay constant folding

   until the rounding mode has been established.



   program foo

  use ieee_arithmetic

  real x

  call ieee_set_rounding_mode(ieee_down)

  x = 0.3 + 0.1999  ! Should be down in round-down?

  print '(Z0)', x

   end program foo



5) Finally, for some intrinsic functions, it is not possible

   to map to a libm routine without now putting a wrapper around

   the libm routine.  For example, consider FRACTION().  The standard

   states:



   Result Value.  The result has the value X*b**(-e), where b

   and e are as defined in 13.4 for the model representation of

   X.  If X has the value zero, the result has the value zero.

   If X is an IEEE infinity, the result is that infinity. If X

   is an IEEE NaN, the result is that NaN.



   The word that in the result is that NaN is problematic. 

   There are something like 2**p bit patterns that much NaN.

   Unfortunately, mapping FRACTION to libm's frexp gives the

   wrong NaN.  See PR 48979 for a longer explanation.



One can side step 1), 2), and 3) by unilaterally returning

false for ieee_support_standard(), which of course indicates

that the IEEE754 isn't standard.  4) and 5) are much harder

to fix.



Of course, I could be wrong.


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2012-10-06 Thread kargl at gcc dot gnu.org


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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 CC||andy.nelson at lanl dot gov



--- Comment #7 from kargl at gcc dot gnu.org 2012-10-07 00:08:49 UTC ---

*** Bug 54840 has been marked as a duplicate of this bug. ***


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2011-07-22 Thread longb at cray dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

Bill Long longb at cray dot com changed:

   What|Removed |Added

 CC||longb at cray dot com

--- Comment #6 from Bill Long longb at cray dot com 2011-07-22 17:53:49 UTC 
---
Since most other compilers support ieee_arithmetic now, the lack of support in
gfortran is becoming a portability issue.  Simple test case with 4.6.1:

 cat t1.f90
program test
   use,intrinsic :: ieee_arithmetic

   real :: x
   read *, x
   if (ieee_is_nan(x)) then
  print *, Nan
   else
  print *, Not NaN
   end if
end program test
 gfortran t1.f90
t1.f90:2.35:

   use,intrinsic :: ieee_arithmetic
   1
Fatal Error: Can't find an intrinsic module named 'ieee_arithmetic' at (1)


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2011-01-24 Thread thenlich at users dot sourceforge.net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

Thomas thenlich at users dot sourceforge.net changed:

   What|Removed |Added

 CC||thenlich at users dot
   ||sourceforge.net

--- Comment #5 from Thomas thenlich at users dot sourceforge.net 2011-01-24 
08:53:10 UTC ---
Even a partial, incomplete support of module IEEE_ARITHMETIC would be very
useful and much appreciated:

From http://gcc.gnu.org/ml/gcc/2008-11/msg00372.html

a) To set an IEEE value (NaN, INF, etc.)
b) Check whether a value is NaN, etc.

and IEEE_VALUE(X, IEEE_QUIET_NAN)

So we wouldn't have to resort to non-standard functions like ISNAN()
(http://gcc.gnu.org/onlinedocs/gfortran/ISNAN.html) anymore.


[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2010-06-12 Thread burnus at gcc dot gnu dot org


--- Comment #4 from burnus at gcc dot gnu dot org  2010-06-12 12:15 ---
Malcolm Cohen wrote in Implementing the Standards...,
http://www.fortran.bcs.org/2007/jubilee/f50.pdf, the following:

IEEE module implementation
• Only if IEEE_GET_FLAG is directly called in a routine: save then clear the
flags on entry, merge the flags on exit.
• Only in a routine that uses a mode setting procedure: save mode on entry,
restore mode on exit.
• Parallelism and other optimisations are little impeded by the use of IEEE
facilities (all IEEE semantics being local).


-- 


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



[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2010-04-14 Thread burnus at gcc dot gnu dot org


--- Comment #3 from burnus at gcc dot gnu dot org  2010-04-14 06:33 ---
Some underflow module for Fortran:
  http://gcc.gnu.org/ml/fortran/2010-04/msg00144.html


-- 


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



[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2009-09-07 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2009-09-07 08:07 ---
Add links to some discussions to make sure it won't get lost:

http://gcc.gnu.org/ml/gcc/2008-11/msg00372.html

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1efc9e7a19651b81
The thread which is here and maybe also some other fort...@gcc emails by Tim
and Nick around this time:
http://gcc.gnu.org/ml/fortran/2009-08/msg00338.html


-- 


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



[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2006-10-22 Thread fxcoudert at gcc dot gnu dot org


--- Comment #1 from fxcoudert at gcc dot gnu dot org  2006-10-22 07:19 
---
Confirmed.

This one will probably be implemented after ISO_C_BINDING.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-10-22 07:19:52
   date||


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