Re: [PATCH] libfortran: fix conversion of UNSIGNED(kind=16) to decimal in output [PR118406]

Hello Harald, the conversion of (unsigned) integers to decimal in output was designed to be efficient up to INTEGER(kind=16) and did not handle values larger than roughly (10^19 * 2^64). The attached obvious patch fixes this. Regtested on x86_64-pc-linux-gnu.  OK for mainline? OK. Thanks a

Re: PING **(6./7.): [patch, Fortran] -fc-prototypes fixes.

Am 16.01.25 um 01:50 schrieb Jerry D: Yes I think this is OK, a definite improvement. Committed as r15-6967. Thanks for the review! Best regards Thomas

PING **(6./7.): [patch, Fortran] -fc-prototypes fixes.

Am 09.01.25 um 14:36 schrieb Thomas Koenig: Am 09.01.25 um 14:34 schrieb Thomas Koenig: This patch fixes and reorganizes dumping C prototypes. And here is the "five seconds later, I realized I had forgotten to attach the patch" e-mail... ... with the original text: Hello world,

Re: [patch, fortran] Dump all symbol attributes with -fdump-fortran-original

Hi Harald, there is one irregularity here (partial lower case instead of consistently upper case: +  if (attr->oacc_declare_copyin) +    fputs (" OACC-DECLARE-copyin", dumpfile); Otherwise this is OK. Thanks for catching this! Committed with the fix as r15-6840-gf4fa0b7d493a4ba217d989d3df75

[patch, fortran] Dump all symbol attributes with -fdump-fortran-original

Hell world, after finding that an attribute I was looking for was not in the -fdump-fortran-original dump, I started putting in attributes and didn't stop until I had them all (or so I hope :-) It should be easier to read than looking at the symbol attributes in a debugging session, and could ho

[patch, fortran, committed] Fix union member access

-g40754a3b9bef83bf4da0675fcb378e8cd1675602 . Best regards Thomas Author: Thomas Koenig Date: Sun Jan 12 13:05:25 2025 +0100 Fix union member access for EXEC_INQUIRE. gcc/fortran/ChangeLog: PR fortran/118432 * frontend-passes.cc (doloop_code): Select correct member

Re: [PATCH, v2] Fortran: implement F2018 intrinsic OUT_OF_RANGE [PR115788]

Hi Harald, Thanks for pointing this out!  I've also added a few gcc_unreachable() to prevent other potential false positives, see attached. Just a couple of documentation nits: The documentation says INTEGER or REAL only, but it also works (as an extension) for UNSIGNED. Also, OUT_OF_RANGE is

Re: [PATCH] Fortran: implement F2018 intrinsic OUT_OF_RANGE [PR115788]

Hello Harald, Regtested on x86_64-pc-linux-gnu. OK for mainline? I just started to run a bootstrap on cfarm120 (because it is the only machine I can lay my hands on where I can run "make -j128" without disturbing anybody :-) and I got ../../trunk/gcc/fortran/trans-intrinsic.cc: In function ‘

Re: [Patch] Fortran: Fix location_t in gfc_get_extern_function_decl; support 'omp dispatch interop'

Hi Tobias, Comments, remarks, suggestions? I assume you regression-tested (you didn't say). Otherwise, I regard the common Fortran code as obvious - and the OpenMP part covered by my (co)maintainership. Regarding the Fortran part: - fndecl = build_decl (input_location, + fndecl = build_

Re: [patch, Fortran] -fc-prototypes fixes.

Am 09.01.25 um 14:45 schrieb Andre Vehreschild: You forgot to add the patch! Sent two minutes later :-) https://gcc.gnu.org/pipermail/fortran/2025-January/061540.html

Re: [patch, Fortran] -fc-prototypes fixes.

Am 09.01.25 um 14:34 schrieb Thomas Koenig: This patch fixes and reorganizes dumping C prototypes. And here is the "five seconds later, I realized I had forgotten to attach the patch" e-mail... diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc index 8

[patch, Fortran] -fc-prototypes fixes.

Hello world, This patch fixes and reorganizes dumping C prototypes. It makes the following changes: - BIND(C) types are now always output before any global symbols - CFI_cdesc_t is issued for assumed shape and assumed rank arguments. - BIND(C,NAME="...") entities were no

Re: [PATCH] fortran: Bump MOD_VERSION to "16" [PR118337]

Am 08.01.25 um 19:18 schrieb Steve Kargl: While working on f_c_string(), it never occurred to me that the version number should have been bumped. Thanks for the sleuthing you've done so far. Same for me! Best regards Thomas

[patch, doc, Fortran] Further documentation of UNSIGNED

Hello world, the attached patch does what it says in the ChangeLog entry. Tested with "make dvi" and "make pdf". OK for trunk? Best regards Thomas Document unsigned constants in intrinsic modules. gcc/fortran/ChangeLog: * intrinsic.texi (ISO_FORTRAN_ENV): Also

[patch, Fortran, doc] Mention generating C prototypes from Fortran

Hello world, I noticed that there is no mention of automatically generating C prototypes and declarations in the relevant section of the docs, "Interoperability with C". This patch remedies that. OK for trunk? Best regards Thomas gcc/fortran/ChangeLog: * gfortran.texi: New su

[patch, wwwdocs, committed] Fix link to unsigned integers

Hello world, a change in the section heading of the documentation broke a link in gcc-15/changes.html, fixed with this patch. Best regards Thomas Author: Thomas Koenig Date: Fri Nov 29 07:19:36 2024 +0100 Correct link to unsigned integers for Fortran. * htdocs/gcc

Re: [libgfortran, patch] PR88052 Format contravening constraint C1002 permitted

Hi Jerry, I had originally created this patch in 2018 and we did not get back to it. This results in more restrictive runtime behavior. I will go through the front-end code with another patch to catch this at compile time. Changelog and new test case. See attached patch. OK for trunk Yes, O

Re: [Patch, fortran] PR109066 - Segfault when using defined assignment

Hi Paul, This is a particularly straightforward, going on 'obvious',  patch. The bug goes back to at least gcc-6.4.1. OK for mainline and, after a week or two, to 13- and 14-branches? As you say, this one is straightforward. OK for trunk and as far back as you care to backport. Thanks for

[patch, fortran, doc, committed] Mention that SELECT CASE works for unsigned

Hello world, I just committed the attached documentatin patch as obvious, in r15-5344-gbf00f117eb4b5527592029e39a3d79f2048745d8 . Best regards Thomas Document that SELECT CASE works for unsigned. gcc/fortran/ChangeLog: * gfortran.texi: Document that SELECT CASE works for UNSI

[patch, Fortran, committed] Handle unsigned constants in modules

Hello world, Steve found a test case where unsigned constants were not handled in a module. Single-line patch committed as obvious and simple, r15-5341-g66096151afc6631f8f2a3458b154c5daa822b963 . Best regards Thomas Handle unsigned constants for module I/O. gcc/fortran/ChangeLog:

Re: [patch, Fortran] Reject UNSIGNED for COMPLEX

Am 10.11.24 um 21:54 schrieb Harald Anlauf: Hi Thomas, the patch is basically fine. I am wondering if we should create a new helper function that is the opposite of type_check ("type_cannot_be"), so that we avoid redundant code at the source level.  It may not be worth it yet, so your choice.

[patch, Fortran] Reject UNSIGNED for COMPLEX

Hello world, the attached patch rejects UNSIGNED arguments for the COMPLEX function, which is an extension. It also documents CMPLX, INT and REAL as taking UNSIGNED arguments. Regression-tested. OK for trunk? Best regards Thomas gcc/fortran/ChangeLog: * check.cc (gfc_check_c

Re: [patch, Fortran] Introduce unsigned versions of MASKL and MASKR

Ping **(5./7.) ? MASKR and MASKL are obvious candidates for unsigned, too; in the previous version of the doc patch, I had promised that these would take unsigned arguments in the future. What I had in mind was they could take an unsigned argument and return an unsigned result. Thinking about t

[patch, Fortran] Fix -mod(unsigned, unsigned)

Hello world, during testing, I noticed that parameters of the form - mod(u1,u2) were rejected with an unknown type. The fix is straightforward, but required an adjustment to another test case. Regression-tested. OK for trunk? gcc/fortran/ChangeLog: * resolve.cc (resolve_operator): Als

[patch, Fortran] Introduce unsigned versions of MASKL and MASKR

Hello world, MASKR and MASKL are obvious candidates for unsigned, too; in the previous version of the doc patch, I had promised that these would take unsigned arguments in the future. What I had in mind was they could take an unsigned argument and return an unsigned result. Thinking about this a

Re: [pushed] doc, fortran: Add a missing menu item.

Am 27.10.24 um 00:15 schrieb Iain Sandoe: Tested on x86_64-darwin21 and linux, with makeinfo 6.7 pushed to trunk, thanks Thanks! For the record, makeinfo 6.8 did not show this as an error. Best regards Thomas

Re: [patch, Fortran, doc] Update descriptions for UNSIGNED

Am 26.10.24 um 22:10 schrieb Iain Sandoe: Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143). This seems to have broken —enable-languages=all bootstrap with /src-local/gcc-master/gcc/fortran/intrinsic.texi:39: node `Intrinsic Procedures' lacks menu item for `UINT' despite being its Up target

Re: [patch, Fortran, doc] Update descriptions for UNSIGNED

Hi Steve, OK for trunk? OK, but see below. Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143). Thanks for the proof-reading! Best regards Thomas

