[Bug fortran/109684] New: compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

[Bug fortran/109684] New: compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

[wangmianzhi1 at linuxmail dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

            Bug ID: 109684
           Summary: compiling failure: complaining about a final
                    subroutine of a type being not PURE (while it is
                    indeed PURE)
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wangmianzhi1 at linuxmail dot org
  Target Milestone: ---

Created attachment 54964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54964&action=edit
build with cmake

This issue emerges after upgrading to Fedora 38 (gcc version 13.1.1 20230426)
from Fedora 37 (gcc 12.x series). There was no issue in Fedora 37.

The issue takes place when:
mkdir build; cd build; cmake ..; make

GCC would popup an error message like this:
/home/mianzhi/Desktop/final_subroutine_not_pure/src/test/basicFEM1.f90:3:0:

    3 | function basicFEM1() result(ierr)
      | 
Error: Contained procedure ‘__final_modotgrid_Otgrid’ at (1) of a PURE
procedure must also be PURE

The f90 file that actually contains the otGrid type with its final procedure
compiles fine. The basicFEM1.f90 uses module modFileIO, which has an interface
that involves type otGrid.

The attached is a stripped-down version of the code. I've tried to further
simplify the code but removing seemingly irrelevant things could prevent the
error from happening.

Thank you very much for your help.

Best regards,
Mianzhi

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

[wangmianzhi1 at linuxmail dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

Mianzhi Wang <wangmianzhi1 at linuxmail dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #54964|0                           |1
        is obsolete|                            |
                 CC|                            |wangmianzhi1 at linuxmail dot org

--- Comment #1 from Mianzhi Wang <wangmianzhi1 at linuxmail dot org> ---
Created attachment 55103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55103&action=edit
slightly more simplified

build with cmake

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

[trnka at scm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

Tomáš Trnka <trnka at scm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trnka at scm dot com

--- Comment #2 from Tomáš Trnka <trnka at scm dot com> ---
Created attachment 55133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55133&action=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)

[trnka at scm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #3 from Tomáš Trnka <trnka at scm dot com> ---
Created attachment 55134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55134&action=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)

[trnka at scm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #4 from Tomáš Trnka <trnka at scm dot com> ---
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 <pault@gcc.gnu.org>
Date:   Sat Mar 18 07:56:23 2023 +0000

    Fortran: Fix bugs and missing features in finalization [PR37336]

    2023-03-18  Paul Thomas  <pault@gcc.gnu.org>

    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.
            * trans-decl.cc(init_intent_out_dt): Tidy up the code.
            * trans-expr.cc (gfc_init_se): Initialize finalblock.
            (gfc_conv_procedure_call): Use gfc_finalize_tree_expr to
            finalize function results. Replace in-line block for class
            results with call to new function.
            (gfc_conv_expr): Finalize structure constructors for F2003 and
            F2008. Warn that this feature was deleted in F2018 and, unlike
            array constructors, is not default. Add array constructor
            finalblock to the post block.
            (gfc_trans_scalar_assign): Suppress finalization by setting new
            argument in call to gfc_deallocate_alloc_comp_no_caf. Add the
            finalization blocks to the main block.
            (gfc_trans_arrayfunc_assign): Use gfc_assignment_finalizer_call
            and ensure that finalization occurs after the evaluation of the
            rhs but using the initial value for the lhs. Finalize rhs
            function results using gfc_finalize_tree_expr.
            (trans_class_assignment, gfc_trans_assignment_1): As previous
            function, taking care to order evaluation, assignment and
            finalization correctly.
            * trans-io.cc (gfc_trans_transfer): Add the final block.
            * trans-stmt.cc (gfc_trans_call, gfc_trans_allocate): likewise.
            (trans_associate_var): Nullify derived allocatable components
            and finalize function targets with defined assignment
            components on leaving the block scope.
            (trans_allocate): Finalize source expressions, if required,
            and set init_expr artificial temporarily to suppress the
            finalization in gfc_trans_assignment.
            * trans.cc (gfc_add_finalizer_call): Do not finalize the
            temporaries generated in type assignment with defined
            assignment components.
            (gfc_assignment_finalizer_call): New function.
            (gfc_finalize_tree_expr): New function.
            * trans.h: Add finalblock to gfc_se. Add the prototypes for
            gfc_finalize_tree_expr and gfc_assignment_finalizer_call.

    gcc/testsuite/
            PR fortran/64290
            * gfortran.dg/finalize_38.f90 : New test.
            * gfortran.dg/finalize_38a.f90 : New test.
            * gfortran.dg/allocate_with_source_25.f90 : The number of final
            calls goes down from 6 to 4.
            * gfortran.dg/associate_25.f90 : Remove the incorrect comment.
            * gfortran.dg/auto_dealloc_2.f90 : Change the tree dump expr
            but the final count remains the same.
            * gfortran.dg/unlimited_polymorphic_8.f90 : Tree dump reveals
            foo.1.x rather than foo.0.x

            PR fortran/67444
            * gfortran.dg/finalize_39.f90 : New test.

            PR fortran/67471
            * gfortran.dg/finalize_40.f90 : New test.

            PR fortran/69298
            PR fortran/70863
            * gfortran.dg/finalize_41.f90 : New test.

            PR fortran/71798
            * gfortran.dg/finalize_42.f90 : New test.

            PR fortran/80524
            * gfortran.dg/finalize_43.f90 : New test.

            PR fortran/82996
            * gfortran.dg/finalize_44.f90 : New test.

            PR fortran/84472
            * gfortran.dg/finalize_45.f90 : New test.

            PR fortran/88735
            PR fortran/93691
            * gfortran.dg/finalize_46.f90 : New test.

            PR fortran/91316
            * gfortran.dg/finalize_47.f90 : New test.

            PR fortran/106576
            * gfortran.dg/finalize_48.f90 : New test.

            PR fortran/37336
            * gfortran.dg/finalize_49.f90 : New test.
            * gfortran.dg/finalize_50.f90 : New test.
            * gfortran.dg/finalize_51.f90 : New test.

 gcc/fortran/class.cc                               |  81 ++++-
 gcc/fortran/dump-parse-tree.cc                     |   2 +-
 gcc/fortran/gfortran.h                             |   1 +
 gcc/fortran/resolve.cc                             | 351 +++++++++++++++++----
 gcc/fortran/trans-array.cc                         | 234 +++++++++-----
 gcc/fortran/trans-array.h                          |   5 +-
 gcc/fortran/trans-decl.cc                          |  44 ++-
 gcc/fortran/trans-expr.cc                          | 259 ++++++++++-----
 gcc/fortran/trans-io.cc                            |   1 +
 gcc/fortran/trans-stmt.cc                          |  50 ++-
 gcc/fortran/trans.cc                               | 281 ++++++++++++++++-
 gcc/fortran/trans.h                                |   8 +-
 .../gfortran.dg/allocate_with_source_25.f90        |   2 +-
 gcc/testsuite/gfortran.dg/associate_25.f90         |   4 +-
 gcc/testsuite/gfortran.dg/auto_dealloc_2.f90       |   4 +-
 gcc/testsuite/gfortran.dg/finalize_38.f90          | 222 +++++++++++++
 gcc/testsuite/gfortran.dg/finalize_38a.f90         | 240 ++++++++++++++
 gcc/testsuite/gfortran.dg/finalize_39.f90          |  71 +++++
 gcc/testsuite/gfortran.dg/finalize_40.f90          |  44 +++
 gcc/testsuite/gfortran.dg/finalize_41.f90          | 139 ++++++++
 gcc/testsuite/gfortran.dg/finalize_42.f90          |  53 ++++
 gcc/testsuite/gfortran.dg/finalize_43.f90          |  41 +++
 gcc/testsuite/gfortran.dg/finalize_44.f90          | 123 ++++++++
 gcc/testsuite/gfortran.dg/finalize_45.f90          | 132 ++++++++
 gcc/testsuite/gfortran.dg/finalize_46.f90          |  92 ++++++
 gcc/testsuite/gfortran.dg/finalize_47.f90          | 105 ++++++
 gcc/testsuite/gfortran.dg/finalize_48.f90          |  59 ++++
 gcc/testsuite/gfortran.dg/finalize_49.f90          |  67 ++++
 gcc/testsuite/gfortran.dg/finalize_50.f90          | 254 +++++++++++++++
 gcc/testsuite/gfortran.dg/finalize_51.f90          |  70 ++++
 .../gfortran.dg/unlimited_polymorphic_8.f90        |   4 +-
 31 files changed, 2800 insertions(+), 243 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_38.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_38a.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_39.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_40.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_41.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_42.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_43.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_44.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_45.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_46.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_47.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_48.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_49.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_50.f90
 create mode 100644 gcc/testsuite/gfortran.dg/finalize_51.f90

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

Paul Thomas <pault at gcc dot gnu.org> 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 <pault at gcc dot gnu.org> ---
Created attachment 55144
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55144&action=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)

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
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)

[trnka at scm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #7 from Tomáš Trnka <trnka at scm dot com> ---
(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  0x0000000001852c42 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  0x0000000001806881 in gfc_resolve_expr (e=0x2aefc80) at
../../gcc/fortran/resolve.cc:7231
#5  resolve_structure_cons (expr=<optimized out>, init=1) at
../../gcc/fortran/resolve.cc:1341
#6  0x000000000185896a in resolve_values (sym=0x2ad30c0) at
../../gcc/fortran/resolve.cc:12771
#7  0x0000000001869493 in do_traverse_symtree (st=<optimized out>, st_func=0x0,
sym_func=0x1858900 <resolve_values(gfc_symbol*)>)
    at ../../gcc/fortran/symbol.cc:4190
#8  0x000000000185b030 in gfc_traverse_ns (sym_func=0x1858900
<resolve_values(gfc_symbol*)>, ns=0x3ae65e0) at
../../gcc/fortran/symbol.cc:4215
#9  resolve_types (ns=0x3ae65e0) at ../../gcc/fortran/resolve.cc:17899
#10 0x000000000184cf94 in gfc_resolve (ns=0x3ae65e0) at
../../gcc/fortran/resolve.cc:17996
#11 0x000000000184d022 in gfc_resolve (ns=<optimized out>) at
../../gcc/fortran/resolve.cc:17983
#12 0x000000000184fb48 in resolve_symbol (sym=<optimized out>) at
../../gcc/fortran/resolve.cc:16567
#13 0x0000000001869493 in do_traverse_symtree (st=<optimized out>, st_func=0x0,
sym_func=0x184d030 <resolve_symbol(gfc_symbol*)>)
    at ../../gcc/fortran/symbol.cc:4190
