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

[committed] Fix FMA test case

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=31d7c8bc2630e1b5a35ccce9

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

Re: [PATCH] Fortran 2018 rounding modes changes

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 o

Re: [PATCH] Fortran 2018 rounding modes changes

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 shoul

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> > >> Le 31 août 2022 à 20:29, FX a écrit

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

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

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

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 o

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). > > 1. Add the new IEE

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

> 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

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

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 i

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

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 externa

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

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

[PATCH] Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES

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

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

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

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

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 fr

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

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

Re: Floating-point comparisons in the middle-end

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

Re: Floating-point comparisons in the middle-end

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

Re: Floating-point comparisons in the middle-end

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

> 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"); f

Re: Floating-point comparisons in the middle-end

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 For

Re: Floating-point comparisons in the middle-end

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

Floating-point comparisons in the middle-end

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 inte

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 targ

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

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 6

[PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

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

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

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 use

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

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

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

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 n

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

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

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

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

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

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_fe

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

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

Re: New signaling NaN causes 12 testsuite failures

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

Re: New signaling NaN causes 12 testsuite failures

> 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

Re: New signaling NaN causes 12 testsuite failures

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

> 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

Re: powerpc64le real(kind=16) and IEEE_{ARITHMETIC,EXCEPTIONS} modules

> 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

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

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

Re: New signaling NaN causes 12 testsuite failures

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

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

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

> 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

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

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 typ

[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

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

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

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

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

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

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

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

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 differ

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

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

[PATCH] Fortran: make IEEE_VALUE produce signaling NaNs

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

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

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 (

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_CLASS, by > using the i

[PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

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

[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

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 pa

Need for __builtin_issignaling()

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

Re: [PATCH] Make integer output faster in libgfortran

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 boots

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

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

Re: [PATCH] Make integer output faster in libgfortran

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 woul

Re: [PATCH] Make integer output faster in libgfortran

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

[PATCH] Make integer output faster in libgfortran

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

[PATCH] Simplify integer output-related functions in libgfortran

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

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

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

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

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

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

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 p

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

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

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

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 Trivial fix, adding a testcase. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? FX pr101255.

[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

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

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

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 time to submit the Fortra

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 currently rely on the following as

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

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 m

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

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 d

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

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