[Bug fortran/95980] New: ICE in get_unique_type_string, at fortran/class.c:485

[Bug fortran/95980] New: ICE in get_unique_type_string, at fortran/class.c:485

[gscfq@t-online.de]

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

            Bug ID: 95980
           Summary: ICE in get_unique_type_string, at fortran/class.c:485
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Affects versions down to at least r5.
With a missing attribute allocatable or pointer :


$ cat z1.f90
program p
   type t
      integer :: a
   end type
   class(t) :: x
   select type (y => x)
   end select
end


$ gfortran-11-20200628 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbd215f crash_signal
        ../../gcc/toplev.c:328
0x63535a get_unique_type_string
        ../../gcc/fortran/class.c:485
0x635de1 get_unique_hashed_string
        ../../gcc/fortran/class.c:522
0x6392ce gfc_build_class_symbol(gfc_typespec*, symbol_attribute*,
gfc_array_spec**)
        ../../gcc/fortran/class.c:666
0x68f543 gfc_match_select_type()
        ../../gcc/fortran/match.c:6422
0x6ae2b4 match_word
        ../../gcc/fortran/parse.c:65
0x6ae2b4 decode_statement
        ../../gcc/fortran/parse.c:428
0x6afaea next_free
        ../../gcc/fortran/parse.c:1280
0x6afaea next_statement
        ../../gcc/fortran/parse.c:1512
0x6b113b parse_spec
        ../../gcc/fortran/parse.c:3923
0x6b3f0c parse_progunit
        ../../gcc/fortran/parse.c:5852
0x6b55e9 gfc_parse_file()
        ../../gcc/fortran/parse.c:6393
0x7016ff gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:212

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[gscfq@t-online.de]

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

G. Steinmetz <gscfq@t-online.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code

--- Comment #1 from G. Steinmetz <gscfq@t-online.de> ---


Related (and presumably also pr86551) :


$ cat z2.f90
program p
   type t
   end type
   class(t) :: x
   select type (y => x)
   end select
end


$ gfortran-11-20200628 -c z2.f90
f951: internal compiler error: Segmentation fault
0xbd215f crash_signal
        ../../gcc/toplev.c:328
0x686d9b copy_ts_from_selector_to_associate
        ../../gcc/fortran/match.c:6162
0x68f543 gfc_match_select_type()
        ../../gcc/fortran/match.c:6422
0x6ae2b4 match_word
        ../../gcc/fortran/parse.c:65
0x6ae2b4 decode_statement
        ../../gcc/fortran/parse.c:428
0x6afaea next_free
        ../../gcc/fortran/parse.c:1280
0x6afaea next_statement
        ../../gcc/fortran/parse.c:1512
0x6b113b parse_spec
        ../../gcc/fortran/parse.c:3923
0x6b3f0c parse_progunit
        ../../gcc/fortran/parse.c:5852
0x6b55e9 gfc_parse_file()
        ../../gcc/fortran/parse.c:6393
0x7016ff gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:212

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Priority|P3                          |P4

--- Comment #2 from kargl at gcc dot gnu.org ---
Patch is against svn r280156.

Index: gcc/fortran/match.c
===================================================================
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -6174,7 +6174,10 @@ build_class_sym:
     {
       /* The correct class container has to be available.  */
       assoc_sym->ts.type = BT_CLASS;
-      assoc_sym->ts.u.derived = CLASS_DATA (selector)->ts.u.derived;
+      if (CLASS_DATA (selector)->ts.u.derived != NULL)
+        assoc_sym->ts.u.derived = CLASS_DATA (selector)->ts.u.derived;
+      else
+        assoc_sym->ts.u.derived = selector->ts.u.derived;
       assoc_sym->attr.pointer = 1;
       gfc_build_class_symbol (&assoc_sym->ts, &assoc_sym->attr,
&assoc_sym->as);
     }

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-06-29

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-June/054648.html

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

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

commit r11-1855-gf2151227dfe90a5fe73297c370786be98b0b090f
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Mon Jul 6 18:58:23 2020 +0200

    PR fortran/95980 - ICE on using sync images with -fcheck=bounds

    In SELECT TYPE, the argument may be an incorrectly specified unlimited
    polymorphic variable.  Avoid a NULL pointer dereference for clean error
    recovery.

    gcc/fortran/
            PR fortran/95980
            * match.c (copy_ts_from_selector_to_associate, build_class_sym):
            Distinguish between unlimited polymorphic and ordinary variables
            to avoid NULL pointer dereference.
            * resolve.c (resolve_select_type):
            Distinguish between unlimited polymorphic and ordinary variables
            to avoid NULL pointer dereference.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