#14 0x000000000185aee1 in gfc_traverse_ns (sym_func=0x184d030
<resolve_symbol(gfc_symbol*)>, ns=0x3697bb0) at
../../gcc/fortran/symbol.cc:4215
#15 resolve_types (ns=0x3697bb0) at ../../gcc/fortran/resolve.cc:17880
#16 0x000000000184cf94 in gfc_resolve (ns=0x3697bb0) at
../../gcc/fortran/resolve.cc:17996
#17 0x000000000184d022 in gfc_resolve (ns=<optimized out>) at
../../gcc/fortran/resolve.cc:17983
#18 0x000000000184fb48 in resolve_symbol (sym=<optimized out>) at
../../gcc/fortran/resolve.cc:16567
#19 0x0000000001869493 in do_traverse_symtree (st=<optimized out>, st_func=0x0,
sym_func=0x184d030 <resolve_symbol(gfc_symbol*)>)
    at ../../gcc/fortran/symbol.cc:4190
#20 0x000000000185aee1 in gfc_traverse_ns (sym_func=0x184d030
<resolve_symbol(gfc_symbol*)>, ns=0x3238a50) at
../../gcc/fortran/symbol.cc:4215
#21 resolve_types (ns=0x3238a50) at ../../gcc/fortran/resolve.cc:17880
#22 0x000000000184cf94 in gfc_resolve (ns=0x3238a50) at
../../gcc/fortran/resolve.cc:17996
#23 0x000000000184d022 in gfc_resolve (ns=<optimized out>) at
../../gcc/fortran/resolve.cc:17983
#24 0x000000000184fb48 in resolve_symbol (sym=<optimized out>) at
../../gcc/fortran/resolve.cc:16567
#25 0x0000000001869493 in do_traverse_symtree (st=<optimized out>, st_func=0x0,
sym_func=0x184d030 <resolve_symbol(gfc_symbol*)>)
    at ../../gcc/fortran/symbol.cc:4190
