On Jan 21, 2021, Jakub Jelinek <ja...@redhat.com> wrote:
> Does that affect only Ada and not other languages?
I haven't observed it on other languages, but I didn't try really hard.
Doing that now, with an assert that the newly-added condition doesn't
ever hit. I'd already completed a bootstrap-asan the other day, but not
with all languages.
The kind of variable that triggers the problem is created within
gcc/ada/gcc-interface/trans.c:Call_to_gnu, specifically within
create_temporary in the same file. In the provided testcase, it injects
the temporary created for the return value from N, passed as a parameter
to C. The binding block containing that temporary ends up dropped when
the initializer of V is discarded, because it's dynamic and V is
imported from a different unit.
I figured if the added condition were to ever hit before, we would add a
poison call to a function that did not have gimple_add_tmp_var called on
it, and that would NOT have it called in the block right after the one I
proposed to modify:
if (!DECL_SEEN_IN_BIND_EXPR_P (decl)
&& DECL_ARTIFICIAL (decl) && DECL_NAME (decl) == NULL_TREE)
gimple_add_tmp_var (decl);
Without gimple_add_tmp_var, we wouldn't allocate automatic storage to
the variable in expand, and then the attempt to take its address for the
poisoning call would explode in make_decl_rtl like this testcase does,
because make_decl_rtl is not to be called for automatic variables.
Since this didn't happen, I figured the new condition would not be hit
except for the failing case. But I was wrong. The bootstrap with the
added assert has just failed, as early as stage2 libiberty. Looking
into it...
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
