[PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

[FX via Gcc-patches]

Hi,

This patch adds four IEEE functions from the Fortran 2018 standard: 
IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, and IEEE_MAX_NUM_MAG.

Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 and 64-bit. OK to 
commit?

FX



0001-Fortran-add-Fortran-2018-IEEE_-MIN-MAX-functions.patch
Description: Binary data

Re: [PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

Hi,

> Joseph's reply earlier in this thread has indicated a desire to verify that 
> verifies FE_INVALID is raised when appropriate and not raised when 
> inappropriate when the arguments come from volatile variables rather than 
> directly from constants.
> 
> The patch itself looks pretty reasonable.  So let's get the testing coverage 
> Joseph wanted so we can move forward.

Sadly, while I had some time to deal with it when the patch was originally 
submitted, once the review came back my hands were full and right now I cannot 
find time. I hope someone can pick it up and finish, otherwise it will have to 
wait for the next version.

FX

Re: [PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

Hi,

Just adding, from the Fortran 2018 perspective, things we will need to 
implement for which I think support from the middle-end might be necessary:

- rounded conversions: converting, from an integer or floating point type, into 
another floating point type, with specific rounding mode passed as argument
- conversion to integer: converting, from a floating point type, into an 
integer type, with specific rounding mode passed as argument
- IEEE operations corresponding to nextDown and nextUp (or are those already 
available? I have not checked the fine print)

I would like to add them all for GCC 13.

FX

Re: [PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

ping*3
please?


> Le 21 sept. 2022 à 11:40, FX  a écrit :
> 
> ping*2
> 
> <0001-Add-__builtin_iseqsig.patch>
> 
>> Le 9 sept. 2022 à 19:55, FX  a écrit :
>> 
>> ping
>> 
>> 
>>> Le 1 sept. 2022 à 23:02, FX  a écrit :
>>> 
>>> Attached patch adds __builtin_iseqsig() to the middle-end and C family 
>>> front-ends.
>>> Testing does not currently check whether the signaling part works, because 
>>> with optimisation is actually does not (preexisting compiler bug: 
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)
>>> 
>>> Bootstrapped and regtested on x86_64-linux.
>>> OK to commit?
>>> 
>>> (I’m not very skilled for middle-end hacking, so I’m sure there will be 
>>> modifications to make.)
>>> 
>>> FX
>>> <0001-Add-__builtin_iseqsig.patch>
>> 
> 

Re: [PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

ping*2



0001-Add-__builtin_iseqsig.patch
Description: Binary data


> Le 9 sept. 2022 à 19:55, FX  a écrit :
> 
> ping
> 
> 
>> Le 1 sept. 2022 à 23:02, FX  a écrit :
>> 
>> Attached patch adds __builtin_iseqsig() to the middle-end and C family 
>> front-ends.
>> Testing does not currently check whether the signaling part works, because 
>> with optimisation is actually does not (preexisting compiler bug: 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)
>> 
>> Bootstrapped and regtested on x86_64-linux.
>> OK to commit?
>> 
>> (I’m not very skilled for middle-end hacking, so I’m sure there will be 
>> modifications to make.)
>> 
>> FX
>> <0001-Add-__builtin_iseqsig.patch>
> 

Re: [PATCH] Fortran 2018 rounding modes changes

[FX via Gcc-patches]

Follow-up patch, including a test, committed as attached.

FX



0001-Fortran-handle-RADIX-kind-in-IEEE_SET_ROUNDING_MODE.patch
Description: Binary data

Re: [PATCH] Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES

[FX via Gcc-patches]

I forgot to include the gfortran.map part of the patch, and so the test failed 
on platforms that have symbol versioning.
Fix below committed to master.

FX



commit ce8aed75a38b468490ecab4c318e3eb08d468608 (HEAD -> master)
Author: Francois-Xavier Coudert 
Date:   2022-09-21 10:04:22 +0200

Fortran: add symbols in version map for IEEE_GET_MODES and IEEE_SET_MODES

The symbols were forgotten in the patch that added IEEE_GET_MODES
and IEEE_SET_MODES.

2022-09-21  Francois-Xavier Coudert  

libgfortran/

* gfortran.map: Add symbols for IEEE_GET_MODES
and IEEE_SET_MODES.

diff --git a/libgfortran/gfortran.map b/libgfortran/gfortran.map
index e0e795c3d48..db9b86cb183 100644
--- a/libgfortran/gfortran.map
+++ b/libgfortran/gfortran.map
@@ -1759,3 +1759,9 @@ GFORTRAN_12 {
   _gfortran_transfer_real128_write;
 #endif
 } GFORTRAN_10.2;
+
+GFORTRAN_13 {
+  global:
+__ieee_exceptions_MOD_ieee_get_modes;
+__ieee_exceptions_MOD_ieee_set_modes;
+} GFORTRAN_12;

Re: [PATCH] Fortran 2018 rounding modes changes

[FX via Gcc-patches]

Hi,

> Hmm, not really convinced, but that's a possible interpretation, I guess.

It seems to me to be in line with the handling of all other IEEE intrinsics: 
the user is responsible for querying support before calling any relevant 
routine. I admit that there is no explicit language in the case of the rounding 
mode, I will try to find time to ask for an official interpretation.


> My sentence was about IEEE_*S*ET_ROUNDING_MODE actually.
> My point that we previously reported an error (at compile time) to a user 
> that would try to pass a radix 10 while we now silently do... something else 
> that was requested (i.e. set the radix 2 rounding mode).

Oh sorry, I see what you mean and you’re totally right. This is an easy 
improvement, and while I believe it is undefined behaviour in any case, we can 
easily improve that.


> I think it's worth at least documenting that only radix 2 is supported.

That also makes sense. I’ll propose a patch.

Thanks,
FX

Re: [PATCH] Fortran 2018 rounding modes changes

[FX via Gcc-patches]

Hi,

>> 2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and 
>> IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support 
>> floating-point radices other than 2.
> If we accept the argument, we have to support it somehow.
> So for IEEE_GET_ROUNDING_MODE (*, 10), we should return IEEE_OTHER, shouldn't 
> we?

I think I disagree. We do not support any real kind with radix 10, so calling 
IEEE_GET_ROUNDING_MODE with RADIX=10 is invalid. Or, in another interpretation, 
the rounding mode is whatever-you-want-to-call it, since you cannot perform 
arithmetic in that radix anyway.


> There is no problem for IEEE_SET_ROUNDING_MODE (*, 10) as there is no way 
> this to be a valid call if radix 10 is not supported, but changing a compile 
> time error to a runtime unexpected behavior seems like a step backwards.

What do you mean by that? The behavior is not unexpected, the value returned by 
IEEE_GET_ROUNDING_MODE for RADIX=10 is irrelevant and cannot be used for 
anything useful.

FX

Re: [PATCH] Fortran 2018 rounding modes changes

[FX via Gcc-patches]

Committed as 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4637a1d293c978816ad622ba33e3a32a78640edd

FX


> Le 10 sept. 2022 à 12:21, FX  a écrit :
> 
> ping
> (with fix for the typo Bernhard noticed)
> 
> <0001-Fortran-F2018-rounding-modes-changes.patch>
> 
>> Le 31 août 2022 à 20:29, FX  a écrit :
>> 
>> This adds new F2018 features, that are not really enabled (because their 
>> runtime support is optional).
>> 
>> 1. Add the new IEEE_AWAY rounding mode. It is unsupported on all known 
>> targets, but could be supported by glibc and AIX as part of the C2x 
>> proposal. Testing for now is minimal, but once a target supports that 
>> rounding mode, the tests will fail and we can fix them by expanding them.
>> 
>> 2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and 
>> IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support 
>> floating-point radices other than 2.
>> 
>> 
>> Regression-tested on x86_64-pc-linux-gnu, both 32- and 64-bit.
>> OK to commit?
>> 
>> 
>> <0001-fortran-Fortran-2018-rounding-modes-changes.patch>
> 

Re: [PATCH] Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES

[FX via Gcc-patches]

Hi Mikael,

> Looks good, thanks.

Thank you for your reviews. This patch is committed to trunk: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4637a1d293c978816ad622ba33e3a32a78640edd

FX

Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

[FX via Gcc-patches]

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_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES

[FX via Gcc-patches]

ping


> Hi,
> 
> The IEEE_MODES_TYPE type and the two functions that get and set it were added 
> in Fortran 2018.  They can be implemented using the already existing 
> target-specific functions.  A future optimization could, on some targets, 
> set/get all modes through one or two instructions only, but that would need a 
> new set of functions in all config/fpu-* files.
> 
> This was regtested on aarch64-darwin, which does not support underflow modes, 
> so I will further test on x86_64-linux when I finish travelling in a couple 
> of days.
> OK to commit?
> 
> FX
> 
> <0001-Fortran-add-IEEE_MODES_TYPE-IEEE_GET_MODES-and-IEEE_.patch>

Re: [PATCH] Fortran 2018 rounding modes changes

[FX via Gcc-patches]

ping
(with fix for the typo Bernhard noticed)



0001-Fortran-F2018-rounding-modes-changes.patch
Description: Binary data


> Le 31 août 2022 à 20:29, FX  a écrit :
> 
> This adds new F2018 features, that are not really enabled (because their 
> runtime support is optional).
> 
> 1. Add the new IEEE_AWAY rounding mode. It is unsupported on all known 
> targets, but could be supported by glibc and AIX as part of the C2x proposal. 
> Testing for now is minimal, but once a target supports that rounding mode, 
> the tests will fail and we can fix them by expanding them.
> 
> 2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and 
> IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support 
> floating-point radices other than 2.
> 
> 
> Regression-tested on x86_64-pc-linux-gnu, both 32- and 64-bit.
> OK to commit?
> 
> 
> <0001-fortran-Fortran-2018-rounding-modes-changes.patch>

Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

[FX via Gcc-patches]

> 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] Add __builtin_iseqsig()

[FX via Gcc-patches]

ping


> Le 1 sept. 2022 à 23:02, FX  a écrit :
> 
> Attached patch adds __builtin_iseqsig() to the middle-end and C family 
> front-ends.
> Testing does not currently check whether the signaling part works, because 
> with optimisation is actually does not (preexisting compiler bug: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)
> 
> Bootstrapped and regtested on x86_64-linux.
> OK to commit?
> 
> (I’m not very skilled for middle-end hacking, so I’m sure there will be 
> modifications to make.)
> 
> FX
> <0001-Add-__builtin_iseqsig.patch>

Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

[FX via Gcc-patches]

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

[FX via Gcc-patches]

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

[FX via Gcc-patches]

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>

[PATCH] Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES

[FX via Gcc-patches]

Hi,

The IEEE_MODES_TYPE type and the two functions that get and set it were added 
in Fortran 2018.  They can be implemented using the already existing 
target-specific functions.  A future optimization could, on some targets, 
set/get all modes through one or two instructions only, but that would need a 
new set of functions in all config/fpu-* files.

This was regtested on aarch64-darwin, which does not support underflow modes, 
so I will further test on x86_64-linux when I finish travelling in a couple of 
days.
OK to commit?

FX



0001-Fortran-add-IEEE_MODES_TYPE-IEEE_GET_MODES-and-IEEE_.patch
Description: Binary data

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

[FX via Gcc-patches]

> IIRC there was discussion about abort on the ML some years ago where folks 
> decided to switch to stop N.
> I don't think I participated in that discussion, maybe somebody remembers the 
> reasoning or is able to find the thread.

Found it: https://gcc.gnu.org/legacy-ml/fortran/2018-02/msg00105.html
Will replace those abort calls, then.

FX

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

[FX via Gcc-patches]

Hi Bernhard,

> Please do not call the non-standard abort, but use stop N.

Is there a specific reason? It’s a well-documented GNU extension, and it’s 
useful because it can easily display a backtrace and give line info for the 
failure, unlike STOP.
I’ll replace if there is consensus, but apart from aesthetics I don’t see why.

FX

[PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

[FX via Gcc-patches]

Hi,

These operations were added to Fortran 2018, and correspond to well-defined 
IEEE comparison operations, with defined signaling semantics for NaNs. All are 
implemented in terms of GCC expressions and built-ins, with no library support 
needed.

Bootstrapped and regtested on x86_64-linux, both 32- and 64-bit. Depends on a 
patch currently under review for the middle-end 
(https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600840.html).

OK to commit?
FX




0001-Fortran-add-IEEE_QUIET_-and-IEEE_SIGNALING_-comparis.patch
Description: Binary data

[PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

Attached patch adds __builtin_iseqsig() to the middle-end and C family 
front-ends.
Testing does not currently check whether the signaling part works, because with 
optimisation is actually does not (preexisting compiler bug: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)

Bootstrapped and regtested on x86_64-linux.
OK to commit?

(I’m not very skilled for middle-end hacking, so I’m sure there will be 
modifications to make.)

FX


0001-Add-__builtin_iseqsig.patch
Description: Binary data

Re: Floating-point comparisons in the middle-end

[FX via Gcc]

> See N3047 Annex F for the current bindings (there have been a lot of 
> changes to the C2x working draft after N3047 in the course of editorial 
> review, but I don't think any of them affect the IEEE bindings for 
> comparisons).

Thanks for the pointer, it is very helpful.

The next thing I need to tackle for Fortran is the implementation of functions 
that perform maxNum, maxNumMag, minNum, and minNumMag.
Am I correct in assuming that maxNum and minNum correspond to fmin and fmax? 
Are there builtins for maxNumMag and minNumMag? Or does anyone know what the 
“canonical” way to perform it is? I do not want to mess up corners cases, which 
is so easy to do…

Thanks again,
FX

Re: Floating-point comparisons in the middle-end

[FX via Gcc]

Hi Joseph,

I have a Fortran patch ready to submit, but before I do so I’d like to know: do 
you support or oppose a __builtin_iseqsig()?
Jakub said he was against, but deferred to you on that.

For me, it makes the Fortran front-end part slightly simpler, so if it is 
decided to go that route I’ll propose a middle-end + C patch first. But I do 
not need it absolutely.

Thanks,
FX

Re: Floating-point comparisons in the middle-end

[FX via Gcc]

For the record, this is now PR 106805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805

FX

Re: Floating-point comparisons in the middle-end

[FX via Gcc]

> Presumably that can be reproduced without depending on the new built-in 
> function?  In which case it's an existing bug somewhere in the optimizers.

Yes:

$ cat a.c
#include 
#include 
#include 

void foo (void) {
  if (fetestexcept (FE_INVALID) & FE_INVALID)
printf("Invalid raised\n");
  feclearexcept (FE_ALL_EXCEPT);
}

static inline int iseqsig(float x, float y) { return (x >= y && x <= y); }

int main (void) {
  float x = __builtin_nanf("");
  float y;

  printf("%d\n", iseqsig(__builtin_nanf(""), 1.));
  foo();

  printf("%d\n", iseqsig(x, __builtin_inff()));
  foo();
}

$ ./bin/gcc a.c -lm -fno-unsafe-math-optimizations -frounding-math 
-fsignaling-nans -O0 && ./a.out
0
Invalid raised
0
Invalid raised

$ ./bin/gcc a.c -lm -fno-unsafe-math-optimizations -frounding-math 
-fsignaling-nans -O1 && ./a.out
0
0


Do you want me to file a bug report?

FX

Re: Floating-point comparisons in the middle-end

[FX via Gcc]

Hi,

> Dunno if we really need a builtin for this, especially if it is lowered
> to that x >= y && x <= y early, will defer to Joseph.

I think it’d be nice to have one for consistency, as the other standard 
floating-point functions are there. It would also make things slightly easier 
for our Fortran implementation, although admittedly we can do without.

A tentative patch is attached, it seems to work well on simple examples, but 
for test coverage the hard part is going to be that the comparisons seem to be 
optimised away very easily into their non-signaling versions. Basically, if I 
do:

  float x = __builtin_nanf("");
  printf("%d\n", __builtin_iseqsig(__builtin_nanf(""), __builtin_inff()));
  printf("%d\n", __builtin_iseqsig(x, __builtin_inff()));

With -O0 -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans: first 
one does not raise invalid, second one does.
With -O2 -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans: no 
invalid raised at all.

FX



iseqsig.diff
Description: Binary data

Re: Floating-point comparisons in the middle-end

[FX via Gcc]

Hi Jakub,

>> 2.  All the functions are available as GCC type-generic built-ins (yeah!),
>> except there is no __builtin_ iseqsig
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77928).  Is there a
>> fundamental problem with creating one, and could someone help there?
> 
> IMHO until that one is implemented you can just use
> tx = x, ty = y, tx>=ty && tx<=ty
> (in GENERIC just SAVE_EXPR >= SAVE_EXPR && SAVE_EXPR <= SAVE_EXPR

If it’s just that (optimization aside), I probably can create a C built-in. It 
would need to be:

1. defined in builtins.def
2. lowered in builtins.cc
3. type-checked in c-family/c-common.cc
4. documented in doc/extend.texi
5. tested in fp-test.cc
6. covered in the testsuite

Is that right?

Thanks,
FX


PS: I see that reclassify is not covered in fp-test.cc, is that file obsolete?

Floating-point comparisons in the middle-end

[FX via Gcc]

Hi,

Fortran 2018 introduced intrinsic functions for all the IEEE-754 comparison 
operations, compareQuiet* and compareSignaling*  I want to introduce those into 
the Fortran front-end, and make them emit the right code. But cannot find the 
correspondance between IEEE-754 nomenclature and GCC internal representation.

I understand that the middle-end representation was mostly created with C in 
mind, so I assume that the correspondance is that used by the C standard. That 
helps me to some extent, as I can find draft documents that seem to list the 
following table (page 8 of 
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1615.pdf):

compareQuietEqual ==
compareQuietNotEqual !=
compareSignalingEqual iseqsig
compareSignalingGreater >
compareSignalingGreaterEqual >=
compareSignalingLess <
compareSignalingLessEqual <=
compareSignalingNotEqual !iseqsig
compareSignalingNotGreater !(x>y)
compareSignalingLessUnordered !(x=>y)
compareSignalingNotLess !(xhttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=77928). Is there a fundamental 
problem with creating one, and could someone help there?


Thanks,
FX

Re: [PATCH] Fortran 2018 rounding modes changes

[FX via Gcc-patches]

> +  case GFC_FPE_GFC_FPE_AWAY:
> 
> typo?

Absolutely. Didn’t break the build because glibc currently doesn’t define 
FE_TONEARESTFROMZERO, but it should in the future (when C2x is included).

FX

[PATCH] Fortran 2018 rounding modes changes

[FX via Gcc-patches]

This adds new F2018 features, that are not really enabled (because their 
runtime support is optional).

1. Add the new IEEE_AWAY rounding mode. It is unsupported on all known targets, 
but could be supported by glibc and AIX as part of the C2x proposal. Testing 
for now is minimal, but once a target supports that rounding mode, the tests 
will fail and we can fix them by expanding them.

2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and 
IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support 
floating-point radices other than 2.


Regression-tested on x86_64-pc-linux-gnu, both 32- and 64-bit.
OK to commit?




0001-fortran-Fortran-2018-rounding-modes-changes.patch
Description: Binary data

Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

[FX via Gcc-patches]

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

[FX via Gcc-patches]

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

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]

[FX via Gcc-patches]

Hi,

>> Why looping over fields? The class type is a simple type with only one 
>> member (and it should be an integer, we can assert that).
> 
> I wanted to make sure it has exactly one field.
> The ieee_arithmetic.F90 module in libgfortran surely does that, but I've
> been worrying about some user overriding that module with something
> different.

In Fortran world it would be a rare and crazy thing to do, but I see. Could you 
add a comment (pointing out to the type definition in libgfortran)?


> The libgfortran version had default: label:
>switch (type) \
>{ \
>  case IEEE_SIGNALING_NAN: \
>return __builtin_nans ## SUFFIX (""); \
>  case IEEE_QUIET_NAN: \
>return __builtin_nan ## SUFFIX (""); \
>  case IEEE_NEGATIVE_INF: \
>return - __builtin_inf ## SUFFIX (); \
>  case IEEE_NEGATIVE_NORMAL: \
>return -42; \
>  case IEEE_NEGATIVE_DENORMAL: \
>return -(GFC_REAL_ ## TYPE ## _TINY) / 2; \
>  case IEEE_NEGATIVE_ZERO: \
>return -(GFC_REAL_ ## TYPE) 0; \
>  case IEEE_POSITIVE_ZERO: \
>return 0; \
>  case IEEE_POSITIVE_DENORMAL: \
>return (GFC_REAL_ ## TYPE ## _TINY) / 2; \
>  case IEEE_POSITIVE_NORMAL: \
>return 42; \
>  case IEEE_POSITIVE_INF: \
>return __builtin_inf ## SUFFIX (); \
>  default: \
>return 0; \
>} \
> and I've tried to traslate that into what it generates.

OK, that makes sense. But:

> There is at least the IEEE_OTHER_VALUE (aka 0) value
> that isn't covered in the switch, but it is just an integer
> under the hood, so it could have any other value.

I think I originally included the default for IEEE_OTHER_VALUE, but the 
standard says IEEE_OTHER_VALUE as an argument to IEE_VALUE is not allowed. If 
removing the default would make the generated code shorter, I suggest we do it; 
otherwise let’s keep it.

With those two caveats, the patch is OK. We shouldn’t touch the library code 
for now, but when the patch is committed we can add the removal of IEEE_VALUE 
and IEEE_CLASS from the library to this list: 
https://gcc.gnu.org/wiki/LibgfortranAbiCleanup

FX

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]

[FX via Gcc-patches]

Hi Jakub,

I have two questions, on this and the ieee_class patch:


> +  tree type = TREE_TYPE (arg);
> +  gcc_assert (TREE_CODE (type) == RECORD_TYPE);
> +  tree field = NULL_TREE;
> +  for (tree f = TYPE_FIELDS (type); f != NULL_TREE; f = DECL_CHAIN (f))
> +if (TREE_CODE (f) == FIELD_DECL)
> +  {
> + gcc_assert (field == NULL_TREE);
> + field = f;
> +  }
> +  gcc_assert (field);

Why looping over fields? The class type is a simple type with only one member 
(and it should be an integer, we can assert that).


> + case IEEE_POSITIVE_ZERO:
> +   /* Make this also the default: label.  */
> +   label = gfc_build_label_decl (NULL_TREE);
> +   tmp = build_case_label (NULL_TREE, NULL_TREE, label);
> +   gfc_add_expr_to_block (, tmp);
> +   real_from_integer (, TYPE_MODE (type), 0, SIGNED);
> +   break;

Do we need a default label? It’s not like this is a more likely case than 
anything else…


Thanks,
FX

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_class inline [PR106579]

[FX via Gcc-patches]

Question to the Fortran maintainers:

Do you know if the standard allows IEEE_CLASS and IEEE_VALUE to be used as 
procedure pointers? I think not, because they do not follow (in F2008) the 
standard constraint C729 / R740.

If so, we need to keep these functions implementations in libgfortran for now 
(for ABI compatibility) but can remove them at the next breakage. Is one 
planned? Where is this tracked, is it still at 
https://gcc.gnu.org/wiki/LibgfortranAbiCleanup or do we have another place 
(e.g. in bugzilla)?

Thanks,
FX

Re: [PATCH] Implement __builtin_issignaling

[FX via Gcc-patches]

Hi Jakub,

Thank you for taking this on (this patch and the Fortran ones), it is really 
appreciated and will improve gfortran's IEEE conformance.

- "Implement __builtin_issignaling”: is approved for the tiny Fortran part
- "libgfortran: Use __builtin_issignaling in libgfortran”: was approved by 
Thomas
- I will have to look at the next two patches (ieee_value and ieee_class) in 
the next few days. I think we can make adjustments to the runtime library as 
well.

Related: there are several tests in our testsuite that have { 
dg-require-effective-target issignaling }
This is checked by check_effective_target_issignaling in 
gcc/testsuite/lib/target-supports.exp, and probes the support for the 
issignaling macro in . I think it would make sense to adjust those 
tests to run on a wider range of targets, using the new built-in.

FX

Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd

[FX via Gcc-patches]

> Actually, test results don't change at all. However, software that otherwise 
> fails to build with "Cannot find an intrinsic module named 
> 'ieee_arithmetic'", now builds successfully.

Test results should definitely change, we’d need to see a before/after list 
(same build, same revision, without and with patch applied) to know. Run “make 
check-gfortran”.

All tests in gcc/testsuite/gfortran.dg/ieee/ should be running and running fine 
(i.e., PASS). You can also grep for “ieee” in the gcc/testsuite/gfortran.sum 
file created after “make check-gfortran” is run, and report both here. This 
will help investigate.

Thanks,
FX


signature.asc
Description: Message signed with OpenPGP

Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd

[FX via Gcc-patches]

> Given that 12 has been branched off, is it OK now to commit this patch?

How does the patch affect the results of “make check-gfortran”? How many tests 
that failed or were unsupported pass?

FX

Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd

[FX via Gcc-patches]

Hi,

> can you check the following patch?

Why restrict it to powerpc-freebsd only, and not all freebsd? Do they differ?
Otherwise it looks ok to me, but probably should be tested on a glibc non-x86 
target.

In any case, this will be for the new branch, when stage 1 reopens.

FX

Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd

[FX via Gcc-patches]

Hi,

> the problem is that configure checks for feenableexcept() in libm:
> AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes 
> AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])
> 
> FreeBSD doesn't have this function in libm, it's implemented in 
> /usr/include/fenv.h.

I see. Then we probably can use AC_CHECK_FUNCS, or design a specific check, so 
that it gives the right value on both glibc and FreeBSD targets.

Could you test something on your end?

FX

Re: [PATCH] middle-end/100786 - constant folding from incompatible alias

[FX via Gcc-patches]

Hi Richard,

The patch for PR100786 introduced a testcase that systematically fails on 
darwin:

FAIL: gcc.dg/torture/pr100786.c   -O0  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O1  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O2  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O2 -flto -flto-partition=none  (test for 
excess errors)
FAIL: gcc.dg/torture/pr100786.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/pr100786.c   -Os  (test for excess errors)

see https://gcc.gnu.org/pipermail/gcc-testresults/2022-March/757882.html

because

pr100786.c:4:12: error: only weak aliases are supported in this configuration
4 | extern int b __attribute__((alias("a")));
  |^
pr100786.c:8:15: error: only weak aliases are supported in this configuration
8 | extern double b2 __attribute__((alias("a2")));
  |   ^~


FX

Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd

[FX via Gcc-patches]

Hi,

(Please send all Fortran (front-end and libgfortran) patches in CC to the 
Fortran list.)

Please hold from pushing the patch as is, I have some questions:

- If FreeBSD has feenableexcept() and related functions, it should already use 
the fpu-glibc code, because of this:

if test "x${have_feenableexcept}" = "xyes"; then
  fpu_host='fpu-glibc'
  ieee_support='yes'
fi

So before the patch, what was configure.host returning, and what is the value 
of have_feenableexcept?

- Why restrict the patch to powerpc*? Don’t other FreeBSD targets have that 
function?
- How does the patch affect the results of “make check-gfortran”?


Thanks,
FX

Re: [PATCH] testsuite: avoid analyzer asm failures on non-Linux

[FX via Gcc]

Hi David,

> Thanks.  I extended your patch as follows, which works successfully for
> me on x86_64-pc-linux-gnu.
> 
> Does the following look OK for the analyzer asm failures on
> x86_64-apple-darwin?

Sorry for the late reply… yes it does!

FX

Re: [PATCH] testsuite: Fix gfortran.dg/ieee/signaling_?.f90 tests for x86 targets

[FX via Gcc-patches]

Hi Uroš,

> Please note that check_effective_target_ia32 test tries to compile code that
> uses __i386__ target-dependent preprocessor definition, so it is guaranteed
> to fail on all non-ia32 targets.

Thanks, I didn’t know the difference!
OK to push.

FX

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

[FX via Gcc-patches]

Hi Jakub,

> This doesn't seem to handle the powerpc* IBM double double long double.

Do we support the IEEE Fortran modules on this target, despite having a 
non-IEEE long double? I remember we talked about it when I first implemented 
it, but can’t remember what choice we ended up making.


> __LDBL_IS_IEC_60559__ isn't defined for this type, because it is far from
> an IEEE754 type, but it has signaling NaNs - as can be seen in glibc
> libc/sysdeps/ieee754/ldbl-128ibm/s_issignalingl.c
> the type is a pair of doubles and whether it is a sNaN or qNaN is determined
> by whether the first double is a sNaN or qNaN.
> 
> Ok for trunk?

It doesn’t hurt to provide an implementation, in any case. OK to push, and 
thanks for the patch.

FX

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

[FX via Gcc-patches]

> Yes, it does.
> 
> (There is also some leeway granted to non-release-critical languages
> like Fortran.  RM approval is only needed once a branch has been
> frozen).

Thanks Thomas. Pushed: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e89d0befe3ec3238fca6de2cb078eb403b8c7e99

I’m hoping my use of macros is enough to make it build on all target, and I’ll 
follow the gcc-testresults and other lists to see if there is any trouble. If 
you see something (or something is reported), feel free to CC me on it…

FX

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

[FX via Gcc-patches]

> Then it’s OK to commit for me, but you will need approval from release 
> managers at this stage.

Hum… I submitted it before stage 4 started, does that count?

FX

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

[FX via Gcc-patches]

Hi Mikael,

> I spotted two unexpected things (to me at least) related to x86 extended type:
> - You check for endianness, so the format is not x86-specific?
> - Is it expected that the padding bits are in the middle of the data in the 
> big-endian case?

IEEE specifies that extended precision types can be present, possibly with any 
endianness, at least in theory. There are other CPUs with extended precision 
types than Intel, although we probably don’t support them currently in 
gfortran: Motorola 68881 has a IEEE-compatible 80-bit format and is big endian. 
I kept the code generic, but if you think it’s a problem I can remove that part 
and make it error out.

I followed the logic used in glibc to deal with bit layout and endianness, so 
it should be safe as currently proposed.

FX

[PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

[FX via Gcc-patches]

This patch is the third in my “signaling NaN” series. For targets with IEEE 
support but without the issignaling macro in libc (i.e., everywhere except 
glibc), this allows us to provide a fallback implementation. In order to keep 
the code in ieee_helper.c relatively readable, I’ve put that new implementation 
in a separate file, issignaling_fallback.h.

The logic is borrowed from different routines in glibc, but gathered into a 
single file and much simpler than the glibc implementation, because we do not 
need to cover all the cases they have (comments with details are available in 
issignaling_fallback.h).

I can’t test this on all the targets I’d like to, obviously. But it was tested 
on x86_64-pc-linux-gnu (where it doesn’t do anything), on x86_64-pc-linux-gnu 
by mimicking the lack of a issignaling macro, and on x86_64-apple-darwin (which 
does not have issignaling).

OK to push?



issignaling.diff
Description: Binary data

Re: [PATCH] Fortran: make IEEE_VALUE produce signaling NaNs

[FX via Gcc-patches]

Hi Mikael, team,

> Thanks. Pushed: 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=90045c5df5b3c8853e7740fb72a11aead1c489bb

Pushed a further commit to XFAIL the testcases on x87:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=86e3b476d5defaa79c94d40b76cbeec21cd02e5f

There the ABI does not allow us to meaningfully pass signaling NaNs in float 
and double types, sadly.

FX

Re: [PATCH] Fortran: make IEEE_VALUE produce signaling NaNs

[FX via Gcc-patches]

Thanks Mikael,

> This looks good to me. Thanks.

Thanks. Pushed: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=90045c5df5b3c8853e7740fb72a11aead1c489bb

FX

Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)

[FX via Gcc]

> No, that's "dg-do compile" (as in "compile but don't assemble").

I can confirm that this patch:

diff --git a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c 
b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
index c235e22fd01..4730255bb3c 100644
--- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
@@ -1,4 +1,4 @@
-/* { dg-do assemble { target x86_64-*-* } } */
+/* { dg-do compile { target x86_64-*-* } } */
 /* { dg-require-effective-target lp64 } */
 
 #include "analyzer-decls.h”


fixes the gcc.dg/analyzer/asm-x86-lp64-1.c failure on x86_64-apple-darwin. The 
same is true of this one:

diff --git 
a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c 
b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
index e90dccf58dd..4cbf43206dc 100644
--- 
a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
+++ 
b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
@@ -1,4 +1,4 @@
-/* { dg-do assemble { target x86_64-*-* } } */
+/* { dg-do compile { target x86_64-*-* } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-additional-options "-fsanitize=bounds -fno-analyzer-call-summaries" } 
*/
 /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */



These other three:
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c

still fail with dg-do compile, as explained, become the error comes from the C 
front-end, not the assembler:

/Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
 warning: 'asm' operand 6 probably does not match constraints
/Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
 error: impossible constraint in 'asm'


FX

Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)

[FX via Gcc]

Hi David,

> The purpose of these asm tests is to verify that the analyzer doesn't
> get confused by various inline assembler directives used in the source
> of the Linux kernel.  So in theory they ought to work on any host, with
> a gcc configured for a suitable target.
> 
> These tests are marked with "dg-do assemble" directives, which I'd
> hoped would mean it uses -S for the tests (to make a .s file), but
> looking at a log locally, it appears to be using -c (to make a .o
> file), so maybe that's what's going wrong for you as well?

The tests even compiled with -S still fail:

spawn -ignore SIGHUP /Users/fx/ibin/gcc/xgcc -B/Users/fx/ibin/gcc/ 
exceptions_enabled42475.cc -fdiagnostics-plain-output -S -o excep
tions_enabled42475.s
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c   -O1  (test for 
excess errors)
Excess errors:
/Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
 warning: 'asm' operand 6 probably does not match constraints
/Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
 error: impossible constraint in 'asm'

It’s the same for the other four.


gcc.dg/analyzer/asm-x86-lp64-1.c is slightly different, there it’s an assembler 
error:


/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//cc4b3ybm.s:160:20: 
error:unexpected token in '.section' directive
.pushsection .text
  ^
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//cc4b3ybm.s:162:2: error: 
unknown directive
.type add_asm, @function
^
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//cc4b3ybm.s:167:13: error: 
.popsection without corresponding .pushsection
.popsection
   ^



>>> ## Builtin-related failures
>>> 
>>> Those four cases fail:
>>> 
>>> gcc.dg/analyzer/data-model-1.c
>>> gcc.dg/analyzer/pr103526.c
>>> gcc.dg/analyzer/taint-size-1.c
>>> gcc.dg/analyzer/write-to-string-literal-1.c
> 
> Can you file a bug about this and attach the preprocessed source from
> the test (using -E).

Done, it is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042


FX

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

> Thanks.  Just a nit, it is cc1 that reports the warning, not f951.

I confirm the patch fixes the testcase failure. And I fixed the comment in a 
follow-up commit.

Thanks!

FX

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

Hi Jakub,

> We need -fintrinsic-modules-path option for the signalling_1.f90 compilation
> but need to make sure it isn't used when the *.c file is compiled, so they
> need to be compiled by separate compiler invocations probably.

Thanks for posting the errors! So I wasn’t seeing it because I had run “make 
install” before the testsuite. The patch I pushed at 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6b14100b9504800768da726dcb81f1857db3b493
 should fix the failure, then.

FX

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

Hi,

I can confirm that I don’t see this failure on a Debian bullseye/sid (Linux 
5.11.0-46, glibc 2.31-0ubuntu9.2) with a fresh bootstrap of master:

$ grep signaling testsuite/gfortran/gfortran.sum
PASS: gfortran.dg/ieee/signaling_1.f90   -O0  (test for excess errors)
PASS: gfortran.dg/ieee/signaling_1.f90   -O0  execution test
PASS: gfortran.dg/ieee/signaling_1.f90   -O1  (test for excess errors)
PASS: gfortran.dg/ieee/signaling_1.f90   -O1  execution test
PASS: gfortran.dg/ieee/signaling_1.f90   -O2  (test for excess errors)
PASS: gfortran.dg/ieee/signaling_1.f90   -O2  execution test
PASS: gfortran.dg/ieee/signaling_1.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess 
errors)
PASS: gfortran.dg/ieee/signaling_1.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
PASS: gfortran.dg/ieee/signaling_1.f90   -O3 -g  (test for excess errors)
PASS: gfortran.dg/ieee/signaling_1.f90   -O3 -g  execution test
PASS: gfortran.dg/ieee/signaling_1.f90   -Os  (test for excess errors)
PASS: gfortran.dg/ieee/signaling_1.f90   -Os  execution test

It’s showing on some gcc-testresults for x86_64 and aarch64 linux, so I’ll need 
someone (HJ, Andreas are in CC) to show me what the error is.

It may be related to the use of dg-options instead of dg-additional-options in 
that testcase, so I pushed the attached fix. I’ll check the test results 
mailing-list to see if it improved things (or confirm when the error message is 
posted).

FX




test.patch
Description: Binary data

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

Hi HJ,

> I looked at gcc-testresults and find e.g.
> 
> https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747938.html
> https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747935.html
> 
> which is x86 (64 and 32 bit) by H.J.; plus some more.
> Maybe H.J. can explain what is different from your platform?

Could you kindly look up what the log says for these failures on your boxes:

FAIL: gfortran.dg/ieee/signaling_1.f90   -O0  (test for excess errors)
UNRESOLVED: gfortran.dg/ieee/signaling_1.f90   -O0  compilation failed to 
produce executable

Somehow they did not seem to show up on my test machine. I’m launching a fresh 
bootstrap, but it will take a while.

FX

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

Hi Harald,

> I think this patch breaks the testsuite

On what platform? It regtested fine on x86_64-pc-linux-gnu


> since the directive
> ! { dg-additional-sources signaling_1_c.c }
> should rather read
> ! { dg-additional-sources "signaling_1_c.c" }

I find plenty of evidence saying it’s allowed (just quoting a few, but there 
are a lot):

./gfortran.dg/PR94331.f90:! { dg-additional-sources PR94331.c }
./gfortran.dg/global_vars_c_init.f90:! { dg-additional-sources 
global_vars_c_init_driver.c }
./gfortran.dg/c_char_tests.f03:! { dg-additional-sources c_char_driver.c }


FX

[PATCH] Fortran: make IEEE_VALUE produce signaling NaNs

[FX via Gcc-patches]

Hi,

Second part of a three-patch series to fix PR 82207 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle 
signaling NaNs. This part fixes the library code implementing IEEE_VALUE. To do 
so, I switched that part of library code from Fortran to C, because in C we 
have access to all GCC built-ins related to NaNs/infinities/etc, which is super 
useful for generating the right bit patterns (instead of using roundabout ways, 
like the previous Fortran implementation, for which I am guilty).

I needed to add to kinds.h the value of TINY for each floating-point (which is 
used to produce denormals, by halving TINY).

The patch comes with a testcase, which is still conditional on issignaling 
support at this stage (and therefore will run on glibc targets only).

I had to amend the gfortran.dg/ieee/ieee_10.f90 testcase, which produces 
signaling NaNs while -ffpe-trap=invalid is set. It passed before, but only by 
accident, because we were not actually generating signaling NaNs. I’m not sure 
what is the expected behaviour, but the patch does not affect the real 
behaviour.

Bootstrapped and regtested on x86_64-pc-gnu-linux. OK to commit?

FX



0001-Fortran-Allow-IEEE_CLASS-to-identify-signaling-NaNs.patch
Description: Binary data




0001-Fortran-allow-IEEE_VALUE-to-correctly-return-signali.patch
Description: Binary data

Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)

[FX via Gcc]

Hi David,

May I kindly ping you on that? Or anyone with knowledge of the static analyzer?

Thanks,
FX


> Le 23 déc. 2021 à 22:49, FX  a écrit :
> 
> Hi David, hi everone,
> 
> I’m trying to understand how best to fix or silence the several failures in 
> gcc.dg/analyzer that occur on x86_64-apple-darwin. Some of them, according to 
> gcc-testresults, also occur on other non-Linux targets. See for example, the 
> test results at 
> https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html
> 
> ## gcc.dg/analyzer/torture/asm-x86-linux-*.c
> 
> Are these supposed to be run only on Linux (as the name implies)? Four of 
> them fail on x86_64-apple-darwin, because they use assembly that is not 
> supported:
> 
> FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c
> FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c
> FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c
> FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
> 
> Should they be restricted to Linux targets? There is another one that has the 
> same error, as well, although it doesn’t have linux in the name:
> 
> FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c
> 
> 
> ## Builtin-related failures
> 
> Those four cases fail:
> 
> gcc.dg/analyzer/data-model-1.c
> 
> gcc.dg/analyzer/pr103526.c
> gcc.dg/analyzer/taint-size-1.c
> gcc.dg/analyzer/write-to-string-literal-1.c
> 
> but pass if the function calls (memset and memcpy) are replaced by the 
> built-in variant (__builtin_memset and __builtin_memcpy). The reason for that 
> is the darwin headers, in  (included from ) does 
> this:
> 
> #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__)
> #undef memcpy
> /* void *memcpy(void *dst, const void *src, size_t n) */
> #define memcpy(dest, ...) \
>__builtin___memcpy_chk (dest, __VA_ARGS__, __darwin_obsz0 
> (dest))
> #endif
> 
> where __darwin_obsz0 is defined thusly:
> 
> #define __darwin_obsz0(object) __builtin_object_size (object, 0)
> 
> 
> Does the analyzer not handle the _chk builtin variants? Should it?
> I’m happy to investigate more, but I’m not sure what to do.
> 
> 
> Best,
> FX

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

Thanks Mikael. I haven’t been active with gfortran development in a while, but 
I originally wrote those IEEE routines so I believe my understanding of them is 
fair. I will continue posting my next patches to gather comments (if any), but 
they’re relatively straightforward.

The main limitation (not with this patch, but with the next ones) is some 
targets have really weird floating-point formats, and I cannot test on all 
possible targets. Feel free to poke me on any issue that arises, in ML or in 
bugzilla.

Best,
FX

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

ping


> Le 2 janv. 2022 à 11:50, FX  a écrit :
> 
> Hi,
> 
> This is the first part of a three-patch series to fix PR 82207 
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle 
> signaling NaNs. This part fixes the library code implementing IEEE_CLASS, by 
> using the issignaling macro (from TS 18661-1:2014) to check whether a NaN is 
> signalling.
> 
> The patch comes with a testcase, conditional on issignaling support (which 
> will therefore run on glibc targets), which uses C built-ins to generate 
> signaling NaNs and checks in Fortran code that they are classified and behave 
> as expected.
> 
> Once this is in, the next two parts are:
> 
> - Add support for generating signaling NaNs in IEEE_VALUE, which is a longer 
> patch because it requires moving the IEEE_VALUE library code from Fortran to 
> C (but will be much more efficient and correct than the current 
> implementation).
> - Provide a fallback implementation of issignaling on targets that don’t have 
> it.
> 
> 
> Bootstrapped and regtested on x86_64-pc-gnu-linux. OK to commit?
> 
> FX
> 


0001-Fortran-Allow-IEEE_CLASS-to-identify-signaling-NaNs.patch
Description: Binary data

Re: [PATCH] Libquadmath: add nansq() function

[FX via Gcc-patches]

Hi Joseph,

> All targets with _Float128 should have __builtin_nansf128, since we have
> DEF_GCC_FLOATN_NX_BUILTINS (BUILT_IN_NANS, "nans", NAN_TYPE, 
> ATTR_CONST_NOTHROW_NONNULL)
> in builtins.def.

Hum, I see, I didn’t know that version existed. To be honest, I find the “other 
built-ins” doc page to be quite confusing to read: 
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Thanks!

FX

[PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

Hi,

This is the first part of a three-patch series to fix PR 82207 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle 
signaling NaNs. This part fixes the library code implementing IEEE_CLASS, by 
using the issignaling macro (from TS 18661-1:2014) to check whether a NaN is 
signalling.

The patch comes with a testcase, conditional on issignaling support (which will 
therefore run on glibc targets), which uses C built-ins to generate signaling 
NaNs and checks in Fortran code that they are classified and behave as expected.

Once this is in, the next two parts are:

- Add support for generating signaling NaNs in IEEE_VALUE, which is a longer 
patch because it requires moving the IEEE_VALUE library code from Fortran to C 
(but will be much more efficient and correct than the current implementation).
- Provide a fallback implementation of issignaling on targets that don’t have 
it.


Bootstrapped and regtested on x86_64-pc-gnu-linux. OK to commit?

FX



0001-Fortran-Allow-IEEE_CLASS-to-identify-signaling-NaNs.patch
Description: Binary data

[PATCH] Fixincludes: handle __FLT_EVAL_METHOD__ == 16 on darwin

[FX via Gcc-patches]

Hi,

The darwin system headers error out on __FLT_EVAL_METHOD__ == 16, which
occurs when the compiler is called with -mavx512fp16 on i386. Allow this
value to proceed past the check (nothing else depends on it in the
system headers). See https://gcc.gnu.org/pipermail/gcc/2021-December/237972.html
for details.

We can use fixincludes to fix this.
Bootstrapped on both x86_64-apple-darwin and aarch64-apple-darwin.

OK to commit?



0001-Fixincludes-Handle-__FLT_EVAL_METHOD__-16-on-darwin.patch
Description: Binary data

[PATCH] Libquadmath: add nansq() function

[FX via Gcc-patches]

Hi,

This patch adds nansq() to libquadmath, a function that returns a signalling 
NaN. It is a need for full libgfortran support of signalling NaNs, because not 
all targets that have _Float128 define a __builtin_nanq() function.

Bootstrapped and tested on x86_64-pc-gnu-linux and aarch64-apple-darwin21 (port 
under development).
OK to commit?

FX



0001-Libquadmath-Add-nansq-function.patch
Description: Binary data

[PATCH, committed] PR 89639, fix testcase for targets without REAL128

[FX via Gcc-patches]

Attached patch pushed as cb48166e52c0f159eb80a0666c4847825e294ec0
Confirmed by Dave to make the testcase pass on hppa-unknown-linux-gnu

FX



0001-Fortran-Fix-test-on-targets-without-REAL128.patch
Description: Binary data

Re: Weird behaviour (bug?) of __builtin_nans()

[FX via Gcc]

Hi Joseph,

> 1. You should use -fsignaling-nans if you want signaling NaNs to work 
> correctly.

Thanks, we’ll compile the libgfortran parts that are IEEE-related with that 
from now on. Sounds like a good idea, anyway.


> 3. There is probably a reasonable case for interpreting such conversions 
> (including casts) as copy operations instead, including in the absence of 
> -fsignaling-nans; C23 Annex F leaves that implementation-defined, and 
> handling such conversions as copy operations is likely to be more 
> predictable and more useful.

I agree that while there may be no guarantee, it sounds like a reasonable 
expectation in the case I posted. I’ve filed a PR: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103883


Thanks,
FX

Weird behaviour (bug?) of __builtin_nans()

[FX via Gcc]

Hi,

I think I’ve found a bug in the handling of __builtin_nans() in GCC, but I am 
aware that this is a tricky area, so before claiming so I would like to check 
with the experts. Consider the following code:

$ cat v.c 
#include 
#include 

#if 1
typedef double GFC_REAL_8;
#else
#define GFC_REAL_8 double
#endif

GFC_REAL_8 foo (void)
{
  return __builtin_nans("");
}

int main (void) {
  double x;

  x = __builtin_nans ("");
  printf("==> %lX\n", *(uint64_t *) );
  x = foo ();
  printf("==> %lX\n", *(uint64_t *) );
}
$ gcc v.c -W -Wall && ./a.out
==> 7FF4
==> 7FF8


My expectation is: the x variable should be assigned a signalling NaN, both 
times, and therefore the code should output the same value twice. But as you 
can see, the second time the NaN is converted to quiet.

What is even more troubling: this behavior only happens if GFC_REAL_8 is 
typedef’ed to double. If we use the double type directly (change #if 1 to #if 
0) then the output is as expected:

==> 7FF4
==> 7FF4


What is even more worrying is that, if you keep the typedef, but change the 
function to go through a variable, then the signalling nan is returned 
correctly:

typedef double GFC_REAL_8;
GFC_REAL_8 foo (void)
{
  GFC_REAL_8 x = __builtin_nans("");
  return x;
}


-

The reason I ended up in this rabbit hole is that I am implementing some 
handling of signalling NaNs in libgfortran. Could someone either confirm that 
the behavior observed above is a bug, or if not, kindly explain to me why it 
happens?


Thanks,
FX

Re: _Float16-related failures on x86_64-apple-darwin

[FX via Gcc]

Hi Joseph,

> fixincludes is the right place for a fix for this issue.  There is a 
> plausible case for having an architecture-independent 
> __FLT_EVAL_METHOD___ macro that takes only values defined by 
> C99 (regardless of -fpermitted-flt-eval-methods), rather than using the 
> new C23 values such as 16, but if you did have such a macro you'd still 
> need to fixinclude the system headers - it would just affect exactly what 
> change fixincludes makes to those headers (if there were such a macro, 
> fixincludes could change the headers to use it).

There is still a difference. If we define a new macro 
__FLT_EVAL_METHOD_OLDSTYLE__ (however it is named), it means we can make a more 
robust fixinclude, using that macro. If we fixinclude right now to handle the 
value of 16, then we might have to update the fixinclude for any new value that 
comes along in the future.

FX

[pushed] Fortran: keep

[FX via Gcc-patches]

Hi,

Fortran 2018 added some synonyms to the existing IEEE_CLASS_TYPE values, namely
IEEE_NEGATIVE_SUBNORMAL (which is the same as IEEE_NEGATIVE_DENORMAL)
and IEEE_POSITIVE_SUBNORMAL (same as IEEE_POSITIVE_DENORMAL). When they
were added to the C side, they were not kept in sync with the Fortran
part of the library. Thew new values are not used (yet), so it is
currently harmless, but better fix it.

I’ve pushed on master as obvious after testing on x86_64-pc-gnu-linux.

FX



0001-Fortran-keep-values-of-IEEE_CLASS_TYPE-in-sync.patch
Description: Binary data

Need for __builtin_issignaling()

[FX via Gcc]

Hi,

In order to finalize our support for Fortran IEEE modules, we need to have 
access to a reliable issignaling() macro, that would work across all 
floating-point types. Some targets (glibc ones, notably) have it, but not all, 
far from it. Instead of implementing our own, probably buggy, probably not very 
portable version… I think it would be a great idea for a GCC builtin: 
__builtin_issignaling()

As far as I can see, this macro was proposed in the “ Optional support for 
Signaling NaNs” WG14 document 
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1011.htm#7.12.3.x%20the%20issignaling%20macro).
 Many other proposed macros from this document are available as GCC builtins, 
so I wonder: why not __builtin_issignaling()?

Is it particularly hard to do? I came across a post in the list archives from 
Joseph, who said it would be good to have. I’d be willing to try and put 
something together, unless you think it’s a big project. Any pointers as to how 
to start would be appreciated.

Best,
FX

Re: [PATCH] Prune LTO warnings that some tests fail

[FX via Gcc-patches]

Hi,

> Did you mean to include the change pruning visibility warnings?  I don't 
> think it's necessarily wrong, it just doesn't match the patch description or 
> ChangeLog.

Yes, I think they should be applied, and will fix long-standing failures 
reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334
ChangeLog and patch description amended.

OK to commit?

FX




0001-LTO-Prune-some-warnings-in-the-testsuite.patch
Description: Binary data

Re: [PATCH] Make integer output faster in libgfortran

[FX via Gcc-patches]

Follow-up patch committed, after my use of the one-argument variant of 
static_assert() broke bootstrap on Solaris (sorry Rainer!).
The one-arg form is new since C23, while Solaris  only supports the 
two-arg form (C11).

I have confirmed that other target libraries use the two-arg form, and 
bootstrapped the attached patch on x86_64-pc-linux-gnu.

FX



static_assert.diff
Description: Binary data

[PATCH] Prune LTO warnings that some tests fail

[FX via Gcc-patches]

The testcase g++.dg/torture/pr31863.C fails on *-apple-darwin with:

FAIL: g++.dg/torture/pr31863.C   -O2 -flto  (test for excess errors)
Excess errors:
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs

The test otherwise works fine, but those lto warnings should be pruned.

OK to commit?
FX




0001-LTO-Prune-some-warnings-in-the-testsuite.patch
Description: Binary data

[PATCH] Emit correct types for CHARACTER(C_CHAR), VALUE

[FX via Gcc-patches]

Hi,

I’ve spent many hours going down a rabbit hole, namely that we emit incorrect 
types for C interoperable procedure parameters of type CHARACTER(C_CHAR), 
VALUE. The full details can be found here: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828 I will try here to be as 
brief as I can.

This bug manifests on the new target aarche64-apple-darwin, and there only if a 
CHARACTER(C_CHAR), VALUE argument is the 11th (or greater) argument to the 
function. Then, we would pass it as a 32-bit value, instead of an 8-bit value 
(as should a char). The front-end emits the wrong type information about the 
argument, but it turns out for all other targets this simply does not matter, 
due to their ABI.

Interoperable CHARACTER(C_CHAR), VALUE arguments are weird, because deep down 
they’re not actually character types (in the Fortran sense of the word), i.e. 
arrays, but scalar C char (i.e., integers!). So they’ve always been kind-of 
second class citizens in the front-end. A function was introduced in 2007 that 
basically patches their type on the fly: gfc_conv_scalar_char_value(). The 
problem is that function is simply wrong. It says (from comments):

  /* Modify the tree type for scalar character dummy arguments of bind(c)
procedures if they are passed by value.  The tree type for them will
be promoted to INTEGER_TYPE for the middle end, which appears to be
what C would do with characters passed by-value.  The value attribute
 implies the dummy is a scalar.  */

The error is a misunderstanding of the C standard. char (and integer types 
smaller than int) are promoted to int for argument passing in unprototyped 
(old-school K) functions. In prototyped functions, they are most definitely 
not promoted. Therefore, the function is wrong.

More importantly, we can actually emit the right type much earlier in the 
front-end, and we already have a place to do so, in gfc_sym_type(). We already 
handle the result variables, but by-value arguments should have the same type, 
so the fix is easy.

In fact, once we emit the right type in gfc_sym_type(), we actually never need 
to fix it up in gfc_conv_scalar_char_value(). Removing the hack, I decided to 
leave it as a series of assertions, because we have seen in the past that this 
case is difficult to catch, and can easily regress due to changes elsewhere in 
the front-end.

Then, once the hack is removed, it becomes clear that the two callers of 
gfc_conv_scalar_char_value() expected different things from it: it’s called 
from generate_local_decl() to hack the sym->backend_decl; and it’s called from 
gfc_conv_procedure_call() for its true purpose, as a real conv_* function. For 
the first case, we can inline the checks (which have replaced the hack) into 
the caller in generate_local_decl(). Once only the second use case remains, we 
can make the function local to that file (make static, remove gfc_ prefix).


The patch comes with a couple of extra testcases, exercising the passing of 
char by value, and as integer, and their interoperability.
It was regtested on x86_64-pc-gnu-linux, on aarch64-apple-darwin (because its 
ABI is picky).

OK to commit?

FX



0001-Fortran-Emit-correct-types-for-CHARACTER-C_CHAR-VALU.patch
Description: Binary data

Re: [PATCH] Make integer output faster in libgfortran

[FX via Gcc-patches]

Hi,

> I tested this on x86_64-pc-linux-gnu with
> make -k -j8 check-fortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
> and didn't see any problems.

Thanks Thomas! Pushed.


> (We could also do something like that for a 32-bit system, but
> that is another kettle of fish).

We probably wouldn’t get a speed-up that big. Even on 32-bit targets (at least 
common ones), the 64-bit type and its operations (notably division) are 
implemented via CPU instructions, not library calls.

At this point, the output of integers is probably bound by the many layers of 
indirection of libgfortran's I/O system (which are necessary because of the 
rich I/O formatting allowed by the standard).

Best,
FX

Re: [PATCH] Make integer output faster in libgfortran

[FX via Gcc-patches]

Hi Thomas,

> There are two possibilities: Either use gcc45 on the compile farm, or
> run it with
> make -k -j8 check-fortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"

Thanks, right now I don’t have a Linux system with 32-bit support. I’ll see how 
I can connect to gcc45, but if someone who is already set up to do can fire a 
quick regtest, that would be great ;)

FX

[PATCH] Make integer output faster in libgfortran

[FX via Gcc-patches]

Hi,

Integer output in libgfortran is done by passing values as the largest integer 
type available. This is what our gfc_itoa() function for conversion to decimal 
form uses, as well, performing series of divisions by 10. On targets with a 
128-bit integer type (which is most targets, really, nowadays), division is 
slow, because it is implemented in software and requires a call to a libgcc 
function.

We can speed this up in two easy ways:
- If the value fits into 64-bit, use a simple 64-bit itoa() function, which 
does the series of divisions by 10 with hardware. Most I/O will actually fall 
into that case, in real-life, unless you’re printing very big 128-bit integers.
- If the value does not fit into 64-bit, perform only one slow division, by 
10^19, and use two calls to the 64-bit function to output each part (the low 
part needing zero-padding).


What is the speed-up? It really depends on the exact nature of the I/O done. 
For the most common-case, list-directed I/O with no special format, the patch 
does not speed (or slow!) things for values up to HUGE(KIND=4), but speeds 
things up for larger values. For very large 128-bit values, it can cut the I/O 
time in half.

I attach my own timing code to this email. Results before the patch (with 
previous itoa-patch applied, though):

 Timing for INTEGER(KIND=1)
 Value 0, time:  0.191409990
 Value HUGE(KIND=1), time:  0.173687011
 Timing for INTEGER(KIND=4)
 Value 0, time:  0.171809018
 Value 1049, time:  0.177439988
 Value HUGE(KIND=4), time:  0.217984974
 Timing for INTEGER(KIND=8)
 Value 0, time:  0.178072989
 Value HUGE(KIND=4), time:  0.214841008
 Value HUGE(KIND=8), time:  0.276726007
 Timing for INTEGER(KIND=16)
 Value 0, time:  0.175235987
 Value HUGE(KIND=4), time:  0.217689037
 Value HUGE(KIND=8), time:  0.280257106
 Value HUGE(KIND=16), time:  0.420036077

Results after the patch:

 Timing for INTEGER(KIND=1)
 Value 0, time:  0.194633007
 Value HUGE(KIND=1), time:  0.172436997
 Timing for INTEGER(KIND=4)
 Value 0, time:  0.167517006
 Value 1049, time:  0.176503003
 Value HUGE(KIND=4), time:  0.172892988
 Timing for INTEGER(KIND=8)
 Value 0, time:  0.171101034
 Value HUGE(KIND=4), time:  0.174461007
 Value HUGE(KIND=8), time:  0.180289030
 Timing for INTEGER(KIND=16)
 Value 0, time:  0.175765991
 Value HUGE(KIND=4), time:  0.181162953
 Value HUGE(KIND=8), time:  0.186082959
 Value HUGE(KIND=16), time:  0.207401991

Times are CPU times in seconds, for one million integer writes into a buffer 
string. With the patch, we see that integer decimal output is almost 
independent of the value written, meaning the I/O library overhead is dominant, 
not the decimal conversion. For this reason, I don’t think we really need a 
faster implementation of the 64-bit itoa, and can keep the current 
series-of-division-by-10 approach.

---

This patch applies on top of my previous itoa-related patch at 
https://gcc.gnu.org/pipermail/fortran/2021-December/057218.html

The patch has been bootstrapped and regtested on two 64-bit targets: 
aarch64-apple-darwin21 (development branch) and x86_64-pc-gnu-linux. I would 
like it to be tested on a 32-bit target without 128-bit integer type. Does 
someone have access to that?

Once tested on a 32-bit target, OK to commit?

FX



itoa-faster.patch
Description: Binary data


timing.f90
Description: Binary data

[PATCH] Simplify integer output-related functions in libgfortran

[FX via Gcc-patches]

Merry Christmas!

The code related to integer output in libgfortran has accumulated some… 
oddities over the years. I will soon post a finalized patch for faster 
integer-to-decimal conversion (see 
https://gcc.gnu.org/pipermail/fortran/2021-December/057201.html), but while 
working on that I found a couple of things we ought to fix, that are not 
directly related.

So this patch is a simplification patch, a no-op. It does the following things:

 - gfc_itoa() is always called for nonnegative values, to make it take an 
unsigned arg. It allows us to simplify the code handling for negative signs 
(instead of doing it in two places).
 - fix undefined behaviour on possible overflow when negating large negative 
values (-HUGE-1)
 - all callers of write_decimal() always use gfc_itoa() as conversion function, 
so remove one layer of indirection: get rid of that argument, call gfc_itoa() 
directly inside write_decimal()
 - gfc_xtoa() is only used in one file anymore, so move it there and rename it 
to xtoa()
 - ztoa_big() is renamed to xtoa_big(), following the convention of other 
?to_big() functions
 - runtime/backtrace.c is the only user of gfc_itoa() outside the I/O system; 
add a comment so we remember in the future why we use gfc_itoa() there… and 
what are its limits

All this makes the code easier to understand, more consistent, probably 
marginally more efficient (the gfc_itoa pointer indirection), and will make the 
future work on speeding up gfc_itoa() easier.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX



itoa.patch
Description: Binary data

Libbacktrace: Fix the use of newline in sed replacement

[FX via Gcc-patches]

Hi,

Libbacktrace fails to run “make check" on macOS (*-apple-darwin21), where the 
system make is GNU Make 3.81. But I think it would occur on all platforms that 
are not ELF and use make < 4. Running `make check` leads to this failure:

elf_32.c:144:26: error: extra tokens at end of #undef directive [-Werror]
  144 | #undef BACKTRACE_ELF_SIZE#define BACKTRACE_ELF_SIZE 32
  |  ^

where the invalid elf_32.c is generated by this command:

SEARCH='#error "Unknown BACKTRACE_ELF_SIZE"'; \
REPLACE='#undef BACKTRACE_ELF_SIZE\
#define BACKTRACE_ELF_SIZE'; \
/usr/bin/sed "s/^$SEARCH\$/$REPLACE 32/" \
/tmp/gcc-darwin-arm64/libbacktrace/elf.c \
> elf_32.c.tmp
mv elf_32.c.tmp elf_32.c

This tries to have a newline inside the REPLACE string, and pass it to sed. 
This fails with GNU Make < 4. And GCC requires "GNU make version 3.80 (or 
later)".

The portable solution is given in the autoconf manual: 
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Newlines-in-Make-Rules.html

Attached is a patch that fixes it. Tested on x86_64-apple-darwin21.
OK to commit?

FX



libbacktrace.patch
Description: Binary data

Re: _Float16-related failures on x86_64-apple-darwin

[FX via Gcc]

> I’m not sure what the fix should be, either. We could use fixinclude to make 
> the darwin headers happy, but we don’t really have a macro to provide the 
> right value. Like a __FLT_EVAL_METHOD_OLDSTYLE__ macro.
> 
> What should be the float_t and double_t types for FLT_EVAL_METHOD == 16? 
> float and double, if I understand right?

This is one possibility, assuming I am right about the types:

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 46e3b8c993a..bea85ef7367 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -1767,6 +1767,18 @@ fix = {
 test_text = ""; /* Don't provide this for wrap fixes.  */
 };
 
+/*  The darwin headers don't accept __FLT_EVAL_METHOD__ == 16.
+*/
+fix = {
+hackname  = darwin_flt_eval_method;
+mach  = "*-*-darwin*";
+files = math.h;
+select= "^#if __FLT_EVAL_METHOD__ == 0$";
+c_fix = format;
+c_fix_arg = "#if __FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == 16";
+test_text = "#if __FLT_EVAL_METHOD__ == 0";
+};
+
 /*
  *  Fix  on Digital UNIX V4.0:
  *  It contains a prototype for a DEC C internal asm() function,


Sucks to have to fix headers… and we certainly can’t fix people’s code that may 
depend on __FLT_EVAL_METHOD__ have well-defined values. So not convinced this 
is the right approach.

FX

Re: _Float16-related failures on x86_64-apple-darwin

[FX via Gcc]

Hi,

> See  https://gcc.gnu.org/bugzilla//show_bug.cgi?id=100854 .

I found that, indeed, but what I struggle to see is: this behaviour of 
__FLT_EVAL_METHOD__ has been around for several years now, so why aren’t there 
more tests failing?

I’m not sure what the fix should be, either. We could use fixinclude to make 
the darwin headers happy, but we don’t really have a macro to provide the right 
value. Like a __FLT_EVAL_METHOD_OLDSTYLE__ macro.

What should be the float_t and double_t types for FLT_EVAL_METHOD == 16? float 
and double, if I understand right?

FX

_Float16-related failures on x86_64-apple-darwin

[FX via Gcc]

Hi,

Some recently introduced tests have been failing for several weeks on 
x86_64-apple-darwin.

FAIL: gcc.target/i386/cond_op_maxmin__Float16-1.c
FAIL: gcc.target/i386/pr102464-copysign-1.c
FAIL: gcc.target/i386/pr102464-fma.c
FAIL: gcc.target/i386/pr102464-maxmin.c
FAIL: gcc.target/i386/pr102464-sqrtph.c
FAIL: gcc.target/i386/pr102464-sqrtsh.c
FAIL: gcc.target/i386/pr102464-vrndscaleph.c

In all cases the symptom is the same: the include of  errors out with 
“Unsupported value of __FLT_EVAL_METHOD__”. It appears that the compile option 
-mavx512fp16 defines __FLT_EVAL_METHOD__ to have value 16, which is not 
understood by darwin:

> /*  Define float_t and double_t per C standard, ISO/IEC 9899:2011 7.12 2,
> taking advantage of GCC's __FLT_EVAL_METHOD__ (which a compiler may
> define anytime and GCC does) that shadows FLT_EVAL_METHOD (which a
> compiler must define only in float.h).
> */
> #if __FLT_EVAL_METHOD__ == 0
> typedef float float_t;
> typedef double double_t;
> #elif __FLT_EVAL_METHOD__ == 1
> typedef double float_t;
> typedef double double_t;
> #elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1
> typedef long double float_t;
> typedef long double double_t;
> #else /* __FLT_EVAL_METHOD__ */
> #   error "Unsupported value of __FLT_EVAL_METHOD__."
> #endif /* __FLT_EVAL_METHOD__ */


Is the use of __FLT_EVAL_METHOD__ set to 16 supposed to be portable across all 
targets? Or is it linux-only, and should marked as such?

Thanks for any help you can give.

FX

Many analyzer failures on non-Linux system (x86_64-apple-darwin)

[FX via Gcc]

Hi David, hi everone,

I’m trying to understand how best to fix or silence the several failures in 
gcc.dg/analyzer that occur on x86_64-apple-darwin. Some of them, according to 
gcc-testresults, also occur on other non-Linux targets. See for example, the 
test results at 
https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html

## gcc.dg/analyzer/torture/asm-x86-linux-*.c

Are these supposed to be run only on Linux (as the name implies)? Four of them 
fail on x86_64-apple-darwin, because they use assembly that is not supported:

FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c

Should they be restricted to Linux targets? There is another one that has the 
same error, as well, although it doesn’t have linux in the name:

FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c


## Builtin-related failures

Those four cases fail:

gcc.dg/analyzer/data-model-1.c

gcc.dg/analyzer/pr103526.c
gcc.dg/analyzer/taint-size-1.c
gcc.dg/analyzer/write-to-string-literal-1.c

but pass if the function calls (memset and memcpy) are replaced by the built-in 
variant (__builtin_memset and __builtin_memcpy). The reason for that is the 
darwin headers, in  (included from ) does this:

#if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__)
#undef memcpy
/* void *memcpy(void *dst, const void *src, size_t n) */
#define memcpy(dest, ...) \
__builtin___memcpy_chk (dest, __VA_ARGS__, __darwin_obsz0 
(dest))
#endif

where __darwin_obsz0 is defined thusly:

#define __darwin_obsz0(object) __builtin_object_size (object, 0)


Does the analyzer not handle the _chk builtin variants? Should it?
I’m happy to investigate more, but I’m not sure what to do.


Best,
FX

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

[FX via Gcc-patches]

Thanks Thomas, pushed as 228173565eafbe34e44c1600c32e32a323eb5aab



228173565eafbe34e44c1600c32e32a323eb5aab.patch
Description: Binary data

Re: [patch, Fortran] IEEE support for aarch64-apple-darwin

[FX via Gcc-patches]

Hi Thomas,

> OK, and thanks for the patch!

Thanks for the review, committed a slightly amended patch as 
220b9bdfe8faebdd2aea0ab7cea81c162d42d8e0 with underflow control support added.

FX



ieee.patch
Description: Binary data

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

[FX via Gcc-patches]

Hi Thomas,

> I am not sure the logic is correct for POWER (old style) where we have
> a 16-byte long double made up from two 8-byte doubles, which is not
> __float128 (IFmode)

As written, the patch should be a no-op for existing platforms. I know about 
the ppc double-double "long double" type, and I think it works. (If it is 
actually broken, please let me know how, I’ll improve the patch.)

If we follow the logic of mk-kinds-h.sh:

- it will loop over real kinds, and reach kind=16
- [ $long_double_kind -eq 10 ] is false, so we go to the second block
- we define the following:

>   ctype="long double"
>   cplxtype="complex long double"
>   suffix="l"
> + echo "#define GFC_REAL_16_IS_LONG_DOUBLE"


which is true.


> I have a proposal: Since I am currently trying to unravel this
> on the power-ieee128 branch, I would like to take this on,
> if that is fine with you.

I’m not opposed, but I’d really like to get this into the current branch. It is 
a much less invasive change than the power-ieee128 work. The only case I 
changed is the case where there is a kind 16, and there is a long double, but 
the long double is neither kind 10 neither kind 16. I don’t think there is such 
a platform currently (otherwise it wouldn’t have worked).

Best,
FX

Re: [PATCH] Testsuite: mark two tests that require alias

[FX via Gcc-patches]

> I think such patches are OK under the "trivial and obvious rules”.

Committed as ba64166bf81b6eaa6e12e1aab786f22f6605401f

FX

[PATCH] Testsuite: mark two tests that require alias

[FX via Gcc-patches]

Hi,

Not sure who can review/approve this patch. These two tests have been failing 
on darwin, apparently since they were introduced earlier this year. Mark them 
with dg-require-alias.

Tested on aarch64-apple-darwin21.
OK to commit?

FX




alias.patch
Description: Binary data

Re: [patch] Future-proof and homogenise handling of darwin versions

[FX via Gcc-patches]

> Yes, but please put this ^^ explanation into the git commit log, and prepend 
> the title line with Darwin:

Thanks, committed.

FX

Re: [patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

[FX via Gcc-patches]

Hi Harald,

I’m not on the list for now, please keep me in CC so I don’t miss replies. 
Thought it feels nice to be working on gfortran again :)


> However, I am wondering if calling the macros safe_* gives a false
> impression of what they actually do.  The cases where they are used
> with your patch applied seem sane, for now, though.

I thought about that, it’s not really “safer” than the underlying C library 
obviously. I couldn’t find a better name, but I’ll wait before I commit so 
others can suggest something else.

unrelated PS: I’ve been thinking aloud and benchmarking faster integer I/O for 
libgfortran at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
Comments are welcome on the proposed design, I think the current proposal is a 
low-hanging fruit (not risky, much faster).


Best,

FX

[patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

[FX via Gcc-patches]

Hi,

Functions from  should only be called on values that can be 
represented by unsigned char. On targets where char is a signed type, some of 
libgfortran calls have undefined behaviour.

The solution is to cast the argument to unsigned char type. I’ve defined macros 
in libgfortran.h to do so, to retain legibility of the library code.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX



pr95177.patch
Description: Binary data

Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

[FX via Gcc-patches]

Patch committed, after changing “call abort” to “stop”.
Thanks for the review.

FX

Re: [patch] Fix libfortran/98507, handling of timezone near year boundaries

[FX via Gcc-patches]

> OK after fixing the above, and thanks for the patch!

Patch committed, after changing “call abort” to “stop”.
Thanks for the review.

FX

Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

[FX via Gcc-patches]

With correct patch attached, sorry.



Hi,

Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255 

Trivial fix, adding a testcase.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX



pr101255.patch
Description: Binary data

[patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

[FX via Gcc-patches]

Hi,

Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255
Trivial fix, adding a testcase.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX




pr98507.patch
Description: Binary data