#26 0x000000000185aee1 in gfc_traverse_ns (sym_func=0x184d030
<resolve_symbol(gfc_symbol*)>, ns=0x2503410) at
../../gcc/fortran/symbol.cc:4215
#27 resolve_types (ns=0x2503410) at ../../gcc/fortran/resolve.cc:17880
#28 0x000000000185aff8 in resolve_types (ns=0x24fd1f0) at
../../gcc/fortran/resolve.cc:17892
#29 0x000000000184cf94 in gfc_resolve (ns=0x24fd1f0) at
../../gcc/fortran/resolve.cc:17996
#30 0x0000000001823689 in gfc_resolve (ns=<optimized out>) at
../../gcc/fortran/resolve.cc:17983
#31 gfc_parse_file () at ../../gcc/fortran/parse.cc:6861
#32 0x000000000187b705 in gfc_be_parse_file () at
../../gcc/fortran/f95-lang.cc:229
#33 0x00000000015b4582 in compile_file () at ../../gcc/toplev.cc:447
#34 0x0000000001592fc6 in do_compile (no_backend=false) at
../../gcc/toplev.cc:2128
#35 toplev::main (this=this@entry=0x7fffffffb82e, argc=<optimized out>,
argv=<optimized out>) at ../../gcc/toplev.cc:2282
#36 0x000000000159238f in main (argc=<optimized out>, argv=<optimized out>) at
../../gcc/main.cc:39
(gdb) up
#1  0x0000000001852c42 in resolve_procedure_expression (expr=0x2aefc80) at
../../gcc/fortran/resolve.cc:1957

