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

Hi, > Joseph's reply earlier in this thread has indicated a desire to verify that > verifies FE_INVALID is raised when appropriate and not raised when > inappropriate when the arguments come from volatile variables rather than > directly from constants. > > The patch itself looks pretty

Re: [PATCH] Add __builtin_iseqsig()

Hi, Just adding, from the Fortran 2018 perspective, things we will need to implement for which I think support from the middle-end might be necessary: - rounded conversions: converting, from an integer or floating point type, into another floating point type, with specific rounding mode passed

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 : >>> >>> Attached patch adds __builtin_iseqsig() to the middle-end and C family

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-ends. >> Testing does not currently check

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

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

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

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

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

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

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

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

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

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

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:

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

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

[PATCH] Add __builtin_iseqsig()

Attached patch adds __builtin_iseqsig() to the middle-end and C family front-ends. Testing does not currently check whether the signaling part works, because with optimisation is actually does not (preexisting compiler bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805) Bootstrapped and

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

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

[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

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

Re: [PATCH] Implement __builtin_issignaling

Hi Jakub, Thank you for taking this on (this patch and the Fortran ones), it is really appreciated and will improve gfortran's IEEE conformance. - "Implement __builtin_issignaling”: is approved for the tiny Fortran part - "libgfortran: Use __builtin_issignaling in libgfortran”: was approved by

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,

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 >

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

Hi Richard, The patch for PR100786 introduced a testcase that systematically fails on darwin: FAIL: gcc.dg/torture/pr100786.c -O0 (test for excess errors) FAIL: gcc.dg/torture/pr100786.c -O1 (test for excess errors) FAIL: gcc.dg/torture/pr100786.c -O2 (test for excess errors) FAIL:

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

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

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

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

[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

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

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:

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

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

[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

Re: [PATCH] Libquadmath: add nansq() function

Hi Joseph, > All targets with _Float128 should have __builtin_nansf128, since we have > DEF_GCC_FLOATN_NX_BUILTINS (BUILT_IN_NANS, "nans", NAN_TYPE, > ATTR_CONST_NOTHROW_NONNULL) > in builtins.def. Hum, I see, I didn’t know that version existed. To be honest, I find the “other built-ins” doc

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

Hi, This patch adds nansq() to libquadmath, a function that returns a signalling NaN. It is a need for full libgfortran support of signalling NaNs, because not all targets that have _Float128 define a __builtin_nanq() function. Bootstrapped and tested on x86_64-pc-gnu-linux and

[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

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

Hi, > Did you mean to include the change pruning visibility warnings? I don't > think it's necessarily wrong, it just doesn't match the patch description or > ChangeLog. Yes, I think they should be applied, and will fix long-standing failures reported in

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

[PATCH] Prune LTO warnings that some tests fail

The testcase g++.dg/torture/pr31863.C fails on *-apple-darwin with: FAIL: g++.dg/torture/pr31863.C -O2 -flto (test for excess errors) Excess errors: lto-wrapper: warning: using serial compilation of 2 LTRANS jobs The test otherwise works fine, but those lto warnings should be pruned. OK to

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

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

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,

[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

Libbacktrace: Fix the use of newline in sed replacement

Hi, Libbacktrace fails to run “make check" on macOS (*-apple-darwin21), where the system make is GNU Make 3.81. But I think it would occur on all platforms that are not ELF and use make < 4. Running `make check` leads to this failure: elf_32.c:144:26: error: extra tokens at end of #undef

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,

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

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

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

[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

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

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

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

[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

[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

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

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

[patch] Fix build when source directory includes @ character

Hi, Attached is a fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076 Currently, we cannot build GCC when the source directory contains a @ character (which is a problem for Homebrew, where we typically build in directories such as /tmp/gcc@10/src:

Re: [PATCH] PR fortran/97272 - Wrong answer from MAXLOC with character arg

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

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

Fortran: fix another function argtypes bug for ppc

This is another function argtypes issue, very similar to This code from proc_ptr_comp_13.f90 : ! PR 40882: [F03] infinite recursion in gfc_get_derived_type with PPC returning derived type. ! At the same time, check that a formal argument does not cause infinite recursion (PR

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 conventions there and what we would need > to correc the function decl to use build_function_type_list? Done. FX

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

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

Hi, The Fortran front-end, in gfc_trans_fail_image() emits a call to _gfortran_caf_fail_image with one argument (a NULL pointer): return build_call_expr_loc (input_location, gfor_fndecl_caf_fail_image, 1, build_int_cst

[patch] Fortran: fix prototype of _gfortran_is_extension_of()

Hi, The problem was reported in detail here: https://gcc.gnu.org/pipermail/fortran/2020-September/055005.html and in previous messages. When resolving select type constructs, the Fortran front-end is trying to use the _gfortran_is_extension_of() library call (which is also used for the

[patch] Fortran: fix prototype for class vptr fields

Hi, Attached is a patch fixing the problem at: https://gcc.gnu.org/pipermail/fortran/2020-September/054978.html the reasoning behind the solution is explained here: https://gcc.gnu.org/pipermail/fortran/2020-September/054997.html In short, calls to class copy functions are made with wrong