PR59723: fix LTO + fortran namelist ICEs

[Richard Biener]

Aldy Hernandez <aldyh@redhat.com> wrote:
>Hi folks.
>
>The problem here is that while streaming the DECL_NAME with 
>stream_read_tree() and consequently lto_output_tree(), we trigger an
>ICE 
>because we are recursing on the DFS walk:
>
>   else
>     {
>       /* This is the first time we see EXPR, write all reachable
>	 trees to OB.  */
>       static bool in_dfs_walk;
>
>       /* Protect against recursion which means disconnect between
>          what tree edges we walk in the DFS walk and what edges
>	 we stream out.  */
>       gcc_assert (!in_dfs_walk);
>
>In the namelist fortran testcases, this is the first time we see the 
>DECL_NAMEs, so we ICE.  I fixed this by outputting the DECL_NAME's 
>string with streamer_write_string() instead.
>
>[I honestly wondered why we don't stream the entire NAMELIST_DECL the 
>same way we stream IMPORTED_DECL, all in one go, instead of piecemeal 
>like the present code does.  But LTO is this complicated black box in
>my 
>head that I try not to think about too much...the current patch touches
>
>as little as possible.]
>
>This change alone fixes the problems in the PR, but I also found
>another 
>ICE now that streaming actually works: dwarf.  It turns out, that the 
>way the CONSTRUCTOR elements in the NAMELIST_DECL are streamed, a 
>PARM_DECL that has been previously seen (in the function's 
>DECL_ARGUMENTS) will be streamed with different reference magic (or 
>whatever streamed references or ids are called in LTO speak).  So when 
>we read the CONSTRUCTOR elements in the LTO read phase, we end up with 
>different pointers for a PARM_DECL in the constructor for the seemingly
>
>same PARM_DECL in the function's arguments (DECL_ARGUMENTS).
>
>I don't understand LTO very well, but I do see that using 
>stream_read_tree (lto_output_tree) caches the entries, so it seems like
>
>a good fit to avoid writing two distinct items for the same PARM_DECL. 
>And since the constructor elements have been previously seen, we won't 
>hit the aforementioned DFS recursion ICE.
>
>It'd be great if the LTO gods could illuminate this abyss (that's you 
>Mr. Biener ;-)), but the attached patch fixes all the LTO problems 
>exhibited by:
>
>make check-fortran RUNTESTFLAGS="--target_board=unix'{-flto}' 
>dg.exp=*namelist*"
>
>As an aside, we really should test some subset of the LTO tests while 
>testing Fortran, or this oversight will surely repeat itself on any 
>changes to the Fortran streamer bits.
>
>Does this help?  OK?

I'll return from vacation next week and will have a closer look then.

Richard.

>Aldy