[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #25 from Steve Kargl --- On Mon, Nov 06, 2023 at 03:34:42PM +, trnka at scm dot com wrote: > > If expr->where is pointing to NULL, then something is definitely not > > set up correctly or your code is now going through a different code > > path in the compiler. > > Sorry for the delay with testing this, I was busy with other more pressing > tasks. No problem. I have very limited time to look at gfortran bugs and yours caught my eye. > It's not that expr->where would be NULL completely, but its components (nextc > and lb) are both NULL. Sorry about that. I did mean to say the components not just expr->where. In any event, the locus is clearly not correct. > > If this is related to setting up the artificial __final_* procedure, > > then it might be missing properly setting the locus. This patch > > simply sets the locus of the artificial procedure and its arguments > > to that of the derived symbol. This might prevent the ICE, but > > lead to a bogus error message. Can you test this? > > Tested, does not change a thing. The error does not seem to directly have > anything to do with the __final_*, but with building the __vtab_* using a > structure constructor, which is likely happening at a different place as > a side effect of Paul's finalization improvements. Bummer. I was hoping that it would give a better pointer to where gfortran needs to handle the locus. > As this seems to be a different (although possibly related) issue, > I have created PR112407 for further follow-up and posted my new > observations in there. I saw the new PR. Thanks for the in depth analysis. In setting up the constructor for a __vtab_* (an internal symbol), we likely need to ensure the locus is properly set in each list member.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #24 from Tomáš Trnka --- (In reply to Steve Kargl from comment #23) > If expr->where is pointing to NULL, then something is definitely not > set up correctly or your code is now going through a different code > path in the compiler. Sorry for the delay with testing this, I was busy with other more pressing tasks. It's not that expr->where would be NULL completely, but its components (nextc and lb) are both NULL. > If this is related to setting up the artificial __final_* procedure, > then it might be missing properly setting the locus. This patch > simply sets the locus of the artificial procedure and its arguments > to that of the derived symbol. This might prevent the ICE, but > lead to a bogus error message. Can you test this? Tested, does not change a thing. The error does not seem to directly have anything to do with the __final_*, but with building the __vtab_* using a structure constructor, which is likely happening at a different place as a side effect of Paul's finalization improvements. As this seems to be a different (although possibly related) issue, I have created PR112407 for further follow-up and posted my new observations in there.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #23 from Steve Kargl ---
On Wed, Aug 09, 2023 at 04:19:52PM +, trnka at scm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
>
> --- Comment #22 from Tomáš Trnka ---
> (In reply to Steve Kargl from comment #21)
> > I missed your comment #7 as simply grabbed the "slightly
> > more simplified" attachment and started a bug hunt from there.
> > Do either of the other testcase attachments exhibit the issue?
>
> Unfortunately, none of the testcases attached to this bug happen to trigger
> that particular issue. It seems to pop up in many different modules in our
> codebase, but they are all modules with quite complicated dependency trees, so
> isolating a small testcase from them is not straigtforward (I need to start
> from several tens of thousands of SLOC worth of stuff and manually try to
> reduce it from there, which is tedious at best).
>
> That's why I was hoping one of you GCC devs might have an idea of what could
> possibly be wrong (and some suggestions on what to look at in the gfortran
> internals or which pieces of code to start playing with).
>
> The bad part is that what should just be a warning ends up bringing the
> compiler down because it hits an assert in the diagnostic printing code. Does
> expr->where being completely blank sound suspicious? Perhaps something to do
> with the artificially generated code?
If expr->where is pointing to NULL, then something is definitely not
set up correctly or your code is now going through a different code
path in the compiler. Normally, if the locus can be NULL, one has
something like
if (!expr->where)
gcc_error ("Use last known locus --> %C");
else
gcc_error ("Use expr->where locus--> %L", >where);
You're clearly not getting this.
If this is related to setting up the artificial __final_* procedure,
then it might be missing properly setting the locus. This patch
simply sets the locus of the artificial procedure and its arguments
to that of the derived symbol. This might prevent the ICE, but
lead to a bogus error message. Can you test this?
diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index 9d0c802b867..ee591793c19 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -1739,6 +1739,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
name = xasprintf ("__final_%s", tname);
gfc_get_symbol (name, sub_ns, );
sub_ns->proc_name = final;
+ final->declared_at = derived->declared_at;
final->attr.flavor = FL_PROCEDURE;
final->attr.function = 1;
final->attr.pure = 0;
@@ -1756,6 +1757,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
/* Set up formal argument. */
gfc_get_symbol ("array", sub_ns, );
+ array->declared_at = derived->declared_at;
array->ts.type = BT_DERIVED;
array->ts.u.derived = derived;
array->attr.flavor = FL_VARIABLE;
@@ -1774,6 +1776,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
/* Set up formal argument. */
gfc_get_symbol ("byte_stride", sub_ns, _stride);
+ byte_stride->declared_at = derived->declared_at;
byte_stride->ts.type = BT_INTEGER;
byte_stride->ts.kind = gfc_index_integer_kind;
byte_stride->attr.flavor = FL_VARIABLE;
@@ -1787,6 +1790,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
/* Set up formal argument. */
gfc_get_symbol ("fini_coarray", sub_ns, _coarray);
+ fini_coarray->declared_at = derived->declared_at;
fini_coarray->ts.type = BT_LOGICAL;
fini_coarray->ts.kind = 1;
fini_coarray->attr.flavor = FL_VARIABLE;
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #22 from Tomáš Trnka --- (In reply to Steve Kargl from comment #21) > I missed your comment #7 as simply grabbed the "slightly > more simplified" attachment and started a bug hunt from there. > Do either of the other testcase attachments exhibit the issue? Unfortunately, none of the testcases attached to this bug happen to trigger that particular issue. It seems to pop up in many different modules in our codebase, but they are all modules with quite complicated dependency trees, so isolating a small testcase from them is not straigtforward (I need to start from several tens of thousands of SLOC worth of stuff and manually try to reduce it from there, which is tedious at best). That's why I was hoping one of you GCC devs might have an idea of what could possibly be wrong (and some suggestions on what to look at in the gfortran internals or which pieces of code to start playing with). The bad part is that what should just be a warning ends up bringing the compiler down because it hits an assert in the diagnostic printing code. Does expr->where being completely blank sound suspicious? Perhaps something to do with the artificially generated code? The warning is triggered by defined assignment routines, not (directly) by the finalizer. However, it does not occur on GCC 12 or on GCC 13 with the change in comment 4 reverted. It is thus either a preexisting bug uncovered by the fix for this bug or a new one caused by the fix, dunno. That's why I haven't posted it as a separate issue (yet), should I?
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #21 from Steve Kargl ---
On Wed, Aug 09, 2023 at 10:08:45AM +, trnka at scm dot com wrote:
>
> --- Comment #17 from Tomáš Trnka ---
> (In reply to kargl from comment #10)
> > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > index 3cd470ddcca..b0bb8bc1471 100644
> > --- a/gcc/fortran/resolve.cc
> > +++ b/gcc/fortran/resolve.cc
> > @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
> >
> >for (n = ns->contained; n; n = n->sibling)
> > {
> > - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> > + if (gfc_pure (ns->proc_name)
> > + && !gfc_pure (n->proc_name)
> > + && !n->proc_name->attr.artificial)
> > gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
> >"also be PURE", n->proc_name->name,
> >>proc_name->declared_at);
> >
> > pault, dos the above look correct?
>
> On our codebase, this patch behaves just like the patch in comment #5, in that
> it also triggers the issue described in comment #7 (assert in a warning about
> non-recursive procedures getting called recursively).
>
> Does either of you have any idea as to what that issue could be about? Or is
> isolating a testcase our only hope?
I missed your comment #7 as simply grabbed the "slightly
more simplified" attachment and started a bug hunt from there.
Do either of the other testcase attachments exhibit the issue?
The code in class.cc(generate_finalization_wrapper) sets
final->attr.pure = 0;
final->attr.recursive = 1;
final->attr.artificial = 1;
for the artificial __final_* wrapper function. So, the routine
should be recursive.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Paul Thomas --- Fixed on 13-branch and trunk. Thanks for the report Paul
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #19 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:ed049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 commit r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 Author: Paul Thomas Date: Wed Aug 9 15:53:40 2023 +0100 Fortran: Allow pure final procs contained in pure proc. [PR109684] 2023-08-09 Steve Kargl gcc/fortran PR fortran/109684 * resolve.cc (resolve_types): Exclude contained procedures with the artificial attribute from test for pureness.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #18 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:b8ec3c952324f866f191883473922e250be81341 commit r14-3098-gb8ec3c952324f866f191883473922e250be81341 Author: Paul Thomas Date: Wed Aug 9 12:04:09 2023 +0100 Fortran: Allow pure final procs contained in pure proc. [PR109684] 2023-08-09 Steve Kargl gcc/fortran PR fortran/109684 * resolve.cc (resolve_types): Exclude contained procedures with the artificial attribute from test for pureness.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #17 from Tomáš Trnka ---
(In reply to kargl from comment #10)
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 3cd470ddcca..b0bb8bc1471 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
>
>for (n = ns->contained; n; n = n->sibling)
> {
> - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> + if (gfc_pure (ns->proc_name)
> + && !gfc_pure (n->proc_name)
> + && !n->proc_name->attr.artificial)
> gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
> "also be PURE", n->proc_name->name,
> >proc_name->declared_at);
>
> pault, dos the above look correct?
On our codebase, this patch behaves just like the patch in comment #5, in that
it also triggers the issue described in comment #7 (assert in a warning about
non-recursive procedures getting called recursively).
Does either of you have any idea as to what that issue could be about? Or is
isolating a testcase our only hope?
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #16 from Paul Thomas --- > > I am wondering about the pureness test itself, however. Surely, the test > should be for impure procedures that are referenced and not just accessible? > > Paul Cancel that comment - it's nonsense! Paul
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #15 from Paul Thomas ---
(In reply to kargl from comment #14)
> (In reply to Paul Thomas from comment #13)
> > (In reply to Steve Kargl from comment #12)
> > > On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote:
> > > >
> > > > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > > > index 3cd470ddcca..b0bb8bc1471 100644
> > > > --- a/gcc/fortran/resolve.cc
> > > > +++ b/gcc/fortran/resolve.cc
> > > > @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
> > > >
> > > >for (n = ns->contained; n; n = n->sibling)
> > > > {
> > > > - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> > > > + if (gfc_pure (ns->proc_name)
> > > > + && !gfc_pure (n->proc_name)
> > > > + && !n->proc_name->attr.artificial)
> > > > gfc_error ("Contained procedure %qs at %L of a PURE procedure
> > > > must "
> > > >"also be PURE", n->proc_name->name,
> > > >>proc_name->declared_at);
> > > >
> > > > pault, dos the above look correct?
> > > >
> > >
> > > This patch passes a regression test with no new regressions
> > > on x86_64-*-*freebsd.
> >
> > Hi Steve,
> >
> > That will certainly fix the bug. An alternative crosses my mind, which is to
> > check the pureness of the final routines as the wrapper is being built and
> > give the wrapper the pure attribute if they are all pure.
> >
>
> Just saw that you attached a patch on 5/23/23 that it essentially the same
> as I suggested. I tried to simply set the final->attr.pure to 1, but this
> ran into issues with the argument list having intent(inout) instead of just
> intent(in).
Having looked at it, I have concluded that the simple fix is the right one for
the time being.
I am wondering about the pureness test itself, however. Surely, the test should
be for impure procedures that are referenced and not just accessible?
Paul
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #14 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #13)
> (In reply to Steve Kargl from comment #12)
> > On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote:
> > >
> > > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > > index 3cd470ddcca..b0bb8bc1471 100644
> > > --- a/gcc/fortran/resolve.cc
> > > +++ b/gcc/fortran/resolve.cc
> > > @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
> > >
> > >for (n = ns->contained; n; n = n->sibling)
> > > {
> > > - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> > > + if (gfc_pure (ns->proc_name)
> > > + && !gfc_pure (n->proc_name)
> > > + && !n->proc_name->attr.artificial)
> > > gfc_error ("Contained procedure %qs at %L of a PURE procedure
> > > must "
> > >"also be PURE", n->proc_name->name,
> > >>proc_name->declared_at);
> > >
> > > pault, dos the above look correct?
> > >
> >
> > This patch passes a regression test with no new regressions
> > on x86_64-*-*freebsd.
>
> Hi Steve,
>
> That will certainly fix the bug. An alternative crosses my mind, which is to
> check the pureness of the final routines as the wrapper is being built and
> give the wrapper the pure attribute if they are all pure.
>
Just saw that you attached a patch on 5/23/23 that it essentially the same as I
suggested. I tried to simply set the final->attr.pure to 1, but this ran into
issues with the argument list having intent(inout) instead of just intent(in).
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #13 from Paul Thomas ---
(In reply to Steve Kargl from comment #12)
> On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote:
> >
> > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > index 3cd470ddcca..b0bb8bc1471 100644
> > --- a/gcc/fortran/resolve.cc
> > +++ b/gcc/fortran/resolve.cc
> > @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
> >
> >for (n = ns->contained; n; n = n->sibling)
> > {
> > - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> > + if (gfc_pure (ns->proc_name)
> > + && !gfc_pure (n->proc_name)
> > + && !n->proc_name->attr.artificial)
> > gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
> >"also be PURE", n->proc_name->name,
> >>proc_name->declared_at);
> >
> > pault, dos the above look correct?
> >
>
> This patch passes a regression test with no new regressions
> on x86_64-*-*freebsd.
Hi Steve,
That will certainly fix the bug. An alternative crosses my mind, which is to
check the pureness of the final routines as the wrapper is being built and give
the wrapper the pure attribute if they are all pure.
Cheers
Paul
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #12 from Steve Kargl ---
On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote:
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 3cd470ddcca..b0bb8bc1471 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
>
>for (n = ns->contained; n; n = n->sibling)
> {
> - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> + if (gfc_pure (ns->proc_name)
> + && !gfc_pure (n->proc_name)
> + && !n->proc_name->attr.artificial)
> gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
>"also be PURE", n->proc_name->name,
>>proc_name->declared_at);
>
> pault, dos the above look correct?
>
This patch passes a regression test with no new regressions
on x86_64-*-*freebsd.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #11 from Steve Kargl --- On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote: > > Note final->attr.pure = 0 seems to contradict C1595 while constructing > the wrapper. I'm not too familiar with this portion of gfortran's > internals. Either the attribute should be set to 1 or the error > message can be suppressed through inspection of final->attr.artificial. > Whoops, I thought I included C1595 Any procedure referenced in a pure subprogram, including oner referenced via a defined operation, defined assignment, defined input/output, or finalization, shall be pure.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Neil Carlson from comment #9)
> Bug is still present in 13.2.0.
class.cc(generate_finalization_wrapper) contains the following
/* Set up the procedure symbol. */
name = xasprintf ("__final_%s", tname);
gfc_get_symbol (name, sub_ns, );
sub_ns->proc_name = final;
final->attr.flavor = FL_PROCEDURE;
final->attr.function = 1;
final->attr.pure = 0;
final->attr.recursive = 1;
final->result = final;
final->ts.type = BT_INTEGER;
final->ts.kind = 4;
final->attr.artificial = 1;
Note final->attr.pure = 0 seems to contradict C1595 while constructing
the wrapper. I'm not too familiar with this portion of gfortran's
internals. Either the attribute should be set to 1 or the error
message can be suppressed through inspection of final->attr.artificial.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 3cd470ddcca..b0bb8bc1471 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
for (n = ns->contained; n; n = n->sibling)
{
- if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
+ if (gfc_pure (ns->proc_name)
+ && !gfc_pure (n->proc_name)
+ && !n->proc_name->attr.artificial)
gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
"also be PURE", n->proc_name->name,
>proc_name->declared_at);
pault, dos the above look correct?
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #9 from Neil Carlson --- Bug is still present in 13.2.0.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #8 from Neil Carlson --- We've been bitten by what looks to be the same bug in our large Fortran code: 245 | end module kuprat_mapper_type | 1 Error: Contained procedure ‘__final_integer_set_type_wavl_Integer_set’ at (1) of a PURE procedure must also be PURE This one really had me baffled. The kuprat_mapper type has no component (or component of component) of the integer_set type, nor any pure procedures. At most, some procedure associated with the kuprat_mapper type has a local integer_set variable. In any event, the integer_set type does have a final procedure and it is pure! What's more baffling is why this error occurred at this point; the integer_set module compiled without error as did many other module files that use it. Note that the code compiles fine with the oneAPI ifort and NAG compilers (and also with gfortran 12.2 and earlier). I haven't attempted yet to try and pare things down to a reportable reproducer, but if it would help I could try to do so.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #7 from Tomáš Trnka --- (In reply to Paul Thomas from comment #5) > Created attachment 55144 [details] > Fix for this PR > > Thanks for reporting this. The patch "fingered" in comment #4 is certainly > responsible for this regression. In particular, it is the first chunk in > resolve.cc that is the culprit. > > The attached patch feels to be a bit of sticking plaster on top of sticking > plaster and so I will go back to hunt down the root cause of these > namespace-less symbols. Thanks for the patch. It seems to mostly do the trick for our huge proprietary F2008 codebase, but some files ultimately fail to compile with the following error (not sure if related or a different bug): in gfc_format_decoder, at fortran/error.cc:1078 0xb01b5a gfc_format_decoder ../../gcc/fortran/error.cc:1078 0x1594c0c pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.cc:1475 0x10f0c5e diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.cc:1592 0x1789c5d gfc_report_diagnostic ../../gcc/fortran/error.cc:890 0x1789c5d gfc_warning ../../gcc/fortran/error.cc:923 0x1789da7 gfc_warning(int, char const*, ...) ../../gcc/fortran/error.cc:954 0x1852c41 resolve_procedure_expression ../../gcc/fortran/resolve.cc:1957 0x1852c41 resolve_variable ../../gcc/fortran/resolve.cc:6030 0x1852c41 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7266 0x1806880 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7231 0x1806880 resolve_structure_cons ../../gcc/fortran/resolve.cc:1341 0x1858969 resolve_values ../../gcc/fortran/resolve.cc:12771 0x1869492 do_traverse_symtree ../../gcc/fortran/symbol.cc:4190 0x185b02f gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) ../../gcc/fortran/symbol.cc:4215 0x185b02f resolve_types ../../gcc/fortran/resolve.cc:17899 0x184cf93 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17996 0x184fb47 resolve_symbol ../../gcc/fortran/resolve.cc:16567 0x1869492 do_traverse_symtree ../../gcc/fortran/symbol.cc:4190 0x185aee0 gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) ../../gcc/fortran/symbol.cc:4215 0x185aee0 resolve_types ../../gcc/fortran/resolve.cc:17880 This seems to be the following assert: gcc_assert (loc->nextc - loc->lb->line >= 0); The backtrace I get from gdb is a little different (there's no resolve_structure_cons in it, for example; I guess that it might be due to LTO): #0 gfc_warning (opt=0, gmsgid=0x1e55748 "Non-RECURSIVE procedure %qs at %L is possibly calling itself recursively. Declare it RECURSIVE or use %<-frecursive%>") at ../../gcc/fortran/error.cc:950 #1 0x01852c42 in resolve_procedure_expression (expr=0x2aefc80) at ../../gcc/fortran/resolve.cc:1957 #2 resolve_variable (e=0x2aefc80) at ../../gcc/fortran/resolve.cc:6030 #3 gfc_resolve_expr (e=0x2aefc80) at ../../gcc/fortran/resolve.cc:7266 #4 0x01806881 in gfc_resolve_expr (e=0x2aefc80) at ../../gcc/fortran/resolve.cc:7231 #5 resolve_structure_cons (expr=, init=1) at ../../gcc/fortran/resolve.cc:1341 #6 0x0185896a in resolve_values (sym=0x2ad30c0) at ../../gcc/fortran/resolve.cc:12771 #7 0x01869493 in do_traverse_symtree (st=, st_func=0x0, sym_func=0x1858900 ) at ../../gcc/fortran/symbol.cc:4190 #8 0x0185b030 in gfc_traverse_ns (sym_func=0x1858900 , ns=0x3ae65e0) at ../../gcc/fortran/symbol.cc:4215 #9 resolve_types (ns=0x3ae65e0) at ../../gcc/fortran/resolve.cc:17899 #10 0x0184cf94 in gfc_resolve (ns=0x3ae65e0) at ../../gcc/fortran/resolve.cc:17996 #11 0x0184d022 in gfc_resolve (ns=) at ../../gcc/fortran/resolve.cc:17983 #12 0x0184fb48 in resolve_symbol (sym=) at ../../gcc/fortran/resolve.cc:16567 #13 0x01869493 in do_traverse_symtree (st=, st_func=0x0, sym_func=0x184d030 ) at ../../gcc/fortran/symbol.cc:4190 #14 0x0185aee1 in gfc_traverse_ns (sym_func=0x184d030 , ns=0x3697bb0) at ../../gcc/fortran/symbol.cc:4215 #15 resolve_types (ns=0x3697bb0) at ../../gcc/fortran/resolve.cc:17880 #16 0x0184cf94 in gfc_resolve (ns=0x3697bb0) at ../../gcc/fortran/resolve.cc:17996 #17 0x0184d022 in gfc_resolve (ns=) at ../../gcc/fortran/resolve.cc:17983 #18 0x0184fb48 in resolve_symbol (sym=) at ../../gcc/fortran/resolve.cc:16567 #19 0x01869493 in do_traverse_symtree (st=, st_func=0x0, sym_func=0x184d030 ) at ../../gcc/fortran/symbol.cc:4190 #20 0x0185aee1 in gfc_traverse_ns (sym_func=0x184d030 , ns=0x3238a50) at ../../gcc/fortran/symbol.cc:4215 #21 resolve_types (ns=0x3238a50) at ../../gcc/fortran/resolve.cc:17880 #22 0x0184cf94 in gfc_resolve (ns=0x3238a50) at ../../gcc/fortran/resolve.cc:17996 #23 0x0184d022 in gfc_resolve (ns=) at ../../gcc/fortran/resolve.cc:17983 #24 0x0184fb48 in
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #6 from Paul Thomas --- The trigger for this problem is not apparent to me at all. The chunk that I mentioned in comment #5 is not responsible for it. The finalization of 'grid' in 13.f90 is done by an invocation of the 'finalization wrapper', which is an artificial procedure generated in class.cc. It does the selection of the final procedure, depending on the rank, plus the finalization of parent types and finalizable components, as required by the standard. Apparently, no check was done for the pureness of the finalization_wrapper or for the final procedures that it invokes. For reasons that I don't understand, this is being done since my finalization patch, pinpointed in comment #4 (Thanks Tomas!). The constraint, F2018(C1594), is absolutely clear: "Any procedure referenced in a pure subprogram, including one referenced via a defined operation, defined assignment, defined input/output, or finalization, shall be pure." I guess that the best way to proceed then is to set the finalization wrapper pure if and only if all the final procedures are pure. I will test other brands to see what they do. Otherwise, I am warming to my patch, even though it ducks the check. Paul
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Last reconfirmed||2023-05-23 Ever confirmed|0 |1 --- Comment #5 from Paul Thomas --- Created attachment 55144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55144=edit Fix for this PR Thanks for reporting this. The patch "fingered" in comment #4 is certainly responsible for this regression. In particular, it is the first chunk in resolve.cc that is the culprit. The attached patch feels to be a bit of sticking plaster on top of sticking plaster and so I will go back to hunt down the root cause of these namespace-less symbols. I fear that you will have to make your procedures impure for the time being or, if you don't need the added finalization features, revert to a previous version of gfortran. Regards and apologies for the inconvenience. Paul
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #4 from Tomáš Trnka --- This is a regression in GCC 13, which bisects to the following commit. Reverting that commit on current releases/gcc-13 tip (together with dependent commits 259bd7686403 and 3e791f45ded8) makes the issue go away. d7caf313525a46f200d7f5db1ba893f853774aee is the first bad commit commit d7caf313525a46f200d7f5db1ba893f853774aee Author: Paul Thomas Date: Sat Mar 18 07:56:23 2023 + Fortran: Fix bugs and missing features in finalization [PR37336] 2023-03-18 Paul Thomas gcc/fortran PR fortran/103854 PR fortran/96122 PR fortran/37336 * class.cc (finalize_component): Include the missing arguments in the call to the component's finalizer wrapper. (has_finalizer_component): Do not return true for procedure pointer components. (finalizer_insert_packed_call): Remove the redundant argument in the call to the final subroutine. (generate_finalization_wrapper): Add support for assumed rank finalizers. (gfc_may_be_finalized): New helper function. * dump-parse-tree.cc (write_proc): Whitespace. * gfortran.h : Add prototype for gfc_may_be_finalized. * resolve.cc (resolve_function): Correct derived types that have an incomplete namespace. (resolve_where, gfc_resolve_where_code_in_forall, gfc_resolve_forall_body, gfc_resolve_code): Check that the op code is still EXEC_ASSIGN. If it is set lhs to must finalize. (is_finalizable_type): New function. (generate_component_assignments): Set must_finalize if needed. (gfc_resolve_finalizers): Error if assumed rank finalizer is not the only one. Warning on lack of scalar finalizer modified to account for assumed rank finalizers. (generate_final_call): New function. (generate_component_assignments): Enclose the outermost call in a block to capture automatic deallocation and final calls. Set must_finalize as required to satisfy the standards. Use an explicit pointer assignment for pointer components to capture finalization of the target. Likewise use explicit assignment for allocatable components. Do not use the temporary copy of the lhs in defined assignment if the component is allocatable. Put the temporary in the same namespace as the lhs symbol if the component may be finalized. Remove the leading assignment from the expansion of assignment of components that have their own defined assignment components. Suppress finalization of assignment of temporary components to the lhs. Make an explicit final call for the rhs function temporary if it exists. (gfc_resolve_code): Set must_finalize for assignments with an array constructor on the rhs. (gfc_resolve_finalizers): Ensure that an assumed rank finalizer is the only finalizer for that type and correct the surprising warning for the lack of a scalar finalizer. (check_defined_assignments): Handle allocatable components. (resolve_fl_derived): Set referenced the vtab for use associated symbols. (resolve_symbol): Set referenced an unreferenced symbol that will be finalized. * trans-array.cc (gfc_trans_array_constructor_value): Add code to finalize the constructor result. Warn that this feature was removed in F2018 and that it is suppressed by -std=2018. (trans_array_constructor): Add finalblock, pass to previous and apply to loop->post if filled. (gfc_add_loop_ss_code): Add se finalblock to outer loop post. (gfc_trans_array_cobounds, gfc_trans_array_bounds): Add any generated finalization code to the main block. (structure_alloc_comps): Add boolean argument to suppress finalization and use it for calls from gfc_deallocate_alloc_comp_no_caf. Otherwise it defaults to false. (gfc_copy_alloc_comp_no_fini): New wrapper for structure_alloc_comps. (gfc_alloc_allocatable_for_assignment): Suppress finalization by setting new arg in call to gfc_deallocate_alloc_comp_no_caf. (gfc_trans_deferred_array): Use gfc_may_be_finalized and do not deallocate the components of entities with a leading '_' in the name that are also marked as artificial. * trans-array.h : Add the new boolean argument to the prototype of gfc_deallocate_alloc_comp_no_caf with a default of false. Add prototype for gfc_copy_alloc_comp_no_fini.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #3 from Tomáš Trnka --- Created attachment 55134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55134=edit testcase reduced to three files This is the most reduced testcase I have found. It was created from the previous one by concatenating files 01 through 06 and dropping files 08 through 12. Again, compile with "gfortran -c *.f90" to reproduce. Concatenating any of these remaining three files together makes the bug disappear.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 Tomáš Trnka changed: What|Removed |Added CC||trnka at scm dot com --- Comment #2 from Tomáš Trnka --- Created attachment 55133 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55133=edit cmake-less equivalent of the original testcase Here are the same files from the original testcase sorted in the order that cmake uses to compile them. Simply running "gfortran -c *.f90" here performs the exact same sequence of compilation steps as the original cmake build, reproducing the issue.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 Mianzhi Wang changed: What|Removed |Added Attachment #54964|0 |1 is obsolete|| CC||wangmianzhi1 at linuxmail dot org --- Comment #1 from Mianzhi Wang --- Created attachment 55103 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55103=edit slightly more simplified build with cmake
