PATCH: Fix 64-bit Solaris 2/x86 IE TLS code sequence

[H.J. Lu]

On Tue, Mar 9, 2010 at 8:10 AM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> Uros Bizjak <ubizjak@gmail.com> writes:
>
>> On Tue, Mar 2, 2010 at 12:41 AM, Rainer Orth
>> <ro@cebitec.uni-bielefeld.de> wrote:
>>
>>>> As far as addq is concerned, you will need to disable generic add patterns
>>>> for tls_symbolic_operand and provide special ones that will handle
>>>> tls_symbolic_operand.  Try to add "! tls_symbolic_operand (operands[2],
>>>> VOIDmode) to PLUS rtx patterns and provide specialized
>>>
>>> which of them would that be?  Consider me pretty much ignorant of this
>>> side of GCC ;-)  There are so many *add patterns, and I have no idea if
>>> I need to change them all or which subset.
>>
>> You will need to disable for tls_symbolic_operand (and add replacement
>> that handles this operand) for *add<mode>_1 and *addsi_1_zext.
>> Probably you will need to disable (without replacement) *add<mode>_2,
>> *addsi2_zext, *add<mode>_3, *addsi3_zext, *add<mode>_5 for
>> tls_symbolic_operand (in fact, all "add" patterns that are already
>> disabled for pic_symbolic_operand - grep for "Current assemblers are
>> broken").
>
> Thanks, that was really helpful.  I'm making some progress, but am not
> there yet.  With my test program
>
> $ cat tie-common.c
> int cnt;
> #pragma omp threadprivate (cnt)
>
> int
> main (void)
> {
>  cnt = 0;
>  return 0;
> }
> $ gcc -fopenmp -S tie-common.c
> $ cat tie-common.s
> [...]
>        movq    %fs:0, %rax
>        movq    %rax, %rdx
>        movq    cnt@gottpoff(%rip), %rax
>        movl    $0, (%rdx,%rax)
> $ gcc -fopenmp -O2 -S tie-common.c
> $ cat tie-common.s
> [...]
>        movq    cnt@gottpoff(%rip), %rdx
>        movq    %fs:0, %rax
>        movl    $0, (%rax,%rdx)
>
> So there's either still the intervening movq %rax, %rdx, or the sequence
> is reordered and the wrong destination register used.
>
> Below's my (actually your :-) current patch.
>
> Suggestions?
>
> Btw., in the meantime I've noticed that the code sequence demanded in
> the Solaris Linker and Libraries Guide is not in any way Sun specific,
> but actually still in the current version of the `ELF Handling for
> Thread-Local Storage' specification:
>
>        http://people.redhat.com/drepper/tls.pdf
>
> So, unless there's an updated specification somewhere, the fix might be
> applied more generally (which currently already happens; there's no
> TARGET_SUN_TLS predicate anywhere), even though GNU ld can handle the
> alternative code sequences produced by GCC just fine.
>

What is the TLS problem on Linux? Do you have a testcase? Unless
there is a testcase, I prefer you not to change TLS for Linux.

Thanks.


-- 
H.J.