[Bug libfortran/66458] New: Loading libgfortran.so changes the FPU exception flags

[Bug libfortran/66458] New: Loading libgfortran.so changes the FPU exception flags

[jan at epgmod dot phys.tue.nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458

            Bug ID: 66458
           Summary: Loading libgfortran.so changes the FPU exception flags
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jan at epgmod dot phys.tue.nl
  Target Milestone: ---

It appears that the mere act of loading libgfortran.so changes the FPU
exception mask. It looks as if the library contains initialization code that I
would have expected to appear in the program's start-up code. (Indeed it
appears to do so in line 266 of libgfortran/runtime/main.c.)

The problem can be reproduced by compiling the following C program:

// fpuflags
#include <fenv.h>
#include <dlfcn.h>

int main(int argc, char* argv[])
{
        volatile double d=0;
        feenableexcept(FE_ALL_EXCEPT);
        if (argc==2)
        {
                dlopen(argv[1],RTLD_NOW);
        }
        // I expect the expression 1/d to generate an FPU exception:
        return 1/d;
}

> gcc fpuflags.c -ldl -lm
> ./a.out 
Floating point exception
> ./a.out /usr/lib64/libstdc++.so.6
Floating point exception
> ./a.out /usr/lib64/gcc/x86_64-suse-linux/4.8/libgfortran.so
> #nothing happens

After merely loading libgfortan.so, no FPU exceptions are generated anymore.
Loading libstdc++.so does not result in such problem.

This is a problem in my numerical application where libgfortran.so is loaded as
a depency of a plugin library that is loaded at runtime.

At first sight, this problem may be similar to that in PR20788.

[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is done on purpose.

[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags

[jan at epgmod dot phys.tue.nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458

Jan van Dijk <jan at epgmod dot phys.tue.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-unknown-linux-gnu
               Host|                            |x86_64-unknown-linux-gnu
              Build|                            |x86_64-unknown-linux-gnu

--- Comment #2 from Jan van Dijk <jan at epgmod dot phys.tue.nl> ---
Could you elaborate on the rationale? I this behaviour is
implementation-defined, this may need to be marked a documentation issue
(assuming that I did not miss existing docs about the subject).

[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Jan van Dijk from comment #0)
> It appears that the mere act of loading libgfortran.so changes the FPU
> exception mask. It looks as if the library contains initialization code that
> I would have expected to appear in the program's start-up code. (Indeed it
> appears to do so in line 266 of libgfortran/runtime/main.c.)
> 
> The problem can be reproduced by compiling the following C program:
> 
> // fpuflags
> #include <fenv.h>
> #include <dlfcn.h>

#pragma STDC FENV_ACCESS ON

> int main(int argc, char* argv[])
> {
>         volatile double d=0;
          fenv_t fpu;

>         feenableexcept(FE_ALL_EXCEPT);
>         if (argc==2)
>         {

                  fegetenv(&fpu);

>                 dlopen(argv[1],RTLD_NOW);

                  fesetenv(&fpu);

>         }
>         // I expect the expression 1/d to generate an FPU exception:
>         return 1/d;
> }
> 
> > gcc fpuflags.c -ldl -lm
> > ./a.out 
> Floating point exception
> > ./a.out /usr/lib64/libstdc++.so.6
> Floating point exception
> > ./a.out /usr/lib64/gcc/x86_64-suse-linux/4.8/libgfortran.so
> > #nothing happens
> 
> After merely loading libgfortan.so, no FPU exceptions are generated anymore.
> Loading libstdc++.so does not result in such problem.
> 
> This is a problem in my numerical application where libgfortran.so is loaded
> as a depency of a plugin library that is loaded at runtime.

You're loading a dynamic library that has a constructor that is
executed to set up the library's internal state.  If you're loading
libraries and you want a specific FPU state, then you'll need to 
save and reset the state.

-- 
steve

[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-07-05
                 CC|                            |fxcoudert at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |fxcoudert at gcc dot gnu.org
   Target Milestone|---                         |6.0
     Ever confirmed|0                           |1

--- Comment #4 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to kargl from comment #3)
> You're loading a dynamic library that has a constructor that is
> executed to set up the library's internal state.  If you're loading
> libraries and you want a specific FPU state, then you'll need to 
> save and reset the state.

Yet, if not FPE-specific option was passed, there is no good reason for us to
mess with the FPU state.

Anyway, currently something's a bit suboptimal here. For example, if a program
is compiled with -ffpe-trap, we're gonna call set_fpu() twice: once from the
constructor, then again from the main program. That doesn't seem right.

[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458

--- Comment #5 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
The comment in the front-end confirms the original intent, which is that FPU
shouldn't be messed with if the user didn't explicitly request it:

  /* If -ffpe-trap option was provided, add a call to set_fpe so that
     the library will raise a FPE when needed.  */

The patch below makes libgfortran behave in the same way:

Index: runtime/main.c
===================================================================
--- runtime/main.c      (revision 226632)
+++ runtime/main.c      (working copy)
@@ -263,7 +263,11 @@ init (void)
   init_variables ();

   init_units ();
-  set_fpu ();
+
+  /* If (and only if) the user asked for it, set up the FPU state.  */
+  if (options.fpe != 0)
+    set_fpu ();
+
   init_compile_options ();

 #ifdef DEBUG

[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458

--- Comment #6 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Author: fxcoudert
Date: Fri Aug  7 16:23:53 2015
New Revision: 226725

URL: https://gcc.gnu.org/viewcvs?rev=226725&root=gcc&view=rev
Log:
        PR libfortran/66458
        * runtime/main.c (init): Only call set_fpu() if requested by user.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/runtime/main.c

[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Fixed on trunk.