[fortran, patch] IEEE intrinsic modules

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[fortran, patch] IEEE intrinsic modules

FX Coudert
Hi,

Last November, I worked on a patch to add the IEEE intrinsic modules to gfortran (thread starting at https://gcc.gnu.org/ml/fortran/2013-11/msg00126.html). After a round of review, I continued working on it, then didn’t have time, then development was frozen… Now, I found some time to get back to it, and here’s a more complete patch. I’ve bootstrapped it and regtested on:

  – x86_64-linux (both 32-bit and 64-bit); this also uses 387/SSE assembler
  – x86_64-linux with tweaked configure.host to force it to use glibc functions in config/fpu-glibc.h (both 32-bit and 64-bit)

The current state of the patch: as far as I can tell, nearly full support. In particular, since my last patch, I’ve added “saving/restoring FPU state on procedure entry/exit, when IEEE is used”. This is done in trans-decl.c, by wrapping each affected function body between calls to the library:

  try
    {
      _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
      /* procedure body goes here */
    }
  finally
    {
      _gfortran_ieee_procedure_exit ((void *) &fpstate.0);
    }



What’s missing:

  0. Gradual underflow control is implemented as "not supported by the processor" (its SUPPORT function returns false, and the GET and SET procedures abort if you call them). That’s explicitly allowed by the standard, so it’s not actually “missing". We can improve on this in the future, if people can help.

  1. Documenting the flags necessary for full IEEE compatibility: it seems that "-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans” is good, but I’ll have to check that with the floating-point middle-end experts. That’s next on my list: documenting our support, and interaction with compilation flags.

  2. Your review of the patch!


I really think getting IEEE support early in stage 1 will benefit the compiler, through good testing before release. I’d like to get this in, but I don’t intend to disappear afterwards… though I’m stepping back “full time” into the team, I will be there to fix IEEE bugs and issues.

OK to commit?

FX




ieee.ChangeLog (2K) Download Attachment
ieee.diff (144K) Download Attachment
ieee_withregenerated.diff (163K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules

Janne Blomqvist-3
On Thu, Jun 5, 2014 at 1:04 AM, FX <[hidden email]> wrote:
>   2. Your review of the patch!

Not a full review, just a few quick comments.

- Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
symbol node, as you're the first one to export new symbols in the 4.10
cycle. I've seen occasional confusion from users when they have symbol
version mismatches and e.g. "1.4" doesn't match any version they've
seen before. So I think it might be better to switch to a scheme where
the symbol node name matches the compiler version, i.e. GFORTRAN_4.10.

- Many of the intrinsics are just thin wrappers around
__builtin_foo(). Couldn't these be generated inline instead?


> I really think getting IEEE support early in stage 1 will benefit the compiler, through good testing before release.

I agree, IEEE support seems to be one of the most commonly requested
features. Thanks for all the hard work on this.





--
Janne Blomqvist
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules

Uros Bizjak-3
In reply to this post by FX Coudert
Hello!

> +int
>  get_fpu_except_flags (void)
>  {
>    unsigned short cw;
>    int excepts;
>    int result = 0;
>
> -  __asm__ __volatile__ ("fnstsw\t%0" : "=a" (cw));
> +  __asm__ __volatile__ ("fnstsw\t%0" : "=m" (cw));
>    excepts = cw;
>
>    if (has_sse())

You can use "=am" constraint here, and the compiler will be free to
choose the most appropriate form.

Also, you should use __asm__ __volatile__ consistently in the headers.

Uros.
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules

Rainer Orth-2
In reply to this post by Janne Blomqvist-3
Janne Blomqvist <[hidden email]> writes:

> On Thu, Jun 5, 2014 at 1:04 AM, FX <[hidden email]> wrote:
>>   2. Your review of the patch!
>
> Not a full review, just a few quick comments.
>
> - Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
> symbol node, as you're the first one to export new symbols in the 4.10
> cycle. I've seen occasional confusion from users when they have symbol
> version mismatches and e.g. "1.4" doesn't match any version they've
> seen before. So I think it might be better to switch to a scheme where
> the symbol node name matches the compiler version, i.e. GFORTRAN_4.10.

Except libgcc_s.so.1, none of the other GCC runtime libraries does
that.  Changing schemes in the middle is going to be even more confusing
than staying with what we have here.  The only other reasonable scheme
is what libgomp.so.1 does, namely naming the versions after the OpenMP
standard they implement.

        Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules

FX Coudert
In reply to this post by Janne Blomqvist-3
Hi Janne,

Thanks for the quick feedback.

> - Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
> symbol node, as you're the first one to export new symbols in the 4.10
> cycle. I've seen occasional confusion from users when they have symbol
> version mismatches and e.g. "1.4" doesn't match any version they've
> seen before. So I think it might be better to switch to a scheme where
> the symbol node name matches the compiler version, i.e. GFORTRAN_4.10.

I don’t have an opinion on that, I’ll follow what you settle on.


> - Many of the intrinsics are just thin wrappers around
> __builtin_foo(). Couldn't these be generated inline instead?

They could, but… having them in the library allows to rely on its mechanism for detection of features, providing IEEE modules and functions only when we actually support them. I’m open to moving some of the IEEE handling towards the front-end, but we need to think clearly about that…

FX
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules

Uros Bizjak-3
In reply to this post by FX Coudert
Hello!

> 0. Gradual underflow control is implemented as "not supported by the processor" (its SUPPORT
> function returns false, and the GET and SET procedures abort if you call them). That’s explicitly
> allowed by the standard, so it’s not actually “missing". We can improve on this in the future, if
> people can help.

Please look at libgcc/config/i386/crtfastmath.c for how to set
MXCSR_FTZ from mxcsr. You already have all necessary bits in place,
the function is basically only:

+  if (has_sse())
+  {
+    unsigned int cw_sse;
+
+    __asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (cw_sse));
+    cw_sse |= MXCSR_DAZ;
+    __asm__ __volatile__ ("%vldmxcsr\t%0" : : "m" (cw_sse));
+  }

Please note, that FTZ applies only to SSE math. x87 and (IIRC) soft-FP
don't handle this setting.

Uros.
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules

FX Coudert
> Please look at libgcc/config/i386/crtfastmath.c for how to set
> MXCSR_FTZ from mxcsr. You already have all necessary bits in place,
> the function is basically only:
>
> +  if (has_sse())
> +  {
> +    unsigned int cw_sse;
> +
> +    __asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (cw_sse));
> +    cw_sse |= MXCSR_DAZ;
> +    __asm__ __volatile__ ("%vldmxcsr\t%0" : : "m" (cw_sse));
> +  }

Thanks for the suggestion!


> Please note, that FTZ applies only to SSE math. x87 and (IIRC) soft-FP
> don't handle this setting.

Yeah, that’s also why I prefer for now to have it declared as unsupported: the Fortran standard doesn’t really allow for partial support such as this, so I’m still trying to figure out what The Right Thing To Do is.

FX
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules

Uros Bizjak-3
On Thu, Jun 5, 2014 at 11:35 AM, FX <[hidden email]> wrote:

>> Please look at libgcc/config/i386/crtfastmath.c for how to set
>> MXCSR_FTZ from mxcsr. You already have all necessary bits in place,
>> the function is basically only:
>>
>> +  if (has_sse())
>> +  {
>> +    unsigned int cw_sse;
>> +
>> +    __asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (cw_sse));
>> +    cw_sse |= MXCSR_DAZ;
>> +    __asm__ __volatile__ ("%vldmxcsr\t%0" : : "m" (cw_sse));
>> +  }

