Re: [Patch, fortran] PR87477 - (associate) - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
Sure, but his comment was about the case gfc_replace_expr is *not* executed.
I should perhaps have remarked that, following the divide error,
gfc_simplify_expr was returning a mutilated version of the expression
and this was somehow connected with successfully simplifying the
parentheses. Copying and replacing on no errors deals with the
problem.
Is the expression mutilated enough that it can't be safely freed?
Re: [Patch, fortran] PR87477 - (associate) - [meta-bug] [F03] issues concerning the ASSOCIATE statement
On 6/8/23 09:46, Mikael Morin wrote:
Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
Sure, but his comment was about the case gfc_replace_expr is *not*
executed.
Right. The following legal code exhibits the leak, pointing
to the gfc_copy_expr:
subroutine paul (n)
integer :: n
character(n) :: c
end
I should perhaps have remarked that, following the divide error,
gfc_simplify_expr was returning a mutilated version of the expression
and this was somehow connected with successfully simplifying the
parentheses. Copying and replacing on no errors deals with the
problem.
Is the expression mutilated enough that it can't be safely freed?
Re: [Patch, fortran] PR87477 - (associate) - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Thanks Gents!
The solution is to gfc_free_expr (p) if the replacement is not made.
I am regtesting a patch for PR107900. I'll include the fix for the
memory leak in the patch for that.
Cheers
Paul
On Thu, 8 Jun 2023 at 09:30, Harald Anlauf wrote:
>
> On 6/8/23 09:46, Mikael Morin wrote:
> > Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
> >> Hi Harald,
> >>
> >> In answer to your question:
> >> void
> >> gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
> >> {
> >>free_expr0 (dest);
> >>*dest = *src;
> >>free (src);
> >> }
> >> So it does indeed do the job.
> >>
> > Sure, but his comment was about the case gfc_replace_expr is *not*
> > executed.
>
> Right. The following legal code exhibits the leak, pointing
> to the gfc_copy_expr:
>
> subroutine paul (n)
>integer :: n
>character(n) :: c
> end
>
> >> I should perhaps have remarked that, following the divide error,
> >> gfc_simplify_expr was returning a mutilated version of the expression
> >> and this was somehow connected with successfully simplifying the
> >> parentheses. Copying and replacing on no errors deals with the
> >> problem.
> >>
> > Is the expression mutilated enough that it can't be safely freed?
> >
> >
> >
>
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
Hi together, On 6/6/23 21:11, FX Coudert via Gcc-patches wrote: 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 I was hoping for Thomas to come forward with some comment, as he was quite involved in related work. There are several threads on IEEE128 for Power on the fortran ML e.g. around November/December 2021, January 2022. I wasn't meaning to block your work, just wondering if the Power platform needs more attention here. % cd gcc/gccx/libgfortran % grep HAVE_GFC_REAL_17 ieee/* % troutmask:sgk[219] ls ieee % ieee_arithmetic.F90 ieee_features.F90 % ieee_exceptions.F90 ieee_helper.c There are zero hits for REAL(17) in the IEEE code. If REAL(17) is intended to be an IEEE-754 type, then it seems gfortran's support was never added for it. If anyone has access to a power system, it's easy to test program foo use ieee_arithmetic print *, ieee_support_datatype(1.e_17) end program foo 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: $ cat ml.f90 subroutine mm(a) real(kind=16), dimension(:,:) :: a print *,maxloc(a) end subroutine mm $ gfortran -S -mabi=ieeelongdouble ml.f90 && grep maxloc ml.s bl _gfortran_maxloc0_4_r17 $ gfortran -S ml.f90 && grep maxloc ml.s bl _gfortran_maxloc0_4_r16 On POWER, if IBM long double exists, it is GFC_REAL_16, with GFC_REAL_17 being IEEE long double. Everywhere else, GFC_REAL_16 is IEEE long double. If POWER gets the flag -mabi=ieeelongdouble, it uses IEEE long doubles. If it gets the additionalflag -mcpu=power9 or -mcpu=power10, it uses the hardware instructions for the arithmetic instead of library calls. 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 like configure \ --prefix=$HOME \ --enable-languages=c,c++,fortran \ --disable-plugin \ --enable-checking \ --enable-stage1-checking \ --enable-gnu-indirect-function \ --disable-maintainer-mode \ --disable-libgomp \ --enable-decimal-float \ --enable-secureplt \ --enable-threads=posix \ --enable-__cxa_atexit \ --with-cpu=power9 \ --with-long-double-128 \ --with-as=/opt/at15.0/bin/as \ --with-ld=/opt/at15.0/bin/ld \ --with-gnu-as=/opt/at15.0/bin/as \ --with-gnu-ld=/opt/at15.0/bin/ld \ --with-advance-toolchain=at15.0 \ --with-native-system-header-dir=/opt/at15.0/include \ --without-ppl \ --without-cloog \ --without-isl which Michael Meissner helped me with, I would never have figured it out on my own. There is a virutal POWER machine at OSUL dedicated to the IEEE QP gfortran effort. It hasn't been used for some time, but it's still active. I just bootstrapped trunk there and ran all the IEEE from the testsuite manually, with $ for a in *.f90; do echo "Testing $a"; gfortran -o $a.exe -fno-range-check -mcpu=power9 -mabi=ieeelongdouble -static-libgfortran $a signaling_1_c.c signaling_2_c.c ; ./$a.exe ; done 2>&1 | grep -v command-line Testing fma_1.f90 2. 1.5000 2. 1.5000 2.000 1.500 2. 1.5000 Testing ieee_10.f90 Testing ieee_12.f90 Testing ieee_2.f90 Testing ieee_3.f90 Testing ieee_4.f90 Testing ieee_5.f90 Testing ieee_6.f90 Testing ieee_7.f90 Testing ieee_8.f90 Testing ieee_9.f90 Testing intrinsics_1.f90 Testing large_1.f90 Testing large_2.f90 Testing large_4.f90 Testing modes_1.f90 Testing pr77372.f90 Testing pr77507.f90 -Infinity F Testing rounding_1.f90 Testing rounding_2.f90 Testing rounding_3.f90 Testing signaling_1.f90 Testing signaling_2.f90 Testing signaling_3.f90 Testing signbit_1.f90 Testing underflow_1.f90 so that seems to be OK. However, the fact that there is no mention of GFC_REAL_17 in there makes me a bit suspicious, Michael, maybe you can comment if all is indeed well there, and if the right things are being tested? 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. Best regards Thomas
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 Fortran 2018 IEEE_{MIN,MAX} functions
Hi FX, 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. Well, I can tell you why I helped in this: I like non-standard architectures, I like 128-bit floats, and I like fast execution speed of programs. And if POWER having this goes any way towards pushing Intel, AMD, or ARM towards having 128-bit floating point... well, I would like that a lot. And the need for all this magic will go away once distributions switch to IEEE QP float as default. By the way, if anybody wants to play with it, there should be no problem in getting an account on the the OSL (virtual) machine I ran this on. As for the speed difference: A simple matrix multiplication has around 50 MFlops on my home box and around 250 MFlops on the POWER9 box I am testing this on. POWER10 should double that. Best regards Thomas
Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons
Hi FX, Am 06.06.23 um 21:29 schrieb FX Coudert via Gcc-patches: 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. 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. 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 Thanks, Harald
Re: Possible funding of gfortran work
Hello, Le 06/06/2023 à 15:06, Andre Vehreschild a écrit : Hi Mikael, ... Yes, I don't like it but I understand the need for estimating. I have looked at the evaluation criteria at [1]. There is among other things: Furthermore, we look at how well the planning for the project is laid out. Are the activities well-structured, appropriate and feasible? I think we are far from having a "well laid out planning". Even if it's difficult to estimate the amount of days of work, we should probably at least try to decompose the project into milestones, that is (small) steps proving progress toward the target. I understand. I would have been happy in the past when a client had as much knowledge and structure than we already have. Under "Project goal" we now have about 300 words. So we could add more. Well, It wouldn't be really part of the goal, more how to reach that goal. The "timeframe" question is possibly where it should go. Or if you consider that the planning is a goal itself, it could be put here. What do you have in mind? Something that breaks a big, risky thing to a set of smaller, manageable ones. Something showing that the main problems (or some of them at least) have been identified and that we have a path to solve them one by one. Like adding more bullet points to each item in the form of: - rebase existing implementation to current master - identify missing requirements - add tests for missing requirements - implement missing requirements to pass tests. ... Well, this is a bit too general to be useful. Or are your targeting a more time based approach like: Milestone 1: shared mem coarrays merge to master in week 2 of project Milestone 2: finish research on general way for doing remote coarray access in alien structures to finish in week 1 of project ... Maybe, but I would not emphasize the time constraints that much. I have done it below for the scalarizer simplification, which is what for which the picture is the most clear in my mind regarding what to do and how to do it. Here it is, with the expected number of weeks (that's 3 days for me) to do it: - Add optional scalarization block. (1 week) - Setup multiple expression usage (in case of multiple loops) in a more clear way. (3 weeks) - Move array and loop bounds setup to an opaque "start scalarization" function (3 weeks) - Make scalarization independant on previous setup of array information and move setup code from "start scalarization" to "finish scalarization" (5 weeks) - Initialize array information inside the gfc_conv_expr* functions and remove preliminary walking of expressions (4 weeks) I hope that's not too technical to be put in the application form. Take the above as examples please, not as proposals. In the meantime I have added something to the "Who section": ... Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced in gfortran development and component dependencies. I'm not affiliated to any company, university or organization. Just myself. :-)
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
> Hi together,
>
> > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > > > 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
> > >
> > > I was hoping for Thomas to come forward with some comment, as
> > > he was quite involved in related work.
> > >
> > > There are several threads on IEEE128 for Power on the fortran ML
> > > e.g. around November/December 2021, January 2022.
> > >
> > > I wasn't meaning to block your work, just wondering if the Power
> > > platform needs more attention here.
> > >
> >
> > % cd gcc/gccx/libgfortran
> > % grep HAVE_GFC_REAL_17 ieee/*
> > % troutmask:sgk[219] ls ieee
> > % ieee_arithmetic.F90 ieee_features.F90
> > % ieee_exceptions.F90 ieee_helper.c
> >
> > There are zero hits for REAL(17) in the IEEE code. If REAL(17)
> > is intended to be an IEEE-754 type, then it seems gfortran's
> > support was never added for it. If anyone has access to a
> > power system, it's easy to test
> >
> > program foo
> > use ieee_arithmetic
> > print *, ieee_support_datatype(1.e_17)
> > end program foo
>
> 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:
>
> $ cat ml.f90
> subroutine mm(a)
> real(kind=16), dimension(:,:) :: a
> print *,maxloc(a)
> end subroutine mm
> $ gfortran -S -mabi=ieeelongdouble ml.f90 && grep maxloc ml.s
> bl _gfortran_maxloc0_4_r17
> $ gfortran -S ml.f90 && grep maxloc ml.s
> bl _gfortran_maxloc0_4_r16
>
> On POWER, if IBM long double exists, it is GFC_REAL_16, with GFC_REAL_17
> being IEEE long double. Everywhere else, GFC_REAL_16 is IEEE long
> double.
>
> If POWER gets the flag -mabi=ieeelongdouble, it uses IEEE long doubles.
>
> If it gets the additionalflag -mcpu=power9 or -mcpu=power10, it uses
> the hardware instructions for the arithmetic instead of library calls.
>
(trimming for length)
Thanks for the explanation. As I likely will not use a POWER-based
system, I only loosely followed the discussion. I don't remember
if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is
REAL(16), then everything should (I believe) be okay.
> There is a virutal POWER machine at OSUL dedicated to the IEEE QP
> gfortran effort. It hasn't been used for some time, but it's still
> active. I just bootstrapped trunk there and ran all the IEEE from the
> testsuite manually, with
>
> $ for a in *.f90; do echo "Testing $a"; gfortran -o $a.exe -fno-range-check
> -mcpu=power9 -mabi=ieeelongdouble -static-libgfortran $a signaling_1_c.c
> signaling_2_c.c ; ./$a.exe ; done 2>&1 | grep -v command-line
> Testing fma_1.f90
These could be misleading. gfortran has pre-processor tokens
for REAL(10) and REAL(16). If __GFC_REAL_16__ isn't defined
the ieee testing is skipped.
% cd gcc/gccx/gcc/fortran/
% grep __GFC_REAL_ *
cpp.cc: cpp_define (cpp_in, "__GFC_REAL_10__=1");
cpp.cc: cpp_define (cpp_in, "__GFC_REAL_16__=1");
invoke.texi:@code{__GFC_REAL_10__}, and @code{__GFC_REAL_16__}.
% more cpp.cc
...
/* Pre-defined macros for non-required REAL kind types. */
for (gfc_real_info *rtype = gfc_real_kinds; rtype->kind != 0; rtype++)
{
if (rtype->kind == 10)
cpp_define (cpp_in, "__GFC_REAL_10__=1");
if (rtype->kind == 16)
cpp_define (cpp_in, "__GFC_REAL_16__=1");
}
...
Should we have a __GFC_REAL_17__?
% cd ../testsuite/gfortran.dg/
% grep __GFC_REAL ieee/*
ieee/dec_math_1.f90: ! Note however that if both __GFC_REAL_10__ and
__GFC_REAL_16__ are defined,
ieee/dec_math_1.f90:#if defined(__GFC_REAL_10__)
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__)
ieee/dec_math_1.f90:#ifdef __GFC_REAL_10__
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__)
ieee/dec_math_1.f90:#ifdef __GFC_REAL_16__
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_10__)
ieee/ieee_11.F90:#ifdef __GFC_REAL_10__
ieee/ieee_11.F90:#ifdef __GFC_REAL_16__
--
Steve
Re: [PATCH v6 0/4] P1689R5 support
> On Jun 7, 2023, at 00:50, Ben Boeckel via Gcc-patches > wrote: > > Hi, > > This patch series adds initial support for ISO C++'s [P1689R5][], a > format for describing C++ module requirements and provisions based on > the source code. This is required because compiling C++ with modules is > not embarrassingly parallel and need to be ordered to ensure that > `import some_module;` can be satisfied in time by making sure that any > TU with `export import some_module;` is compiled first. Hi Ben, This patch series causes ICEs on arm-linux-gnueabihf. Would you please investigate? Please let me know if you need any in reproducing these. === g++ tests === Running g++:g++.dg/modules/modules.exp ... FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/ben-1_a.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_a.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/ben-1_a.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_a.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/ben-1_a.C module-cmi =partitions/module-import.mod (partitions/module-import.mod) FAIL: g++.dg/modules/ben-1_b.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/ben-1_b.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/ben-1_b.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/ben-1_b.C module-cmi =module.mod (module.mod) FAIL: g++.dg/modules/gc-2_a.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/gc-2_a.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/gc-2_a.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/gc-2_a.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/gc-2_a.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/gc-2_a.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/gc-2_a.C module-cmi =map-1_a.nms (map-1_a.nms) UNRESOLVED: g++.dg/modules/map-1 -std=c++17 execute UNRESOLVED: g++.dg/modules/map-1 -std=c++17 link UNRESOLVED: g++.dg/modules/map-1 -std=c++2a execute UNRESOLVED: g++.dg/modules/map-1 -std=c++2a link UNRESOLVED: g++.dg/modules/map-1 -std=c++2b execute UNRESOLVED: g++.dg/modules/map-1 -std=c++2b link FAIL: g++.dg/modules/map-1_a.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_a.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/map-1_a.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_a.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/map-1_a.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_a.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/map-1_a.C module-cmi =map-1_a.nms (map-1_a.nms) FAIL: g++.dg/modules/map-1_b.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/map-1_b.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/map-1_b.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/map-2.C -std=c++17 at line 8 (test for errors, line 7) FAIL: g++.dg/modules/map-2.C -std=c++17 at line 9 (test for errors, line ) FAIL: g++.dg/modules/map-2.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-2.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/map-2.C -std=c++2a at line 8 (test for errors, line 7) FAIL: g++.dg/modules/map-2.C -std=c++2a at line 9 (test for errors, line ) FAIL: g++.dg/modules/map-2.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-2.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/map-2.C -std=c++2b at line 8 (test for errors, line 7) FAIL: g++.dg/modules/map-2.C -std=c++2b at line 9 (test for errors, line ) FAIL: g++.dg/modules/map-2.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-2.C -std=c++2b (test for excess errors) === Thanks, -- Maxim Kuvyrkov https://www.linaro.org > > [P1689R5]: https://isocpp.org/files/papers/P1689R5.html > > I've also added patches to include imported module CMI files and the > module mapper file as dependencies of the compilation. I briefly looked > into adding dependencies on response files as well, but that appeared to > need some code contortions to have a `class mkdeps` available before > parsing the comma
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
Hi Steve, On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote: [...] Thanks for the explanation. As I likely will not use a POWER-based system, I only loosely followed the discussion. I don't remember if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is REAL(16), then everything should (I believe) be okay. From a user standpoint, REAL(16) is always used. We only use the 17 as a marker in the library, and to be able to have library versions of IBM long double co-reside with IEEE long double. There is a virutal POWER machine at OSUL dedicated to the IEEE QP gfortran effort. It hasn't been used for some time, but it's still active. I just bootstrapped trunk there and ran all the IEEE from the testsuite manually, with $ for a in *.f90; do echo "Testing $a"; gfortran -o $a.exe -fno-range-check -mcpu=power9 -mabi=ieeelongdouble -static-libgfortran $a signaling_1_c.c signaling_2_c.c ; ./$a.exe ; done 2>&1 | grep -v command-line Testing fma_1.f90 These could be misleading. gfortran has pre-processor tokens for REAL(10) and REAL(16). If __GFC_REAL_16__ isn't defined the ieee testing is skipped. Hmm... need to check. With the recently-built compiler: $ cat tst.F90 program memain #if __GFC_REAL_16__ print *,"__GFC_REAL_16 found" #endif #if __GFC_REAL_17__ print *,"__GFC_REAL_17 found" #endif print *,"digits is ",digits(1._16) end program memain $ gfortran -static-libgfortran tst.F90 && ./a.out __GFC_REAL_16 found digits is 106 $ gfortran -static-libgfortran -mabi=ieeelongdouble -mcpu=power9 tst.F90 && ./a.out __GFC_REAL_16 found digits is 113 Looks clean. [...] Should we have a __GFC_REAL_17__? I don't think we need it - REAL(KIND=17) is not supported in the compiler (we discussed and rejected that), and people who mix IBM long double and IEEE long double will have no joy with their programs; they need to recompile everything. But we may have to do something about the files in the thelibgfortran/ieee subdirectory. Best regards Thomas
Orphaned patches
If anyone is so inclined, the patches in the following PR's can be committed and the PR closed. These are patches for gfortran. 69101 91960 95613 99139 99368 99798 100607 103795 103796 104626 105594 101967 101951 104649 106050 106500 107266 107406 107596 This is an opportunity for lurkers in the fortran@ list to grab a patch, apply to the tree, ask questions, and then take the plunge to being someone who can help care for gfortran. -- Steve
