[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #14 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #13) > The following variant gives an ICE > >type t >end type > contains >function f() result(t) > character(3) :: c > c = 'abc' >end > end > > > Is the code valid? No.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #13 from Dominique d'Humieres --- The following variant gives an ICE type t end type contains function f() result(t) character(3) :: c c = 'abc' end end The back trace is * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x7fff206945d2 libsystem_platform.dylib`_platform_strlen + 18 frame #1: 0x000100e99509 f951`get_identifier(text=0x) at stringpool.c:95:32 frame #2: 0x00010012b302 f951`::build_function_decl(gfc_symbol *, bool) [inlined] gfc_sym_identifier(sym=) at trans-decl.c:366:10 frame #3: 0x00010012b2d5 f951`::build_function_decl(sym=0x00014331e0b0, global=) frame #4: 0x000100139a3b f951`gfc_generate_function_code(gfc_namespace*) [inlined] gfc_create_function_decl(global=, ns=0x00014403da00) at trans-decl.c:3082:23 frame #5: 0x000100139a2d f951`gfc_generate_function_code(gfc_namespace*) [inlined] gfc_generate_contained_functions(parent=0x000144038e00) frame #6: 0x000100139a03 f951`gfc_generate_function_code(ns=0x000144038e00) frame #7: 0x0001000b04c4 f951`gfc_parse_file() at parse.c:6354:25 frame #8: 0x0001001049bc f951`::gfc_be_parse_file() at f95-lang.c:212:18 frame #9: 0x000100ea0264 f951`::compile_file() at toplev.c:457:25 frame #10: 0x0001016597cf f951`toplev::main(int, char**) at toplev.c:2201:24 frame #11: 0x00010165948e f951`toplev::main(this=0x7ffeefbff09e, argc=, argv=) frame #12: 0x00010165b9e1 f951`main(argc=2, argv=0x7ffeefbff0d8) at main.c:39:22 Is the code valid?
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #12 from Dominique d'Humieres ---
/* Symbol flavors: these are all mutually exclusive.
12 elements = 4 bits. */
enum sym_flavor
{
FL_UNKNOWN = 0, FL_PROGRAM, FL_BLOCK_DATA, FL_MODULE, FL_VARIABLE,
FL_PARAMETER, FL_LABEL, FL_PROCEDURE, FL_DERIVED, FL_NAMELIST,
FL_UNION, FL_STRUCT, FL_VOID
};
so code=15 is invalid.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #11 from Dominique d'Humieres ---
With a clean tree at r11-7872 I get
(lldb) b misc.c:309
Breakpoint 1: where = f951`gfc_code2string(mstring const*, int) + 26 at
misc.c:309:22, address = 0x00010008457a
(lldb) run pr96013.f90
Process 14637 launched:
'/opt/gcc/gcc11a/libexec/gcc/x86_64-apple-darwin20.3.0/11.0.1/f951' (x86_64)
Process 14637 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010008457a f951`gfc_code2string(m=0x0001019c00e0,
code=15) at misc.c:309:22
306m++;
307 }
308
-> 309gfc_internal_error ("gfc_code2string(): Bad code");
310/* Not reached */
311 }
312
Target 0: (f951) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x00010008457a f951`gfc_code2string(m=0x0001019c00e0,
code=15) at misc.c:309:22
frame #1: 0x00010008810c f951`::mio_name(int, const mstring *)
[inlined] mio_name(m=0x0001019bffc0, t=15) at module.c:1800:44
frame #2: 0x000100088102 f951`::mio_name(t=15, m=0x0001019bffc0)
frame #3: 0x00010008816f
f951`::mio_symbol_attribute(attr=0x000142a06520) at module.c:2221:1
frame #4: 0x00010008d633 f951`::mio_symbol(sym=0x000142a064d0) at
module.c:4550:24
frame #5: 0x00010008db98 f951`::write_symbol(n=,
sym=0x000142a064d0) at module.c:5914:14
frame #6: 0x00010008dc42
f951`::write_symbol1_recursion(sp=) at module.c:6117:16
frame #7: 0x000100091baa f951`::dump_module(const char *, int) at
module.c:6150:27
frame #8: 0x000100091b7c f951`::dump_module(const char *, int)
frame #9: 0x000100091b7c f951`::dump_module(name=,
dump_flag=)
frame #10: 0x000100092229 f951`gfc_dump_module(name="m", dump_flag=1)
at module.c:6483:15
frame #11: 0x0001000b2eec f951`gfc_parse_file() at parse.c:6506:23
frame #12: 0x00010010d987 f951`::gfc_be_parse_file() at
f95-lang.c:212:18
frame #13: 0x000100d1a294 f951`::compile_file() at toplev.c:457:25
frame #14: 0x00010120dd9f f951`toplev::main(int, char**) at
toplev.c:2201:24
frame #15: 0x00010120da5e f951`toplev::main(this=0x7ffeefbff09e,
argc=, argv=)
frame #16: 0x00010120ffb1 f951`main(argc=2, argv=0x7ffeefbff0d8) at
main.c:39:22
frame #17: 0x7fff2066d621 libdyld.dylib`start + 1
frame #18: 0x7fff2066d621 libdyld.dylib`start + 1
(lldb) c
Process 14637 resuming
f951: internal compiler error: gfc_code2string(): Bad code
I get the same with the patch in comment 6.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #9) > > > Sometime the test ICE with > > > > > > f951: internal compiler error: gfc_code2string(): Bad code > > > > > > which cannot be fixed by the patch in comment 6. > > > > > > > Don't know anything about libsantize. > > The error has nothing to do with libsanitize. So, then why are you posting incomprehensible garbage from libsanitize, which may have absolutely nothing to do with this patch. The patch in comment #6 prevents the segfault; thereby allowing f951 to continue with the processing of the source code. > It is generated by gfc_code2string in gcc/fortran/misc.c > in a random manner. I cannot reproduce your results. Without a method to reproduce the issue and/or a complete backtrace with line numbers, I standby my assertion that the patch in comment #6 fixes the segfault reported by Gerhard. More importantly, it does not matter if the patch fixes the segfault, because no one is going to commit it anyway.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #9 from Dominique d'Humieres --- > > Sometime the test ICE with > > > > f951: internal compiler error: gfc_code2string(): Bad code > > > > which cannot be fixed by the patch in comment 6. > > > > Don't know anything about libsantize. The error has nothing to do with libsanitize. It is generated by gfc_code2string in gcc/fortran/misc.c in a random manner.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #7) > Sometime the test ICE with > > f951: internal compiler error: gfc_code2string(): Bad code > > which cannot be fixed by the patch in comment 6. > Don't know anything about libsantize. You can fix that issue. The patch I supplied in comment 6 fixes the issue reported by Gerhard. (Un)Fortunately, no one will ever commit the patch. So, I suppose we're all good here.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #7 from Dominique d'Humieres --- Sometime the test ICE with f951: internal compiler error: gfc_code2string(): Bad code which cannot be fixed by the patch in comment 6. A sanitized version with the patch at https://gcc.gnu.org/pipermail/fortran/2021-March/055811.html fails with ==51183==ERROR: AddressSanitizer: heap-use-after-free on address 0x6130351a at pc 0x0001002bac61 bp 0x7ffeefbfe6d0 sp 0x7ffeefbfe6c8 READ of size 1 at 0x6130351a thread T0 #0 0x1002bac60 in write_symbol(int, gfc_symbol*) module.c:5889 #1 0x1002bb0d3 in write_symbol1_recursion(sorted_pointer_info*) module.c:6122 #2 0x1002bb1be in write_symbol1_recursion(sorted_pointer_info*) module.c:6125 #3 0x1002bb43b in write_symbol1(pointer_info*) module.c:6155 #4 0x1002c51e0 in write_module() module.c:6302 #5 0x1002c568f in dump_module(char const*, int) module.c:6431 #6 0x1002c5df6 in gfc_dump_module(char const*, int) module.c:6488 #7 0x10038ac06 in gfc_parse_file() parse.c:6509 #8 0x10057734e in gfc_be_parse_file() f95-lang.c:212 #9 0x10715ded6 in compile_file() toplev.c:457 #10 0x10716c319 in do_compile() toplev.c:2201 #11 0x10a205550 in toplev::main(int, char**) toplev.c:2340 #12 0x10a20b4eb in main main.c:39 #13 0x7fff2066d620 in start+0x0 (libdyld.dylib:x86_64+0x15620) ...
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #6 from kargl at gcc dot gnu.org ---
With this patch the code compiles:
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 280157)
+++ gcc/fortran/module.c(working copy)
@@ -5737,8 +5737,13 @@ write_symbol (int n, gfc_symbol *sym)
{
const char *label;
- if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
-gfc_internal_error ("write_symbol(): bad module symbol %qs", sym->name);
+ if ((sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
+ && !(sym->ts.type != BT_UNKNOWN && sym->attr.result))
+{
+ gfc_error ("Invalid symbol %qs at %L", sym->name,
+>declared_at);
+ return;
+}
mio_integer ();
As far as setting 't', one can get a warning with -Wall.
gfcx -Wall -c a.f90
a.f90:5:25:
5 |function f() result(t)
| 1
Warning: Return value 't' of function 'f' declared at (1) not set
[-Wreturn-typ]
Not sure why this isn't an error (perhaps, false-positives?).
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> (In reply to kargl from comment #3)
> > The code is invalid. Patch against svn revision 280156.
> >
> > Index: gcc/fortran/module.c
> > ===
> > --- gcc/fortran/module.c(revision 280157)
> > +++ gcc/fortran/module.c(working copy)
> > @@ -5738,7 +5738,11 @@ write_symbol (int n, gfc_symbol *sym)
> >const char *label;
> >
> >if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
> > -gfc_internal_error ("write_symbol(): bad module symbol %qs",
> > sym->name);
> > +{
> > + gfc_error ("Invalid symbol %qs at %L", sym->name,
> > +>declared_at);
> > + return;
> > +}
> >
> >mio_integer ();
>
> The patch is wrong and Gerhard is sort of correct. z1.f90 is
> invalid as the result variable is never set. But, an internal
> error should not be signaled. Fortran 2018 has
>
> 19.5.1.4 Host association
>
> A name that appears in the scoping unit as
> ...
> (12) a result-name in a function-stmt or in an entry-stmt,
> ...
> is a local identifier in the scoping unit and any entity of the host
> that has this as its nongeneric name is inaccessible by that name by
> host association.
>
> So, the type 't' is inaccessible in the local scope of f(). The code
> is a good example for the requirement of 'implicit none'.
Note, if 't' is actually set to a value, then the code compiles
module m
type t
end type
contains
function f() result(t)
character(3) :: c
c = 'abc'
t = 1
end
end
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> The code is invalid. Patch against svn revision 280156.
>
> Index: gcc/fortran/module.c
> ===
> --- gcc/fortran/module.c (revision 280157)
> +++ gcc/fortran/module.c (working copy)
> @@ -5738,7 +5738,11 @@ write_symbol (int n, gfc_symbol *sym)
>const char *label;
>
>if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
> -gfc_internal_error ("write_symbol(): bad module symbol %qs", sym->name);
> +{
> + gfc_error ("Invalid symbol %qs at %L", sym->name,
> + >declared_at);
> + return;
> +}
>
>mio_integer ();
The patch is wrong and Gerhard is sort of correct. z1.f90 is
invalid as the result variable is never set. But, an internal
error should not be signaled. Fortran 2018 has
19.5.1.4 Host association
A name that appears in the scoping unit as
...
(12) a result-name in a function-stmt or in an entry-stmt,
...
is a local identifier in the scoping unit and any entity of the host
that has this as its nongeneric name is inaccessible by that name by
host association.
So, the type 't' is inaccessible in the local scope of f(). The code
is a good example for the requirement of 'implicit none'.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-06-30
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #3 from kargl at gcc dot gnu.org ---
The code is invalid. Patch against svn revision 280156.
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 280157)
+++ gcc/fortran/module.c(working copy)
@@ -5738,7 +5738,11 @@ write_symbol (int n, gfc_symbol *sym)
const char *label;
if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
-gfc_internal_error ("write_symbol(): bad module symbol %qs", sym->name);
+{
+ gfc_error ("Invalid symbol %qs at %L", sym->name,
+>declared_at);
+ return;
+}
mio_integer ();
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- I'm not sure that this is valid code. The result variable 't' is neither declared nor set in the function. A type cannot not be a result variable.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- This variant (also legal) compiles : $ cat zz3.f90 module m type t character, allocatable :: a end type contains function f() result(t) character(3) :: c c = 'abc' t = 1.0 end end $ gfortran-11-20200628 -c zz3.f90 $
