Re: [PATCH] Fortran 2018 rounding modes changes

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

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

Re: [PATCH] Add __builtin_iseqsig()

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 : >>> &g

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

t function? - How does the patch affect the results of “make check-gfortran”? Thanks, FX

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

tion 8 | extern double b2 __attribute__((alias("a2"))); | ^~ FX

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

mented 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

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

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

> 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

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

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

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

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

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

t “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()

all for GCC 13. FX

Re: [PATCH] Implement __builtin_issignaling

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

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]

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]

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

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

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

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 targ

Re: [PATCH] Fortran 2018 rounding modes changes

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

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

, 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

art from aesthetics I don’t see why. FX

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

/2018-02/msg00105.html Will replace those abort calls, then. FX

[PATCH] Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES

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

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

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 >

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

how to handle. FX

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

k 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()

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 comp

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

es, then intend to document the current state of things once the dust has settled. FX

Re: [PATCH] Fortran 2018 rounding modes changes

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

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

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

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

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

> 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

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

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

> 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

om/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()

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

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

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

> 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

> 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

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

> 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

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

meone 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

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 curr

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

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

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

commit? FX pr98507.patch Description: Binary data

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

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

With correct patch attached, sorry. Hi, Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255 <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 pr

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

> 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

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

, 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

ng 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

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

> 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

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

> 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

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

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

Thanks Thomas, pushed as 228173565eafbe34e44c1600c32e32a323eb5aab 228173565eafbe34e44c1600c32e32a323eb5aab.patch Description: Binary data

Libbacktrace: Fix the use of newline in sed replacement

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 o

[PATCH] Simplify integer output-related functions in libgfortran

. 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

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

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

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

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

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

Re: [PATCH] Make integer output faster in libgfortran

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

s://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

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

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

-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

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 f

[PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

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

“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

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_C

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

(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

-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

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

y 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

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

(or confirm when the error message is posted). FX test.patch Description: Binary data

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

g 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

> 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

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

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

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 im

[PATCH] Add __builtin_iseqsig()

is now done systematically. Bootstrapped and regtested on x86_64-pc-linux-gnu OK to commit? FX 0001-Add-__builtin_iseqsig.patch Description: Binary data

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

o kind=17 mention in them anywhere. Actually, where is the kind=17 documented? FX

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

(), which I posted for review at: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620801.html Bootstrapped and regtested on x86_64-pc-linux-gnu, OK to commit (once the middle-end patch is accepted)? FX 0002-Fortran-add-IEEE_QUIET_-and-IEEE_SIGNALING_-comparis.patch Description: Binary data

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

e parameter as X. As you saw, the module built as part of libgfortran deals with that. In the longer term, we would need a revamp of those modules to handle everything as intrinsic modules, which would give us more flexibility, but I never found the time to do this migration :( Best, FX

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

magic Thanks for the frank description, Thomas. To be honest, it reinforces my feeling from when this was originally proposed and added: why are we doing so much extra work for a feature that is used by such a tiny fraction of our user base. FX

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

d to get an OK on the middle-end part first, but I consider the Fortran part approved. Thanks, FX 0001-Add-__builtin_iseqsig.patch Description: Binary data 0002-Fortran-add-IEEE_QUIET_-and-IEEE_SIGNALING_-comparis.patch Description: Binary data

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

one for each ABI. I am sure this was considered and rejected, do you remember what was the rationale? Thanks, FX

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

Given the agreement that the patch is not making things for powerpc worse, and the review by Steve, I have committed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=17bccd1d2c0fa1f08e0483c8ed841994a95febb0 Best, FX

<    1   2   3   4   5   6   7   >