Re: [PATCH] Fortran: improve diagnostic message for COMMON with automatic object [PR32986]
On Wed, Aug 23, 2023 at 09:16:08PM +0200, Harald Anlauf via Fortran wrote: > > here's a simple patch for a very old PR that suggests a more helpful > error message for an automatic object in a COMMON. The patch also > suppresses the less helpful old error message after the new one has > been emitted. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > OK. I leave the decision on backporting to you. -- Steve
Re: beta gfortran 14.x.y (using -march=native and intrinsic repeat) gives a signal SIGILL
On Sat, Aug 12, 2023 at 10:41:10AM -0300, Jorge D'Elia via Fortran wrote: > > $ test-march.exe > > Program received signal SIGILL: Illegal instruction. > This, to me, suggests that the backend is emitting a wrong assembly language code. I suspect that you'll need to compare the generated assembly code between a working gfortran and the bad gfortran. It is also possible to get a listing of the actually options that -march=native activates. For example, % gfcx -o z -O -march=native --verbose a.f90 It is the options that begin with -m that matter. For my hardware I see 108 such options. With patients you can determine if one of these triggers the issues. One can also scan gcc/gcc/ChangeLog for changes to config/i386/i386.md. For example 2023-08-07 Jan Beulich * config/i386/i386.md (sse4_1_round2): Make "length_immediate" uniformly 1. * config/i386/mmx.md (mmx_pblendvb_v8qi): Likewise. (mmx_pblendvb_): Likewise. There are at least 10 commits on 2023-08-07 to this file. Finally, as a non-git user, you can always try git's bisection feature to identify where things go left. -- Steve
Re: [PATCH] Fortran: do not pass hidden character length for TYPE(*) dummy [PR110825]
On Thu, Jul 27, 2023 at 09:39:53PM +0200, Harald Anlauf via Fortran wrote: > Dear all, > > when passing a character actual argument to an assumed-type dummy > (TYPE(*)), we should not pass the character length for that argument, > as otherwise other hidden arguments that are passed as part of the > gfortran ABI will not be interpreted correctly. This is in line > with the current way the procedure decl is generated. > > The attached patch fixes the caller and clarifies the behavior > in the documentation. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > OK. Patch looks small enough that if you are so inclined to backport that's ok as well. Thanks for the quick response. -- Steve
Re: Compile antiquated fortran?
On Thu, Jul 27, 2023 at 01:36:46PM -0400, Allin Cottrell via Fortran wrote: > I have old fortran source code (not my own work) for a specialized > statistical program that I and others find quite useful. > > A few years ago I was able to compile it on Linux using gfortran with > std=legacy (and also cross-compile it for Windows an Mac). Now I'd like to > rebuild it, but with recent gfortran (I've tried 12.2.1 on Fedora and 13.1.1 > on Arch) it's a no-go. I get lots of errors of the following sort: > > ansub9.f:151:44: > > 151 |INTEGER ITYPE,INIT,LAM,IMEAN,IP,ID,Q,BP,BD,BQ,SQG,MQ,L,M, > | 1 > Error: Symbol ‘q’ at (1) already has basic type of REAL > > I can understand this complaint. The code contains this sort of thing within > a given subroutine: > >IMPLICIT REAL*8 (A-H,O-Z) > > then some lines later on: > >INTEGER ITYPE,INIT,LAM,IMEAN,P,D,Q,... > > I guess the author was assuming that an explicit type-assignment just > overrides an implicit one. Older gfortran apparently played along with that. > > My question: Given that I'm already using -std=legacy, are there any other > flags that I could add to get the code to compile? > > (I know I could tackle this by renaming a bunch of variables, but in context > that would be an extremely fiddly job.) > I'm afraid we'll need to see some actual code. The following compiles without a problem. SUBROUTINE FOO(Q) IMPLICIT REAL*8 (A-H,O-Z) INTEGER Q Q = 1 END Hmmm, are DATA statements in the code? SUBROUTINE FOO IMPLICIT REAL*8 (A-H,O-Z) DATA Q/1/ INTEGER Q Q = 1 END % gfortran12 -c -Wall a.f a.f:4:16: 4 |INTEGER Q |1 Error: Symbol 'q' at (1) already has basic type of REAL gfortran is correct to complain here. The DATA statement give Q a REAL type due to the implicit statement. Q can only appear in a later declaration statement that re-affirms that type. -- Steve
Re: [PATCH, v3] Fortran: diagnose strings of non-constant length in DATA statements [PR68569]
On Wed, Jul 26, 2023 at 09:33:22PM +0200, Harald Anlauf via Fortran wrote: > I am going to get the brown bag for today... This is now the right > corrected patch. > > Sorry for all the noise! > Third times a charm (as the saying goes). Looks good to me. Thanks for the patch. -- Steve
Re: [PATCH] Fortran: intrinsics and deferred-length character arguments [PR95947,PR110658]
On Sun, Jul 16, 2023 at 10:30:59PM +0200, Harald Anlauf via Fortran wrote: > Dear all, > > some intrinsics may return character results with the same > characteristics as their first argument (e.g. PACK, MINVAL, ...). > If the first argument is of deferred-length, we need to derive > the character length of the result from the first argument, like > in the assumed-length case, but we must not handle it as > deferred-length, as that has a different argument passing > convention. > > The attached - almost trivial and obvious - patch fixes that. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > As this is a rather simple fix for a wrong-code bug, I would > like to backport this at least to 13-branch, unless there > are major concerns. > OK for trunk and backports. -- Steve
Re: [PATCH] Fortran: formal symbol attributes for intrinsic procedures [PR110288]
On Tue, Jul 11, 2023 at 09:39:31PM +0200, Harald Anlauf via Fortran wrote: > Dear all, > > for intrinsic procedures we derive the typespec of the formal symbol > attributes from the actual arguments. This can have an undesired > effect for character actual arguments, as the argument passing > conventions differ for deferred-length (length is passed by reference) > and otherwise (length is passed by value). > > The testcase in the PR nicely demonstrates the issue for > FINDLOC(array,value,...), when either array or value are deferred-length. > > We therefore need take care that we do not copy ts.deferred, but > rather set it to false if the formal argument is neither allocatable > or pointer. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > This is actually a 11/12/13/14 regression (and I found a potential > "culprit" in 11-development that touched the call chain in question), > so the patch might finally need backporting as far as seems reasonable. > OK. Backports are OK as well. -- Steve
Re: [Patch, fortran] Fix default type bugs in gfortran [PR99139, PR99368]
On Sat, Jul 08, 2023 at 03:23:31PM +0100, Paul Richard Thomas wrote: > The attached patch incorporates two of Steve's "Orphaned Patches" - > https://gcc.gnu.org/pipermail/fortran/2023-June/059423.html Thanks Paul for picking up the pieces I left behind. A few nits below. > They have in common that they both involve faults in use of default > type and that I was the ultimate cause of the bugs. > > The patch regtests with the attached testcases. > > I will commit in the next 24 hours unless there are any objections. > > Paul > > Fortran: Fix default type bugs in gfortran [PR99139, PR99368] > > 2023-07-08 Steve Kargl ka...@gcc.gnu.org. > gcc/fortran > PR fortran/99139 > PR fortran/99368 > * match.cc (gfc_match_namelist): Check for host associated or > defined types before applying default type. > (gfc_match_select_rank): Apply default type to selector of > unlnown type if possible. s/unlnown/unknown > * resolve.cc (resolve_fl_variable): Do not apply local default > initialization to assumed rank entities. > > gcc/testsuite/ > PR fortran/999139 > * gfortran.dg/pr99139.f90 : New test > > PR fortran/99368 > * gfortran.dg/pr99368.f90 : New test > > Fortran: Fix default type bugs in gfortran [PR99139, PR99368] > > 2023-07-08 Steve Kargl ka...@gcc.gnu.org > > gcc/fortran > PR fortran/99139 > PR fortran/99368 > * match.cc (gfc_match_namelist): Check for host associated or > defined types before applying default type. > (gfc_match_select_rank): Apply default type to selector of > unlnown type if possible. s/unlnown/unknown Other than the nits the patch looks fine. -- Steve
Re: [PATCH] Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments [PR92178]
On Tue, Jul 04, 2023 at 11:26:26AM +0200, Mikael Morin wrote: > Le 04/07/2023 à 01:56, Steve Kargl a écrit : > > On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote: > > > > > > Indeed, this is a nice demonstration. > > > > > > While playing, I was wondering whether the following code is conforming: > > > > > > program p > > >call s ((1)) > > > contains > > >subroutine s (x) > > > integer :: x > > > x = 42 > > >end subroutine > > > end > > > > > > (It crashes with gfortran, but not with any foreign brand tested). > > > > > > > It's not conforming. '(1)' is an expression and it cannot appear > > in a variable definition condition. I am not aware of any numbered > > constraint tha would require a Fortran processor to generate an > > error. > > > > I think you would be right if X had INTENT(OUT) or INTENT(INOUT) attribute. > This is F2023, 15.5.2.4 (no mention of variable definition context here): > > If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual > > argument shall be definable. > > However, with unspecified intent, I can't find the rule explicitly > forbidding the above example. > I'm tempted to say it is conforming. I thought it was in Sec. 19, but failed to locate any prohibition. The best I can find is 23-007r1.pdf 8.5.10 INTENT attribute pg. 114 (following Note 1) If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of its effective argument (15.5.2). pg. 115 (within Note 4, so non-normative text) INTENT (INOUT) is not equivalent to omitting the INTENT attribute. The actual argument corresponding to an INTENT (INOUT) dummy argument is always required to be definable, while an actual argument corresponding to a dummy argument without an INTENT attribute need be definable only if the dummy argument is actually redefined. Searching for "definable" does not lead to a prohibition of the form "An expression is not definable." -- Steve
Re: [PATCH] Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments [PR92178]
On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote: > > Indeed, this is a nice demonstration. > > While playing, I was wondering whether the following code is conforming: > > program p > call s ((1)) > contains > subroutine s (x) > integer :: x > x = 42 > end subroutine > end > > (It crashes with gfortran, but not with any foreign brand tested). > It's not conforming. '(1)' is an expression and it cannot appear in a variable definition condition. I am not aware of any numbered constraint tha would require a Fortran processor to generate an error. -- Steve
Re: PR82943 - Suggested patch to fix
On Thu, Jun 29, 2023 at 10:38:42PM -0500, Alexander Westbrooks via Fortran wrote: > I have finished my testing, and updated my patch and relevant Changelogs. I > added 4 new tests and all the existing tests in the current testsuite > for gfortran passed or failed as expected. Do I need to attach the test > results here? Yes. It helps others also do testing to have one self-contained patch (which I don't know to generate with git and new files :-( ). It may also be a good idea to attach the patch and test cases to the PR in bugzilla so that they don't accidentally get lost. > The platform I tested on was a Docker container running in Docker Desktop, > running the "mcr.microsoft.com/devcontainers/universal:2-linux" image. > > I also made sure that my code changes followed the coding standards. Please > let me know if there is anything else that I need to do. I don't have > write-access to the repository. See the legal link that Harald provided. At one time, one needed to assign copyright to the FSF with a wet-ink signature on some form. Now, I think you just need to attest that you have the right to provide the code to the gcc project. PS: Welcome to the gfortran development world. Don't be put off if there is a delay in getting feedback/review. There are too few contributors and too little time. If a week passes simply ping the mailing list. I'll try to carve out some time to look over your patch this weekend. -- steve > > Thanks, > > Alexander > > On Wed, Jun 28, 2023 at 4:14 PM Harald Anlauf wrote: > > > Hi Alex, > > > > welcome to the gfortran community. It is great that you are trying > > to get actively involved. > > > > You already did quite a few things right: patches shall be sent to > > the gcc-patches ML, but Fortran reviewers usually notice them only > > where they are copied to the fortran ML. > > > > There are some general recommendations on the formatting of C code, > > like indentation, of the patches, and of the commit log entries. > > > > Regarding coding standards, see https://www.gnu.org/prep/standards/ . > > > > Regarding testcases, a recommendation is to have a look at > > existing testcases, e.g. in gcc/testsuite/gfortran.dg/, and then > > decide if the testcase shall test the compile-time or run-time > > behaviour, and add the necessary dejagnu directives. > > > > You should also verify if your patch passes regression testing. > > For changes to gfortran, it is usually sufficient to run > > > > make check-fortran -j > > > > where is the number of parallel tests. > > You would need to report also the platform where you tested on. > > > > There is also a legal issue to consider before non-trivial patches can > > be accepted for incorporation: https://gcc.gnu.org/contribute.html#legal > > > > If your patch is accepted and if you do not have write-access to the > > repository, one of the maintainers will likely take care of it. > > If you become a regular contributor, you will probably want to consider > > getting write access. > > > > Cheers, > > Harald > > > > > > > > On 6/24/23 19:17, Alexander Westbrooks via Gcc-patches wrote: > > > Hello, > > > > > > I am new to the GFortran community. Over the past two weeks I created a > > > patch that should fix PR82943 for GFortran. I have attached it to this > > > email. The patch allows the code below to compile successfully. I am > > > working on creating test cases next, but I am new to the process so it > > may > > > take me some time. After I make test cases, do I email them to you as > > well? > > > Do I need to make a pull-request on github in order to get the patch > > > reviewed? > > > > > > Thank you, > > > > > > Alexander Westbrooks > > > > > > module testmod > > > > > > public :: foo > > > > > > type, public :: tough_lvl_0(a, b) > > > integer, kind :: a = 1 > > > integer, len :: b > > > contains > > > procedure :: foo > > > end type > > > > > > type, public, EXTENDS(tough_lvl_0) :: tough_lvl_1 (c) > > > integer, len :: c > > > contains > > > procedure :: bar > > > end type > > > > > > type, public, EXTENDS(tough_lvl_1) :: tough_lvl_2 (d) > > > integer, len :: d > > > contains > > > procedure :: foobar > > > end type > > > > > > contains > > > subroutine foo(this) > > > class(tough_lvl_0(1,*)), intent(inout) :: this > > > end subroutine > > > > > > subroutine bar(this) > > > class(tough_lvl_1(1,*,*)), intent(inout) :: this > > > end subroutine > > > > > > subroutine foobar(this) > > > class(tough_lvl_2(1,*,*,*)), intent(inout) :: this > > > end subroutine > > > > > > end module > > > > > > PROGRAM testprogram > > > USE testmod > > > > > > TYPE(tough_lvl_0(1,5)) :: test_pdt_0 > > > TYPE(tough_lvl_1(1,5,6)) :: test_pdt_1 > > > TYPE(tough_lvl_2(1,5,6,7)) :: test_pdt_2 > > > > > > CALL test_pdt_0%foo() > > > > > >
Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
On Wed, Jun 21, 2023 at 05:12:22PM +0100, Paul Richard Thomas wrote: > Committed as r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27 > > Thanks for the help and the review Harald. Thanks to Steve too for > picking up Neil Carlson's bugs. > It's only natural. You fix bugs in a long desired feature, and people will start to use that feature more. I always look at Neil's bug reports. They're typically concise code snippets and have cross references to the Fortran standard. Unfortunately, I lack the ability to fix them. :( -- Steve
Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
On Sat, Jun 17, 2023 at 10:14:43AM +0100, Paul Richard Thomas via Fortran wrote: > > PS This leaves 89645 and 99065 as the only real blockers to PR87477. > Hate to be the bearer of bad news, but Neil Carlson has added a couple PRs about associate that may not be listed in 87447. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 For the second one, if I suppress the bogus error message, the compiler runs into a new error message. The second error message indicates the associate-name is not an unexpected coarray. I haven't determined how to propagate the information that the selector is a coarray to the associate-name. -- Steve
Re: program errors with GNU Fortran
On Fri, Jun 16, 2023 at 07:18:54PM +, Michael Schneider via Fortran wrote: > Hello, > > I'm looking for a forum that can provide answers to > questions arising with GNU Fortran. Is this the right place? > fortran@gcc is normally used for discussion about the development of the gfortran compiler. However, if a users has hit a bug within gfortran (a so-called internal compiler error), one is encouraged to report it either here or in bugzilla. If your questions are somewhat generic Fortran question, and you just happen to use gfortran as your compiler, then those questions should be addressed to the comp.lang.fortran USENET newsgroup or stackoverflow. -- Steve
Re: [PATCH] Fortran: fix passing of zero-sized array arguments to procedures [PR86277]
On Mon, Jun 12, 2023 at 11:12:45PM +0200, Harald Anlauf via Fortran wrote: > Dear all, > > the attached - actually rather small - patch is the result of a > rather intensive session with Mikael in an attempt to fix the > situation that we did not create proper temporaries when passing > zero-sized array arguments to procedures. When the dummy argument > was declared as OPTIONAL, in many cases it was mis-detected as > non-present. This also depended on the type of argument, and > was different for different intrinsic types, notably character, > and derived types, and should explain the rather large ratio of > the size of the provided testcases to the actual fix... > > (What the patch does not address: we still generate too much code > for unneeded temporaries, often two temporaries instead of just > one. I'll open a separate PR to track this.) > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > If this survives long enough on 14-trunk, would this be eligible > for a backport to 13-branch in time for 13.2? > OK to commit. I've reviewed the bugzilla exchange between Mikael and you, and agree with committing this and opening a new PR to track the unneeded temporaries issue. -- Steve
Orphaned patches
If anyone is so inclined, the patches in the following PR's can be committed and the PR closed. These are patches for gfortran. 69101 91960 95613 99139 99368 99798 100607 103795 103796 104626 105594 101967 101951 104649 106050 106500 107266 107406 107596 This is an opportunity for lurkers in the fortran@ list to grab a patch, apply to the tree, ask questions, and then take the plunge to being someone who can help care for gfortran. -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
> Hi together,
>
> > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > > > Hi,
> > > >
> > > > > I cannot see if there is proper support for kind=17 in your patch;
> > > > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
> > > > > seem to have any related code.
> > > >
> > > > Can real(kind=17) ever be an IEEE mode? If so, something seriously
> > > > wrong happened, because the IEEE modules have no kind=17 mention in
> > > > them anywhere.
> > > >
> > > > Actually, where is the kind=17 documented?
> > > >
> > > > FX
> > >
> > > I was hoping for Thomas to come forward with some comment, as
> > > he was quite involved in related work.
> > >
> > > There are several threads on IEEE128 for Power on the fortran ML
> > > e.g. around November/December 2021, January 2022.
> > >
> > > I wasn't meaning to block your work, just wondering if the Power
> > > platform needs more attention here.
> > >
> >
> > % cd gcc/gccx/libgfortran
> > % grep HAVE_GFC_REAL_17 ieee/*
> > % troutmask:sgk[219] ls ieee
> > % ieee_arithmetic.F90 ieee_features.F90
> > % ieee_exceptions.F90 ieee_helper.c
> >
> > There are zero hits for REAL(17) in the IEEE code. If REAL(17)
> > is intended to be an IEEE-754 type, then it seems gfortran's
> > support was never added for it. If anyone has access to a
> > power system, it's easy to test
> >
> > program foo
> > use ieee_arithmetic
> > print *, ieee_support_datatype(1.e_17)
> > end program foo
>
> The KIND=17 is a bit of a kludge. It is not visible for
> user programs, they use KIND=16, but this is then translated
> to library calls as if it was KIND=17 if the IEEE 128-bit floats
> are selected:
>
> $ cat ml.f90
> subroutine mm(a)
> real(kind=16), dimension(:,:) :: a
> print *,maxloc(a)
> end subroutine mm
> $ gfortran -S -mabi=ieeelongdouble ml.f90 && grep maxloc ml.s
> bl _gfortran_maxloc0_4_r17
> $ gfortran -S ml.f90 && grep maxloc ml.s
> bl _gfortran_maxloc0_4_r16
>
> On POWER, if IBM long double exists, it is GFC_REAL_16, with GFC_REAL_17
> being IEEE long double. Everywhere else, GFC_REAL_16 is IEEE long
> double.
>
> If POWER gets the flag -mabi=ieeelongdouble, it uses IEEE long doubles.
>
> If it gets the additionalflag -mcpu=power9 or -mcpu=power10, it uses
> the hardware instructions for the arithmetic instead of library calls.
>
(trimming for length)
Thanks for the explanation. As I likely will not use a POWER-based
system, I only loosely followed the discussion. I don't remember
if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is
REAL(16), then everything should (I believe) be okay.
> There is a virutal POWER machine at OSUL dedicated to the IEEE QP
> gfortran effort. It hasn't been used for some time, but it's still
> active. I just bootstrapped trunk there and ran all the IEEE from the
> testsuite manually, with
>
> $ for a in *.f90; do echo "Testing $a"; gfortran -o $a.exe -fno-range-check
> -mcpu=power9 -mabi=ieeelongdouble -static-libgfortran $a signaling_1_c.c
> signaling_2_c.c ; ./$a.exe ; done 2>&1 | grep -v command-line
> Testing fma_1.f90
These could be misleading. gfortran has pre-processor tokens
for REAL(10) and REAL(16). If __GFC_REAL_16__ isn't defined
the ieee testing is skipped.
% cd gcc/gccx/gcc/fortran/
% grep __GFC_REAL_ *
cpp.cc: cpp_define (cpp_in, "__GFC_REAL_10__=1");
cpp.cc: cpp_define (cpp_in, "__GFC_REAL_16__=1");
invoke.texi:@code{__GFC_REAL_10__}, and @code{__GFC_REAL_16__}.
% more cpp.cc
...
/* Pre-defined macros for non-required REAL kind types. */
for (gfc_real_info *rtype = gfc_real_kinds; rtype->kind != 0; rtype++)
{
if (rtype->kind == 10)
cpp_define (cpp_in, "__GFC_REAL_10__=1");
if (rtype->kind == 16)
cpp_define (cpp_in, "__GFC_REAL_16__=1");
}
...
Should we have a __GFC_REAL_17__?
% cd ../testsuite/gfortran.dg/
% grep __GFC_REAL ieee/*
ieee/dec_math_1.f90: ! Note however that if both __GFC_REAL_10__ and
__GFC_REAL_16__ are defined,
ieee/dec_math_1.f90:#if defined(__GFC_REAL_10__)
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__)
ieee/dec_math_1.f90:#ifdef __GFC_REAL_10__
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__)
ieee/dec_math_1.f90:#ifdef __GFC_REAL_16__
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_10__)
ieee/ieee_11.F90:#ifdef __GFC_REAL_10__
ieee/ieee_11.F90:#ifdef __GFC_REAL_16__
--
Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Wed, Jun 07, 2023 at 08:31:35PM +0200, Harald Anlauf via Fortran wrote: > Hi FX, > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote: > > Hi, > > > > > I cannot see if there is proper support for kind=17 in your patch; > > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not > > > seem to have any related code. > > > > Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong > > happened, because the IEEE modules have no kind=17 mention in them anywhere. > > > > Actually, where is the kind=17 documented? > > > > FX > > I was hoping for Thomas to come forward with some comment, as > he was quite involved in related work. > > There are several threads on IEEE128 for Power on the fortran ML > e.g. around November/December 2021, January 2022. > > I wasn't meaning to block your work, just wondering if the Power > platform needs more attention here. > % cd gcc/gccx/libgfortran % grep HAVE_GFC_REAL_17 ieee/* % troutmask:sgk[219] ls ieee % ieee_arithmetic.F90 ieee_features.F90 % ieee_exceptions.F90 ieee_helper.c There are zero hits for REAL(17) in the IEEE code. If REAL(17) is intended to be an IEEE-754 type, then it seems gfortran's support was never added for it. If anyone has access to a power system, it's easy to test program foo use ieee_arithmetic print *, ieee_support_datatype(1.e_17) end program foo -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Tue, Jun 06, 2023 at 09:35:26PM +0200, FX Coudert wrote: > Hi Steve, > > I am not subscribed to the list (too little time, sadly), please keep me in > CC of your responses. > Unfortunately, fx is using a gmail account. Emails from my system to @gmail.com users are routinely and silently rejected. > > 1. You added fmin, fmax, and friends. Are these used > >internally by gfortran in support of the IEEE_* > >functions or are these exposed to the user? > > The math builtins are added to the front-end, and use for > code generation. In conv_intrinsic_ieee_minmax(), you can > see we find the right function using things like: > builtin_decl_explicit (BUILT_IN_ISSIGNALING) This answers my question 1. I think the patch can be committed after you've given time for Harald to answer your question about REAL(17). I think isn't important as all of the other ieee testcase would be broken on powerpc. -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Tue, Jun 06, 2023 at 08:51:54AM -0700, Steve Kargl via Fortran wrote: > > Scratch 2. Another scan shows that you moduled the Fortran s/you moduled/you added to > module where interface are built. This will automatically s/interface/interfaces > catch and report the items in 2. Complete lack of coffee. -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Tue, Jun 06, 2023 at 08:43:36AM -0700, Steve Kargl via Fortran wrote: > On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote: > > Hi, > > > > This patch adds four IEEE functions from the Fortran 2018 > > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, > > and IEEE_MAX_NUM_MAG. > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 > > and 64-bit. OK to commit? > > > > FX, > > If no one else looks over the patch before the weekend, > I'll give it a deeper look. Two questions after a > quick scan: > > 1. You added fmin, fmax, and friends. Are these used >internally by gfortran in support of the IEEE_* >functions or are these exposed to the user? > > 2. I did not see error handling or conversion, but on a >quick scan I may have missed it. What happens with >IEEE_MAX_NUM(2.0_4, 3.0_8) or IEEE_MAX_NUM(2.0_4, INT(3))? >17.11.17 has > >X shall be of type real. >Y shall be of the same type and kind type parameter as X. > Scratch 2. Another scan shows that you moduled the Fortran module where interface are built. This will automatically catch and report the items in 2. -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote: > Hi, > > This patch adds four IEEE functions from the Fortran 2018 > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, > and IEEE_MAX_NUM_MAG. > > Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 > and 64-bit. OK to commit? > FX, If no one else looks over the patch before the weekend, I'll give it a deeper look. Two questions after a quick scan: 1. You added fmin, fmax, and friends. Are these used internally by gfortran in support of the IEEE_* functions or are these exposed to the user? 2. I did not see error handling or conversion, but on a quick scan I may have missed it. What happens with IEEE_MAX_NUM(2.0_4, 3.0_8) or IEEE_MAX_NUM(2.0_4, INT(3))? 17.11.17 has X shall be of type real. Y shall be of the same type and kind type parameter as X. -- Steve
Re: [Patch, fortran] PR37336 finalization
On Sat, Jun 03, 2023 at 07:50:19AM +0200, Thomas Koenig via Fortran wrote: > Hi Paul, > > > I propose to backport > > r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very > > soon. > > Is this something that we usually do? > > While finalization was basically broken before, some people still used > working subsets (or subsets that were broken, and they adapted or > wrote their code accordingly). > > What is the general opinion on that? I'm undecided. > I think a backport that fixes a bug that is a violation of Fortran standard is always okay. A backport of anything else is up to the discretion of the contributor. If pault or you or harald or ... want to backport a patch, after all these years, I think we should trust their judgement. -- Steve
Re: A doubt about IMPORT and SELECT TYPE
Oh, I'm not asking you or any of the other regular contributors to gfortran to pick up my WIP patch and finish the last 5%. Now, lurkers on the mailing list, who have always wanted to give back, well I'm more than willing to help explain the patch and what I think needs to be done if they are so inclined to get their hands dirty. IMPORT is an interesting construct. Originally, all entities are blocked from host assocation into an INTERFACE, so J3 invented IMPORT to allow one to cherry pick entities from the host. gfortran's implementation is fairly straightforward. In F2018, J3 extended IMPORT to block host-association in for example a contained subprogram or BLOCK construct. This seems like a logical and good thing; except this is the complete opposite of its original use. Undoing/revising gfortran'sr original implemenation of IMPORT is a bit more challenging. -- steve On Fri, Jun 02, 2023 at 09:14:01PM +0100, Paul Richard Thomas wrote: > Hi Steve, > > As noted in the previous email :-), although I didn't mention the partially > cooked patch. > > One day, once F2003 is sorted, I might turn to F2008/18! > > Cheers > > Paul > > > On Fri, 2 Jun 2023, 16:27 Steve Kargl via Fortran, > wrote: > > > On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richard Thomas via Fortran > > wrote: > > > Hi Jorge, > > > > > > As I posted in the Intel Community, the error generated by gfortran > > > (and nagfor) is consistent with the F2003 constraint: C1210 (R1209) > > > The IMPORT statement is allowed only in an interface-body. > > > > > > Could you please raise a problem report in gcc Bugzilla? > > > > > > > There already is a PR about IMPORT. See > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 > > > > There is a patch that is 95-ish% complete. The last > > 5% is the hard part, which it seems no one has had > > time or ideas on how to finish the patch. > > > > -- > > Steve > > -- Steve
Re: A doubt about IMPORT and SELECT TYPE
On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richard Thomas via Fortran wrote: > Hi Jorge, > > As I posted in the Intel Community, the error generated by gfortran > (and nagfor) is consistent with the F2003 constraint: C1210 (R1209) > The IMPORT statement is allowed only in an interface-body. > > Could you please raise a problem report in gcc Bugzilla? > There already is a PR about IMPORT. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 There is a patch that is 95-ish% complete. The last 5% is the hard part, which it seems no one has had time or ideas on how to finish the patch. -- Steve
Re: [EXTERNAL] Re: Advice with finding speed between O2 and O3
On Thu, May 25, 2023 at 04:05:11PM +, Thompson, Matt (GSFC-610.1)[SCIENCE
SYSTEMS AND APPLICATIONS INC] via Fortran wrote:
> Thomas,
>
> Well, the code did not change. Period. Neither did the compiler. It was 12.3.
> (We can't use GCC 13 because it seems not to like something in our advanced
> Fortran code (lots of OO, submodules, string fun...)).
>
> And I did a run with essentially all the GNU checks on (our Debug build mode)
> and it happily runs!
>
> That said, I did some further tests and I am *really* confused. This fails:
>
> -O3 -march=haswell -mtune=generic -funroll-loops -g
>
> And this works:
>
> -O2 -march=haswell -mtune=generic -funroll-loops -g
>
> Now I just tried:
>
> -O2 -fgcse-after-reload-fipa-cp-clone-floop-interchange
> -floop-unroll-and-jam-fpeel-loops-fpredictive-commoning
> -fsplit-loops-fsplit-paths-ftree-loop-distribution
> -ftree-partial-pre-funroll-completely-grow-size-funswitch-loops
> -fversion-loops-for-strides -march=haswell -mtune=generic -funroll-loops -g
>
> which as far as I can see from the gcc man page:
>
>-O3 Optimize yet more. -O3 turns on all optimizations specified by
> -O2 and also turns on the following optimization flags:
>
>-fgcse-after-reload -fipa-cp-clone -floop-interchange
> -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops
> -fsplit-paths -ftree-loop-distribution -ftree-partial-pre -funswitch-loops
>-fvect-cost-model=dynamic -fversion-loops-for-strides
>
> means I am running essentially -O3.
>
> But it works.
>
> I'm...baffled. Is there something that *gfortran* enables with -O3 that isn't
> visible from the *gcc* man page?
>
gcc/gcc/opts.cc also shows some fiddling with parameters.
/* -O3 parameters. */
{ OPT_LEVELS_3_PLUS, OPT__param_max_inline_insns_auto_, NULL, 30 },
{ OPT_LEVELS_3_PLUS, OPT__param_early_inlining_insns_, NULL, 14 },
{ OPT_LEVELS_3_PLUS, OPT__param_inline_heuristics_hint_percent_, NULL, 600 },
{ OPT_LEVELS_3_PLUS, OPT__param_inline_min_speedup_, NULL, 15 },
{ OPT_LEVELS_3_PLUS, OPT__param_max_inline_insns_single_, NULL, 200 },
AFAICT, gfortran does not add or change anything with -O3.
Out of curosity, does it compile and run with -O3 if you
remove one or both of '-march=haswell -mtune=generic'?
One other possibility is an issue with signed integer overflow,
but I don't remember if the change that causes the issue has
reached 12.x. Does the code run if you add -fwrapv to your
options list?
--
Steve
Re: [PATCH] Fortran: CLASS pointer function result in variable definition context [PR109846]
On Sun, May 14, 2023 at 10:04:25PM +0200, Harald Anlauf via Fortran wrote: > > Fortran allows functions in variable definition contexts when the > result variable is a pointer. We already handle this for the > non-CLASS case (in 11+), but the logic that checks the pointer > attribute was looking in the wrong place for the CLASS case. > > Once found, the fix is simple and obvious, see attached patch. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. As you say, it is obvious once found. Ok to backport after a few days. -- Steve
Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE
On Tue, May 09, 2023 at 08:35:00PM +0200, Harald Anlauf wrote: > On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote: > > > > It's not needed. See above. gfc_state_stack->previous is referenced > > a few lines above the if-stmt. The reference will segfault if the > > pointer is NULL. > > > > You're absolutely right. So it is OK as is. Thanks for keeping us honest and the review. -- Steve
Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE
On Tue, May 09, 2023 at 08:24:16PM +0200, Harald Anlauf wrote:
> Hi Paul,
>
> On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
> > this testcase checked that finalizable derived types could not be specified
> > in a submodule. I have replaced the original test with a test of the patch.
> >
> > Thanks also to Malcolm Cohen for guidance on this.
> >
> > OK for trunk?
>
> the patch looks good to me. However:
>
> @@ -11637,8 +11637,9 @@ gfc_match_final_decl (void)
>block = gfc_state_stack->previous->sym;
^
See below.
>gcc_assert (block);
>
> - if (!gfc_state_stack->previous || !gfc_state_stack->previous->previous
> - || gfc_state_stack->previous->previous->state != COMP_MODULE)
> + if (gfc_state_stack->previous->previous
> + && gfc_state_stack->previous->previous->state != COMP_MODULE
> + && gfc_state_stack->previous->previous->state != COMP_SUBMODULE)
> {
>gfc_error ("Derived type declaration with FINAL at %C must be in
> the"
> " specification part of a MODULE");
>
> I am wondering if we should keep the protection against a potential
> NULL pointer dereference (i.e. gfc_state_stack->previous == NULL) for
> possibly invalid code. I have failed to produce a simple testcase,
> but others may have "better" ideas.
It's not needed. See above. gfc_state_stack->previous is referenced
a few lines above the if-stmt. The reference will segfault if the
pointer is NULL.
--
Steve
Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
Harald, Thanks for keeping us honest. I didn't check what other separators might cause a problem. After 2 decades of working on gfortran, I've come to conclusion that -std=f2018 should be the default. When f2023 is ratified, the default becomes -std=f2023. All GNU fortran extension should be behind an option, and we should be aggressive eliminating extensions. Yes, this means that 'real*4' and similar would require a -fallow-nonstandard-declaration option. -- steve On Sun, May 07, 2023 at 08:33:43PM +0200, Harald Anlauf wrote: > Hi Jerry, > > I've made a small compiler survey how they behave on namelist read > from an internal unit when: > > 1.) there is a single input line of the type > "" // testchar // " n = 666/" > > 2.) the input spans 2 lines split after the testchar > > 3.) same as 2.) but first line right-adjusted > > See attached source code. > > Competitors: Intel, NAG, NVidia, gfortran at r14-547 with -std=f2018. > > My findings were (last column is iostat, next-to-last is n read or -1): > > NAG: > > Compiler version = NAG Fortran Compiler Release 7.1(Hanzomon) Build 7101 > 1-line: > < 666 0 > 2-line/left: > < 666 0 > 2-line/right: > < 666 0 > 1-line: >!< -1 187 > 2-line/left: >!< -1 187 > 2-line/right: >!< -1 187 > 1-line: >/< -1 187 > 2-line/left: >/< -1 187 > 2-line/right: >/< -1 187 > 1-line: >,< -1 187 > 2-line/left: >,< -1 187 > 2-line/right: >,< -1 187 > 1-line: >;< -1 187 > 2-line/left: >;< -1 187 > 2-line/right: >;< -1 187 > 1-line: tab 666 0 > 2-line/left: tab 666 0 > 2-line/right: tab 666 0 > 1-line: lf -1 187 > 2-line/left: lf -1 187 > 2-line/right: lf -1 187 > 1-line: ret -1 187 > 2-line/left: ret -1 187 > 2-line/right: ret -1 187 > > My interpretation of this is that NAG treats tab as (white)space, > everything else gives an error. This is the strictest compiler. > > Intel: > > Compiler version = Intel(R) Fortran Intel(R) 64 Compiler Classic for > applications running on Intel(R) 64, Version 2021.9.0 Build 20230302_00 > 1-line: > < 666 0 > 2-line/left: > < 666 0 > 2-line/right: > < 666 0 > 1-line: >!< -1 -1 > 2-line/left: >!< 666 0 > 2-line/right: >!< 666 0 > 1-line: >/< -1 0 > 2-line/left: >/< -1 0 > 2-line/right: >/< -1 0 > 1-line: >,< -1 17 > 2-line/left: >,< -1 17 > 2-line/right: >,< -1 17 > 1-line: >;< -1 17 > 2-line/left: >;< -1 17 > 2-line/right: >;< -1 17 > 1-line: tab 666 0 > 2-line/left: tab 666 0 > 2-line/right: tab 666 0 > 1-line: lf 666 0 > 2-line/left: lf 666 0 > 2-line/right: lf 666 0 > 1-line: ret -1 17 > 2-line/left: ret -1 17 > 2-line/right: ret -1 17 > > Nvidia: > > Compiler version = nvfortran 23.3-0 > 1-line: > < 6660 > 2-line/left: > < 6660 > 2-line/right: > < 6660 > 1-line: >!< -1 -1 > 2-line/left: >!< -1 -1 > 2-line/right: >!< -1 -1 > 1-line: >/< -1 -1 > 2-line/left: >/< -1 -1 > 2-line/right: >/< -1 -1 > 1-line: >,< -1 -1 > 2-line/left: >,< -1 -1 > 2-line/right: >,< -1 -1 > 1-line: >;< -1 -1 > 2-line/left: >;< -1 -1 > 2-line/right: >;< -1 -1 > 1-line: tab 6660 > 2-line/left: tab 6660 > 2-line/right: tab 6660 > 1-line: lf -1 -1 > 2-line/left: lf 6660 > 2-line/right: lf 6660 > 1-line: ret 6660 > 2-line/left: ret 6660 > 2-line/right: ret 6660 > > gfortran (see above): > > Compiler version = GCC version 14.0.0 20230506 (experimental) > 1-line: > < 666 0 > 2-line/left: > < 666 0 > 2-line/right: > < 666 0 > 1-line: >!< -1 -1 > 2-line/left: >!< -1 0 > 2-line/right: >!< 666 0 > 1-line: >/< -1 0 > 2-line/left: >/< -1 0 > 2-line/right: >/< -1 0 > 1-line: >,< 6665010 > 2-line/left: >,< 6665010 > 2-line/right: >,< 6665010 > 1-line:
Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote: > The attached patch adds a check for the invalid comma and emits a runtime > error if -std=f95,f2003,f2018 are specified at compile time. > > Attached patch includes a new test case. > > Regression tested on x86_64-linux-gnu. > > OK for mainline? > Yes. Thanks for the fix. It's been a long time since I looked at libgfortran code and couldn't quite determine where to start to fix this. -- Steve
Re: finalization issue
Hi Paul, I'll need to go through F2018 again, but I thought I found a statement that a module procedure can be in a submodule. Here's the starting point 14.2.3 Submodules A submodule is a program unit that extends a module or another submodule. ... A submodule may provide implementations for separate module procedures (15.6.2.5), each of which is declared (15.4.3.2) within that submodule or one of its ancestors, and declarations and definitions of other entities that are accessible by host association in its descendants. 15.2.2.2 External, internal, and module procedures ... A module procedure is a procedure that is defined by a module subprogram, 15.6.2 Procedures defined by subprograms ... C1548 (R1526) If MODULE appears in the prefix of a module subprogram, it shall have been declared to be a separate module procedure in the containing program unit or an ancestor of that program unit. At this point, I get bogged down in chase 'module subprogram' through the standard. On Thu, May 04, 2023 at 09:09:30AM +0100, Paul Richard Thomas wrote: > Hi Steve, > > Nagfor responds to the test case with "Error: pr97122.f90, line 14: Type T > has final subroutines but is not defined in the specification part of a > module" > > F2018: > "C787(R753) A final-subroutine-name shall be the name of a module procedure > with exactly one dummy argument." > > Since, of necessity, the argument is declared to be of the derived type > with the final binding, the gfortran and nagfor errors are correct IMHO. > ifort compiles it without complaint. > > I have marked this as "waiting" pending a contrary interpretation. > > Cheers > > Paul > > On Wed, 3 May 2023 at 23:59, Steve Kargl via Fortran > wrote: > > > All, > > > > PR97122 shows an issue with finalization. > > It seems I attached a diff to the PR in 2020, > > which allows the code to compile. The diff > > applied to today's trunk still allows the > > code to compile but there is now at least > > 1 regression with finalize_8.f03. > > > > Even with my patch, I'm uncertain as to > > whether the finalizing subroutine is > > correctly hooked to the right namespace. > > > > -- > > steve > > > > > -- > "If you can't explain it simply, you don't understand it well enough" - > Albert Einstein -- Steve
finalization issue
All, PR97122 shows an issue with finalization. It seems I attached a diff to the PR in 2020, which allows the code to compile. The diff applied to today's trunk still allows the code to compile but there is now at least 1 regression with finalize_8.f03. Even with my patch, I'm uncertain as to whether the finalizing subroutine is correctly hooked to the right namespace. -- steve
Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500]
On Sat, Apr 22, 2023 at 08:43:53PM +0200, Mikael Morin wrote: > > > OK, let's go with your patch as originally submitted then. > Mikael, thanks for looking at the original patch and suggested an alternative location to attempt to fix the bug. Halrald, thanks for following up on Mikael's suggestion. -- Steve
Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500]
On Sat, Apr 22, 2023 at 05:17:30PM +0200, Mikael Morin wrote: > Le 22/04/2023 à 15:52, Steve Kargl a écrit : > > On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote: > > > > > > Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit : > > > > Dear all, > > > > > > > > Fortran 2018 added a clarification that the *result* of a function > > > > whose result *variable* has the ALLOCATABLE attribute is a *value* > > > > that itself does not have the ALLOCATABLE attribute. > > > > > > > > For those interested: there was a thread on the J3 mailing list > > > > some time ago (for links see the PR). > > > > > > > > The patch which implements a related check was co-authored with > > > > Steve and regtested by him. Testcase verified against NAG. > > > > > > > > OK for mainline (gcc-14)? > > > > > > > Looks good in principle, but I think the real fix should be in the > > > gfc_expr_attr function, which copies all the attributes (including > > > allocatable) in the EXPR_FUNCTION case. How would the testsuite react if > > > that attribute was cleared there? Is your patch still needed if > > > gfc_expr_attr is fixed? > > > > You may be correct that something can be done elsewhere. > > I do note that a function result can be allocatable > > (within the funciton body). The issue only arises when > > argument association is done, which is done where Harald > > and I have the patch. Do we know that the function will > > be an actual argument associated with an allocatable > > dummy argument when gfc_expr_attr is invoked? > > > No, there is no context information in gfc_expr_attr, but the result should > not be dependent on context anyway. > > You are probably right that the impact of this bug is limited to the case of > argument association, not as broad as I thought. Yet we should not keep > gfc_expr_attr returning an allocatable attribute for function expressions in > any case. I suspect we're stuck in a catch-22 situation. The symbol is marked as allocatable, function foo() integer, allocatable :: foo foo = 42 !<--- So that this isn't rejected end but when the function is actually referenced in an expression the result is normally used, and symbol is still marked as allocatable. -- Steve
Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500]
On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote: > > Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit : > > Dear all, > > > > Fortran 2018 added a clarification that the *result* of a function > > whose result *variable* has the ALLOCATABLE attribute is a *value* > > that itself does not have the ALLOCATABLE attribute. > > > > For those interested: there was a thread on the J3 mailing list > > some time ago (for links see the PR). > > > > The patch which implements a related check was co-authored with > > Steve and regtested by him. Testcase verified against NAG. > > > > OK for mainline (gcc-14)? > > > Looks good in principle, but I think the real fix should be in the > gfc_expr_attr function, which copies all the attributes (including > allocatable) in the EXPR_FUNCTION case. How would the testsuite react if > that attribute was cleared there? Is your patch still needed if > gfc_expr_attr is fixed? You may be correct that something can be done elsewhere. I do note that a function result can be allocatable (within the funciton body). The issue only arises when argument association is done, which is done where Harald and I have the patch. Do we know that the function will be an actual argument associated with an allocatable dummy argument when gfc_expr_attr is invoked? -- Steve
Re: coarrays using extended precision (80 bits) ?
On Sat, Apr 22, 2023 at 07:46:12AM -0300, Jorge D'Elia wrote: > > On Fri, Apr 21, 2023 at 08:33:31AM -0300, Jorge D'Elia wrote: > >> > >> One question: is there any chance of encoding with coarrays using > >> extended precision (80 bits) at least inside a multicore computer? > >> (as if to simplify a bit). > >> > >> To date, the possibility of using double precision (64 bits) or > >> extended precision (80 bits) is an alternative in our production > >> code, but sometimes we would like to do computations in > >> 80 bits and, in certain parts, there are coarrays. > >> We have validated even in quadruple precision (128 bits), using > >> ifort although, as is well known, the CPU times are largely > >> excessive. > >> > > Well, I just installed OpenCoarray and downloaded a pi/4 > > monte carlo code that Thomas wrote using REAL. I changed > > everything to use REAL(10). Compiled and executed without > > a problem. I also tested REAL(16), which worked although > > it's painfully slow due to software floating point. So, > > I guess I don't understand what you're asking? > > > > Thanks a lot for your answer. Now: > > Since we were noticing numerical issues in certain cases in our code, > we moved on to a toy model. The toy model is based on a standard LU > factorization with a dense block-distributed system matrix. So: > > 1/2) When we use gfortran+opencoarrays: > The verification computation of the numerical solution of the system > of equations is OK if we use precision either (single, double, extended, > quadruple) when the number Z of images is equal to 1. It is also OK if > we use precision either (single, double) when Z>1. But it fails if we > use precision either (extended, quadruple) when Z>1. > > 2/2) When we use ifort: > The verification computation of the numerical solution of the system > of equations is OK if we use precision either (single, double, quadruple) > either when Z=1 or when Z>1. We cannot check it in extended precision > because ifort does not support the use of extended precision. > > As a first attempt to explain the discrepancy, we assume that those > verification failures in the solution could be attributed to > gfortran+opencoarrays not quite correctly transmitting numbers in > extended precision, because opencoarrays relies on some standard MPI > for single and double precision (it would be like this?). This might be a bug in OC or gfortran or both. It is unclear if there is any further work being done on OC. If the LU toy code is short enough, you might try compiling it with -fcoarray=lib -fdump-tree-original to see if there are any obvious function argument mismatches in the underlying code. I looked more closely at Thomas's code. It was passing integer arrays between images while the images internally used REAL(10). If it's an argument passing issues with REAL(10), his code would not expose it. -- Steve
Re: coarrays using extended precision (80 bits) ?
On Fri, Apr 21, 2023 at 08:33:31AM -0300, Jorge D'Elia wrote: > Dear GFortran developers, > > One question: is there any chance of encoding with coarrays using > extended precision (80 bits) at least inside a multicore computer? > (as if to simplify a bit). > > To date, the possibility of using double precision (64 bits) or > extended precision (80 bits) is an alternative in our production > code, but sometimes we would like to do computations in > 80 bits and, in certain parts, there are coarrays. > We have validated even in quadruple precision (128 bits), using > ifort although, as is well known, the CPU times are largely > excessive. > > Thanks in any case. > Well, I just installed OpenCoarray and downloaded a pi/4 monte carlo code that Thomas wrote using REAL. I changed everything to use REAL(10). Compiled and executed without a problem. I also tested REAL(16), which worked although it's painfully slow due to software floating point. So, I guess I don't understand what you're asking? -- Steve
Re: ping Re: [PATCH 3/3] Fortran: Fix mpz and mpfr memory leaks
On Mon, Apr 17, 2023 at 09:47:50PM +0200, Bernhard Reutner-Fischer via Fortran
wrote:
> Ping!
>
> Harald fixed the leak in set_exponent in the meantime.
> As stated in the cover-letter, it was bootstrapped and regtested
> without regression on x86_64-foo-linux.
>
> I consider it obvious, but never the less, OK for trunk (as in gcc-14)
> so far?
See below.
>
> On Mon, 03 Apr 2023 23:42:06 +0200
> Bernhard Reutner-Fischer wrote:
>
> > On 3 April 2023 21:50:49 CEST, Harald Anlauf wrote:
> > >Hi Bernhard,
> > >
> > >there is neither context nor a related PR with a testcase showing
> > >that this patch fixes issues seen there.
> >
> > Yes, i forgot to mention the PR:
> >
> > PR fortran/68800
> >
> > I did not construct individual test cases but it should be obvious that we
> > should not leak these.
> >
> > >
> > >On 4/2/23 17:05, Bernhard Reutner-Fischer via Gcc-patches wrote:
> > >> From: Bernhard Reutner-Fischer
> > >>
> > >> Cc: fortran@gcc.gnu.org
> > >>
> > >> gcc/fortran/ChangeLog:
> > >>
> > >> * array.cc (gfc_ref_dimen_size): Free mpz memory before ICEing.
> > >> * expr.cc (find_array_section): Fix mpz memory leak.
> > >> * simplify.cc (gfc_simplify_reshape): Fix mpz memory leaks in
> > >> error paths.
> > >> (gfc_simplify_set_exponent): Fix mpfr memory leak.
> > >> ---
> > >> gcc/fortran/array.cc| 3 +++
> > >> gcc/fortran/expr.cc | 8
> > >> gcc/fortran/simplify.cc | 7 ++-
> > >> 3 files changed, 13 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
> > >> index be5eb8b6a0f..8b1e816a859 100644
> > >> --- a/gcc/fortran/array.cc
> > >> +++ b/gcc/fortran/array.cc
> > >> @@ -2541,6 +2541,9 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen,
> > >> mpz_t *result, mpz_t *end)
> > >> return t;
> > >>
> > >> default:
> > >> + mpz_clear (lower);
> > >> + mpz_clear (stride);
> > >> + mpz_clear (upper);
> > >> gfc_internal_error ("gfc_ref_dimen_size(): Bad dimen_type");
> > >> }
> > >
> > > What is the point of clearing variables before issuing
> > > a gfc_internal_error?
> >
> > To make it obvious that we are aware that we allocated these.
I must admit I agree with Harald on this portion
of the diff. What's the point? There is alot more
allocated than just those 3 mzp_t variables when the
internal error occurs. For example, gfortran does not
walk the namespaces and free those before the ICE.
I suppose silencing valgrind might be sufficient
reason for the clutter. So, ok.
> > >> _exp->where, shape[rank], rank+1);
> > >> + mpz_clear (index);
> > >>return _bad_expr;
> > >> }
These types of changes are 'ok'. IIRC, gfortran
will queue an error, and then forge on trying to
match the code with other matchers. If successful,
the error is tossed, so this would be a memory leak.
--
Steve
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
On Fri, Apr 14, 2023 at 09:49:22PM +0200, Harald Anlauf wrote: > > On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote: > > I was wondering about the difference between set_exponent() > > and scale(), and found that set_exponent() talks about IEEE > > values while scale() doesn't. I'm wondering if we should > > add the IEEE special cases to the testsuite. Of particular > > note, I doubt that this is true: > > > > If X is an IEEE NaN, the result is the same NaN. > > > > program foo > > real x, y > > x = 1 > > y = x - x > > x = (x - x) / y > > print '(F4.0,1X,Z8.8)', x, x > > y = set_exponent(x,1) > > print '(F4.0,1X,Z8.8)', y, y > > end program foo > > > > gfcx -o z a.f90 && ./z > > NaN FFC0 > > NaN 7FC0 > > > > Those are not the same NaN. The second is a qNaN. > > The first looks like a qNaN with the sign bit set. > > Until now there was no testing at all of SET_EXPONENT in the testsuite. > It would be really good to have better coverage of compile-time and > runtime behavior of the intrinsics and checking consistency ... ;-) > > I think you have much more experience in that area. (Hint!) > I might have some experience. :-) Unfortunately, I have no time (for at least 4-5 years) to jump down that rabbit hole (as I would try to fix things ;-). However, writing testcases to exercise the intrinsic subprograms is something that the LURKERS here in the mailing list might comtemplate. Any takers? Note returning the 'same Nan" is not special to set_exponent(). At least, fraction() and rrspacing() have "If X is an IEEE NaN, the result is that NaN." Oh, and thanks for your relentless assault on bugs. -- Steve
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
On Fri, Apr 14, 2023 at 12:33:18PM -0700, Steve Kargl via Fortran wrote: > >If X is an IEEE NaN, the result is the same NaN. > A better testcase as gfortran will quiet a NaN on assignment. program foo integer i equivalence(i,y) i = int(z'7FC0BEEF',4) ! Add payload to NaN. print '(F4.0,2(1X,Z8.8))', y, y, set_exponent(y,1) end program foo gfortran -o z a.f90 && ./z N 7FC0BEEF 7FC0 -- Steve
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
On Fri, Apr 14, 2023 at 08:59:24PM +0200, Harald Anlauf via Fortran wrote: > > the compile-time simplification of intrinsic SET_EXPONENT was > broken since the early days of gfortran for argument X < 1 > (including negative X) and for I < 0. I identified and fixed > several issues in the implementation. The testcase explores > argument space comparing compile-time and runtime results and > is checked against Intel. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes, it is certainly better than the current situation. > This is not a regression, but can lead to wrong code. > Would it be OK to backport to open branches? Sure. Looks simply and fairly specific. I was wondering about the difference between set_exponent() and scale(), and found that set_exponent() talks about IEEE values while scale() doesn't. I'm wondering if we should add the IEEE special cases to the testsuite. Of particular note, I doubt that this is true: If X is an IEEE NaN, the result is the same NaN. program foo real x, y x = 1 y = x - x x = (x - x) / y print '(F4.0,1X,Z8.8)', x, x y = set_exponent(x,1) print '(F4.0,1X,Z8.8)', y, y end program foo gfcx -o z a.f90 && ./z NaN FFC0 NaN 7FC0 Those are not the same NaN. The second is a qNaN. The first looks like a qNaN with the sign bit set. -- Steve
replacing hardware?
All, The systems that I've used while hacking on gfortran bugs and features are starting to show their age. I'm in the early stage of put together the wishlist for a budget friendly replacement. While I'll likely go with a Ryzen7 cpu, NVME M2 drives, and as much memory as I can afford, I'm looking for recommendations for a budget friendly video/gpu card that will allow me to take a deeper dive into openacc/openmp and offloading. Anyone have a suggestion? Note, I've mostly used FreeBSD over the last 25+ years. I suspect that pursuing offloading may be easier with a flavor linux. Any recommendation would also be appreciated. -- Steve
Re: [PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.
On Thu, Mar 30, 2023 at 07:39:55PM +0200, Thomas Koenig via Fortran wrote:
> Hi Andrew,
>
> > "long long". This was just an oversight and a missing check.
> >
> > Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
>
> Thanks!
>
> I think this one is obvious enough that it deserves a backport.
> I've cherry-picked this for gcc12, will do gcc11 tomorrow.
>
The patch is incomplete.
module foo
use, intrinsic :: iso_c_binding
implicit none
public :: bar
type, bind(c) :: bar
real(10) a
end type
end module
This yields
typedef struct bar {
long_double a /* WARNING: Converting 'REAL(10)' to interoperable type */;
} bar;
That should be 'long double'.
--
Steve
Re: [patch, Fortran] Enable -fwrapv for -std=legacy
On Fri, Mar 10, 2023 at 07:01:29PM +0100, Richard Biener via Fortran wrote: > > > > Am 10.03.2023 um 18:54 schrieb Thomas Koenig via Fortran > > : > > > > 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. > > The „problem“ is latent forever, I’m not sure it’s good to > amend the kitchen-sink std=legacy option with -fwrapv since > that has quite some negative effects on optimization. In that case, it would then seem logical to remove whatever patch was added to -O3 that causes the massive regression with rnflow.f90 and add it instead to -Ofast. -Ofast at least hints that is unsafe to use. -- Steve
Re: [Patch, fortran] PR37336 finalization
On Thu, Mar 09, 2023 at 08:18:08AM +, Richard Biener wrote: > > the existing comment already explains the issue. I suppose > -fdefault-integer-8 would also work around the issue? > Please, no. -fdefault-* options should have been removed from gfortran years ago. Without a careful review, one might be stepping into a minefield, because the -fdefault-* option break storage association rules. If you want to use an option, then you likely want -finteger-4-integer-8. This option preserves storage association. -- Steve
Re: [Patch, fortran] PR37336 finalization
On Wed, Mar 08, 2023 at 07:32:55AM +, Paul Richard Thomas wrote: > > Could you please review the patch on that self same time scale? I would be > happy to have feedback one file at a time. > Yes, I'll commit time to review individual patches. Smaller patches are typically easier to review. As to other topics in the thread, I suspect you won't find a lot of open-source Fortran project that make heavy use of finalization. This is likely due to gfortran's current lack of robust support. There, however, must some implicit finalization already occurring. For one of my codes, I see % foreach i (*.o) foreach? nm $i | grep final foreach? end 0280 T __beamsm_MOD___final_beamsm_Table_t 0580 T __bsam_MOD___final_bsam_Bsa_info_t 01e0 T __bsam_MOD___final_bsam_Bsa_t 00a0 T __ffn_data_MOD___final_ffn_data_Fe_t I do not explicitly use finalization nor do I have subprograms named __final_*. To me, this re-inforces Richard's point about not breaking existing code. -- Steve
Re: [Patch, fortran] PR37336 finalization
On Tue, Mar 07, 2023 at 03:58:32PM +0100, Thomas Koenig via Fortran wrote: > Paul, > > first of all, thank you very much indeed for the hard work you put into > this! This is a great step for gfortran. Ditto**2 > > I can hurry this along to get the patch > > into 13-branch or I can wait until 14-branch opens. > > Personally, I think that this fixes so many bugs, and makes > the compiler so much better, that I would prefer having it > in gcc-13. Finalization was only of very limited use before, > and the risk of meaningful regressions (short of a build > failure) is therefore very low. > I agree with Thomas. The main branch is in stage 4, which is regression and documentation fixing mode. I would think the number of bugs fixed by your patch can be argued as fixing regressions. I can set aside some time on Saturday to help with a review (if required). -- Steve
Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]
On Fri, Mar 03, 2023 at 10:24:07PM +0100, Mikael Morin wrote: > Hello, > > Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit : > > On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote: > > > - if (attr->class_ok) > > > -/* Class container has already been built. */ > > > + /* Class container has already been built with same name. */ > > > + if (attr->class_ok > > > + && ts->u.derived->components->attr.dimension >= attr->dimension > > > + && ts->u.derived->components->attr.codimension >= attr->codimension > > > + && ts->u.derived->components->attr.class_pointer >= attr->pointer > > > + && ts->u.derived->components->attr.allocatable >= > > > attr->allocatable) > > > > I suppose I'm a bit confused here. dimension, codimension, > > pointer and allocatable are 1-bit bitfields in the attr > > struct. These can have the values 0 and 1, so the above > > conditionals are always true. > > > as I understand it, they aren't if attr has attributes that aren't already > set in the class container's first component. > a >= b == !(a < b) and if a and b are boolean-valued, a < b == !a && b. > Admittedly, I haven't tested the logic like Harald has. > Mikael, thanks for smacking me with the clue stick. I had to do a quick test to see the trees. % cc -o z a.c && ./z a.i = 0, b.i = 0, a.i >= b.i = 1 a.i = 1, b.i = 0, a.i >= b.i = 1 a.i = 1, b.i = 1, a.i >= b.i = 1 a.i = 0, b.i = 1, a.i >= b.i = 0 I was overlooking the last case. So, the above is an all or nothing test. -- steve
Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote: > - if (attr->class_ok) > -/* Class container has already been built. */ > + /* Class container has already been built with same name. */ > + if (attr->class_ok > + && ts->u.derived->components->attr.dimension >= attr->dimension > + && ts->u.derived->components->attr.codimension >= attr->codimension > + && ts->u.derived->components->attr.class_pointer >= attr->pointer > + && ts->u.derived->components->attr.allocatable >= attr->allocatable) I suppose I'm a bit confused here. dimension, codimension, pointer and allocatable are 1-bit bitfields in the attr struct. These can have the values 0 and 1, so the above conditionals are always true. The rest of the patch looks reasonable. If Tobias has no objections or comments, it's ok to commit once the above is explained. -- Steve
Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]
On Thu, Mar 02, 2023 at 01:07:32AM +0100, Bernhard Reutner-Fischer wrote: > On Wed, 1 Mar 2023 07:39:40 -0800 > Steve Kargl via Gcc-patches wrote: > > > In fact, Hollerith should be hidden behind a -fallow-hollerith > > option and added to -std=legacy. > > While i'd be all for that, in my mind this will block off literally all > consultants and quite some scientists unless we error out > with a specific hint to an option that re-enable this. > > So yea, but please forgivingly for the decades to come? > It has already been decades. It seems to me that only way to motivate people to fix their code is to nag. Hollerith is pre-F77 era code. gfortran already provide a warning. The warning should be made into an error, and yes, it can point to -fallow-hollerith. The option would downgrade the error to a warning. The only way to suppress the warning is to suppress all warnings with -w. See -fallow-invalid-boz. % cat > a.f90 program foo! free-form source code is post-f77. real :: b = 4H1234 ! No code, in particular, legacy has print *, b ! initialization expressions. end program foo % gfcx -o z a.f90 a.f90:2:14: 2 |real :: b = 4H1234 | 1 Warning: Extension: Conversion from HOLLERITH to REAL(4) at (1) a.f90:2:18: 2 |real :: b = 4H1234 | 1 Warning: Legacy Extension: Hollerith constant at (1) -- Steve
Re: [PATCH][stage1] Remove conditionals around free()
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran wrote: > libgfortran/caf/single.c |6 ++ > libgfortran/io/async.c |6 ++ > libgfortran/io/format.c |3 +-- > libgfortran/io/transfer.c|6 ++ > libgfortran/io/unix.c|3 +-- The Fortran ones are OK. -- Steve
Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]
On Wed, Mar 01, 2023 at 10:40:15AM +0100, Tobias Burnus wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> > @@ -0,0 +1,14 @@
> > +! { dg-do compile { target powerpc*-*-* } }
> > +! { dg-options "-O2 -mabi=ibmlongdouble" }
> > +
> > +! Test to ensure that it reports an "Unclassifiable statement" error
> > +! instead of throwing an ICE when the memory represent of the HOLLERITH
> > +! string is not unique with ibm long double encoding.
> > ...
> > + real(kind = k):: b = 4h1234
This should be rejected with an error message. Hollerith was
deleted from Fortran in Appendix C-1 of the Fortran 77 standard.
The appearance of a Hollerith entity in an initialization
expression has never be conforming.
In fact, Hollerith should be hidden behind a -fallow-hollerith
option and added to -std=legacy.
> diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
> index 64821c84543..b60d92a0665 100644
> --- a/gcc/fortran/intrinsic.cc
> +++ b/gcc/fortran/intrinsic.cc
> @@ -27,2 +27,3 @@ along with GCC; see the file COPYING3. If not see
> #include "intrinsic.h"
> +#include "diagnostic.h" /* For errorcount. */
>
> @@ -4622,2 +4623,3 @@ do_simplify (gfc_intrinsic_sym *specific, gfc_expr *e)
>gfc_actual_arglist *arg;
> + int old_errorcount = errorcount;
>
> @@ -4710,3 +4712,7 @@ finish:
>if (result == _bad_expr)
> -return false;
> +{
> + if (errorcount == old_errorcount)
> + gfc_error ("Cannot simplify expression at %L", >where);
> + return false;
> +}
I'm okay with this suggestion.
--
Steve
Re: [PATCH] Fortran: fix corner case of IBITS intrinsic [PR108937]
On Mon, Feb 27, 2023 at 09:54:38PM +0100, Harald Anlauf via Fortran wrote: > > as found by the reporter, the result of the intrinsic IBITS > differed from other compilers (e.g. Intel, NAG) for the corner > case that the LEN argument was equal to BIT_SIZE(I), which is > explicitly allowed by the standard. > > We actually had an inconsistency for this case between > code generated by the frontend and compile-time simplified > expressions. > > The reporter noticed that this is related to a restriction in > gcc that requires that shift widths shall be smaller than the > bit sizes, and we already special case this for ISHFT. > It makes sense to use the same special casing for IBITS. > > Attached patch fixes this and regtests on x86_64-pc-linux-gnu. > > OK for mainline? Yes. Good catch on comparison with simplification, which I failed to consider last night. > This issue has been there for ages. Shall this be backported > or left in release branches as is? As always, backporting is up to you and your bandwidth. Bring the the run-time result and simplification into agreement suggests that a back port is a good thing. -- Steve
Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"
On Thu, Feb 23, 2023 at 07:24:26AM -0800, Damian Rouson wrote: > I wonder if a relatively easy starting point would be enabling the > declaration of do concurrent construct variables: > > do concurrent (integer :: i = 1:n) > > It’s a minor convenience and less exciting than adding locality specifiers > but possibly a good first exercise. > > > Damian I've already implemented 95% of the above. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 Unfortunately, the last 5% will take me too much time, which I don't have at the moment. Problems arise from the parsing of an iterator is shared by do current, forall, implied-do, and good old do-loops. For the first 3, 'i' is a control variable and is a statement entity (i.e., in the namespace of construct). To do a type spec in one of these cleanly, it would be prudent to either define a namespace for the construct or to use a shadow variable. The shadow variablei, which I was leaning towards, would replace the above with something like do concurrent (integer :: _i = 1:n) '_i' cannot conflict 'i', but this requires walking the execution block of the construct and replacing 'i' with '_i'. Perhaps, starting with the patch in PR96255 would be gentle intro to gfortran hacking. -- Steve
Re: [PATCH] Fortran: reject invalid CHARACTER length of derived type components [PR96024]
On Tue, Feb 21, 2023 at 10:18:58PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > the attached simple patch detects and rejects CHARACTER components > of derived types whose length specification is non-integer. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > This PR is also marked as a 10/11/12/13 regression, so I would > like to backport this as far as it seems reasonable. > OK. Backports are fine with me, but give others a chance to comment. Thanks for continuing to pursue the backlog of bug reports. -- Steve
Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types
On Mon, Feb 20, 2023 at 07:56:14AM +0100, Tobias Burnus wrote: > On 17.02.23 17:27, Steve Kargl wrote: > > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote: > > > OK for mainline? > > Short version: no. > > Would you mind to write a reasoning beyond only a single word? > > > > subroutine foo(n) > > >integer :: n > > >integer :: array(n*5) > > >integer :: my_len > > >... > > >my_len = 5 > > >block > > > character(len=my_len, kind=4) :: str > > > > > > my_len = 99 > > > print *, len(str) ! still shows 5 - not 99 > > >end block > > > end > > Are you sure about the above comment? > > Yes - for three reasons: > * On the what-feels-right side: It does not make any sense to print > any other value than 5 given that 'str' has been declared with len = 5. > * On the GCC side, the SAVE_EXPR ensures that the length is evaluated > early and then "saved" to ensure its original value is available > * The quoted text from the standard implies that this is what > should happen. Your comment in the above code suggest to me that you expected 99. Of course, the print statement should produce 5 and that is what gfortran does. If your patch only effects deferred character types, why are you including a useless code example. -- steve
Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types
On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> Short version:
>
> This fixes potential and real bugs related to 'len=:' character variables
> as for the length/byte size an old/saved expression is used instead of
> the current value. - That's fine but not for allocatable/pointer with 'len=:'.
>
>
> Main part of the patch: Strip the SAVE_EXPR from the size expression:
>
> if (len && deferred && TREE_CODE (TYPE_SIZE (type)) == SAVE_EXPR)
> {
> gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (type)) == SAVE_EXPR);
> TYPE_SIZE (type) = TREE_OPERAND (TYPE_SIZE (type), 0);
> TYPE_SIZE_UNIT (type) = TREE_OPERAND (TYPE_SIZE_UNIT (type), 0);
> }
>
>
> OK for mainline?
Short version: no.
>
> * * *
>
> Long version:
>
> BACKGROUND:
>
>
> (A) VLA / EXPLICIT-SIZE ARRAYS + LEN= STRINGS
>
>
> C knows something like VLA (variable length arrays), likewise Fortran
> knows explicit size array and character length where the length/size
> depends on an variable set before the current scoping unit. Examples:
>
> void f(int N)
> {
> int vla[N*5];
> }
>
> subroutine foo(n)
> integer :: n
> integer :: array(n*5)
> integer :: my_len
> ...
> my_len = 5
> block
> character(len=my_len, kind=4) :: str
>
> my_len = 99
> print *, len(str) ! still shows 5 - not 99
> end block
> end
Are you sure about the above comment? At the time
that str is declared, it is given a kind type parameter
of len=5 and kind=4. After changing my_len to 99
the kind type parameter of str does not change.
8.3 Automatic data objects
If a type parameter in a declaration-type-spec or in a char-length
in an entity-decl for a local variable of a subprogram or BLOCK
construct is defined by an expression that is not a constant
expression, the type parameter value is established on entry to a
procedure defined by the subprogram, or on execution of the BLOCK
statement, and is not affected by any redefinition or undefinition
of the variables in the expression during execution of the
procedure or BLOCK construct.
--
steve
Re: [PATCH, committed] Fortran: error recovery on invalid assumed size reference [PR104554]
On Wed, Feb 15, 2023 at 10:28:00PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > I've committed the attached obvious and trivial patch for a NULL > pointer dereference on behalf of Steve and after regtesting on > x86_64-pc-linux-gnu as r13-6066-ga418129273725fd02e881e6fb5e0877287a1356c > Thanks Harald! -- Steve
Re: Support for NOINLINE attribute
On Fri, Feb 10, 2023 at 10:07:24PM +0100, Harald Anlauf via Fortran wrote: > Hello all, > > I actually like the idea of supporting the suggested attributes, > provided they work and behave the same way with and without LTO. > > - NOINLINE: I disagree with Steve here; we shouldn't invent a new > syntax (noinline on/off), and rather follow what other compilers > provide (INLINE/NOINLINE). I wasn't proposing any specific syntax. I was asking if the attribute could be toggled on/off as the pseudocode showed. -- Steve
Re: Support for NOINLINE attribute
On Fri, Feb 10, 2023 at 10:38:04AM +0200, Rimvydas Jasinskas wrote: > On Fri, Feb 10, 2023 at 10:24 AM Steve Kargl via Fortran > wrote: > > > would it be possible to extend gfortran attribute support to handle > > > NOINLINE too? Like: "!GCC$ ATTRIBUTES noinline :: ...". > > > > It looks to me like you are conflating three independent topics. > > What does NOINLINE have to do with WEAK? What does WEAK have > > to do with NORETURN? > > As I wrote these are optional (different issues, quite useful to have > but still easy to work around with different means), the main issue is > still missing NOINLINE for -flto. Unfortunately, conflating unrelated topics can lead to distraction. I do however see value in NORETURN. I suppose a person writing a library may find WEAK useful. > > More importantly what is the effect of NOINLINE if a user > > does not specify the -flto option? Does this block inlining > > regardless of LTO? > > > > -- > > steve > Yes, there is no way to differentiate between LTO and non-LTO > compilations (at least from what I have seen in the code). > As long as subroutines/functions are in separate compilation units, > this has no effect for non-LTO builds anyway. Main issue is to deal > with unintentional over inlining between different compilation units > with lto1 backend. I haven't studied your patch in detail, so apologies up front if this is already available. Can attribute be applied to only a block of code in a file?. Suppose there are 3 functions in a file. Can the attribute be toggled on and off? Something like function bar() ... end function bar() !GCC$ ATTRIBUTES noinline on function foo() ... end function foo() !GCC$ ATTRIBUTES noinline off function bah() ... end function bah() bar() and bah() can be inlined while inlining foo() is prevented. -- Steve
Re: Support for NOINLINE attribute
On Fri, Feb 10, 2023 at 07:42:47AM +0200, Rimvydas Jasinskas via Fortran wrote: > Hello everyone, > > would it be possible to extend gfortran attribute support to handle > NOINLINE too? Like: "!GCC$ ATTRIBUTES noinline :: ...". It looks to me like you are conflating three independent topics. What does NOINLINE have to do with WEAK? What does WEAK have to do with NORETURN? More importantly what is the effect of NOINLINE if a user does not specify the -flto option? Does this block inlining regardless of LTO? -- steve
Re: [PATCH] fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451]
On Fri, Feb 03, 2023 at 08:03:36PM +0100, Jakub Jelinek via Fortran wrote: > Hi! > > The first testcase in the PR (which I haven't included in the patch because > it is unclear to me if it is supposed to be valid or not) ICEs since extra > hash table checking has been added recently. The problem is that > gfc_trans_use_stmts does > tree *slot = entry->decls->find_slot_with_hash (rent->use_name, > hash, > INSERT); > if (*slot == NULL) > and later on doesn't store anything into *slot and continues. Another spot > a few lines later correctly clears the slot if it decides not to use the > slot, so the following patch does the same. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > Yes. See my comment in the PR about the testcases being invalid Fortran. -- Steve
Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Tue, Jan 31, 2023 at 10:38:02PM +0800, LIU Hao wrote: > 在 2023-01-31 21:13, Thomas Schwinge 写道: > > Hi! > > > > On 2023-01-30T14:50:08-0800, Steve Kargl via Fortran > > wrote: > > > Does the skull and crossbones convey anymore info than the rest of > > > the subject line > > > > > > Buildbot (Sourceware): gcc - failed configure (failure) (master) > > > > They convey as much additional information as does (automated) colorful > > syntax highlighting, or (manual) source code line indentation: "none" to > > some, "a lot" to others. > > > > > > First, I'd argue that 'emoji characters imply spammer' makes little sense. > Everyone can examine the source of all messages in this thread and their > `X-Spam-Status` headers. The fact is that, so far no message had been given > a tag for having emoji/bad/obfuscated characters in its subject. > The irony! Your email ended up in one of my spam folders. X-junkfilter: 20020519 X-Spammer: bodychk-domains: 126.com> domains: 126.com -- Steve
Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Mon, Jan 30, 2023 at 11:07:46PM +0100, Gerald Pfeifer wrote: > On Mon, 30 Jan 2023, Steve Kargl via Gcc wrote: > > Bingo. In the case of non-[a-zA-Z] characters in the > > Subject (or Fromi or To) line, the spam folder is normally > > named /dev/null. > > Hmm, so any digit, parenthesis, or bracket in the Subject, and mails gets > to /dev/null? I suppose I should have just noted characters should be members of the Processor Character Set (18-007r1.pdf, Sec. 6.1), but I suspect some here have no idea what that means. > Or having an umlaut or other special character in one's name - which is > pretty common in parts of the world like Central Europe? umlaut and other special chars can trigger spam filters. Whitelisting is used for those that matter. Does the skull and crossbones convey anymore info than the rest of the subject line Buildbot (Sourceware): gcc - failed configure (failure) (master) -- Steve
Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Mon, Jan 30, 2023 at 03:46:30PM +0100, Thomas Koenig wrote: > On 30.01.23 14:52, Mark Wielaard wrote: > > Hi Steve, > > > > On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote: > > > Please remove the skull and cross bones in the subject line. > > > > That is the default "hazard symbol" buildbot uses if a build turns from > > success to failure. If you have a better suggestion you might want to > > contact upstream https://buildbot.net/ We'll pick up the new default > > when we'll upgrade. > > > > Or if you think we should use a custom email template: > > https://docs.buildbot.net/latest/manual/configuration/report_generators/formatter.html > > You can provide a patch to build...@sourceware.org. > > The code for our instance can be found here: > > https://sourceware.org/git/builder.git > > I usually put e-mails with such unicode characters into my spam folder > automatically. > > If that's what you want, that is fine with me. > Bingo. In the case of non-[a-zA-Z] characters in the Subject (or Fromi or To) line, the spam folder is normally named /dev/null. -- Steve
Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Sun, Jan 29, 2023 at 07:49:35PM +, Sam James via Fortran wrote: > > > > On 29 Jan 2023, at 19:36, Jerry D via Gcc wrote: > > > > I had this show up today. I have no idea what this is about. > > > > Please advise. > > > > Sorry Jerry, false positive -- something went wrong with > the builder. Disregard. > > We're still setting things up there. > Please remove the skull and cross bones in the subject line. -- Steve
Re: [PATCH] Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]
On Sat, Jan 28, 2023 at 06:07:50PM +0100, Harald Anlauf via Fortran wrote: > > a USE associated symbol shall not appear in a COMMON block > (F2018:C8121) and needs to be diagnosed. The patch is > fairly obvious. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > As the PR is marked as a 10/11/12/13 regression, > I plan to backport as appropriate. > Yes. Backports are fine with a clean regression test. Thanks for the patch and your continued attack on bugzilla issues. -- Steve
Re: [PATCH] Fortran: fix ICE in check_host_association [PR108544]
On Wed, Jan 25, 2023 at 10:59:22PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > the attached patch fixes two issues: first it addresses a NULL pointer > dereference on invalid input, triggered by the provided testcase. > > Second, while analyzing the context of the affected code, I looked into > the testcase for PR96102, and by varying it slightly, i.e. replacing > functions by subroutines I found that we accept invalid code that is > rejected by several other brands tested. To fix this, I removed one > line of a condition that did not seem to make sense to me. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. I briefly looked at this by simply commenting out the assert, which gives too many odd error messages. Returning 'false' seems to be best. -- Steve
Re: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]
On Mon, Jan 23, 2023 at 10:23:54PM +0100, Harald Anlauf via Fortran wrote: > > 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. I agree patch looks obvious once the issue is found. Thanks for the patch. -- Steve
Re: [PATCH] Fortran: avoid ICE on invalid array subscript triplets [PR108501]
On Mon, Jan 23, 2023 at 09:34:59PM +0100, Harald Anlauf via Fortran wrote: > > we did not check array element triplets for validity strictly enough > (i.e. defensively in the case of invalid code), so we could encounter > non-integer constant expressions that were passed to mpz_get_si. > > The attached obvious patch tries to fix all such potential issues > in get_expr_storage_size. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: Error on left hand function reference
On Thu, Jan 12, 2023 at 02:31:12AM +, Jerry DeLisle via Fortran wrote: > Hi all, > > I spotted this today on the Fortran-Lang Discourse. > > It would not be setting precednce for us to allow an extension and turn > this into a warning with -std=gnu and an error of strict compliance is > wanted. > > https://fortran-lang.discourse.group/t/error-the-leftmost-part-ref-in-a-data-ref-cannot-be-a-function-reference/4990 > > I will create a PR and chase this one if concurrence here. > > Opinions? > gfortran's current behavior is standard conforming. Personally, I think this should not be implemented in gfortran. If you do scratch the itch, then please hide it behind some option such as -fallow-nonconforming-Fortran-leftmost-part-reference-function-component. Please, do not enable it under -std=gnu (which should be deprecated in favor of -std=f2018 and then -std=f2023). Putting it under -std=gnu would imply that it will be supported in future versions of gfortran and would need to support whatever is implemented now and whatever might get standardized in the future. I'll send end by noting that there are several unimplemented F2018 features and F2023 will be approved in the April-ish timeframe. -- Steve
Re: [PATCH] libgfortran: Replace mutex with rwlock
On Wed, Dec 21, 2022 at 07:27:11PM -0500, Lipeng Zhu via Fortran wrote: > This patch try to introduce the rwlock and split the read/write to > unit_root tree and unit_cache with rwlock instead of the mutex to > increase CPU efficiency. In the get_gfc_unit function, the percentage > to step into the insert_unit function is around 30%, in most instances, > we can get the unit in the phase of reading the unit_cache or unit_root > tree. So split the read/write phase by rwlock would be an approach to > make it more parallel. > > BTW, the IPC metrics can increase from 0.25 to 2.2 in the Intel > SRP server with 220 cores. The benchmark we used is > https://github.com/rwesson/NEAT > The patch fails bootstrap on x86_64-*-freebsd. gmake[6]: Entering directory '/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src/c++17' /bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile /home/kargl/gcc/obj/./gcc/xgcc -shared-libgcc -B/home/kargl/gcc/obj/./gcc -nostdinc++ -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src/.libs -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/libsupc++/.libs -B/home/kargl/work/x86_64-unknown-freebsd14.0/bin/ -B/home/kargl/work/x86_64-unknown-freebsd14.0/lib/ -isystem /home/kargl/work/x86_64-unknown-freebsd14.0/include -isystem /home/kargl/work/x86_64-unknown-freebsd14.0/sys-include -fno-checking -I/home/kargl/gcc/gcc/libstdc++-v3/../libgcc -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0 -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include -I/home/kargl/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++ -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo -fimplicit-templates -g -O2 -c -o floating_from_chars.lo ../../../../../gcc/libstdc++-v3/src/c++17/floating_from_chars.cc libtool: compile: /home/kargl/gcc/obj/./gcc/xgcc -shared-libgcc -B/home/kargl/gcc/obj/./gcc -nostdinc++ -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src/.libs -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/libsupc++/.libs -B/home/kargl/work/x86_64-unknown-freebsd14.0/bin/ -B/home/kargl/work/x86_64-unknown-freebsd14.0/lib/ -isystem /home/kargl/work/x86_64-unknown-freebsd14.0/include -isystem /home/kargl/work/x86_64-unknown-freebsd14.0/sys-include -fno-checking -I/home/kargl/gcc/gcc/libstdc++-v3/../libgcc -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0 -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include -I/home/kargl/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo -fimplicit-templates -g -O2 -c ../../../../../gcc/libstdc++-v3/src/c++17/floating_from_chars.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o floating_from_chars.o In file included from /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/memory_resource:40, from ../../../../../gcc/libstdc++-v3/src/c++17/floating_from_chars.cc:37: /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex: In function 'int std::__glibcxx_rwlock_rdlock(pthread_rwlock**)': /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:80:3: error: call of overloaded '__gthrw_pthread_rwlock_rdlock(pthread_rwlock**&)' is ambiguous 80 | _GLIBCXX_GTHRW(rwlock_rdlock) | ^ In file included from /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0/bits/gthr.h:148, from /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/bits/std_mutex.h:41, from /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:41: /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:80:3: note: candidate: 'int std::__gthrw_pthread_rwlock_rdlock(pthread_rwlock**)' 80 | _GLIBCXX_GTHRW(rwlock_rdlock) | ^~ /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0/bits/gthr-default.h:140:1: note: candidate: 'int __gthrw_pthread_rwlock_rdlock(pthread_rwlock**)' 140 | __gthrw(pthread_rwlock_rdlock) | ^~~ /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex: In function 'int std::__glibcxx_rwlock_tryrdlock(pthread_rwlock**)': /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:81:3: error: call of overloaded
Re: [PATCH] Fortran: check for invalid uses of statement functions arguments [PR69604]
On Thu, Dec 22, 2022 at 10:13:04PM +0100, Harald Anlauf via Fortran wrote: > > the attached patch adds a check for statement function bodies for > invalid uses of dummy arguments. This fixes an ICE-on invalid. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: [PATCH] Fortran: a C interoperable function cannot have the CLASS attribute [PR95375]
On Tue, Dec 20, 2022 at 09:40:23PM +0100, Harald Anlauf via Fortran wrote: > > we obviously forgot to extend the C interoperability check of the > type of function results to CLASS variables and thus did not reject > them. Wrong code could lead to an ICE, see testcase by Gerhard. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: [Bug 106731] ICE on automatic array of derived type with DTIO: need help
On Thu, Dec 15, 2022 at 01:51:26PM +0100, Federico Perini via Fortran wrote: > > 3. Of the optimization flags "-fpeel-loops" is the one that triggers the > failing tests > > 3. in dtio_4.f90, the first test fails for 1) non-extended class; 2) > derived-type READ. Write works; extended type (BT_CLASS) works. It appears > that the optimizer thinks the derived type is not modified by the read > statement. Federico, thanks for following up here. As I indicated before, you're in an area of the compiler that I do not normally hack. But, the above description sounds like a tree is not marked as used. There is code of the form "TREE_USED (decl) = 1;" in the trans-*.cc files. Setting this might inhibit the -fpeel-loops optimization, but this is just a guess. -- Steve
Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]
On Mon, Dec 12, 2022 at 08:49:50PM +0100, Harald Anlauf via Fortran wrote:
>
> Committed as r13-4623-gcf5327b89ab610.
>
To be clear, I have no problems with this commit.
But, just a FYI, there is gfc_peek_ascii_char(),
which allows you to look at the next character
without having to keep track of the locus.
> +{
> + locus old_loc = gfc_current_locus;
> + if (gfc_match_char ('*') == MATCH_YES)
gfc_gobble_whitespace (); /* Can't remember if matching up to this
eats whitespace. */
if (gfc_peek_ascii_char () == '*')
> + {
> + /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
> + gfc_error ("A lower bound must precede colon in "
> + "assumed-size array specification at %L", _loc);
> + return AS_UNKNOWN;
> + }
> + else
> + {
gfc_current_locus = old_loc; /* Is this needed? */
> + return AS_DEFERRED;
> + }
> +}
--
Steve
Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]
On Sun, Dec 11, 2022 at 11:33:43PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached patch improves checking of array specs in two ways:
> - bad assumed size array spec
> - a bad first array element spec may already trigger an error,
> leading to a more consistent behavior
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
OK with minor nit.
> + /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
> + if (gfc_match (" : * ") == MATCH_YES)
> +{
> + gfc_error ("A lower bound must precede colon in "
> + "assumed size array specification at %C");
"assumed size" should likely be "assumed-size"
> + return AS_UNKNOWN;
> +}
> +
--
Steve
Re: [PATCH] Fortran: reject bad SIZE argument while simplifying ISHFTC [PR106911]
On Sat, Dec 10, 2022 at 10:14:06PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > we should not try to simplify ISHFTC if the SIZE argument > is known to be outside the allowed range. It's better to > generate an error by terminating the simplification. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: Team Collaboration Considerations
On Sat, Dec 10, 2022 at 12:10:20PM -0800, Jerry D wrote: > On 12/8/22 11:14 AM, Holcomb, Katherine A (kah3f) via Fortran wrote: > > I was thinking I might try to contribute when I retire, though that may be > > in a year or two. But it's been a very long time since I dove into a large > > software project and it's intimidating. I do know C (really C++, I haven't > > used plain C for a long time). I am one of those "aging" types but I am > > familiar at least superficially with newer tools because I must use them > > for work, specifically git and Slack (Mattermost seems to be an open-source > > Slack alternative) -- we make heavy use of Slack in particular. > > > > Is there some kind of "getting started" guide? > > > > Katherine Holcomb > > UVA Research Computing https://www.rc.virginia.edu > > ka...@virginia.edu434-982-5948 > > > > In your case I would recommend just pick a bug and start exploring it with > gdb and valgrind. There is no need to learn the whole project. If you > want, we could pick one for you as a starter. I will send you an invite to > the Mattermost so you can watch as we organize it. One thought we had is to > use "boards" for categories of bugs and use it as a way to triage the list > of bugs (ideas evolving) > Katherine's name appears in the copyright notice in intrinsic.h and intrinsic.c. The overall design has not changed from when g95 was imported to become gfortran. There are a few new intrinsics coming with F2023. Perhaps, this might be a point of entry (pun intended) for returning to gfortran hacking. Katherine, your return will be most welcomed. -- Steve
Re: [PATCH] Fortran: diagnose and reject duplicate CONTIGUOUS attribute [PR108025]
On Thu, Dec 08, 2022 at 10:59:42PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > a fairly obvious, or rather trivial fix that appeared while > analyzing another pr and that can be treated independently: > reject duplicate CONTIGUOUS attributes. > > (Intel and NAG reject this, Cray warns that this is non-standard.) > > Regtested on x86_64-pc-linux-gnu. OK for mainline? Yes, thanks for the patch. -- Steve
Re: Team Collaboration Considerations
On Wed, Dec 07, 2022 at 05:54:40PM -0800, Jerry D via Fortran wrote: > Other than Benson, I have received no sign of any interest from gfortran > developers to adopt a teaming/collaboration platform. I am a bit > disappointed. Maybe my intent was misunderstood. I am not suggesting > replacing the email approval process but there are many other features of > these platforms, in particular, communication efficiency that would be very > helpful. > > I know many software developers who use these tools regularly. Honestly I do > not know why gcc.gnu.org does not adopt one of these as a whole. Perhaps it > is simply resistance to change. > > I will keep the Mattermost workspace. If anyone want to join send me your > email and I will send you an invite. > > Well, as always, best regards, > Jerry, I think you're seeing the effects of the move to git and an aging base of contributors. Harald is almost single-handily dealing with bug reports. Mikeal has recently been reviewing Harald's patches, and offers some good advice on improvements. Occasionally, Thomas and I offer up patches, but this occurs in a rather sparse manner. In fact, if I fix a bug, the patch is attached to the bugzilla report where it sits until Harald stumbles across it or it bit rots. I don't know how to attract new contributors. I've invited more than one person who's pointed out a issue with gfortran to join the developers. This is typically met with "I don't know C", "I don't know compiler design", "I don't have time"r, ... -- Steve
Re: [PATCH] Fortran: handle zero-sized arrays in ctors with typespec [PR108010]
On Wed, Dec 07, 2022 at 09:57:20PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > we need to be careful about zero-sized arrays in arithmetic > reductions (unary & binary), as we otherwise may hit a NULL > pointer dereference on valid code. > > The actual fix is straightforward, see attached patch. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: Setup Install GCC compiler Issue
On Sun, Dec 04, 2022 at 01:49:51PM -0800, Demian Sanchez Lopez via Fortran wrote: > Hello Fortran Admin, > > I would love to begin my computer programming journey, but I am having > problems at the installation point. Where do I install the GCC compilers? I > accidentally deleted the location on the "Browse" stage. Please help. > Depends on the operating system and may be local policies. If you have admin rights on a Windows system, I'll suggest install WSL2 with ubuntu and use apt to install gfortran-11. -- Steve
Re: typespec in forall and implied-do
On Tue, Nov 22, 2022 at 10:15:39PM +0100, Harald Anlauf via Fortran wrote: > Minor addition: > > program foo > implicit none > real(8) :: i > integer, parameter :: q(*) = [(kind(i), integer :: i = 1, 3)] > print *, q > end program foo > > This prints > >8 8 8 > > although it should be all 4's. So we really need to create a local > namespace or even block to shadow the host's variable. > > Crayftn and NAG accept this too, Intel has a problem report on this. > I'll see if I can make the shadow variable idea work. For two lines integer, parameter :: q(3) = [(kind(i), integer :: i = 1, 3)] integer:: p(3) = [(kind(i), integer :: i = 1, 3)] I believe the paths through the compiler differ sufficiently, and the shado variable might help in keeping the change simple. -- Steve
Re: typespec in forall and implied-do
On Sun, Nov 20, 2022 at 10:28:40PM +0100, Harald Anlauf via Fortran wrote: > > for unknown reasons I cannot reply to your mail on gmane, > so trying directly via mailing list. > I forgot to address this. I updated my OS on Thursday afternoon, and when I rebooted, sendmail failed to start. It took me until noon-ish on Friday to restore the ability to use sendmail. Perhaps, the gmane mails were rejected while I was off-line. -- Steve
Re: typespec in forall and implied-do
On Sun, Nov 20, 2022 at 10:28:40PM +0100, Harald Anlauf via Fortran wrote:
> Steve,
>
> for unknown reasons I cannot reply to your mail on gmane,
> so trying directly via mailing list.
>
> I tried your patch, and it works on the supplied testcases.
>
> However, there is a scoping issue for the declaration of the
> index variable, as can be seen by the following variation:
>
> program foo
> use iso_fortran_env, only : k => real_kinds
> implicit none
> integer, parameter :: n = size(k)
> integer(8) :: i
> !!$ integer, parameter :: &
> !!$ & p(n) = [(precision(real(1.,k(i))), integer :: i = 1, n)]
> integer, parameter :: &
>& q(n) = [(kind(i), integer(2) :: i = 1, n)]
> integer, parameter :: &
>& r(n) = [(storage_size(i), integer(1) :: i = 1, n)]
> !!$ print *, p
> print *, q
> print *, r
> end program foo
>
> After your patch, gfortran prints:
>
>8 8 8 8
> 64 64 64 64
>
> This suggests that the integer kind is taken from the host decl,
> which is kind=8, and not the local one (2 or 1).
>
> Crayftn (which chokes on your original testcase):
>
> 3*2
> 3*8
>
> This is what I expect.
>
> Intel doesn't accept storage_size() here, which is a bug.
> Commenting the uses of array r, I then get:
>
>2 2 2
>
> At least this agrees with Cray.
>
> Can you have another look at this?
>
Unfortunately, gfortran does not define a namespace for an implied-do
index and uses a kludge by adding the attr.implied_index attribute to
the symbol. Unfortunately**2, gfortran uses gfc_match_iterator for
all places that 'i = start, stop [,step]' and there is no way to know
if what is being parsed. With the introduction of an optional typespec,
there is no easy way to deal with it in a clean way. Things get messy
quickly when trying to deal with implicit typing and explicitly typed
symbols. So, if the implied-do index has previously been typed such as
integer(8) i
print *, (i, integer(2) i=1, 3)
the integer(2) is ignored. That's this part of the gfc_match_iterator
diff
+ if (seen_ts && var->ts.type == BT_UNKNOWN)
+{
+ var->ts.type = ts.type;
+ var->ts.kind = ts.kind;
+ var->symtree->n.sym->ts.type = ts.type;
+ var->symtree->n.sym->ts.kind = ts.kind;
+}
Perhaps, a better way would be to simply create a shadow symbol
if a typespec appears in an iterator
print *, (i, integer i=1,3)
would become
print *, (_i, integer _i=1,3)
The issue is then that implied-do object list needs to be walked
and all occurrence of i must be replaced with _i.
--
Steve
Re: typespec in forall and implied-do
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> F2008 introduced the inclusion of a typespec in a forall
> statement, and thn F2018 a typespec was allowed in an
> implied-do. There may even be a few bug reports.
New patch and two test cases (don't know how add testcases under git).
Fixes pr78219 for forall. I thought, but cannot find, there is a PR
about implied-do.
* fortran/decl.cc: Place current_attr in global namespace. Needed ...
* fortran/expr.cc (gfc_reduce_init_expr): ... here. Handle an implied-do
loop in an initialization expression whre a type-spec has been given.
* fortran/match.cc (gfc_match_iterator): Match optional type-spec in
implied-do.
* fortran/match.cc (match_forall_header): Match optional type-spec in
forall-control-header.
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 0f9b2ced4c2..068eb6c4113 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -52,7 +52,7 @@ static int old_char_selector;
static gfc_typespec current_ts;
-static symbol_attribute current_attr;
+symbol_attribute current_attr;
static gfc_array_spec *current_as;
static int colon_seen;
static int attr_seen;
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 69d0b57c688..899c76f8cde 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3162,12 +3162,34 @@ gfc_check_init_expr (gfc_expr *e)
bool
gfc_reduce_init_expr (gfc_expr *expr)
{
+ extern symbol_attribute current_attr;
bool t;
gfc_init_expr_flag = true;
+
+ /* This block is need to reduce an initialization expression with an
+ implied-do loop where a type-spec is include, e.g.,
+
+ integer, parameter :: &
+ & p(n) = [(precision(real(1.,k(i))), integer :: i = 1, n)] */
+ if (expr
+ && expr->expr_type == EXPR_ARRAY
+ && expr->ts.type == BT_UNKNOWN
+ && current_attr.flavor == FL_PARAMETER
+ && gfc_current_ns->seen_implicit_none == 1)
+{
+ gfc_simplify_expr (expr, 1);
+ gfc_resolve_expr (expr);
+ if (!gfc_check_constructor_type (expr))
+ return false;
+ if (!gfc_expand_constructor (expr, true))
+ return false;
+}
+
t = gfc_resolve_expr (expr);
if (t)
t = gfc_check_init_expr (expr);
+
gfc_init_expr_flag = false;
if (!t || !expr)
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 8b8b6e79c8b..3fd2a80caad 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -968,9 +968,39 @@ gfc_match_iterator (gfc_iterator *iter, int init_flag)
gfc_expr *var, *e1, *e2, *e3;
locus start;
match m;
+ gfc_typespec ts;
+ bool seen_ts;
e1 = e2 = e3 = NULL;
+ /* Match an optional "integer ::" type-spec. */
+ start = gfc_current_locus;
+ seen_ts = false;
+ gfc_clear_ts ();
+ m = gfc_match_type_spec ();
+ if (m == MATCH_YES)
+{
+ seen_ts = (gfc_match (" ::") == MATCH_YES);
+
+ if (seen_ts)
+ {
+ if (!gfc_notify_std (GFC_STD_F2018, "Optional type-spec "
+ "included in implied-do loop at %C"))
+ goto cleanup;
+
+ if (ts.type != BT_INTEGER)
+ {
+ gfc_error ("Type in type-spec at %C shall be INTEGER");
+ goto cleanup;
+ }
+ }
+}
+ else if (m == MATCH_ERROR)
+goto cleanup;
+
+ if (!seen_ts)
+gfc_current_locus = start;
+
/* Match the start of an iterator without affecting the symbol table. */
start = gfc_current_locus;
@@ -984,6 +1014,14 @@ gfc_match_iterator (gfc_iterator *iter, int init_flag)
if (m != MATCH_YES)
return MATCH_NO;
+ if (seen_ts && var->ts.type == BT_UNKNOWN)
+{
+ var->ts.type = ts.type;
+ var->ts.kind = ts.kind;
+ var->symtree->n.sym->ts.type = ts.type;
+ var->symtree->n.sym->ts.kind = ts.kind;
+}
+
if (var->symtree->n.sym->attr.dimension)
{
gfc_error ("Loop variable at %C cannot be an array");
@@ -2396,6 +2434,9 @@ match_forall_header (gfc_forall_iterator **phead,
gfc_expr **mask)
gfc_forall_iterator *head, *tail, *new_iter;
gfc_expr *msk;
match m;
+ locus start;
+ gfc_typespec ts;
+ bool seen_ts;
gfc_gobble_whitespace ();
@@ -2405,12 +2446,48 @@ match_forall_header (gfc_forall_iterator **phead,
gfc_expr **mask)
if (gfc_match_char ('(') != MATCH_YES)
return MATCH_NO;
+ /* Match an optional "integer ::" type-spec. */
+ start = gfc_current_locus;
+ seen_ts = false;
+ gfc_clear_ts ();
+ m = gfc_match_type_spec ();
+ if (m == MATCH_YES)
+{
+ seen_ts = (gfc_match (" ::") == MATCH_YES);
+
+ if (seen_ts)
+ {
+ if (!gfc_notify_std (GFC_STD_F2008, "Optional type-spec "
+ "included in FORALL at %C"))
+ goto cleanup;
+
+ if (ts.type !=
Re: typespec in forall and implied-do
On Wed, Nov 16, 2022 at 04:47:50PM -0800, Steve Kargl via Fortran wrote: > On Wed, Nov 16, 2022 at 04:32:39PM -0800, Steve Kargl via Fortran wrote: > > On Wed, Nov 16, 2022 at 01:30:07PM -0800, Steve Kargl via Fortran wrote: > > > On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote: > > > > F2008 introduced the inclusion of a typespec in a forall > > > > statement, and thn F2018 a typespec was allowed in an > > > > implied-do. There may even be a few bug reports. > > > > > > > > > > New patch. This one handles the example of an implied-do > > > loop in an initialization expression (see patch for expr.cc). > > > > > > > Seems to cause regressions. > > > > It seems that the patch to expr.cc allows the implied-do-index > to escape into the namespace of scoping unit that contains > the implied-do loop. > If I restrict the expr.cc patch to only kick-in when gfc_current_ns->seen_implicit_none == 1, then there are only 11 regression. Perhaps, this should be committed? -- Steve
Re: typespec in forall and implied-do
On Wed, Nov 16, 2022 at 04:32:39PM -0800, Steve Kargl via Fortran wrote: > On Wed, Nov 16, 2022 at 01:30:07PM -0800, Steve Kargl via Fortran wrote: > > On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote: > > > F2008 introduced the inclusion of a typespec in a forall > > > statement, and thn F2018 a typespec was allowed in an > > > implied-do. There may even be a few bug reports. > > > > > > > New patch. This one handles the example of an implied-do > > loop in an initialization expression (see patch for expr.cc). > > > > Seems to cause regressions. > It seems that the patch to expr.cc allows the implied-do-index to escape into the namespace of scoping unit that contains the implied-do loop. -- Steve
Re: typespec in forall and implied-do
On Wed, Nov 16, 2022 at 01:30:07PM -0800, Steve Kargl via Fortran wrote: > On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote: > > F2008 introduced the inclusion of a typespec in a forall > > statement, and thn F2018 a typespec was allowed in an > > implied-do. There may even be a few bug reports. > > > > New patch. This one handles the example of an implied-do > loop in an initialization expression (see patch for expr.cc). > Seems to cause regressions. -- Steve
Re: [PATCH, committed] Fortran: ICE on procedure arguments with non-integer length [PR107707]
On Wed, Nov 16, 2022 at 10:58:18PM +0100, Harald Anlauf via Fortran wrote: > > @Steve: please close PR if you think everything is ok. > Thanks. I'll close the pr. -- Steve
Re: typespec in forall and implied-do
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> F2008 introduced the inclusion of a typespec in a forall
> statement, and thn F2018 a typespec was allowed in an
> implied-do. There may even be a few bug reports.
>
New patch. This one handles the example of an implied-do
loop in an initialization expression (see patch for expr.cc).
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 69d0b57c688..90bd8d7251d 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3165,9 +3165,20 @@ gfc_reduce_init_expr (gfc_expr *expr)
bool t;
gfc_init_expr_flag = true;
+
+ if (expr->expr_type == EXPR_ARRAY && expr->ts.type == BT_UNKNOWN)
+{
+ gfc_simplify_expr (expr, 1);
+ if (!gfc_check_constructor_type (expr))
+ return false;
+ if (!gfc_expand_constructor (expr, true))
+ return false;
+}
+
t = gfc_resolve_expr (expr);
if (t)
t = gfc_check_init_expr (expr);
+
gfc_init_expr_flag = false;
if (!t || !expr)
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 8b8b6e79c8b..3fd2a80caad 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -968,9 +968,39 @@ gfc_match_iterator (gfc_iterator *iter, int init_flag)
gfc_expr *var, *e1, *e2, *e3;
locus start;
match m;
+ gfc_typespec ts;
+ bool seen_ts;
e1 = e2 = e3 = NULL;
+ /* Match an optional "integer ::" type-spec. */
+ start = gfc_current_locus;
+ seen_ts = false;
+ gfc_clear_ts ();
+ m = gfc_match_type_spec ();
+ if (m == MATCH_YES)
+{
+ seen_ts = (gfc_match (" ::") == MATCH_YES);
+
+ if (seen_ts)
+ {
+ if (!gfc_notify_std (GFC_STD_F2018, "Optional type-spec "
+ "included in implied-do loop at %C"))
+ goto cleanup;
+
+ if (ts.type != BT_INTEGER)
+ {
+ gfc_error ("Type in type-spec at %C shall be INTEGER");
+ goto cleanup;
+ }
+ }
+}
+ else if (m == MATCH_ERROR)
+goto cleanup;
+
+ if (!seen_ts)
+gfc_current_locus = start;
+
/* Match the start of an iterator without affecting the symbol table. */
start = gfc_current_locus;
@@ -984,6 +1014,14 @@ gfc_match_iterator (gfc_iterator *iter, int init_flag)
if (m != MATCH_YES)
return MATCH_NO;
+ if (seen_ts && var->ts.type == BT_UNKNOWN)
+{
+ var->ts.type = ts.type;
+ var->ts.kind = ts.kind;
+ var->symtree->n.sym->ts.type = ts.type;
+ var->symtree->n.sym->ts.kind = ts.kind;
+}
+
if (var->symtree->n.sym->attr.dimension)
{
gfc_error ("Loop variable at %C cannot be an array");
@@ -2396,6 +2434,9 @@ match_forall_header (gfc_forall_iterator **phead,
gfc_expr **mask)
gfc_forall_iterator *head, *tail, *new_iter;
gfc_expr *msk;
match m;
+ locus start;
+ gfc_typespec ts;
+ bool seen_ts;
gfc_gobble_whitespace ();
@@ -2405,12 +2446,48 @@ match_forall_header (gfc_forall_iterator **phead,
gfc_expr **mask)
if (gfc_match_char ('(') != MATCH_YES)
return MATCH_NO;
+ /* Match an optional "integer ::" type-spec. */
+ start = gfc_current_locus;
+ seen_ts = false;
+ gfc_clear_ts ();
+ m = gfc_match_type_spec ();
+ if (m == MATCH_YES)
+{
+ seen_ts = (gfc_match (" ::") == MATCH_YES);
+
+ if (seen_ts)
+ {
+ if (!gfc_notify_std (GFC_STD_F2008, "Optional type-spec "
+ "included in FORALL at %C"))
+ goto cleanup;
+
+ if (ts.type != BT_INTEGER)
+ {
+ gfc_error ("Type in type-spec at %C shall be INTEGER");
+ goto cleanup;
+ }
+ }
+}
+ else if (m == MATCH_ERROR)
+goto cleanup;
+
+ if (!seen_ts)
+gfc_current_locus = start;
+
m = match_forall_iterator (_iter);
if (m == MATCH_ERROR)
goto cleanup;
if (m == MATCH_NO)
goto syntax;
+ if (seen_ts && new_iter->var->ts.type == BT_UNKNOWN)
+{
+ new_iter->var->ts.type = ts.type;
+ new_iter->var->ts.kind = ts.kind;
+ new_iter->var->symtree->n.sym->ts.type = ts.type;
+ new_iter->var->symtree->n.sym->ts.kind = ts.kind;
+}
+
head = tail = new_iter;
for (;;)
--
Steve
Re: typespec in forall and implied-do
On Tue, Nov 15, 2022 at 06:31:16PM -0800, Steve Kargl via Fortran wrote:
> On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> > F2008 introduced the inclusion of a typespec in a forall
> > statement, and thn F2018 a typespec was allowed in an
> > implied-do. There may even be a few bug reports.
> >
>
> Forgot to ask. Anyone know how namespaces work with
> initialization expressions in gfortran? This code
> should compile
>
>program foo
>use iso_fortran_env, only : k => real_kinds
>implicit none
>integer, parameter :: n = size(k)
>integer, parameter :: &
>& p(n) = [(precision(real(1.,k(i))), integer :: i = 1, n)]
>print '(*(I0,X))', p
>end program foo
>
>
> The first occurence of 'i' in the expression for 'p(n)'
> is either thought to be in a different namespace, or
> an implied-do loop cannot be used in an initialization
> expression.
After spending to much time on this, I found that decl.cc:3044-50
m = gfc_match_init_expr ();
if (m == MATCH_NO)
{
gfc_error ("Expected an initialization expression at %C");
m = MATCH_ERROR;
}
results in m == MATCH_ERROR. First, I would expect the "if"
condition to include the m == MATCH_ERROR to generate an
error message. Second, an implied-do loop can appear in
an initialization expression. So, gfortran is not handling
this correctly. Now, if one goes to expr.cc:gfc_match_init_expr,
gfortran matches the RHS expression, but gfc_reduce_init_expr()
fails to expand the array constructor.
--
Steve
Re: typespec in forall and implied-do
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote: > > This patch allows the above to compile and execute. > It has only had some light testing, and I do not know > if nested forall and implied-do loops do work. Feel > free to commit as I cannot. > Appears to work for nested forall (at least in the execution part of a subprogram). ! From Section 6.9 of MR program foo implicit none integer, parameter :: n = 9 integer i, j integer k integer a(n,n), b(n,n) a = reshape([(i,i=1,n**2)], [n,n]) do k = 1, 9 print '(*(I3))', a(k,:) end do print * b = a forall (i = 1:n-1) forall (j = i+1:n) a(i,j) = a(j,i) ! a is a rank-2 array end forall end forall do k = 1, 9 print '(*(I3))', a(k,:) end do print * a = b forall (integer :: ii = 1:n-1) forall (integer :: jj = ii+1:n) a(ii,jj) = a(jj,ii) ! a is a rank-2 array end forall end forall do k = 1, 9 print '(*(I3))', a(k,:) end do print * end program foo -- Steve
Re: typespec in forall and implied-do
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote: > > This patch allows the above to compile and execute. > It has only had some light testing, and I do not know > if nested forall and implied-do loops do work. Feel > free to commit as I cannot. For nested implied-do loops, the patch appears to do the right thing on program foo implicit none integer, parameter :: m = 4, n = 3 integer k, x(m*n) print '(*(I0,1X))', [(i, (i*j, integer :: j=1, n), integer :: i=1, m)] x = [((i*j, integer :: j=1, n), integer :: i=1, m)] print '(*(I0,1X))', x end program foo -- Steve
Re: typespec in forall and implied-do
On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote: > F2008 introduced the inclusion of a typespec in a forall > statement, and thn F2018 a typespec was allowed in an > implied-do. There may even be a few bug reports. > Forgot to ask. Anyone know how namespaces work with initialization expressions in gfortran? This code should compile program foo use iso_fortran_env, only : k => real_kinds implicit none integer, parameter :: n = size(k) integer, parameter :: & & p(n) = [(precision(real(1.,k(i))), integer :: i = 1, n)] print '(*(I0,X))', p end program foo The first occurence of 'i' in the expression for 'p(n)' is either thought to be in a different namespace, or an implied-do loop cannot be used in an initialization expression. -- Steve
typespec in forall and implied-do
F2008 introduced the inclusion of a typespec in a forall
statement, and thn F2018 a typespec was allowed in an
implied-do. There may even be a few bug reports.
Consider,
program foo
implicit none
integer, parameter :: n = 9
integer a(n,n), b(n), j
b = [(k, integer :: k = 1, n)]
if (any(b /= [1, 2, 3, 4, 5, 6, 7, 8, 9])) stop 1
a = 0
forall (integer :: i = 1:n) a(i,i) = b(i)
do j = 1, n
if (a(j,j) /= b(j)) stop j
end do
call bar
contains
subroutine bar
real x(n)
x = [(sqrt(real(p)), integer :: p = 1, n)]
print '(*(F8.2,1X))', x
end subroutine bar
end program foo
This patch allows the above to compile and execute.
It has only had some light testing, and I do not know
if nested forall and implied-do loops do work. Feel
free to commit as I cannot.
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 8b8b6e79c8b..3fd2a80caad 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -968,9 +968,39 @@ gfc_match_iterator (gfc_iterator *iter, int init_flag)
gfc_expr *var, *e1, *e2, *e3;
locus start;
match m;
+ gfc_typespec ts;
+ bool seen_ts;
e1 = e2 = e3 = NULL;
+ /* Match an optional "integer ::" type-spec. */
+ start = gfc_current_locus;
+ seen_ts = false;
+ gfc_clear_ts ();
+ m = gfc_match_type_spec ();
+ if (m == MATCH_YES)
+{
+ seen_ts = (gfc_match (" ::") == MATCH_YES);
+
+ if (seen_ts)
+ {
+ if (!gfc_notify_std (GFC_STD_F2018, "Optional type-spec "
+ "included in implied-do loop at %C"))
+ goto cleanup;
+
+ if (ts.type != BT_INTEGER)
+ {
+ gfc_error ("Type in type-spec at %C shall be INTEGER");
+ goto cleanup;
+ }
+ }
+}
+ else if (m == MATCH_ERROR)
+goto cleanup;
+
+ if (!seen_ts)
+gfc_current_locus = start;
+
/* Match the start of an iterator without affecting the symbol table. */
start = gfc_current_locus;
@@ -984,6 +1014,14 @@ gfc_match_iterator (gfc_iterator *iter, int init_flag)
if (m != MATCH_YES)
return MATCH_NO;
+ if (seen_ts && var->ts.type == BT_UNKNOWN)
+{
+ var->ts.type = ts.type;
+ var->ts.kind = ts.kind;
+ var->symtree->n.sym->ts.type = ts.type;
+ var->symtree->n.sym->ts.kind = ts.kind;
+}
+
if (var->symtree->n.sym->attr.dimension)
{
gfc_error ("Loop variable at %C cannot be an array");
@@ -2396,6 +2434,9 @@ match_forall_header (gfc_forall_iterator **phead,
gfc_expr **mask)
gfc_forall_iterator *head, *tail, *new_iter;
gfc_expr *msk;
match m;
+ locus start;
+ gfc_typespec ts;
+ bool seen_ts;
gfc_gobble_whitespace ();
@@ -2405,12 +2446,48 @@ match_forall_header (gfc_forall_iterator **phead,
gfc_expr **mask)
if (gfc_match_char ('(') != MATCH_YES)
return MATCH_NO;
+ /* Match an optional "integer ::" type-spec. */
+ start = gfc_current_locus;
+ seen_ts = false;
+ gfc_clear_ts ();
+ m = gfc_match_type_spec ();
+ if (m == MATCH_YES)
+{
+ seen_ts = (gfc_match (" ::") == MATCH_YES);
+
+ if (seen_ts)
+ {
+ if (!gfc_notify_std (GFC_STD_F2008, "Optional type-spec "
+ "included in FORALL at %C"))
+ goto cleanup;
+
+ if (ts.type != BT_INTEGER)
+ {
+ gfc_error ("Type in type-spec at %C shall be INTEGER");
+ goto cleanup;
+ }
+ }
+}
+ else if (m == MATCH_ERROR)
+goto cleanup;
+
+ if (!seen_ts)
+gfc_current_locus = start;
+
m = match_forall_iterator (_iter);
if (m == MATCH_ERROR)
goto cleanup;
if (m == MATCH_NO)
goto syntax;
+ if (seen_ts && new_iter->var->ts.type == BT_UNKNOWN)
+{
+ new_iter->var->ts.type = ts.type;
+ new_iter->var->ts.kind = ts.kind;
+ new_iter->var->symtree->n.sym->ts.type = ts.type;
+ new_iter->var->symtree->n.sym->ts.kind = ts.kind;
+}
+
head = tail = new_iter;
for (;;)
Re: allocatable arrays and -fmax-stack-var-size
On Thu, Mar 31, 2022 at 08:36:37PM +0200, Thomas Koenig wrote:
> Hi Steve,
>
> > So, it seems that at some point in the past, the option
> > -fmax-stack-var-size was expanded to allow the placement
> > of an allocatable array into static memory. This has
> > a possibly unintended consequence in that automatic
> > deallocation of an allocatable array does not (or can
> > not) occur.
>
> Sounds like a bug to me, and if your test program worked
> in a previous release, it's a regression.
>
> Probably best to open a PR.
>
Thomas
Seems someone from Fortran Discourse forum beat me to it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105117
With all of the work on openmp, I wasn't sure if this
was intended or not. Either way it is surprising to me
that an allocatable array is placed in static memory.
I went looking and found this chunk of code in trans-decl.cc
(lines 743-774 where I removed the paragraph warning).
/* Keep variables larger than max-stack-var-size off stack. */
if (!(sym->ns->proc_name && sym->ns->proc_name->attr.recursive)
&& !sym->attr.automatic
&& sym->attr.save != SAVE_EXPLICIT
&& sym->attr.save != SAVE_IMPLICIT
&& INTEGER_CST_P (DECL_SIZE_UNIT (decl))
&& !gfc_can_put_var_on_stack (DECL_SIZE_UNIT (decl))
/* Put variable length auto array pointers always into stack. */
&& (TREE_CODE (TREE_TYPE (decl)) != POINTER_TYPE
|| sym->attr.dimension == 0
|| sym->as->type != AS_EXPLICIT
|| sym->attr.pointer
|| sym->attr.allocatable)
&& !DECL_ARTIFICIAL (decl))
{
if (flag_max_stack_var_size > 0
&& !(sym->ns->proc_name
&& sym->ns->proc_name->attr.is_main_program))
gfc_warning (OPT_Wsurprising,
...
sym->name, >declared_at);
TREE_STATIC (decl) = 1;
If I set the last line to 0, I get what I expect as far as an
allocatable array. I have been unable to decipher the 12 line
conditional.
--
Steve
allocatable arrays and -fmax-stack-var-size
So, it seems that at some point in the past, the option
-fmax-stack-var-size was expanded to allow the placement
of an allocatable array into static memory. This has
a possibly unintended consequence in that automatic
deallocation of an allocatable array does not (or can
not) occur.
program foo
implicit none
call testAutoDealloc(20)
call testAutoDealloc(200)
contains
subroutine testAutoDealloc(n)
integer, intent(in) :: n
real, allocatable :: temp(:)
allocate(temp(n))
temp = n
if (temp(n) /= n) stop n
end
end program foo
% gfcx -o u a.f90 && ./u
% gfcx -o u -fmax-stack-var-size=10 -fdump-tree-original a.f90 && ./u
At line 9 of file a.f90
Fortran runtime error: Attempting to allocate already allocated variable 'temp'
% head -4 u-a.f90.005t.original
__attribute__((fn spec (". r ")))
void testautodealloc (integer(kind=4) & restrict n)
{
static struct array01_real(kind=4) temp = {.data=0B};
Now, it seems that an explicit deallocation of temp at the end of
the subroutine testAutoDealloc suppresses the runtime error. Looking
at a -fdump-tree-original with the modified code shows
if ((real(kind=4)[0:] * restrict) temp.data == 0B)
{
_gfortran_runtime_error_at (...Attempt to DEALLOCATE unallocated...);
}
else
{
__builtin_free ((void *) temp.data);
(real(kind=4)[0:] * restrict) temp.data = 0B;
}
Should the automatic deallocation of allocatable arrays be restore?
I'll let someone who cares enough to pursue this route. Until then,
here's a patch to the manual to caution the unwary.
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 6435dc4d4de..b5002d2a31a 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1786,13 +1786,19 @@ The default value for @var{n} is 65535.
@item -fmax-stack-var-size=@var{n}
@opindex @code{fmax-stack-var-size}
This option specifies the size in bytes of the largest array that will be put
-on the stack; if the size is exceeded static memory is used (except in
-procedures marked as RECURSIVE). Use the option @option{-frecursive} to
-allow for recursive procedures which do not have a RECURSIVE attribute or
-for parallel programs. Use @option{-fno-automatic} to never use the stack.
+on the stack. If the size of an array exceeds @var{n}, then the array is
+placed in static memory (except in procedures marked as RECURSIVE). Use
+the option @option{-frecursive} to allow for recursive procedures which
+do not have a RECURSIVE attribute or for parallel programs.
+Use @option{-fno-automatic} to never use the stack.
+
+The @option{-Wsurprising} option can be used to determine which arrays
+have been placed into static memory.
+
+@option{-fmax-stack-var-size} can inhibit the automatic deallocation of
+allocatable arrays. Proper memory management is required if this option
+is used (i.e., explicit deallocation is encouraged).
-This option currently only affects local arrays declared with constant
-bounds, and may not apply to all character variables.
Future versions of GNU Fortran may improve this behavior.
The default value for @var{n} is 65536.
--
Steve
