Re: How to add an additional option to dg-compile and dg-run
Am 29.07.24 um 11:22 schrieb Jonathan Wakely via Gcc: > # If a testcase doesn't have special options, use these. > global DEFAULT_FFLAGS > if ![info exists DEFAULT_FFLAGS] then { > set DEFAULT_FFLAGS " -pedantic-errors" > } I tried using that, still saw a lot of errors when compiling C files. I also tried --- a/gcc/testsuite/gfortran.dg/dg.exp +++ b/gcc/testsuite/gfortran.dg/dg.exp @@ -32,7 +32,7 @@ dg-init global gfortran_test_path global gfortran_aux_module_flags set gfortran_test_path $srcdir/$subdir -set gfortran_aux_module_flags $DEFAULT_FFLAGS +set gfortran_aux_module_flags "-O0" proc dg-compile-aux-modules { args } { global gfortran_test_path global gfortran_aux_module_flags but that also seems to have been the wrong button to press, that also didn't do anything. Anything else to try? I'd really like to set up some sort of regression test to make sure that -funsigned does not break anything else, but right now I'm out of ideas. Best regards Thomas
How to add an additional option to dg-compile and dg-run
Hi, for the fortran-unsigned branch, I would like to be able to run all existing Fortran tests also with -funsigned, to make sure the option does not break anything on existing code. Question is: How? I came as far as $ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned" but that causes testsuite failures because C does not recognize the option. Any other possibilites? Best regards Thomas
Planned Fortran unsigned numbers branch
Hi everybody, now that a proposal for unsigned number inclusion in Fortran has passed the J3 hurdle, https://j3-fortran.org/doc/year/24/24-116.txt , I thought I would put my working hours where my mouth is and try my hand at a testbed implementation for gfortran. I am still grateful to Reinhold that he put this on the DIN list as a suggestion. I will use the text above as a preliminary spec. Of course, there is a chance that the feature may actually not make it into F2028, or that there would be differences, but that is what experimental work is for. As for my motivation, I hate having to drop to C because Fortran lacks a feature :-) Everything will be hidden behind a flag, tentatively called -funsigned, to allow inclusion into the compiler at a later date. The amount of work will be substantial, but not too difficult - mostly copying and modifying what already works for integers Putting the work on a public branch probably works best; I will do so in the next few days. As name, I will use fortran_unsigned, unless somebody has a better idea. As to when this will be finished... I don't know, it could already be somewhat usable before being complete. It is also work that can be split into many relatively small parts, just implementing one feature at a time. Best regards Thomas
Re: [RFC] MAINTAINERS: require a BZ account field
Am 25.06.24 um 21:08 schrieb Arsen Arsenović via Gcc: Richard Biener writes: I'd welcome this - care to create a patch for contrib/gcc-git-customization.sh? Sure - I've attached a partial patch. I didn't find the hook which runs on each push to check commits, so the current patch is minimal. Is that also in the tree? I could try hacking it to check commits. Will this also influence commits to, for example, github?
Re: Updated Sourceware infrastructure plans
Am 18.04.24 um 01:27 schrieb Mark Wielaard: We also should make sure that all generated files (either in git or in the release/snapshot tar balls) can be reliably and reproducibly regenerated. This also helps the (pre-commit) CI buildbots. We already have the autoregen bots for gcc and binutils-gdb. And Christoph has been working on extending the scripts to regenerate more kinds of files. I regenerate auto* files from time to time for libgfortran. Regenerating them has always been very fragile (using --enable-maintainer-mode), and difficult to get right. If there is a better process available to do it the right way is that is documented and easy to use, this will make work easier. If not, it has the potential to stop the work I am planning to contribute in a project that is about a month from starting (and maybe stop the project altogether). Can anybody point me towards the tools that will be the gold standard in the future, and the reproducible way of regenerating them? Best regards Thomas
contrib/reghunt documentation
Hi, is there some sort of concise explanation of how to use the scripts in contrib/reghunt? There is no real documentation for what is in the directory, specifically not how to invoke them, and which directory to invoke them from. I have also not been able to do run the examples from contrib/reghunt/examples, let alone my own regression search.
Re: Test with an lto-build of libgfortran.
Hi Jakub, It is worse than that, usually the LTO format changes e.g. any time any option or parameter is added on a release branch (several times a year) and at other times as well. Hm, that makes LTO not very well suited for libraries... Though, admittedly GCC is the single package that actually could get away with LTO in lib*.a libraries, at least in some packagings (if the static libraries are in gcc specific subdirectories rather than say /usr/lib{,64} or similar and if the packaging of gcc updates both the compiler and corresponding static libraries in a lock-step. Because in that case LTO in there will be always used only by the same snapshot from the release branch and so should be compatible with the LTO in it. Maybe another approach: Instead of storing version-dependent LTO code in the *.a files, we could just store preprocessed C code there, somewhat shortened by removing whitespace, comments and unused declarations (and/or store them in compressed format). This would also allow the something like sanitizers to look into the runtime libraries, and other instrumentation. It would also be a much more extensive project, also involving modifications to the linker. Not sure how realistic that would be. Best regards Thomas
Re: Test with an lto-build of libgfortran.
Hi Toon, During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the possibility (and hazards) of building the run time libraries for various compilers with -flto, enabling an -flto -static linking of programs with the run time library available during link time optimizations. This would be a big win for libgfortran, especially the array functions, knowing that stride==1 can be a _big_ win for optimization. This is why LTO is such an excellent idea for Fortran in general, and for the library in particular. There is a PR on this with quite some discussion already, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 . I've put you in CC of that bug, maybe we can discuss there more in detail. One point about the array functions: In the library, we use sort of a ripple carry algorithm to step through the arrays. This saves space an is general, but the performance (esp for the most common one-and two-dimensional arrays) can suffer. [...] The full question of "lto-ing" run time libraries is more complicated than just "whether it works" as those who attended the BoF will recall. I didn't attend the Cauldron (but that discussion would have been very interesting). I think for libgfortran, a first step would be additional work to get declarations on both sides to agree (which is worth doing anyway). Best regards Thomas
Re: Calling convention for Intel APX extension
Am 27.07.23 um 15:43 schrieb Michael Matz: I've recently submitted a patch that adds some attributes that basically say "these-and-those regs aren't clobbered by this function" (I did them for not clobbered xmm8-15). Something similar could be used for the new GPRs as well. Then it would be a matter of ensuring that the interesting functions are marked with that attributes (and then of course do the necessary call-save/restore). Interesting. Taking this a bit further: The compiler knows which registers it used (and which ones might get clobbered by called functions) and could generate such information automatically and embed it in the assembly file, and the assembler could, in turn, put it into the object file. A linker (or LTO) could then check this and elide save/restore pairs where they are not needed. Now, I know that removing instructions during linking is a dangerous business, and is a source of hard-to-find and rare bugs (the worst kind) if not done right; a bullet-proof algorithm would be needed for that. It would probably be impossible for calls into shared libraries, since the saved registers might change from version to version. It also would probably not work for virtual member functions which are not found by devirtualitzation. Still, potential gains could be substantial, and it could have an effect which could come close to inlining, while actually saving space instead of using extra. Comments?
Calling convention for Intel APX extension
With the upcoming Intel APX extension, Intel processors will finally gain 32 general-purpose registers and three-operand arithmetic, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html Intel recommends to have the new registers as caller-saved for compatibility with current calling conventions. If I understand this correctly, this is required for exception unwinding, but not if the function called is __attribute__((nothrow)). Since Fortran tends to use a lot of registers for its array descriptors, and also tends to call nothrow functions (all Fortran functions, and all Fortran intrinsics, such as sin/cos/etc) a lot, it could profit from making some of the new registers callee-saved, to save some spills at function calls. What are the thoughts on it? Is a modification to the ps-ABI already in the works, and how would it treat this case? 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
Interesting a binary regression search into the compiler
Hi, I'm not sure who on this mailing list reads comp.compilers, but there is an interesting article about built-in regression search in the go compiler at https://compilers.iecc.com/comparch/article/23-05-003 . Using a similar approach could also be interesting for gcc, complementing tools like the regression search and cvise. Best regards Thomas
Re: More C type errors by default for GCC 14
On 13.05.23 02:45, Po Lu via Gcc wrote: Gabriel Ravier writes: ...You're joking, right ? You can't possibly be seriously arguing this, you have to be kidding... right ? No, I'm not. The meaning of a variable declaration with only a storage class specifier is extremely clear: the type of the variable is `int'. C99, 6.7.2, "Type specifiers" # Constraints # At least one type specifier shall be given in the declaration # specifiers in each declaration, and in the specifier-qualifier # list in each struct declaration and type name. There's absolutely nothing ambiguous about it whatsoever: In C99 and onwards, this is an error (a violation of a "shall" directive). register i; extern limit, *k, do_some_computation (); for (i = 0; i < limit; ++i) k[i] = do_some_computation (i); Please try to prove me wrong. Happy to oblige.
Re: More C type errors by default for GCC 14
On 12.05.23 09:53, Eli Zaretskii via Gcc wrote: I described in an earlier message how this breakage looks in real life, and why it causes a lot of frustration. The main problem is discovering that things broke because GCC defaults, and then discovering how to pacify GCC with the least effort. Gcc is quite helpful these days: $ gcc -c example.c example.c:1:1: warning: data definition has no type or storage class 1 | a(); | ^ example.c:1:1: warning: type defaults to 'int' in declaration of 'a' [-Wimplicit-int] $ gcc -Werror -c example.c example.c:1:1: error: data definition has no type or storage class [-Werror] 1 | a(); | ^ example.c:1:1: error: type defaults to 'int' in declaration of 'a' [-Werror=implicit-int] (sorry, cannot show the nice coloring). It tells you right in the error message which option caused the or warning in question. This is not hard. Is your opinion that reading error messages (and making the mental leap of adding the negative, of course) is too much to expect? 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: More C type errors by default for GCC 14
On 10.05.23 14:03, Jakub Jelinek via Gcc wrote: We do such changes several times a year, where we reject something that has been previously accepted in older standards, admittedly mostly in C++. ... and in Fortran.
Re: More C type errors by default for GCC 14
Not replying to anybody in particular, just a bit of history, with some potential parallels. In gfortran, we have had two major issues with interfaces. One was that code which had happily violated the compiler ABI started failing, due to a fix in the gfortran front end which meant that we were no longer mixing varargs and non-varargs calls (which led to code being correctly compiled for POWER which had been miscompiled for basically forewer). Among other things, this broke R, and was fixed by Jakub by applying a workaround. After a few years, people in core libraries like BLAS and Netlib are finally getting around to fixing their code. There is no knowing what codes still have that, so the workaround will probably stay around forever, although we don't promise that it does. Partially motivated by this, we then added a file-level check for argument list mismatches (type and rank), which issued an error. That error could be disabled by a new option, -fallow-argument-mismatch, but that caused problems for people using different versions of the compiler. So we added this option to -std=legacy, which is a catch-all kitchen sink, which accepts some not-so-nice things. Of course, as everybody on this list knows, mixing types like this is dangerous, and is liable to break sooner or later in future compiler release. Nonetheless, even a package like MPICH chose to use autoconf to set the -fallow-argument-mismatch flag rather than fix the code :-( Others, like the LAPACK maintainers, have reacted and installed patches. So... using an error message as a crowbar to change people's behavior failed, at least partially. And you only hear from the people who complain, not from those who are glad that they found errors that they would otherwise have missed. What does that mean for the case at hand? Based on past experience, I'd lean towards putting all the warnings about the special offending codes into one warning option (-Wsevere, or something) which could then be made into an error by -Werror=severe or such variant; maybe other warnings could be grouped in there as well. And if these severe warnings should then be made default or not, well... that (like the rest of my mail) is open for discussion. Best regards Thomas
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: Buildbot (Sourceware): gcc - failed configure (failure) (master)
On 30.01.23 23:07, Gerald Pfeifer wrote: Hmm, so any digit, parenthesis, or bracket in the Subject, and mails gets to /dev/null? Sending mail with special graphics in Subject lines is what spammers do, to attract special attention. (And no, umlauts are not included :-). So, If I ever happen to break bootstrap, I will not learn about it from a mail that uses spammer's techniques. A regular mail, on the other hand, I would read. Regards Thomas
Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)
On 30.01.23 14:52, Mark Wielaard wrote: Hi Steve, On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote: Please remove the skull and cross bones in the subject line. That is the default "hazard symbol" buildbot uses if a build turns from success to failure. If you have a better suggestion you might want to contact upstream https://buildbot.net/ We'll pick up the new default when we'll upgrade. Or if you think we should use a custom email template: https://docs.buildbot.net/latest/manual/configuration/report_generators/formatter.html You can provide a patch to build...@sourceware.org. The code for our instance can be found here: https://sourceware.org/git/builder.git I usually put e-mails with such unicode characters into my spam folder automatically. If that's what you want, that is fine with me. 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: B^HDEAD code generation (AMD64)
On 09.01.23 12:35, Stefan Kanthak wrote: 20 superfluous instructions of the total 102 instructions! The proper place for bug reports is https://gcc.gnu.org/bugzilla/ . Feel free to submit these cases there.
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: testsuite under wine
On 17.12.22 01:26, NightStrike wrote: On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig wrote: On 16.12.22 03:20, NightStrike via Fortran wrote: When I run the testsuite under wine, I'm getting a lot of ANSI escape sequences. We had fixed this long ago, but it seems to be back. Any idea what I should change in my configuration to have this not happen? This should probably be fixed properly in some *.exp file, but you can try setting the GCC_COLORS environment variable to an empty string before running the test. That didn't help. It looks like this is always escape 25h to start the output and 25l to end it, which I think is turning the cursor on and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I apparently fixed this previously by building wine with --without-curses (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that option to wine was removed. Is there a way to hack this on the Deja side to ignore the escapes? Or to tell it to run in a way that makes wine not emit them? Truth is, I don't know. I have included the gcc mailing list in this reply, where more knowledgeable people can be found :-)
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: Inquiry: Country of Origin for gfortran
Hi Cynthia, > Hello, my name is Cynthia and I am a Supply Chain Risk Management > Analyst at NASA. NASA is currently conducting a supply chain > assessment of gfortran. As stated in Sections 208 and 514 of the > Consolidated Appropriations Act, 2022, Public Law 117-103, > enacted March 15, 2022, a required step of our process is to > verify the Country of Origin (CoO) information for the > product (i.e., the country where the products were developed, > manufactured, and assembled.) > As gfortran is open source, we understand that this inquiry is > not directly applicable, as contributions may be made from > individuals from around the world. In this case, NASA is > interested in confirming the following information: > 1. Is there an organization which sponsors/publishes the project, or > a primary developer who audits the code for potential vulnerabilities, > errors, or malicious code? Y/N gfortran is not an independent project, it is part of the Gnu Compiler Collection, https://gcc.gnu.org/ . As such, any evaluation you may already have made of gcc also should also apply to gfortran, and I am also addressing this mail to the gcc mailing list, where it is more appropriate, especially since I personally am unclear about the current relationship with the Free Software Foundation. Regarding gfortran specifically: Code changes are reviewed by the individuals listed in the file https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=MAINTAINERS;hb=HEAD (where you can search for Fortran). > 2. Does gfortran have an overseeing organization or individual > along these lines? Y/N See my previous reply. > 1. If so, please provide the name of the organization and country > they are established in > If the information above is unknown or cannot be provided, we > request that you provide the country or list of countries where > the majority of contributions originate from to satisfy Sections > 208 and 514 of the Consolidated Appropriations Act, 2022, Public > Law 117-103, enacted March 15, 2022. Main contributions to gfortran, i.e. the Fortran front end to gcc and its supporting library, came (in no particular order) from the UK, the US, France, Finland, Germany, the Netherlands and the Czech Republic. Up to 2006, there were also some contributors from China. 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