On Mon, Mar 12, 2012 at 12:58 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 7:42 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>
>>> 2012-03-12 H.J. Lu <hongjiu...@intel.com>
>>>
>>> * config/i386/i386.c (ix86_gen_tls_global_dynamic_64): New.
>>> (ix86_gen_tls_local_dynamic_base_64): Likewise.
>>> (ix86_option_override_internal): Set ix86_gen_tls_global_dynamic_64
>>> and ix86_gen_tls_local_dynamic_base_64.
>>> (legitimize_tls_address): Use ix86_gen_tls_global_dynamic_64 and
>>> ix86_gen_tls_local_dynamic_base_64.
>>>
>>> * config/i386/i386.md (*tls_global_dynamic_64): Renamed to ...
>>> (*tls_global_dynamic_64_<mode>): This.
>>> (tls_global_dynamic_64): Renamed to ...
>>> (tls_global_dynamic_64_<mode>): This.
>>> (*tls_local_dynamic_base_64): Renamed to ...
>>> (*tls_local_dynamic_base_64_<mode>): This.
>>> (tls_local_dynamic_base_64): Renamed to ...
>>> (tls_local_dynamic_base_64_<mode>): This.
>>
>> This patch caused x32 libgcc build failure:
>>
>> ../../../../src-trunk/libgcc/generic-morestack-thread.c: In function
>> 'stack_split_initialize_thread':
>> ../../../../src-trunk/libgcc/generic-morestack-thread.c:128:1: error:
>> unrecognizable insn:
>> (call_insn/u 8 7 9 3 (parallel [
>> (set (reg:DI 0 ax)
>> (call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")) [0 S1 A8])
>> (const_int 0 [0])))
>> (unspec:DI [
>> (symbol_ref:SI ("__morestack_segments") [flags
>> 0x50] <var_decl 0x7ffff7725780 __morestack_segments>)
>> ] UNSPEC_TLS_GD)
>> ]) ../../../../src-trunk/libgcc/generic-morestack-thread.c:117 -1
>> (expr_list:REG_EH_REGION (const_int -2147483648 [0xffffffff80000000])
>> (nil))
>> (nil))
>> ../../../../src-trunk/libgcc/generic-morestack-thread.c:128:1:
>> internal compiler error: in extract_insn, at recog.c:2123
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <http://gcc.gnu.org/bugs.html> for instructions.
>> make[8]: *** [generic-morestack-thread.o] Error 1
>> make[8]: *** Waiting for unfinished jobs....
>>
>> __morestack_segments is always in SImode for x32. Adding
>> :P to
>>
>> (unspec:P [(match_operand 1 "tls_symbolic_operand" "")]
>>
>> causes it to fail when Pmode == DImode I checked in this patch
>> to revert the part of that change.
>
> Please better declare tls_symbolic_operand as special predicate, as in
> attached patch.
>
That is a good idea.
Thanks.
--
H.J.
