[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
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!
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #18 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a3980ada1bd99cf8df22284862693088e5d1ca7c commit r10-8525-ga3980ada1bd99cf8df22284862693088e5d1ca7c Author: Harald Anlauf 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #19 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:76a8ff3948ad5a36ccae7305a2e9a7c2499418e5 commit r10-8526-g76a8ff3948ad5a36ccae7305a2e9a7c2499418e5 Author: Harald Anlauf 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #17 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:70c884a4b82733027ac0e2620d09169b177080d7 commit r11-2026-g70c884a4b82733027ac0e2620d09169b177080d7 Author: Harald Anlauf 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #16 from G. Steinmetz --- 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #14 from G. Steinmetz --- > ... 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #13 from Dominique d'Humieres --- 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #10 from Dominique d'Humieres --- > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #9 from Steve Kargl --- On Mon, Jul 06, 2020 at 08:29:24PM +, 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #8 from Dominique d'Humieres --- > 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
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
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=edit Patch, part 2
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #5 from Dominique d'Humieres --- > The master branch has been updated by Harald Anlauf : 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f2151227dfe90a5fe73297c370786be98b0b090f commit r11-1855-gf2151227dfe90a5fe73297c370786be98b0b090f Author: Harald Anlauf 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
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
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
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 (_sym->ts, _sym->attr,
_sym->as);
}
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- 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
