* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
@ 2020-06-30 20:12 ` gscfq@t-online.de
2020-06-30 20:47 ` kargl at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: gscfq@t-online.de @ 2020-06-30 20:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
G. Steinmetz <gscfq@t-online.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-valid-code
--- Comment #1 from G. Steinmetz <gscfq@t-online.de> ---
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
$
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
2020-06-30 20:12 ` [Bug fortran/96013] " gscfq@t-online.de
@ 2020-06-30 20:47 ` kargl at gcc dot gnu.org
2020-06-30 21:00 ` kargl at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-06-30 20:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
2020-06-30 20:12 ` [Bug fortran/96013] " gscfq@t-online.de
2020-06-30 20:47 ` kargl at gcc dot gnu.org
@ 2020-06-30 21:00 ` kargl at gcc dot gnu.org
2020-06-30 21:22 ` kargl at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-06-30 21:00 UTC (permalink / raw)
To: gcc-bugs
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,
+ &sym->declared_at);
+ return;
+ }
mio_integer (&n);
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (2 preceding siblings ...)
2020-06-30 21:00 ` kargl at gcc dot gnu.org
@ 2020-06-30 21:22 ` kargl at gcc dot gnu.org
2020-06-30 21:38 ` kargl at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-06-30 21:22 UTC (permalink / raw)
To: gcc-bugs
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,
> + &sym->declared_at);
> + return;
> + }
>
> mio_integer (&n);
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'.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (3 preceding siblings ...)
2020-06-30 21:22 ` kargl at gcc dot gnu.org
@ 2020-06-30 21:38 ` kargl at gcc dot gnu.org
2020-06-30 21:41 ` kargl at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-06-30 21:38 UTC (permalink / raw)
To: gcc-bugs
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,
> > + &sym->declared_at);
> > + return;
> > + }
> >
> > mio_integer (&n);
>
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (4 preceding siblings ...)
2020-06-30 21:38 ` kargl at gcc dot gnu.org
@ 2020-06-30 21:41 ` kargl at gcc dot gnu.org
2021-03-26 12:08 ` dominiq at lps dot ens.fr
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-06-30 21:41 UTC (permalink / raw)
To: gcc-bugs
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,
+ &sym->declared_at);
+ return;
+ }
mio_integer (&n);
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?).
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (5 preceding siblings ...)
2020-06-30 21:41 ` kargl at gcc dot gnu.org
@ 2021-03-26 12:08 ` dominiq at lps dot ens.fr
2021-03-26 16:04 ` kargl at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-03-26 12:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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 0x61300000351a
at pc 0x0001002bac61 bp 0x7ffeefbfe6d0 sp 0x7ffeefbfe6c8
READ of size 1 at 0x61300000351a 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)
...
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (6 preceding siblings ...)
2021-03-26 12:08 ` dominiq at lps dot ens.fr
@ 2021-03-26 16:04 ` kargl at gcc dot gnu.org
2021-03-26 16:30 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-03-26 16:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (7 preceding siblings ...)
2021-03-26 16:04 ` kargl at gcc dot gnu.org
@ 2021-03-26 16:30 ` dominiq at lps dot ens.fr
2021-03-26 17:12 ` kargl at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-03-26 16:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > 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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (8 preceding siblings ...)
2021-03-26 16:30 ` dominiq at lps dot ens.fr
@ 2021-03-26 17:12 ` kargl at gcc dot gnu.org
2021-03-27 13:56 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-03-26 17:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (9 preceding siblings ...)
2021-03-26 17:12 ` kargl at gcc dot gnu.org
@ 2021-03-27 13:56 ` dominiq at lps dot ens.fr
2021-03-27 13:59 ` dominiq at lps dot ens.fr
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-03-27 13:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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 = 0x000000010008457a
(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: 0x000000010008457a f951`gfc_code2string(m=0x00000001019c00e0,
code=15) at misc.c:309:22
306 m++;
307 }
308
-> 309 gfc_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: 0x000000010008457a f951`gfc_code2string(m=0x00000001019c00e0,
code=15) at misc.c:309:22
frame #1: 0x000000010008810c f951`::mio_name(int, const mstring *)
[inlined] mio_name(m=0x00000001019bffc0, t=15) at module.c:1800:44
frame #2: 0x0000000100088102 f951`::mio_name(t=15, m=0x00000001019bffc0)
frame #3: 0x000000010008816f
f951`::mio_symbol_attribute(attr=0x0000000142a06520) at module.c:2221:1
frame #4: 0x000000010008d633 f951`::mio_symbol(sym=0x0000000142a064d0) at
module.c:4550:24
frame #5: 0x000000010008db98 f951`::write_symbol(n=<unavailable>,
sym=0x0000000142a064d0) at module.c:5914:14
frame #6: 0x000000010008dc42
f951`::write_symbol1_recursion(sp=<unavailable>) at module.c:6117:16
frame #7: 0x0000000100091baa f951`::dump_module(const char *, int) at
module.c:6150:27
frame #8: 0x0000000100091b7c f951`::dump_module(const char *, int)
frame #9: 0x0000000100091b7c f951`::dump_module(name=<unavailable>,
dump_flag=<unavailable>)
frame #10: 0x0000000100092229 f951`gfc_dump_module(name="m", dump_flag=1)
at module.c:6483:15
frame #11: 0x00000001000b2eec f951`gfc_parse_file() at parse.c:6506:23
frame #12: 0x000000010010d987 f951`::gfc_be_parse_file() at
f95-lang.c:212:18
frame #13: 0x0000000100d1a294 f951`::compile_file() at toplev.c:457:25
frame #14: 0x000000010120dd9f f951`toplev::main(int, char**) at
toplev.c:2201:24
frame #15: 0x000000010120da5e f951`toplev::main(this=0x00007ffeefbff09e,
argc=<unavailable>, argv=<unavailable>)
frame #16: 0x000000010120ffb1 f951`main(argc=2, argv=0x00007ffeefbff0d8) at
main.c:39:22
frame #17: 0x00007fff2066d621 libdyld.dylib`start + 1
frame #18: 0x00007fff2066d621 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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (10 preceding siblings ...)
2021-03-27 13:56 ` dominiq at lps dot ens.fr
@ 2021-03-27 13:59 ` dominiq at lps dot ens.fr
2021-04-18 11:27 ` dominiq at lps dot ens.fr
2021-04-18 17:34 ` kargl at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-03-27 13:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
/* 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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (11 preceding siblings ...)
2021-03-27 13:59 ` dominiq at lps dot ens.fr
@ 2021-04-18 11:27 ` dominiq at lps dot ens.fr
2021-04-18 17:34 ` kargl at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-04-18 11:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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: 0x00007fff206945d2 libsystem_platform.dylib`_platform_strlen + 18
frame #1: 0x0000000100e99509 f951`get_identifier(text=0x0000000000000000)
at stringpool.c:95:32
frame #2: 0x000000010012b302 f951`::build_function_decl(gfc_symbol *, bool)
[inlined] gfc_sym_identifier(sym=<unavailable>) at trans-decl.c:366:10
frame #3: 0x000000010012b2d5
f951`::build_function_decl(sym=0x000000014331e0b0, global=<unavailable>)
frame #4: 0x0000000100139a3b
f951`gfc_generate_function_code(gfc_namespace*) [inlined]
gfc_create_function_decl(global=<unavailable>, ns=0x000000014403da00) at
trans-decl.c:3082:23
frame #5: 0x0000000100139a2d
f951`gfc_generate_function_code(gfc_namespace*) [inlined]
gfc_generate_contained_functions(parent=0x0000000144038e00)
frame #6: 0x0000000100139a03
f951`gfc_generate_function_code(ns=0x0000000144038e00)
frame #7: 0x00000001000b04c4 f951`gfc_parse_file() at parse.c:6354:25
frame #8: 0x00000001001049bc f951`::gfc_be_parse_file() at
f95-lang.c:212:18
frame #9: 0x0000000100ea0264 f951`::compile_file() at toplev.c:457:25
frame #10: 0x00000001016597cf f951`toplev::main(int, char**) at
toplev.c:2201:24
frame #11: 0x000000010165948e f951`toplev::main(this=0x00007ffeefbff09e,
argc=<unavailable>, argv=<unavailable>)
frame #12: 0x000000010165b9e1 f951`main(argc=2, argv=0x00007ffeefbff0d8) at
main.c:39:22
Is the code valid?
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
2020-06-30 20:12 [Bug fortran/96013] New: ICE in write_symbol, at fortran/module.c:5747 gscfq@t-online.de
` (12 preceding siblings ...)
2021-04-18 11:27 ` dominiq at lps dot ens.fr
@ 2021-04-18 17:34 ` kargl at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-04-18 17:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread