Testsuite: fix contructor priority test

Bordering on obvious, tested on darwin where the test case fails before (and now passes). OK to commit? FX 0001-Testsuite-fix-contructor-priority-test.patch Description: Binary data

[PATCH] aarch64: fix format specifier

A rather trivial fix for fprintf() specifier of a HOST_WIDE_INT value. Tested on aarch64-apple-darwin. OK to commit? FX 0001-aarch64-fix-format-specifier.patch Description: Binary data

Re: [PATCH] core: Support heap-based trampolines

and libgcc. Currently regtesting on x86_64 linux and darwin (it was fine before I split up into three commits, so I’m re-testing to make sure I didn’t screw anything up). OK to commit? FX 0001-core-Support-heap-based-trampolines.patch Description: Binary data 0002-target-Support-heap-based

Re: [PATCH] Add __builtin_iseqsig()

6 weeks later, I’d like to ask a global maintainer to review this. The idea was okay’ed previously by Joseph Myers, but he asked for testing of both the quiet and signalling NaN cases, which is now done. FX > Le 6 juin 2023 à 20:15, FX Coudert a écrit : > > Hi, > > (It

Re: [PATCH] core: Support heap-based trampolines

Hi, > Since this affects the ABI of libgcc I think we don't want that part > to be user configurable but rather determined by > some static list of targets that opt-in to this config. If I do that, do the Linux maintainers want Linux in or out? > You mention setjmp/longjmp - on darwin and

[PATCH] core: Support heap-based trampolines

. OK to commit? FX 0001-core-Support-heap-based-trampolines.patch Description: Binary data

Re: [PATCH] Add __builtin_iseqsig()

ping**3 >> Le 6 juin 2023 à 20:15, FX Coudert a écrit : >> >> Hi, >> >> (It took me a while to get back to this.) >> >> This is a new and improved version of the patch at >> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602

Re: [PATCH] Add __builtin_iseqsig()

ping**2 > Le 6 juin 2023 à 20:15, FX Coudert a écrit : > > Hi, > > (It took me a while to get back to this.) > > This is a new and improved version of the patch at > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html > It addresses the comment

Re: [PATCH] Add __builtin_iseqsig()

n the case of both quiet and signaling NaNs, which 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

“IEEE_SUPPORT_*” functions. FX

Re: libgfortran: remove support for --enable-intermodule

> OK, thanks. Committed at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ecc96eb5d2a0e5dd93365ef76a58d7f754273934

libgfortran: remove support for --enable-intermodule

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109373 I don’t believe it is widely used, and it was removed from everywhere else in gcc. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? FX 0001-libgfortran-remove-support-for-enable-intermodule.patch Description: Binary data

gcc/config.in was not regenerated

EFAULT_STK_CLASH_GUARD_SIZE which I think are because this commit https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0a85544e1aaeca41133ecfc438cda913dbc0f122 should have regenerated and committed config.in <http://config.in/> Christina, can you please have a look? 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

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 IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

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

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

[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

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

[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

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

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

Re: [PATCH] Add __builtin_iseqsig()

pick it up and finish, otherwise it will have to wait for the next version. FX

Re: [PATCH] Add __builtin_iseqsig()

all for GCC 13. FX

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] 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] 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] Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES

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

Re: [PATCH] Fortran 2018 rounding modes changes

that only radix 2 is supported. That also makes sense. I’ll propose a patch. Thanks, FX

Re: [PATCH] Fortran 2018 rounding modes changes

at 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

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

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

Hi Mikael, > Looks good, thanks. Thank you for your reviews. This patch is committed to trunk: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4637a1d293c978816ad622ba33e3a32a78640edd FX

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

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

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 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_SIGNBIT and IEEE_FMA functions

tches, then intend to document the current state of things once the dust has settled. 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

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] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

ow how to handle. FX

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

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 >

[PATCH] Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES

, 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

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

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

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

art from aesthetics I don’t see why. FX

[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

[PATCH] Add __builtin_iseqsig()

and regtested on x86_64-linux. OK to commit? (I’m not very skilled for middle-end hacking, so I’m sure there will be modifications to make.) FX 0001-Add-__builtin_iseqsig.patch Description: Binary data

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

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

- and 64-bit. OK to commit? FX 0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch Description: Binary data

[PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

instruction (as expected). Regression-tested on x86_64-pc-linux-gnu. OK to commit? FX 0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch Description: Binary data

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

library code for now, but when the patch is committed we can add the removal of IEEE_VALUE and IEEE_CLASS from the library to this list: https://gcc.gnu.org/wiki/LibgfortranAbiCleanup FX

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

t; + break; Do we need a default label? It’s not like this is a more likely case than anything else… Thanks, FX

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

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

Re: [PATCH] Implement __builtin_issignaling

is checked by check_effective_target_issignaling in gcc/testsuite/lib/target-supports.exp, and probes the support for the issignaling macro in . I think it would make sense to adjust those tests to run on a wider range of targets, using the new built-in. FX

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

nd report both here. This will help investigate. Thanks, FX signature.asc Description: Message signed with OpenPGP

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

> 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

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

> /usr/include/fenv.h. I see. Then we probably can use AC_CHECK_FUNCS, or design a specific check, so that it gives the right value on both glibc and FreeBSD targets. Could you test something on your end? FX

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

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

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

oes the patch affect the results of “make check-gfortran”? Thanks, 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

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

whether the first double is a sNaN or qNaN. > > Ok for trunk? It doesn’t hurt to provide an implementation, in any case. OK to push, and thanks for the patch. FX

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

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

> 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

code generic, but if you think it’s a problem I can remove that part and make it error out. I followed the logic used in glibc to deal with bit layout and endianness, so it should be safe as currently proposed. FX

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

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

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

allow us to meaningfully pass signaling NaNs in float and double types, sadly. 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_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_CLASS recognize signaling NaNs

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

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

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

how 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

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

[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

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

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

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 IE

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

[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

[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

[PATCH] Libquadmath: add nansq() function

-darwin21 (port under development). OK to commit? FX 0001-Libquadmath-Add-nansq-function.patch Description: Binary data

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

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

[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

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

/bugzilla/show_bug.cgi?id=47334 ChangeLog and patch description amended. OK to commit? FX 0001-LTO-Prune-some-warnings-in-the-testsuite.patch Description: Binary data

Re: [PATCH] Make integer output faster in libgfortran

, and bootstrapped the attached patch on x86_64-pc-linux-gnu. FX static_assert.diff Description: Binary data

[PATCH] Prune LTO warnings that some tests fail

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

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

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

irection of libgfortran's I/O system (which are necessary because of the rich I/O formatting allowed by the standard). Best, FX

Re: [PATCH] Make integer output faster in libgfortran

but if someone who is already set up to do can fire a quick regtest, that would be great ;) FX

[PATCH] Make integer output faster in libgfortran

someone have access to that? Once tested on a 32-bit target, OK to commit? FX itoa-faster.patch Description: Binary data timing.f90 Description: Binary data

[PATCH] Simplify integer output-related functions in libgfortran

. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? FX itoa.patch Description: Binary data

Libbacktrace: Fix the use of newline in sed replacement

Make < 4. And GCC requires "GNU make version 3.80 (or later)". The portable solution is given in the autoconf manual: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Newlines-in-Make-Rules.html Attached is a patch that fixes it. Tested on x86_64-apple-darwi

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

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

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

there is a long double, but the long double is neither kind 10 neither kind 16. I don’t think there is such a platform currently (otherwise it wouldn’t have worked). Best, FX

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

> I think such patches are OK under the "trivial and obvious rules”. Committed as ba64166bf81b6eaa6e12e1aab786f22f6605401f 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] 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

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] 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 libfortran/101255, wrong IOSTAT value for FLUSH

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

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

<    1   2   3   4   5   6   >