[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] PR fortran/97272 - Wrong answer from MAXLOC with character arg

[FX via Gcc-patches]

Hi Harald,

While this is fresh in your memory, could I suggest you have a look at this 
FINDLOC issue, which seems possibly related:
https://gcc.gnu.org/pipermail/fortran/2020-September/055016.html
and further messages from Thomas Koenig?

Thanks,
FX

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 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 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]

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: 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]

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] 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] 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] 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] 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,

> 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] 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: 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

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]

> 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]

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] 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

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

[FX via Gcc-patches]

Hi everyone,

Since support for target aarch64-apple-darwin has been submitted for review, 
it’s time to submit the Fortran part, i.e. enabling IEEE support on that target.

The patch has been in use now for several months, in a developer branch shipped 
by some distros on macOS (including Homebrew). It was authored more than a year 
ago, but I figured it wasn’t relevant to submit until the target was actually 
close to be in trunk: 
https://github.com/iains/gcc-darwin-arm64/commit/b107973550d3d9a9ce9acc751adbbe2171d13736

Bootstrapped and tested on aarch64-apple-darwin20 (macOS Big Sur) and 
aarch64-apple-darwin21 (macOS Monterey).

OK to merge?
Can someone point me to the right way of formatting ChangeLogs and commit 
entries, nowadays?


Thanks,
FX



b107973550d3d9a9ce9acc751adbbe2171d13736.patch
Description: Binary data

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

[FX via Gcc-patches]

Hi,

Right now, the logic in libgfortran for the detection of REAL(KIND=16) is in 
kinds-override.h:

/* What are the C types corresponding to the real(kind=10) and
   real(kind=16) types? We currently rely on the following assumptions:
 -- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is defined,
then it is necessarily the "long double" type
 -- if real(kind=16) exists, then:
 * if HAVE_GFC_REAL_10, real(kind=16) is "__float128"
* otherwise, real(kind=16) is "long double"
   To allow to change this in the future, we create the
   GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran.  */


Well, this may not be true of all platforms, and it’s possible to have other 
combinations. On the aarch64-apple-darwin port, I’m currently playing with 
enabling a binary128 floating-point mode, and that target has double == long 
double… so the assumptions above are not true.

Funnily, we already have more fine-grained logic in the mk-kinds-h.sh script, 
where we actually check the Fortran kind corresponding to C’s long double. We 
just have to use it, and emit the GFC_REAL_16_IS_FLOAT128 / 
GFC_REAL_16_IS_LONG_DOUBLE macros there.


Bootstrapped and regtested on x86_64-linux, checked that no symbols were 
introduced or removed.
(and tested on a port to aarch64-apple-darwin).

OK to commit?

FX



libgfortran.patch
Description: Binary data

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

[FX via Gcc-patches]

Hi Richard,

> This isn't a full review, but I do have a question: is this really specific 
> to Darwin?  or is it really generic aarch64 code?  If the former, then the 
> file name is not right and it should reflect the darwin-specific nature of 
> the contents.  If the latter, then I wonder why most other fortran targets 
> don't seem to have specific implementations of this.

The code is not specific to Darwin, but right now I chose to only enable on 
Darwin because:
- All glibc targets are covered already by using glibc  function calls
- I don’t know if there are other aarch64 targets that exist, support Fortran 
and IEEE, but don’t have glibc

I’d suggest other non-glibc aarch64 targets could be added to the support and 
enable this code, but I don’t want to do it unless it’s been tested there. IEEE 
support is optional in Fortran, so I suggest we keep it “opt-in”: targets where 
it’s known to work enable it, but it’s off by default on other targets.

I hope this explains the rationale.

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] 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: 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] 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 (&body, tmp);
> +   real_from_integer (&real, 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_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

[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: 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 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 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] 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

[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

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

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

[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_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>

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]

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] 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]

> 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 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_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: 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: 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]

> 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] Fix build when source directory includes @ character

[FX via Gcc-patches]

Here is an updated patch, that quotes all three makeinfo special characters: @ 
{ }
Tested on a build with source directory /tmp/foo@bar{gee}qux

OK to commit?



at.diff
Description: Binary data


at.ChangeLog
Description: Binary data

Re: [patch] Fix build when source directory includes @ character

[FX via Gcc-patches]

> OK.  You have commit privs, right?

Yes, and I did commit after Richard’s OK: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=034db20e2ea8301b5dc251bf10a97ce1cf90655f

… but I forgot to send an email saying I had, sorry.

FX

[patch] Fortran: fix prototype for class vptr fields

[FX via Gcc-patches]

Hi,

Attached is a patch fixing the problem at: 
https://gcc.gnu.org/pipermail/fortran/2020-September/054978.html
the reasoning behind the solution is explained here: 
https://gcc.gnu.org/pipermail/fortran/2020-September/054997.html

In short, calls to class copy functions are made with wrong function type:

 >
SI
size  
constant 32>
unit-size  
constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 
0x14461be70
arg-types >
pointer_to_this >

