[Bug c++/87436] New: G++ produces >300MB .rodata section to initialize struct with big array

[metalcaedes at gmail dot com]

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