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 mention in them anywhere. Actually, where is the kind=17 documented? FX
[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(), 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
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 to the front-end, and use for code generation. In conv_intrinsic_ieee_minmax(), you can see we find the right function using things like: builtin_decl_explicit (BUILT_IN_ISSIGNALING) Those built-ins are not exposed to the user: we don’t need any more GNU-specific intrinsics, methinks. > 2. I did not see error handling or conversion, but on a >quick scan I may have missed it. What happens with >IEEE_MAX_NUM(2.0_4, 3.0_8) or IEEE_MAX_NUM(2.0_4, INT(3))? >17.11.17 has > >X shall be of type real. >Y shall be of the same type and kind type 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
> 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 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
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 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
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? It’s not even clear to me what the IEEE kinds selected should be, in this case, depending on -mabi=ieeelongdouble > Regarding FX's patch: I am not quite sure that I am > actually testing the right thing if running the testsuite > there, so POWER should not hold up this patch. If it turns > out that POWER needs additonal work on IEEE, we can always > add that later. Actually, it sounds like the situation is: the same target can have two ABIs based on a compile-time flag. That sounds like a job for multilib, i.e., we should compile libgfortran twice, 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
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 can be any > constant expression instead of being limited to combinations of constants, > implied-do variables, and intrinsic operations. Unless I misunderstand this quote, I think we have that already. Maybe we always had that? I have run the attached test program, which uses non-trivial constant expressions, and it passes fine. So I plan to add that to our testsuite, and change the wiki. But I would like someone else to confirm: do you understand this the same way I do? Do you have ideas of other ways to test it, tricky expressions, etc? Are there other ways that "Subscripts and nested implied-do limits” may appear in a DATA statement? Thanks, FX data.f90 Description: Binary data
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
Re: libgfortran: remove support for --enable-intermodule
> OK, thanks. Committed at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ecc96eb5d2a0e5dd93365ef76a58d7f754273934
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 0c2d6aa1be2ea85e751852834986ae52d58134d3 all IEEE functions manipulating real or complex arguments are actually expanded fully inline (we retain functions in libgfortran for backward compatibility). The only IEEE functions that depend on libgfortran runtime are the “IEEE_SUPPORT_*” functions. FX
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=a54c71ccc24874ce79019b51150b3a00b7c785cd Best, FX
