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

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] 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: [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, 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 de

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

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

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

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 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 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, fortran] PR98565 - internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950

Hi Paul, Regtested on FC33/x86_64 - OK in a few weeks for 9- and 10-branches? Yes, I think this is obvious enough for a backport. Thanks for the patch! Best regards Thomas

Re: [PATCH] PR fortran/70070 - ICE on initializing character data beyond min/max bound

Hi Harald, the attached patch is pretty much self-explaining: check for bounds violation when initializing a substring in a data statement and treat the resulting error. If more detailed information should be emitted with the error message, I'm open for suggestions. Currently, we issue these

Re: [Patch, fortran] PR98573 - Dynamic type lost on assignment

Hi Paul, This is a relatively obvious patch. The chunk in trans-array.c is not part of the fix for the PR but does suppress some of the bad dtype's that arise from allocation of class objects. The part in trans-stmt.c provides vptrs for all class allocations if the expression3 is available. Reg

Re: [PATCH Fortran] Re: PR fortran/93524 - rank >= 3 array stride incorrectly set in CFI_establish

Hi Harris! OK for master? I do not have write access, so someone will need to commit this for me. Reviewed, regression-tested and committed as https://gcc.gnu.org/g:1cdca4261e88f4dc9c3293c6b3c2fff3071ca32b Thanks for your patch, and welcome aboard! Best regards Thomas

Re: [PATCH] [8/9/10/11 Regression] [OOP] PR fortran/86470 - ICE with OpenMP

Hello Harald, OK for master / backports? OK. It is indeed fairly obvious, as you write. Should the testcase be moved to the gomp/ subdirectory? Yes. It's a compile-time test, and it will then only be run if the the compiler can do OpenMP. You will not need the +! { dg-options "-fopenmp"

Re: [Patch] Fortran: Fix Array dependency with local coarrays [PR98913] (was: Re: A question about coarrays and -Warray-temporaries)

Am 02.02.21 um 12:46 schrieb Tobias Burnus: Hi all, the attached patch now handles -fcoarray=single and access to the local image like no coarray access, using the same check a before. Actually, I think we could remove the if (..coarray..) check completely: For 'single', it is like no coarrays;

Re: [patch, libgfortran] PR98825 Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'

Hi Jerry, OK for trunk and backport to 10 since it is simple enough? OK for trunk. Because this is a user-visible change (even if we did the wrong thing before) I don't feel that we should backport (but I am open to suggestions otherwise). Could you also mention this in gcc-11/changes.html

