[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[mikael at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

Mikael Morin  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[mikael at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

Mikael Morin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Mikael Morin  ---
Fixed for gfortran 14.  Closing.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

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

commit r14-3864-gb9cbd1a2c2f50d4e305938d97916011bd5839ce0
Author: Mikael Morin 
Date:   Tue Sep 12 10:24:20 2023 +0200

fortran: Undo new symbols in all namespaces [PR110996]

Remove new symbols from all namespaces they may have been added to in case
a
statement mismatches in the end and all the symbols referenced in it have
to
be reverted.

This fixes memory errors and random internal compiler errors caused by
a new symbol left with dangling pointers but not properly removed from the
namespace at statement rejection.

Before this change, new symbols were removed from their own namespace
(their ns field) only.  This change additionally removes them from the
namespaces pointed to by respectively the gfc_current_ns global variable,
and the symbols' formal_ns field.

PR fortran/110996

gcc/fortran/ChangeLog:

* gfortran.h (gfc_release_symbol): Set return type to bool.
* symbol.cc (gfc_release_symbol): Ditto.  Return whether symbol was
freed.
(delete_symbol_from_ns): New, outline code from...
(gfc_restore_last_undo_checkpoint): ... here.  Delete new symbols
from two more namespaces.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr110996.f90: New test.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[mikael at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

Mikael Morin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mikael at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #9 from Mikael Morin  ---
Created attachment 55801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55801=edit
Draft patch, to be cleaned up.

I need to clean up this, but it passes the fortran testsuite in its current
form.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[mikael at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

--- Comment #8 from Mikael Morin  ---
(In reply to JuzheZhong from comment #7)
> Do you have a solution that we can fix RISC-V backend?

No, this is not RISC-V specific.

> Or you will fix it in Fortran front-end?

Yes, the fix will have to be in the fortran front-end, but I haven't found it
yet.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[juzhe.zhong at rivai dot ai via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

--- Comment #7 from JuzheZhong  ---
(In reply to Mikael Morin from comment #6)
> (In reply to Mikael Morin from comment #5)
> > Here sym->formal_ns is NULL because the symbol C has not been completely
> > setup.
> 
> This makes the following an "obvious" fix:
> 
> diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
> index 8182ef29f43..5afb9f2e2d3 100644
> --- a/gcc/fortran/decl.cc
> +++ b/gcc/fortran/decl.cc
> @@ -7496,6 +7496,7 @@ gfc_match_function_decl (void)
>  sym->attr.module_procedure = 1;
>  
>gfc_new_block = sym;
> +  sym->formal_ns = gfc_current_ns;
>  
>m = gfc_match_formal_arglist (sym, 0, 0);
>if (m == MATCH_NO)
> @@ -7993,6 +7994,7 @@ gfc_match_subroutine (void)
>  sym = sym->result;
>  
>gfc_new_block = sym;
> +  sym->formal_ns = gfc_current_ns;
>  
>/* Check what next non-whitespace character is so we can tell if there
>   is the required parens if we have a BIND(C).  */
> 
> 
> However, that patch makes the situation worse by releasing the namespace for
> "c" too early, as we access it later in reject_statement (it is the
> "current" namespace).

Thanks for helping with this issue. 
Do you have a solution that we can fix RISC-V backend?
Or you will fix it in Fortran front-end?

Thanks.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[mikael at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

--- Comment #6 from Mikael Morin  ---
(In reply to Mikael Morin from comment #5)
> Here sym->formal_ns is NULL because the symbol C has not been completely
> setup.

This makes the following an "obvious" fix:

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 8182ef29f43..5afb9f2e2d3 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -7496,6 +7496,7 @@ gfc_match_function_decl (void)
 sym->attr.module_procedure = 1;

   gfc_new_block = sym;
+  sym->formal_ns = gfc_current_ns;

   m = gfc_match_formal_arglist (sym, 0, 0);
   if (m == MATCH_NO)
@@ -7993,6 +7994,7 @@ gfc_match_subroutine (void)
 sym = sym->result;

   gfc_new_block = sym;
+  sym->formal_ns = gfc_current_ns;

   /* Check what next non-whitespace character is so we can tell if there
  is the required parens if we have a BIND(C).  */


However, that patch makes the situation worse by releasing the namespace for
"c" too early, as we access it later in reject_statement (it is the "current"
namespace).

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[mikael at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

Mikael Morin  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-17
 CC||mikael at gcc dot gnu.org

--- Comment #5 from Mikael Morin  ---
Confirmed on the reduced example from comment #2.

The problem arises because of the bogus subroutine statement:
   SUBROUTINE c(d) e

This is rejected and symbols C and D should be released (no symbol has been
built for E at the time the statement is rejected).
D is released, but C is not, and it keeps a pointer to D through it's formal
field. BOOM.

The reason C is not released is its reference count is 2 and the condition to
break cycles at the beginning of gfc_release_symbol doesn't hold:

3118  if (sym->formal_ns != NULL && sym->refs == 2 && sym->formal_ns != sym->ns
3119  && (!sym->attr.entry || !sym->module))

Here sym->formal_ns is NULL because the symbol C has not been completely setup.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[juzhe.zhong at rivai dot ai via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

--- Comment #4 from JuzheZhong  ---
(In reply to Jeremy Bennett from comment #3)
> @JuzheZhong I believe this is in someway related to RVV.  If I remove `v'
> from the march:
> 
> riscv64-unknown-linux-gnu-gfortran -march=rv64gc -mabi=lp64d -c -Ofast
> testcase.f90
> 
> The output I get is correct:
> 
> testcase.f90:6:20:
> 
> 6 |SUBROUTINE c(d) e
>   |1
> Error: Syntax error in SUBROUTINE statement at (1)
> 
> Why does adding `v' to the -march string cause a SEGV?

I didn't reproduce the issue. What I see is GCC has ICE even without 'v' in 
-march. And I have no idea for it.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[jeremy.bennett at embecosm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

--- Comment #3 from Jeremy Bennett  ---
@JuzheZhong I believe this is in someway related to RVV.  If I remove `v' from
the march:

riscv64-unknown-linux-gnu-gfortran -march=rv64gc -mabi=lp64d -c -Ofast
testcase.f90

The output I get is correct:

testcase.f90:6:20:

6 |SUBROUTINE c(d) e
  |1
Error: Syntax error in SUBROUTINE statement at (1)

Why does adding `v' to the -march string cause a SEGV?

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||error-recovery

--- Comment #2 from anlauf at gcc dot gnu.org ---
I don't see an ICE on x86_64-pc-linux-gnu, but valgrind shows several
invalid reads, even on e.g. a shorter version:

PROGRAM p
CONTAINS
  SUBROUTINE c(d) e
  SUBROUTINE f
  END
END

We also have a couple of other PRs on error recovery on weird syntax errors.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[juzhe.zhong at rivai dot ai via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996

JuzheZhong  changed:

   What|Removed |Added

 CC||juzhe.zhong at rivai dot ai

--- Comment #1 from JuzheZhong  ---
I don't think this is RISC-V target specific issue, at leas it should not be
the RVV specific issue:

[jzzhong@rios-cad5:/work/home/jzzhong/work/insn]$~/work/rvv-opensource/output/gcc-rv64/bin/riscv64-rivai-elf-gfortran
-march=rv64gc -mabi=lp64d -Ofast pr110996.f90
pr110996.f90:6:20:

6 |SUBROUTINE c(d) e
  |1
Error: Syntax error in SUBROUTINE statement at (1)
f951: internal compiler error: Segmentation fault
0x17bd167 crash_signal
../../../riscv-gcc/gcc/toplev.cc:314
0xe9d659 resolve_symbol
../../../riscv-gcc/gcc/fortran/resolve.cc:16643
0xec5dfd do_traverse_symtree
../../../riscv-gcc/gcc/fortran/symbol.cc:4190
0xec5eb8 gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
../../../riscv-gcc/gcc/fortran/symbol.cc:4215
0xea0421 resolve_types
../../../riscv-gcc/gcc/fortran/resolve.cc:17963
0xea04d9 resolve_types
../../../riscv-gcc/gcc/fortran/resolve.cc:17977
0xea0915 gfc_resolve(gfc_namespace*)
../../../riscv-gcc/gcc/fortran/resolve.cc:18083
0xe6bd6b resolve_all_program_units
../../../riscv-gcc/gcc/fortran/parse.cc:6909
0xe6c558 gfc_parse_file()
../../../riscv-gcc/gcc/fortran/parse.cc:7165
0xed11d9 gfc_be_parse_file
../../../riscv-gcc/gcc/fortran/f95-lang.cc:229
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


It can be reproduced without 'v' extension in '-march'.