[Bug target/24428] New: [4.1 regression] TLS miscompilation on x86_64

["jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

Following testcase (distilled from Fortran test in openmpbench_F_v2):

extern __thread double thrtest[81];

int main (void)
{
  int i;
  for (i = 0; i < 81; i++)
    thrtest[i] = 1.0;
}

is miscompiled at -O2 on x86_64:
        movq    thrtest@GOTTPOFF(%rip), %rax
        addq    %fs:0, %rax
.L2:    movabsq $4607182418800017408, %rdx
        movq    %rdx, (%rax)
        addq    $8, %rax
        cmpq    $thrtest+648, %rax
        jne     .L2
        rep ; ret

Note $thrtest+648 which is wrong for __thread variables.
The i386 backend (but it seems other backends as well) legitimize TLS
addresses either when LEGITIMIZE_ADDRESS, or when expanding a move
(ix86_expand_move).  But in this case the middle-end created
(const:DI (plus:DI (symbol_ref:DI ("thrtest") [flags 0x58]) (const_int 648)))
and passed it to gen_movdi, which doesn't do any legitimization.

Adding calls to a legitimization function for TLS addresses to (almost) every
expander is certainly not going to work, so I wonder if either
expand_expr_addr_expr shouldn't notice addresses of TLS variables and force_reg
them, or if general_operand and other routines shouldn't check for this and
reject it (which I guess would cause it to be forced to register and therefore
ix86_expand_move etc. could do its job).


-- 
           Summary: [4.1 regression] TLS miscompilation on x86_64
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-*-linux*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24428