https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looking at the #c7 testcase, confirming that ~ 29KB stack in one of the
functions. The problem is that msg has char buf[8192]; variable in it and is
inline, gets inlined into a function 3 times and can throw.
ehcleanup1 removes the buf (and str) clobbers that were the only reason to have
an EH pad that just rethrows (and I agree it is a good idea to do that, because
otherwise inliner thinks the functions are more expensive than they actually
are).
But then the function into which this function is ultimately inlined has some
finalization (destructors) covering the code into which it has been inlined, so
the former EH with no successor block because it would throw externally now
becomes EH edge from the code to a landing block onto which everything is
marked as conflicting, there is no clobber at all for the variables.
So, I wonder if we shouldn't add in such cases clobbers to the start of those
landing pads in the situation, either for all variables that live in memory, or
at least for the larger ones. Will play with it tomorrow.
There is another thing - I've noticed add_stack_var_conflict is often called
with x == y, shouldn't we return right away in that case? We don't need to
record that a var conflicts with itself, we later on return that no variable
conflicts with itself.
Note, before r255104 we weren't inlining msg into the bigger function and thus
the issue was latent.
The workaround for MySQL, at least for -O2, would be to move logger:msg
definition out from the class, so it is not inline, then at least gcc trunk
doesn't want to inline it and you don't run into this.
