This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/86214] New: [8 Regression] Strongly increased stack usage
- From: "sgunderson at bigfoot dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 19 Jun 2018 16:48:38 +0000
- Subject: [Bug tree-optimization/86214] New: [8 Regression] Strongly increased stack usage
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
Bug ID: 86214
Summary: [8 Regression] Strongly increased stack usage
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Created attachment 44296
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44296&action=edit
Test case
Hi,
We noticed that MySQL does not pass its test suite when compiled with GCC 8; it
runs out of stack. (GCC 7 is fine.) A reduced test case is included (mostly by
C-Reduce, but it needed some help by hand); most of it appears to be fluff that
keeps the compiler from just optimizing away the entire thing, but the gist of
it seems to be that it inlines the bg::bl() function several times without
caring that it balloons the stack size, and then doesn't manage to shrink the
stack again by overlapping variables. Putting the noinline attribute on
bg::bl() seems to be a workaround for now.
For comparison:
> g++-7 -O2 -Wstack-usage=1 -Wno-return-type -Wno-unused-result -c stack.i
stack.i: In function ‘void c()’:
stack.i:34:6: warning: stack usage is 8240 bytes [-Wstack-usage=]
void c() {
^
> g++-8 -O2 -Wstack-usage=1 -Wno-return-type -Wno-unused-result -c stack.i
stack.i: In function ‘void c()’:
stack.i:34:6: warning: stack usage is 32816 bytes [-Wstack-usage=]
void c() {
^
The actual, unreduced file can be found at
https://github.com/mysql/mysql-server/blob/8.0/storage/innobase/row/row0ins.cc#L926
(the line is positioned on a function whose adding noinline helps, although I
don't think it corresponds directly to bg::bl; I think bg::bl might be
ib::error, and the 8192-sized buffer comes from ib::logger::msg).