[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-09-19 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #14 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Harald Anlauf
:

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

commit r8-10521-ge0c7ff6237c78d99b40869afbdcdbe27fe98b698
Author: Tobias Burnus 
Date:   Thu Sep 17 14:01:09 2020 +0200

Fortran: Avoid double-free with parse error (PR96041, PR93423)

gcc/fortran/

PR fortran/96041
PR fortran/93423
* decl.c (gfc_match_submod_proc): Avoid later double-free
in the error case.

(cherry picked from commit c12facd22881517127ebbe213d7ecc7fc1fcea4e)

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-09-19 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #13 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:0e442063a0adf01e6348e9fc55cc3e9869974769

commit r9-8921-g0e442063a0adf01e6348e9fc55cc3e9869974769
Author: Tobias Burnus 
Date:   Thu Sep 17 14:01:09 2020 +0200

Fortran: Avoid double-free with parse error (PR96041, PR93423)

gcc/fortran/

PR fortran/96041
PR fortran/93423
* decl.c (gfc_match_submod_proc): Avoid later double-free
in the error case.

(cherry picked from commit c12facd22881517127ebbe213d7ecc7fc1fcea4e)

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-09-18 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:13421890f81844acb134a460eda7132db3e504ed

commit r10-8775-g13421890f81844acb134a460eda7132db3e504ed
Author: Tobias Burnus 
Date:   Thu Sep 17 14:01:09 2020 +0200

Fortran: Avoid double-free with parse error (PR96041, PR93423)

gcc/fortran/

PR fortran/96041
PR fortran/93423
* decl.c (gfc_match_submod_proc): Avoid later double-free
in the error case.

(cherry picked from commit c12facd22881517127ebbe213d7ecc7fc1fcea4e)

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-09-17 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

Tobias Burnus  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from Tobias Burnus  ---
FIXED on trunk (GCC 11), which is the only one affected.

Note: The patch causing this issue is for PR93423. The latter was a 8/9/10/11
regression of type ICE-on-invalid. If the PR93423 patch gets cherry-picked for
a branch, you may likely also see cherry-picks commits in PR.

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-09-17 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r11-3259-gc12facd22881517127ebbe213d7ecc7fc1fcea4e
Author: Tobias Burnus 
Date:   Thu Sep 17 14:01:09 2020 +0200

Fortran: Avoid double-free with parse error (PR96041, PR93423)

gcc/fortran/

PR fortran/96041
PR fortran/93423
* decl.c (gfc_match_submod_proc): Avoid later double-free
in the error case.

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-09-14 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #9 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553799.html

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-07-07 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #7)
> f951`gfc_resolve_formal_arglist(proc=0x00014301fbb0) at resolve.c:313:18
> frame #2: 0x0001000eb283

Setting a breakpoint here and inspecting the arguments of

313   if (strcmp (proc->name, sym->name) == 0)

one can see that sym->name can be junk after the error message was emitted.

The place where sym is determined is a couple of lines above:

290   for (f = proc->formal; f; f = f->next)
291 {
292   gfc_array_spec *as;
293
294   sym = f->sym;

Either proc got corrupted or has not been set up properly.

On my x86_64 system I have:

(gdb) p *proc->formal->sym->name
$23 = 0 '\000'

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-07-07 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #7 from Dominique d'Humieres  ---
Reduced test (provided t.mod exists)

submodule (t) ts

contains

  module procedure bp(s)
!  end procedure bp

end submodule ts
end

pr93423_red.f90:5:19:

5 |   module procedure bp(s)
  |   1
Error: MODULE PROCEDURE at (1) must be in a generic module interface
f951: internal compiler error: Segmentation fault: 11

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
  * frame #0: 0x7fff6bd198b5 libsystem_platform.dylib`_platform_strcmp +
181
frame #1: 0x0001000c8856
f951`gfc_resolve_formal_arglist(proc=0x00014301fbb0) at resolve.c:313:18
frame #2: 0x0001000eb283 f951`::do_traverse_symtree(st=,
st_func=0x, sym_func=(f951`::find_arglists(gfc_symbol *) at
resolve.c:546:3))(gfc_symtree *), void (*)(gfc_symbol *)) at symbol.c:4170:18
frame #3: 0x0001000c9098 f951`::resolve_types(gfc_namespace *)
[inlined] resolve_formal_arglists(ns=) at resolve.c:563:19
frame #4: 0x0001000c9089 f951`::resolve_types(gfc_namespace *)
[inlined] resolve_contained_functions(ns=0x000143839200)
frame #5: 0x0001000c9089 f951`::resolve_types(ns=0x000143839200)
frame #6: 0x0001000bb9a3 f951`gfc_resolve(ns=0x000143839200) at
resolve.c:17326:17
frame #7: 0x0001000ae701 f951`gfc_parse_file() at parse.c:6448:15
frame #8: 0x0001001032dc f951`::gfc_be_parse_file() at
f95-lang.c:212:18
frame #9: 0x000100e8fddb f951`::compile_file() at toplev.c:458:25
frame #10: 0x0001015dcc7b f951`toplev::main(int, char**) at
toplev.c:2307:24
frame #11: 0x0001015dc8e0 f951`toplev::main(this=0x7ffeefbff26e,
argc=, argv=)
frame #12: 0x0001015dfb61 f951`main(argc=2, argv=0x7ffeefbff2a8) at
main.c:39:22
frame #13: 0x7fff6bb23cc9 libdyld.dylib`start + 1
frame #14: 0x7fff6bb23cc9 libdyld.dylib`start + 1

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-07-06 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #6 from anlauf at gcc dot gnu.org ---
On x86_64 I never reach symbol.c:2662, since the code returns from line 2659.
This the closest I get to your backtrace:

Breakpoint 2, free_st_labels (label=0x0) at
../../gcc-trunk/gcc/fortran/symbol.c:2659
2659  if (label == NULL)
(gdb) bt
#0  free_st_labels (label=0x0) at ../../gcc-trunk/gcc/fortran/symbol.c:2659
#1  0x0073ad9a in gfc_free_namespace (ns=0x27c7c60)
at ../../gcc-trunk/gcc/fortran/symbol.c:4050
#2  0x0073af45 in gfc_free_symbol (sym=0x27c7b00)
at ../../gcc-trunk/gcc/fortran/symbol.c:3091
#3  0x0073b09f in free_sym_tree (sym_tree=0x275f280)
at ../../gcc-trunk/gcc/fortran/symbol.c:3902
#4  0x0073b096 in free_sym_tree (sym_tree=0x27c5a00)
at ../../gcc-trunk/gcc/fortran/symbol.c:3900
#5  0x0073b08d in free_sym_tree (sym_tree=0x275fb90)
at ../../gcc-trunk/gcc/fortran/symbol.c:3899
#6  0x0073b08d in free_sym_tree (sym_tree=0x27c79a0)
at ../../gcc-trunk/gcc/fortran/symbol.c:3899
#7  0x0073ad12 in gfc_free_namespace (ns=0x27c2670)
at ../../gcc-trunk/gcc/fortran/symbol.c:4041
#8  0x0073b34b in gfc_symbol_done_2 ()
at ../../gcc-trunk/gcc/fortran/symbol.c:4101
#9  0x006d9379 in gfc_done_2 () at
../../gcc-trunk/gcc/fortran/misc.c:358
#10 0x006f2053 in clean_up_modules (gsym=0x275e880)
at ../../gcc-trunk/gcc/fortran/parse.c:6267
#11 0x006f201d in clean_up_modules (gsym=0x2823580)
at ../../gcc-trunk/gcc/fortran/parse.c:6259
#12 0x006fd73c in translate_all_program_units
(gfc_global_ns_list=)
at ../../gcc-trunk/gcc/fortran/parse.c:6330
#13 gfc_parse_file () at ../../gcc-trunk/gcc/fortran/parse.c:6546
#14 0x00749f00 in gfc_be_parse_file ()
at ../../gcc-trunk/gcc/fortran/f95-lang.c:212
#15 0x00d74e8f in compile_file () at ../../gcc-trunk/gcc/toplev.c:458
#16 0x006621c9 in do_compile () at ../../gcc-trunk/gcc/toplev.c:2307
#17 toplev::main (this=this@entry=0x7fffd4ae, argc=,
argc@entry=2, 
argv=, argv@entry=0x7fffd5a8) at
../../gcc-trunk/gcc/toplev.c:2446
#18 0x0066602b in main (argc=2, argv=0x7fffd5a8)
at ../../gcc-trunk/gcc/main.c:39
(gdb) p label
$1 = (gfc_st_label *) 0x0

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-07-06 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #5 from Bill Seurer  ---
It hits that breakpoints many times and for the first many it was always 0. 
Then I just let it run until it ICEd and backed up the call stack a bit.


Program received signal SIGSEGV, Segmentation fault.
0x106dcbd4 in free_st_labels (label=0x981) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
2662  free_st_labels (label->left);
(gdb) where
#0  0x106dcbd4 in free_st_labels (label=0x981) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
#1  0x106dcbe0 in free_st_labels (label=0x13492760) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
#2  0x106dcbe0 in free_st_labels (label=0x3fffb7e50a58 )
at /home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
#3  0x106dff28 in gfc_free_namespace (ns=0x13495ae0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4050
#4  0x106dda60 in gfc_free_symbol (sym=0x13493e40) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3084
#5  0x106ddc14 in gfc_release_symbol (sym=0x13493e40) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3125
#6  0x106dfa10 in free_sym_tree (sym_tree=0x13493e00) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3902
#7  0x106dfa00 in free_sym_tree (sym_tree=0x13493ac0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3900
#8  0x106df9f0 in free_sym_tree (sym_tree=0x13493fa0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3899
#9  0x106dfe90 in gfc_free_namespace (ns=0x1348f6b0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4041
#10 0x106e0144 in gfc_symbol_done_2 () at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4101
#11 0x1062536c in gfc_done_2 () at
/home/seurer/gcc/git/gcc-test/gcc/fortran/misc.c:358
#12 0x1066cec8 in clean_up_modules (gsym=0x13490330) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6267
#13 0x1066d22c in translate_all_program_units
(gfc_global_ns_list=0x13477bf0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6330
#14 0x1066da84 in gfc_parse_file () at
/home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6546
#15 0x106f0488 in gfc_be_parse_file () at
/home/seurer/gcc/git/gcc-test/gcc/fortran/f95-lang.c:212
#16 0x11248514 in compile_file () at
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:458
#17 0x1124d87c in do_compile () at
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:2307
#18 0x1124dda4 in toplev::main (this=0x3fffe910, argc=20,
argv=0x3fffed78) at /home/seurer/gcc/git/gcc-test/gcc/toplev.c:2446
#19 0x124facf4 in main (argc=20, argv=0x3fffed78) at
/home/seurer/gcc/git/gcc-test/gcc/main.c:39

up a few times...

4050  free_st_labels (ns->st_labels);
(gdb) print ns->st_labels
$8 = (gfc_st_label *) 0x3fffb7e50a58 

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-07-04 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #3)
> From several runs
> 
> frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
> [inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
> frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *)
> [inlined] free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
> 
> It seems that some trees are not built properly.

I set breakpoints in gdb in these routines but see nothing special on x86_64.

Maybe some stack/heap corruption issue affecting ref counts?

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-07-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #3 from Dominique d'Humieres  ---
>From several runs

frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17

It seems that some trees are not built properly.

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-07-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-04
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed on darwin.

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-07-03 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #0)
> f951: internal compiler error: Segmentation fault
> 0x10be671b crash_signal
>   /home/seurer/gcc/git/gcc-test/gcc/toplev.c:328
> 0x103a6484 free_st_labels
>   /home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
> 0x103a648f free_st_labels
>   /home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
> 0x103a648f free_st_labels
>   /home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
> 0x103afd63 gfc_free_namespace(gfc_namespace*)
>   /home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4044

Bill,

can you set a breakpoint at symbol.c:4044 and print ns->st_labels?

On x86_64 I always have a NULL pointer here, so that symbol.c:2662
is never reached.

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

2020-07-03 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0