On Tue, Nov 12, 2024 at 10:18:49AM -0500, Jason Merrill wrote:
> Why the v3 tag in the subject line? I don't see any libstdc++ changes.
3rd version of the patch. That has nothing to do with libstdc++.
> > + if (optimize && !optimize_debug && !guard_if_stmt && !sanitize)
>
> Why suppress this optimization in these three conditions?
>
> Well, I guess in the guard_if_stmt case we need to consider some TUs doing
> this optimization and others not, so a dynamic init in another TU could
> start with the constant initialization from this TU instead of the zero-init
> it expects. If the guard is in the same COMDAT group as the variable we
> should be able to statically set the guard to 1 along with setting the
> variable value, and avoid the problem?
>
> Why would we not want this with -Og or asan?
I wanted to avoid -O0 or -Og in case user wants to step through the global
constructor or functions called from there, the optimization (and it is an
optimization, so I think optimize is appropriate in any case) changes the
debugging experience.
For guard_if_stmt, either the guard related stuff is in between the magic
ifns and then it will never be optimized because it isn't turned into a
merge constant store, or if the magic ifns are placed inside of it it would
need more work, tell the post IPA pass there is a guard around this and let
it deal with that. So, in the latter case, not unsolvable, but something
that could be handled incrementally.
And for asan, the thing is that asan performs at runtime checking of the
order of the global ctors and the optimization could result in not detecting
some misuses.
Jakub
