https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #19 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #17)
> there's variably_modified_type_p (you can pass NULL_TREE for the fndecl)
> which is more to the point. Otherwise it looks reasonable. Does IPA CP
> do things like IPA SRA and split aggregates?
No, it does not split them, the only SRAish thing it does is simple
removal of unused register-type parameters.
> I wonder in which cases IPA CP would derive "constants" for
> aggregates, so why are aggregate parameters even tracked?
I am not sure I understand the question. The testcase in comment #12
attempts to pass a simple double constant to what is actually a VLA
structure, causing an ICE on undefined behavior input, which is the
main thing I want to avoid.
But I have just realized that if we now insist that we know all types
anyway - I have run the whole C testsuite and did not find any K&R
testcase where IPA-CP would consider a parameter for propagation when
not knowing its type - we can do something better and only propagate
when we know that force_value_to_type would not resort to building a
zero constructor.
This will allow to still propagate ("aggregate") constants within VLAs
like if there was one in b.n in the testcase (and the caller was
somewhat saner).
> I am testing the following for the inline issue for the last testcase,
> leaving the IPA CP one to you.
Sure, thanks.
