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: [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: [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: [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: [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
> 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: >;< 666 0
> 2-line/left: >;< 666 0
> 2-line/right: >;< 666 0
> 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 666 0
> 2-line/left: ret 666 0
> 2-line/right: ret 666 0
>
>
> So there seems to be a consensus that "," and ";" must be rejected,
> and tab is accepted (makes real sense), but already the termination
> character "/" and comment character "!" are treated differently.
> And how do we want to treat lf and ret in internal files with
> -std=f20xx?
>
> Cheers,
> Harald
>
>
> On 5/7/23 19:33, Jerry D via Gcc-patches wrote:
> > On 5/6/23 11:15 AM, Harald Anlauf via Fortran wrote:
> > > Hi Jerry, Steve,
> > >
> > > I think I have to pour a little water into the wine.
> > >
> > > The patch fixes the reported issue only for a comma after
> > > the namelist name, but we still accept a few other illegal
> > > characters, e.g. ';', because:
> > >
> > > #define is_separator(c) (c == '/' || c == ',' || c == '\n' || c == ' ' \
> > > || c == '\t' || c == '\r' || c == ';' || \
> > > (dtp->u.p.namelist_mode && c == '!'))
> > >
> > > We don't want that in standard conformance mode, or do we?
> > >
> > > Cheers,
> > > Harald
> > >
> > > On 5/6/23 06:02, Steve Kargl via Gcc-patches wrote:
> > > > 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.
> > > >
> > >
> >
> > As I think back, I don't recall ever seeing a semi-colon used after a
> > NAMELIST name, so I think we should reject it always. The other "soft"
> > blanks we should allow.
> >
> > I will make a another patch on trunk to reject the semi-colon and if no
> > one objects here I will test and push it.
> >
> > Regards,
> >
> > Jerry
> >
> >
> program testnmlread
> use iso_fortran_env, only: compiler_version
> implicit none
> print *,'Compiler version = ',trim(compiler_version())
> call test (" ")
> call test ("!")
> call test ("/")
> call test (",")
> call test (";")
> call test (achar(9), "tab")
> call test (achar(10), "lf")
> call test (achar(13), "ret")
> contains
> subroutine test (c, desc)
> character,intent(in) :: c
> character(*), intent(in), optional :: desc
> character(8) :: d
> character(16) :: line, lines(2)
> integer :: ios
> integer :: n
> namelist/stuff/n
> character(*), parameter :: s1 = "", s2 = " n = 666/"
>
> d = ">" // c // "<"; if (present (desc)) d = desc
> ! Prepare input:
> line = s1 // c // s2
> lines(1) = s1 // c ! Left-adjusted
> lines(2) = s2
> ! Single line input
> n = -1
> read(line,nml=stuff,iostat=ios)
> write(*,*) "1-line: ", trim (d), n, ios
> ! Multi-line input
> n = -1
> read(lines,nml=stuff, iostat=ios)
> write(*,*) "2-line/left: ", trim (d), n, ios
> lines(1) = adjustr (lines(1)) ! Right-adjust first line
> n = -1
> read(lines,nml=stuff, iostat=ios)
> write(*,*) "2-line/right: ", trim (d), n, ios
> end subroutine test
> end program testnmlread
--
Steve
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: [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: 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: fort...@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
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 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: [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: [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: [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: [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: [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: [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: [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: [PATCH] PR target/89125
On Mon, Apr 25, 2022 at 09:26:26AM +0200, Richard Biener wrote: > On Sat, Apr 23, 2022 at 8:40 PM Steve Kargl via Gcc-patches > wrote: > > > > ping. > > I have tested the patch on x86_64-linux and pushed it. > Thanks. -- Steve
Re: [PATCH] PR target/89125
ping.
On Fri, Apr 15, 2022 at 09:23:43AM -0700, Steve Kargl wrote:
> Can someone, anyone, please commit the attach patch, which is
> also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
> where one can read the audit trail. The original patch was
> submitted 2 years ago, and required manual intervention due to
> the recent *.c to *.cc rename.
>
> Back story: When GCC is configured and built on non-glibc platforms,
> it seems very little to no effort is made to enumerate the available
> C99 libm functions. It is all or nothing for C99 libm. The patch
> introduces a new function, used on only FreeBSD, to inform gcc that
> it has C99 libm functions (minus a few which clearly GCC does not check
> nor test).
>
> The patch introduces no regression on x86_64-*-freebsd while
> allowing an additional 31 new passes.
>
> === gcc Summary ===
> w/o patch w patch
> # of expected passes175405 175434
> # of unexpected failures1081 1051
> # of unexpected successes 20 20
> # of expected failures 1459 1459
> # of unresolved testcases 10 10
> # of unsupported tests 3252 3252
>
> === g++ Summary ===
> w/o patch w patch
> # of expected passes225338 225341
> # of unexpected failures678676
> # of expected failures 2071 2071
> # of unresolved testcases 11 11
> # of unsupported tests 10353 10353
>
> === gfortran Summary ===
> w/o patch w patch
> # of expected passes65901 65901
> # of unexpected failures12 12
> # of expected failures 272272
> # of unsupported tests 100100
>
>
> 2022-04-15 Steven G. Kargl
>
> PR target/89125
> * config/freebsd.h: Define TARGET_LIBC_HAS_FUNCTION to be
> bsd_libc_has_function.
> * gcc/targhooks.cc(bsd_libc_has_function): New function.
> Expand the supported math functions to inclue C99 libm.
> * gcc/targhooks.h: Prototype for bsd_libc_has_function.
>
> --
> Steve
> diff --git a/gcc/config/freebsd.h b/gcc/config/freebsd.h
> index 28ebcad88d4..d89ee7dfc97 100644
> --- a/gcc/config/freebsd.h
> +++ b/gcc/config/freebsd.h
> @@ -55,7 +55,7 @@ along with GCC; see the file COPYING3. If not see
> #endif
>
> #undef TARGET_LIBC_HAS_FUNCTION
> -#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
> +#define TARGET_LIBC_HAS_FUNCTION bsd_libc_has_function
>
> /* Use --as-needed -lgcc_s for eh support. */
> #ifdef HAVE_LD_AS_NEEDED
> diff --git a/gcc/targhooks.cc b/gcc/targhooks.cc
> index e22bc66a6c8..ff127763cf2 100644
> --- a/gcc/targhooks.cc
> +++ b/gcc/targhooks.cc
> @@ -1843,6 +1843,20 @@ no_c99_libc_has_function (enum function_class fn_class
> ATTRIBUTE_UNUSED,
>return false;
> }
>
> +/* Assume some c99 functions are present at the runtime including sincos.
> */
> +bool
> +bsd_libc_has_function (enum function_class fn_class,
> +tree type ATTRIBUTE_UNUSED)
> +{
> + if (fn_class == function_c94
> + || fn_class == function_c99_misc
> + || fn_class == function_sincos)
> +return true;
> +
> + return false;
> +}
> +
> +
> tree
> default_builtin_tm_load_store (tree ARG_UNUSED (type))
> {
> diff --git a/gcc/targhooks.h b/gcc/targhooks.h
> index ecfa11287ef..ecce55ebe79 100644
> --- a/gcc/targhooks.h
> +++ b/gcc/targhooks.h
> @@ -212,6 +212,7 @@ extern bool default_libc_has_function (enum
> function_class, tree);
> extern bool default_libc_has_fast_function (int fcode);
> extern bool no_c99_libc_has_function (enum function_class, tree);
> extern bool gnu_libc_has_function (enum function_class, tree);
> +extern bool bsd_libc_has_function (enum function_class, tree);
>
> extern tree default_builtin_tm_load_store (tree);
>
--
Steve
[PATCH] PR target/89125
Can someone, anyone, please commit the attach patch, which is
also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
where one can read the audit trail. The original patch was
submitted 2 years ago, and required manual intervention due to
the recent *.c to *.cc rename.
Back story: When GCC is configured and built on non-glibc platforms,
it seems very little to no effort is made to enumerate the available
C99 libm functions. It is all or nothing for C99 libm. The patch
introduces a new function, used on only FreeBSD, to inform gcc that
it has C99 libm functions (minus a few which clearly GCC does not check
nor test).
The patch introduces no regression on x86_64-*-freebsd while
allowing an additional 31 new passes.
=== gcc Summary ===
w/o patch w patch
# of expected passes175405 175434
# of unexpected failures1081 1051
# of unexpected successes 20 20
# of expected failures 1459 1459
# of unresolved testcases 10 10
# of unsupported tests 3252 3252
=== g++ Summary ===
w/o patch w patch
# of expected passes225338 225341
# of unexpected failures678676
# of expected failures 2071 2071
# of unresolved testcases 11 11
# of unsupported tests 10353 10353
=== gfortran Summary ===
w/o patch w patch
# of expected passes65901 65901
# of unexpected failures12 12
# of expected failures 272272
# of unsupported tests 100100
2022-04-15 Steven G. Kargl
PR target/89125
* config/freebsd.h: Define TARGET_LIBC_HAS_FUNCTION to be
bsd_libc_has_function.
* gcc/targhooks.cc(bsd_libc_has_function): New function.
Expand the supported math functions to inclue C99 libm.
* gcc/targhooks.h: Prototype for bsd_libc_has_function.
--
Steve
diff --git a/gcc/config/freebsd.h b/gcc/config/freebsd.h
index 28ebcad88d4..d89ee7dfc97 100644
--- a/gcc/config/freebsd.h
+++ b/gcc/config/freebsd.h
@@ -55,7 +55,7 @@ along with GCC; see the file COPYING3. If not see
#endif
#undef TARGET_LIBC_HAS_FUNCTION
-#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
+#define TARGET_LIBC_HAS_FUNCTION bsd_libc_has_function
/* Use --as-needed -lgcc_s for eh support. */
#ifdef HAVE_LD_AS_NEEDED
diff --git a/gcc/targhooks.cc b/gcc/targhooks.cc
index e22bc66a6c8..ff127763cf2 100644
--- a/gcc/targhooks.cc
+++ b/gcc/targhooks.cc
@@ -1843,6 +1843,20 @@ no_c99_libc_has_function (enum function_class fn_class ATTRIBUTE_UNUSED,
return false;
}
+/* Assume some c99 functions are present at the runtime including sincos. */
+bool
+bsd_libc_has_function (enum function_class fn_class,
+ tree type ATTRIBUTE_UNUSED)
+{
+ if (fn_class == function_c94
+ || fn_class == function_c99_misc
+ || fn_class == function_sincos)
+return true;
+
+ return false;
+}
+
+
tree
default_builtin_tm_load_store (tree ARG_UNUSED (type))
{
diff --git a/gcc/targhooks.h b/gcc/targhooks.h
index ecfa11287ef..ecce55ebe79 100644
--- a/gcc/targhooks.h
+++ b/gcc/targhooks.h
@@ -212,6 +212,7 @@ extern bool default_libc_has_function (enum function_class, tree);
extern bool default_libc_has_fast_function (int fcode);
extern bool no_c99_libc_has_function (enum function_class, tree);
extern bool gnu_libc_has_function (enum function_class, tree);
+extern bool bsd_libc_has_function (enum function_class, tree);
extern tree default_builtin_tm_load_store (tree);
Re: [PATCH] PR fortran/102917 - PDT type parameters are not restricted to default integer
On Sun, Oct 24, 2021 at 09:00:52PM +0200, Harald Anlauf wrote: > Dear Fortranners, Steve, > > I've created PR 102917 for tracking this issue and packaged > the attached patch. > > Regtested on x86_64-pc-linux-gnu. OK mainline? > Thanks for picking this up. The patch looks good to me, but you may want to have Thomas or Tobias cast a quick glance over it. -- Steve
Re: [Patch, Fortran, backport 2 gcc-11] PR98301 Re: RANDOM_INIT() and coarray Fortran
On Sat, Jun 05, 2021 at 04:04:51PM +0200, Andre Vehreschild wrote: > > I was asked to backport the patch for pr98301 to gcc-11. The patches have > been in mainline for two weeks without any defect reports I could fined. The > patch for mainline applied with a bit of shift cleanly. > > Regstested fine on x86_64/f33. Ok for backport gcc-11? > I think the backport is fine. -- Steve
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote: > Ping, ping! > > Please find attached a rebased version of the patch for the RANDOM_INIT issue > with coarray Fortran. Nothing changed to the previous version, just rebased to > current master. > > Regtested fine on x86_64-linux/f33. Ok for trunk? > I think you've down your due diligence with 2 pings. I would commit. -- steve
Re: [Ping, Patch, Fortran, Update 2] PR98301 Re: RANDOM_INIT() and coarray Fortran
On Mon, May 03, 2021 at 11:21:10AM +0200, Andre Vehreschild wrote: > Ping! > > Ok for trunk? > > I have looked at other patches, but none was patching any location I have > worked on previously. Therefore I can't return the favor of reviewing any > currently open patches and have to ask for volunteers here. > > - Andre > I doubt I'm allowed to approve a patch, where I wrote a portion of it. However, if no one else steps forward in the next day or two, then I think you should commit. -- Steve
Re: off-by-one buffer overflow patch
On Sat, Mar 27, 2021 at 03:11:05PM -0700, Jerry DeLisle wrote: > Pushed: > > To git+ssh://gcc.gnu.org/git/gcc.git > 651684b462f..01685676a93 master -> master > > Author: Steve Kargl > Date: Sat Mar 27 15:02:16 2021 -0700 > > fortran: Fix off-by-one in buffer sizes. > > gcc/fortran/ChangeLog: > > * misc.c (gfc_typename): Fix off-by-one in buffer sizes. > > Regards, > > Jerry Thanks for committing the patch. -- steve
off-by-one buffer overflow patch
This patch fixes an off-by-one buffer overflow issue.
Please commit.
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 8a96243e80d..3d449ae17fe 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -124,8 +124,10 @@ gfc_basic_typename (bt type)
const char *
gfc_typename (gfc_typespec *ts, bool for_hash)
{
- static char buffer1[GFC_MAX_SYMBOL_LEN + 7]; /* 7 for "TYPE()" + '\0'. */
- static char buffer2[GFC_MAX_SYMBOL_LEN + 7];
+ /* Need to add sufficient padding for "TYPE()" + '\0', "UNION()" + '\0',
+ or "CLASS()" + '\0'. */
+ static char buffer1[GFC_MAX_SYMBOL_LEN + 8];
+ static char buffer2[GFC_MAX_SYMBOL_LEN + 8];
static int flag = 0;
char *buffer;
gfc_typespec *ts1;
--
Steve
Re: [PATCH] dec_math.f90 needs to be xfailed
On Tue, Jan 05, 2021 at 11:26:24AM -0700, Jeff Law wrote: > > > On 1/4/21 3:28 PM, Steve Kargl wrote: > > On Mon, Jan 04, 2021 at 02:30:43PM -0700, Jeff Law wrote: > >> On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote: > >>> Can someone, anyone, please commit the following trivially patch? > >>> gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*. > >> Why will the test never pass on that platform? I don't mind installing > >> the patch, but I'd like to have a bit more background first :-) > >> > > The testcase assumes REAL(10) has 64-bits of precision. On > > i?86-*-freebsd, the i387 FPU control word is set to 53-bits. > > The test program is not set up to deal with 11-bits of > > missing precision. > Thanks. That's precisely what I needed to know. I suspected it was > related to the differing state of the fpu control word. But that begs > the question of whether or not the change should apply to the other BSD > variants. > I don't know about other BSD variants. The setting of the control word was done some 27 years ago on i?86-FreeBSD. Hmmm. A little code spelunking back to original FreeBSD 2.0.5, https://svnweb.freebsd.org/base/stable/2.0.5/sys/i386/include/npx.h?revision=4=markup The lines 101-132 provide the justification for the control word. AFIK, older FreeBSD sources are not published on FreeBSD.org due to USL lawsuit. If this file is current http://mirror.nyi.net/NetBSD/misc/joerg/GENERIC/src/src/sys/arch/x86/include/cpu_extended_state.h.html then NetBSD is not affected unless, you are using a older version. See lines 196-220. -- Steve
Re: [PATCH] dec_math.f90 needs to be xfailed
On Mon, Jan 04, 2021 at 02:30:43PM -0700, Jeff Law wrote: > > On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote: > > Can someone, anyone, please commit the following trivially patch? > > gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*. > Why will the test never pass on that platform? I don't mind installing > the patch, but I'd like to have a bit more background first :-) > The testcase assumes REAL(10) has 64-bits of precision. On i?86-*-freebsd, the i387 FPU control word is set to 53-bits. The test program is not set up to deal with 11-bits of missing precision. The current code uses the preprocessor to enable testing of REAL(10) with something like #ifdef __GFC_REAL_10__ real(10) x print *, digits(x) #endif There are 44 instances of '#ifdef __GFC_REAL_10__'. Each of those would need to be modified to determine if __FreeBSD__ and __i386__ are defined, and gfortran would need to be modified to define those macros! IOW, xfailing the test is the easiest path forward for something that will never pass. -- Steve
[PATCH] dec_math.f90 needs to be xfailed
Can someone, anyone, please commit the following trivially patch?
gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*.
diff --git a/gcc/testsuite/gfortran.dg/dec_math.f90
b/gcc/testsuite/gfortran.dg/dec_math.f90
index cc141aba412..d95233a5169 100644
--- a/gcc/testsuite/gfortran.dg/dec_math.f90
+++ b/gcc/testsuite/gfortran.dg/dec_math.f90
@@ -1,5 +1,5 @@
! { dg-options "-cpp -std=gnu" }
-! { dg-do run }
+! { dg-do run { xfail i?86-*-freebsd* } }
!
! Test extra math intrinsics formerly offered by -fdec-math,
! now included with -std=gnu or -std=legacy.
--
Steve
Re: [Patch, fortran] PR96102 - ICE in check_host_association, at fortran/resolve.c:5994
On Wed, Aug 05, 2020 at 03:59:38PM +0100, Paul Richard Thomas wrote: > The attached patch builds on a draft posted by Steve Kargl. I have left the > gcc_assert in place just in case my imagination was too limited to generate > an ICE. > > Regtests OK on FC31/x86_64 - OK for trunk? > Looks OK to me. -- Steve
Re: Fix an ICE found in PR93686
On Mon, Apr 06, 2020 at 04:10:24PM -0400, Fritz Reese wrote: > On Sat, Apr 4, 2020 at 2:58 PM Steve Kargl via Fortran > wrote: > > > > This patch fixes the ICE found in PR93686. > > > > > > Index: gcc/fortran/decl.c > > === > > --- gcc/fortran/decl.c (revision 280157) > > +++ gcc/fortran/decl.c (working copy) > > @@ -696,6 +696,10 @@ gfc_match_data (void) > > /* F2008:C567 (R536) A data-i-do-object or a variable that appears > > as a data-stmt-object shall not be an object designator in > > which > > a pointer appears other than as the entire rightmost part-ref. > > */ > > + if (!e->ref && e->ts.type == BT_DERIVED > > + && e->symtree->n.sym->attr.pointer) > > + goto partref; > > + > > ref = e->ref; > > if (e->symtree->n.sym->ts.type == BT_DERIVED > > && e->symtree->n.sym->attr.pointer > > > > -- > > Steve > > LGTM, thanks for the patch. I will commit along with the testcases from the > PR. > Thanks. For reference, my original code did not check the left-most partref for the pointer attribute. This patch implements this check. BTW, if you haven't committed the degree trig functions, then I think you should to get the fixes in for 10.1. -- Steve
Re: [Patch][Fortran] Resolve formal args before checking DTIO (was: Re: [PATCH] deferred-shape vs assumed-shape)
This one is a little bit wierd for me. It seems AS_DEFERRED
is overloaded and things get fixed up later. In array.c
one finds match_array_element_spec(), which set AS_DEFERRED
if the matchers sees (:) regardless of how the array is used.
Then in gfc_set_array_spec(), the array spec is attached to
the symbol in this block
if (sym->as == NULL)
{
sym->as = as;
return true;
}
We can check sym->attr to determine if this is a nonallocatable
nonpointer dummy argument and reset the type to AS_ASSUMED_SHAPE;
or at least I though tI could. This leads to a very, very, long
list of regressions. So, I went with the direct hammer.
Your patch is fine with me as it likely resolves (fixes up?)
the symbol for future references.
--
steve
On Thu, Apr 02, 2020 at 11:34:16AM +0200, Tobias Burnus wrote:
> Hi Steve,
>
> I think your patch is fine - however, I think calling the normal
> resolve_formal_arglist looks a bit cleaner to me (as done in the
> attached patch). — Additionally, I added the testcase.
>
> Side effect of my variant is that gfc_check_dtio_interfaces will
> be called again a bit later again. — In this sense, Steve's patch,
> which replicates a chunk of resolve_formal_arglist, is better.
>
> Thoughts by anyone?
>
> OK?
>
> Tobias
>
> PS: I was thinking of calling resolve_symbol instead
> but this one does not resolve the formal arguments
> (via "gfc_resolve (sym->formal_ns)") as sym->attr.contained.
>
> On 4/1/20 10:04 PM, Steve Kargl via Fortran wrote:
>
> > See
> > https://stackoverflow.com/questions/60972134/whats-wrong-with-the-following-fortran-code-gfortran-dtio-dummy-argument-at
> >
> > Is A(:) a deferred-shape array or an assumed-shape array? The
> > answer of course depends on context.
> >
> > This patch fixes the issue found at the above URL.
> >
> > Index: gcc/fortran/interface.c
> > ===
> > --- gcc/fortran/interface.c (revision 280157)
> > +++ gcc/fortran/interface.c (working copy)
> > @@ -4916,10 +4916,15 @@ check_dtio_arg_TKR_intent (gfc_symbol *fsym, bool
> > type
> > || ((type != BT_CLASS) && fsym->attr.dimension)))
> > gfc_error ("DTIO dummy argument at %L must be a scalar",
> > >declared_at);
> > - else if (rank == 1
> > -&& (fsym->as == NULL || fsym->as->type != AS_ASSUMED_SHAPE))
> > -gfc_error ("DTIO dummy argument at %L must be an "
> > -"ASSUMED SHAPE ARRAY", >declared_at);
> > + else if (rank == 1)
> > +{
> > + if (fsym->as == NULL
> > + || !(fsym->as->type == AS_ASSUMED_SHAPE
> > + || (fsym->as->type == AS_DEFERRED && fsym->attr.dummy
> > + && !fsym->attr.allocatable && !fsym->attr.pointer)))
> > + gfc_error ("DTIO dummy argument at %L must be an "
> > +"ASSUMED-SHAPE ARRAY", >declared_at);
> > +}
> >
> > if (type == BT_CHARACTER && fsym->ts.u.cl->length != NULL)
> > gfc_error ("DTIO character argument at %L must have assumed length",
> >
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> Alexander Walter
> [Fortran] Resolve formal args before checking DTIO
>
> * gfortran.h (gfc_resolve_formal_arglist): Add prototype.
> * interface.c (check_dtio_interface1): Call it.
> * resolve.c (gfc_resolve_formal_arglist): Renamed from
> resolve_formal_arglist, removed static.
> (find_arglists, resolve_types): Update calls.
>
> * gfortran.dg/dtio_35.f90: New.
>
> gcc/fortran/gfortran.h| 1 +
> gcc/fortran/interface.c | 4 ++-
> gcc/fortran/resolve.c | 10 +++
> gcc/testsuite/gfortran.dg/dtio_35.f90 | 50
> +++
> 4 files changed, 59 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> index 96037629f5f..88e4d9236f3 100644
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -3369,6 +3369,7 @@ bool gfc_resolve_expr (gfc_expr *);
> void gfc_resolve (gfc_namespace *);
> void gfc_resolve_code (gfc_code *, gfc_namespace *);
> void gfc_resolve_blocks (gfc_code *, gfc_namespace *);
> +void gfc_resolve_formal_arglist (gfc_symbol *);
> int gfc_impure_variable (gfc_symbol *);
> int gfc_pure (gfc_symbol *);
> int gfc_implicit_pure (gfc_symbol *);
> diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
> index 14d03c27759..75a50c999b7 100644
> --- a/gcc/fortran/interface.c
> +++ b/gcc/fortran/interface.c
> @@ -5007,6 +5007,9 @@ check_dtio_interface1 (gfc_symbol *derived, gfc_symtree
> *tb_io_st,
> gfc_error ("DTIO procedure %qs at %L must be a subroutine",
> dtio_sub->name, _sub->declared_at);
>
> + if (!dtio_sub->resolved)
> +gfc_resolve_formal_arglist (dtio_sub);
> +
>arg_num = 0;
>for (formal = dtio_sub->formal; formal;
[PATCH] deferred-shape vs assumed-shape
See
https://stackoverflow.com/questions/60972134/whats-wrong-with-the-following-fortran-code-gfortran-dtio-dummy-argument-at
Is A(:) a deferred-shape array or an assumed-shape array? The
answer of course depends on context.
This patch fixes the issue found at the above URL.
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 280157)
+++ gcc/fortran/interface.c (working copy)
@@ -4916,10 +4916,15 @@ check_dtio_arg_TKR_intent (gfc_symbol *fsym, bool type
|| ((type != BT_CLASS) && fsym->attr.dimension)))
gfc_error ("DTIO dummy argument at %L must be a scalar",
>declared_at);
- else if (rank == 1
- && (fsym->as == NULL || fsym->as->type != AS_ASSUMED_SHAPE))
-gfc_error ("DTIO dummy argument at %L must be an "
- "ASSUMED SHAPE ARRAY", >declared_at);
+ else if (rank == 1)
+{
+ if (fsym->as == NULL
+ || !(fsym->as->type == AS_ASSUMED_SHAPE
+ || (fsym->as->type == AS_DEFERRED && fsym->attr.dummy
+ && !fsym->attr.allocatable && !fsym->attr.pointer)))
+ gfc_error ("DTIO dummy argument at %L must be an "
+ "ASSUMED-SHAPE ARRAY", >declared_at);
+}
if (type == BT_CHARACTER && fsym->ts.u.cl->length != NULL)
gfc_error ("DTIO character argument at %L must have assumed length",
--
Steve
Re: PATCH -- Fix degree trignometric functions
On Sat, Mar 28, 2020 at 08:10:38AM +0100, Tobias Burnus wrote: > Two remarks: > > * As the file trigd_lib.inc is shared between libgfortran > and gcc/fortran, I wonder whether it should be placed > under include/ (under the GCC toplevel directroy) The original name and location were chosen to match intrinsics/erfc_scaled_inc.c, which is included in intrinsics/erfc_scaled.c. I think Fritz's re-use in simplification makes since given the ugly nested if-elseif-else constructs in the file. As this is Fortran specific, I do not believe it should be moved up to a toplevel diretory. > > * All included files need dependency; I do not quickly > see whether that' the case. They do? See intrinsics/erfc_scaled*.c. % grep erfc_ Makefile.am intrinsics/erfc_scaled.c \ -- steve
