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

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

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),

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

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

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

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

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,

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

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

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

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

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

[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

[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 ---

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

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

[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

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

[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

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

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

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

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

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

Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)

Hi Richard, There is no reliable way to get this correct at the moment and if there were good and easy ways to get this working they'd be implemented already. OK, I then withdraw the patch (and have unassigned myself from the PR). Best regards Thomas

Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)

Hi Richard, Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran : Hi Thomas, Following your off-line explanation that the seemingly empty looking assembly line forces an effective reload from memory, all is now clear. It’s not a full fix (for register vars) and it’s ‚superior‘

[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

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

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:

[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

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

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

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

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

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

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

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?

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

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

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

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

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 \

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!

[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 @@

[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.

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

*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

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

[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

[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

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

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

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

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"

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

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

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

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

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

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

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

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

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

[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

[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

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

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

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

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

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

Re: [power-ieee128] OPEN CONV

On 07.01.22 10:22, Jakub Jelinek wrote: On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote: On 06.01.22 06:00, Michael Meissner via Fortran wrote: What is still missing is the conversion for unformatted I/O, both ways. I'll start doing some stuff on it. Just one question: What

Re: [power-ieee128] RFH: LTO broken

On 06.01.22 06:00, Michael Meissner via Fortran wrote: I pushed the patch to the branch. Test results are looking quite good right now. What is still missing is the conversion for unformatted I/O, both ways. I'll start doing some stuff on it. Just one question: What are functions that I

Re: [power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes

Hi Jakub, This test FAILs because f951: Error: '-mabi=ieeelongdouble' requires full ISA 2.06 support compiler exited with status 1 FAIL: gfortran.dg/pr47614.f -O0 (test for excess errors) As powerpc64le* only supports -mcpu=power8 and newer, I think we shouldn't be testing with that

Re: [power-ieee128] fortran, libgfortran: Add remaining missing *_r17 symbols

Hi Jakub, Following patch adds remaining missing *_r17 entrypoints, so that we have 91 *_r16 and 91 *_r17 entrypoints (and 24 *_c16 and 24 *_c17). This fixes: FAIL: gfortran.dg/dec_math.f90 -O0 execution test FAIL: gfortran.dg/dec_math.f90 -O1 execution test FAIL:

Re: [power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes

On 04.01.22 15:23, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? Also OK. Best regards Thomas

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix

On 04.01.22 14:41, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? OK.

Re: [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O

Hi Jakub, clearly there is still work to fix (but seems e.g. most of the lto tests are related to the gnu attributes stuff:( ). This is looking better than what I expected. Apart from LTO, I expect that a couple of files still do not have the correct flags set when compiling, or maybe some

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

On 03.01.22 17:26, Jakub Jelinek wrote: so we could similarly have something like: #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; #endif ... #if

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

Hi Jakub, So, either we'd need to add e.g. preprocessing support for gfortran.map or some other way how to make certain symbols appear conditionally at different symbol versions, or another option would be to choose different symbol names for those for the powerpc64le-linux cases

Re: [power-ieee128] libquadmath: Use -mno-gnu-attribute in libquadmath

On 03.01.22 16:24, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? OK. Thanks! Best regards Thomas

Re: [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran

Hi Jakub, On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote: The idea behind this is that libstdc++ is written such that it can handle both IBM extended and IEEE quad long double, so its object files are compatible with both. Now tested on powerpc64le-linux (and together with the

[patch, power-ieee128, committed] Make the library functions compile correctly

Hello world, the attached patch lets the library compile correctly, as far as I have been able to determine. Committed to the branch. Best regards Thomas Make sure the Fortran specifics have real(kind=16). This brings the library to compile with all specific functions. It also

Re: [power-ieee128] gfortran, v2: Introduce gfc_type_abi_kind

Hi Jakub, Actually playing with that (e.g. for matmul) revealed a brown paper bag bug in the previous patch, fixed thusly: OK. Thanks a lot! Best regards Thomas

Re: [power-ieee128] libgfortran: Small progress on the library side

Hi Jakub, Ok for power-ieee128 branch? OK. Thanks for stepping up! I am a little distracted right now, but I think I will also continue working on this for a bit. Best regards Thomas

Re: [PATCH] Make integer output faster in libgfortran

Hi FX, (We could also do something like that for a 32-bit system, but that is another kettle of fish). We probably wouldn’t get a speed-up that big. Even on 32-bit targets (at least common ones), the 64-bit type and its operations (notably division) are implemented via CPU instructions, not

Re: [PATCH] Make integer output faster in libgfortran

Hi fX, right now I don’t have a Linux system with 32-bit support. I’ll see how I can connect to gcc45, but if someone who is already set up to do can fire a quick regtest, that would be great;) I tested this on x86_64-pc-linux-gnu with make -k -j8 check-fortran

Re: [PATCH] Make integer output faster in libgfortran

Hi FX, The patch has been bootstrapped and regtested on two 64-bit targets: aarch64-apple-darwin21 (development branch) and x86_64-pc-gnu-linux. I would like it to be tested on a 32-bit target without 128-bit integer type. Does someone have access to that? There are two possibilities:

Re: [PATCH] Simplify integer output-related functions in libgfortran

First merry Christmas to all! Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? OK. Thanks for the (preliminary) patch!

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

Hi FX, I’m not opposed, but I’d really like to get this into the current branch. It is a much less invasive change than the power-ieee128 work. The only case I changed is the case where there is a kind 16, and there is a long double, but the long double is neither kind 10 neither kind 16.

Re: [patch, Fortran] IEEE support for aarch64-apple-darwin

Hi FX, Since support for target aarch64-apple-darwin has been submitted for review, it’s time to submit the Fortran part, i.e. enabling IEEE support on that target. The patch has been in use now for several months, in a developer branch shipped by some distros on macOS (including

  1   2   3   4   >