This is the updated testcase.
Thanks,
Wei.
===================================================================
--- testsuite/gcc.dg/pr58066.c (revision 0)
+++ testsuite/gcc.dg/pr58066.c (revision 0)
@@ -0,0 +1,18 @@
+/* { dg-do compile { target {{ i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
+/* { dg-options "-fPIC -O2" } */
+
+/* Check whether the stack frame starting addresses of tls expanded calls
+ in foo and goo are 16bytes aligned. */
+static __thread char ccc1;
+void* foo()
+{
+ return &ccc1;
+}
+
+__thread char ccc2;
+void* goo()
+{
+ return &ccc2;
+}
+
+/* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 16" 2 } } */
On Wed, Mar 12, 2014 at 2:51 PM, Wei Mi <w...@google.com> wrote:
> Oh, I see. Thanks!
>
> Wei.
>
> On Wed, Mar 12, 2014 at 2:42 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>> On Wed, Mar 12, 2014 at 2:36 PM, Wei Mi <w...@google.com> wrote:
>>> Hi H.J.,
>>>
>>> Could you show me why you postpone the setting
>>> ix86_tls_descriptor_calls_expanded_in_cfun until reload_complete and
>>> use ix86_tls_descriptor_calls_expanded_in_cfun instead of
>>> ix86_current_function_calls_tls_descriptor? Isn't
>>> ix86_current_function_calls_tls_descriptor useful to consider the case
>>> that tls call is optimized away?
>>>
>>
>> When a tls call is optimized away, it won't survive reload.
>> If it does survive reload, it isn't optimized away. Also
>> checking df_regs_ever_live_p (SP_REG) isn't reliable
>> when called from ix86_compute_frame_layout.
>>
>> --
>> H.J.
