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.