where the arg-types is (void) instead of being undefined (like K&R functions). 
This has no apparent consequences on current targets, but it leads to wrong 
code generation for aarch64-apple-darwin20.

The attached patch fixes this. The patch is regtested on x86_64-apple-darwin19.
I also tested it on aarch64-apple-darwin20 (Iain’s current port based on trunk 
at https://github.com/iains/gcc-darwin-arm64) where it brings the number of 
test failures down from 811 to 166!


OK to commit?

FX



ppc_type.diff
Description: Binary data


ppc_type.ChangeLog
Description: Binary data

[patch] Fortran: fix prototype of _gfortran_is_extension_of()

[FX via Gcc-patches]

Hi,

The problem was reported in detail here: 
https://gcc.gnu.org/pipermail/fortran/2020-September/055005.html and in 
previous messages. When resolving select type constructs, the Fortran front-end 
is trying to use the _gfortran_is_extension_of() library call (which is also 
used for the EXTENDS_TYPE_OF Fortran intrinsic). However, in doing so, it is 
constructing the symbol of the function call without proper formal arguments, 
which leads to the function call being built with a wrong arg-types in the 
function type tree.

This has no known impact on most targets, but it does lead to wrong code 
generation on aarch64-apple-darwin20, which is how this bug was identified. The 
attached patch simply adds proper formal argument list to the intrinsic call.


Regtested on x86_64-apple-darwin19 and tested on aarch64-apple-darwin20.
OK to commit?

FX


is_extension_of.diff
Description: Binary data


is_extension_of.ChangeLog
Description: Binary data

[patch] Fortran: _gfortran_caf_fail_image() should have no argument

[FX via Gcc-patches]

Hi,

The Fortran front-end, in gfc_trans_fail_image() emits a call to 
_gfortran_caf_fail_image with one argument (a NULL pointer):

return build_call_expr_loc (input_location,
gfor_fndecl_caf_fail_image, 1,
build_int_cst (pchar_type_node, 0));

while the prototype for the function in libgfortran is clear that it takes no 
argument:

  void _gfortran_caf_fail_image (void) __attribute__ ((noreturn));

The bug was filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947
This obvious patch removes the useless argument (which triggers wrong code 
generation on aarch64-apple-darwin20).


Regtested on x86_64-apple-darwin19 and tested on aarch64-apple-darwin20.
OK to commit?

FX



fail_image.diff
Description: Binary data


fail_image.ChangeLog
Description: Binary data

Re: [patch] Fortran: _gfortran_caf_fail_image() should have no argument

[FX via Gcc-patches]

> OK!

Committed at 
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3489d80fee42764460cb06f7a2e9f126c18602b4
It’s my first commit since GCC moved to git, let me know if I did it correctly 
:)

FX

Re: [patch] Fortran: fix prototype for class vptr fields

[FX via Gcc-patches]

> Could you maybe put a FIXME at that place, explaining that we are
> in fact following K&R conventions there and what we would need
> to correc the function decl to use build_function_type_list?

Done.

FX

Fortran: fix another function argtypes bug for ppc

[FX via Gcc-patches]

This is another function argtypes issue, very similar to 

This code from proc_ptr_comp_13.f90 :


! PR 40882: [F03] infinite recursion in gfc_get_derived_type with PPC returning 
derived type.
! At the same time, check that a formal argument does not cause infinite 
recursion (PR 40870).
implicit none
type :: t
  procedure(foo), pointer, nopass :: ppc
end type

type(t) :: o, o2
o2 = o%ppc(o)

contains
  function foo(arg)
type(t) :: foo, arg
  end function
end


causes the compiler to emit wrong code for the call to o%ppc(o), because it 
gets the type of the function wrong. Again, the intent was to emit an 
incomplete function type, but this time it is on purpose, and I think 
unavoidable (to avoid infinite recursion). Except, it was done with the wrong 
middle-end call. The patch fixes it.

The patch is regtested on x86_64-apple-darwin19.
I also tested it on aarch64-apple-darwin20, where it fixes wrong code issues in 
several testcases.

OK to commit?

FX



ppc_dt.diff
Description: Binary data


ppc_dt.ChangeLog
Description: Binary data

Re: Fortran: fix another function argtypes bug for ppc

[FX via Gcc-patches]

> OK (you can also put in a quick FIXME there).

Actually the decl being declared is using itself as one of the arguments, so I 
think it’s on purpose that we don’t want to emit a full arglist here… to avoid 
recursion. So I’m not sure we would want to change that.

FX

[patch] Fix build when source directory includes @ character

[FX via Gcc-patches]

Hi,

