https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
--- Comment #7 from JuzheZhong <juzhe.zhong at rivai dot ai> --- (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.
