Re: [patch, libfortran] PR114618 Version 2 Format produces incorrect output when contains 1x, ok when uses " "
On 1/31/25 11:30 AM, Harald Anlauf wrote: --- snip -- So either commit the current version and track this issue in a PR if not yet done, or have a look if there is a quick fix. Thanks for the work! Harald Committed as: commit cfed99751c1a3b93ca66451eb1b62271e682f927 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Wed Jan 29 13:40:59 2025 -0800 Fortran: Fix handling of the X edit descriptor.
[Patch, fortran] PR118750 - [14/15 Regression] ICE on associate with elemental function with polymorphic array dummy argument
This regression must have been generated during my ASSOCIATE campaign; I am
not sure when or where. Fortunately the fix is extremely simple and is
explained in the ChangeLog.
Regression tests fine. OK for both affected branches?
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 7f73d53e31e..a961843edc4 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -10741,7 +10741,7 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
|| gfc_is_ptr_fcn (target));
/* Finally resolve if this is an array or not. */
- if (target->expr_type == EXPR_FUNCTION
+ if (target->expr_type == EXPR_FUNCTION && target->rank == 0
&& (sym->ts.type == BT_CLASS || sym->ts.type == BT_DERIVED))
{
gfc_expression_rank (target);
diff --git a/gcc/testsuite/gfortran.dg/associate_72.f90 b/gcc/testsuite/gfortran.dg/associate_72.f90
new file mode 100644
index 000..993ebdfd5a7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associate_72.f90
@@ -0,0 +1,26 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+!
+! Test the fix for the 14/15 regression PR118750
+!
+! Contributed by Damian Rouson
+!
+ implicit none
+
+ type string_t
+character(:), allocatable :: str
+ end type
+
+ associate(str_a => get_string([string_t ("abcd"),string_t ("ef")]))
+if (str_a(1)%str//str_a(2)%str /= "abcdef") STOP 1 ! Returned "Invalid array reference at (1)"
+ end associate
+
+contains
+
+ type(string_t) elemental function get_string(mold)
+class(string_t), intent(in) :: mold
+get_string = string_t(mold%str)
+ end function
+
+end
+! { dg-final { scan-tree-dump-times "array01_string_t str_a" 1 "original" } }
Re: [patch, libfortran] PR114618 Version 2 Format produces incorrect output when contains 1x, ok when uses " "
On 1/31/25 11:30 AM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.25 um 21:50 schrieb Jerry D:
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 to the patch puts this right.
case FMT_X:
case FMT_TR:
consume_data_flag = 0;
dtp->u.p.skips += f->u.n;
tab_pos = bytes_used + dtp->u.p.skips - 1;
dtp->u.p.pending_spaces = tab_pos - dtp->u.p.max_pos + 1;
dtp->u.p.pending_spaces = dtp->u.p.pending_spaces < 0
? f->u.n : dtp->u.p.pending_spaces;
//if (t == FMT_X && tab_pos < dtp->u.p.max_pos)
//{
//write_x (dtp, dtp->u.p.skips, dtp->u.p.pending_spaces);
//dtp->u.p.skips = dtp->u.p.pending_spaces = 0;
//}
Interestingly, it also fixes a floating point exception I ran into
while setting up another test case for part 2 of this effort. I
suspect this may be what was detected by the auto patch tester.
I will clean this up, adjust the test case for this part and re-submit.
Regards,
Jerry
Here is version 2 of the patch cleaned up and with the test case revised
accordingly.
Thank you Herald for helping with my blindness.
Regressions tested on x86_64. I will wait a bit to see if the auto patch
tester reports anything.
Otherwise, OK for trunk?
this looks mostly good. There is only one (minor?) issue I saw:
writing output to a file, there is a discrepancy between stream-
and non-stream I/O. Adding
write (*, fmt1) 'RADIX', radix(pi)
write (*, fmt2) 'RADIX', radix(pi)
open (10, form="formatted")
write(10, fmt1) 'RADIX', radix(pi)
write(10, fmt2) 'RADIX', radix(pi)
close(10)
open (11, form="formatted", access="stream")
write(11, fmt1) 'RADIX', radix(pi)
write(11, fmt2) 'RADIX', radix(pi)
close(11)
shows agreement between stdout and fort.10, while fort.11 differs:
% head fort.10 fort.11
==> fort.10 <==
RADIX.. 2
RADIX . 2
==> fort.11 <==
RADIX 2
RADIX 2...
Other brands do not show this discrepancy.
Regards,
Jerry
PS working on part 2 still.
Are you addressing this in the second part of your work?
As the test program crashes with current HEAD and earlier
anyway, your patch is already progress, but we don't want
to leave it that way.
So either commit the current version and track this issue in
a PR if not yet done, or have a look if there is a quick fix.
Thanks for the work!
Harald
After studying this a bit more I will commit the subject patch. I have
opened a new PR to track this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118774
Regards,
Jerry
Re: [Patch, fortran] PR118750 - [14/15 Regression] ICE on associate with elemental function with polymorphic array dummy argument
Hi Paul, looks fine to me. Thanks for the patch, Andre Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Tel.: +49 178 3637538 * ve...@gmx.de Am 6. Februar 2025 16:49:18 schrieb Paul Richard Thomas : This regression must have been generated during my ASSOCIATE campaign; I am not sure when or where. Fortunately the fix is extremely simple and is explained in the ChangeLog. Regression tests fine. OK for both affected branches? Paul
Re: [Patch, fortran] PR118750 - [14/15 Regression] ICE on associate with elemental function with polymorphic array dummy argument
Hi Andre, Thanks for the review - pushed as commit r15-7389. Paul On Thu, 6 Feb 2025 at 16:22, Andre Vehreschild wrote: > Hi Paul, > > looks fine to me. > > Thanks for the patch, > Andre > Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen > Tel.: +49 178 3637538 * ve...@gmx.de > > Am 6. Februar 2025 16:49:18 schrieb Paul Richard Thomas < > paul.richard.tho...@gmail.com>: > >> This regression must have been generated during my ASSOCIATE campaign; I >> am not sure when or where. Fortunately the fix is extremely simple and is >> explained in the ChangeLog. >> >> Regression tests fine. OK for both affected branches? >> >> Paul >> >> >
