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

[FX via Fortran]

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

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

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

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

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

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

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

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

[FX via Fortran]

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

Quick test integrating the idea into libgfortran, here are the timings to make 
a formatted write of 10 million integers into a string:

- very small value (1), negligible speedup (2.273s to 2.248s)
- small value (1042), speedup of 28% (3.224s to 2.350s)
- huge(0_8), speed up of 50% (5.914s to 2.560s)
- huge(0_16), speed up of 83% (19.46s to 3.31s)

Conclusion: this looks quite interesting! I’m not sure what use cases people 
have for writing lots of formatted integers, but this doesn’t sound too bad.

Further thought: fast 64-bit itoa() implementations, under the MIT license 
(https://github.com/jeaiii/itoa) promise a speed-up of 2 to 10 times compared 
to naive implementation. That could bring us down further, but we probably 
cannot incorporate that, right?

Two questions:

1. This is easy, am I missing something? Some reason why it was never tried 
before?
2. Why is gfc_xtoa() in runtime/error.c? We should probably move it.

Cheers,
FX

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

[FX via Fortran]

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

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

Thanks Thomas, pushed as 228173565eafbe34e44c1600c32e32a323eb5aab



228173565eafbe34e44c1600c32e32a323eb5aab.patch
Description: Binary data

[PATCH] Simplify integer output-related functions in libgfortran

[FX via Fortran]

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

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

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

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

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

Re: [PATCH] Make integer output faster in libgfortran

[FX via Fortran]

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

Need for __builtin_issignaling()

[FX via Fortran]

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

[pushed] Fortran: keep

[FX via Fortran]

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

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] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Fortran]

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

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

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

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

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

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

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

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

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

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

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

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: detect signaling NaNs on targets without issignaling macro in libc

[FX via Fortran]

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

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

> 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: New signaling NaN causes 12 testsuite failures

[FX via Fortran]

Hi Steve,

> New signaling NaN causes 12 testsuite failures

Thanks for alerting me.


> Line 42 of signal_1.f90 looks wrong unless the
> line is testing conversion on assignment.  Should
> y be x?

Indeed. Fixed: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c0a4a658097c56fa03d04b8d15c3ea02961d62a4


> Got the following in testsuite/gfortran/gfortran.log
> 
> NaN 7FFFA000
> NaN 7FFFC000
> NaN 7FFFA000
> 
> and with "stop 300" commented out everything passes.  Now to
> chase down hex representations for sNaN and qNaN.  Suspect
> ieee_class() is broken.

How does the long double formation look like on x86_64-unknown-freebsd?
That test passes on x86_64 for linux and darwin, so I’m wondering what’s 
different about freebsd…

Can you tell me whether the C front-end defines __LDBL_IS_IEC_60559__? What is 
the value of __LDBL_DIG__? __DBL_DIG__? __FLOAT_WORD_ORDER == __BIG_ENDIAN or 
__LITTLE_ENDIAN?


FX

Re: New signaling NaN causes 12 testsuite failures

[FX via Fortran]

> FAIL: gfortran.dg/ieee/signaling_3.f90   -O0  execution test

For that one, can you confirm it’s a 64-bit run, not -m32?
I’ve fixed that case: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0336ab4e7e2eb58a64d8ee4e5e8083dd53a4d2d

FX

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

[FX via Fortran]

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: powerpc64le real(kind=16) and IEEE_{ARITHMETIC,EXCEPTIONS} modules

[FX via Fortran]

> Thus, more functions could be handled in the compiler itself.
> (Likewise for INTMOD_IEEE_EXCEPTIONS, not that I know whether
> that has any relevant functions.)

In theory, there is no reason why we need an explicit .mod file in the library 
for any of the three IEEE modules. They would probably be better treated as 
compiler intrinsics in the front-end itself, in fact, like all other 
intrinsics. It would also be easier to adjust for generic forms, and provide 
better diagnostics for mismatching arguments, etc. This seems to be the way to 
go, as the next standard versions have added even more intrinsics, some of 
which really shouldn’t be function calls (comparison, ordering, etc).

The reason those modules are not fully implemented in the front-end is simple: 
I didn’t know how to implement them directly in the front-end, and I am not 
entirely sure we have the appropriate stuff for that. ISO_FORTRAN_ENV is 
implemented in the front-end, but its members are simpler, really.

In a way, you can see this as a call for help: if someone front-end-savvy has 
ideas how to do this, we could partner up ;)

FX

Re: New signaling NaN causes 12 testsuite failures

[FX via Fortran]

> With --disable-multilib, so no -m32 support, I still 
> signaling_3.f90 failing.  In
> 
> ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> ! x87 / x86-32 ABI is unsuitable for signaling NaNs

This just means the test shouldn’t be run on 32-bit Intel.

Can you run this:

#include 
#include 
#include "issignaling_fallback.h"