[patch, Fortran, doc] Update descriptions for UNSIGNED

Hello world, the attached patch adds documentation for the long list of intrinsics which take UNSIGNED arguments. Checked with "make html", "make pdf" and "make info". gcc/fortran/ChangeLog: * gfortran.texi: Correct reference to make clear that UNSIGNED will not be part of F202Y

[patch, fortran] Fix UNSIGNED ICE on matchting

Hello world, I have just committed the attached patch as obvious - just recognize that an UNSIGNED is an error in a complex part. Fix an ICE with UNSIGNED in match_sym_complex_part. gcc/fortran/ChangeLog: PR fortran/117225 * primary.cc (match_sym_complex_part): An UNSIGNED in

[patch, fortran] Fix ICE with use of INT32 et al from ISO_FORTRAN_ENV

Hello world, The attached patch fixes an ICE when an UNSIGNED-specific constant is used from ISO_FORTRAN_ENV. The error message is not particularly great, it is Error: Unsigned: The symbol 'uint32', referenced at (1), is not in the selected standard but it is better than an ICE. OK for trun

Re: [patch, Fortran] Unsigned constants for ISO_FORTRAN_ENV and ISO_C_BINDING

Hi Jerry, the attached patch implements the constants for UNSIGNED for ISO_FORTRAN_ENV and ISO_C_BINDING.  With this, the implementation of UNSIGNED for gfortran should be complete, modulo bugs, of course. OK for trunk? Looks good to go Thomas. Committed, thanks for the review! Actually, t

