Re: [patch, libfortran] PR114618 Version 2 Format produces incorrect output when contains 1x, ok when uses " "

On 1/29/25 10:30 AM, Jerry D wrote: Follow-up: On 1/28/25 1:33 PM, Harald Anlauf wrote: Jerry, while I haven't read your actual patch yet, I think the testcase is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang disagree with it. --- snip --- The following adjustment t

Re: [PATCH] Fortran: fix passing of component ref to assumed-rank dummy [PR118683]

unless there are comments. Regtested on x86_64-pc-linux-gnu. Will also backport to 14-branch, which has the same code. Thanks, Harald Good to go. Jerry

Re: [patch, libfortran] PR114618 Format produces incorrect output when contains 1x, ok when uses " "

On 1/28/25 1:33 PM, Harald Anlauf wrote: Jerry, while I haven't read your actual patch yet, I think the testcase is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang disagree with it. I also installed flang and noticed this. I also received a auto patch test on ARM that c

[patch, libfortran] PR114618 Format produces incorrect output when contains 1x, ok when uses " "

trunk? Regards, Jerry Author: Jerry DeLisle Date: Mon Jan 27 19:08:46 2025 -0800 Fortran: Fix handling of the X edit descriptor. This patch is a partial fix of handling of X edit descriptors when combined with certain T edit descriptors. PR libfortran/114618

Re: [PATCH] Fortran: fix bogus diagnostics on renamed interface import [PR110993]

) interfaces that are not explicitly made accessible via a use statement, see testcase. Regtested on x86_64-pc-linux-gnu.  OK for mainline? Could this one be backportable, e.g. to 14-branch? Thanks, Harald This is OK. Backport up to you. Jerry

Re: [PATCH] Fortran: fix issues with variables in BLOCK DATA [PR58857]

COMMON block if the option "-Wunused-variable" is set. Regtested on x86_64-pc-linux-gnu.  OK for mainline? Thanks, Harald Yes, looks good. Thanks. Jerry

Re: [patch. libgfortran] PR118571 UTF-8 output and the A edit descriptor

On 1/24/25 12:25 AM, Andre Vehreschild wrote: Hi Jerry, the patch looks good to me. One small nit: in write.c after the period of the first sentence should be two space, when I am not mistaken. Thanks for the patch, Andre Thanks for review. Pushed as: commit r15-7181-g4daf088123b

[patch. libgfortran] PR118571 UTF-8 output and the A edit descriptor

Hello all, The attached patch is straight forward. I spent more time on getting the test case ready. Thanks Steve for finding this and narrowing down where the problem was. Regression tested on x86_64-linux-gnu. OK for trunk? What about a backport to 14? Regards, Jerry Author: Jerry

Re: [PATCH] libfortran: G formatting for UNSIGNED [PR118536]

Looks Ok by me. Thanks, Jerry On Fri, Jan 17, 2025, 12:25 PM Harald Anlauf wrote: > Dear all, > > the attached obvious patch extends G formatting to UNSIGNED by reusing > the code for I formatting. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > >

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

nding): New function.     (gfc_dump_c_prototypes): Adjust to take only a file output.  Add     "#include Yes I think this is OK, a definite improvement. Regards, Jerry

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

SoC project. It is modified slightly by Jerry DeLisle for minor formatting. The patch provides front-end parsing of the LOCALITY specs in DO_CONCURRENT and adds numerous test cases. gcc/fortran/ChangeLog: * dump-parse-tree.cc (show_code_node): Updated

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

e current code is fine. * * * On 1/7/25 12:06 PM, Jerry D wrote: cannot understand why moving the forall_iterator from the sub- structure 'concur' back to where it was at the 'ext' sub-structure of typedef struct gfc_code. 'ext' is a union. I suspected there is an

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

On 1/7/25 12:06 PM, Jerry D wrote: On 9/25/24 3:18 AM, Andre Vehreschild wrote: Hi all, I finally managed to apply the fixed patch. It still had some stray line break so check_GNU_style.py wouldn't succeed. But with that fixed I agree to have only some nonsense bickering of the script

Re: [Patch, fortran] PR108434 - [12/13/14/15 Regression] ICE in class_allocatable, at fortran/expr.cc:5000

ul, thanks for fix. Jerry