Re: [Patch] Fortran: intrinsic.texi add missing arg to FINDLOC (was: FINDLOC documentation at https://gcc.gnu.org/onlinedocs/gfortran/FINDLOC.html)

Hi Tobias, I intent commit it as obvious, unless there are comments. Just one nit: MASK does not have to be an array, it can also be a scalar. It just has to be conformable. OK with that change. Best regards Thomas

Re: [Patch] Fortran: Fix ubound simplifcation [PR99027]

Hi Tobias, The problem which accessing dim= for an expression is that when the argument is an array, dim= and expr->rank are relative to the resulting array – but the array-ref also contains the DIMEN_ELEMENT which does not count for dim=/rank. OK for the trunk? (Reported against GCC 11, but I

Re: [Patch] Fortran: Fix rank of assumed-rank array [PR99043]

Hi Tobias, OK for mainline? Reported against GCC 10, not a regression but simple wrong-code fix; does it make sense to apply there was well? OK for both. Thanks for the patch! Best regards Thomas

Re: [PATCH 1/7] fortran: new abstract class gfc_dummy_arg

Hi Mikael, Introduce a new abstract class gfc_dummy_arg that provides a common interface to both dummy arguments of user-defined procedures (which have type gfc_formal_arglist) and dummy arguments of intrinsic procedures (which have type gfc_intrinsic_arg). good to see you again! So far, we

Re: [PATCH] PR fortran/97272 - Wrong answer from MAXLOC with character arg

Hi FX, While this is fresh in your memory, could I suggest you have a look at this FINDLOC issue, which seems possibly related: https://gcc.gnu.org/pipermail/fortran/2020-September/055016.html and further messages from Thomas Koenig? I am actually working on this again, having returned from h

Re: [Patch, fortran] PR/97045 A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument

Hi Paul, Regtests on FC31/x86_64 - OK for master? OK. You're quite right that trans-* is chock full of special-case handling (which I also found out, again, working together with Nicolas on the shared memory coarrays). Cleaning that up would be a worthwile job, although probably quite big :

Re: [PATCH] Fortran : ICE in gfc_validate_kind PR96099

Hi Mark, This is a follow up to PR95586 which fixed only the ICE that occurred when using derived types in an implicit statement.  The ICE occurred because an attempt was made to determine kind for types that do not have kinds. This patch ensures that kind is only determined for types that s

Re: [PATCH] PR fortran/97272 - Wrong answer from MAXLOC with character arg

Hello Harald, Slightly rewritten version of the patch, with the removal of the KIND argument from the argument list factored out: OK for master. I think it is also OK for backport as far as you want to. 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

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]

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 t

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

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

[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

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.

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 func

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: *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.htm

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] 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 an

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 l

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

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

Re: [PATCH] PR fortran/101329 - ICE: Invalid expression in gfc_element_size

On 17.11.21 22:28, Harald Anlauf via Fortran wrote: Dear Fortranners, as NULL() is not interoperable, we have to reject it. Confirmed by NAG. Other compilers show "interesting behavior". Obvious patch by Steve. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK, and thanks! Best regard

[patch, power-ieee128, committed] First stab at the library

Hi, here is a first stab at the library side of power-ieee128, committed to the branch. It compiles, but probably still has a lot of issues. It is also not called from the compiler yet. Regards Thomas 2021-10-19 Thomas Koenig Prepare library for REAL(KIND=17). This

Re: [PATCH] PR fortran/103610 - ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

Hi Harald, when simplifying SHAPE(), we rely on spec_dimen_size returning non-negative dimensions. That actually did not happen in all cases, as the testcase by Gerhard shows. (The testcase is rather fallout from the wrong simplification). The solution is trivial: simply check the dimensions

[patch, power-ieee128, committed] Fix pattern for _c17 and _r17

Pushed to the branch. With this patch, the instructions generated are the ones that are expected, for example: $ objdump --disassemble sum_r17.o | grep xsaddqp 3cc: 08 08 00 fc xsaddqp v0,v0,v1 3dc: 08 08 00 fc xsaddqp v0,v0,v1 3ec: 08 08 00 fc xsaddqp v0,v0,v1 410: 08

[pach, power-ieee128, committed] Generate config.h macros for ieee128 functions

Pushed to the branch. Generate config.h macros for IEEE128 math functions. libgfortran/ChangeLog: * acinclude.m4 (LIBGFOR_CHECK_MATH_IEEE128): New macro. * configure.ac: Use it. * config.h.in: Regenerate. * configure: Regenerate. diff --git a/libgfortran/Makefile

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

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]

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

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

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

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 regard

*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: *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 conf

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

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

Re: *PING* Re: [Patch] Fortran: Fix function decl's location [PR95847]

Hi Tobias, *PING* OK. Thanks for the patch! Best regards Thomas

Re: [Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

Hi Paul, This all bootstraps and regtests on FC31/x86_64 - OK for master? This is a sizable patch, and from what I can see, it all looks plausible. So, I's say OK for master (with one nit, below), but maybe you could wait a day or so to give others the chance to look it over, too. The nit:

[patch, fortran] Correct fndecls for some library functions

Hello world, this patch makes sure that we pass the correct fn decls for some of our library functions. cshift and others still remain to be implemented. This is a step in our voyage to stop lying to the middle end :-) Regression-tested. OK for trunk? Best regards Thomas Generate cor

Re: [PATCH, v1] PR fortran/48958 - Add runtime diagnostics for SIZE intrinsic function

Hi Harald, Feedback, such as comments for improvement, are welcome. It feels a bit strange to have a check for an allocatable behind -fcheck=pointer, but I'm not sure that introducing a special check option would really be worth it. Regarding pointers: They are usually not nullified (unless th

Re: [Patch][wwwdocs] gcc-11/changes.html update for OpenMP + !GCC$ attributes + project/libgomp/ omp 5.1 update