[patch, Fortran] Unsigned constants for ISO_FORTRAN_ENV and ISO_C_BINDING

Hello world, the attached patch implements the constants for UNSIGNED for ISO_FORTRAN_ENV and ISO_C_BINDING. With this, the implementation of UNSIGNED for gfortran should be complete, modulo bugs, of course. OK for trunk? Best regards Thomas gcc/fortran/ChangeLog: * dump-par

Re: [Patch] Fortran: Unify gfc_get_location handling; fix expr->ts bug

Hi Tobias, This unifies the two locus to location_t conversion functions, preparing for some changes I want to do later. In principle, I had the patch this morning; however, the assert is now exercised more often than before - and it triggered rather unexpected when running the testsuite.

Re: [patch, Fortran, RFC] Introduce GFC_STD_UNSIGNED

Am 11.10.24 um 18:00 schrieb Thomas Koenig: Hello world, the attached patch creates an unsigned "standard" for the gfc_option.allow_std field. One of the main reason why people want UNSIGNED for Fortran is interfacing for C. This is a preparation for further work on the ISO

[patch, Fortran, RFC] Introduce GFC_STD_UNSIGNED

Hello world, the attached patch creates an unsigned "standard" for the gfc_option.allow_std field. One of the main reason why people want UNSIGNED for Fortran is interfacing for C. This is a preparation for further work on the ISO_C_BINDING constants. That, we do via iso-c-binding.def , whose l

