https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Jason Merrill from comment #10) > A lot of the problem here is that building a std::string involves building a > std::allocator<char> temporary to pass to the string constructor, and then > we need to wait until the entire array is built before we can destroy any of > them: https://eel.is/c++draft/class.temporary#5 says we can only destroy > temporaries early if there was no initializer for that array element. So > for each element of the initializer we have another EH region for its > allocator temporary. > > We could do better for the general case by creating a parallel array of > temporaries and using the same single cleanup region for it as for the array > of strings. This seems like a worthwhile general optimization. > > We might be able to do better for the specific case by recognizing that > std::allocator has no data and nothing cares about its address, so we can go > ahead and destroy it after initializing the string, and reuse the stack > slot. This also saves stack space. Even if we don't emit a loop (which I still think is the way to go for larger initializers because anything else means just too large code), can't there for the larger initializers simply be some variable holding a counter how many initializers have been already initialized and a single EH region that will perform all the cleanups based on that counter?