Oops, the above should read MXCSR_FTZ.

> Thanks for the suggestion!
>
>
>> Please note, that FTZ applies only to SSE math. x87 and (IIRC) soft-FP
>> don't handle this setting.
>
> Yeah, that’s also why I prefer for now to have it declared as unsupported: the Fortran standard doesn’t really allow for partial support such as this, so I’m still trying to figure out what The Right Thing To Do is.

Referring to some older mails [1], this looks like a performance-only
setting (sort of fast-math). So, we can perhaps just set this bit,
regardless of the details. Maybe soft-fp will grow support for FTZ
sometime, it looks like a useful addition from the performance POV.

[1] https://gcc.gnu.org/ml/fortran/2013-11/msg00133.html

Uros.
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules

Rainer Orth-2
In reply to this post by Rainer Orth-2
Rainer Orth <[hidden email]> writes:

> Janne Blomqvist <[hidden email]> writes:
>
>> On Thu, Jun 5, 2014 at 1:04 AM, FX <[hidden email]> wrote:
>>>   2. Your review of the patch!
>>
>> Not a full review, just a few quick comments.
>>
>> - Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
>> symbol node, as you're the first one to export new symbols in the 4.10
>> cycle. I've seen occasional confusion from users when they have symbol
>> version mismatches and e.g. "1.4" doesn't match any version they've
>> seen before. So I think it might be better to switch to a scheme where
>> the symbol node name matches the compiler version, i.e. GFORTRAN_4.10.
>
> Except libgcc_s.so.1, none of the other GCC runtime libraries does
> that.  Changing schemes in the middle is going to be even more confusing
> than staying with what we have here.  The only other reasonable scheme
> is what libgomp.so.1 does, namely naming the versions after the OpenMP
> standard they implement.

