This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/86214] [8/9 Regression] Strongly increased stack usage
- From: "amonakov at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 04 Jul 2018 14:00:55 +0000
- Subject: [Bug tree-optimization/86214] [8/9 Regression] Strongly increased stack usage
- Auto-submitted: auto-generated
- References: <bug-86214-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
--- Comment #5 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Sorry, this still seems over-reduced: the 'cmp' variable is uninitialized, and
gcc-7 completely optimizes out the block with large stack usage guarded by 'cmp
== 0' test, so gcc-7 vs gcc-8 is not directly comparable. It's strange that
gcc-7 optimizes that out, but it's a different issue.
Can you attach the unreduced preprocessed source, and if you make another
attempt at reducing, perhaps enable most warnings?
That said, it seems gcc is not very good at re-discovering non-overlapping
stack allocations introduced by inlining. Looking at your testcase I came up
with the following minimal test:
struct S{~S();};
void f(void *);
inline void ff()
{
char c[1000];
f(c);
}
void g(int n)
{
S s;
char c[100];
f(c);
if (n) ff(), ff();
}
(there's no regression vs. gcc-7 on this example, but gcc-4.6 used to get a
better result by consuming 1100 bytes rather than 2100).