Fwd: [patch, fortran] Implement maxloc and minloc for unsigned

] Implement maxloc and minloc for unsigned Datum: Fri, 4 Oct 2024 09:54:37 +0200 Von: Thomas Koenig An: fort...@gcc.gnu.org , gcc-patches Hello world, please find attached the patch for implementing MAXLOC and MINLOC for unsigned. The patch is rather lengthy, but mostly due to combinatorial

[patch, Fortran] FINDLOC for unsigned

.texi: Include FINDLOC in unsigned documentation. * iresolve.cc (gfc_resolve_findloc): Use INTEGER version for UNSIGNED. gcc/testsuite/ChangeLog: * gfortran.dg/unsigned_33.f90: New test.From 864071a00f886ae2115d6dfa5d286c84e67360f6 Mon Sep 17 00:00:00 2001 From: Thomas Koenig

[patch, Fortran] CSHIFT and EOSHIFT for unsigned

00:00:00 2001 From: Thomas Koenig Date: Thu, 26 Sep 2024 21:46:55 +0200 Subject: [PATCH] Implement CSHIFT and EOSHIFT for unsigned. gcc/fortran/ChangeLog: * check.cc (gfc_check_eoshift): Handle BT_UNSIGNED. * simplify.cc (gfc_simplify_eoshift): Likewise. * gfortran.texi: Document CSHIFT and

Re: Fwd: [patch, fortran] Matmul and dot_product for unsigned

Hi Mikael, Now for the remaining intrinsics (FINDLOC, MAXLOC, MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing). I have one patch series touching (inline) MINLOC and MAXLOC to post in the coming days.  Could you please keep away from them for one more week or two? Looking at the pre

Fwd: [patch, fortran] Matmul and dot_product for unsigned

after that, C interop, one of the main reasons this was requested. I have also committed, right now, a fix for the failure of unsigned_25.f90 on 32-bit systems as obvious. Best regards Thomas Author: Thomas Koenig Date: Wed Sep 25 18:51:48 2024 +0200 Fix testsuite failure on 32

Re: [Patch, fortran] PR116733: Generic processing of assumed rank objects (f202y)

Am 23.09.24 um 11:02 schrieb Paul Richard Thomas: Hi All, The moment I saw the DIN4 proposal for "Generic processing of assumed rank objects", I thought that this was a highly intuitive and implementable proposal. I implemented a test version in June and had some correspondence with Reinhold

Re: [patch, fortran] Matmul and dot_product for unsigned

Hello Andre and everybody else? Any more comments on the matmul patch? The other ones depend on it, so I would like to commit (unless there are further questions, of course). Best regards Thomas

Re: [patch, fortran] Add random numbers and fix some bugs.

22:15 +0200 Thomas Koenig wrote: This patch adds random number support for UNSIGNED, plus fixes two bugs, with array I/O where the type used to be set to BT_INTEGER, and for division with the divisor being a constant. Again, depends on prevous submissions. OK for trunk? gcc/fortran/Chan

Re: [Patch, Fortran] Implement Unsigned for SUM and PRODUCT

