[Bug fortran/116875] Internal compiler error: in make_decl_rtl, at varasm.cc:1443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116875 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > I think I've seen at least one other PR with the same pattern. The following PRs may have a different traceback, but might suffer from the same or related problem with missings/losts decls within a block..end block: pr92975 - ICE in convert_nonlocal_reference_op pr105582 - ICE on procedure pointer assignment inside block pr107075 - ICE in get, at cgraph.h
[Bug libfortran/116886] maxval/minval should not return empty result for empty array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116886 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #2) > The behavior for simplification is correct, as far as I understand: > > $ cat mv2.f90 > program memain > integer, dimension(0,0), parameter :: empty = reshape([(0,i=1,0)],[0,0]) > print *,maxval(empty) > print *,minval(empty) > end program memain > $ gfortran mv2.f90 && ./a.out > -2147483648 > 2147483647 I guess you meant to add dim=1 as in: program memain integer, dimension(0,0), parameter :: empty = reshape([(0,i=1,0)],[0,0]) print *,maxval(empty,dim=1) print *,minval(empty,dim=1) end program memain This prints 2 empty lines (as expected).
[Bug fortran/116875] Internal compiler error: in make_decl_rtl, at varasm.cc:1443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116875 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-09-28 Status|UNCONFIRMED |NEW Known to fail||15.0, 7.5.0 Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. It is an old bug that affects all gfortran versions since at least gcc-7. The issue is triggered by the BLOCK construct. The dump-tree suggests that a decl for S1_POINTER is lost or not generated. I think I've seen at least one other PR with the same pattern.
[Bug fortran/116858] gfortran.dg/initialization_25.f90 test failure (exposed by r15-3890-g34bf6aa41ba539)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from anlauf at gcc dot gnu.org --- I am seeing the following on x86_64-pc-linux-gnu: Running /work/gnu/git/gcc-trunk/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/initialization_25.f90 -O xfail *-*-* (test for errors, line 11) Also seen on gcc-testresults... Can you please check again?
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 --- Comment #3 from anlauf at gcc dot gnu.org --- I meant: diff --git a/gcc/testsuite/gfortran.dg/unsigned_22.f90 b/gcc/testsuite/gfortran.dg/unsigned_22.f90 index bc2f810238d..17ebb973cf1 100644 --- a/gcc/testsuite/gfortran.dg/unsigned_22.f90 +++ b/gcc/testsuite/gfortran.dg/unsigned_22.f90 @@ -22,4 +22,5 @@ program memain read (10,*,iostat=iostat,iomsg=iomsg) u if (iostat == 0) error stop 7 if (iomsg /= "Unsigned integer overflow while reading item 1 of list input") error stop 8 + close(10, status="delete") end program memain
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #1) > The cause is that the unsigned_22 test (added in the named commit) leaves an > output file "fort.10", which is picked up by write_check3 which then calls > libgfortran raw_truncate. I guess the gfortran "unit-machinery" wants to > clear that file if it exists. > > Some option is needed to make the "fort.10" file name unique or something to > that effect in a way that it isn't picked up by write_check3. A dg- cleanup > function might do, perhaps one exists? A "git grep -w fort" in > testsuite/lib catches nothing though. Well observed. Can you test if adding a line close(10, status="delete") before the end program memain fixes the issue? If so, such a fix is pre-approved; you can also ask Thomas.
[Bug fortran/116679] Memory leak when creating derived type instance with allocatable component within array expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116679 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-09-20 Status|UNCONFIRMED |NEW --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. The testcase in comment#1 needs fixing (remove 'use bugdemo'). The memleak there depends on array being a pointer. Changing it to allocatable seems to plug the leak here. Note that replacing in the block items = [wrapper(1)] by items(1)% val = 1 also does not leak.
[Bug fortran/100273] [12/13/14 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/100273] [12/13/14 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE |ICE in |in |gfc_create_module_variable, |gfc_create_module_variable, |at |at |fortran/trans-decl.c:5352 |fortran/trans-decl.c:5352 --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15.
[Bug fortran/100273] [12/13/14/15 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #10 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-September/060949.html
[Bug fortran/100273] [12/13/14/15 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 --- Comment #9 from anlauf at gcc dot gnu.org --- Patch that fixes the ICE: diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc index 6692ac7ef4c..ee41d66e6d2 100644 --- a/gcc/fortran/trans-decl.cc +++ b/gcc/fortran/trans-decl.cc @@ -5540,7 +5540,8 @@ gfc_create_module_variable (gfc_symbol * sym) /* Create the variable. */ pushdecl (decl); gcc_assert (sym->ns->proc_name->attr.flavor == FL_MODULE - || (sym->ns->parent->proc_name->attr.flavor == FL_MODULE + || ((sym->ns->parent->proc_name->attr.flavor == FL_MODULE + || sym->ns->parent->proc_name->attr.flavor == FL_PROCEDURE) && sym->fn_result_spec)); DECL_CONTEXT (decl) = sym->ns->proc_name->backend_decl; rest_of_decl_compilation (decl, 1, 0);
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |15.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from anlauf at gcc dot gnu.org --- Backported to 14-branch. Closing. Thanks for the report!
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #13 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-August/060931.html
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline so far.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #6) > (In reply to anlauf from comment #3) > > Tentative obvious fix for NULL pointer dereference: > > > > diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc > > index 7ab82fa2f5b..de38f4a808f 100644 > > --- a/gcc/fortran/trans-io.cc > > +++ b/gcc/fortran/trans-io.cc > > @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const > > char * var_name, > >gcc_assert (sym || c); > > > >/* Build the namelist object name. */ > > - if (sym && !sym->attr.use_only && sym->attr.use_rename) > > + if (sym && !sym->attr.use_only && sym->attr.use_rename > > + && sym->ns->use_stmts->rename) > > string = gfc_build_cstring_const > > (sym->ns->use_stmts->rename->local_name); > >else > > string = gfc_build_cstring_const (var_name); > > Patch looks good. If it passes regression testing, you can commit it you > want. Yes, it passed. I was just packaging it for submission, but given your OK I will push to master and inform the list.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #5) > (In reply to anlauf from comment #4) > > (In reply to kargls from comment #1) > > > (In reply to philippe.wautelet from comment #0) > > > > > > > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > > > trigger an ICE. > > > > > > > > > > I agree with you about the ICE should not happen. Staring at F2023, > > > I find the following constraint. > > > > > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > > > association. > > > > > > If I understand it, your code is nonstandard. But, I don't use namelist, > > > so > > > will need to read through the Fortran standard a bit more. > > > > This constraint applies to the namelist statement and does not apply to the > > issue here. > > Yeah, I needed to review more the Fortran, and you beat me > to working out a patch. The '(R871)' above restricts the > constraint to namelist statement. However, this did lead to > > module mod_nml1 >implicit none >logical :: ldiag >namelist /nam_nml1/ldiag > end module mod_nml1 > > program ice_nml >use mod_nml1 >implicit none >integer :: ilu, j >namelist /nam_nml1/j !<-- Does this violates C8107? Yes, that is illegal and rejected by Intel and NAG, e.g.: NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200 Error: iii.f90, line 11: Redeclaration of symbol NAM_NML1 from USEd module MOD_NML1 detected at /@NAM_NML1 Warning: iii.f90, line 15: Unused local variable ILU [NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning] I think we should track that constraint violation separately (no regression) from the present PR (regression). >ldiag = .false. >j = 42 >write(*,nml=nam_nml1) > end program ice_nml > > % gfcx -o z a.f90 && ./z > &NAM_NML1 > LDIAG=F, > J=42 , > /
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #1) > (In reply to philippe.wautelet from comment #0) > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > trigger an ICE. > > > > I agree with you about the ICE should not happen. Staring at F2023, > I find the following constraint. > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > association. > > If I understand it, your code is nonstandard. But, I don't use namelist, so > will need to read through the Fortran standard a bit more. This constraint applies to the namelist statement and does not apply to the issue here.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #3 from anlauf at gcc dot gnu.org --- Tentative obvious fix for NULL pointer dereference: diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc index 7ab82fa2f5b..de38f4a808f 100644 --- a/gcc/fortran/trans-io.cc +++ b/gcc/fortran/trans-io.cc @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const char * var_name, gcc_assert (sym || c); /* Build the namelist object name. */ - if (sym && !sym->attr.use_only && sym->attr.use_rename) + if (sym && !sym->attr.use_only && sym->attr.use_rename + && sym->ns->use_stmts->rename) string = gfc_build_cstring_const (sym->ns->use_stmts->rename->local_name); else string = gfc_build_cstring_const (var_name);
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE with member of namelist |[14/15 Regression] ICE with |renamed by use module |member of namelist renamed ||by use module Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Priority|P3 |P4 Known to work||13.3.0 Target Milestone|--- |14.3 Known to fail||14.1.0, 14.2.0, 15.0 Last reconfirmed||2024-08-29 --- Comment #2 from anlauf at gcc dot gnu.org --- Reduced testcase: module mod_nml1 logical :: ldiag namelist /nam_nml1/ldiag end module mod_nml1 module mod_interm use mod_nml1 end module mod_interm program ice_nml ! Interchanging the following two lines fixes the ICE: use mod_nml1, ldiag_nml1 => ldiag use mod_interm integer :: ilu read(unit=ilu,nml=nam_nml1) end program ice_nml Works with Intel, NAG, Nvidia, flang. As written above, interchanging the use statements fixes the ICE.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #12 from anlauf at gcc dot gnu.org --- Created attachment 59021 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59021&action=edit Patch Revisiting this one, I arrived at the attached patch. This seems to fix the present issues and regtests fine, needing only minor adjustments to: gfortran.dg/alloc_comp_class_4.f03 (need to remove a bogus warning) gfortran.dg/pdt_26.f03 (adjust the count of __builtin_malloc)
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #11)
I tried a simpler variation of your patch that aims at a more coherent
error message:
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index f7cbb4bb5e2..28b27874298 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4377,10 +4377,22 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
if (a == NULL)
goto do_sort;
+ /* The generic interface of the following intrinsics was extended in F2008.
+ A specific interface may not be available at a selected standard. */
+ if ((gfc_option.allow_std & GFC_STD_F2008) != 0
+ && (strcmp (name, "atan") == 0
+ || strcmp (name, "atand") == 0))
+goto no_specific;
+
whoops:
gfc_error ("Too many arguments in call to %qs at %L", name, where);
return false;
+no_specific:
+ gfc_error ("Generic function %qs at %L is not consistent with a "
+"specific intrinsic interface", name, where);
+ return false;
+
keywords:
/* Associate the remaining actual arguments, all of which have
to be keyword arguments. */
With this you get the message:
Error: Generic function 'atan' at (1) is not consistent with a specific
intrinsic interface
whether atan is explicitly declared as intrinsic or not.
> Now, to real cause so head scratching. keywords are not honored!
>
> subroutine s3
> real :: r = 1.
> print *, atan (y=-1.d0,x=r) ! Should give error similar to s1 case
> end
>
> % gfcx -c a.f90
> a.f90:3:10:
>
> 3 | print *, atan (y=-1.d0,x=r) ! Should give error similar to
> s1 case
> | 1
> Error: Cannot find keyword named ‘y’ in call to ‘atan’ at (1)
>
> I think we need to rethink the handling of the 2 argument case, where we
> make the second argument optional. Then, in gfc_check_atan, we need to
> swap expressions to align Y with arg1 and X with arg2.
Yes, this is because once a keyword is used, we never reach the check.
Which makes me think whether sort_actual is the right place for the check.
Is there any generic intrinsic where a keyword is needed for resolving?
Besides the weird ALLOCATED(), where there can be only one argument
(ARRAY or SCALAR), but then this is a fixed number.
[Bug fortran/116128] missed optimisation: fortran sum instrinsic performed in order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116128
--- Comment #6 from anlauf at gcc dot gnu.org ---
Guided by the dump-tree for the inlining code, I played a little to see
what kind of code the middle-end expects. To this end I used C code.
The reference for the sum over a rank-1 array (given stride and count):
double __attribute__ ((noipa,noinline))
sum_v1 (double x[], int stride, int n)
{
double sum = 0.;
for (int i = 0; i < n; i++)
sum += x[i*stride];
return sum;
}
An optimizer might see a pattern in the array access. I guess that for
stride=1 it generates a separate path like:
double __attribute__ ((noipa,noinline))
sum_v2 (double x[], int stride, int n)
{
double sum = 0.;
if (stride == 1)
{
for (int i = 0; i < n; i++)
sum += x[i];
}
else
{
for (int i = 0; i < n; i++)
sum += x[i*stride];
}
return sum;
}
Unit stride should give faster loads (it does on vector machines).
I wonder if gcc does that rather obvious transformation if stride can
be 1 and the loop is "hot".
Another optimization could be partial sums with reordering - which is what
you mention - but only if associative math is enabled. Code might look like:
double __attribute__ ((noipa,noinline))
sum_v4 (double x[], int stride, int n)
{
double sum;
double tmp[4];
int i, off, n4;
if (n <= 0)
return 0.;
for (int i = 0; i < 4; i++)
tmp[i] = 0.;
n4 = n & ~0x3;
off = 0;
for (i = 0; i < n4; i += 4)
{
tmp[0] += x[off];
tmp[1] += x[off+1*stride];
tmp[2] += x[off+2*stride];
tmp[3] += x[off+3*stride];
off += 4*stride;
}
sum = (tmp[0] + tmp[1]) + (tmp[2] + tmp[3]);
for (; i < n; i++)
sum += x[off + (i-n4)*stride];
return sum;
}
While this may look natural when memory bandwidth is "infinite" and SIMD
performance is limited, I do not know what the situation is for common
scalar architectures.
Ideally, if annotation of a reduction loop (e.g. "associative math") could
tell the middle-end that any of the above transformations is allowed, the
generation of inline code could be rather target-agnostic.
Doing code transforms as above when generating inline code in the frontend
could end up in a nightmare.
[Bug fortran/116359] Nested contained procedures rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116359 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-08-26 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- There seems nothing wrong with gfortran here, it is the Fortran standard which is not as regular as you expect. (I am also bothered by this limitation, but it has there for quite some time.) Can we close this one?
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 --- Comment #8 from anlauf at gcc dot gnu.org --- I looked at this one again, also at the fortran-dump. Consider: subroutine s1 intrinsic :: atan real :: r = 1. print *, atan (-1.d0,r) end subroutine s2 external :: atan real :: r = 1. print *, atan (-1.d0,r) end subroutine s3 real :: r = 1. print *, atan (-1.d0,r) ! Should give error similar to s1 case end subroutine s4 real :: r = 1. print *, atan (-1.d0,r) ! Reasonable diagnostics contains elemental function atan (x, y) real, intent(in) :: x, y real :: atan atan = atan2 (x, y) end function atan end Subroutine s1 gets diagnosed with: pr113412.f90:4:10: 4 | print *, atan (-1.d0,r) | 1 Error: Generic function 'atan' at (1) is not consistent with a specific intrinsic interface which is correct. The fortran-dump therefore correctly shows: TRANSFER atan[((-1._8) (s1:r))] Subroutine s3 gives pr113412.f90:15:10: 15 | print *, atan (-1.d0,r) ! Should give error similar to s1 case | 1 Error: Too many arguments in call to 'atan' at (1) which looks like resolution happens slightly different. Subroutine s4 shows that regular interfaces are handled reasonably: pr113412.f90:20:10: 20 | print *, atan (-1.d0,r) ! Should give error similar to s1 case | 1 Error: Type mismatch in argument 'x' at (1); passed REAL(8) to REAL(4) NAG gives consistent diagnostics for s1 and s3, as does flang. (Nvidia is not so consistent, and Intel ICEs).
[Bug fortran/107145] Indefinite recursion in gfc_check_dummy_characteristics/gfc_compare_interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107145
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Priority|P3 |P4
Last reconfirmed||2024-08-20
--- Comment #1 from anlauf at gcc dot gnu.org ---
The following patch breaks the recursion:
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index b592fe4f6c7..80c7239eec7 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -1384,6 +1396,10 @@ gfc_check_dummy_characteristics (gfc_symbol *s1,
gfc_symbol *s2,
return false;
}
+ /* Short-cut for same symbols. */
+ if (s1 == s2)
+return true;
+
/* Check type and rank. */
if (type_must_agree)
{
However, we then miss the circular dependency, which is detected by NAG:
NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200
Warning: pr107145.f90, line 9: Unused dummy procedure P2
Error: pr107145.f90, line 8: Named interface P for entity P2 depends on P2
itself via SUB
Errors in declarations, no further processing for CIRCULAR
[Bug fortran/107508] Invalid bounds due to bogus reallocation on assignment with KIND=4 characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107508 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED Known to fail||12.3.0 Known to work||13.3.0 --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed in gcc-13.
[Bug fortran/99884] Double spaces in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed almost 2 years ago. Anything left?
[Bug fortran/106603] Problem with character(:), allocatable, intent(out) :: err for functions which return fixed arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106603 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-08-18 Status|UNCONFIRMED |WAITING Keywords||wrong-code Known to fail||12.3.0, 7.5.0 Priority|P3 |P4 Known to work||13.3.0, 14.2.0, 15.0 --- Comment #1 from anlauf at gcc dot gnu.org --- While this error goes back to at least 7.5.0 and is present in 12.3.0, it appears fixed on 13-branch and newer. Can you please verify that newer gfortran releases fix your problem?
[Bug fortran/114781] Error in ALLOCATE with MOLD=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114781 --- Comment #2 from anlauf at gcc dot gnu.org --- Update: at r15-2986 the allocation errors are no longer present. Likely fixed by r15-1704 and r15-2910. Older branches are still affected. Replacing mold= by source=, or using parentheses around polymorphic mold argument we hit issues with the ALLOCATE statement: MODULE mold_test_mo IMPLICIT NONE CONTAINS SUBROUTINE aalloc(sample) CLASS(*),INTENT(in) :: sample INTEGER :: localsample CLASS(*),ALLOCATABLE :: arr(:), tmparr(:) ! ALLOCATE(arr(1), mold=sample) ALLOCATE(arr(1), source=sample) CALL MOVE_ALLOC(arr, tmparr) SELECT TYPE(tmparr) TYPE is (INTEGER) PRINT *,tmparr END SELECT ! ALLOCATE(arr(2), mold=tmparr(1)) ! OK ! ALLOCATE(arr(2), mold=(tmparr(1))) ! ICE ALLOCATE(arr(2), source=tmparr(1)) ! runtime segfault SELECT TYPE(arr) TYPE is (INTEGER) PRINT *,arr END SELECT END SUBROUTINE aalloc END MODULE mold_test_mo PROGRAM mold_test USE mold_test_mo IMPLICIT NONE CALL aalloc(3) END PROGRAM mold_test
[Bug fortran/114146] REPEATABLE argument of RANDOM_INIT and repeated execution of the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114146 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- The updated docomentation is visible at https://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fINIT.html Thus fixed. Thanks for the report!
[Bug fortran/114146] REPEATABLE argument of RANDOM_INIT and repeated execution of the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114146 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #1) > Looks like someone needs to update the gfortran manual. Submitted: https://gcc.gnu.org/pipermail/fortran/2024-August/060848.html
[Bug fortran/99837] ICE in parse_associate, at fortran/parse.c:4780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837 --- Comment #4 from anlauf at gcc dot gnu.org --- The following variation (valid code) which compiles here with 14-branch fails at r15-2937: program p type t !integer, allocatable :: a(:) integer :: b end type class(t), allocatable :: x[:] select type (y => x) end select end % gfc-15 pr99837-zz.f90 -fcoarray=single pr99837-zz.f90:1:9: 1 | program p | 1 internal compiler error: in fold_convert_loc, at fold-const.cc:2768 0x24a75c6 internal_error(char const*, ...) ../../gcc-trunk/gcc/diagnostic-global-context.cc:491 0x97a1c2 fancy_abort(char const*, int, char const*) ../../gcc-trunk/gcc/diagnostic.cc:1772 0x7ab36c fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc-trunk/gcc/fold-const.cc:2768 0xb2ee7a trans_associate_var ../../gcc-trunk/gcc/fortran/trans-stmt.cc:2212 0xb33c81 gfc_trans_block_construct(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-stmt.cc:2423 0xa8f537 trans_code ../../gcc-trunk/gcc/fortran/trans.cc:2463 0xac6964 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:7961 0xa3696f translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7145 0xa3696f gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7459 0xa8c07f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221 --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to Sam James from comment #10) > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > interface.cc: In function ‘gfc_get_formal_from_actual_arglist’: > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > interface.cc:5726:21: warning: ‘s’ may be used uninitialized > [-Wmaybe-uninitialized] > 5726 | s->ts = a->expr->ts; > | ^ > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > interface.cc:5708:15: note: ‘s’ was declared here > 5708 | gfc_symbol *s; > | ^ OK, initialize. > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc: In function ‘gfc_get_intrinsic_function_symbol’: > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc:156:22: warning: ‘sym’ may be used uninitialized > [-Wmaybe-uninitialized] > 156 | sym->attr.external = 1; > | ^ > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc:153:15: note: ‘sym’ was declared here > 153 | gfc_symbol *sym; > | ^ Likewise. > In function ‘gfc_get_intrinsic_function_symbol’, > inlined from ‘specific_intrinsic_symbol’ at > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > trans-intrinsic.cc:4322:47: > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc:158:29: warning: ‘sym’ may be used uninitialized > [-Wmaybe-uninitialized] > 158 | sym->attr.always_explicit = 1; > | ^ > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc: In function ‘specific_intrinsic_symbol’: > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc:153:15: note: ‘sym’ was declared here > 153 | gfc_symbol *sym; > | ^ > > ``` OK. It makes sense to initialize sym in gfc_find_intrinsic_symbol.
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Sam James from comment #9)
> A handful more:
> ```
> In function ‘gfc_restore_backend_locus’,
> inlined from ‘gfc_trans_if_1’ at
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> trans-stmt.cc:1485:31:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> trans.cc:2323:39: warning: ‘saved_loc.lb’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 2323 | gfc_current_backend_file = loc->lb->file;
> | ^
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> trans-stmt.cc: In function ‘gfc_trans_if_1’:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> trans-stmt.cc:1464:9: note: ‘saved_loc.lb’ was declared here
> 1464 | locus saved_loc;
> | ^
This one is a false-positive. The code in question is:
if (code->expr1->where.lb)
{
gfc_save_backend_locus (&saved_loc);
gfc_set_backend_locus (&code->expr1->where);
}
gfc_conv_expr_val (&if_se, code->expr1);
if (code->expr1->where.lb)
gfc_restore_backend_locus (&saved_loc);
Maybe LTO does not understand that gfc_conv_expr_val (my guess) does not have
a side-effect that changes the condition (code->expr1->where.lb != NULL).
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> parse.cc: In function ‘parse_contained’:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> parse.cc:6578:15: warning: ‘sym’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 6578 | if (!sym->attr.pure)
> | ^
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> parse.cc:6507:15: note: ‘sym’ was declared here
> 6507 | gfc_symbol *sym;
> | ^
That could be solved by initializing sym.
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> match.cc: In function ‘gfc_match_call’:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> match.cc:5132:33: warning: ‘select_st’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 5132 | select_sym = select_st->n.sym;
> | ^
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> match.cc:5124:20: note: ‘select_st’ declared here
> 5124 | gfc_symtree *select_st;
> |^
That's again because gfc_get_ha_sym_tree is complicated and can be fixed
by initializing select_st.
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |15.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15.
[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-08-13 --- Comment #3 from anlauf at gcc dot gnu.org --- Running the resulting executable under valgrind shows issues that were not present in gcc-14: there are many reports of the type ==11462== Conditional jump or move depends on uninitialised value(s) ==11462==at 0x48386ED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11462==by 0x428DF0: __final_MAIN___T.1 (sizeof_6.f90:5) ==11462==by 0x42AF7C: __final_MAIN___T2.5 (sizeof_6.f90:5) ==11462==by 0x426D1E: MAIN__ (sizeof_6.f90:281) ==11462==by 0x42D581: main (sizeof_6.f90:287) ==11462== [...] ==11462== Use of uninitialised value of size 8 ==11462==at 0x428FD3: __final_MAIN___T.1 (sizeof_6.f90:5) ==11462==by 0x42AF7C: __final_MAIN___T2.5 (sizeof_6.f90:5) ==11462==by 0x426D1E: MAIN__ (sizeof_6.f90:281) ==11462==by 0x42D581: main (sizeof_6.f90:287) ==11462== [...] Commenting lines 281..287 (six deallocates at the end of the main), the issues seems to disappears. A bookkeeping issue in the finalization?
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 --- Comment #14 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #13) > (In reply to anlauf from comment #11) > > Created attachment 58926 [details] > > Patch > > > > This patch applies the check of the declared type in resolve_array_list, > > where there is already a check for unlimited polymorphic elements. > > > > Will submit if it regtests ok. > > Looks good except don't you also need to check c->expr->ts.type == > BT_DERIVED. > > One can have > > type, abstract :: a > ... > end type a > > Or, does the 'abstract' attribute cause gfortran to use BT_CLASS? Can you construct a testcase which is missed? type(a) :: a_instance is already rejected with Error: 'a_instance' at (1) is of the ABSTRACT type 'a' from which I took over the wording. See also F2018:C703: The derived-type-spec shall not specify an abstract type (7.5.7).
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #12 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-August/060824.html
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 --- Comment #11 from anlauf at gcc dot gnu.org --- Created attachment 58926 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58926&action=edit Patch This patch applies the check of the declared type in resolve_array_list, where there is already a check for unlimited polymorphic elements. Will submit if it regtests ok.
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #9)
> I had
>
> gfc_error ("Declared type of %qs has an ABSTRACT attribute, "
>"it cannot appear in the array constructor at %L",
>expr->symtree->name, &expr->where);
>
> but the word 'it' seemed too vague to me. Using NAG's message
> would have
>
> gfc_error ("Array constructor value %qs at %L is of abstract type %qs",
>expr->symtree->name, &expr->where, expr->ts.u.derived->name);
>
> with the output
>
> Array constructor value A_ARRAY is of abstract type __CLASS_MY_MODULE_A_1_0A
>
> gfortran mangles names. I suppose we can do
>
> gfc_error ("Array constructor value %qs at %L is of abstract type,
>expr->symtree->name, &expr->where);
>
> and leave out the name of the derived type.
There is already a solution: gfc_typename
gfc_error ("Array constructor value %qs at %L is of abstract type %qs",
expr->symtree->name, &expr->where, gfc_typename (&expr->ts));
This gives:
Error: Array constructor value 'a_array' at (1) is of abstract type 'CLASS(a)'
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #7)
> I can no longer edit meta data for a PR. The keyword: field is wrong. This
> is an ice-on-invalid-code. Please change.
I think you need to login with your @gcc.gnu.org address now, if you have
one.
Regarding your patch, is there a reason you emit the symbol name twice?
gfc_error ("Declared type of %qs has an ABSTRACT attribute, "
"%qs cannot appear in the array constructor at %L",
expr->symtree->name, expr->symtree->name, &expr->where);
How about just doing it once (see e.g. NAG)?
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 --- Comment #3 from anlauf at gcc dot gnu.org --- There may be some doubt on the validity of the testcase. Intel ifx: pr114308.f90(20): warning #9108: Polymorphic values in array constructors will be converted to their declared type. [A_ARRAY] a_array = [a_array, b_instance] ! This one throws an ICE -^ pr114308.f90(20): error #6315: The array-constructor has ac-values of differing types. [B_INSTANCE] a_array = [a_array, b_instance] ! This one throws an ICE --^ compilation aborted for pr114308.f90 (code 1) NAG: NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200 Warning: pr114308.f90, line 21: Symbol B_INSTANCE referenced but never set Error: pr114308.f90, line 20: Array constructor value A_ARRAY is of abstract type A [NAG Fortran Compiler error termination, 1 error, 1 warning]
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2024-08-11 --- Comment #8 from anlauf at gcc dot gnu.org --- Patches from comment#3 and comment#5 have been applied. If the LTO warnings are fixed, please close this PR. Otherwise we should look into remaining warnings.
[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- OK, this is weird: Breakpoint 3, conv_intrinsic_move_alloc (code=) at ../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:12769 12769 from_se.expr = gfc_get_symbol_decl (vtab); (gdb) l 12764 gfc_symbol *vtab; 12765 from_tree = from_se.expr; 12766 12767 vtab = gfc_find_vtab (&from_expr->ts); 12768 gcc_assert (vtab); 12769 from_se.expr = gfc_get_symbol_decl (vtab); 12770 } 12771 gfc_add_block_to_block (&block, &from_se.pre); 12772 12773 to_se.want_pointer = 1; The offending code here was added in r15-1704-gaa3599a10cab34: commit aa3599a10cab34104c0b9bd6951c5f0c420795d8 Author: Andre Vehreschild Date: Tue Jun 11 12:52:26 2024 +0200 Add gfc_class_set_vptr. First step to adding a general assign all class type's data members routine. Having a general routine prevents forgetting to tackle the edge cases, e.g. setting _len. gcc/fortran/ChangeLog: * trans-expr.cc (gfc_class_set_vptr): Add setting of _vptr member. * trans-intrinsic.cc (conv_intrinsic_move_alloc): First use of gfc_class_set_vptr and refactor very similar code. * trans.h (gfc_class_set_vptr): Declare the new function. CC'ing Andre.
[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292 --- Comment #6 from anlauf at gcc dot gnu.org --- Note that the ICE also happens for other variable types (e.g. integer), and disappears for rank > 0. This works: program p character, allocatable :: buffer, dummy ! integer, allocatable :: buffer, dummy dimension :: buffer(:), dummy(:) contains subroutine s call move_alloc (dummy, buffer) end end
[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292
--- Comment #5 from anlauf at gcc dot gnu.org ---
Breakpoint 1, build_function_decl (sym=0x3316310, global=global@entry=false)
at ../../gcc-trunk/gcc/fortran/trans-decl.cc:2486
2486 gcc_assert (current_function_decl == NULL_TREE
(gdb) l
2481 /* Set the line and filename. sym->declared_at seems to point to the
2482 last statement for subroutines, but it'll do for now. */
2483 gfc_set_backend_locus (&sym->declared_at);
2484
2485 /* Allow only one nesting level. Allow public declarations. */
2486 gcc_assert (current_function_decl == NULL_TREE
2487 || DECL_FILE_SCOPE_P (current_function_decl)
2488 || (TREE_CODE (DECL_CONTEXT (current_function_decl))
2489 == NAMESPACE_DECL));
2490
The ICE comes after:
(gdb) p debug_tree(current_function_decl)
>
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76a327e0
attributes
value >>
arg-types >>
static QI pr116292.f90:4:14 align:8 warn_if_not_align:0 context
result
ignored VOID pr116292.f90:4:14
align:8 warn_if_not_align:0 context >
(mem:QI (symbol_ref:DI ("s.0") [flags 0x3] ) [0 S1 A8])
struct-function 0x7680a0c0>
[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-08-08 Keywords||ice-on-valid-code CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 --- Comment #4 from anlauf at gcc dot gnu.org --- Confirmed. Reduced testcase: program p character, allocatable :: buffer, dummy contains subroutine s call move_alloc (dummy, buffer) end end % gfc-15 pr116292.f90 pr116292.f90:5:35: 5 | call move_alloc (dummy, buffer) | 1 internal compiler error: in build_function_decl, at fortran/trans-decl.cc:2486 0x24a0a76 internal_error(char const*, ...) ../../gcc-trunk/gcc/diagnostic-global-context.cc:491 0x9799d6 fancy_abort(char const*, int, char const*) ../../gcc-trunk/gcc/diagnostic.cc:1772 0x75758c build_function_decl ../../gcc-trunk/gcc/fortran/trans-decl.cc:2486 0xac17bc gfc_get_symbol_decl(gfc_symbol*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:1861 0xadfe3e gfc_conv_variable ../../gcc-trunk/gcc/fortran/trans-expr.cc:3155 0xa8 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.cc:8912 0xade1dd gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc-trunk/gcc/fortran/trans-expr.cc:9857 0xaddcef gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.cc:8927 0xac11db gfc_get_symbol_decl(gfc_symbol*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:2031 0xb00d5d conv_intrinsic_move_alloc ../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:12769 0xb00d5d gfc_conv_intrinsic_subroutine(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:12918 0xa8e752 trans_code ../../gcc-trunk/gcc/fortran/trans.cc:2425 0xac5b24 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:7961 0xac58dc gfc_generate_contained_functions ../../gcc-trunk/gcc/fortran/trans-decl.cc:6076 0xac58dc gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:7893 0xa3615f translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7132 0xa3615f gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7446 0xa8b3cf gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241
[Bug fortran/116128] missed optimisation: fortran sum instrinsic performed in order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116128 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to mjr19 from comment #3) > It seems that most of these are in-line expanded by gfortran-14.1, at least > in some cases. > > function foo(a,n) > real(kind(1d0))::a(*),foo > integer::n > > foo=sum(a(1:n)) > end function foo > > and > > function foo(a) > real(kind(1d0)), contiguous::a(:) > real(kind(1d0)):: foo > > foo=sum(a) > end function foo > > are both inline expanded, and with gfortran-14.1 -O3 -mavx2 -S give > > .L5: > vaddsd (%rax), %xmm0, %xmm0 > addq$32, %rax > vaddsd -24(%rax), %xmm0, %xmm0 > vaddsd -16(%rax), %xmm0, %xmm0 > vaddsd -8(%rax), %xmm0, %xmm0 > cmpq%rdx, %rax > jne .L5 > > and > > .L5: > movq%rdx, %rax > addq$1, %rdx > salq$5, %rax > addq%rcx, %rax > vaddsd (%rax), %xmm0, %xmm0 > vaddsd 8(%rax), %xmm0, %xmm0 > vaddsd 16(%rax), %xmm0, %xmm0 > vaddsd 24(%rax), %xmm0, %xmm0 > cmpq%rdx, %rsi > jne .L5 > > At -O2 there is no unrolling, but the benefits of unrolling whilst retaining > the data dependency on %xmm0 must be very slight. (I am also slightly > confused that using contiguous is not equivalent to the a(*) version.) Indeed, this is an interesting observation! Comparing the generated tree code and assembler for the second (contiguous) version, using either foo = sum (a) or foo = sum (a(1:size(a))) show slight differences which might be worth to investigate. > At -Ofast one gets > > .L5: > vaddpd (%rax), %ymm0, %ymm0 > addq$32, %rax > cmpq%rdx, %rax > jne .L5 > > and > > .L5: > movq%rax, %rdx > addq$1, %rax > salq$5, %rdx > vaddpd (%rcx,%rdx), %ymm0, %ymm0 > cmpq%rax, %rsi > jne .L5 I played with your examples. Indeed, the generated code looks conservative, with improvements going from -O2 -> -O3 -> -O3 -ffast-math -> -Ofast . The frontend generates straightforward tree code, so even allowing reassociation by the optimizer will not make it possible to take full advantage of vectorization similar to nvfortran. Unless the middle-end allowed to annotate loops/loop nests to make a transformation of the loop. Of course such an optimization would only be allowable for types for which reassociation is allowed (or with -ffast-math). (Compilers for real vector machines do generate code for recursively calculating partial sums, otherwise these machines would be painfully slow.) What gcc seems to lack is support for annotating loop nests to collapse loops - I only see mentioning of the explicit OMP annotation. If we loop over elements of a contiguous array, this may result in reduction of a significant loop overhead. > In contrast nvfortran at -O2 and above produces > > .LBB0_7: > movq%rdx, %r8 > vaddpd (%rsi), %ymm0, %ymm0 > vaddpd 32(%rsi), %ymm1, %ymm1 > vaddpd 64(%rsi), %ymm2, %ymm2 > vaddpd 96(%rsi), %ymm3, %ymm3 > subq$-128, %rsi > addq$-16, %rdx > addq$-15, %r8 > cmpq$16, %r8 > jg .LBB0_7 > > I am not sure that I like the loop control instructions, but the vaddpd's to > four separate sums look good as this breaks the data dependencies between > the longish-latency vaddpd's. One could emulate this by switching to a fast library version of sum for sufficiently large array arguments (with a threshold to be determined, like we do e.g. for using dgemm from blas instead of matmul). > If the code had been written with an explicit loop > > foo=0 > do i=1,n > foo=foo+a(i) > enddo > > then it would not be standard-conformant to rearrange into partial sums as > gfortran does at -Ofast, and nvfortran does at -O2. Right. > But my understanding is > that the intrinsic sum function does not specify the ordering, and hence any > ordering would be standard-compliant, Agree here. > and, arguably, the use of partial sums > actually increases the accuracy for general data, and so should be > preferable from an accuracy point of view, as well as for performance. I do not see this. Why should it increase accuracy for *general* data? It's just faster but numerically different, isn't it? > Gfortran appears not to support the newly-introduced "reduce" qualifier of > "do concurrent". No, not yet. But there are open pr's on this, and I think there was a project. Do not know about it's status, though
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Sam James from comment #4)
> That works, thanks!
Did you also need to apply an equivalent initialization to silence the
warnings in comment#1:
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index 40f4c4f4b0b..62c349da7f6 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -131,7 +131,7 @@ gfc_type_abi_kind (bt type, int kind)
gfc_symbol *
gfc_get_intrinsic_sub_symbol (const char *name)
{
- gfc_symbol *sym;
+ gfc_symbol *sym = NULL;
gfc_get_symbol (name, gfc_intrinsic_namespace, &sym);
sym->attr.always_explicit = 1;
If this solves the issues reported here, I can push these changes.
[Bug fortran/116128] missed optimisation: fortran sum instrinsic performed in order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116128 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 --- Comment #2 from anlauf at gcc dot gnu.org --- Can you provide testcases for discussion? The library versions have to deal with different situations: - non-unit strides. Vectorization on many architectures only works for unit stride, or for those processors with support for gather/(scatter). - minval/maxval need to deal with NaNs etc. for proper IEEE support. One could try different paths for better vectorization: (1) add runtime library versions/code paths for unit stride (2) generate inline code instead of calling the runtime library (3) create avx2/... versions of the runtime library code (this was done for matmul so far). Among these options, (2) is probably the hardest one. Option (1) would allow auto-vectorization by the compiler, while (3) looks like a natural but manual solution for x86. > makes me think that the optimisations of omp simd reduce(+) would be > permitted. omp simd is something which could be tried for 'sum', but to get full performance needs a rewrite of the related library code. > The same comment applies to dot_product, and probably the other intrinsic > reduction operations. dot_product is inline-expanded.
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Sam James from comment #0)
> With an LTO bootstrap, I saw the following:
> ```
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> symbol.cc: In function ‘gfc_get_ha_symbol’:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> symbol.cc:3606:7: warning: ‘st’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 3606 | if (st)
> | ^
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> symbol.cc:3602:16: note: ‘st’ declared here
> 3602 | gfc_symtree *st;
> |^
> ```
>
> At a glance, it looks like it might be right.
>
> ```
> int
> gfc_get_ha_symbol (const char *name, gfc_symbol **result)
> {
> int i;
> gfc_symtree *st;
>
> i = gfc_get_ha_sym_tree (name, &st);
>
> if (st)
> *result = st->n.sym;
> else
> *result = NULL;
>
> return i;
> }
> ```
>
> We always test st after calling gfc_get_ha_sym_tree, but gfc_get_ha_sym_tree
> doesn't _always_ initialise st (result):
>
> int
> gfc_get_ha_sym_tree (const char *name, gfc_symtree **result)
> {
> gfc_symtree *st;
> int i;
>
> i = gfc_find_sym_tree (name, gfc_current_ns, 0, &st);
>
> if (st != NULL)
> {
> gfc_save_symbol_data (st->n.sym);
> *result = st;
> return i;
> }
>
> i = gfc_find_sym_tree (name, gfc_current_ns, 1, &st);
> if (i)
> return i;
>
> if (st != NULL)
> {
> *result = st;
> return 0;
> }
>
> return gfc_get_sym_tree (name, gfc_current_ns, result, false);
> }
I can imagine that it is difficult to prove that in gfc_get_ha_symbol
st always gets set before the test. Does it help to initialize it?
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index b5143d9f790..a8b623dd92a 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3599,7 +3599,7 @@ int
gfc_get_ha_symbol (const char *name, gfc_symbol **result)
{
int i;
- gfc_symtree *st;
+ gfc_symtree *st = NULL;
i = gfc_get_ha_sym_tree (name, &st);
[Bug fortran/101919] Inconsistent -Wstringop-overread warning with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101919 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||8.5.0 Known to work||7.5.0 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > This fixes comment#2: > > diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c However, it does not fix the following even simpler example: subroutine foo (d, e) implicit none character(len=10) :: d character(len=*) :: e integer :: i = 0 d = '1234567890'(6:10+i) ! Warning d = '1234567890'(6+0*i:10+i) ! Warning d = '1234567890'(6+1*i:10+i) ! OK e = '1234567890'(6:10+i) ! OK end The code appears to work as expected, but I cannot find a way to suppress the warning at -flto -O0.
[Bug fortran/109345] [12/13/14/15 Regression] class(*) variable that is a string array is not handled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |12.5 Known to fail||12.4.0, 13.3.0, 14.1.0, ||15.0 Known to work||11.5.0 Summary|class(*) variable that is a |[12/13/14/15 Regression] |string array is not handled |class(*) variable that is a |correctly |string array is not handled ||correctly Ever confirmed|0 |1 Keywords||wrong-code Priority|P3 |P4 Last reconfirmed||2024-07-23 --- Comment #1 from anlauf at gcc dot gnu.org --- Interesting bug. This does work in 11.5.0 but fails in 12+. Slightly rewritten to exhibit the issue more clearly: program test implicit none character(len=12) :: str_array(4) !< Array of strings str_array(:) = "" str_array(1) = "12345678" str_array(2) = "@ABCDEFG" call foo2(str_array) !< char type call foo (str_array) !< class(*) call foo3(str_array) !< class(*) with str copy contains subroutine foo ( var) !< Uses class(*) class(*), intent(in) :: var(:) integer :: i print *, "Using class(*)" select type (var) type is (character(len=*)) do i = 1, size(var) print *, len_trim(var(i)), var(i)==str_array(i), "data:", trim(var(i)) enddo end select end subroutine foo2 (var) !< Uses char type character(len=*), intent(in) :: var(:) integer :: i print *, "Using character(*)" do i = 1, size(var) print *, len_trim(var(i)), var(i)==str_array(i), "data:", trim(var(i)) enddo end subroutine foo3 (var) !< Uses class(*) with a workaround class(*), intent(in) :: var(:) integer :: i character(len=:), dimension(:), allocatable :: str select type (var) type is (character(len=*)) str = var !< copy class(*) var to an allocatable string print *, "Using class(*), with string copy workaround" do i = 1, size(str) print *, len_trim(str(i)), str(i)==str_array(i), "data:", trim(str(i)) enddo print *, (str(i)==var(i),i=1,size(str)) print *, (str(:)==var(:)) end select end end This prints with 11.5.0: Using character(*) 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: Using class(*) 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: Using class(*), with string copy workaround 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: T T T T T T T T With 12+: Using character(*) 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: Using class(*) 8 T data:12345678 12 F data:2345678@ 12 F data:345678@A 12 F data:45678@AB Using class(*), with string copy workaround 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: T F F F T T T T The issue seems to require a class(*) dummy involved.
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 --- Comment #15 from anlauf at gcc dot gnu.org --- Paul, the fix was fine for 15-mainline and 14-branch. There seems to be testsuite fallout on 13-branch (pr116040), because this fix apparently depends on the fix for pr89645, which is quite large (too large for 13-branch I am afraid). If you revert r13-8926, you might fix pr116040.
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #23 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #22) > (In reply to anlauf from comment #21) > > (In reply to Paul Thomas from comment #20) > > > OK the regression is fixed - thanks for the green light, Harald. > > > > > > It's a pity that I have missed the 4.2 release :-( > > > > > > Paul > > > > It is more important that 14.2 gets regression-free out of the door. > > Indeed! I reverted the patch but it doesn't seem to have been recorded here > (Is that normal?). I just checked that my tree is synched with the release > branch and that dependent_decls_2.f90 fails while dependent_decls_3.f90 > compiles and runs successfully. I don't know why it is not recorded here. The auto-generated ChangeLog nevertheless got it. > My original plan was to update with the regression fix but, being ultra > careful, recompiled and regtested, which caused me to time out on the > release. No, that's fine. It's better to wait until after the 14.2 release. Did you fully understand why the ordering of the treatment of the dummy arguments changed the way we observed? I got lost when I compared the tree dumps before and after the 1st committed patch. Was it because one dummy was used in the declaration of another one? I'll try to gather some more ideas to stress-test the robustness of the handling of dummy declarations. > Paul Cheers, Harald
[Bug fortran/115997] Findloc does not find the result of a function with a deferred-length character return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997 --- Comment #3 from anlauf at gcc dot gnu.org --- The original issue was reported for findloc, but did occur with several other intrinsics accepting deferred-length character. If you edit the bugzilla search to include resolved issues, you will also see the mentioned one. You have several options to go beyond 13.1: - try upgrading to 13.3 - wait for the upcoming 14.2 release (expected soon)
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #20 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15, and backported to all open branches. Closing. Thanks for the report!
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #21 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #20) > OK the regression is fixed - thanks for the green light, Harald. > > It's a pity that I have missed the 4.2 release :-( > > Paul It is more important that 14.2 gets regression-free out of the door. Unfortunately I test my codes less with trunk than with the latest release branch, otherwise I would have discovered the issue in comment#12 earlier. It takes too much time to regularly rebuild a larger software stack with trunk on my notebook, so I normally do this later in the development cycle. Just did that, and it seems to look good. :-) Anyway, the complete fix for this PR still looks like a candidate for 14-branch to me, maybe for a more quiet time with sufficient distance to release dates... Thanks for the quick reaction and the fix on trunk! Harald
[Bug fortran/59104] 15 Regression - Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #17 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #16) > Created attachment 58717 [details] > Fix for the regression > > The mechanism in the original fix was OK but the use of the locus location > was not. I will investigate why this is the case but the attached works and > is very close to the first thing that I tried for the PR! > > It regtests fine. I will dejagnu-ify the testcase and will commit to > mainline in 24 hours, if I don't hear objections. I've just tested that fix and it works here. Fixes also the full module where I extracted the reproducer from. OK from my side. Thanks, Paul!
[Bug fortran/59104] 15 Regression - Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #15 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #14) > Seems to affect only dummies, not local arrays. Comparing the dump tree between working and failing, the order of the generation of the descriptors seems reversed, i.e. a bound is set from a variable that is set later, which is why one sees a 0 or junk. I haven't figured out yet how the patch leads to that effect...
[Bug fortran/59104] 15 Regression - Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #14 from anlauf at gcc dot gnu.org --- Further reduced: program p implicit none integer, parameter :: nx = 64 real, dimension(nx) :: x, s, d, f print *, shape (x), shape (s), shape (d), shape (f) call sub (x,s,d,f) contains subroutine sub (v, w, e, g) real, intent(in):: v(:) real, intent(out), dimension (size (v)) :: w ! OK real, intent(out), dimension (size (v)) :: e ! not OK real, intent(out), dimension (size (v)) :: g ! not OK real, dimension (size (v)) :: x real, dimension (size (v)) :: y print *, shape (v), shape (w), shape (e), shape (g), shape (x), shape (y) end subroutine sub end Should print: 64 64 64 64 64 64 64 64 64 64 Now prints: 64 64 64 64 64 64 0 0 64 64 It looks like only the first intent(out) argument of sub has the right size, the second and third do not. Replacing in the size() expressions in the declarations of dummies e or g array v by w does not fix the problem. Seems to affect only dummies, not local arrays.
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #12 from anlauf at gcc dot gnu.org --- Paul, can I ask you to revert commit r14-10477 asap? The following code - extracted from a larger code base - miscompiles with it: program p implicit none integer, parameter :: nx = 64, ny = 32 real :: x(nx,ny), s(nx/2,ny), d(nx/2,ny) print *, shape (x), shape (s), shape (d) call sub (x,s,d) contains subroutine sub (v, w, d) real, intent(in) :: v(:,:) real, intent(out), dimension (size (v,dim=1)/2,size (v,dim=2)) :: w, d print *, shape (v), shape (w), shape (d) end subroutine sub end Correct output should be: 64 32 32 32 32 32 64 32 32 32 32 32 With 15-trunk and 14 after the above commit I get - dependent on -Ox: 64 32 32 32 32 32 64 32 32 32 363993500 0 or 64 32 32 32 32 32 64 32 32 32 0 0 Reducing the testcase further make the commit look innocent, however...
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834 Bug 32834 depends on bug 59104, which changed state. Bug 59104 Summary: Wrong result with SIZE specification expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug fortran/55858] When scalarizing contiguous whole-arrays, consider folding into a single loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55858 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115935 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- See also pr115935 on missed optimizations when zeroing of contiguous whole arrays that are components of derived types.
[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||mscfd at gmx dot net --- Comment #12 from anlauf at gcc dot gnu.org --- *** Bug 115997 has been marked as a duplicate of this bug. ***
[Bug fortran/115997] Findloc does not find the result of a function with a deferred-length character return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- Fixed in newer releases. Please consider upgrading. *** This bug has been marked as a duplicate of bug 110288 ***
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #15 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-July/060703.html
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #58695|0 |1 is obsolete|| --- Comment #14 from anlauf at gcc dot gnu.org --- Created attachment 58702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58702&action=edit Better fix. This is a much safer fix and also much simpler. Currently regtesting. Will submit later if it passes.
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #12) > Created attachment 58695 [details] > Tentative patch > > This patch fixes the ICE by ensuring to derive the element size of constant > character elements in the array constructor from these and not trying > to guess from the deferred-length element. > > Currently reg-testing. Regtest was OK.
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #12 from anlauf at gcc dot gnu.org --- Created attachment 58695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58695&action=edit Tentative patch This patch fixes the ICE by ensuring to derive the element size of constant character elements in the array constructor from these and not trying to guess from the deferred-length element. Currently reg-testing.
[Bug fortran/115781] Error with passing array of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781 --- Comment #2 from anlauf at gcc dot gnu.org --- Interesting observation: replacing call use_mats(mats) by call use_mats(mats(lbound(mats,1):)) leads to apparently correct output: top level: mats, lbound= 2, ubound= 4 top level, 2: nRows= 2 top level, 3: nRows= 3 top level, 4: nRows= 4 in use_mats: mats, lbound= 1, ubound= 3 use_mats, 1: nRows= 2 use_mats, 2: nRows= 3 use_mats, 3: nRows= 4
[Bug fortran/115781] Error with passing array of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed||2024-07-16 Keywords||wrong-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/115884] overload when one specific subroutine has no arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115884 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to john.harper from comment #2) > Thank you kargls. My test program compiled and ran OK with another > machine which has gfortran 14.1.1. My Ubuntu system doesn't make it > easy for me to upgrade from gfortran 13.1. That's not your problem. Closing then as WORKSFORME.
[Bug fortran/115935] Extend lowering to memset for zeroing array when it's used as a component reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115935 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-07-16 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/100273] [11/12/13/14/15 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > Looks very related to the len_trim issue in pr84868. Possibly a duplicate. After the fix for pr84868, the issue still persists. Reduced testcase: module m implicit none private contains subroutine s() ! character, parameter :: c(3) = ['*', '+', '-'] ! works when placed here contains function f(n) result(z) integer, intent(in) :: n character, parameter :: c(3) = ['*', '+', '-'] ! ICE when here character(len_trim(c(n))) :: z z = c(n) end end end We hit the assert in gfc_create_module_variable: gcc_assert (sym->ns->proc_name->attr.flavor == FL_MODULE || (sym->ns->parent->proc_name->attr.flavor == FL_MODULE && sym->fn_result_spec)); (gdb) p sym->ns->proc_name->attr.flavor $1 = FL_PROCEDURE (gdb) p sym->ns->parent->proc_name->attr.flavor $2 = FL_PROCEDURE For the working version from above, one finds: (gdb) p sym->ns->proc_name->attr.flavor $3 = FL_PROCEDURE (gdb) p sym->ns->parent->proc_name->attr.flavor $4 = FL_MODULE
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #10) > Leave open partly because it is awaiting backporting to 14-branch but also > because there are remaining, pre-existing issues involving parentheses > around selector/source expressions: > https://gcc.gnu.org/pipermail/fortran/2024-May/060510.html Paul, is this still on your list of backports?
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #8 from anlauf at gcc dot gnu.org --- Paul, are you planning to backport your fix?
[Bug fortran/115700] [11/12/13 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[11/12/13/14 regression]|[11/12/13 regression] Bogus |Bogus warning for associate |warning for associate with |with assumed-length |assumed-length character |character array |array --- Comment #8 from anlauf at gcc dot gnu.org --- Original issue fixed on mainline for gcc-15, and on 14-branch so far. Backporting further seems to depend on backporting at least the changes to trans-stmt.cc from r14-1629. I'd rather not do this. Leaving open to track the issues mentioned in comment#5.
[Bug fortran/115788] New: [F2018] Implement OUT_OF_RANGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115788 Bug ID: 115788 Summary: [F2018] Implement OUT_OF_RANGE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- F2018 has: 16.9.146 OUT_OF_RANGE (X, MOLD [, ROUND]) Description. Whether a value cannot be converted safely. Class. Elemental function. Arguments. X shall be of type integer or real. MOLD shall be an integer or real scalar. If it is a variable, it need not be defined. ROUND (optional) shall be a logical scalar. ROUND shall be present only if X is of type real and MOLD is of type integer. Result Characteristics. Default logical. Result Value. Case(i): If MOLD is of type integer, and ROUND is absent or present with the value false, the result is true if and only if the value of X is an IEEE infinity or NaN, or if the integer with largest magnitude that lies between zero and X inclusive is not representable by objects with the type and kind of MOLD. Case(ii): If MOLD is of type integer, and ROUND is present with the value true, the result is true if and only if the value of X is an IEEE infinity or NaN, or if the integer nearest X, or the integer of greater magnitude if two integers are equally near to X, is not representable by objects with the type and kind of MOLD. Case(iii): Otherwise, the result is true if and only if the value of X is an IEEE infinity or NaN that is not supported by objects of the type and kind of MOLD, or if X is a finite number and the result of rounding the value of X (according to the IEEE rounding mode if appropriate) to the extended model for the kind of MOLD has magnitude larger than that of the largest finite number with the same sign as X that is representable by objects with the type and kind of MOLD. Examples. If INT8 is the kind value for an 8-bit binary integer type, OUT_OF_RANGE (−128.5, 0_INT8) will have the value false and OUT_OF_RANGE (−128.5, 0_INT8, .TRUE.) will have the value true.
[Bug fortran/107996] ICE in gfc_walk_array_ref, at fortran/trans-array.cc:11429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107996 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-07-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- The testcase in comment#0 is rejected since gcc-14 (but still ICEs in gcc-13): pr107996-z1.f90:3:31: 3 | print *, [character(size(a(:))) :: 'a'] | 1 Error: Scalar variable 'a' has an array reference at (1) The testcases in comment#1 however still fail with a bogus error.
[Bug fortran/115700] [11/12/13/14 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-July/060625.html What the patch does not address is substring references, e.g. associate (tmp4 => x(:)(1:)) if (len (tmp4) /= len (x)) stop 4 end associate I looked at resolve_assoc_var, at the block: /* Fix up the type-spec for CHARACTER types. */ creating a new string length and setting sym->ts.deferred = 1; but could not find suitable restrictions so that no regression occurs. Maybe gfc_conv_expr_descriptor is another place: /* Set the string_length for a character array. */ but gfc_get_expr_charlen (expr) returns a non_lvalue_expr, so this fails for me sooner or later.
[Bug fortran/115700] [11/12/13/14 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Adding Paul (sorry!), as he knows the associate stuff much better than me.
[Bug fortran/115700] [11/12/13/14 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 58553 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58553&action=edit Draft patch Very hackish patch that sets the character length of the selector at the beginning of the associate block if the target is a variable and thus is known in advance. Not sure if this is the right approach, but it fixes the testcase.
[Bug fortran/115711] Fortran: extra malloc and copy with transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115711 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Interesting. At -Ofast and on Skylake, the optimized tree has for the second variant: A.20_11 = __builtin_alloca_with_align (32, 64); and I do not see a call to malloc in the assembler, but at -O3 -mavx2: _9 = __builtin_malloc (32); which is visible in the assembler. Similar findings apply to subroutine foo3(a,b,n) integer, intent(in) :: n complex(kind(1d0)) ::a(n) real(kind(1d0)) ::b(2*n) b=transfer(a,b) end So the questions are: which option of -Ofast does enable the use of alloca, and what can be done to merge the memcpy? Is it potential aliasing/overlap?
[Bug fortran/114019] allocation with source of deferred character length entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114019 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15, and backported to 14-branch. Closing. Might be backportable to 13-branch, but not tested.
[Bug fortran/114019] allocation with source of deferred character length entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114019 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-June/060609.html
[Bug fortran/115689] Missed deallocation before exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115689 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #4) > (In reply to kargls from comment #3) > > The code you posted is standard conforming, and when > > compiled, executes as expected. > > > > My point is that the program is exiting. The operate system will > > reap the process and reclaim the memory. Valgrind need not warn > > about this. It is just noise. It is not a memory leak. If anything > > it is poor programming on the part of the person that wrote the > > code, and arguably a bug the code. > > > > I agree completely, I would prefer that programmers explicitly deallocate. That's what I do in runtime tests (unless I forget to). > I simply do not know what our expectations should be when testing. Maybe in > this case it is a don't care. I posted the question for clarification from > others. Running the program from comment#0 - compiled with ifx - under valgrind gives here: ==12826== HEAP SUMMARY: ==12826== in use at exit: 60 bytes in 1 blocks ==12826== total heap usage: 13 allocs, 12 frees, 12,926 bytes allocated ==12826== ==12826== LEAK SUMMARY: ==12826==definitely lost: 0 bytes in 0 blocks ==12826==indirectly lost: 0 bytes in 0 blocks ==12826== possibly lost: 60 bytes in 1 blocks But as Steve pointed out: this is irrelevant, just a hint to the programmer.
[Bug fortran/104130] [12/13 Regression] ICE in gfc_add_class_array_ref, at fortran/class.c:274 since r12-4467-g64f9623765da3306
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104130 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Andre Vehreschild from comment #7) > ifort/ifx (2024.1.2) accepts the code. Well, Intel rejects a bare call s(z) so it should also reject call s(transpose(z)) for multiple reasons. Intel still has a couple of issues with unlimited polymorphism. > My fortran is not very good, but I would expect either a select around the > call to `s` or needing `x` to be of `class(*)`. The latter is what the > changed example errors with: Right. A correct version would be: program p class(*), pointer :: z(:,:) select type (z) type is (integer) call s(z) call s(transpose(z)) end select contains subroutine s(x) bind(c) integer, contiguous :: x(:,:) end end This is happily accepted by all gfortran >= 12. Updating keywords from ice-on-valid-code to ice-on-invalid-code.
[Bug fortran/114019] allocation with source of deferred character length entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114019
--- Comment #2 from anlauf at gcc dot gnu.org ---
The following - seemingly hackish - change fixes the ICE:
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 93b633e212e..60275e18867 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6464,7 +6464,10 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist
*omp_allocate)
else if (se.expr != NULL_TREE && temp_var_needed)
{
tree var, desc;
- tmp = GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se.expr)) || is_coarray ?
+ tmp = (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se.expr))
+|| is_coarray
+|| (code->expr3->ts.type == BT_CHARACTER
+&& code->expr3->rank == 0)) ?
se.expr
: build_fold_indirect_ref_loc (input_location, se.expr);
For reasons I do not see the case of source being a scalar character
expression, where we already have created se as a reference a few lines
further up in the code, is not handled by the original code.
This regtests cleanly.
Is there a better solution?
[Bug fortran/55978] class_optional_2.f90 -Os fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #33 from anlauf at gcc dot gnu.org ---
I've been repeatedly struggling with the testcase in comment#19.
Since the dump-tree did not reveal anything, I ran a reduced version
under gdb to see why the code crashes at -O0 and -Og but not at higher
optimization. I got them impression that the dump-tree does not tell
the full truth: subroutine one has
{
struct array01_integer(kind=4) * D.4292;
D.4292 = x != 0B ? (struct array01_integer(kind=4) *)
_gfortran_internal_pack (x) : 0B;
two (D.4292);
if (x != 0B && (integer(kind=4)[0:] *) x->data != (integer(kind=4)[0:] *)
D.4292)
{
_gfortran_internal_unpack (x, D.4292);
__builtin_free ((void *) D.4292);
}
}
but to my untrained eye it looked like the test x->data != D.4292 was
executed before x != 0B. This lead me to the following tentative patch:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 19d69aec9c0..06bfea1f461 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -9025,7 +9100,7 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr * expr,
bool g77,
fold_convert (TREE_TYPE (tmp), ptr), tmp);
if (fsym && fsym->attr.optional && sym && sym->attr.optional)
- tmp = fold_build2_loc (input_location, TRUTH_AND_EXPR,
+ tmp = fold_build2_loc (input_location, TRUTH_ANDIF_EXPR,
logical_type_node,
gfc_conv_expr_present (sym), tmp);
Strangely enough, this gives exactly the same dump-tree!
(If someone knows why, please enlighten me!)
But it fixed the issue.
The I looked at the optimized tree. The reference version has:
[local count: 1073741824]:
# _5 = PHI <_19(3), y_17(D)(2)>
two (_5);
_1 = y_17(D) != 0B;
_2 = y_17(D)->data;
_3 = _2 != _5;
_4 = _1 & _3;
if (_4 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 354334800]:
__builtin_free (_5);
This explains the "boom".
The version with the ANDIF has:
[local count: 1073741824]:
# _2 = PHI <_16(3), y_14(D)(2)>
two (_2);
if (y_14(D) != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751619280]:
_1 = y_14(D)->data;
if (_1 != _2)
goto ; [53.47%]
else
goto ; [46.53%]
[local count: 401890828]:
__builtin_free (_2);
This looks sane to me: the data component is not referenced if the dummy
is seen to be absent.
Regtesting...
[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.4 Status|NEW |RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 115390, which changed state. Bug 115390 Summary: Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-June/060591.html
[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 58455
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58455&action=edit
Patch
The attached patch fixes the ordering such that the bogus warning does no
longer appear and gives for the reduced test:
__attribute__((fn spec (". r ")))
void bar (struct CFI_cdesc_t00 & restrict _s)
{
integer(kind=8) s.0;
character(kind=1)[1:s.0] * s;
bitsizetype D.4279;
sizetype D.4280;
s.0 = (integer(kind=8)) _s->elem_len;
D.4279 = (bitsizetype) (sizetype) NON_LVALUE_EXPR * 8;
D.4280 = (sizetype) NON_LVALUE_EXPR ;
s = (character(kind=1)[1:s.0] *) _s->base_addr;
foo ((character(kind=1)[1:s.0] *) s, s.0);
}
Currently regtesting ...
[Bug fortran/115401] valgrind error in gfc_class_len_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115401 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-06-09 Ever confirmed|0 |1 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Reduced testcase which ICEs here: module m implicit none type :: t1 integer :: a end type contains function copy(a) result(ty) class(t1), allocatable :: ty(:) integer, intent(in) :: a allocate(t1::ty(a)) ty%a = 1 end function subroutine test() ! class(t1), allocatable :: up(:) ! OK class(*), allocatable :: up(:) ! ICE allocate(up(10), source=copy(10)) end subroutine end module
[Bug fortran/115348] [13/14/15 Regression] -fcheck=recursion issue with intent(out) derived type argument without components with default value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115348 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail||15.0 Priority|P3 |P4 Summary|-fcheck=recursion issue |[13/14/15 Regression] |with intent(out) derived|-fcheck=recursion issue |type argument without |with intent(out) derived |components with default |type argument without |value |components with default ||value Ever confirmed|0 |1 Last reconfirmed||2024-06-08 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. Workarounds: - add "recursive" attribute to subroutine myroutine - add a default initialization to component mynumber Might be related to pr115070.
[Bug fortran/107141] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to David Binderman from comment #5) > Bit more detail from valgrind: > > /Lower/derived-type-finalization.f90 > ==687074== Invalid read of size 8 > ==687074==at 0x856D97: gfc_class_len_get(tree_node*) (trans-expr.cc:273) > ==687074==by 0x86F37B: trans_class_vptr_len_assignment(stmtblock_t*, > gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) > (trans-expr.cc:10169) Judging from the name of the testcase this could be a quite different issue. Please open a separate PR and attach the source there.
[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390
--- Comment #2 from anlauf at gcc dot gnu.org ---
Slightly rewritten (we only need the interface of foo):
module test
implicit none
interface
subroutine foo(s)
character(*), intent(in) :: s
end subroutine foo
end interface
contains
subroutine bar(s) bind(c)
character(*), intent(in) :: s
call foo(s)
end
end
This gives:
__attribute__((fn spec (". r ")))
void bar (struct CFI_cdesc_t00 & restrict _s)
{
integer(kind=8) s.0;
character(kind=1)[1:s.0] * s;
bitsizetype D.4279;
sizetype D.4280;
D.4279 = (bitsizetype) (sizetype) NON_LVALUE_EXPR * 8;
D.4280 = (sizetype) NON_LVALUE_EXPR ;
s.0 = (integer(kind=8)) _s->elem_len;
s = (character(kind=1)[1:s.0] *) _s->base_addr;
foo ((character(kind=1)[1:s.0] *) s, s.0);
}
