[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 Bug 87994 depends on bug 87993, which changed state. Bug 87993 Summary: ICE in gfc_constructor_first, at fortran/constructor.c:234 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87993 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #9 from kargl at gcc dot gnu.org --- Fixed on trunk.
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 --- Comment #8 from Dominique d'Humieres --- I have instrumented gfortran with the patch in comment 5 and all the tests fail as with pr87881: = ==67715==ERROR: AddressSanitizer: heap-use-after-free on address 0x617045d8 at pc 0x0001001565a9 bp 0x7ffeefbfdd30 sp 0x7ffeefbfdd28 READ of size 8 at 0x617045d8 thread T0 #0 0x1001565a8 in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1943 #1 0x10015438e in gfc_simplify_expr(gfc_expr*, int) expr.c:2164 #2 0x100369eaf in gfc_match_varspec(gfc_expr*, int, bool, bool) primary.c:2287 #3 0x1003798ba in gfc_match_rvalue(gfc_expr**) primary.c:3670 #4 0x1000c2f63 in match_data_constant(gfc_expr**) decl.c:379 #5 0x1000c4291 in top_val_list(gfc_data*) decl.c:478 #6 0x1000c4905 in gfc_match_data() decl.c:624 #7 0x10032fbc7 in match_word(char const*, match (*)(), locus*) parse.c:65 #8 0x10033d154 in decode_statement() parse.c:468 #9 0x10033ee0d in next_free() parse.c:1234 #10 0x10033f7d2 in next_statement() parse.c:1466 #11 0x100345d67 in parse_spec(gfc_statement) parse.c:3858 #12 0x10034c892 in parse_progunit(gfc_statement) parse.c:5671 #13 0x10034ec10 in gfc_parse_file() parse.c:6211 #14 0x100525304 in gfc_be_parse_file() f95-lang.c:204 #15 0x1062941c8 in compile_file() toplev.c:455 #16 0x10629f87c in do_compile() toplev.c:2172 #17 0x109388807 in toplev::main(int, char**) toplev.c:2307 #18 0x1097eaf4c in main main.c:39 #19 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c) 0x617045d8 is located 728 bytes inside of 736-byte region [0x61704300,0x617045e0) freed by thread T0 here: #0 0x15948a8e0 in wrap_free.part.0 sanitizer_malloc_mac.inc:121 #1 0x10012e8e5 in gfc_free_ref_list(gfc_ref*) expr.c:599 #2 0x10012efdd in free_expr0(gfc_expr*) expr.c:505 #3 0x10012f3be in gfc_replace_expr(gfc_expr*, gfc_expr*) expr.c:616 #4 0x1001563b7 in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1970 #5 0x10015438e in gfc_simplify_expr(gfc_expr*, int) expr.c:2164 #6 0x100369eaf in gfc_match_varspec(gfc_expr*, int, bool, bool) primary.c:2287 #7 0x1003798ba in gfc_match_rvalue(gfc_expr**) primary.c:3670 #8 0x1000c2f63 in match_data_constant(gfc_expr**) decl.c:379 #9 0x1000c4291 in top_val_list(gfc_data*) decl.c:478 #10 0x1000c4905 in gfc_match_data() decl.c:624 #11 0x10032fbc7 in match_word(char const*, match (*)(), locus*) parse.c:65 #12 0x10033d154 in decode_statement() parse.c:468 #13 0x10033ee0d in next_free() parse.c:1234 #14 0x10033f7d2 in next_statement() parse.c:1466 #15 0x100345d67 in parse_spec(gfc_statement) parse.c:3858 #16 0x10034c892 in parse_progunit(gfc_statement) parse.c:5671 #17 0x10034ec10 in gfc_parse_file() parse.c:6211 #18 0x100525304 in gfc_be_parse_file() f95-lang.c:204 #19 0x1062941c8 in compile_file() toplev.c:455 #20 0x10629f87c in do_compile() toplev.c:2172 #21 0x109388807 in toplev::main(int, char**) toplev.c:2307 #22 0x1097eaf4c in main main.c:39 #23 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c) previously allocated by thread T0 here: #0 0x159489db3 in wrap_calloc sanitizer_malloc_mac.inc:132 #1 0x1088a10de in xcalloc xmalloc.c:162 #2 0x10035b5ae in is_inquiry_ref(char const*, gfc_ref**) primary.c:1964 #3 0x100368721 in gfc_match_varspec(gfc_expr*, int, bool, bool) primary.c:2199 #4 0x1003798ba in gfc_match_rvalue(gfc_expr**) primary.c:3670 #5 0x1000c2f63 in match_data_constant(gfc_expr**) decl.c:379 #6 0x1000c4291 in top_val_list(gfc_data*) decl.c:478 #7 0x1000c4905 in gfc_match_data() decl.c:624 #8 0x10032fbc7 in match_word(char const*, match (*)(), locus*) parse.c:65 #9 0x10033d154 in decode_statement() parse.c:468 #10 0x10033ee0d in next_free() parse.c:1234 #11 0x10033f7d2 in next_statement() parse.c:1466 #12 0x100345d67 in parse_spec(gfc_statement) parse.c:3858 #13 0x10034c892 in parse_progunit(gfc_statement) parse.c:5671 #14 0x10034ec10 in gfc_parse_file() parse.c:6211 #15 0x100525304 in gfc_be_parse_file() f95-lang.c:204 #16 0x1062941c8 in compile_file() toplev.c:455 #17 0x10629f87c in do_compile() toplev.c:2172 #18 0x109388807 in toplev::main(int, char**) toplev.c:2307 #19 0x1097eaf4c in main main.c:39 #20 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c) SUMMARY: AddressSanitizer: heap-use-after-free expr.c:1943 in simplify_ref_chain(gfc_ref*, int, gfc_expr**) Shadow bytes around the buggy address: 0x1c2e0860: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x1c2e0870: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x1c2e0880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x1c2e0890: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x1c2e08a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd =>0x1c2e00
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #6) > AFAICT the patch in comment 5 fixes the tests in comments 1 and 5, but not > the test in comment 0. % cat a.f90 program p real :: a, b data b /a%kind/ print *, b end % gfcx -o z a.f90 && ./z 4.
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 --- Comment #6 from Dominique d'Humieres --- AFAICT the patch in comment 5 fixes the tests in comments 1 and 5, but not the test in comment 0.
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #5 from kargl at gcc dot gnu.org ---
Better patch. Permits %re and %im in data statement.
program p
complex, parameter :: a = (42.5,23)
real :: b
data b /a%re/
print *, b
end
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 266155)
+++ gcc/fortran/decl.c (working copy)
@@ -388,6 +388,14 @@ match_data_constant (gfc_expr **result)
}
else if (m == MATCH_YES)
{
+ /* If a parameter inquiry ends up here, symtree is NULL but **result
+contains the right constant expression. Check here. */
+ if ((*result)->symtree == NULL
+ && (*result)->expr_type == EXPR_CONSTANT
+ && ((*result)->ts.type == BT_INTEGER
+ || (*result)->ts.type == BT_REAL))
+ return m;
+
/* F2018:R845 data-stmt-constant is initial-data-target.
A data-stmt-constant shall be ... initial-data-target if and
only if the corresponding data-stmt-object has the POINTER
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #4 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 266155)
+++ gcc/fortran/decl.c (working copy)
@@ -388,6 +388,13 @@ match_data_constant (gfc_expr **result)
}
else if (m == MATCH_YES)
{
+ /* If a parameter inquiry ends up here, symtree is NULL but **result
+contains the right constant expression. Check here. */
+ if ((*result)->symtree == NULL
+ && (*result)->expr_type == EXPR_CONSTANT
+ && (*result)->ts.type == BT_INTEGER)
+ return m;
+
/* F2018:R845 data-stmt-constant is initial-data-target.
A data-stmt-constant shall be ... initial-data-target if and
only if the corresponding data-stmt-object has the POINTER
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 --- Comment #3 from G. Steinmetz --- Sure ...
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 --- Comment #2 from Dominique d'Humieres --- Related to/duplicate of pr87881/pr87945/pr87993. > Changed between 20181028 and 20181104 (ICE). Parameter inquiry has been introduced at revision r265729: before it gave the error Error: Unexpected '%' for nonderived-type variable 'a' at (1) IMO you should give Paul a chance to fix pr87881 before filing new PRs.
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-13 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 --- Comment #1 from G. Steinmetz --- > Should be valid code, ... Whoops, suboptimal. Better examples : $ cat z3.f90 program p real, parameter :: a = 1.0 data b /a%kind/ end $ cat z4.f90 program p integer, parameter :: a = 1 integer :: b data b /a%kind/ end Changed between 20181028 and 20181104 (ICE).
