Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
Le 11/09/2022 à 11:57, FX a écrit : As a first step, one could check the use rename lists; what's done for iso_fortran_env can be used as an example. Yes, but iso_fortran_env is handled entirely in front-end, not through external files. That's true, but the standard check doesn't really depend on that. It only needs the u->use_name for each use rename u.
Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
Hi Mikael, > As a first step, one could check the use rename lists; what's done for > iso_fortran_env can be used as an example. Yes, but iso_fortran_env is handled entirely in front-end, not through external files. This is what I plan to do when migrating the IEEE modules to front-end, but it is a big task. > Another possibility is mimicking or modifying gfc_resolve_intrinsic, which > already does a similar job for intrinsic procedures. That’s probably the best place to put it for now, indeed. Thanks for the advice. FX
Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
Le 10/09/2022 à 12:14, FX via Fortran a écrit : If you have a solution for the standards checking, I’ll add it. As a first step, one could check the use rename lists; what's done for iso_fortran_env can be used as an example. To diagnose the other usages, the check could be put in resolve_symbol but it would diagnose it even if not used, so one can add a check on attr.referenced (I hope it can be relied upon). Another possibility is mimicking or modifying gfc_resolve_intrinsic, which already does a similar job for intrinsic procedures. I hope this helps.
Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
> Actuelly, that does not work. gfc_notify_std() should not be used at > code-generation time, but in matching or setting-up symbols. It is never used > in trans-* files, so I do not think I should introduce it now. > > Any hard objection to committing as it is? In the middle term, I intend to > revamp this part anyway, as I said in my previous email. I’ve committed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7c4c65d11469d29403d5a88316445ec95cd3c3f8 If you have a solution for the standards checking, I’ll add it. I will finish my series of IEEE-related patches, then intend to document the current state of things once the dust has settled. FX
Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
Hi Thomas, >> Both of these functions are new with Fortran 2018, could you add >> a standards version check? > > Thanks Thomas, I will do that and post here the commit diff. The check will > not be perfect, though, because the warning/error cannot be emitted when > loading the module (because it’s in an external file), but will have to be > when the call is actually emitted. Actuelly, that does not work. gfc_notify_std() should not be used at code-generation time, but in matching or setting-up symbols. It is never used in trans-* files, so I do not think I should introduce it now. Any hard objection to committing as it is? In the middle term, I intend to revamp this part anyway, as I said in my previous email. Thanks, FX
Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
Hi, > Both of these functions are new with Fortran 2018, could you add > a standards version check? Thanks Thomas, I will do that and post here the commit diff. The check will not be perfect, though, because the warning/error cannot be emitted when loading the module (because it’s in an external file), but will have to be when the call is actually emitted. This means that loading a symbol and not using it will not trigger the error it should, but we cannot do better in the current scheme. IEEE modules will need to be fully moved to the front-end at some point, bécause F2018 added two procedures that cannot be described in a Fortran module (functions whose return kind is described by an optional KIND argument). - IEEE_INT (A, ROUND [, KIND]) - IEEE_REAL (A [, KIND]) But emitting all the symbols in the front-end is a huge work, and there are some cases I do not know how to handle. FX
Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
Hi FX, Maybe the ping is a bit early, as you know I’m not very active anymore, so I do not know what are the current policies. In particular, how much leeway do I have to commit the patch if there is no comment from another maintainer? I am fairly confident about the code, because I wrote the original IEEE implementation so I know it very well. I believe it would probably be better to commit this and have it tested on mainline, that wait for too long. I intend to submit further patches and improvements in this area, once those are merged. Looks good in principle. Just a couple of remarks: Both of these functions are new with Fortran 2018, could you add a standards version check? And, more general: I don't think we document which part of the IEEE arithmetic we support. It might be a good idea to add that to the manual (but not for this patch). So, OK with the version check. Best regards Thomas
Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
ping on that patch from last week Maybe the ping is a bit early, as you know I’m not very active anymore, so I do not know what are the current policies. In particular, how much leeway do I have to commit the patch if there is no comment from another maintainer? I am fairly confident about the code, because I wrote the original IEEE implementation so I know it very well. I believe it would probably be better to commit this and have it tested on mainline, that wait for too long. I intend to submit further patches and improvements in this area, once those are merged. Best, FX > Le 31 août 2022 à 16:22, FX a écrit : > > Hum, slightly amended patch, after checking 32-bit results on another linux > machine. > The test for FMA has been made a bit less strict, because otherwise we have > surprised on 387 arithmetic due to excess precision. > > Final patch is attached. Regression-tested on x86_64-pc-linux-gnu, both 32- > and 64-bit. > OK to commit? > > FX > > <0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch>
Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
Hum, slightly amended patch, after checking 32-bit results on another linux machine. The test for FMA has been made a bit less strict, because otherwise we have surprised on 387 arithmetic due to excess precision. Final patch is attached. Regression-tested on x86_64-pc-linux-gnu, both 32- and 64-bit. OK to commit? FX 0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch Description: Binary data
[PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
Hi, These functions were added in Fortran 2018: https://gcc.gnu.org/wiki/Fortran2018Status When it comes to floating-point and IEEE compliance, gfortran fully implements the 2003 and 2008 standards. In a series of patch, as time permits, I would like to add all Fortran 2018 features before the GCC 13 release process begins. Regarding this patch, the functions are added to the IEEE_ARITHMETIC module, but are entirely expanded in the front-end, using GCC built-ins. They will benefit fully from middle-end optimisation where relevant, and on many targets FMA will reduce to a single instruction (as expected). Regression-tested on x86_64-pc-linux-gnu. OK to commit? FX 0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch Description: Binary data
