[llvm-bugs] [Bug 50266] New: static initialization order issue with inline variables and -fno-use-init-array

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50266

            Bug ID: 50266
           Summary: static initialization order issue with inline
                    variables and -fno-use-init-array
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Wolfgang_Pieb at playstation.sony.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

// The following test suffers from an incorrect initialization
// order when compiled with
// > clang -fno-use-init-array -o t t.cpp
// > .t
// I want to be printed second
// I want to be printed first


extern "C" int printf(const char *, ...);
class A {
public:
  A() {
    printf("I want to be printed first\n");
  }
};

class B {
public:
  B() {
    printf("I want to be printed second\n");
  }
};

class StaticsClass {
private:
    static inline A A_Var;
    static inline B B_Var;
};

int main(void) {
    return 0;
}
//****** end *********

Important: The test case needs to be linked with a pair or crtbegin/crtend
startup files that do not define stubs for .init_array, otherwise
nothing will be printed.

Examining the assembly output, after the following commit:

=================================================
commit c19f4f8069722f6804086d4438a0254104242c46
Author: Jennifer Yu <jennifer.yu at intel.com>
Date:   Thu Apr 25 17:45:45 2019 +0000

    Fix bug 37903:MS ABI: handle inline static data member and inline variable
as template static
data member

    llvm-svn: 359212
=================================================

we see 2 different .ctors section entries in different
comdat groups

        .section        .ctors,"aGw", at progbits,_ZN12StaticsClass5A_VarE,comdat
        .p2align        3
        .quad   __cxx_global_var_init
        .section        .ctors,"aGw", at progbits,_ZN12StaticsClass5B_VarE,comdat
        .p2align        3
        .quad   __cxx_global_var_init.1

which end up consecutively in the executable in this order. However,
the startup code travels the .ctors array in reverse, so we end up
reversing the intialization order.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210507/37be5535/attachment.html>