[Bug c++/109164] New: aarch64 thread_local initialization error with -ftree-pre and -foptimize-sibling-calls

["loganh at synopsys dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164

            Bug ID: 109164
           Summary: aarch64 thread_local initialization error with
                    -ftree-pre and -foptimize-sibling-calls
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: loganh at synopsys dot com
  Target Milestone: ---

Created attachment 54687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54687&action=edit
Bash script that reproduces the issue

With -ftree-pre, -foptimize-sibling-calls, and -O1 enabled, on
aarch64-linux-gnu, GCC 12.1.0 can generate code to access parts of thread_local
variables before the corresponding TLS init function is called if the variable
is accessed from a different TU than the variable is defined in. This
reordering could likely cause a number of different issues, but the one that
I've run into is that:
- When the compiler generates code to call a virtual function on a reference to
a to a global thread_local instance of an object defined in a different
translation unit, and
- The function calls itself in at least once branch,
the address of the  object is fetched from TLS before it's initialized, and
when the vtable lookup is attempted on that object to call the virtual function
the program segfaults.

Here's an example of the kind of code that will trip it up:

struct Struct  {                                                                
  virtual void virtual_func();                                                  
};                                                                              

extern thread_local Struct& thread_local_ref;                                   

bool other_func(void);                                                          

bool test_func(void) {                                                          
  thread_local_ref.virtual_func();                                              
  return other_func() && test_func();                                           
}

When this is compiled (on aarch64-linux-gnu, with -O1 and -ftree-pre and
-foptimize-sibling-calls) to an object file and then dumped with objdump -C -d,
this is the code produced:

0000000000000000 <test_func()>:                                                 
    0: a9be7bfd  stp x29, x30, [sp, #-32]!                                      
    4: 910003fd  mov x29, sp                                                    
    8: a90153f3  stp x19, x20, [sp, #16]                                        
    c: 90000000  adrp  x0, 0 <thread_local_ref>                                 
   10: f9400000  ldr x0, [x0]                                                   
   14: d53bd041  mrs x1, tpidr_el0                                              
   18: f8606834  ldr x20, [x1, x0]                                              
   1c: 90000013  adrp  x19, 0 <TLS init function for thread_local_ref>          
   20: f9400273  ldr x19, [x19]                                                 
   24: b4000053  cbz x19, 2c <test_func()+0x2c>                                 
   28: 94000000  bl  0 <TLS init function for thread_local_ref>                 
   2c: f9400280  ldr x0, [x20]                                                  
   30: f9400001  ldr x1, [x0]                                                   
   34: aa1403e0  mov x0, x20                                                    
   38: d63f0020  blr x1                                                         
   3c: 94000000  bl  0 <other_func()>                                           
   40: 12001c00  and w0, w0, #0xff                                              
   44: 35ffff00  cbnz  w0, 24 <test_func()+0x24>                                
   48: a94153f3  ldp x19, x20, [sp, #16]                                        
   4c: a8c27bfd  ldp x29, x30, [sp], #32                                        
   50: d65f03c0  ret  

Looking at addresses 0x14 through 0x18, you can see that the address of
'thread_local_ref' is read from the TLS block for the thread; the first time
this function is called, this will result in register x20 containing zero,
since the TLS block isn't intialized until the function call at 0x28. Directly
after that, at location 0x2c, a read is attempted from the address in register
x20 (zero) causing a segfault. Without -ftree-pre and -foptimize-sibling calls,
and without letting `test_func` call itself on at least one path, the code to
get the address of `thread_local_ref` is generated after the TLS init call, so
the problem does not occur.

I've attached a script that will reproduce what I've shown here, as well as
demonstrate the issue in action with a full executable that will produce the
segfault I've described.