Re: [Ping, Fortran, Patch, PR114612, v1] Fix missing deep-copy for allocatable components of derived types having cycles.

rather its former absence) for allocatable components of derived types having cyclic dependencies. Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Yes, OK. Thanks. Jerry Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Email

Re: [-Ping-, Fortran, Patch, PR116669, v3] Fix ICE in deallocation of derived types having cyclic dependencies

-gnu / F41. Ok for mainline? ... and this tweak is OK. Proceed. Jerry Regards, Andre On Mon, 6 Jan 2025 11:06:46 +0100 Andre Vehreschild wrote: Hi all, pinging attached rebased patch. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? - Andre On Thu, 12 Dec 2024 14:50:13

Re: [Ping, Fortran, Patch, PR116669, v1] Fix ICE in deallocation of derived types having cyclic dependencies

lated when a type has the recursive and the alloc_comp flag set. Bootstraps and regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? This one is good to go. Jerry Note: The patch was developed on top of my coarray patch, but should apply with delta on a regular trunk w/o issues. Re

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

work my way up the emails with comments and see where we get. Jerry

Re: [PATCH] Fortran: Cray pointer comparison wrongly optimized away [PR106692]

ther back, up to you. Jerry

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

On 12/30/24 12:34 AM, Paul Richard Thomas wrote: Hi Jerry, With such an illustrious group of contributors, I can hardly say 'no', can I? :-) It looks fine to me - OK for trunk. Regards Paul Thanks Paul. Special thanks to Steve for taking this o

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

Morin, and Jerry DeLisle. PR fortran/117643 gcc/fortran/ChangeLog: * check.cc (gfc_check_f_c_string): Check arguments of f_c_string(). * gfortran.h (enum gfc_isym_id): New symbol GFC_ISYM_F_C_STRING. * intrinsic.cc (add_functions): Add the ISO C Binding

Re: [PATCH] Fortran: fix NULL without MOLD argument to scalar DT pointer dummy [PR118179]

pointer dummies with no specified intent. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald OK, and thanks for the fix. Jerry

