On 11/11/24 3:43 AM, Jakub Jelinek wrote:
Hi!

I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588539.html
patch.
Previous mails on this topic
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/thread.html#583289
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/585994.html
As it has been a while, the patch doesn't apply cleanly anymore, so here
is an updated patch (minor changes), bootstrapped/regtested on x86_64-linux
and i686-linux:

2024-11-11  Jakub Jelinek  <ja...@redhat.com>

        PR c++/102876
gcc/
        * internal-fn.def (DYNAMIC_INIT_START, DYNAMIC_INIT_END): New internal
        functions.
        * internal-fn.cc (expand_DYNAMIC_INIT_START, expand_DYNAMIC_INIT_END):
        New functions.
        * tree-pass.h (make_pass_dyninit): Declare.
        * passes.def (pass_dyninit): Add after dce4.
        * function.h (struct function): Add has_dynamic_init bitfield.
        * tree-inline.cc (initialize_cfun): Copy over has_dynamic_init.
        (expand_call_inline): Or in has_dynamic_init from inlined fn into
        caller.
        * params.opt (--param=dynamic-init-max-size=): New param.
        * gimple-ssa-store-merging.cc (pass_data_dyninit): New variable.
        (class pass_dyninit): New type.
        (pass_dyninit::execute): New method.
        (make_pass_dyninit): New function.
gcc/cp/
        * decl2.cc (one_static_initialization_or_destruction): Emit
        .DYNAMIC_INIT_START and .DYNAMIC_INIT_END internal calls around
        dynamic initialization of variables that don't need a guard.
gcc/testsuite/
        * g++.dg/opt/init3.C: New test.

Why the v3 tag in the subject line?  I don't see any libstdc++ changes.

+         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?

Jason

Reply via email to