Re: Fortran 2008 DATA statement restrictions

Hi, Thanks Harald. I see there are bugs open, but actually not that many, compared to other areas of the compiler :) I think the code I sent was not really covered in the testsuite, so I have committed it (after testing on x86_64-linux). https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a54c71ccc248

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

Hi, > Running > nohup make -j7 check-fortran > RUNTESTFLAGS="--target_board=unix/-mabi=ieeelongdouble/-mcpu=power9"& > from the gcc subdirectory yielded only a single failure: I dug more into the code and I understand why all tests are running: since db630423a97ec6690a8eb0e5c3cb186c91e3740d and

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

Fortran 2008 DATA statement restrictions

Hi, I was looking at our table for Fortran 2008 conformance (https://gcc.gnu.org/wiki/Fortran2008Status) and we really have only a few items missing. One in particular is: "Data statement restrictions lifted”. Quoting the document: > Subscripts and nested implied-do limits in a data statement

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

Hi Thomas, > The KIND=17 is a bit of a kludge. It is not visible for > user programs, they use KIND=16, but this is then translated > to library calls as if it was KIND=17 if the IEEE 128-bit floats > are selected Can you check what the IEEE test results are when -mabi=ieeelongdouble is enabled

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

Hi Harald, > I just looked at that thread. I guess if you answer Mikael's > questions at > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601744.html > the patch will be fine. Amended patch, adding the required testing of signalling vs. quiet behaviour. I still need to get an OK on th

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

> Having a POWER system isn't enough, it also needs the IBM "advance > toolchain", and (at least with current distros, which default to > ibm long double), you need to dance counterclockwise three > times... I mean you need to invoke configure with some special magic Thanks for the frank descripti

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

Hi Steve, I am not subscribed to the list (too little time, sadly), please keep me in CC of your responses. > 1. You added fmin, fmax, and friends. Are these used >internally by gfortran in support of the IEEE_* >functions or are these exposed to the user? The math builtins are added

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

Hi, This is a repost of the patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html which never really got green light, but I stopped pushing because stage 1 was closing and I was out of time. It depends on a middle-end patch adding a type-generic __builtin_iseqsig(), whi

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

Hi, > I cannot see if there is proper support for kind=17 in your patch; > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not > seem to have any related code. Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong happened, because the IEEE modules have no kind=17