The affected routine is a defined assignment in the ftlDynArray class, used in
this case to hold ordinary integers: 
https://github.com/SCM-NV/ftl/blob/master/src/ftlDynArray.F90_template

That defined assignment is impure elemental, if that matters.

(gdb) p *sym                                                                   
                                                                    $7 = {name
= 0x7fffea3fd9a0 "assignother", module = 0x7fffea3ec8d0 "ftldynarrayintmodule",
declared_at = {nextc = 0x24d0648, lb = 0x24d0600},         ts = {type =
BT_UNKNOWN, kind = 0, u = {derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0,
is_c_interop = 0, is_iso_c = 0,                           f90_type =
BT_UNKNOWN, deferred = false, interop_kind = 0x0}, attr = {allocatable = 0,
dimension = 0, codimension = 0, external = 0,                intrinsic = 0,
optional = 0, pointer = 0, target = 0, value = 0, volatile_ = 0, temporary = 0,
dummy = 0, result = 0, assign = 0,                   threadprivate = 0,
not_always_present = 0, implied_index = 0, subref_array_pointer = 0,
proc_pointer = 0, asynchronous = 0, contiguous = 0,         fe_temp = 0,
automatic = 0, class_pointer = 0, save = SAVE_NONE, data = 0, is_protected = 0,
use_assoc = 1, used_in_submodule = 0,                  use_only = 0, use_rename
= 0, imported = 0, host_assoc = 0, in_namelist = 0, in_common = 0,
in_equivalence = 0, function = 0, subroutine = 1,       procedure = 0, generic
= 0, generic_copy = 0, implicit_type = 0, untyped = 0, is_bind_c = 0, extension
= 0, is_class = 0, class_ok = 0,             vtab = 0, vtype = 0, is_c_interop
= 0, is_iso_c = 0, sequence = 0, elemental = 1, pure = 0, recursive = 0,
unmaskable = 0, masked = 0,              contained = 0, mod_proc = 0, abstract
= 0, module_procedure = 0, public_used = 0, implicit_pure = 0,
array_outer_dependency = 1, noreturn = 0,      entry = 0, entry_master = 0,
mixed_entry_master = 0, always_explicit = 1, artificial = 0, referenced = 0,
is_main_program = 0,                      access = ACCESS_UNKNOWN, intent =
INTENT_UNKNOWN, flavor = FL_PROCEDURE, if_source = IFSRC_DECL, proc =
PROC_MODULE, cray_pointer = 0,              cray_pointee = 0, alloc_comp = 0,
pointer_comp = 0, proc_pointer_comp = 0, private_comp = 0, zero_comp = 0,
coarray_comp = 0, lock_comp = 0,        event_comp = 0, defined_assign_comp =
0, unlimited_polymorphic = 0, has_dtio_procs = 0, caf_token = 0,
select_type_temporary = 0,                   select_rank_temporary = 0,
associate_var = 0, pdt_kind = 0, pdt_len = 0, pdt_type = 0, pdt_template = 0,
pdt_array = 0, pdt_string = 0,
    omp_udr_artificial_var = 0, omp_declare_target = 0, omp_declare_target_link
= 0, omp_device_type = OMP_DEVICE_TYPE_UNSET,
    oacc_declare_create = 0, oacc_declare_copyin = 0, oacc_declare_deviceptr =
0, oacc_declare_device_resident = 0, oacc_declare_link = 0,
    oacc_routine_lop = OACC_ROUTINE_LOP_NONE, oacc_routine_nohost = 0, ext_attr
= 0, volatile_ns = 0x0, asynchronous_ns = 0x0}, generic = 0x0,
  component_access = ACCESS_UNKNOWN, formal = 0x381f040, formal_ns = 0x3ae65e0,
f2k_derived = 0x0, param_list = 0x0, value = 0x0, as = 0x0,
  result = 0x0, components = 0x0, cp_pointer = 0x0, entry_id = 0, hash_value =
0, common_next = 0x0, common_head = 0x0, dummy_order = 0,
  namelist = 0x0, namelist_tail = 0x0, tlink = 0x0, old_symbol = 0x0, mark = 0,
comp_mark = 0, data_mark = 0, dev_mark = 0, gen_mark = 0,
  reduc_mark = 0, gfc_new = 0, equiv_built = 0, forall_index = 0,
fn_result_spec = 0, resolve_symbol_called = 1, abr_modproc_decl = 0, error = 0,
  maybe_array = 0, pass_as_value = 0, refs = 1, ns = 0x3697bb0, backend_decl =
0x0, from_intmod = INTMOD_NONE, intmod_sym_id = 0,
  binding_label = 0x0, common_block = 0x0, assoc = 0x0, dt_next = 0x0}

expr->where is full of zeros (so is *expr, mostly):

(gdb) p *expr
$9 = {expr_type = EXPR_VARIABLE, ts = {type = BT_PROCEDURE, kind = 0, u =
{derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0,
    is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false, interop_kind = 0x0},
rank = 0, shape = 0x0, symtree = 0x3fc73b0, ref = 0x0, where = {
    nextc = 0x0, lb = 0x0}, base_expr = 0x0, is_snan = 0, error = 0,
user_operator = 0, mold = 0, must_finalize = 0, no_bounds_check = 0,
  external_blas = 0, do_not_resolve_again = 0, do_not_warn = 0,
from_constructor = 0, representation = {length = 0, string = 0x0}, boz = {len =
0,
    rdx = 0, str = 0x0}, value = {logical = 0, iokind = M_READ, integer =
{{_mp_alloc = 0, _mp_size = 0, _mp_d = 0x0}}, real = {{_mpfr_prec = 0,
        _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}, complex = {{re =
{{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}, im = {{
            _mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}}},
op = {op = GFC_INTRINSIC_BEGIN, uop = 0x0, op1 = 0x0, op2 = 0x0},
    function = {actual = 0x0, name = 0x0, isym = 0x0, esym = 0x0}, compcall =
{actual = 0x0, name = 0x0, base_object = 0x0, tbp = 0x0,
      ignore_pass = 0, assign = 0}, character = {length = 0, string = 0x0},
constructor = 0x0}, param_list = 0x0}

This all happens when compiling one of our modules with lots of dependencies,
so I can't easily turn it into a standalone testcase. I could possibly just
send you the source together with all the .mod dependencies, but isolating it
further will take me a while (if needed).

Another defined assignment routine triggering the same warning/assert is even
weirder, since I can't imagine how this could end up calling itself
recursively:

   impure elemental subroutine AssignOther(self, other)
      class(InputType), intent(inout) :: self
       type(InputType), intent(in)    :: other

      ! TODO: Implement actual assignment. (Default assignment will not do the
right job, so we disable it for now.)
      call StopIt('Developer error: InputType is not assignable.')
      DontWarnUnused(self)
      DontWarnUnused(other)
   end subroutine

(StopIt is an external subroutine which just does some cleanup and stops the
program. This type does have a finalizer, but it certainly shouldn't trigger
the assignment again.)

   type :: InputType
(snip)
      final              :: Finalizer
      generic  , public  :: assignment(=) => AssignOther
      procedure, private :: AssignOther
   end type

   subroutine DeletePrivate(self)
      class(InputType), intent(inout) :: self

      self%quiet        = .false.
      self%stringLeafs  = .false.
      self%stopOnError  = .true.
      self%hasError     = .true.
      call self%errorMessage%Delete()

      call self%prog%Delete()
      call self%inputDef%Destroy()
      if (associated(self%pRoot)) call self%json%Destroy(self%pRoot)

   end subroutine
   !
   subroutine Finalizer(self)
      type(InputType), intent(inout) :: self
      call self%Delete()
   end subroutine

In the end I ended up having to compile everything -frecursive because this
issue pops up in many different modules and hunting them all down is really
tedious (having to extract the gfortran commandline out from our buildsystem,
get the corresponding f951 command line, run f951 under gdb to break on
gfc_warning, check *sym).

Compiling with this patch also makes PR103931 rear its ugly head in one module,
which does not happen when the offending commit in comment #4 is reverted
instead. But that PR is weird enough as it is, likely some minor changes in the
module file layout are all that's needed to trigger it.

> 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.

Well, our codebase uses F2008 features extensively, and defined assignments
plus finalization are by far the two most prominent sources of bugs in both
ifort and gfortran, so we already have layers upon layers of workarounds for
those in place. Any change to that mix is prone to break something else.

Your work on this in gfortran will likely allow us to get rid of quite some of
those workarounds, so it is greatly appreciated!

Indeed, running with gfortran 12 is certainly an option, but 13 with the revert
seems to do the job as well. We want to make our code compile with GCC 13
before that version is picked up by major distros and makes the life of our
developers miserable.

(I'm sure the whole world would be much better off if we could just include our
codebase in the regression test suites of both ifort and gfortran :-))

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #8 from Neil Carlson <neil.n.carlson at gmail dot com> ---
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)

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #9 from Neil Carlson <neil.n.carlson at gmail dot com> ---
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)

[kargl at gcc dot gnu.org]

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, &final);
  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,
                   &n->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)

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 07, 2023 at 10:04:54PM +0000, 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)

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 07, 2023 at 10:04:54PM +0000, 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,
>                    &n->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)

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #13 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Steve Kargl from comment #12)
> On Mon, Aug 07, 2023 at 10:04:54PM +0000, 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,
> >                    &n->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)