Hi Tobias, should the OpenMP news about Fortran be mentioned (also) in the Fortran section? Best regards Thomas

Re: [PATCH] PR fortran/102287 - optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines

Hello Harald, As nicely described in the PR, we mishandled the case of passing optional allocatable DT arguments with allocatable components when the INTENT was declared as INTENT(OUT), as we unconditionally tried to deallocate these components even when the argument was not present. The obviou

Re: [PATCH, Fortran] Fixes for F2018 C838 (PR fortran/101334)

Hi Sandra, This patch fixes some bugs in handling of assumed-rank arguments revealed by the TS29113 testsuite, allowing xfails to be removed from those testcases.  It was previously failing to diagnose an error when passing an assumed-rank argument to a procedure via a non-assumed-rank dummy,

Re: [Patch] Fortran: Add gfc_simple_for_loop aux function

Hi Tobias, This patch adds a useful auxiliary function to generate a loop. Looks good to me (and there are probably quite a few places where this could be useful). Best regards Thomas

Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]

Hi Tobias, OK for mainline? As promised on IRC, here's the review. Maybe you can add a test case which shows that the call to the size intrinsic really does not happen. OK with that. Thanks for the patch! Best regards Thomas

Re: [PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

On 23.09.21 21:47, Harald Anlauf via Fortran wrote: Dear Fortranners, we missed certain intrinsics as being disallowed in constant expressions, which lead to an ICE when these intrinsics were used in a specification expression with an initializer. The intrinsics in question are listed in F2018:

Re: [Patch] Fortran: Fix associated intrinsic with assumed rank [PR101334] [was: [PATCH, Fortran] Fixes for F2018 C838 (PR fortran/101334)]

On 23.09.21 21:13, Tobias Burnus wrote: On 20.09.21 09:58, Tobias Burnus wrote: On 20.09.21 06:01, Sandra Loosemore wrote: This patch fixes some bugs in handling of assumed-rank arguments revealed by the TS29113 testsuite, ... giving a bogus error when passing one as the first argument to the

Re: [PATCH] PR fortran/102520 - [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802

Hi Harald, Gerhard's testcase triggers a NULL pointer dereference during the attempt to expand an invalid constructor. The simple and obvious solution is to catch that case. Regtested on x86_64-pc-linux-gnu. OK for all affected branches? OK. Thanks for the patch! Best regards Tho

Re: [PATCH] Fortran: Silence -Wmaybe-uninitialized warning

Hi Bernhard, gcc/fortran/ChangeLog: * resolve.c (resolve_fl_procedure): Initialize allocatable_or_pointer. Looking at the code, it is clear that this is a false positive, or a false maybe, but the semantics of C/C++ may well indicate that sym->result could change, although i

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

Hi Manfred, In addition to the patches of Steve Kargl for PR 91497: The MIN1 and MAX1 intrinsics do explicit type conversions and should be silenced too for -Wconversion and -Wconversion-extra. Adjust testcase to only use *4 and *8 real types, provide a second testcase for *10 and *16 precision

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

On 02.11.21 15:22, Manfred Schwarb wrote: Am 02.11.21 um 14:26 schrieb Thomas Koenig: Hi Manfred, In addition to the patches of Steve Kargl for PR 91497: The MIN1 and MAX1 intrinsics do explicit type conversions and should be silenced too for -Wconversion and -Wconversion-extra. Adjust testca

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

Hi Manfred, looks good to me. Thanks for the patch! Best regards Thomas

[patch, fortran, wwwdocs] Fix name of argument to CO_REDUCE

Hello world, the attached patches fix the name of the function argument to CO_REDUCE to conform to Fortran 2018 instead of the TR. This is a user-visible change, so I have put this both into changes.html and porting_to.html. Regression-tested. OK for trunk? Best regards Thomas Autho

Re: [PATCH] PR fortran/103217 & 103218 - ICEs during simplification after r12-4967-gbcf3728abe848888

Hi Harald, I'd like to commit the attached patch as obvious within the next 24 hours unless anybody objects, or earlier if there is positive feedback. OK with a ChangeLog entry and the correct PR numbers (I believe they are 103137 and 103138) :-) Best regards Thomas

Re: [PATCH v3 0/5] fortran: Ignore unused arguments for scalarisation [PR97896]

Hi Mikael, Regression-tested on x86_64-linux-gnu. Ok for master? This looks quite good, and is (I think) a cleaner version than what we had before. OK. Thanks a lot for the patch(es)! Best regards Thomas

Re: [PATCH 0/2] fortran: Ignore unused arguments for scalarisation [PR97896]

On 07.11.21 17:17, Mikael Morin via Fortran wrote: Regression-tested on x86_64-linux-gnu. Ok for master and 11 branch? OK. Just one remark: Since just reverting my old patch would introduce a regression for that one revision, please squash the patches before committing. Thanks a lot for th

Re: [PATCH] PR fortran/102717 - ICE in gfc_simplify_reshape, at fortran/simplify.c:6843

H Harald, when simplifying RESHAPE we hit a gcc_assert for negative entries in the SHAPE array. Obvious solution: replace gcc_assert by an error message. Regtested on x86_64-pc-linux-gnu. OK for mainline? As this is a safe fix, I'd like to backport to suitable branches. OK for both. Thank

Re: [PATCH] PR fortran/102716 - ICE in gfc_validate_kind(): Got bad kind

Hi Harald, another simple and obvious fix: we need to reorder the argument checks to the SHAPE intrinsic so that invalid KIND arguments can be detected. Regtested on x86_64-pc-linux-gnu. OK for mainline? As I consider this a safe fix, I'd like to backport to suitable branches. Also OK for b

Re: [PATCH][WIP] Add install-dvi Makefile targets

Hi Eric, Hi, I have updated this patch and tested it with more languages now; I can now confirm that it works with ada, d, and fortran now. The only languages that remain untested now are go (since I'm building on darwin and go doesn't build on darwin anyways, as per bug 46986) and jit (which I

Re: [wwwdocs, committed] GCC 12: Add release note for Fortran TS29113 improvements

Hi Sandra, I've checked in the attached patch to announce the cleanup project that Tobias and I have been working on over the last several months in the GCC 12 release notes.  I also updated the page for TS29113 on the GCC wiki to reflect that anything that still doesn't work ought to be cons

Re: [PATCH, Fortran] Add testcase for PR100906

Hi Sandra, PR100906 ("Bind(c): failure handling character with len/=1") has been fixed by Tobias's rewrite of the GFC <-> C descriptor conversions.  I'd like to add José's testcase for that issue before closing it.  OK? OK. I think adding undisputed passing test cases from PRs for somethin

Re: [PATCH,Fortran 1/7] Fortran: make some trans* functions static

Hi Bernhard, what you're doing seems a useful clean-up, thanks. One point for discussion: -match +static match gfc_match_label (void) I have generally understood that the gfc_ prefix is for global variables and functions only. We do not always adhere to it (also since some global functi

[patch, fortran] Fix PR 100227, write with implied DO loop

Hello world, after a bit of an absence, I am now back, at least for some regression fixing (and for reviewing patches, if that is called for). So, here's a regression fix to start with. OK for trunk and affected branches (down to 9)? Best regards Thomas Do not replace variable op var

Re: [patch, fortran] Fix PR 100227, write with implied DO loop

Hi Jerry, Looks OK Thomas, Good for backport as well. Thanks. Committed to trunk so far, will add a git worktree for gcc11 next :-) Best regards Thomas

Re: [PATCH] PR fortran/100949 - [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975

Hi Harald, we rather shouldn't consider a presence check for a non-dummy variable. Regtested on x86_64-pc-linux-gnu. OK for all affected branches? OK for all. Thanks for the patch! Best regards Thomas

Re: [PATCH, Fortran] Bind(c): CFI_signed_char is not a Fortran character type

Hi Sandra, The part of the patch to add tests for this goes on top of my base TS29113 testsuite patch, which hasn't been reviewed or committed yet. It is my understanding that it is not gcc policy to add xfailed test cases for things that do not yet work. Rather, xfail is for tests that late

Re: Pushing XFAILed test cases

On 16.07.21 20:22, Sandra Loosemore wrote: So it seems to me rather surprising to take the position that we should not be committing any new test cases that need to be XFAILed It is what I was told in no uncertain terms some years ago, which is where my current state of knowledge comes from. S

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

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

  1   2   3   4   >