Re: [Patch] Fortran: Fix libgfortran I/O race with newunit_free [PR99529]

Looks good Tobias, OK, Odd about that line in set_internal_unit. Probably leftover from a copy/paste. I see in comment #5 of the PR that you mentioned trying the assert to make sure it is useless code. Thanks for the patch, Jerry On 3/11/21 2:38 AM, Tobias Burnus wrote: Revised version – th

Re: 12 PR fixed

I have reviewed this and all looks good. I also regression tested on x86_64-pc-linux-gnu. I don't want to do a bunch of individual commits. Steve, if you can do a ChangeLog I can commit in one blast. Regards, Jerry On 3/13/21 1:33 PM, Steve Kargl via Fortran wrote: The following patch fixes

Re: 12 PR fixed

excess errors) FAIL: gfortran.dg/pr96025.f90   -O  (internal compiler error) FAIL: gfortran.dg/pr96025.f90   -O   (test for errors, line 5) FAIL: gfortran.dg/pr96025.f90   -O  (test for excess errors) On 3/13/21 8:46 PM, Jerry DeLisle wrote: I have reviewed this and all looks good. I also

Re: 12 PR fixed

urnus wrote: On 14.03.21 06:13, Jerry DeLisle wrote: Well, I am seeing the falling upon a closer look.  I do not know if related to the patch yet.  Lets make sure this is fixed. FAIL: gfortran.dg/pr87907.f90   -O  (internal compiler error) FAIL: gfortran.dg/pr87907.f90   -O  (test for excess e

Re: [patch, fortran] Also use size estimate for vector-matrix matmul

Yes Ok for trunk. Thanks much! On 3/19/21 10:37 AM, Thomas Koenig via Fortran wrote: Hell world, here is the patch I talked about earlier.  It passes regression testing. OK for trunk? Best regards Thomas Add size check to vector-matrix matmul. It turns out the library version is much

Re: [Patch] Fortran: Fix 'name' bound size [PR99688]

Hi Tobias and others, Reembering some of my own history, we always have used a +1 on 'LENGTH_MAX' items to allow the C null termination on strings or buffers for obvious reasons. Certainly OK for trunk and backports. Regards, Jerry On 3/21/21 9:08 AM, Tobias Burnus wrote: The gfc_match_se

Re: off-by-one buffer overflow patch

On 3/26/21 10:38 AM, dhumieres.dominique--- via Fortran wrote: I have proposed a similar patch in pr95998. I cannot commit to git!-( Thanks Dominique I do not see a patch in 95998.  Do you need help to do a commit? Jerry

Re: off-by-one buffer overflow patch

zes. Regards, Jerry On 3/27/21 6:28 AM, dhumieres.domini...@free.fr wrote: Le 2021-03-27 06:36, Jerry DeLisle a écrit : On 3/26/21 10:38 AM, dhumieres.dominique--- via Fortran wrote: I have proposed a similar patch in pr95998. I cannot commit to git!-( Thanks Dominique I do not see a patch

Re: [PATCH] PR fortran/99840 - [8/9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777

Yes OK for trunk and affected branches. Thanks, Jerry On 3/31/21 2:08 PM, Harald Anlauf via Fortran wrote: Dear all, the simplification of the TRANSPOSE of a zero-sized array would lead to an ICE if the result was used in a subsequent simplification of a MATMUL. The reason was the lack of the

Re: [Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186

Paul, This looks OK to me for Trunk. I believe 10 is in freeze so it may have to wait or get release manager approval. Jerry On 4/1/21 6:44 AM, Paul Richard Thomas via Fortran wrote: This one is trivial. The wrong error message was transformed by my patch for PR98897 into an ICE. This patch

Re: *PING* [PATCH] PR fortran/100274 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

LGTM, OK for trunk and back ports. On 5/4/21 11:34 AM, Harald Anlauf via Fortran wrote: PING! --- Dear Fortranners, Gerhard found a case where the mismatch of actual and formal argument lead to an ICE instead of the relevant warning. Furthermore, the special case of character argument avoide

Re: [PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer argument is not associated" runtime error

On 5/18/21 11:36 AM, Harald Anlauf via Fortran wrote: The generation of the new runtime check picked up the wrong attributes in the case of CLASS array arguments. There is related new code in gfc_conv_procedure_call which served as reference for the fix. Regtested on x86_64-pc-linux-gnu. OK fo

Re: [PATCH] PR fortran/100656 - ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934

On 5/26/21 2:04 PM, Harald Anlauf via Fortran wrote: Dear Fortranners, Gerhard found a case where bounds-checking for an optional, allocatable character dummy resulted in an ICE. We'd better not call the presence check on a non-dummy symbol, as this will hit an assert... Regtested on x86_64-pc

[patch, libgfortran] PR99210 X editing for reading file with encoding='utf-8'

The attached patch fixes the X editing. Fairly self explanatory. I created the patch a few years back. Regression tested on x86_64 and new test case. OK for trunk? Regards, Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr99210.f90 b/gcc/testsuite/gfortran.dg/pr99210.f90 new file mode 100644 inde

Re: Mattermost discussion on PR98426

On Fri, Apr 26, 2024, 2:47 AM Tobias Burnus wrote: > Hi Bernhard, hello all, > Bernhard Reutner-Fischer wrote: > > PS: unfortunately the git branch > (https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool > ) mentioned in mail (I) lived in the old git, before we swit

Re: [Ping, Fortran, Patch, PR85510, v2] Fix coarray token in associate not linking

Ok and thanks. On Fri, Aug 9, 2024, 7:33 AM Andre Vehreschild wrote: > Ping! > > And the last ping in the series. I have a "bigger" patch in the queue and > want > the pending ones done beforehand. > > Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? > > - Andre > > On Mon, 22 J

[patch, fortran] ICE in attr_decl1, at fortran/decl.c:8691

The attached patch was provided by Steve Kargl. After exploring for possible other checks I settled on leaving the patch intact. Two existing test cases updated as different but sensible error messages resulted. Regression tested on main line. OK to commit? Regards, Jerry Author: Steve Kargl

Error on left hand function reference

Hi all, I spotted this today on the Fortran-Lang Discourse. It would not be setting precednce for us to allow an extension and turn this into a warning with -std=gnu and an error of strict compliance is wanted. https://fortran-lang.discourse.group/t/error-the-leftmost-part-ref-in-a-data-ref-cann

[patch, gfortran.dg] Allow test to pass on mingw

Hi all, Similar to a patch I committed a while ago for Cygwin, the attached patch allows it to pass on the mingw version of gfortran. It is trivial. Ok for trunk? Regards, Jerrydiff --git a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f9

[patch, fortran] PR103506 [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c

Attached patch fixes this problem by allowing the namespace pointer to be set correctly regardless of error condition. Regression tested on x86_64_linux_gnu. OK for trunk and backports? Regards, Jerry Author: Jerry DeLisle Date: Sat Jan 28 20:00:34 2023 -0800 ICE in

[PATCHES, Committed] As obvious

Committed as obvious: commit 061b13ed014ba0b6891800a5c7f852bf58e4d856 Author: Jerry DeLisle Date: Thu Feb 16 18:13:56 2023 -0800 Fortran Tests: Allow passing on mingw. gcc/testsuite/ChangeLog: * gfortran.dg/bind_c_array_params_2.f90: Add *-*-ming* to dg-final. and

Possible funding of gfortran work

Hi all, I found this message in my spam folder tonight. Please look. I also sent a note to Damian on this. Maybe we can get someone to push forward on te native coarrays work? Other thoughts? Jerry

GFortran MatterMost new Hosting

Hello all, As of today the free hosting of our MatterMost workspace is ended. The MatterMost cloud service organization decided to end free accounts. Fortunately, the platform is Open Source and we owe a tremendous gratitude to the Oregon State University Open Software Lab (OSUOSL)for providi