[kargl at gcc dot gnu.org]

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 +0000, 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,
> > >                    &n->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)

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #15 from Paul Thomas <pault at gcc dot gnu.org> ---
(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 +0000, 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,
> > > >                    &n->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)

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #16 from Paul Thomas <pault at gcc dot gnu.org> ---

> 
> 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)

[trnka at scm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #17 from Tomáš Trnka <trnka at scm dot com> ---
(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,
>  		   &n->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)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:b8ec3c952324f866f191883473922e250be81341

commit r14-3098-gb8ec3c952324f866f191883473922e250be81341
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Wed Aug 9 12:04:09 2023 +0100

    Fortran: Allow pure final procs contained in pure proc. [PR109684]

    2023-08-09  Steve Kargl  <sgk@troutmask.apl.washington.edu>

    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)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:ed049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7

commit r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Wed Aug 9 15:53:40 2023 +0100

    Fortran: Allow pure final procs contained in pure proc. [PR109684]

    2023-08-09  Steve Kargl  <sgk@troutmask.apl.washington.edu>

    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)

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #20 from Paul Thomas <pault at gcc dot gnu.org> ---
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)

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #21 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Aug 09, 2023 at 10:08:45AM +0000, trnka at scm dot com wrote:
> 
> --- Comment #17 from Tomáš Trnka <trnka at scm dot com> ---
> (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,
> >  		   &n->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)

[trnka at scm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #22 from Tomáš Trnka <trnka at scm dot com> ---
(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)

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #23 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Aug 09, 2023 at 04:19:52PM +0000, trnka at scm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
> 
> --- Comment #22 from Tomáš Trnka <trnka at scm dot com> ---
> (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", &expr->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, &final);
   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);
+  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, &byte_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, &fini_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)

[trnka at scm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #24 from Tomáš Trnka <trnka at scm dot com> ---
(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)

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684

--- Comment #25 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Nov 06, 2023 at 03:34:42PM +0000, 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.