int main (void) {
  long double z;
 
  z = __builtin_nansl("");
  printf("%d\n", issignaling(z));

  z = __builtin_nanl("");
  printf("%d\n", issignaling(z));
}

compiled with -fsignaling-nans and the issignaling_fallback.h file from 
libgfortran?

FX

Re: New signaling NaN causes 12 testsuite failures

[FX via Fortran]

This is x86_64-linux, with the same source:

$ gcc-10 v.c -fsignaling-nans && ./a.out
Quiet NaN
nan 7fc0
nan 7ff8
nan 564e29277fffc000
Signaling NaN
nan 7fa0
nan 7ff4
nan 564e29277fffa000

Re: New signaling NaN causes 12 testsuite failures

[FX via Fortran]

> Found it.  https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
> 
> Add trailing undersores to __FLOAT_WORD_ORDER and change
> __BIG_ENDIAN to __ORDER_BIG_ENDIAN__.  Likewise for LITTLE.

Thanks Steve!

What I wonder is: if those conditions failed, then the struct they define 
should have been empty, and therefore the code shouldn’t compile anyway (that 
was the intent).

Does the attached patch fix the remaining failures?

FX

commit 03cfe155f46c05e4dda349be2abe467c16789491
Author: Francois-Xavier Coudert 
Date:   2022-01-25 21:54:03 +0100

Fortran: fix issignaling() implementation

libgfortran/ChangeLog:

* ieee/issignaling_fallback.h: Fix GCC-specific preprocessor
macros.

diff --git a/libgfortran/ieee/issignaling_fallback.h 
b/libgfortran/ieee/issignaling_fallback.h
index 4632bc510f7..fc59481c43b 100644
--- a/libgfortran/ieee/issignaling_fallback.h
+++ b/libgfortran/ieee/issignaling_fallback.h
@@ -103,12 +103,12 @@ typedef union
   long double value;
   struct
   {
-#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__
 int sign_exponent:16;
 unsigned int empty:16;
 uint32_t msw;
 uint32_t lsw;
-#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+#elif __FLOAT_WORD_ORDER__ == __ORDER_LITTLE_ENDIAN__
 uint32_t lsw;
 uint32_t msw;
 int sign_exponent:16;
@@ -146,10 +146,10 @@ typedef union
   long double value;
   struct
   {
-#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__
 uint64_t msw;
 uint64_t lsw;
-#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+#elif __FLOAT_WORD_ORDER__ == __ORDER_LITTLE_ENDIAN__
 uint64_t lsw;
 uint64_t msw;
 #endif
@@ -191,10 +191,10 @@ typedef union
   __float128 value;
   struct
   {
-#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__
 uint64_t msw;
 uint64_t lsw;
-#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+#elif __FLOAT_WORD_ORDER__ == __ORDER_LITTLE_ENDIAN__
 uint64_t lsw;
 uint64_t msw;
 #endif

Re: New signaling NaN causes 12 testsuite failures

[FX via Fortran]

>> Does the attached patch fix the remaining failures?
> 
> Yes!
> 
> % gmake check-fortran RUNTESTFLAGS="ieee.exp=signaling_\*"
> ...
>=== gfortran Summary ===
> 
> # of expected passes24
> # of unsupported tests  6

Thanks Steve, pushed: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fa262add75ab6631bf22b7e2884437ba9c62ed2a

FX

Re: New signaling NaN causes 12 testsuite failures

[FX via Fortran]

> AFAICT, the first condition does not fail due to the missing
> trailing underscores.
> 
> #if __FLOAT_WORD_ORDER == __BIG_ENDIAN
> 
> becomes (I believe)
> 
> #if 0 == 0
> 
> so FreeBSD was using big endian in FX's issignaling_fallback
> when it needed little endian.

Yeah that makes total sense.

FX

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

[FX via Fortran]

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: use fpu-glibc on powerpc*-unknown-freebsd

[FX via Fortran]

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] fortran: use fpu-glibc on powerpc*-unknown-freebsd

[FX via Fortran]

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

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

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

> 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: Expand ieee_arithmetic module's ieee_class inline [PR106579]

[FX via Fortran]

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

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

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

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

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

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

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

Floating-point comparisons in the middle-end

[FX via Fortran]

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: Floating-point comparisons in the middle-end

[FX via Fortran]

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?

Re: Floating-point comparisons in the middle-end

[FX via Fortran]

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

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

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

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

> 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

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

[FX via Fortran]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FX



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

[committed] Fix FMA test case

[FX via Fortran]

I’ve committed the attached patch as obvious, relaxing the IEEE_FMA tests to 
remove some floating-point equality tests that failed on various targets 
(powerpc in this case): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=31d7c8bc2630e1b5a35ccce97ac862c4920ba582

FX



0001-Fortran-fix-testcases.patch
Description: Binary data

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

[FX via Fortran]

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

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

[FX via Fortran]

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

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

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

[FX via Fortran]

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

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