Besides, the request constitues a fundamental misunderstanding how
interface (and symbol) versioning work.  I bet those same users clamour
to change the SONAME from libgfortran.so.3 to .so.4 to match the GCC
major version ;-(  Tell them to read up on interface vs. release
versioning in the libtool manual; symbol versioning is just a more
granular version of interface versioning.

Imagine the next version of gcc is called 5.0 instead of 4.10.  Would
you change the SONAME to .so.5 (suggesting an incompatible change) and
interface version to GFORTRAN_5.0 even if no symbols were added?

        Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules

Janne Blomqvist-3
On Thu, Jun 5, 2014 at 1:13 PM, Rainer Orth <[hidden email]> wrote:

> Rainer Orth <[hidden email]> writes:
>
>> Janne Blomqvist <[hidden email]> writes:
>>
>>> On Thu, Jun 5, 2014 at 1:04 AM, FX <[hidden email]> wrote:
>>>>   2. Your review of the patch!
>>>
>>> Not a full review, just a few quick comments.
>>>
>>> - Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
>>> symbol node, as you're the first one to export new symbols in the 4.10
>>> cycle. I've seen occasional confusion from users when they have symbol
>>> version mismatches and e.g. "1.4" doesn't match any version they've
>>> seen before. So I think it might be better to switch to a scheme where
>>> the symbol node name matches the compiler version, i.e. GFORTRAN_4.10.
>>
>> Except libgcc_s.so.1, none of the other GCC runtime libraries does
>> that.  Changing schemes in the middle is going to be even more confusing
>> than staying with what we have here.  The only other reasonable scheme
>> is what libgomp.so.1 does, namely naming the versions after the OpenMP
>> standard they implement.

libgcc_s and glibc seem to use such a scheme, suggesting that
competently maintained libraries can choose to do it that way.

> Besides, the request constitues a fundamental misunderstanding how
> interface (and symbol) versioning work.

Considering that yours truly was the one who originally added symbol
versioning to libgfortran, I dare claim that I have at least a
superficial understanding how it works, thank you very much. Back then
there was some discussion what kind of versioning scheme to use, and I
arbitrarily chose the current one.

>  I bet those same users clamour
> to change the SONAME from libgfortran.so.3 to .so.4 to match the GCC
> major version ;-(

I haven't seen that particular complaint, but it's of course possible
that somebody complains about that.

>  Tell them to read up on interface vs. release
> versioning in the libtool manual; symbol versioning is just a more
> granular version of interface versioning.

I think it's quite infeasible to get most GFortran users to care for,
much less learn about, such a topic.

> Imagine the next version of gcc is called 5.0 instead of 4.10.  Would
> you change the SONAME to .so.5 (suggesting an incompatible change)

No, duh?

> and
> interface version to GFORTRAN_5.0 even if no symbols were added?

No, why would a new symbol node be added if no actual symbols are added?

Now, where I see a minor trouble is that if we first add a symbol node
"GFORTRAN_4.10", and then later on it is decided that the next release
will be 5.0. So then we should change the name of the symbol node to
match, which might cause issues for people who have been building
against trunk versions. But I guess that is par for the course when
using trunk.



--
Janne Blomqvist
Reply | Threaded
Open this post in threaded view
|

[fortran, patch] IEEE intrinsic modules (ping)

FX Coudert
In reply to this post by Uros Bizjak-3
ping for the IEEE patch.

Since last time, I incorporated Uros’ comments on the libgfortran/config/fpu-387.h part, and add some documentation to the manual (list of supported targets, and required compilation flags for full IEE support).

OK to commit?
I’d really like to get this into trunk, so it can get some exposure to iron it out…

FX



> Hi,
>
> Last November, I worked on a patch to add the IEEE intrinsic modules to gfortran (thread starting at
> https://gcc.gnu.org/ml/fortran/2013-11/msg00126.html
> ). After a round of review, I continued working on it, then didn’t have time, then development was frozen… Now, I found some time to get back to it, and here’s a more complete patch. I’ve bootstrapped it and regtested on:
>
>   – x86_64-linux (both 32-bit and 64-bit); this also uses 387/SSE assembler
>   – x86_64-linux with tweaked configure.host to force it to use glibc functions in config/fpu-glibc.h (both 32-bit and 64-bit)
>
> The current state of the patch: as far as I can tell, nearly full support. In particular, since my last patch, I’ve added “saving/restoring FPU state on procedure entry/exit, when IEEE is used”. This is done in trans-decl.c, by wrapping each affected function body between calls to the library:
>
>   try
>     {
>       _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
>       /* procedure body goes here */
>     }
>   finally
>     {
>       _gfortran_ieee_procedure_exit ((void *) &fpstate.0);
>     }
>
>
>
> What’s missing:
>
>   0. Gradual underflow control is implemented as "not supported by the processor" (its SUPPORT function returns false, and the GET and SET procedures abort if you call them). That’s explicitly allowed by the standard, so it’s not actually “missing". We can improve on this in the future, if people can help.
>
>   1. Documenting the flags necessary for full IEEE compatibility: it seems that "-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans” is good, but I’ll have to check that with the floating-point middle-end experts. That’s next on my list: documenting our support, and interaction with compilation flags.
>
>   2. Your review of the patch!
>
>
> I really think getting IEEE support early in stage 1 will benefit the compiler, through good testing before release. I’d like to get this in, but I don’t intend to disappear afterwards… though I’m not stepping back “full time” into the team, I will be there to fix IEEE bugs and issues.
>
> OK to commit?
>
> FX


ieee_2.ChangeLog (2K) Download Attachment
ieee_2.diff (146K) Download Attachment
ieee_withregenerated_2.diff (165K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules (ping)

FX Coudert
ping*2

I understand the size of the patch can be somewhat off-putting, but given its nature it’s rather hard to split it further. Moreover, apart from the OS-specific bits on the library side, it’s not very difficult. If it is hard for anyone to find time to review it in full, may I suggest that it be given a lighter review before commit… then while it gets some real exposure from users/testers, further review can be performed.

FX




> ping for the IEEE patch.
>
> Since last time, I incorporated Uros’ comments on the libgfortran/config/fpu-387.h part, and add some documentation to the manual (list of supported targets, and required compilation flags for full IEE support).
>
> OK to commit?
> I’d really like to get this into trunk, so it can get some exposure to iron it out…
>
> FX
>
>
>
>> Hi,
>>
>> Last November, I worked on a patch to add the IEEE intrinsic modules to gfortran (thread starting at
>> https://gcc.gnu.org/ml/fortran/2013-11/msg00126.html
>> ). After a round of review, I continued working on it, then didn’t have time, then development was frozen… Now, I found some time to get back to it, and here’s a more complete patch. I’ve bootstrapped it and regtested on:
>>
>>  – x86_64-linux (both 32-bit and 64-bit); this also uses 387/SSE assembler
>>  – x86_64-linux with tweaked configure.host to force it to use glibc functions in config/fpu-glibc.h (both 32-bit and 64-bit)
>>
>> The current state of the patch: as far as I can tell, nearly full support. In particular, since my last patch, I’ve added “saving/restoring FPU state on procedure entry/exit, when IEEE is used”. This is done in trans-decl.c, by wrapping each affected function body between calls to the library:
>>
>>  try
>>    {
>>      _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
>>      /* procedure body goes here */
>>    }
>>  finally
>>    {
>>      _gfortran_ieee_procedure_exit ((void *) &fpstate.0);
>>    }
>>
>>
>>
>> What’s missing:
>>
>>  0. Gradual underflow control is implemented as "not supported by the processor" (its SUPPORT function returns false, and the GET and SET procedures abort if you call them). That’s explicitly allowed by the standard, so it’s not actually “missing". We can improve on this in the future, if people can help.
>>
>>  1. Documenting the flags necessary for full IEEE compatibility: it seems that "-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans” is good, but I’ll have to check that with the floating-point middle-end experts. That’s next on my list: documenting our support, and interaction with compilation flags.
>>
>>  2. Your review of the patch!
>>
>>
>> I really think getting IEEE support early in stage 1 will benefit the compiler, through good testing before release. I’d like to get this in, but I don’t intend to disappear afterwards… though I’m not stepping back “full time” into the team, I will be there to fix IEEE bugs and issues.
>>
>> OK to commit?
>>
>> FX


ieee_2.ChangeLog (2K) Download Attachment
ieee_2.diff (146K) Download Attachment
ieee_withregenerated_2.diff (165K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules (ping)

Steve Kargl
I meant to look this over this weekend.  Unfortnately, baseball
and soccer (both daughter and USA vs Portugal) got in the way.
First issue,

cd gcc4x
patch < ieee_withregenerated_2.diff
...
--------------------------
|Index: configure.host
|===================================================================
|--- configure.host     (revision 211688)
|+++ configure.host     (working copy)
--------------------------
File to patch: libgfortran/configure.host
Patching file libgfortran/configure.host using Plan A...
patch: **** malformed patch at line 939: then

As I don't have a top-level configure.host, I guessed that
libgfortran/configure.host was the right file.

All other parts of the patch applied cleanly.

--
steve

On Mon, Jun 23, 2014 at 10:39:30AM +0200, FX wrote:

> ping*2
>
> I understand the size of the patch can be somewhat off-putting, but given its nature it?s rather hard to split it further. Moreover, apart from the OS-specific bits on the library side, it?s not very difficult. If it is hard for anyone to find time to review it in full, may I suggest that it be given a lighter review before commit? then while it gets some real exposure from users/testers, further review can be performed.
>
> FX
>
>
>
>
> > ping for the IEEE patch.
> >
> > Since last time, I incorporated Uros? comments on the libgfortran/config/fpu-387.h part, and add some documentation to the manual (list of supported targets, and required compilation flags for full IEE support).
> >
> > OK to commit?
> > I?d really like to get this into trunk, so it can get some exposure to iron it out?
> >
> > FX
> >
> >
> >
> >> Hi,
> >>
> >> Last November, I worked on a patch to add the IEEE intrinsic modules to gfortran (thread starting at
> >> https://gcc.gnu.org/ml/fortran/2013-11/msg00126.html
> >> ). After a round of review, I continued working on it, then didn?t have time, then development was frozen? Now, I found some time to get back to it, and here?s a more complete patch. I?ve bootstrapped it and regtested on:
> >>
> >>  ? x86_64-linux (both 32-bit and 64-bit); this also uses 387/SSE assembler
> >>  ? x86_64-linux with tweaked configure.host to force it to use glibc functions in config/fpu-glibc.h (both 32-bit and 64-bit)
> >>
> >> The current state of the patch: as far as I can tell, nearly full support. In particular, since my last patch, I?ve added ?saving/restoring FPU state on procedure entry/exit, when IEEE is used?. This is done in trans-decl.c, by wrapping each affected function body between calls to the library:
> >>
> >>  try
> >>    {
> >>      _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
> >>      /* procedure body goes here */
> >>    }
> >>  finally
> >>    {
> >>      _gfortran_ieee_procedure_exit ((void *) &fpstate.0);
> >>    }
> >>
> >>
> >>
> >> What?s missing:
> >>
> >>  0. Gradual underflow control is implemented as "not supported by the processor" (its SUPPORT function returns false, and the GET and SET procedures abort if you call them). That?s explicitly allowed by the standard, so it?s not actually ?missing". We can improve on this in the future, if people can help.
> >>
> >>  1. Documenting the flags necessary for full IEEE compatibility: it seems that "-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans? is good, but I?ll have to check that with the floating-point middle-end experts. That?s next on my list: documenting our support, and interaction with compilation flags.
> >>
> >>  2. Your review of the patch!
> >>
> >>
> >> I really think getting IEEE support early in stage 1 will benefit the compiler, through good testing before release. I?d like to get this in, but I don?t intend to disappear afterwards? though I?m not stepping back ?full time? into the team, I will be there to fix IEEE bugs and issues.
> >>
> >> OK to commit?
> >>
> >> FX
>
>





--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules (ping)

Steve Kargl
On Mon, Jun 23, 2014 at 12:23:39PM -0700, Steve Kargl wrote:

> I meant to look this over this weekend.  Unfortnately, baseball
> and soccer (both daughter and USA vs Portugal) got in the way.
> First issue,
>
> cd gcc4x
> patch < ieee_withregenerated_2.diff
> ...
> --------------------------
> |Index: configure.host
> |===================================================================
> |--- configure.host     (revision 211688)
> |+++ configure.host     (working copy)
> --------------------------
> File to patch: libgfortran/configure.host
> Patching file libgfortran/configure.host using Plan A...
> patch: **** malformed patch at line 939: then
>
> As I don't have a top-level configure.host, I guessed that
> libgfortran/configure.host was the right file.
>

Ignoring this chunk, one doesn't get very far with building gcc. :(

if [ xinfo = xinfo ]; then \
  rm -f doc/gfortran.info-*; \
  makeinfo --split-size=5000000 --split-size=5000000 -I ../../gcc4x/gcc/doc/include -I ../../gcc4x/gcc/fortran \
    -o doc/gfortran.info ../../gcc4x/gcc/fortran/gfortran.texi; \
else true; fi
../../gcc4x/gcc/fortran//intrinsic.texi:13399: Prev reference to nonexistent node `IEEE_EXCEPTIONS' (perhaps incorrect sectioning?).
../../gcc4x/gcc/fortran//intrinsic.texi:13372: Next reference to nonexistent node `IEEE_ARITHMETIC' (perhaps incorrect sectioning?).
../../gcc4x/gcc/fortran//intrinsic.texi:13372: Prev reference to nonexistent node `and IEEE_FEATURES' (perhaps incorrect sectioning?).
../../gcc4x/gcc/fortran//intrinsic.texi:13372: `IEEE modules: IEEE_EXCEPTIONS' has no Up field (perhaps incorrect sectioning?).
../../gcc4x/gcc/fortran//intrinsic.texi:13275: Next reference to nonexistent node `IEEE_EXCEPTIONS' (perhaps incorrect sectioning?).
../../gcc4x/gcc/fortran//intrinsic.texi:13158: Menu reference to nonexistent node `IEEE_EXCEPTIONS' (perhaps incorrect sectioning?).
../../gcc4x/gcc/fortran//intrinsic.texi:13372: warning: unreferenced node `IEEE modules: IEEE_EXCEPTIONS'.
makeinfo: Removing output file `doc/gfortran.info' due to errors; use --force to preserve.
gmake[2]: *** [doc/gfortran.info] Error 1
gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj4x/gcc'
gmake[1]: *** [all-gcc] Error 2
gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj4x'
gmake: *** [all] Error 2
laptop-kargl:kargl[239] pwd


--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules (ping)

FX Coudert
Here’s a patch fixing the diff issue with configure.host and the doc (which apparently is only triggered by some versions of texinfo).
Apart from that, functionnaly identical, so I’ll paste here the “history” of the patch:

---------------------------------------------------

Since last time, I incorporated Uros’ comments on the libgfortran/config/fpu-387.h part, and add some documentation to the manual (list of supported targets, and required compilation flags for full IEE support).

OK to commit?

FX



> Hi,
>
> Last November, I worked on a patch to add the IEEE intrinsic modules to gfortran (thread starting at
> https://gcc.gnu.org/ml/fortran/2013-11/msg00126.html
> ). After a round of review, I continued working on it, then didn’t have time, then development was frozen… Now, I found some time to get back to it, and here’s a more complete patch. I’ve bootstrapped it and regtested on:
>
>  – x86_64-linux (both 32-bit and 64-bit); this also uses 387/SSE assembler
>  – x86_64-linux with tweaked configure.host to force it to use glibc functions in config/fpu-glibc.h (both 32-bit and 64-bit)
>
> The current state of the patch: as far as I can tell, nearly full support. In particular, since my last patch, I’ve added “saving/restoring FPU state on procedure entry/exit, when IEEE is used”. This is done in trans-decl.c, by wrapping each affected function body between calls to the library:
>
>  try
>    {
>      _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
>      /* procedure body goes here */
>    }
>  finally
>    {
>      _gfortran_ieee_procedure_exit ((void *) &fpstate.0);
>    }
>
>
>
> What’s missing:
>
>  0. Gradual underflow control is implemented as "not supported by the processor" (its SUPPORT function returns false, and the GET and SET procedures abort if you call them). That’s explicitly allowed by the standard, so it’s not actually “missing". We can improve on this in the future, if people can help.
>
>  1. Documenting the flags necessary for full IEEE compatibility: it seems that "-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans” is good, but I’ll have to check that with the floating-point middle-end experts. That’s next on my list: documenting our support, and interaction with compilation flags.
>
>  2. Your review of the patch!
>
>
> I really think getting IEEE support early in stage 1 will benefit the compiler, through good testing before release. I’d like to get this in, but I don’t intend to disappear afterwards… though I’m not stepping back “full time” into the team, I will be there to fix IEEE bugs and issues.
>
> OK to commit?
>
> FX







ieee_2.ChangeLog (2K) Download Attachment
ieee_withregenerated_2.diff (165K) Download Attachment
ieee_2.diff (146K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules (ping)

Steve Kargl
On Tue, Jun 24, 2014 at 10:11:32AM +0200, FX wrote:
> Here?s a patch fixing the diff issue with configure.host and the doc (which apparently is only triggered by some versions of texinfo).
> Apart from that, functionnaly identical, so I?ll paste here the ?history? of the patch:
>
> ---------------------------------------------------
>
> Since last time, I incorporated Uros? comments on the libgfortran/config/fpu-387.h part, and add some documentation to the manual (list of supported targets, and required compilation flags for full IEE support).
>
> OK to commit?
>

Not yet.

On i386-*-freebsd

In file included from ../../../gcc4x/libgfortran/runtime/fpu.c:29:0:
./fpu-target.h: In function 'set_fpu_trap_exceptions':
./fpu-target.h:31:3: error: unknown type name 'fp_except'
   fp_except cw = fpgetmask();

...

gmake[3]: *** [fpu.lo] Error 1
gmake[3]: Leaving directory `/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd11.0/libgfortran'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd11.0/libgfortran'
gmake[1]: *** [all-target-libgfortran] Error 2
gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj4x'

Looking at the libgfortran/config.log shows that there is an error
in the config test for fp_except_t.


configure:26048: checking for fp_except
configure:26048: /home/kargl/gcc/obj4x/./gcc/xgcc -B/home/kargl/gcc/obj4x/./gcc/ -B/home/kargl/work/i386-unknown-freebsd11.0/bin/ -B/home/kargl/work/i386-unknown-freebsd11.0/lib/ -isystem /home/kargl/work/i386-unknown-freebsd11.0/include -isystem /home/kargl/work/i386-unknown-freebsd11.0/sys-include    -c -std=gnu11 -g -O2  conftest.c >&5
conftest.c: In function 'main':
conftest.c:261:13: error: 'fp_except' undeclared (first use in this function)
 if (sizeof (fp_except))
             ^
conftest.c:261:13: note: each undeclared identifier is reported only once for each function it appears in
configure:26048: $? = 1
configure: failed program was:

...

configure:26061: /home/kargl/gcc/obj4x/./gcc/xgcc -B/home/kargl/gcc/obj4x/./gcc/ -B/home/kargl/work/i386-unknown-freebsd11.0/bin/ -B/home/kargl/work/i386-unknown-freebsd11.0/lib/ -isystem /home/kargl/work/i386-unknown-freebsd11.0/include -isystem /home/kargl/work/i386-unknown-freebsd11.0/sys-include    -c -std=gnu11 -g -O2  conftest.c >&5
conftest.c: In function 'main':
conftest.c:261:26: error: expected expression before ')' token
 if (sizeof ((fp_except_t)))
                          ^
configure:26061: $? = 1
configure: failed program was:
| /* confdefs.h */

Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules (ping)

Steve Kargl
On Tue, Jun 24, 2014 at 09:49:36AM -0700, Steve Kargl wrote:

>
> Not yet.
>
> On i386-*-freebsd
>
> In file included from ../../../gcc4x/libgfortran/runtime/fpu.c:29:0:
> ./fpu-target.h: In function 'set_fpu_trap_exceptions':
> ./fpu-target.h:31:3: error: unknown type name 'fp_except'
>    fp_except cw = fpgetmask();
>

The (autogenerated?) fpu-target. h is totally bogus on FreeBSD.
The file includes things like

void
get_fpu_state (void *s)
{
  fpu_state_t *state = s;

  /* Check we can actually store the FPU state in the allocated size.  */
  assert (sizeof(fpu_state_t) <= GFC_FPE_STATE_BUFFER_SIZE);

  s->mask = fpgetmask ();
  s->sticky = fpgetsticky ();
  s->round = fpgetround ();
}

The s-> in the last 3 lines should be state->.
There are several places where fp_except and fp_rnd are used
unconditionally.  On FreeBSD (and perhaps other *BSD), there
is no fpsetsticky().  The function is fpresetsticky().

--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules (ping)

Tobias Burnus
Steve Kargl wrote:
> On FreeBSD (and perhaps other *BSD), there is no fpsetsticky().  The function is fpresetsticky().

Solaris has fpsetsticky() (requires ieeefp.h) and BSD has
fpresetsticky() – thus, like at other places in that file, one needs to
conditionally enable one or the other.

Tobias
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules (ping)

Steve Kargl
On Tue, Jun 24, 2014 at 08:34:23PM +0200, Tobias Burnus wrote:
> Steve Kargl wrote:
> > On FreeBSD (and perhaps other *BSD), there is no fpsetsticky().  The function is fpresetsticky().
>
> Solaris has fpsetsticky() (requires ieeefp.h) and BSD has
> fpresetsticky() ? thus, like at other places in that file, one needs to
> conditionally enable one or the other.
>

I suppose I don't understand the logic in libgfortran/configure.host.
It is picking the wrong config/fpu*.h file.

gmake |& tee sgk.log

shows (long lines wrapped)

cp ../../../gcc4x/libgfortran/config/fpu-sysv.h fpu-target.h
grep '^#define GFC_FPE_' < ../../../gcc4x/libgfortran/../gcc/fortran/\
     libgfortran.h > fpu-target.inc || true
grep '^#define GFC_FPE_' < ../../../gcc4x/libgfortran/libgfortran.h \
     >> fpu-target.inc || true
gmake  all-am


FreeBSD (and the other *BSD) have both feenbleexcept() and
fpsetmask(), but neither check is correct. It seems the check
for feenableexcept assumes glibc and fpsetmask assumes SysV
system.


--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: [fortran, patch] IEEE intrinsic modules (ping)

FX Coudert
Hi Steve,

Thanks for testing on a platform I don’t have access to! I try to answer to the three main points below:

> I suppose I don't understand the logic in libgfortran/configure.host.
> It is picking the wrong config/fpu*.h file.

1. This is a preexisting bug, then. Currently, we have 4 versions of the FPU-specific code:

  — fpu-glibc.h works on any platform that has C99 fenv.h + feenableexcept(), fedisableexcept() & fegetexcept() extensions
  — fpu-387.h aims at x86/x86_64 systems, and should have priority over fpu-glibc.h (because it allows for control of denormals, which the above does not have)
  — fpu-aix.h requires C99 fenv.h + many AIX extensions (fp_trap(), fp_enable(), fp_disable(), fp_is_enabled(), fp_invalid_op())
  — fpu-sysv.h requires many SysV function calls: fpgetmask(), fpgetround(), fpgetsticky(), etc.

The logic in configure.host clearly does not accomodate targets who have two styles of calls. I think it should be moved around so that the order of priority is aix < sysv < glibc < 387.

> FreeBSD (and the other *BSD) have both feenbleexcept() and
> fpsetmask(), but neither check is correct. It seems the check
> for feenableexcept assumes glibc and fpsetmask assumes SysV
> system.

2. How does the check fail? What does the config.log say? It looks like a pretty generic check in configure.ac:

AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])

checking only if libc or libm contain any call to a feenableexcept() function. Is it a macro on FreeBSD?


3. Does the attached updated patch (libgfortran only, without regenerated files) fix the problem?

FX




123