https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87436
Bug ID: 87436
Summary: G++ produces >300MB .rodata section to initialize
struct with big array
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: metalcaedes at gmail dot com
Target Milestone: ---
Created attachment 44749
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44749&action=edit
test code
I'm on Linux x86_64, more specifically XUbuntu 16.04, and use GCC version
"Ubuntu 5.4.0-6ubuntu1~16.04.10", so I selected Version 5.4.0
I think this bug still exists in the latest GCC release, but I was only able to
test that on gcc.godbolt.org (there it produces either a timeout or out of
memory error). It also seems like the bug was introduced between 4.9.x and 5.1
Anyway: I have a simple struct with a few fields that are all have default
values, and another struct containing a huge (16mio elements) array of the
aforementioned type (see attachment for test code).
I built it with "g++ -std=c++11 -c -o testsize.o testsize.cpp" - it takes over
a minute to build, cc1plus uses over 4GB of main memory in the process and it
produces a 385MB .o file.
Inspecting that .o shows that the .rodata section is really big, and its
contents are used for the constructor of the struct containing the array - it
just memcpy()s that massive blob of data into the new object..
Now in general this certainly is a clever optimization, but I don't think it's
a good idea if the object is this big.
Furthermore, it even happens with -0s builds and I guess even for saner object
sizes this kind of optimization is not what you'd want in size-optimized
builds?
This might be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82294 -
however I opened a new bug because that report was about C++17 with constexpr,
while my case is C++11.
Godbolt link: https://gcc.godbolt.org/z/Cseqhi
