public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/108921] New: ICE: using the result of an impure function in automatic character allocation
@ 2023-02-24 10:43 vterzi1996 at gmail dot com
  2023-02-24 17:36 ` [Bug fortran/108921] " kargl at gcc dot gnu.org
  0 siblings, 1 reply; 2+ messages in thread
From: vterzi1996 at gmail dot com @ 2023-02-24 10:43 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 108921
           Summary: ICE: using the result of an impure function in
                    automatic character allocation
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vterzi1996 at gmail dot com
  Target Milestone: ---

Created attachment 54527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54527&action=edit
Complete backtrace

Consider the following minimal working example:
```
module lib
    type t
    contains
        procedure::f,g
    end type
contains
    integer function f(this)
        class(t),intent(in)::this
        f=10
    end
    function g(this)result(r)
        class(t),intent(in)::this
        character(len=this%f())::r  ! problem appears here
        r='42'
    end
end

program prog
    use lib
    type(t)::o
    print*,o%g()
end
```

This example was already discussed here:
https://stackoverflow.com/questions/75544072/using-function-result-as-character-length-in-fortran

The compilation of this code with the GNU compiler (gfortran 12.2.0 on Rocky
Linux 8.7) fails with the message `f951: internal compiler error: Segmentation
fault` (full output is in the attachment). It also fails with 7.5.0, 9.4.0, and
11.1.0 on Ubuntu 18.04.2 LTS. The reason for this problem is the unallowed
usage of the result of an impure function (here: `f`) in the automatic
allocation of the CHARACTER variable, but the compiler fails to identify the
mistake in the code.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug fortran/108921] ICE: using the result of an impure function in automatic character allocation
  2023-02-24 10:43 [Bug fortran/108921] New: ICE: using the result of an impure function in automatic character allocation vterzi1996 at gmail dot com
@ 2023-02-24 17:36 ` kargl at gcc dot gnu.org
  0 siblings, 0 replies; 2+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-02-24 17:36 UTC (permalink / raw)
  To: gcc-bugs

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
           Keywords|                            |ice-on-invalid-code
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
The ever popular NULL pointer dereference from
parsing invalid code.
With this patch

diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index ae653e74437..9ece4482f76 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -2491,7 +2491,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
                  /* This is elemental so that arrays are automatically
                     treated correctly by the scalarizer.  */
                  copy->attr.elemental = 1;
-                 if (ns->proc_name->attr.flavor == FL_MODULE)
+                 if (ns->proc_name && ns->proc_name->attr.flavor == FL_MODULE)
                    copy->module = ns->proc_name->name;
                  gfc_set_sym_referenced (copy);
                  /* Set up formal arguments.  */
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 2ce0f3e4df7..54c9441d7fd 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -2499,7 +2499,7 @@ gfc_find_component (gfc_symbol *sym, const char *name,
   if (sym->attr.flavor == FL_DERIVED)
     sym = gfc_use_derived (sym);
   else
-    gcc_assert (gfc_fl_struct (sym->attr.flavor));
+    return NULL;

   if (sym == NULL)
     return NULL;

I get 
% gfcx -c a.f90
a.f90:13:34:

   13 |         character(len=this%f())::r  ! problem appears here
      |                                  1
Error: Symbol 'r' at (1) already has basic type of REAL
a.f90:13:22:

   13 |         character(len=this%f())::r  ! problem appears here
      |                      1
Error: Function 'this' at (1) must be PURE
a.f90:14:10:

   14 |         r='42'
      |          1
Error: Cannot convert CHARACTER(2) to REAL(4) at (1)
a.f90:19:9:

   19 |     use lib
      |         1
Fatal Error: Cannot open module file 'lib.mod' for reading at (1): No such file
or directory
compilation terminated.

The first and last errors appear to be run on errors.  The second error appears
to be the relevant one, but the 'name' of the function is munged.

Anywhoo, the patch fixes the ICE

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-02-24 17:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-24 10:43 [Bug fortran/108921] New: ICE: using the result of an impure function in automatic character allocation vterzi1996 at gmail dot com
2023-02-24 17:36 ` [Bug fortran/108921] " kargl at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).