AFAICT the patch fixes the ICE for z2.f90, but not for z1.f90.

> Related (and presumably also pr86551) :

The patch seems to also fix the ICEs for pr86551.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Created attachment 48839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48839&action=edit
Patch, part 2

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[anlauf at gcc dot gnu.org]

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> AFAICT the patch fixes the ICE for z2.f90, but not for z1.f90.

You're right.  I got lost in trying to work on too many PRs.

I attached a brute-force patch that makes gfortran reject z1.f90
without ICEing.

Can you confirm this, or is there possibly something left to handle?
I have the impression that there's a lot of bad things happening with
invalid input that is not always caught on x86_64.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I attached a brute-force patch that makes gfortran reject z1.f90
> without ICEing.
>
> Can you confirm this, or is there possibly something left to handle?

Confirmed on preliminary tests (pr86551), full tests in progress: results
tomorrow).

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Jul 06, 2020 at 08:29:24PM +0000, anlauf at gcc dot gnu.org wrote:
> I have the impression that there's a lot of bad things happening with
> invalid input that is not always caught on x86_64.

This has been true since I started working on gfortran some
15+ years ago.  Much of the code is written assuming a correctly
written Fortran program.  Invalid input, particularly corner
cases and with newer features, tend to blow up.

Gerhard seems to delight in finding these issues. :-)

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Confirmed on preliminary tests (pr86551), full tests in progress: results tomorrow).

Regtested without regression.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #10)
> > Confirmed on preliminary tests (pr86551), full tests in progress: results tomorrow).
> 
> Regtested without regression.

Thanks for confirming.

That was on Darwin, right?

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[anlauf at gcc dot gnu.org]

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #9)
> This has been true since I started working on gfortran some
> 15+ years ago.  Much of the code is written assuming a correctly
> written Fortran program.  Invalid input, particularly corner
> cases and with newer features, tend to blow up.
> 
> Gerhard seems to delight in finding these issues. :-)

You know what happened with the internet?

In the beginning it was full of friendly people, and real programmers
wrote fine Fortran programs.

Then the internet changed.  And Gerhard has become the Fortran equivalent... 
;-)

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Tests finished, the patch fixes both pr86551 and pr95980, but not more AFAICT.

> That was on Darwin, right?

Yes

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[gscfq@t-online.de]

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

--- Comment #14 from G. Steinmetz <gscfq@t-online.de> ---

> ... and real programmers wrote fine Fortran programs.
Yeah, optimal world. That's probably the reason why some 
"real" programs don't need test cases - or at most three, 
because they cover everything ;-)

Nobody likes "stupid" bugs. Aren't "smart" bugs from 
"smart" codes of "smart" people the better ones ?-)

Some may proclaim 80% as the new standard threshold.
But is 80% of 20% enough, and is there a VAT ?-)

Most people underestimate the effort for thorough testing - 
not by a factor of 2, but by a factor of X or L or more.

But enough with irony and sarcasm.

---

Even the standards changed, too.
F2018 has the audacity to demand chapter 4.2, item 2.

I would like to see gfortran at a level where an average or 
casual programmer will not encounter an ICE with things like 
a forgotten/wrong keyword, attribute or syntactical element.
It's easy enough to think logically wrong, to be in a hurry 
and mess things up. A compiler could be a helper and guide.

No one said it wouldn't be hard and it won't take long.

Thanks to all bold and brave people that work hard on it.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[anlauf at gcc dot gnu.org]

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #14)
> Even the standards changed, too.
> F2018 has the audacity to demand chapter 4.2, item 2.

"(2) it contains the capability to detect and report the use within a submitted
program unit of a form designated herein as obsolescent, insofar as such use
can be detected by reference to the numbered syntax rules and constraints;"

Wow!

I'm amazed that there was agreement on that one.  Who put that there?

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[gscfq@t-online.de]

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

--- Comment #16 from G. Steinmetz <gscfq@t-online.de> ---
Yeah, and other parts are sort of amazing too.
Let me allow to cite the complete 4.2, item 2, points (1)-(10) :