Attached is a fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076
Currently, we cannot build GCC when the source directory contains a @ character 
(which is a problem for Homebrew, where we typically build in directories such 
as /tmp/gcc@10/src: https://github.com/Homebrew/brew/pull/9007)
The problem is because gcc-vers.texi then contain an unquoted @ character, 
which is interpreted as a texinfo command.
The patch fixes the rule in gcc/Makefile.in so that stray @ characters are 
quoted as @@

Tested and bootstrapped on x86_64-apple-darwin19

PS: It’s possible the same issue occurs with characters { and } in the path 
(according to 
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Conventions.html).
 Do you think they should be quoted too?

Cheers,
FX



at.diff
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, Fortran] Make REAL(KIND=16) detection more robust

[FX via Gcc-patches]

A gentle ping…


> Le 7 déc. 2021 à 15:11, FX  a écrit :
> 
> Hi,
> 
> Right now, the logic in libgfortran for the detection of REAL(KIND=16) is in 
> kinds-override.h:
> 
> /* What are the C types corresponding to the real(kind=10) and
>   real(kind=16) types? We currently rely on the following assumptions:
> -- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is defined,
>then it is necessarily the "long double" type
> -- if real(kind=16) exists, then:
> * if HAVE_GFC_REAL_10, real(kind=16) is "__float128"
>* otherwise, real(kind=16) is "long double"
>   To allow to change this in the future, we create the
>   GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran.  */
> 
> 
> Well, this may not be true of all platforms, and it’s possible to have other 
> combinations. On the aarch64-apple-darwin port, I’m currently playing with 
> enabling a binary128 floating-point mode, and that target has double == long 
> double… so the assumptions above are not true.
> 
> Funnily, we already have more fine-grained logic in the mk-kinds-h.sh script, 
> where we actually check the Fortran kind corresponding to C’s long double. We 
> just have to use it, and emit the GFC_REAL_16_IS_FLOAT128 / 
> GFC_REAL_16_IS_LONG_DOUBLE macros there.
> 
> 
> Bootstrapped and regtested on x86_64-linux, checked that no symbols were 
> introduced or removed.
> (and tested on a port to aarch64-apple-darwin).
> 
> OK to commit?
> 
> FX


libgfortran.patch
Description: Binary data

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

[FX via Gcc-patches]

ping for that patch

(don’t mind the ChangeLog question, I’ve figured it out, will include proper 
ChangeLog in the commit)


> Le 6 déc. 2021 à 17:32, FX  a écrit :
> 
> Hi everyone,
> 
> Since support for target aarch64-apple-darwin has been submitted for review, 
> it’s time to submit the Fortran part, i.e. enabling IEEE support on that 
> target.
> 
> The patch has been in use now for several months, in a developer branch 
> shipped by some distros on macOS (including Homebrew). It was authored more 
> than a year ago, but I figured it wasn’t relevant to submit until the target 
> was actually close to be in trunk: 
> https://github.com/iains/gcc-darwin-arm64/commit/b107973550d3d9a9ce9acc751adbbe2171d13736
> 
> Bootstrapped and tested on aarch64-apple-darwin20 (macOS Big Sur) and 
> aarch64-apple-darwin21 (macOS Monterey).
> 
> OK to merge?
> Can someone point me to the right way of formatting ChangeLogs and commit 
> entries, nowadays?
> 
> 
> Thanks,
> FX
> 
> 

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

[FX via Gcc-patches]

Hi,

DATE_AND_TIME can return incorrect values for non-UTC timezones, near the new 
year, when the local time and UTC time are in different years. 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507

Attached patch fixes the issue by correcting the logic to account for that 
wrapping of “day of the year” around new year. I include a testcase, which 
checks the sanity of values returned by DATE_AND_TIME. Since the bug only 
occurs for a few hours every year, and depends on local timezone, I could not 
think of a better (systematic) test.

I also want to propose (it’s not directly needed to fix the bug) that we switch 
our time routines to rely on clock_gettime() instead of gettimeofday(), when 
available. This is in line with POSIX.1-2008, which marks gettimeofday() as 
obsolete, recommending the use of 
clock_gettime() instead.

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

FX




pr98507.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

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

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]

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

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 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] Future-proof and homogenise handling of darwin versions

[FX via Gcc-patches]

The current GCC branch will become 12.1.0, which will be the stable version of 
GCC when the next macOS version is released. There are some places in GCC that 
don’t handle darwin22 as a version, so we need to future-proof it 
(gcc/config.gcc and gcc/config/darwin-driver.c). We align that code with what 
Apple clang does, i.e. accept all potential major macOS versions until 99.

This patch also homogenises the handling of darwin version numbers, where the 
majority of places use darwin2*, but some used darwin2[0-9]*. Since there never 
was a darwin2.x version, the two are equivalent, and we prefer the simpler 
darwin2*

Bootstrapped and regtested on x86_64-apple-darwin21.
OK to commit?

FX



darwin.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

[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] 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

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, 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]

Thanks Thomas, pushed as 228173565eafbe34e44c1600c32e32a323eb5aab



228173565eafbe34e44c1600c32e32a323eb5aab.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

[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

[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

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

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

[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&R) 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

[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

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

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

[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

[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

[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] 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] 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

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

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] 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

[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: [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

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,

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 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]

> 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_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: [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

[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