On Tue, 22 Nov 2022 12:54:01 +0100
Jan Hubicka <hubi...@ucw.cz> wrote:
> > > I am not quite sure how safe this is. We generally produce DECL_RTL
> > > when we produce assembly file. So if DECL_RTL is set then we probably
> > > already output the original function name and it is too late to change
> > > it.
> >
> > AFAICS we make_decl_rtl in the fortran FE in trans_function_start.
>
> I see, it may be a relic of something that is no longer necessary. Can
> you see why one needs DECL_RTL so early?
No.
I think this is a ward, isn't it.
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index ff64588b9a8..a801e66fb11 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -2922,7 +2922,7 @@ trans_function_start (gfc_symbol * sym)
}
/* Create RTL for function definition. */
- make_decl_rtl (fndecl);
+ //make_decl_rtl (fndecl);
allocate_struct_function (fndecl, false);
But we have that alot, with varous workarounds near
lhd_set_decl_assembler_name.
gcc.gnu.org/pr94223 comes to mind, but that was counters.
But i've seen in C++ too that there are GC dangles like here.
5f3682ffcef162363b783eb9ee702debff489fa8 a.k.a
https://gcc.gnu.org/legacy-ml/gcc-patches/2017-11/msg01340.html
ah lhd_overwrite_decl_assembler_name.
So.. why do we have that, again?
Per default it doesn't look much if there are clones or an ifunc
dispatcher, does it.