2 A processor conforms to this document if:

 (1) it executes any standard-conforming program in a manner that
     fulfills the interpretations herein, subject to any limits that
     the processor may impose on the size and complexity of the program;

 (2) it contains the capability to detect and report the use within a
     submitted program unit of a form designated herein as obsolescent,
     insofar as such use can be detected by reference to the numbered
     syntax rules and constraints;

 (3) it contains the capability to detect and report the use within a
     submitted program unit of a form or relationship that is not permitted
     by the numbered syntax rules or constraints, including the deleted
     features described in Annex B;

 (4) it contains the capability to detect and report the use within a
     submitted program unit of an intrinsic type with a kind type parameter
     value not supported by the processor (7.4);

 (5) it contains the capability to detect and report the use within a
     submitted program unit of source form or characters not permitted
     by Clause 6;

 (6) it contains the capability to detect and report the use within a
     submitted program of name usage not consistent with the scope rules
     for names, labels, operators, and assignment symbols in Clause 19;

 (7) it contains the capability to detect and report the use within a
     submitted program unit of a non-standard intrinsic procedure
     (including one with the same name as a standard intrinsic procedure
     but with different requirements);

 (8) it contains the capability to detect and report the use within a
     submitted program unit of a non-standard intrinsic module;

 (9) it contains the capability to detect and report the use within a
     submitted program unit of a procedure from a standard intrinsic module,
     if the procedure is not defined by this document or the procedure
     has different requirements from those specified by this document; and

(10) it contains the capability to detect and report the reason for
     rejecting a submitted program.


Thanks !

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:70c884a4b82733027ac0e2620d09169b177080d7

commit r11-2026-g70c884a4b82733027ac0e2620d09169b177080d7
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Fri Jul 10 21:35:35 2020 +0200

    PR fortran/95980 - ICE in get_unique_type_string, at fortran/class.c:485

    In SELECT TYPE, the argument may be an incorrectly specified unlimited
    CLASS variable.  Avoid NULL pointer dereferences for clean error
    recovery.

    gcc/fortran/
            PR fortran/95980
            * class.c (gfc_add_component_ref, gfc_build_class_symbol):
            Add checks for NULL pointer dereference.
            * primary.c (gfc_variable_attr): Likewise.
            * resolve.c (resolve_variable, resolve_assoc_var)
            (resolve_fl_var_and_proc, resolve_fl_variable_derived)
            (resolve_symbol): Likewise.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

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

commit r10-8525-ga3980ada1bd99cf8df22284862693088e5d1ca7c
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Mon Jul 6 18:58:23 2020 +0200

    PR fortran/95980 - ICE on using sync images with -fcheck=bounds

    In SELECT TYPE, the argument may be an incorrectly specified unlimited
    polymorphic variable.  Avoid a NULL pointer dereference for clean error
    recovery.

    gcc/fortran/
            PR fortran/95980
            * match.c (copy_ts_from_selector_to_associate, build_class_sym):
            Distinguish between unlimited polymorphic and ordinary variables
            to avoid NULL pointer dereference.
            * resolve.c (resolve_select_type):
            Distinguish between unlimited polymorphic and ordinary variables
            to avoid NULL pointer dereference.

    (cherry picked from commit f2151227dfe90a5fe73297c370786be98b0b090f)

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:76a8ff3948ad5a36ccae7305a2e9a7c2499418e5

commit r10-8526-g76a8ff3948ad5a36ccae7305a2e9a7c2499418e5
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Fri Jul 10 21:35:35 2020 +0200

    PR fortran/95980 - ICE in get_unique_type_string, at fortran/class.c:485

    In SELECT TYPE, the argument may be an incorrectly specified unlimited
    CLASS variable.  Avoid NULL pointer dereferences for clean error
    recovery.

    gcc/fortran/
            PR fortran/95980
            * class.c (gfc_add_component_ref, gfc_build_class_symbol):
            Add checks for NULL pointer dereference.
            * primary.c (gfc_variable_attr): Likewise.
            * resolve.c (resolve_variable, resolve_assoc_var)
            (resolve_fl_var_and_proc, resolve_fl_variable_derived)
            (resolve_symbol): Likewise.

    (cherry picked from commit 70c884a4b82733027ac0e2620d09169b177080d7)

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #20 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11 and on 10-branch.

Thanks for the report!