Re: [2nd PING, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

On 12/20/24 9:09 AM, Andre Vehreschild wrote: Thank you very much Jerry. The delta between the two patches is really minor. In resolve.c I have removed some attr.pointer setting and in caf/single.c the handling for those as well as treating non-descriptor arrays differently. Most changes in

Re: [2nd PING, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

I got as far as applying and regression testing version 2. I have queried around for others to look over the patch. I will scan this one. Since you are the expert in this area, we may just have you push and let the pieces fall out. I will get back to you later today. Jerry On Fri, Dec 20, 2024

Re: [PATCH] Fortran: potential aliasing of complex pointer inquiry references [PR118120]

. The inquiry references can be dealt with later. Regards, Jerry

Re: [Fortran, Patch, PR57598] Fix coarray STOP

* Email: vehre ad gcc dot gnu dot org Yes, this is OK. Thanks, Jerry

Re: [PING!, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

Andre, have you tested this with the tests in OpenCoarrays suite? I ask since this touches coarray things. Jerry On 12/16/24 1:58 AM, Andre Vehreschild wrote: PING! On Fri, 6 Dec 2024 19:10:08 +0100 Andre Vehreschild wrote: Hi all, I had to dive deeply into the issue with handling

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

s interesting. In my tests I tried: print *, len(s1), len(f_c_string(s1)) Which works fine. Is the user required to check for the presence of the optional argument before using it? From the 'view' of the subroutine 'asis' exists but is undefined. Regards, Jerry

Re: [Patch, fortran] PR117897 - [13/14 Regression] Bug in gfortran compiled windows run time with the latest release (14.2.0)

Thanks Paul. Regards, Jerry On Tue, Dec 17, 2024, 12:34 AM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > This bug was so obviously in defiance of the standard that I pushed it to > mainline as r15-6260. I meant to post this message immediately bu

Re: [patch, libgfortran] Bug 117819 - Formatted READ with BZ in format fails

Pushed r15-6090-gcf406a6c Thanks for the review! Jerry On 12/10/24 12:15 AM, Andre Vehreschild wrote: Hi Jerry, patch looks good. Ok for mainline and backport after grace period. Thanks for the patch, Andre On Mon, 9 Dec 2024 20:31:08 -0800 Jerry D wrote: Hi all, The attached

[patch, libgfortran] Bug 117819 - Formatted READ with BZ in format fails

trunk and backport to 14 in a few days. uthor: Jerry DeLisle Date: Mon Dec 9 20:11:23 2024 -0800 Fortran: Fix READ with padding in BLANK ZERO mode. PR fortran/117819 libgfortran/ChangeLog: * io/read.c (read_decimal): If the read value is short of the specified width and pad

Re: [PATCH] Fortran: fix two minor front-end GMP memleaks

Looks good, OK to push. On Sun, Dec 8, 2024, 1:39 PM Harald Anlauf wrote: > Dear all, > > while looking at testcases with inquiry refs, I encountered two minor > GMP memleaks due to double-initialization of GMP variables. Easily > plugged by the attached patch. > > Regtested on x86_64-pc-linux-

[patch, libgfortran] PR117820

Hi all, Attached patch adds a test for zero that is needed for write_boz to work correctly. Almost obvious. Regression tested on x86_64. Ok for trunk? Jerry Author: Jerry DeLisle Date: Mon Dec 2 19:45:26 2024 -0800 Fortran: Fix B64.0 formatted write output. PR fortran

Re: [PATCH] Fortran: fix crash with bounds check writing array section [PR117791]

references? If the code works in 13 maybe we need to isolate to what broke it and intervene at that place. Also go ahead with back porting if no other ideas pop up. I just fear we are covering up something else. Jerry

Re: [Patch, fortran] PR117763 [15.0 regression] segmentation fault through allocatable char arrays (?)

rtran/117763 * gfortran.dg/pr117763.f90: New test. OK Paul, thanks for quick fix. Jerry

Re: [patch, fortran] PR117765 Impure function within a BLOCK construct within a DO CONCURRENT

Thanks Paul, got it. On Mon, Nov 25, 2024, 3:13 AM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Jerry, > > OK by me. > > A small nit: s/too/to/ in the ChangeLog. > > Thanks for the patch > > Paul > > > On Mon, 25 Nov 2024 at 02:50, J

[patch, fortran] PR117765 Impure function within a BLOCK construct within a DO CONCURRENT

I would like to commit the attached patch for Steve. Regression tested on x86-64-linux-gnu. OK for trunk? Author: Steve Kargl Date: Sun Nov 24 18:26:03 2024 -0800 Fortran: Check IMPURE in BLOCK inside DO CONCURRENT. PR fortran/117765 gcc/fortran/ChangeLog:

Re: [wwwdocs] Fortran changes, add description regarding commas in formats

On 11/23/24 10:59 AM, Harald Anlauf wrote: Am 23.11.24 um 19:35 schrieb Jerry D: Suggested docs change regarding fix to PR88052. See attached diff file. OK to push? Regards, Jerry Jerry, for clarification: isn't it the language standard option used when compiling the main th

[wwwdocs] Fortran changes, add description regarding commas in formats

Suggested docs change regarding fix to PR88052. See attached diff file. OK to push? Regards, Jerry diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html index 46dad391..2dc222e3 100644 --- a/htdocs/gcc-15/changes.html +++ b/htdocs/gcc-15/changes.html @@ -143,6 +143,10 @@ a work

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

On 11/23/24 12:40 AM, Thomas Koenig wrote: Hi Jerry, I had originally created this patch in 2018 and we did not get back to it. This results in more restrictive runtime behavior. I will go through the front-end code with another patch to catch this at compile time. Changelog and new test

[libgfortran, patch] PR88052 Format contravening constraint C1002 permitted

: Jerry DeLisle Date: Fri Nov 22 19:29:42 2024 -0800 Fortran: Reject missing comma in format. Standards require rejecting formats where descriptors are not separated by commas. This change allows this the missing comma to be accepted only with

Re: [PATCH] Fortran: fix checking of protected variables in submodules [PR83135]

for mainline? Thanks, Harald Yes, looks good to go. Jerry

Re: [PATCH] Fortran: add bounds-checking for ALLOCATE of CHARACTER with type-spec [PR53357]

ength might be expressions in an explicit interface and the actual declaration, where we don't have a reliable way to compare.) Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Looks good, OK for mainline. Jerry

Re: [PATCH] Fortran: fix passing of NULL() actual argument to character dummy [PR104819]

. One can read through this fairly directly and the comments are very helpful. It begs for some refactoring into a set of smaller functions. Kind and Type regards, Jerry

Re: [Patch, fortran] PR105054 - [12/13/14/15 Regression] Using one kind of pointer functions causes the compiler to hang since r11-3029-g2b0df0a6ac79b34f

(i)) /= trim(chr(i))) print *, i, trim(array_strings2(i)), ' xx ',trim (chr(i)) Change print to a STOP ? Otherwise looks good to me and OK Jerry

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

.  Regressoin-tesed (and this time, I added the intrinsics to the list, so no trouble expected there :-) OK for trunk? Yes, LGTM Jerry

Re: [Patch, fortran] PR115700 - comment 5: uninitialized string length in ASSOCIATE

. Jerry

Re: [PATCH] Fortran: fix several front-end memleaks

ed on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Yes OK for mainline. Thanks, Jerry

Re: [patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests

On 10/20/24 1:16 PM, Harald Anlauf wrote: Hi Jerry! Am 20.10.24 um 21:53 schrieb Jerry D: On 10/20/24 12:23 PM, Harald Anlauf wrote: Hi Jerry! Am 20.10.24 um 18:56 schrieb Jerry D: The attached diff file begins some test suite cleanup. The patch removes extra spaces between dg-do and the

Re: [patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests

On 10/20/24 12:23 PM, Harald Anlauf wrote: Hi Jerry! Am 20.10.24 um 18:56 schrieb Jerry D: The attached diff file begins some test suite cleanup. The patch removes extra spaces between dg-do and the run directive, I only have gone through gfortran.dg and not its sub-directories

[patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests

-64-linux-gnu. OK for trunk? Author: Jerry DeLisle Date: Sat Oct 19 19:29:22 2024 -0700 Fortran: Remove extra space from dg-do run directives. gcc/testsuite/ChangeLog: PR fortran/28031 * gfortran.dg/ISO_Fortran_binding_4.f90: Delete extra space in dg

Re: Fortran: Add range-based diagnostic

1 Error: Allocate-object at (1) must be ALLOCATABLE or a POINTER Tested on x86_64-gnu-linux. Comments, suggestions, remarks? OK for mainline? After scanning through the whole long patch I think I get the pattern of it. Looks Good To Me, OK. Jerry Tobias PS: And

Re: [Patch] Fortran: Fix translatability of diagnostic strings

On 10/18/24 3:20 PM, Tobias Burnus wrote: *Patch ping* OK for trunk. Jerry Tobias Burnus wrote: I noticed that several diagnostic strings were not tagged as translatable. I fixed them by adding _ or G_ as prefix ( →gcc/ABOUT-GCC-NLS) and moved a single-use string to the message to make

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

d standard but it is better than an ICE. OK for trunk? Looks good to me, yes OK. Jerry Best regards Thomas gcc/fortran/ChangeLog:     * error.cc (notify_std_msg): Handle GFC_STD_UNSIGNED. gcc/testsuite/ChangeLog:     * gfortran.dg/unsigned_37.f90: New test.

PR105361 Fix of testcase

Pushed as stated in the PR to cleanup the test case. commit 6604a05fa27bc21c3409e767552daca3fcf43964 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Thu Oct 17 13:39:09 2024 -0700 Fortran: Add tolerance to real value comparisons. gcc/testsuite/Change

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

. Thanks for your efforts! Jerry -- snip --

Re: [patch, Fortran, RFC] Introduce GFC_STD_UNSIGNED

Good to go. On Fri, Oct 11, 2024, 9:06 AM Thomas Koenig wrote: > Am 11.10.24 um 18:00 schrieb Thomas Koenig: > > Hello world, > > > > the attached patch creates an unsigned "standard" for the > > gfc_option.allow_std field. > > > > One of the main reason why people want UNSIGNED for Fortran is >

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

On 9/24/24 5:46 PM, Hans-Peter Nilsson wrote: Thanks for the review! Date: Tue, 24 Sep 2024 17:10:27 -0700 Cc: Jerry D From: Jerry D On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote: I hope the inclusion of gfortran-dg.exp in fortran-torture.exp is not controversial, but there's no fo

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

plain this change of including gfortran-dg.exp in fortran-torture.exp. What does it mean in the case I do 'make -k -j4 check-fortran'? Does gfortran-dg-exp get performed twice? Forgive my ignorance of the testsuite incantations. Regards, Jerry

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

On 9/18/24 1:20 PM, Thomas Koenig wrote: OK for trunk? OK and thanks. Jerry --- snip ---

Re: [PATCH] Fortran: fix ICE in gfc_create_module_variable [PR100273]

d the possibility that that function need not appear at the top level of a module, but could be a contained function. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald OK for mainline. Thanks. Jerry

Re: [Ping x2 , Fortran, Patch, PR77518, (coarray), v4] Fix ICE in sizeof(coarray)

On 8/20/24 5:35 AM, Andre Vehreschild wrote: Hi all, pinging this patch. Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Regards, Andre Your approach looks reasonable so I think OK to push. Thanks, Jerry

Re: [Ping x 3, Fortran, Patch, coarray, PR84246, v2] Fix for [Coarray] ICE in conv_caf_send, at fortran/trans-intrinsic.c:1950

On 8/19/24 4:43 AM, Andre Vehreschild wrote: Hi all, another ping on this patch. Regtests ok on x86_64-pc-linux-gnu on updated master. Ok for mainline? Regards, Andre Looks OK to go ahead Andre. Thanks, Jerry On Fri, 9 Aug 2024 16:29:08 +0200 Andre Vehreschild wrote: Ping

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] Bug 109105 - Error-prone format string building in resolve.cc

mentioned so I used the CHECK_INTERFACES name for the macro. Regression tested on linux-x86_64. No new test cases. OK for mainline? Backport? Regards, Jerry Author: Jerry DeLisle Date: Tue Aug 6 12:47:30 2024 -0700 Fortran: Eliminate error prone translations. PR fortran/109105

[Patch, Fortran] PR104626 ICE in gfc_format_decoder, at fortran/error.cc:1071

Hi all, Doing some catchup here. I plan to commit the following shortly. This is one of Steve's patches posted on bugzilla. I have created a new test case. Regression tested on linux x86-64. git show: commit 4d4549937b789afe4037c2f8f80dfc2285504a1e (HEAD -> master) Author: Steve Kargl Date

[Patch, libgfortran] PR105361 Followup fix to test case

I plan to push this soon to hopefully fix some test breakage on some architetures. It is simple and obvious. I did not get any feedback on this and I do not have access to the machines in question. Regression tested on linux-x86-64. Regards, Jerry commit

ping Re: [patch, libgfortran] PR105361 Incorrect end-of-file condition for derived-type I/O

On 7/22/24 8:13 AM, Jerry D wrote: Hi all, The attached patch fixes this by avoiding looking for and avoiding the EOF condition in the parent READ after returning from the child IO process. I could not think of a simple test case yet since the problem occurred only when redirecting the

[patch, libgfortran] PR105361 Incorrect end-of-file condition for derived-type I/O

. If I have some more time today I will try to come up with something. OK for mainline? Jerry commit e6fa9d84cf126630c9ea744aabec6d7715087310 (HEAD -> master) Author: Jerry DeLisle Date: Sun Jul 21 19:19:00 2024 -0700 Fortran: Suppress wrong End Of File error with user defined

[PATCH] RISC-V: skip vector tests if target not supporting v extension

nsion The test cases under g[cc|++].dg/vect/vect.exp will be skipped on rv64gc after this patch gcc/testsuite/ChangeLog: * lib/target-supports.exp: skip vector tests if target not supporting v extension Signed-off-by: Jerry Zhang Jian --- gcc/testsuite/lib/target-supports.exp | 5 +--

Re: [pushed] readings: Drop FORTRAN 77 test suite at itl.nist.gov

On 6/18/24 10:20 AM, Steve Kargl wrote: On Tue, Jun 18, 2024 at 09:13:23AM +0200, Gerald Pfeifer wrote: The original subsite has disappeared and we couldn't find it elsewhere. https://github.com/gklimowicz/FCVS gklimowicz is a flang developer and member of J3. FWIW my copy of the tests st

Re: [PATCH] Fortran: fix ALLOCATE with SOURCE=, zero-length character [PR83865]

. Thanks, Harald OK and thanks for patch. Jerry

Re: [Patch, fortran] PR114535 - [13/14 regression] ICE with elemental finalizer

cc/fortran PR fortran/114535 * resolve.cc (resolve_symbol): Remove last chunk that checked for finalization of unreferenced symbols. gcc/testsuite/ PR fortran/114535 * gfortran.dg/pr114535d.f90: New test. * gfortran.dg/pr114535iv.f90: Additional source. Yes, OK Paul. Don't feel bad. It wasn't Tabs. LOL Jerry

Re: [Patch] Fortran: List-directed read - accept again tab as alternative to space as separator [PR114304]

On 4/8/24 2:53 AM, Tobias Burnus wrote: Jerry D wrote: See attached updated patch. It turned rather quickly out that this patch – committed as r14-9822-g93adf88cc6744a – caused regressions. Namely, real-world code use tab(s) as separator instead of spaces. [For instance, PR114304 which

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

On 4/5/24 10:47 AM, Jerry D wrote: On 4/4/24 2:41 PM, Tobias Burnus wrote: Hi Jerry, I think for the current testcases, I like the patch – the question is only what's about:    ',3' as input for 'comma'   (or '.3' as input for 'point') For &

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

On 4/4/24 2:41 PM, Tobias Burnus wrote: Hi Jerry, I think for the current testcases, I like the patch – the question is only what's about:   ',3' as input for 'comma'   (or '.3' as input for 'point') For 'point' – 0.3 is read an

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

On 4/4/24 2:31 AM, Tobias Burnus wrote: Hi Jerry, --- snip --- The patch looks mostly like I would expect, except for decimal='point' and a ';' which is *not* preceded by a space. Thanks for working on it. Regarding the 'except' case: --- snip --- i.e. f

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

On 4/4/24 2:31 AM, Tobias Burnus wrote: Hi Jerry, Jerry D wrote: The attached log entry and patch (git show) fixes this issue by adding logic to handle spaces in eat_separators. One or more spaces by themselves are a valid separator. So in this case we look at the character following the

[patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

incorrect separator as long as there is at least one space in front of it. New test case included. Regression tested on X86-64. OK for trunk? Backport to 13 after some time. Regards, Jerrycommit 7d1a958d6b099ea88b6c51649baf5dbd5e598909 Author: Jerry DeLisle Date: Wed Apr 3 18:07:30 2024

Re: [PATCH] Fortran: fix DATA and derived types with pointer components [PR114474]

this fix survives broader testing, I would like to backport. Thanks, Harald P.S.: while trying to extend coverage of conforming code, I had much fun also with other compilers (e.g. NAG panicking...) OK, for trunk and we will see how it survives for a bit before back port. Jerry -

[patch, libgfortran] PR107031 - endfile truncates file at wrong position

Hi all, There has been a bit of discussio on which way to go on this. I took a look today and this trivial patch gives the behavior concluded on Fortran Discourse. See the bugzilla for all the relevant information. Regresion tested on x86-64. I will do the appropriate changelog. OK for trun

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On 3/6/24 9:13 AM, Harald Anlauf wrote: Hi Jerry, can you please replace the user message in e.g. your new testcase pr105456-wf.f90 by say: piomsg="The users message containing % and %% and %s and other stuff" This behaves as expected with Intel, but dies horribly with gfortran

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On 3/5/24 1:51 PM, Harald Anlauf wrote: Hi Jerry, on further thought, do we sanitize 'child_iomsg'? We pass it to snprintf as format. Wouldn't a strncpy be sufficient? Harald Just to be safe I will bump char message[IOMSG_LEN] to char message[IOMSG_LEN + 1] This is like

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On 3/1/24 11:24 AM, rep.dot@gmail.com wrote: Hi Jerry and Steve, On 29 February 2024 19:28:19 CET, Jerry D wrote: On 2/29/24 10:13 AM, Steve Kargl wrote: On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote: On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote: And, just for my own

Re: [PATCH] Fortran: improve checks of NULL without MOLD as actual argument [PR104819]

ranch. Objections? Thanks, Harald Looks good to me. I think backport is OK as well. Jerry -

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote: On Wed, 28 Feb 2024 21:29:06 -0800 Jerry D wrote: The attached patch adds the error checks similar to the first patch previously committed. I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I consolidated this to one define in

[patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

in the library. Regressions tested on x86_64. OK for trunk? Regards, Jerry commit 640991bd6b83df4197b2eaec63d1e0e695e48b75 Author: Jerry DeLisle Date: Wed Feb 28 20:51:06 2024 -0800 Fortran: Add user defined error messages for UDTIO. The defines IOMSG_LEN and MSGLEN were redundant

Re: [PATCH] Fortran testsuite: fix invalid Fortran in testcase

On 2/27/24 1:00 PM, Harald Anlauf wrote: Dear all, the attached patch fixes invalid Fortran in testcase gfortran.dg/pr101026.f, which might prohibit progress in fixing pr111781. (Note that the testcase was for a tree-optimizer issue, not the Fortran frontend.) OK for mainline? Will commit wit

Re: [PATCH] Fortran: do not evaluate polymorphic functions twice in assignment [PR114012]

. OK for mainline? And a backport to 13-branch after some delay? Thanks, Harald Yes, simple enough. OK. Thanks, Jerry

Re: [patch, libgfortran] PR105456 Child I/O does not propage iostat

On 2/25/24 12:34 PM, Harald Anlauf wrote: Hi Jerry, On 2/22/24 20:11, Jerry D wrote: Hi all, The attached fix adds a check for an error condition from a UDDTIO procedure in the case where there is no actual underlying error, but the user defines an error by setting the iostat variable

[patch, libgfortran] PR105456 Child I/O does not propage iostat

WRITE or unformatted READ/WRITE until I get some feedback on the approach. If this approach is OK I would like to commit and then do a separate patch for the cases I just mentioned. Feedback appreciated. Regression tested on x86_64. OK for trunk? Jerry Author: Jerry DeLisle Date: Thu Feb 22

Re: [PATCH] Fix fortran/PR114024

On 2/21/24 12:28 PM, Harald Anlauf wrote: On 2/21/24 20:41, Jerry D wrote: On 2/21/24 10:30 AM, Steve Kargl wrote: I have attached a patch to PR114024, see https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html The patch contains a new testcase and passes regression testing on

Re: [PATCH] Fix fortran/PR114024

Steve, I looked it over and looks reasonable. I will try to apply it next few days and test here. If OK, I will commit. Jerry

[patch, libgfortran] Bug 105473 - semicolon allowed when list-directed read integer with decimal='point'

Hello, I posted the attached patch in bugzilla some time ago. This includes a new test case. The patch adds additional checks in key places to catch eroneous use of semicolons Regression tested on x86_64, OK for trunk and later backport to 13? Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr1

[patch, libgfortran] PR107068 Run-time error when reading logical arrays with a namelist

The attached patch fixes this one. Se the ChangeLog below for explanation. OK for trunk? I think simple enough to backport to 13 as well. Regards, Jerry Author: Jerry DeLisle Date: Fri Feb 16 17:06:37 2024 -0800 libgfortran: Fix namelist read. PR libgfortran/107068

Re: [PATCH] Fortran: deferred length of character variables shall not get lost [PR113911]

. Another temporarily disabled test was re-enabled. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Yes OK for mainline. Thanks, Jerry

[patch, fortran] Bug 105847 - namelist-object-name can be a renamed host associated entity

Pushed as simple and obvious. Regards, Jerry commit 8221201cc59870579b9dc451b173f94b8d8b0993 (HEAD -> master, origin/master, origin/HEAD) Author: Steve Kargl Date: Wed Feb 14 14:40:16 2024 -0800 Fortran: namelist-object-name renaming. PR fortran/105847 gcc/fort

[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

[patch, libgfortran] PR109358

The attached patch fixes this PR by properly adjusting some variables When using stream io. See log below. New test case included. Regression tested on x86_64. OK for trunk and backport? Regards, Jerry ChangeLog: libgfortran: Adjust bytes_left and pos for access="STREAM".

Re: [PATCH] Fortran: error recovery on arithmetic overflow on unary operations [PR113799]

patch looks OK. Thanks, Jerry

  1   2   3   4   5   6   7   8   >