Am 19.09.24 um 11:55 schrieb Andre Vehreschild: Hi Thomas, thanks for the patch. I have one proposal/question and one missing verb (IMO). Else the patch looks fine to me. Ok for trunk. diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index 829ab00c665..e5ffe67 100644 ---

[patch, fortran] Add random numbers and fix some bugs.

This patch adds random number support for UNSIGNED, plus fixes two bugs, with array I/O where the type used to be set to BT_INTEGER, and for division with the divisor being a constant. Again, depends on prevous submissions. OK for trunk? gcc/fortran/ChangeLog: * check.cc (gfc_check_ran

[patch, fortran] Implement IANY, IALL and IPARITY for unsigned

OK for trunk? This is based on the previous submissions. Again, this does not generate a new library version; rather it re-uses the signed integer version already present in the library. OK for trunk? Previous submissions (without which this will not work): https://gcc.gnu.org/pipermail/fortra

Re: [Fortran, Patch, PR106606, v1] Fortran: Break recursion building recursive types. [PR106606]

Hi Andre, Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Extremely minor nit: In the commit message and ChangeLog entry, Build a derived type component's type only, when it is not already being build and the component uses pointer semantics. I believe that should be "being

Re: [Ping, Fortran, Patch, PR85002, v1] Fix deep-copy of alloc. comps. in coarrays ICEing and crashing w/ lib.

Am 18.09.24 um 12:31 schrieb Andre Vehreschild: Regtested ok on x86_64-pc-linux-gnu / F39. Ok for mainline? OK. Thanks for the patch! Best regards Thomas

Re: [Patch, Fortran] Implement Unsigned for SUM and PRODUCT

As Jerry wrote (thanks!), this was missing the attached patch. Best regards Thomasdiff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index 829ab00c665..e5ffe67 100644 --- a/gcc/fortran/gfortran.texi +++ b/gcc/fortran/gfortran.texi @@ -2788,7 +2788,7 @@ As of now, the

[Patch, Fortran] Implement Unsigned for SUM and PRODUCT

Hello world, this implements SUM and PRODUCT for UNSIGNED. This is actually missing from 24-116.txt, but that is due to an oversight. This patch is on top of https://gcc.gnu.org/pipermail/fortran/2024-September/060975.html and uses the same method suggested by Richard: Use unsigned for the dat

[patch, teststuite, Fortran, committed] Fix endianness issue on test case

Author: Thomas Koenig Date: Fri Sep 13 07:47:24 2024 +0200 Fix endianness issue on unsigned_21.f90. gcc/testsuite/ChangeLog: PR fortran/116653 * gfortran.dg/unsigned_21.f90: * gfortran.dg/unsigned_21_be.f90: New test. diff --git a/gcc/testsuite

[patch, fortran, committed] module support for UNSIGNED

Hello world, I just pushed Steve's patch for module support to trunk as obvious, as https://gcc.gnu.org/g:2847a541c1f19b67ae84be8d0f6dc8e1f9371d16 . Best regards Thomas gcc/fortran/ChangeLog: * module.cc (bt_types): Add BT_UNSIGNED. gcc/testsuite/ChangeLog: * gfortra

Re: [patch, fortran] Matmul and dot_product for unsigned

Am 09.09.24 um 20:01 schrieb Richard Biener: But it will require some ugly m4 hackery... I'll take a look if I can make it work. > I meant you shouldn’t need new library entry points for unsigned > but simply call the signed ones (and switch the signed implementation > to use unsigned arithmet

Re: [patch, fortran] Matmul and dot_product for unsigned

Am 09.09.24 um 09:19 schrieb Richard Biener: Is the library implementation in any way different from the signed one? Iff only multiplication and addition/subtraction are involved the unsigned implementation could implement both variants (the signed one would eventually cause undefinedness with r

[patch, fortran] Matmul and dot_product for unsigned

Hello world, like the subject says. The patch is gzipped because it is large; it contains multiple MATMUL library implementations. OK for trunk? Implement MATMUL and DOT_PRODUCT for unsgigned. gcc/fortran/ChangeLog: * arith.cc (gfc_arith_uminus): Fix warning. (gfc_arith_minus)

Re: New version of unsiged patch

Am 06.09.24 um 20:58 schrieb Steve Kargl: Your testcases are all free source form. In fixed form, gfortran would need to deal with 'u = 1 2 3 4 u _8' I don't have the patch in my tree at the moment, it isn't clear to me if the matcher for an unsigned constant is prepared to deal with space betwe

Re: New version of unsiged patch

Am 06.09.24 um 20:15 schrieb Steve Kargl: +Generally, unsigned integers are only permitted as data in intrinsics. Does the word 'intrinsics' apply to 'intrinsic operators' or 'intrinsic subprograms' or both? This might benefit from a big of wordiness. You're right, that wasn't clear at all.

Re: New version of unsiged patch

Ping (a little bit)? With another weekend coming up, I would have some time to work on incorporating any feedback, or on putting in more intrinsics. Best regards Thomas

Re: New version of unsiged patch

Steve, On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote: this version of the patch includes DOT_PRODUCT, MATMUL and quite a few improvements for simplification. Thomas, Your updated patch applied cleanly on top-of-tree gcc. Bootstrap and regression testing on amd64-*-freebsd

Re: [Fortran, Patch, PR116292, v1] Fix 15-regression in move_alloc

Hi Andre, attached patch fixes a regression introduced by my previous patch on handling _vptr's more consistently. The patch gets the _vptr only of a derived or class type now and not of every type. Regression tested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? OK (and looks obviou

Re: [PATCH 0/8] fortran: Inline MINLOC/MAXLOC without DIM argument [PR90608]

Am 08.08.24 um 11:09 schrieb Mikael Morin: As we are not planning to remove the library implementation (-Os!), this is also the best way to compare library to inline code. This makes perfect sense, but why reuse the -ffrontend-optimize option? The manual describes it as: This option performs f

Re: [PATCH 0/8] fortran: Inline MINLOC/MAXLOC without DIM argument [PR90608]

Hi Mikael and Harald, - inline expansion is inhibited at -Os.  But wouldn't it be good if   we make this expansion also dependent on -ffrontend-optimize?   (This was the case for rank-1 before your patch). The original idea was to have -ffrontend-optimize as a check if anything went wrong wi

Re: [PATCH] fortran: Support optional dummy as BACK argument of MINLOC/MAXLOC.

Hi Mikael, +  gcc_assert (backexpr->expr_type == EXPR_VARIABLE); drop it, downgrade to checking, or is it worth? Whether it is worth it, I don't know; it's protecting the access to backexpr->symtree a few lines down, idependently of the implementation of maybe_absent_optional_variable.

Re: Fortran: Use non conflicting file extensions for intermediates [PR81615]

Replying to myself... I think this also desevers a mention in changes.html.  Here is something that I came up with.  OK? Or does anybody have suggestions for a better wording? Or maybe this is better: diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 4b83037a..d232f

Re: Fortran: Use non conflicting file extensions for intermediates [PR81615]

Hi Rimvydas, Documentation part. The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings. Thanks for your work on this! I think this also desevers a mention in changes.html. Here is something that I came up with. OK? Or does anybody have suggestions for a better wordin

Re: [PATCH v4] libgfortran: Replace mutex with rwlock

Hi Lipeng, Sure, as your comments, in the patch V6, I added 3 test cases with OpenMP to test different cases in concurrency respectively: 1. find and create unit very frequently to stress read lock and write lock. 2. only access the unit which exist in cache to stress read lock. 3. access the sa

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 ext

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 ena

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 RE

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 descri

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 seri

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 dan

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

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 w

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

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 T

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

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 on

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

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

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 funct

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

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

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 -Wmaybe-uninitial

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 h

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 at

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‘ t

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

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

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: th

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

  1   2   3   4   5   6   7   8   9   10   >