Re: Fortran: Use non conflicting file extensions for intermediates [PR81615]
Replying to myself... I think this also desevers a mention in changes.html. Here is something that I came up with. OK? Or does anybody have suggestions for a better wording? Or maybe this is better: diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 4b83037a..d232f631 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -282,8 +282,14 @@ a work-in-progress. - - +Fortran + + With the -save-temps option, preprocessed files +with the .fii extension will be generated for +free-form source files such as .F90 and +.fi for fixed-form files such as .F. + +
Re: Fortran: Use non conflicting file extensions for intermediates [PR81615]
Hi Rimvydas, Documentation part. The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings. Thanks for your work on this! I think this also desevers a mention in changes.html. Here is something that I came up with. OK? Or does anybody have suggestions for a better wording? diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 4b83037a..b3b67dda 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -282,8 +282,13 @@ a work-in-progress. - - +Fortran + + With the -save-temps option, .fii and +.fi files are now generated from .F90 +and .F files, respectively. + +
Re: [PATCH v4] libgfortran: Replace mutex with rwlock
Hi Lipeng, Sure, as your comments, in the patch V6, I added 3 test cases with OpenMP to test different cases in concurrency respectively: 1. find and create unit very frequently to stress read lock and write lock. 2. only access the unit which exist in cache to stress read lock. 3. access the same unit in concurrency. For the third test case, it also help to find a bug: When unit can't be found in cache nor unit list in read phase, then threads will try to acquire write lock to insert the same unit, this will cause duplicate key error. To fix this bug, I get the unit from unit list once again before insert in write lock. More details you can refer the patch v6. Could you help to review this update? I really appreciate your assistance. Could you help to review this update? Any concern will be appreciated. Fortran parts are OK (I think I wrote that already), we need somebody for the non-Fortran parts. Jakub, could you maybe take a look? Best regards Thomas
Re: [PATCH] Introduce hardbool attribute for C
Hi Alexandre, On Apr 6, 2023, Bernhard Reutner-Fischer wrote: 29 For C_BOOL, the internal representation of .TRUE._C_BOOL and .FALSE._C_BOOL shall be the same as those of 30 the C values (_Bool)1 and (_Bool)0 respectively. I'm not changing any of the standard types, FWIW. The proposed extension enables alternate boolean types to be introduced, with extra checking for hardening. I personally like your proposed 0 and ~0, that's probably pretty robust. That is only a default. Certain applications may benefit from other values. 0xa5 and 0x5a seem to make a good combination too. In gfortran, we depend on the representation of 0/1 for several things (among them avoiding having separate library versions for logical kind=1,2,4,8,16 for MASK). So, such a type would be incompatible with vanilla LOGICAL variables and with C interop logical variables. If anybody should pass such a hardbool variable to Fortran, they will get unpredictable results, and deserve to lose. The opposite effect of what would be intended :-) Best regards Thomas
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
Hi FX, >> 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? Running nohup make -j7 check-fortran RUNTESTFLAGS="--target_board=unix/-mabi=ieeelongdouble/-mcpu=power9"& from the gcc subdirectory yielded only a single failure: grep ^FAIL nohup.out FAIL: gfortran.dg/gomp/target-update-1.f90 -O scan-tree-dump gimple "#pragma omp target update to\\(c \\[len: [0-9]+\\]\\) to\\(present:a \\[len: [0-9]+\\]\\) to\\(e \\[len: [0-9]+\\]\\) from\\(present:b \\[len: [0-9]+\\]\\) from\\(d \\[len: [0-9]+\\]\\) and also ran the correct tests, as seen from gfortran.log; for example: Executing on host: gfortran /home/tkoenig/gcc/gcc/testsuite/gfortran.dg/ieee/large_2.f90 -mabi=ieeelongdouble -mcpu=power9 -fdiagnostics-plain-output -fdiagnostics-plain-output-O0 -pedantic-errors -fintrinsic-modules-path /home/tkoenig/gcc-bin/powerpc64le-unknown-linux-gnu/./libgfortran/ -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans-lm -o ./large_2.exe(timeout = 300) spawn -ignore SIGHUP gfortran /home/tkoenig/gcc/gcc/testsuite/gfortran.dg/ieee/large_2.f90 -mabi=ieeelongdouble -mcpu=power9 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0 -pedantic-errors -fintrinsic-modules-path /home/tkoenig/gcc-bin/powerpc64le-unknown-linux-gnu/./libgfortran/ -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans -lm -o ./large_2.exe^M PASS: gfortran.dg/ieee/large_2.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/tkoenig/lib/../lib64:.:/home/tkoenig/lib/../lib64 Execution timeout is: 300 spawn [open ...]^M PASS: gfortran.dg/ieee/large_2.f90 -O0 execution test This is a test that fails on POWER with the IBM long double format, so things look ok. It also works when compiled individually. So, this is looking good. By the way, if you or any other gfortran maintainer would like an account on the POWER virtual machine in question, that would be no problem. I would ask the cluster administrators for permission and then create the account (I have admin privileges on that virtual machine). > It’s not even clear to me what the IEEE kinds selected should be, in this case, depending on -mabi=ieeelongdouble The "KIND=17" stuff should only be visible inside the library. > >> 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? I don't remember discussing multilib in this context, sorry. Best regards Thomas
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
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 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] PR37336 finalization
Hi Paul, I want to get something approaching correct finalization to the distros, which implies 12-branch at present. Hopefully I can do the same with associate in a month or two's time. OK by me then. (I just wanted to be sure that we had this discussion :-) Best regards Thomas
Re: [Patch, fortran] PR37336 finalization
Hi Paul, I propose to backport r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very soon. Is this something that we usually do? While finalization was basically broken before, some people still used working subsets (or subsets that were broken, and they adapted or wrote their code accordingly). What is the general opinion on that? I'm undecided. Before that, I propose to remove the F2003/2008 finalization of structure and array constructors in 13- and 14-branches. I can see why it was removed from the standard in a correction to F2008 and think that it is likely to cause endless confusion and maintenance complications. However, finalization of function results within constructors will be retained. That, I agree with. Should it be noted somewhere as an intentional deviation from the standard? Best regards Thomas
Re: [PATCH v4] libgfortran: Replace mutex with rwlock
Hi Lipeng, May I know any comment or concern on this patch, thanks for your time Thanks for your patience in getting this reviewed. A few remarks / questions. Which strategy is used in this implementation, read-preferring or write-preferring? And if read-preferring is used, is there a danger of deadlock if people do unreasonable things? Maybe you could explain that, also in a comment in the code. Can you add some sort of torture test case(s) which does a lot of opening/closing/reading/writing, possibly with asynchronous I/O and/or pthreads, to catch possible problems? If there is a system dependency or some race condition, chances are that regression testers will catch this. With this, the libgfortran parts are OK, unless somebody else has more comments, so give this a couple of days. I cannot approve the libgcc parts, that would be somebody else (Jakub?) Best regards Thomas
Re: [PATCH v2] Fortran: Narrow return types [PR78798]
On 14.05.23 14:27, Mikael Morin wrote:
(...)
@@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref,
gfc_ref *ref)
there is some kind of overlap.
0 : array references are identical or not overlapping. */
-int
+bool
gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse,
bool identical)
{
The function comment states that the function may return 2, which
doesn't seem to be the case any more.
Hm, this makes me a litte suspicious. Was functionality for reversing
loops lost, maybe unintentionally? I assume that, at some time, we did
use the '2' as return value (or did we?)
Best regards
Thomas
Re: [PATCH v2 4/7] fortran: use grep instead of fgrep
On 10.05.23 21:29, Bernhard Reutner-Fischer via Fortran wrote: On Mon, 27 Jun 2022 14:10:36 +0800 Xi Ruoyao wrote: fgrep has been deprecated in favor of grep -F for a long time, and the next grep release (3.8 or 4.0) will print a warning of fgrep is used. Stop using fgrep so we won't see the warning. We can't hard code grep -F here or it may break build on hosts w/o GNU grep. autoconf documentation contains a warning about this issue and suggest to use AC_PROG_FGREP and $FGREP, but these are too overkill in the specific case: there is no way "debian" could be interpreted as an non-trivial regex, so we can use a plain grep here. LGTM but i cannot approve it. I'd say this one is trivial and obvious so you could sneak it in under the "obvious" rule.. I concur, this could also have been obvious. Anyway, OK for trunk, and Thanks for the patch!
Re: [PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.
Hi Steve,
Hi Andrew,
"long long". This was just an oversight and a missing check.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
Thanks!
I think this one is obvious enough that it deserves a backport.
I've cherry-picked this for gcc12, will do gcc11 tomorrow.
The patch is incomplete.
module foo
use, intrinsic :: iso_c_binding
implicit none
public :: bar
type, bind(c) :: bar
real(10) a
end type
end module
This yields
typedef struct bar {
long_double a /* WARNING: Converting 'REAL(10)' to interoperable type */;
} bar;
That should be 'long double'.
Fixed as obvious in 69044e11ac5 .
I will backport soon.
Thanks for the heads-up!
Best regards
Thomas
Re: [PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.
Hi Andrew, "long long". This was just an oversight and a missing check. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. Thanks! I think this one is obvious enough that it deserves a backport. I've cherry-picked this for gcc12, will do gcc11 tomorrow. Best regards Thomas
Re: [PATCH, commited] Fortran: remove dead code [PR104321]
On 26.03.23 08:52, Paul Richard Thomas via Fortran wrote: If you will excuse the British cultural reference, that's a Norwegian Blue alright! Good spot. Still pining for the fjords, I gather?
Re: [patch, fortran, doc] Explicitly mention undefined overflow
I wrote: Yes, that's fine for trunk. I wonder if it is worth being explicit that linear congruential pseudo-random number generators can and do fail at -O3? I don't think we should put this into the docs, because that can change at any time. Maybe into porting_to.html, though (where I have only mentioned this as a general issue with linear congruential generators, without mentioning specific options. Current text can be seen at https://gcc.gnu.org/gcc-13/porting_to.html ). Hm Breaking things actually goes back further than I thought. Taking the random number generator from rnseed and running it 10 times with my system gfortran 9.4.0 gets me, at different levels of optimization: $ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done -O0 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O1 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O2 -0.730588138 0.891386986 -0.555957019 -0.220789105 -0.499941051 0.666437685 -0.333036542 0.462416053 0.376364112 2.90278494E-02 and for current trunk it is $ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done -O0 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O1 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O2 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 so it the general problem is not restricted to -O3 and not to current trunk, it depends on the details. I doubt that the result from 9.4.0 was expected, but rather nobody noticed. Or, bringing out the pseudo-RNG into a different setting changed things. So... any suggestions on how to improve the current wording? Best regards Thomas
Re: [patch, fortran, doc] Explicitly mention undefined overflow
Hi Paul, Yes, that's fine for trunk. I wonder if it is worth being explicit that linear congruential pseudo-random number generators can and do fail at -O3? I don't think we should put this into the docs, because that can change at any time. Maybe into porting_to.html, though (where I have only mentioned this as a general issue with linear congruential generators, without mentioning specific options. Current text can be seen at https://gcc.gnu.org/gcc-13/porting_to.html ). Hm Best regards Thomas
[patch, fortran, doc] Explicitly mention undefined overflow
Here's also an update on the docs to explicitly mention behavior
on overflow.
Maybe this will reach another 0.05% of users...
OK for trunk?
Best regards
Thomas
gcc/fortran/ChangeLog:
* gfortran.texi: Mention behavior on overflow.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index c483e13686d..93c66b18938 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -820,6 +820,7 @@ might in some way or another become visible to the programmer.
* File operations on symbolic links::
* File format of unformatted sequential files::
* Asynchronous I/O::
+* Behavior on integer overflow::o
@end menu
@@ -1160,6 +1161,23 @@ sytems, such as Linux, it is necessary to specify @option{-pthread},
@c Maybe this chapter should be merged with the 'Standards' section,
@c whenever that is written :-)
+@node Behavior on integer overflow
+@section Behavior on integer overflow
+@cindex integer overflow
+@cindex overflow handling
+
+Integer overflow is prohibited by the Fortran standard. The behavior
+of gfortran on integer overflow is undefined by default. Traditional
+code, like linear congruential pseudo-random number generators in old
+programs that rely on specific, non-standard behavior may generate
+unexpected results. The @option{-fsanitize=undefined} option can be
+used to detect such code at runtime.
+
+It is recommended to use the intrinsic subroutine @code{RANDOM_NUMBER}
+for random number generators or, if the old behavior is desired, to
+use the @option{-fwrapv} option. Note that this option can impact
+performance.
+
@node Extensions
@chapter Extensions
@cindex extensions
[patch, wwwdocs] Mention finalization
Hi, the sentence below seems a bit short for such a huge undertaking, but I could not think of anything else to day. Tested with "tidy -e". OK for wwwdocs? Best regards Thomas diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index c8d757b6..a4b71ffa 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -373,7 +373,12 @@ a work-in-progress. - +Fortran + + +Finalization is now fully supported. + +
Re: [PATCH] Fortran: procedures with BIND(C) attribute require explicit interface [PR85877]
Hi Harald,
Am 18.03.23 um 19:52 schrieb Thomas Koenig via Gcc-patches:
Hi Harald,
the Fortran standard requires an explicit procedure interface in certain
situations, such as when they have a BIND(C) attribute (F2018:15.4.2.2).
The attached patch adds a check for this.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
While this fixes the ICE, it misses
function f() bind(c)
f = 42.
end
subroutine p
bind(c) f ! { dg-error "must be explicit" }
x = f()
end
what do you mean by "it misses"?
Sorry, that was caused by confusion on my part (and it is better
to test an assumption of what the compiler actually does :-)
Patch is OK, also for backport. Maybe you can also include the
test above, just to make sure.
Best regards
Thomas
Re: [PATCH] Fortran: procedures with BIND(C) attribute require explicit interface [PR85877]
Hi Harald,
the Fortran standard requires an explicit procedure interface in certain
situations, such as when they have a BIND(C) attribute (F2018:15.4.2.2).
The attached patch adds a check for this.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
While this fixes the ICE, it misses
function f() bind(c)
f = 42.
end
subroutine p
bind(c) f ! { dg-error "must be explicit" }
x = f()
end
subroutine s
interface
function g() bind(c)
end function g
end interface
x = g()
end
where the interface is picked up via a global symbol. This code
may not be valid; nagfor rejects it, but I cannot find a
constraint at least in the F2022 draft that prohibits it.
Hm... might it be better to check for attr->module_procedure ||
attr->if_source == IFSRC_IFBODY?
Best regards
Thomas
[patch, wwwdocs] Mention random number generators in porting_to.html
Hi, Text says it all. OK for web pages? Best regards Thomas Mention issues with integer owerflow for random number generators. This mentions the issues with integer overflow and how to work around them. diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html index 0ee58802..7d733b16 100644 --- a/htdocs/gcc-13/porting_to.html +++ b/htdocs/gcc-13/porting_to.html @@ -203,11 +203,20 @@ class Alloc Since C++20, there is no rebind member in std::allocator, so deriving your own allocator types from -std::allocator is simpler and doesn't require the derived +std::allocator is simpler and does not require the derived allocator to provide its own rebind. For compatibility with previous C++ standards, the member should still be provided. The converting constructor is still required even in C++20. +Fortran language issues +Behavior on integer overflow + GCC 13 includes new optimizations which expose reliance on + non-standard behavior for integer overflow, which was often used + for linear congruential pseudo-random number generators in old + programs. It is recommended to use the intrinsic + subroutine RANDOM_NUMBER for random number generators + or, if the old behavior is desired, to use the -fwrapv + option. Note that this option can impact performance.
Re: [patch, Fortran] Enable -fwrapv for -std=legacy
Hi Richard, Since this appeared only in gcc13, I see no need for a backport. I will also document this in the changes file. The „problem“ It's a real problem, I am afraid... is latent forever, I’m not sure it’s good to amend the kitchen-sink >std=legacy option with -fwrapv since that has quite some negative effects on optimization. So, what are the options? Do nothing, and get silent bad results. I do not think we can do this, there is too much code out there. Just look at Numerical Recipes, which has this kind of random number generator. Apply the patch (with spelling fixes). This has the drawback that you outlined, potential impact on optimization. Put a warning in the release notes. This will not help in general because 99.99% of users will not read it. Revert the patch exposing the problem. No. That would pessimize everything. Put the optimization behind a special flag. That also makes no sense, -fwrapv does the job. Would it be possible to add a warning? Anything of the sort a = b + c * a where b and c are larger than (in this case) 16 bits could be flagged. Other options? Best regards Thomas
[patch, Fortran] Enable -fwrapv for -std=legacy
Hello world, here's the patch that was discussed.
Regression-tested. OK for trunk?
Since this appeared only in gcc13, I see no need for a backport.
I will also document this in the changes file.
Best regards
Thomas
Set -frapv if -std=legacy is set.
Fortran legacy codes sometimes contain linear congruential
seudorandom number generators. These generators implicitly depend
on wrapping behavior on integer overflow, which is illegal Fortran,
but the best they could to at the time.
A gcc13 change exposed this in rnflow, part of the Polyhedron
benchmark, with -O3. Rather than "regress" on such code, this patch
enables -fwrapv if -std=legacy is enabled. This allows the benchmark
to run successfully, and presumably lots of other code as well.
gcc/fortran/ChangeLog:
PR fortran/109075
* options.cc (gfc_handle_option): If -std=legacy is set,
also set -frwapv.
* invoke.texi: Document the change.diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 5679e2f2650..4f4950dad41 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -549,15 +549,16 @@ Fortran standard that includes all of the extensions supported by GNU
Fortran, although warnings will be given for obsolete extensions not
recommended for use in new code. The @samp{legacy} value is
equivalent but without the warnings for obsolete extensions, and may
-be useful for old non-standard programs. The @samp{f95},
-@samp{f2003}, @samp{f2008}, and @samp{f2018} values specify strict
-conformance to the Fortran 95, Fortran 2003, Fortran 2008 and Fortran
-2018 standards, respectively; errors are given for all extensions
-beyond the relevant language standard, and warnings are given for the
-Fortran 77 features that are permitted but obsolescent in later
-standards. The deprecated option @samp{-std=f2008ts} acts as an alias for
-@samp{-std=f2018}. It is only present for backwards compatibility with
-earlier gfortran versions and should not be used any more.
+be useful for old non-standard programs. It also sets
+@option{-fwrapv}. The @samp{f95}, @samp{f2003}, @samp{f2008}, and
+@samp{f2018} values specify strict conformance to the Fortran 95,
+Fortran 2003, Fortran 2008 and Fortran 2018 standards, respectively;
+errors are given for all extensions beyond the relevant language
+standard, and warnings are given for the Fortran 77 features that are
+permitted but obsolescent in later standards. The deprecated option
+@samp{-std=f2008ts} acts as an alias for @samp{-std=f2018}. It is only
+present for backwards compatibility with earlier gfortran versions and
+should not be used any more.
@opindex @code{ftest-forall-temp}
@item -ftest-forall-temp
diff --git a/gcc/fortran/options.cc b/gcc/fortran/options.cc
index 27311961325..76166ac69aa 100644
--- a/gcc/fortran/options.cc
+++ b/gcc/fortran/options.cc
@@ -797,6 +797,8 @@ gfc_handle_option (size_t scode, const char *arg, HOST_WIDE_INT value,
case OPT_std_legacy:
set_default_std_flags ();
gfc_option.warn_std = 0;
+ /* -std=legacy implies -fwapv, but the user can override it. */
+ flag_wrapv = 1;
break;
case OPT_fshort_enums:
Re: [Patch, fortran] PR37336 finalization
Paul, first of all, thank you very much indeed for the hard work you put into this! This is a great step for gfortran. I can hurry this along to get the patch into 13-branch or I can wait until 14-branch opens. Personally, I think that this fixes so many bugs, and makes the compiler so much better, that I would prefer having it in gcc-13. Finalization was only of very limited use before, and the risk of meaningful regressions (short of a build failure) is therefore very low. Again, thanks a lot! Best regards Thomas
Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.
Hi Jerry, I should have clarified in my posts that the warnings are on the use of sstride[0], mstride[0] or both. In a sense it is a regression. It showed up when builds started to use -Wmaybe-unitialized. I think this is OK for trunk now, and backport for up to whenever -Wmaybe-uninitialized was introduced into the build. The "regression-only" rule is mostly motivated by not introducing new bugs (and for Fortran, we have a bit of leeway), and I would be hard to pressed to think of a patch less likely to introduce regressions. Thanks for the patch! Best regards Thomas
Re: [PATCH] Fortran: improve checking of character length specification [PR96025]
Hi Harald, the attached patch fixes an ICE on invalid (non-integer) specification expressions for character length in function declarations. It appears that the error handling was already in place (mostly) and we need to essentially prevent run-on errors. Regtested on x86_64-pc-linux-gnu. OK for mainline? As a very minor matter of style, you might want to write function_result_typed = check_function_result_typed (); instead of if (check_function_result_typed ()) function_result_typed = true; OK either way. The PR is marked as a 10/11/12/13 regression, so I would like to backport this as far as it seems reasonable. Also OK. Thanks for the patch! Best regards Thomas
Re: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]
Hi Harald, the code in the PR demonstrates that dependency checking in the frontend optimization was not recovering well from invalid code, leading to a NULL pointer dereference. An easy and really obvious fix. Regtested on x86_64-pc-linux-gnu. OK for mainline? Yes indeed (and I would not have minded if you had indeed committed it as obvious and simple). Thanks for the patch! Best regards Thomas
Re: nvptx, libgfortran: Switch out of "minimal" mode
Hi Thomas, On 2023-01-20T22:04:02+0100, I wrote: We've been (t)asked to enable (portions of) GCC/Fortran I/O for nvptx offloading, which means building a normal (non-'LIBGFOR_MINIMAL') configuration of libgfortran. This is achieved by 'nvptx, libgfortran: Switch out of "minimal" mode', see attached, again based on WIP work by Andrew Stubbs. This I've just pushed to devel/omp/gcc-12 branch in commit c7734c6fbb5513b4da6306de7bc85de9b8547988, and would like to push to master branch once other pending GCC patches have been accepted. Looks good to me. Regards Thomas
Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)
Hi Richard, There is no reliable way to get this correct at the moment and if there were good and easy ways to get this working they'd be implemented already. OK, I then withdraw the patch (and have unassigned myself from the PR). Best regards Thomas
Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)
Hi Richard, Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran : Hi Thomas, Following your off-line explanation that the seemingly empty looking assembly line forces an effective reload from memory, all is now clear. It’s not a full fix (for register vars) and it’s ‚superior‘ to the call itself only because asm handling is implemented in a rather stupid way in the Alias oracle. So I don’t think this is a „fix“ at all. There are no register variables in Fortran, this is Fortran FE only, and it is a fix in the sense that correct code is no longer miscompiled. There's a FIXME in the code pointing to the relevant PR precisely because I think that this is less than elegant (as do you, obviously). Do you have other suggestions how to implement this? If PR 34678 is solved, this would probably provide a mechanism that we could simply re-use. Best regards Thomas
[patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)
Hello world,
this patch fixes Fortran's handling of common subexpression elimination
across ieee_set_rouding_mode calls. It does so using a rather big
hammer, by issuing a memory barrier to force reload from memory
(and thus a recomputation).
This is a rather big hammer, so if there are more elegant ways
to fix it, I am very much open to suggestions.
If PR 34678 is fixed, then this solution can also be applied here.
OK for trunk? How do you feel about a backport?
Best regards
Thomas
Add memory barrier for calls to ieee_set_rounding_mode.
gcc/fortran/ChangeLog:
PR fortran/108329
* trans-expr.cc (trans_memory_barrier): New functions.
(gfc_conv_procedure_call): Insert memory barrier for
ieee_set_rounding_mode.
gcc/testsuite/ChangeLog:
PR fortran/108329
* gfortran.dg/rounding_4.f90: New test.diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 4f3ae82d39c..29be7804e11 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -5981,6 +5981,20 @@ post_call:
gfc_add_block_to_block (>post, );
}
+/* Helper function - generate a memory barrier. */
+
+static tree
+trans_memory_barrier (void)
+{
+ tree tmp;
+
+ tmp = gfc_build_string_const (sizeof ("memory"), "memory");
+ tmp = build5_loc (input_location, ASM_EXPR, void_type_node,
+ gfc_build_string_const (1, ""), NULL_TREE, NULL_TREE,
+ tree_cons (NULL_TREE, tmp, NULL_TREE), NULL_TREE);
+ ASM_VOLATILE_P (tmp) = 1;
+ return tmp;
+}
/* Generate code for a procedure call. Note can return se->post != NULL.
If se->direct_byref is set then se->expr contains the return parameter.
@@ -7692,6 +7706,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
else
conv_base_obj_fcn_val (se, base_object, expr);
+ /* FIXME: Special handing of ieee_set_rounding_mode - we clobber
+ memory here to avoid common subexpression moving code past calls
+ to ieee_set_rounding_mode. This should only be done for
+ floating point, but currently gcc offers no other possibility.
+ See PR 108329. */
+
+ if (sym->from_intmod == INTMOD_IEEE_ARITHMETIC
+ && strcmp (sym->name, "ieee_set_rounding_mode") == 0)
+{
+ tree tmp = trans_memory_barrier ();
+ gfc_add_expr_to_block (, tmp);
+}
+
/* If there are alternate return labels, function type should be
integer. Can't modify the type in place though, since it can be shared
with other functions. For dummy arguments, the typing is done to
diff --git a/gcc/testsuite/gfortran.dg/rounding_4.f90 b/gcc/testsuite/gfortran.dg/rounding_4.f90
new file mode 100644
index 000..e8799da67dc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/rounding_4.f90
@@ -0,0 +1,31 @@
+! { dg-do run }
+module y
+ implicit none
+ integer, parameter :: wp = selected_real_kind(15)
+contains
+ subroutine foo(a,b,c)
+use ieee_arithmetic
+real(kind=wp), dimension(4), intent(out) :: a
+real(kind=wp), intent(in) :: b, c
+type (ieee_round_type), dimension(4), parameter :: mode = &
+ [ieee_nearest, ieee_to_zero, ieee_up, ieee_down]
+call ieee_set_rounding_mode (mode(1))
+a(1) = b + c
+call ieee_set_rounding_mode (mode(2))
+a(2) = b + c
+call ieee_set_rounding_mode (mode(3))
+a(3) = b + c
+call ieee_set_rounding_mode (mode(4))
+a(4) = b + c
+ end subroutine foo
+end module y
+
+program main
+ use y
+ real(kind=wp), dimension(4) :: a
+ call foo(a,0.1_wp,0.2_wp)
+ if (a(1) <= a(2)) stop 1
+ if (a(3) <= a(4)) stop 2
+ if (a(1) /= a(3)) stop 3
+ if (a(2) /= a(4)) stop 4
+end program main
Re: [PATCH v2] libgfortran: Replace mutex with rwlock
Hi Lipeng, This patch try to introduce the rwlock and split the read/write to unit_root tree and unit_cache with rwlock instead of the mutex to increase CPU efficiency. In the get_gfc_unit function, the percentage to step into the insert_unit function is around 30%, in most instances, we can get the unit in the phase of reading the unit_cache or unit_root tree. So split the read/write phase by rwlock would be an approach to make it more parallel. No comment on the code itself, as yet... but I'd like to know how throroughly you tested it, using which tools, and on which programs. Did you use valgrind --tool=helgrind or --tool=drd? Since it is prone to race conditions, did you also test Fortran's asynchronous I/O? Best regards Thomas
Re: [PATCH] Fortran: error recovery on associate with bad selector [PR107577]
Hi Harald, please find attached an obvious patch by Steve for a technical regression that resulted from improvements in error recovery of bad uses of associate. Regtested on x86_64-pc-linux-gnu. Will commit soon unless there are comments. Obvious enough, I think. Thanks! As a sidenote: the testcase shows that we resolve the associate names quite often, likely more often than necessary, resulting in many error messages produced for the same line of code. In the present case, each use of the bad name produces two errors, one where it is used, and one at the associate statement. That is probably not helpful for the user. We have an "error" flag in gfc_expr, which we use infrequently to avoid repetitions of errors. If an error has already been issued for an expression, then we could set this. We would have to be careful about resetting the error on matching though, so it is probably better to only use it during resolution. Best regards Thomas
[patch, RFC. Fortran] Some clobbering for INTENT(OUT) arrays
Hi,
following Mikael's recent patch series, here is a first idea
of what extending clobbering to arrays wold look like.
The attached patch works for a subset of cases, for example
program main
implicit none
interface
subroutine foo(a)
integer, intent(out) :: a(*)
end subroutine foo
end interface
integer, dimension(10) :: a
call foo(a)
end program main
and
program main
implicit none
interface
subroutine foo(a)
integer, intent(out) :: a(:)
end subroutine foo
end interface
integer, dimension(10) :: a
a(1) = 32
a(2) = 32
call foo(a)
end program main
but it does not cover cases like an assumed-size array
being handed down to an INTENT(OUT) argument.
What happens if the
+ if (!sym->attr.allocatable && !sym->attr.pointer
+ && !POINTER_TYPE_P (TREE_TYPE
(sym->backend_decl)))
part is taken out is that the whole descriptor can be clobbered in
such a case, which is of course not what is wanted.
I am a bit stuck of how to generate a reference to the first element
of the array (really, just dereferencing the data pointer)
in the most elegant way. I am currently leaning towards
building a gfc_expr, which should work, but would be less
than elegant.
So, anything more elegant at hand?
Best regards
Thomasdiff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 4f3ae82d39c..bbb00f90a77 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -43,6 +43,7 @@ along with GCC; see the file COPYING3. If not see
#include "gimplify.h"
#include "tm.h" /* For CHAR_TYPE_SIZE. */
+#include "debug.h"
/* Calculate the number of characters in a string. */
@@ -5981,7 +5982,6 @@ post_call:
gfc_add_block_to_block (>post, );
}
-
/* Generate code for a procedure call. Note can return se->post != NULL.
If se->direct_byref is set then se->expr contains the return parameter.
Return nonzero, if the call has alternate specifiers.
@@ -6099,6 +6099,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
{
bool finalized = false;
tree derived_array = NULL_TREE;
+ tree clobber_array = NULL_TREE;
e = arg->expr;
fsym = formal ? formal->sym : NULL;
@@ -6896,10 +6897,23 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
fsym->attr.pointer);
}
else
- /* This is where we introduce a temporary to store the
- result of a non-lvalue array expression. */
- gfc_conv_array_parameter (, e, nodesc_arg, fsym,
- sym->name, NULL);
+ {
+ /* This is where we introduce a temporary to store the
+ result of a non-lvalue array expression. */
+ gfc_conv_array_parameter (, e, nodesc_arg, fsym,
+ sym->name, NULL);
+ if (fsym && fsym->attr.intent == INTENT_OUT
+ && gfc_full_array_ref_p (e->ref, NULL))
+ {
+ gfc_symbol *sym = e->symtree->n.sym;
+ if (!sym->attr.allocatable && !sym->attr.pointer
+ && !POINTER_TYPE_P (TREE_TYPE (sym->backend_decl)))
+ clobber_array
+ = gfc_build_array_ref (e->symtree->n.sym->backend_decl,
+ build_int_cst (size_type_node, 0),
+ NULL_TREE, true, NULL_TREE);
+ }
+ }
/* If an ALLOCATABLE dummy argument has INTENT(OUT) and is
allocated on entry, it must be deallocated.
@@ -6952,6 +6966,13 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
tmp, build_empty_stmt (input_location));
gfc_add_expr_to_block (>pre, tmp);
}
+
+ if (clobber_array != NULL_TREE)
+ {
+ tree clobber;
+ clobber = build_clobber (TREE_TYPE(clobber_array));
+ gfc_add_modify (, clobber_array, clobber);
+ }
}
}
/* Special case for an assumed-rank dummy argument. */
Re: Proxy ping [PATCH] Fortran: Fix automatic reallocation inside select rank [PR100103]
Hello Harald, the patch for this PR was submitted for review by Jose here: https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html but unfortunately was never reviewed. I verified that it works on mainline and x86_64-pc-linux-gnu, and I think that it is fine. Although the above mail suggests that there is a dependency on the fix for another PR with a rather lengthy patch, it appears that this is no longer the case. It might be that the fix for PR100245 (another reallocation issue) already did the necessary job. So OK for mainline? Looks good to me. Thanks for picking up these patches! Best regards Thomas
Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
Hi Harald, I think I understand much of what is said, but I feel that I do not really understand what *clobber* means for the different beasts we are discussing (although I have an impression of what it means for a scalar object). Obviously, "clobber" means taking a big stick and hitting the beast in question over the head with it :-) More seriously: My understanding of a clobber it is a hint to the middle end that the value in question will not be used, and that operations leading to this value can be removed, unless they are used otherwise. If I'm wrong or imprecise, I'm sure somebody will correct me :-) Regards Thomas
Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
On 19.09.22 22:50, Mikael Morin wrote: Le 19/09/2022 à 21:46, Harald Anlauf a écrit : Am 18.09.22 um 22:55 schrieb Mikael Morin: Le 18/09/2022 à 20:32, Harald Anlauf a écrit : Assumed shape will be on the easy side, while assumed size likely needs to be excluded for clobbering. Isn’t it the converse that is true? Assumed shape can be non-contiguous so have to be excluded, but assumed size are contiguous, so valid candidates for clobbering. No? I really was referring here to *dummies*, as in the following example: program p integer :: a(4) a = 1 call sub (a(1), 2) print *, a contains subroutine sub (b, k) integer, intent(in) :: k integer, intent(out) :: b(*) ! integer, intent(out) :: b(k) if (k > 2) b(k) = k end subroutine sub end program p Assumed size (*) is just a contiguous hunk of memory of possibly unknown size, which can be zero. So you couldn't set a clobber for the a(1) actual argument. Couldn't you clobber A entirely? If no element of B is initialized in SUB, well, A has undefined values on return from SUB. That's how INTENT(OUT) works. Yes, I think so - you are passing the starting element of an array to an assumed-size array via storage association rules. It has to be an explicit interface, of course, otherwise it is unclear if an array or an array element is passed. Best regards Thomas
Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
On 18.09.22 11:10, Mikael Morin wrote: Le 18/09/2022 à 08:12, Richard Biener a écrit : On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin wrote: Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit : I have a concern about this part, though. My understanding at the time was that it is not possible to clobber an individual array element, but that this clobbers anything off the pointer that this is based on. Well, we need the middle-end guys to give a definitive answer on this topic, but I think it would be a very penalizing limitation if that was the case. I have assumed that the clobber spanned the value it was applied on, neither more nor less, so just the array element in case of array elements. There is IL verification that the LHS of a CLOBBER is either a declaration or a pointer dereference, no array or component selection is allowed there. Now, nothing should go wrong here, but we might eventually just drop those CLOBBERs or ICE if we frontend hands us an "invalid" one. Obviously I have assumed too much here; it's probably best to drop this patch. Probably, yes. It is unfortunate as there is some desirable behavior within reach here. I think some of the desired behavior can still be salvaged. For example, for subroutine foo(a,n) integer :: n integer, dimension(n), intent(in) :: n ... subroutine bar(a) integer, intent(out) :: a ... integer :: a(3) call foo(a,3) call foo(a(1),3) clobbers for the whole array can still be generated, but not for call foo(a(2),2) so one would have to look at the lower bound. For this case, it would be helpful to clobber a range a(2:), but that is a wishlist item for the future ;-) What is unsafe, currently, is call bar(a(1)) Best regards Thomas
Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
Hi Mikael, This adds support for clobbering of partial variable references, when they are passed as actual argument and the associated dummy has the INTENT(OUT) attribute. Support includes array elements, derived type component references, and complex real or imaginary parts. This is done by removing the check for lack of subreferences, which is basically a revert of r9-4911-gbd810d637041dba49a5aca3d085504575374ac6f. This removal allows more expressions than just array elements, components and complex parts, but the other expressions are excluded by other conditions: substrings are excluded by the check on expression type (CHARACTER is excluded), KIND and LEN references are rejected by the compiler as not valid in a variable definition context. The check for scalarness is also updated as it was only valid when there was no subreference. First, thanks a lot for digging into this subject. I have looked through the patch series, and it looks very good so far. I have a concern about this part, though. My understanding at the time was that it is not possible to clobber an individual array element, but that this clobbers anything off the pointer that this is based on. So, integer, dimension(3) :: a a(1) = 1 a(3) = 3 call foo(a(1)) would also invalidate the store to a(3). Is my understanding correct? If so, I think this we cannot revert that patch (which was introduced because of a regression). Best regards Thomas
Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions
Hi FX, 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 code, because I wrote the original IEEE implementation so I know it very well. I believe it would probably be better to commit this and have it tested on mainline, that wait for too long. I intend to submit further patches and improvements in this area, once those are merged. Looks good in principle. Just a couple of remarks: Both of these functions are new with Fortran 2018, could you add a standards version check? And, more general: I don't think we document which part of the IEEE arithmetic we support. It might be a good idea to add that to the manual (but not for this patch). So, OK with the version check. Best regards Thomas
Re: [PATCH] libgfortran: Use __builtin_issignaling in libgfortran
Hi Jakub, The following patch makes use of the new __builtin_issignaling, so it no longer needs the fallback implementation and can use the builtin even where glibc provides the macro. Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux and powerpc64le-linux, ok for trunk? OK. Can you mention PR 105105 in the ChangeLog when you commit? Thanks for the patch! Best regards Thomas
Re: [PATCH] libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble [PR106079]
Hi Jakub,
The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble
is used (either default through --with-long-double-format=ieee or
when used explicitly).
The problem is that the read/write transfer routines are called with
BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use to say
it is the IEEE quad real(kind=16) rather than the IBM double double
real(kind=16). For the floating point input/output we then handle kind
17 specially, but for B/O/Z we just treat the bytes of the floating point
value as binary blob and using 17 in that case results in unexpected
behavior, for write it means we don't estimate right how many chars we'll
need and print etc. rather than what we should, and
even with explicit size we'd print one further byte than intended.
For read it would even mean overwriting some unrelated byte after the
floating point object.
Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls.
Bootstrapped/regtested on powerpc64le-linux, ok for trunk / 12.2?
OK for both.
Best regards
Thomas
Re: [PATCH, v3] Fortran: detect blanks within literal constants in free-form mode [PR92805]
Hi Harald, This introduces the helper function gfc_match_next_char, which is your second option. I would be a little bit concerned about compilation times with the additional function call overhead. The function is used only in one place; would it make sense to put it into primary.cc and declare it static? Best regards Thomas
Re: [RFC] fortran: restore array indexing for all descriptor arrays [PR102043]
Hi Mikael, Feel free to comment, do we need this? Thanks for taking this on. One thought: If we have to bite the bullet and break the ABI, why not go all the way and use the C descriptors in ISO_Fortran_binding.h as gfortran's native format? Best regards Thomas
Re: [PATCH] Fortran: fix simplification of INDEX(str1,str2) [PR105691]
Hello Harald, compile time simplification of INDEX(str1,str2,back=.true.) gave wrong results. Looking at gfc_simplify_index, this appeared to be close to a complete mess, while the runtime library code - which was developed later - was a relief. The solution is to use the runtime library code as template to fix this. I took the opportunity to change string index and length variables in gfc_simplify_index to HOST_WIDE_INT. Regtested on x86_64-pc-linux-gnu. OK for mainline? As this is a wrong-code issue, would this qualify for backports to open branches? OK for both. Thanks for the patch! Best regards Thomas
Re: [PATCH] Fortran: handle explicit-shape specs with constant bounds [PR105954]
Hello Harald, after simplification of constant bound expressions of an explicit shape spec of an array, we need to ensure that we never obtain negative extents. In some cases this did happen, and we ICEd as we hit an assert that this should never happen... The original testcase by Gerhard exhibited this for sizeof() of a derived type with an array component, but the issue is more fundamental and affects other intrinsics during simplification. A straightforward solution "fixes up" the upper bound in the shape spec when it is known to be below lower bounds minus one. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. Thanks for the patch! Regards Thomas
Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
Hi, On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote: - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \ + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian' >/dev/null 2>&1; then \ echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info"; \ install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info || : ; \ else : ; fi; \ I'd replace -s >/dev/null 2>&1 with -q while at it. But why is -F used here in the first place? I do not see much in debian that can be interpreted as a regex? I'm not sure. It was there since 2004. Perhaps the author thinks fgrep may save several CPU cycles :). I'll just use a plain grep in PATCH v2. Rainer: do you have some idea about the availability of "-q" on different hosts? If you agree I'll use it instead of -s > /dev/null too. Is there any particular reason why we should not use the result of AC_PROG_FGREP ? AC_PROG_GREP should also work.
Re: [PATCH] Fortran: check POS and LEN arguments simplifying bit intrinsics [PR105986]
Hi Harald, we need to check the POS (and LEN) arguments of bit intrinsics when simplifying, e.g. when used in array constructors. Otherwise we ICE. Found by Gerhard. The fix is straightforward, see attached. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. Thanks for the patch! Regards Thomas
[patch, wwwdocs, committed] Update mail links and dates for GCC 12 and GCC 13 status
Hi, I just pushed the attached patch to update the mail links and dates for GCC 12 and GCC 13, as simple and obvious. Regards Thomasdiff --git a/htdocs/index.html b/htdocs/index.html index 199181b1..e1bb584e 100644 --- a/htdocs/index.html +++ b/htdocs/index.html @@ -172,7 +172,7 @@ More news? Let ger...@pfeifer.com know! Status: - https://gcc.gnu.org/pipermail/gcc/2022-April/238491.html;>2022-04-04 + https://gcc.gnu.org/pipermail/gcc/2022-April/238617.html;>2022-04-28 (frozen for release). @@ -244,7 +244,7 @@ More news? Let ger...@pfeifer.com know! Status: - https://gcc.gnu.org/pipermail/gcc/2022-April/238491.html;>2022-04-04 + https://gcc.gnu.org/pipermail/gcc/2022-April/238619.html;>2022-04-28 (general development).
[patch, wwwdocs, committed] Fix broken link in gcc-12/changes.html
Hi, after noticing an error in the gcc12 changes.html file, I fixed it as obvious and simple with the attached patch. Best regards Thomas Sun May 1 00:05:10 2022 +0200 Added equals sign to fix broken link in RISC-V section. * gcc-12/changes.html: Fixed broken link. diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index c409a17c..87c8bcf8 100644 --- a/htdocs/gcc-12/changes.html +++ b/htdocs/gcc-12/changes.html @@ -771,7 +771,7 @@ function Multiply (S1, S2 : Sign) return Sign is RISC-V Default ISA spec version was bump to 20191213, more detail see this https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4;> +href="https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4;> announcement New ISA extension support for zba, zbb, zbc, zbs was added. New ISA extension support for vector and scalar crypto was added, only
Re: *ping* [patch, wwwdocs] Mention POWER IEEE128 changes for gcc 12
Hi Mikael, OK in any case. Anything is better than nothing. Here is what I committed, with one final tweak. Thanks! Best regards Thomas --- a/htdocs/gcc-12/changes.html +++ b/htdocs/gcc-12/changes.html @@ -501,6 +501,15 @@ function Multiply (S1, S2 : Sign) return Sign is conforming to the Fortran 2018 standard. Previous versions used OPERATOR which conforms to TS 18508. + +On POWER systems which support it, the -mabi=ieeelongdouble +option now selects the IEEE 128-bit floating point format +for REAL(KIND=16). +R16_IBM and R16_IEEE have been added to the +-fconvert option, the CONVERT specifyer of +the OPEN statement and the GFORTRAN_CONVERT_UNIT +environment variable. +
*ping* [patch, wwwdocs] Mention POWER IEEE128 changes for gcc 12
the attached patch documents the support for IEEE long double for Fortran. OK? Suggestions for better wording? I'd like to get this in before the gcc12 release. It would also qualify as obviously correct, I think :-) so I'll commit this on Sunday unless there are any objections. Patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593780.html Best regards Thomas
Re: [patch, fortran, doc] Mention new CONVERT options for POWER
On 28.04.22 19:17, Bernhard Reutner-Fischer wrote: ISTM that this should be s/mod.e/mode./ ? Yep, fixed as obvious and simple on trunk with r13-49-g4a8b45e8bc8246bd141dad65f571a3e0cc499c6b . OK for backport to gcc-12? (This is both extremely safe and not particularly important :-) Best regards Thomas
[patch, wwwdocs] Mention POWER IEEE128 changes for gcc 12
Hi, the attached patch documents the support for IEEE long double for Fortran. OK? Suggestions for better wording? Best regards Thomas Mention support for IEEE 128-bit long double for Fortran. * htdocs/gcc-12/changes.html: Mention support for IEEE 128-bit long double for Fortran.diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index e9f132c0..083d713e 100644 --- a/htdocs/gcc-12/changes.html +++ b/htdocs/gcc-12/changes.html @@ -497,6 +497,14 @@ function Multiply (S1, S2 : Sign) return Sign is conforming to the Fortran 2018 standard. Previous versions used OPERATOR which conforms to TS 18508. + +On POWER systems which support it, -mabi=ieeelongdouble +now uses IEEE 128-bit for REAL(KIND=16). +R16_IBM and R16_IEEE have been added to the +-fconvert option, the CONVERT specifyer of +the OPEN statement and the GFORTRAN_CONVERT_UNIT +environment variable. +
[patch, fortran, doc] Mention new CONVERT options for POWER
Hi,
as we say in German "Nicht documentiert ist nicht gemacht", if
it is not documented, it wasn't done.
So I thought it would be time to document the changes to the various
ways of specifying CONVERT before gcc12 went out of the door, so
here is a patch for that.
If that goes in, I will also write up something for gcc-12/changes.html.
OK for trunk? Suggestions for improvements?
Best regards
Thomas
Document changes to CONVERT for -mabi-ieeelongdouble for POWER
gcc/fortran/ChangeLog:
* gfortran.texi: Mention r16_ieee and r16_ibm.
* invoke.texi: Likewise.diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index f8737f4d323..6f622fb9898 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -589,7 +589,7 @@ Malformed environment variables are silently ignored.
* GFORTRAN_SHOW_LOCUS:: Show location for runtime errors
* GFORTRAN_OPTIONAL_PLUS:: Print leading + where permitted
* GFORTRAN_LIST_SEPARATOR:: Separator for list output
-* GFORTRAN_CONVERT_UNIT:: Set endianness for unformatted I/O
+* GFORTRAN_CONVERT_UNIT:: Set conversion for unformatted I/O
* GFORTRAN_ERROR_BACKTRACE:: Show backtrace on run-time errors
* GFORTRAN_FORMATTED_BUFFER_SIZE:: Buffer size for formatted files
* GFORTRAN_UNFORMATTED_BUFFER_SIZE:: Buffer size for unformatted files
@@ -686,11 +686,12 @@ when @command{a.out} is the compiled Fortran program that you want to run.
Default is a single space.
@node GFORTRAN_CONVERT_UNIT
-@section @env{GFORTRAN_CONVERT_UNIT}---Set endianness for unformatted I/O
+@section @env{GFORTRAN_CONVERT_UNIT}---Set conversion for unformatted I/O
By setting the @env{GFORTRAN_CONVERT_UNIT} variable, it is possible
to change the representation of data for unformatted files.
-The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable is:
+The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable for
+most systems is:
@smallexample
GFORTRAN_CONVERT_UNIT: mode | mode ';' exception | exception ;
mode: 'native' | 'swap' | 'big_endian' | 'little_endian' ;
@@ -711,14 +712,24 @@ the modes are the same as for the @code{CONVERT} specifier:
for unformatted files.
@item @code{BIG_ENDIAN} Use the big-endian format for unformatted files.
@end itemize
+For POWER systems which support @option{-mabi=ieeelongdouble},
+there are additional options, which can be combined with the
+others with commas. Those are
+@itemize @w{}
+@item @code{R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{R16_IBM} Use IBM @code{long double} format for
+@code{REAL(KIND=16)}.
+@end itemize
A missing mode for an exception is taken to mean @code{BIG_ENDIAN}.
Examples of values for @env{GFORTRAN_CONVERT_UNIT} are:
@itemize @w{}
-@item @code{'big_endian'} Do all unformatted I/O in big_endian mode.
+@item @code{'big_endian'} Do all unformatted I/O in big_endian mod.e
@item @code{'little_endian;native:10-20,25'} Do all unformatted I/O
in little_endian mode, except for units 10 to 20 and 25, which are in
native format.
@item @code{'10-20'} Units 10 to 20 are big-endian, the rest is native.
+@item @code{'big_endian,r16_ibm'} Do all unformatted I/O in big-endian
+mode and use IBM long double for output of @code{REAL(KIND=16)} values.
@end itemize
Setting the environment variables should be done on the command
@@ -1736,7 +1747,7 @@ the @code{CONVERT} specifier on the @code{OPEN} statement.
@xref{GFORTRAN_CONVERT_UNIT}, for an alternative way of specifying
the data format via an environment variable.
-Valid values for @code{CONVERT} are:
+Valid values for @code{CONVERT} on most systems are:
@itemize @w{}
@item @code{CONVERT='NATIVE'} Use the native format. This is the default.
@item @code{CONVERT='SWAP'} Swap between little- and big-endian.
@@ -1745,6 +1756,15 @@ for unformatted files.
@item @code{CONVERT='BIG_ENDIAN'} Use the big-endian representation for
unformatted files.
@end itemize
+On POWER systems which support @option{-mabi=ieeelongdouble},
+there are additional options, which can be combined with the others
+with commas. Those are
+@itemize @w{}
+@item @code{CONVERT='R16_IEEE'} Use IEEE 128-bit format for
+@code{REAL(KIND=16)}.
+@item @code{CONVERT='R16_IBM'} Use IBM @code{long double} format for
+real@code{REAL(KIND=16)}.
+@end itemize
Using the option could look like this:
@smallexample
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 5c7501a28b1..c0932f6cd70 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1435,10 +1435,20 @@ These options affect the runtime behavior of programs compiled with GNU Fortran.
@item -fconvert=@var{conversion}
@opindex @code{fconvert=}@var{conversion}
Specify the representation of data for unformatted files. Valid
-values for conversion are: @samp{native}, the default; @samp{swap},
-swap between big- and little-endian; @samp{big-endian}, use big-endian
-representation for unformatted files; @samp{little-endian}, use little-endian
Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]
On 26.04.22 16:40, Hans-Peter Nilsson wrote: These, or specifically r12-8227-g89ca0fffa48b79, "fortran: Pre-evaluate string pointers. [PR102043]" have further exposed (the issue existed before but now fails for more platforms) PR78054 "gfortran.dg/pr70673.f90 FAILs at -O0", at least for cris-elf and apparently also s390x-ibm-linux-gnu. In the PR it is mentioned that running the test through valgrind shows invalid accesses also on x86_64-linux-gnu. Could it be that the test-case is invalid and has undefined behavior? I don't know fortran so I can't tell. You're right. I just looked at the test case and can confirm what Steve Kargl observed in the PR, it is in fact invalid. You cannot do a = a after deallocating a. I've assigned the PR to myself and will commit the change to dg-do compile soon (unless anybody objects). Best regards Thomas
Re: [PATCH] fortran: Compare non-constant bound expressions. [PR105379]
Hi Mikael, this fixes a regression caused by my recent PR103662 patch. Regression tested on x86_64-pc-linux-gnu. OK for master? OK. Good to see that a bit of optimization can also sneak in with a bug fix :-) Best regards Thomas
Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]
Hi Mikael, Ping for the four patches starting at https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html : https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html https://gcc.gnu.org/pipermail/fortran/2022-April/057760.html https://gcc.gnu.org/pipermail/fortran/2022-April/057758.html https://gcc.gnu.org/pipermail/fortran/2022-April/057761.html Richi accepted the general direction and the middle-end interaction. I need a fortran frontend ack as well. Looks good to me. Thanks a lot for taking this on! This would have been a serious regression if released with gcc 12. Best regards Thomas
Re: [PATCH, v2] PR fortran/105184 - ICE in gfc_array_init_size, at fortran/trans-array.cc:5841
Hi Harald, Regtested again with no new failures. OK for mainline? Looks good to me. Thanks for the patch! Best regards Thomas
Re: [PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used
Hi Harald, Steve's analysis (see PR) showed that we confused the case when a symbol refererred to a recursive procedure which was named the same as an intrinsic. The standard allows such recursive references (see e.g. F2018:19.3.1). The attached patch is based on Steve's, but handles both functions and subroutines. Testcase verified with NAG and Crayftn. Regtested on x86_64-pc-linux-gnu. OK for mainline? This bug is a rejects-valid, but could also lead to wrong code, see e.g. the PR, comment#4. Would this qualify for a backport to e.g. the 11-branch? OK for both. Thanks for the patch! Best regards Thomas
Re: [PATCH] fortran: Fix up initializers of param(0) PARAMETERs [PR103691]
On 25.03.22 12:34, Jakub Jelinek via Fortran wrote:
What is the behavior with a RANGE_EXPR when one has { [0..10] = ++i;
}, is that applying the side-effects 11 times or once ?
For side effects during the evaluation of expression, Fortran has a
clear "if you depend on it, it's your fault" rule. In F 2018, it says
10.1.7 Evaluation of operands
1 It is not necessary for a processor to evaluate all of the operands of
an expression, or to evaluate entirely each operand, if the value of the
expression can be determined otherwise.
Also, the semantics of
a(a:b) = expr
say that the expression on the LHS is evaluated only once before
assignment. So, anything that looks like that should be translated
to
tmp = ++i;
[0..10] = tmp;
Re: [PATCH] PR fortran/104619 - [10/11/12 Regression] ICE on list comprehension with default derived type constructor
Hi Harald, a recently introduced shape validation for an array constructor against the declared shape of a DT component failed to punt if the shape of the constructor cannot be determined at compile time. Suggested solution: skip the shape check in those cases. Regtested on x86_64-pc-linux-gnu. OK for mainline / affected branches? Looks good to me. Thanks for the patch! Best regards Thomas
Re: [PATCH] PR fortran/77693 - ICE in rtl_for_decl_init, at dwarf2out.c:17378
Hi Harald, Regtested on x86_64-pc-linux-gnu. OK for mainline? Looks good to me. Thanks for the patch! Best regards Thomas
Re: [PATCH] PR fortran/104211 - ICE in find_array_section, at fortran/expr.cc:1720
Hi Harald, when referencing a bad array section after an erroneous previous declaration we might hit an assert. The assert can be replaced by a more gracious error recovery. Reported by Gerhard. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. Thanks for the patch! Best regards Thomas
Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
On 24.01.22 15:23, FX via Fortran wrote: 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? 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). Best regards Thomas
Re: [PATCH] PR fortran/104127 - [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
Hello Harald, when simplifying TRANSFER with a MOLD argument of type character and with SIZE=0 we lose the character length. This happens in all gfortran versions and results in wrong code. The purported regression is that at some point in the 9-development this lead to a (previously possibly latent) ICE. The attached patch sets up the character length in the typespec and fixes the ICE. There is another generic hidden/latent problem with array constructors of size 0 passed to procedures (see e.g. pr86277) which will remain and is beyond the scope of this fix. Regtested on x86_64-pc-linux-gnu. I also fixed a minor logic bug in testcase transfer_simplify_11.f90. OK for mainline? Backports to branches? OK for both. Thanks for the patch! Regards Thomas
Re: [PATCH] fortran: Extend -fconvert= option for ppc64le r16_ieee and r16_ibm
Hi Jakub, This patch on top of the previously posted option handling changes patch allows specifying -fconvert=swap,r16_ieee etc. (but will error on it when not on powerpc64le because in the library such swapping is only implemented for HAVE_REAL_17). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK! This is a much cleaner solution than what I had in mind, but didn't start work on, which was to make the option into a string and parse by hand. Best regards Thomas
Re: [PATCH] Fortran: Fix scope for OMP AFFINITY clause iterator variables [PR103695]
Hi Sandra, This patch is for PR103695, marked as a P1 regression. OK to check in? I'm not an OpenMP expert, but this looks straightforward enough. I assume you ran a regression-test? OK if that is the case. Thanks for the patch! Best regards Thomas
Re: [PATCH] PR fortran/103692 - [11/12 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:2062
Hi Harald, after lengthy debugging of this PR it became obvious that we killed the typespec while trying to expand an empty array constructor. Bad idea, but easy to fix. Regtested on x86_64-pc-linux-gnu. OK for mainline and 11-branch? OK. Thanks for the patch! Best regards Thomas
Re: [patch, libgfortran, power-ieee128] Add multiple defaults for GFORTRAN_CONVERT_UNIT
On 13.01.22 22:58, Thomas Koenig via Fortran wrote: with this patch, it is now possible to specify both the endianness and the REAL(KIND=16) format using the environment variable GFORTRAN_CONVERT_UNIT. I have now pushed this to trunk. Best regards Thomas
Re: [pushed 3/3] testsuite: Enrich tests with variants failing on the branch.
Hi Mikael, Backporting the fix for pr103789 on the 11 branch revealed a lack of test coverage for the tests provided with that fix. Indeed, the tests use the KIND argument of the respective intrinsics only with keyword arguments. This adds variants with non-keyword arguments. The tests enriched this way fail on the branch if the fix is cherry-picked straightforwardly. The fix will have to be tweaked slightly there. As a general principle, we should not add or amend test cases unless it is wrong code that we need to remove The reason is that changing a test case makes regression testing, especially the automated version, harder - if a test starts failing, is it due to a change in the test case or a change in the compiler or library? I don't think there is a need to revert this patch, but please add separate test cases if you have new things to test in the future. Best regards Thomas
Re: [PATCH] PR fortran/83079 - ICE and wrong code with TRANSFER and character(kind=4)
Hi Harald, An early *ping* ... OK. Thanks for the patch! Best regards Thomas
[patch, libgfortran, power-ieee128] Add multiple defaults for GFORTRAN_CONVERT_UNIT
Hello world,
with this patch, it is now possible to specify both the
endianness and the REAL(KIND=16) format using the
environment variable GFORTRAN_CONVERT_UNIT. The following
now works:
koenig@gcc-fortran:~/Tst$ cat write_env.f90
program main
real(kind=16) :: x
character (len=30) :: conv
x = 1/3._16
open
(10,file="out.dat",status="replace",access="stream",form="unformatted")
inquire(10,convert=conv)
print *,conv
write (10) 1/3._16
end program main
tkoenig@gcc-fortran:~/Tst$ gfortran -g -static-libgfortran write_env.f90
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="little_endian;r16_ibm"
&& ./a.out
LITTLE_ENDIAN,R16_IBM
tkoenig@gcc-fortran:~/Tst$
GFORTRAN_CONVERT_UNIT="little_endian;r16_ieee" && ./a.out
LITTLE_ENDIAN,R16_IEEE
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="big_endian;r16_ieee"
&& ./a.out
BIG_ENDIAN,R16_IEEE
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="big_endian;r16_ibm" &&
./a.out
BIG_ENDIAN,R16_IBM
Since the branch has been pushed to trunk, I don't think we need
it any more (or do we?), so OK for trunk?
Best regards
Thomas
Allow for multiple defaults in endianness and r16 in GFORTRAN_CONVERT_UNIT.
With this patch, it is possible to specify multiple defaults inthe
GFORTRAN_CONVERT_UNIT environment variable so that, for example, R16_IEEE
and BIG_ENDIAN can be specified together.
libgfortran/ChangeLog:
* runtime/environ.c: Allow for multiple default values so that
separate default specifications for IBM long double format and
endianness are possible.
diff --git a/libgfortran/runtime/environ.c b/libgfortran/runtime/environ.c
index 3d60950234d..a53c64965b6 100644
--- a/libgfortran/runtime/environ.c
+++ b/libgfortran/runtime/environ.c
@@ -499,78 +499,79 @@ do_parse (void)
unit_count = 0;
- start = p;
-
/* Parse the string. First, let's look for a default. */
- tok = next_token ();
endian = 0;
-
- switch (tok)
+ while (1)
{
-case NATIVE:
- endian = GFC_CONVERT_NATIVE;
- break;
+ start = p;
+ tok = next_token ();
+ switch (tok)
+ {
+ case NATIVE:
+ endian = GFC_CONVERT_NATIVE;
+ break;
-case SWAP:
- endian = GFC_CONVERT_SWAP;
- break;
+ case SWAP:
+ endian = GFC_CONVERT_SWAP;
+ break;
-case BIG:
- endian = GFC_CONVERT_BIG;
- break;
+ case BIG:
+ endian = GFC_CONVERT_BIG;
+ break;
-case LITTLE:
- endian = GFC_CONVERT_LITTLE;
- break;
+ case LITTLE:
+ endian = GFC_CONVERT_LITTLE;
+ break;
#ifdef HAVE_GFC_REAL_17
-case R16_IEEE:
- endian = GFC_CONVERT_R16_IEEE;
- break;
+ case R16_IEEE:
+ endian = GFC_CONVERT_R16_IEEE;
+ break;
-case R16_IBM:
- endian = GFC_CONVERT_R16_IBM;
- break;
+ case R16_IBM:
+ endian = GFC_CONVERT_R16_IBM;
+ break;
#endif
-case INTEGER:
- /* A leading digit means that we are looking at an exception.
- Reset the position to the beginning, and continue processing
- at the exception list. */
- p = start;
- goto exceptions;
- break;
+ case INTEGER:
+ /* A leading digit means that we are looking at an exception.
+ Reset the position to the beginning, and continue processing
+ at the exception list. */
+ p = start;
+ goto exceptions;
+ break;
-case END:
- goto end;
- break;
+ case END:
+ goto end;
+ break;
-default:
- goto error;
- break;
+ default:
+ goto error;
+ break;
}
- tok = next_token ();
- switch (tok)
-{
-case ';':
- def = endian;
- break;
+ tok = next_token ();
+ switch (tok)
+ {
+ case ';':
+ def = def == GFC_CONVERT_NONE ? endian : def | endian;
+ break;
-case ':':
- /* This isn't a default after all. Reset the position to the
- beginning, and continue processing at the exception list. */
- p = start;
- goto exceptions;
- break;
+ case ':':
+ /* This isn't a default after all. Reset the position to the
+ beginning, and continue processing at the exception list. */
+ p = start;
+ goto exceptions;
+ break;
-case END:
- def = endian;
- goto end;
- break;
+ case END:
+ def = def == GFC_CONVERT_NONE ? endian : def | endian;
+ goto end;
+ break;
-default:
- goto error;
- break;
+ default:
+ goto error;
+ break;
+ }
}
exceptions:
Re: [power-ieee128, committed] Enable conversion selection via environment variable
On 11.01.22 14:19, Jakub Jelinek via Fortran wrote: On Mon, Jan 10, 2022 at 11:44:13PM +0100, Thomas Koenig wrote: Hello world, I have just pushed the attched patch to the branch. Thanks. Here is a patch to fix up the ppc64be vs. ppc64le byteswapping of IBM extended real(kind=16) and complex(kind=16). Similarly to the BT_COMPLEX case it halves size and doubles nelems for the bswap_array calls. Of course for r16_ibm and r16_ieee conversions one needs to make sure it is only done when the on file data is in that format and not in IEEE quad. The patch is OK. So... time to merge the branch into trunk before stage 4 kicks in? IMHO yes. We need to git merge master; git rebase of course before trying to cherry-pick those commits into trunk and pushing there. I would prefer if somebody else did this - my lack of git-fu would forseeably lead to some unforseen problems :-) Best regards Thomas
[power-ieee128, committed] Enable conversion selection via environment variable
Hello world,
I have just pushed the attched patch to the branch.
With this patch, the program
tkoenig@gcc-fortran:~/Tst$ cat write_env.f90
program main
real(kind=16) :: x
character (len=30) :: conv
x = 1/3._16
open
(10,file="out.dat",status="replace",access="stream",form="unformatted")
inquire(10,convert=conv)
print *,conv
write (10) 1/3._16
end program main
gives the result:
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="r16_ibm:10" ./a.out &&
od -w64 -t x1 out.dat
LITTLE_ENDIAN,R16_IBM
000 55 55 55 55 55 55 d5 3f 56 55 55 55 55 55 75 3c
020
tkoenig@gcc-fortran:~/Tst$ GFORTRAN_CONVERT_UNIT="r16_ieee:10" ./a.out
&& od -w64 -t x1 out.dat
LITTLE_ENDIAN,R16_IEEE
000 80 55 55 55 55 55 55 55 55 55 55 55 55 55 fd 3f
020
tkoenig@gcc-fortran:~/Tst$
GFORTRAN_CONVERT_UNIT="big_endian:10;r16_ieee:10" ./a.out && od -w64 -t
x1 out.dat
BIG_ENDIAN,R16_IEEE
000 3f fd 55 55 55 55 55 55 55 55 55 55 55 55 55 80
020
so things look OK. In the next few days, I will do a bit more
testing to see if I have missed any corner cases.
So, the only thing missing is handling of the options, but
I think that is not critical (and could be added later; two
separate possibilities might just be enough for most users :-)
So... time to merge the branch into trunk before stage 4
kicks in?
Best regards
Thomas
Handle R16 conversion for POWER in the environment variables.
This patch handles the environment variables for the REAL(KIND=16)
variables like for the little/big-endian routines, so users without
who have no access to the source or are unwilling to recompile
can use this.
Syntax is, for example
GFORTRAN_CONVERT_UNIT="r16_ieee:10;little_endian:10" ./a.out
libgfortran/ChangeLog:
* runtime/environ.c (R16_IEEE): New macro.
(R16_IBM): New macro.
(next_token): Handle IBM R16 conversion cases.
(push_token): Likewise.
(mark_single): Likewise.
(do_parse): Likewise, initialize endian.
diff --git a/libgfortran/runtime/environ.c b/libgfortran/runtime/environ.c
index fe16c080797..ff10fe53f68 100644
--- a/libgfortran/runtime/environ.c
+++ b/libgfortran/runtime/environ.c
@@ -247,6 +247,11 @@ init_variables (void)
#define SWAP 258
#define BIG 259
#define LITTLE 260
+#ifdef HAVE_GFC_REAL_17
+#define R16_IEEE 261
+#define R16_IBM 262
+#endif
+
/* Some space for additional tokens later. */
#define INTEGER 273
#define END (-1)
@@ -392,6 +397,15 @@ next_token (void)
result = match_word ("swap", SWAP);
break;
+#ifdef HAVE_GFC_REAL_17
+case 'r':
+case 'R':
+ result = match_word ("r16_ieee", R16_IEEE);
+ if (result == ILLEGAL)
+ result = match_word ("r16_ibm", R16_IBM);
+ break;
+
+#endif
case '1': case '2': case '3': case '4': case '5':
case '6': case '7': case '8': case '9':
result = match_integer ();
@@ -414,7 +428,8 @@ push_token (void)
/* This is called when a unit is identified. If do_count is nonzero,
increment the number of units by one. If do_count is zero,
- put the unit into the table. */
+ put the unit into the table. For POWER, we have to make sure that
+ we can also put in the conversion btween IBM and IEEE long double. */
static void
mark_single (int unit)
@@ -428,7 +443,11 @@ mark_single (int unit)
}
if (search_unit (unit, ))
{
+#ifdef HAVE_GFC_REAL_17
+ elist[i].conv |= endian;
+#else
elist[i].conv = endian;
+#endif
}
else
{
@@ -437,7 +456,11 @@ mark_single (int unit)
n_elist += 1;
elist[i].unit = unit;
+#ifdef HAVE_GFC_REAL_17
+ elist[i].conv |= endian;
+#else
elist[i].conv = endian;
+#endif
}
}
@@ -481,6 +504,8 @@ do_parse (void)
/* Parse the string. First, let's look for a default. */
tok = next_token ();
+ endian = 0;
+
switch (tok)
{
case NATIVE:
@@ -499,6 +524,15 @@ do_parse (void)
endian = GFC_CONVERT_LITTLE;
break;
+#ifdef HAVE_GFC_REAL_17
+case R16_IEEE:
+ endian = GFC_CONVERT_R16_IEEE;
+ break;
+
+case R16_IBM:
+ endian = GFC_CONVERT_R16_IBM;
+ break;
+#endif
case INTEGER:
/* A leading digit means that we are looking at an exception.
Reset the position to the beginning, and continue processing
@@ -571,6 +605,19 @@ do_parse (void)
goto error;
endian = GFC_CONVERT_BIG;
break;
+#ifdef HAVE_GFC_REAL_17
+ case R16_IEEE:
+ if (next_token () != ':')
+ goto error;
+ endian = GFC_CONVERT_R16_IEEE;
+ break;
+
+ case R16_IBM:
+ if (next_token () != ':')
+ goto error;
+ endian = GFC_CONVERT_R16_IBM;
+ break;
+#endif
case INTEGER:
push_token ();
[power-ieee128, patch, committed] Implement CONVERT specifier
Hi,
I just pushed the attached patch to the branch. It works with the
attached test case for -mabi=ibmlongdouble and -mabi=ieeelongdouble.
The test case is not quite ready for inclusion in the test suite;
it still leaves its last data files behind, and it needs to be
dejagnuified and put with the right options into the right
directory. Not quite sure how to do this.
Still to do: the environment variables and -fconvert.
For the -fconvert option, I would like to see the same sort
of syntax as in the convert option, something like
-fconvert=r16_ieee,big-endian
but I do not know how to massage the *.opt files to accomplish
that.
Regarding specifying via environment variables: Next on
my agenda.
So, here's the patch.
Implement CONVERT specifier for OPEN.
This patch, based on Jakub's work, implements the CONVERT
specifier for the power-ieee128 brach. It allows specifying
the conversion as r16_ieee,big_endian and the other way around,
based on a table. Setting the conversion via environment
variable and via program option does not yet work.
gcc/ChangeLog:
* flag-types.h (enum gfc_convert): Add flags for
conversion.
gcc/fortran/ChangeLog:
* libgfortran.h (unit_convert): Add flags.
libgfortran/ChangeLog:
* Makefile.in: Regenerate.
* io/file_pos.c (unformatted_backspace): Mask off
R16 parts for convert.
* io/inquire.c (inquire_via_unit): Add cases for
R16 parts.
* io/open.c (st_open): Add cases for R16 conversion.
* io/transfer.c (unformatted_read): Adjust for R16 conversions.
(unformatted_write): Likewise.
(us_read): Mask of R16 bits.
(data_transfer_init): Likewiese.
(write_us_marker): Likewise.
! { dg-do run }
program tescht
implicit none
real (kind=16), parameter :: one_third = 3
call test_sanity
call test_sanity("r16_ieee")
call test_sanity("r16_ieee,big_endian")
call test_sanity("r16_ibm")
call test_sanity("big_endian,r16_ibm")
call test_ibm("r16_ibm")
call test_ibm("r16_ibm,swap")
call test_ibm("r16_ibm,big_endian")
call test_ibm("r16_ibm,little_endian")
call test_ibm("swap,r16_ibm")
call test_ibm("big_endian,r16_ibm")
call test_ibm("little_endian,r16_ibm")
contains
subroutine test_sanity(convert)
character(len=*), optional :: convert
real(kind=16) :: a, b, c, d
complex(kind=16) :: c1, c2
real(kind=16) :: arr(2)
complex(kind=16), dimension(10) :: c_arr
real(kind=16), dimension(10) :: a_arr, b_arr
integer :: i
if (present(convert)) then
open(10,file="dat",form="unformatted",convert=convert,status="replace")
else
open(10,file="dat",form="unformatted",status="replace")
end if
a = atan(1._16)*4
! Writing a single value and reading it back again
write (10) a
rewind (10)
read (10) b
if (abs(a-b) > 1e-30) stop 10
! Writing out a KIND=16 complex number and reading
! it back again
rewind(10)
c1 = cmplx(a, one_third,16)
rewind(10)
write (10) c1
rewind(10)
c2 = 0
read (10) c2
if (abs(c1 - c2) > 1e-10) stop 11
! Reading it back in as two reals
rewind(10)
read (10) c,d
if (abs(c-a) > 1e-30 .or. abs(d-one_third) > 1e-30) stop 12
! Reading it back as an array of two reals
rewind(10)
read (10) arr
if (abs(arr(1) - a) > 1e-30 .or. abs(arr(2) - one_third) > 1e-30) stop 13
close(10)
! Writing out a complex array
c_arr = [(1._16/(1._16+cmplx(0,i,16)),i=1,size(c_arr))]
rewind(10)
write (10) c_arr
rewind(10)
read (10) (a_arr(i), b_arr(i),i=1,10)
if (any (abs(real(c_arr)-a_arr) > 1e-30) .or. any(abs(aimag(c_arr)-b_arr) > 1e-30)) stop 14
end subroutine test_sanity
subroutine test_ibm(convert)
! Specific checks for writing and reading IBM long doubles as pairs
! of doubles.
character(len=*) :: convert
double precision:: x1, x2, x3, x4
real(kind=16) :: a, b, c
complex(kind=16) :: c1, c2
real(kind=16) :: rf(2)
a = atan(1._16)*4
open (10,file=convert // ".dat",status="replace",form ="unformatted",convert=convert)
! Writing a single value and reading it back again
write (10) a
rewind(10)
read (10) b
if (abs(a-b) > 1e-30) stop 1
return
! Writing out a KIND=16 value and reading it back again as a
! pair of doubles.
rewind(10)
read (10) x1, x2
b = real(x1,kind=16) + real(x2,kind=16)
if (abs(a-b) > 1e-30) stop 2
! Writing out a KIND=16 complex number and reading
! it back again
rewind (10)
c1 = cmplx(a, one_third,16)
write (10) c1
rewind (10)
read (10) c2
if (abs(c1 - c2) > 1e-10) stop 3
! Reading it back as a KIND=16 REAL array
rewind(10)
read (10) rf
if (abs(rf(1) - a) > 1e-30 .or. abs(rf(2) - one_third) > 1e-30) stop 4
! Reading it back as four double precision values
rewind (10)
read (10) x1, x2, x3, x4
b = real(x1,kind=16) +
Re: [power-ieee128] OPEN CONV
On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: Note, as for byteswapping, apparently it wasn't ever working right fox the IBM extended real(kind=16) and complex(kind=16). The lack of bug reports since the conversion feature was introduced in 2006, more than 15 years ago, tells us something, I guess...
Re: [power-ieee128] OPEN CONV
On 07.01.22 22:48, Jakub Jelinek wrote: On Fri, Jan 07, 2022 at 10:40:50PM +0100, Thomas Koenig wrote: One thing that one has to watch out for is a big-endian IBM long double file, so the byte swapping will have to be done before assigning the value. I've tried to handle that right, i.e. on unformatted read with byte-swapping and r16 <-> r17 conversions first do byte-swapping and then r16 <-> r17 conversions, while for unformatted writes first r16 <-> r17 conversions and then byte-swapping. I have tried to unravel the different cases here, I count six (lumping together the environment variables, the CONVERT specifier and -fconvert, and leaving out the byte swapping) CompilerConvert Read action Write action IEEENone NoneNone IEEEIEEE NoneNone IEEEIBM IBM->IEEE IEEE->IBM IBM None NoneNone IBM IEEE IEEE->IBM IBM->IEEE IBM IBM NoneNone From this table, it is clear that the compiler has to inform the library about the option it is using, I think it is best encoded in the number passed to _gfortran_set_convert. Old programs should continue to run with the new library, so the absence of a call to _gfortran_set_convert, or a call which sets byte swapping, should have the old meaning, i.e IBM long double. A program which uses IEEE long double should then call _gfortran_set_convert with a suitable argument to let the library know what to do, just in case. I think this is what I will start working on. Best regards Thomas
Re: [power-ieee128] OPEN CONV
On 07.01.22 20:52, Jakub Jelinek wrote: Here is completely untested patch that implements something, but doesn't implement the gcc option stuff, nor the CONVERT= syntax to supply multiple conversion options nor done anything about env var nor any testcases. But it tries to have the native/swap/big/little choice orthogonal from native/r16_ieee/r16_ibm with r16_ieee and r16_ibm only supported on ppc64le-linux. For INQUIRE it has the so far perhaps manageable set of possibilities handled so that it uses string literals and doesn't have to construct those strings at runtime (haven't studied how it would need to be done). I'm afraid I don't know that stuff enough to move forward from this. That looks like the direction to go. I will take it from there and see if I can find some hours over the weekend to work on something. Unfortunately, my daytime job will kick in again on Monday :-) One thing that one has to watch out for is a big-endian IBM long double file, so the byte swapping will have to be done before assigning the value. Best regards Thomas
Re: [power-ieee128] RFH: LTO broken
Hi Jakub, So, the following patch adds -fbuilding-libgfortran option and uses it together with TARGET_GLIBC_M* checks to decide whether to use libquadmath APIs (for the IEEE quad kind=16 if -fbuilding-libgfortran and not glibc or glibc is older than 2.32) or glibc 2.32 APIs (otherwise). This way, libgfortran uses solely the libquadmath APIs on glibc < 2.32 and __*ieee128 APIs on glibc 2.32, while user code always uses the latter. Ok for power-ieee128? OK! Best regards Thomas
Re: [power-ieee128] RFH: LTO broken
Hi Jakub, 00251038 06ad0015 R_PPC64_JMP_SLOT __cabsieee128 + 0 All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc. So, seems all these come from f951 compiled sources. For user code, I think the agreement was if you want to use successfully -mabi=ieeelongdouble, you need glibc 2.32 or later, which is why the Fortran FE doesn't conditionalize on whether glibc 2.32 is available or not and just emits __WHATEVERieee128 entrypoints. That was the idea, I think. But for Fortran compiled sources in libgfortran, we need to use __WHATEVERieee128 only if glibc 2.32 or later and WHATEVERq (from libquadmath) otherwise. I guess easiest would be to do this always in the FE, but we need to determine in the FE if the target is glibc 2.32 or later. Instead of determining this in the front end, maybe we can add an option (documented, but marked as useful as only for internal use and with no guarantee that it will remain) and use that option when compiling libgfortran. On the other side, on glibc 2.32+ build, we still use some libquadmath APIs when we shouldn't: readelf -Wr /home/jakub/gcc/obj/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5 | grep QUADMATH 002502c8 00260015 R_PPC64_JMP_SLOT fmaq@QUADMATH_1.0 + 0 002505f8 00670015 R_PPC64_JMP_SLOT tanq@QUADMATH_1.0 + 0 00250930 009b0015 R_PPC64_JMP_SLOT fabsq@QUADMATH_1.0 + 0 00250940 009d0015 R_PPC64_JMP_SLOT sinq@QUADMATH_1.0 + 0 00250c98 00cf0015 R_PPC64_JMP_SLOT copysignq@QUADMATH_1.0 + 0 00251038 01070015 R_PPC64_JMP_SLOT cosq@QUADMATH_1.0 + 0 00251068 010a0015 R_PPC64_JMP_SLOT fmodq@QUADMATH_1.0 + 0 These should use __fmaieee128, __tanieee128 etc. instead. This one seems easily fixed by the following patch, ok for power-ieee128? OK! Best regards Thomas
Re: [power-ieee128] OPEN CONV
On 07.01.22 10:22, Jakub Jelinek wrote: On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote: On 06.01.22 06:00, Michael Meissner via Fortran wrote: What is still missing is the conversion for unformatted I/O, both ways. I'll start doing some stuff on it. Just one question: What are functions that I can use to convert from IBM long double to IEEE and long double and vice versa? It was in an e-mail somewhere, but I cannot find it at the moment. So, what's the plan for that? Can't find CONVERT= in Fortran 2018, so I assume it is a non-standard extension, Correct. https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/file-operation-i-o-statements/open-statement-specifiers/open-convert-specifier.html#open-convert-specifier documents the Intel one We followed Intel on that one. NAG also has it (although the details differ). and we accept CONVERT='native' CONVERT='swap' CONVERT='big_endian' CONVERT='little_endian' Now, I suppose for powerpc64le we want to add some more, but the question is how they play together with the byteswapping and how to name them, so that it is clear they talk about REAL/COMPLEX KIND=16 format and nothing else. Can we (or do we) want to allow multiple comma separated strings from the orthogonal choices, like CONVERT='big_endian,ibm_extended' CONVERT='swap,ieee_extended' or add ibm_extended, ieee_extended and strings that combine those with swap, big_endian and little_endian ibm_extended_swap, ieee_extended_little etc.? In https://gcc.gnu.org/pipermail/fortran/2021-October/056895.html I made a suggestion how how the format could look like. I used a plus sign instead of a comma because I thought the environment variable should follow the same syntax as the CONVERT specifier, and I did not want to think about having commas in there :-) Thinking about this again after some time, I think the syntax of the environment variable would be clearer if the keywords for the two conversions were separate, so somethig like big_endian;r16_ieee;r16_ibm:10-20; for the environment variable and CONVERT="big_endian,r16_ibm" would probably be better. Best regards Thomas
Re: [power-ieee128] RFH: LTO broken
On 06.01.22 06:00, Michael Meissner via Fortran wrote: I pushed the patch to the branch. Test results are looking quite good right now. What is still missing is the conversion for unformatted I/O, both ways. I'll start doing some stuff on it. Just one question: What are functions that I can use to convert from IBM long double to IEEE and long double and vice versa? It was in an e-mail somewhere, but I cannot find it at the moment. Best regards Thomas
Re: [power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes
Hi Jakub,
This test FAILs because
f951: Error: '-mabi=ieeelongdouble' requires full ISA 2.06 support
compiler exited with status 1
FAIL: gfortran.dg/pr47614.f -O0 (test for excess errors)
As powerpc64le* only supports -mcpu=power8 and newer, I think we shouldn't
be testing with that option.
Ok for power-ieee128?
OK (I would also consider it obvious).
Though, I'm still unsure on what we should do with the array descriptors.
typedef struct dtype_type
{
size_t elem_len;
int version;
signed char rank;
signed char type;
signed short attribute;
}
dtype_type;
Is elem_len really element length, or kind, or both?
It is specified as a length, and should be set correctly also
for complex (where it is twice the length).
It seems a lot of code uses that interchangeably, is there anything where
we'd rely on whether it is the IBM extended real(kind=16) or IEEE quad
real(kind=16) (either in libgfortran or elsewhere)?
I think we use sizeof in all relevant files.
At least in libgfortran/generates/*, GFC_DESCRIPTOR_SIZE is mostly used
as mask_kind (I think the mask arrays are always logical not real/complex,
right?), or for logical stuff like matmul_l*.
Yes, masks are always of type logical, so that should not be an issue.
There are two direct uses of elem_len in caf/singe.c, one in
date_and_time.c and one in io/transfer.c. There is also some
use of a variable of that name ISO_Fortran_binding.c, which can
be checked later.
Best regards
Thomas
Re: [power-ieee128] fortran, libgfortran: Add remaining missing *_r17 symbols
Hi Jakub, Following patch adds remaining missing *_r17 entrypoints, so that we have 91 *_r16 and 91 *_r17 entrypoints (and 24 *_c16 and 24 *_c17). This fixes: FAIL: gfortran.dg/dec_math.f90 -O0 execution test FAIL: gfortran.dg/dec_math.f90 -O1 execution test FAIL: gfortran.dg/dec_math.f90 -O2 execution test FAIL: gfortran.dg/dec_math.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/dec_math.f90 -O3 -g execution test FAIL: gfortran.dg/dec_math.f90 -Os execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O0 execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O1 execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O2 execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O3 -g execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -Os execution test Ok for power-ieee128? Looks good to me. Thanks! Thomas
Re: [power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes
On 04.01.22 15:23, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? Also OK. Best regards Thomas
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix
On 04.01.22 14:41, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? OK.
Re: [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O
Hi Jakub, clearly there is still work to fix (but seems e.g. most of the lto tests are related to the gnu attributes stuff:( ). This is looking better than what I expected. Apart from LTO, I expect that a couple of files still do not have the correct flags set when compiling, or maybe some types are wrong. This is now something that can be debugged in detail. Ok? OK. And thanks! Best regards Thomas
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
On 03.01.22 17:26, Jakub Jelinek wrote: so we could similarly have something like: #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; #endif ... #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif ... #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16 _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif That would also work for me. or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable includes that only define macros and not actual C code). With my most recent commit, HAVE_GFC_REAL_17 can now be found in kinds.inc if all of the macros above are defined, that should be suitable. I found that __powerpc64__ is not defined when compiling *.F90 files (which is why I added them by hand). Not sure how the preprocessor is invoked on gfortran.map, but if things don't work, this could be related :-) So, it's OK either way with me. What do others think? Best regards Thomas
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
Hi Jakub,
So, either we'd need to add e.g. preprocessing support for gfortran.map
or some other way how to make certain symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g._gfortran_transfer_{real,complex}ieee128{,_write}).
Any preferences?
My personal preference would be the ieee128 variant, it would be cleaner
that way, but I have no strong opinion either way.
So, that variant is OK from my side, but maybe you could wait for
a day or so for anybody else to chime in.
Best regards
Thomas
Re: [power-ieee128] libquadmath: Use -mno-gnu-attribute in libquadmath
On 03.01.22 16:24, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? OK. Thanks! Best regards Thomas
Re: [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran
Hi Jakub, On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote: The idea behind this is that libstdc++ is written such that it can handle both IBM extended and IEEE quad long double, so its object files are compatible with both. Now tested on powerpc64le-linux (and together with the regenerated file), ok for power-ieee128? Since you posted it, I had already tested this and included it into the patch I pushed a couple of minutes ago. So, OK, and I already pushed it :-) Thanks a lot for your help in this! Best regards Thomas
[patch, power-ieee128, committed] Make the library functions compile correctly
Hello world, the attached patch lets the library compile correctly, as far as I have been able to determine. Committed to the branch. Best regards Thomas Make sure the Fortran specifics have real(kind=16). This brings the library to compile with all specific functions. It also corrects the patsubst patterns so the right files get the flags. It was necessary to manually add -D__powerpc64__ because apparently this is not set for Fortran. libgfortran/ChangeLog: * Makefile.am: Correct files for compilation flags. Add -D__powerpc64__ for Fortran sources. Get kinds.inc from grep of kinds.h and kinds-override.h. * Makefile.in: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Add -mno-gnu-attribute to compile flags. * generated/_abs_c17.F90: Regenerate. * generated/_abs_r17.F90: Regenerate. * generated/_acos_r17.F90: Regenerate. * generated/_acosh_r17.F90: Regenerate. * generated/_aimag_c17.F90: Regenerate. * generated/_aint_r17.F90: Regenerate. * generated/_anint_r17.F90: Regenerate. * generated/_asin_r17.F90: Regenerate. * generated/_asinh_r17.F90: Regenerate. * generated/_atan2_r17.F90: Regenerate. * generated/_atan_r17.F90: Regenerate. * generated/_atanh_r17.F90: Regenerate. * generated/_conjg_c17.F90: Regenerate. * generated/_cos_c17.F90: Regenerate. * generated/_cos_r17.F90: Regenerate. * generated/_cosh_r17.F90: Regenerate. * generated/_dim_r17.F90: Regenerate. * generated/_exp_c17.F90: Regenerate. * generated/_exp_r17.F90: Regenerate. * generated/_log10_r17.F90: Regenerate. * generated/_log_c17.F90: Regenerate. * generated/_log_r17.F90: Regenerate. * generated/_mod_r17.F90: Regenerate. * generated/_sign_r17.F90: Regenerate. * generated/_sin_c17.F90: Regenerate. * generated/_sin_r17.F90: Regenerate. * generated/_sinh_r17.F90: Regenerate. * generated/_sqrt_c17.F90: Regenerate. * generated/_sqrt_r17.F90: Regenerate. * generated/_tan_r17.F90: Regenerate. * generated/_tanh_r17.F90: Regenerate. * kinds-override.h: Adjust to trunk. Change condition to single line so it can be grepped. * m4/specific.m4: Make sure that real=kind16 is used for _r17.F90 and _c17.F90 files. * m4/specific2.m4: Likewise. * mk-kinds-h.sh: Adjust to trunk. diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am index f3e358368cc..efc79d0d0b7 100644 --- a/libgfortran/Makefile.am +++ b/libgfortran/Makefile.am @@ -1075,15 +1075,16 @@ $(patsubst %.F90,%.lo,$(patsubst %.f90,%.lo,$(notdir $(gfor_specific_src: AM selected_real_kind.lo selected_int_kind.lo: AM_FCFLAGS += -fallow-leading-underscore # Build *_r17.F90 and *_c17.F90 with additional -mabi=ieeelongdouble on powerpc64le-linux. + if HAVE_REAL_17 -$(patsubst %_r17.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_r17.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_c17.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_c17.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_r16.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble -$(patsubst %_r16.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble -$(patsubst %_c16.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble -$(patsubst %_c16.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble +$(patsubst %_r16.F90,%_r16.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble +$(patsubst %_c16.F90,%_c16.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble +$(patsubst %_r17.F90,%_r17.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -D__powerpc64__ +$(patsubst %_c17.F90,%_c17.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -D__powerpc64__ +$(patsubst %_r16.c,%_r16.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ibmlongdouble +$(patsubst %_c16.c,%_c16.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ibmlongdouble +$(patsubst %_r17.c,%_r17.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ieeelongdouble +$(patsubst %_c17.c,%_c17.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ieeelongdouble endif if IEEE_SUPPORT @@ -1154,8 +1155,8 @@ I_M4_DEPS9=$(I_M4_DEPS) m4/ifindloc2.m4 kinds.h: $(srcdir)/mk-kinds-h.sh $(SHELL) $(srcdir)/mk-kinds-h.sh '@LIBGOMP_CHECKED_INT_KINDS@' '@LIBGOMP_CHECKED_REAL_KINDS@' '$(FCCOMPILE)' > $@ || rm $@ -kinds.inc: kinds.h - grep '^#' < kinds.h > $@ +kinds.inc: kinds.h $(srcdir)/kinds-override.h + cat kinds.h $(srcdir)/kinds-override.h | grep '^#' | grep -v include > $@
Re: [power-ieee128] gfortran, v2: Introduce gfc_type_abi_kind
Hi Jakub, Actually playing with that (e.g. for matmul) revealed a brown paper bag bug in the previous patch, fixed thusly: OK. Thanks a lot! Best regards Thomas
Re: [power-ieee128] libgfortran: Small progress on the library side
Hi Jakub, Ok for power-ieee128 branch? OK. Thanks for stepping up! I am a little distracted right now, but I think I will also continue working on this for a bit. Best regards Thomas
Re: [PATCH] Make integer output faster in libgfortran
Hi FX, (We could also do something like that for a 32-bit system, but that is another kettle of fish). We probably wouldn’t get a speed-up that big. Even on 32-bit targets (at least common ones), the 64-bit type and its operations (notably division) are implemented via CPU instructions, not library calls. I'll look at this a bit more closely and report :-) At this point, the output of integers is probably bound by the many layers of indirection of libgfortran's I/O system (which are necessary because of the rich I/O formatting allowed by the standard). There are a few things we could do. Getting a LTO-capable version of libgfortran would be a huge step, because the compiler could then strip out all of these layers. The speed of character:: c write (*,'(A)', advance="no") c could stand some improvement :-) Regards Thomas
Re: [PATCH] Make integer output faster in libgfortran
Hi fX,
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 is already set up to do can fire a quick
regtest, that would be great;)
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.
So, OK for trunk.
(We could also do something like that for a 32-bit system, but
that is another kettle of fish).
Thanks for taking this up!
Best regards
Thomas
Re: [PATCH] Make integer output faster in libgfortran
Hi FX,
The patch has been bootstrapped and regtested on two 64-bit targets:
aarch64-apple-darwin21 (development branch) and x86_64-pc-gnu-linux. I would
like it to be tested on a 32-bit target without 128-bit integer type. Does
someone have access to that?
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}'"
which is the magic incantation to also use -m32 binaries. You'll need
the 32-bit support on your Linux system, of course (which you can
check quickly with a "hello world" kind of program with -m32).
Regards
Thomas
