On Mon, May 12, 2014 at 7:38 PM, Wei Mi wrote:
>>> Here is a patch for the test. It contains two changes:
>>> 1. For emutls, there will be an explicit call generated at expand
>>> pass, and no stack adjustment is needed. So add /* {
>>> dg-require-effective-target tls_native } */ in the test.
>>>
Wei Mi writes:
> Can I checkin this testcase fix?
I think this is for Uros to approve.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Can I checkin this testcase fix?
Thanks,
Wei.
On Tue, May 13, 2014 at 1:39 AM, Rainer Orth
wrote:
> Wei Mi writes:
>
>> Thanks for trying the testcase. rtl scanning will be slightly better
>> than assembly scanning. So how about this one?
>
> This one works fine for me.
>
> Thanks.
> R
Wei Mi writes:
> Thanks for trying the testcase. rtl scanning will be slightly better
> than assembly scanning. So how about this one?
This one works fine for me.
Thanks.
Rainer
--
-
Rainer Orth, Center for Bi
>> Here is a patch for the test. It contains two changes:
>> 1. For emutls, there will be an explicit call generated at expand
>> pass, and no stack adjustment is needed. So add /* {
>> dg-require-effective-target tls_native } */ in the test.
>> 2. Replace cfi_def_cfa_offset with insn sequence chec
Hi Wei,
please teach your mailer not to break/mangle long lines. Thanks.
> Here is a patch for the test. It contains two changes:
> 1. For emutls, there will be an explicit call generated at expand
> pass, and no stack adjustment is needed. So add /* {
> dg-require-effective-target tls_native }
Here is a patch for the test. It contains two changes:
1. For emutls, there will be an explicit call generated at expand
pass, and no stack adjustment is needed. So add /* {
dg-require-effective-target tls_native } */ in the test.
2. Replace cfi_def_cfa_offset with insn sequence check.
Is it ok?
domi...@lps.ens.fr (Dominique Dhumieres) writes:
>> This is the updated patch of pr58066-3.patch. ...
>
> On x86_64-apple-darwin13 I get
>
> FAIL: gcc.target/i386/pr58066.c scan-assembler-times .cfi_def_cfa_offset 16 2
Same on i386-pc-solaris2.* with Sun as (which doesn't support cfi
directives).
> This is the updated patch of pr58066-3.patch. ...
On x86_64-apple-darwin13 I get
FAIL: gcc.target/i386/pr58066.c scan-assembler-times .cfi_def_cfa_offset 16 2
Dominique
On Thu, May 8, 2014 at 12:59 AM, Wei Mi wrote:
> The calls added in the templates of tls_local_dynamic_base_32 and
> tls_global_dynamic_32 in pr58066-3.patch are used to prevent sched2
> from moving sp setting across implicit tls calls, but those calls make
> the combine of UNSPEC_TLS_LD_BASE and
This is the updated patch of pr58066-3.patch.
The calls added in the templates of tls_local_dynamic_base_32 and
tls_global_dynamic_32 in pr58066-3.patch are used to prevent sched2
from moving sp setting across implicit tls calls, but those calls make
the combine of UNSPEC_TLS_LD_BASE and UNSPEC_DT
On Wed, Apr 30, 2014 at 11:44 PM, Uros Bizjak wrote:
> On Thu, May 1, 2014 at 6:42 AM, Wei Mi wrote:
>> Ping. Is pr58066-3.patch or pr58066-4.patch ok for trunk?
>
> None of these patches have correct ChangeLog entries. Please follow
> the rules, outlined in http://gcc.gnu.org/contribute.html (Su
On Thu, May 1, 2014 at 6:42 AM, Wei Mi wrote:
> Ping. Is pr58066-3.patch or pr58066-4.patch ok for trunk?
None of these patches have correct ChangeLog entries. Please follow
the rules, outlined in http://gcc.gnu.org/contribute.html (Submitting
Patches section), otherwise your patches will be simp
Ping. Is pr58066-3.patch or pr58066-4.patch ok for trunk?
Thanks,
Wei.
>> I attached the patch which combined your two patches and the fix in
>> legitimize_tls_address. I tried pr58066.c and c.i in ia32/x32/x86_64,
>> the code looked fine. Do you think it is ok?
>>
>> Thanks,
>> Wei.
>
> Either p
On Thu, Mar 13, 2014 at 10:55 AM, Wei Mi wrote:
>> Can we combine the last two patches, both adding call explicitly in
>> rtl template for tls_local_dynamic_base_32/tls_global_dynamic_32, and
>> set ix86_tls_descriptor_calls_expanded_in_cfun to true only after
>> reload complete?
>>
>
> Hi H.J.
>
> Can we combine the last two patches, both adding call explicitly in
> rtl template for tls_local_dynamic_base_32/tls_global_dynamic_32, and
> set ix86_tls_descriptor_calls_expanded_in_cfun to true only after
> reload complete?
>
Hi H.J.
I attached the patch which combined your two patches and t
> I tried pr58066-3.patch on the above testcase, the code it generated
> seems ok. I think after we change the 32bits pattern in i386.md to be
> similar as 64bits pattern, we should change 32bit expand to be similar
> as 64bit expand in legitimize_tls_address too?
>
> Thanks,
> Wei.
>
Sorry, I pas
>
> My ia32 change generates much worse code:
>
> [hjl@gnu-6 gcc]$ cat /tmp/c.i
> static __thread char ccc, bbb;
>
> int __cxa_get_globals()
> {
> return &ccc - &bbb;
> }
> [hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O2 -fPIC /tmp/c.i
> [hjl@gnu-6 gcc]$ cat c.s
> .file "c.i"
> .section .text.unlikely,"ax",@p
pr58066-2.patch worked for pr58066.c on ia32/x32/x86_64, but it failed
on bootstrap.
/usr/local/google/home/wmi/workarea/gcc-r208410-2/build/./gcc/xgcc
-B/usr/local/google/home/wmi/workarea/gcc-r208410-2/build/./gcc/
-B/usr/local/google/home/wmi/workarea/gcc-r208410-2/build/install/x86_64-unknown-
On Wed, Mar 12, 2014 at 10:52 PM, Wei Mi wrote:
> I saw the problem last patch had on ia32. Without explicit call in rtl
> template, scheduler may schedule the sp adjusting insn across tls
> descriptor and break the alignment assumption.
> I am testing the updated patch on x86_64.
>
> Can we combi
I saw the problem last patch had on ia32. Without explicit call in rtl
template, scheduler may schedule the sp adjusting insn across tls
descriptor and break the alignment assumption.
I am testing the updated patch on x86_64.
Can we combine the last two patches, both adding call explicitly in
rtl
On Wed, Mar 12, 2014 at 5:28 PM, Wei Mi wrote:
>>> Does my patch fix the original problem?
>>
>> Yes, it works. I am doing bootstrap and regression test for your patch.
>> Thanks!
>>
>
> The patch passes bootstrap and regression test on x86_64-linux-gnu.
>
My patch fails to handle ia32. Here is
>> Does my patch fix the original problem?
>
> Yes, it works. I am doing bootstrap and regression test for your patch.
> Thanks!
>
The patch passes bootstrap and regression test on x86_64-linux-gnu.
Thanks,
Wei.
On Wed, Mar 12, 2014 at 3:07 PM, H.J. Lu wrote:
> On Wed, Mar 12, 2014 at 2:58 PM, Wei Mi wrote:
>> This is the updated testcase.
>
> Does my patch fix the original problem?
Yes, it works. I am doing bootstrap and regression test for your patch. Thanks!
>
>> Thanks,
>> Wei.
>>
>> ==
On Wed, Mar 12, 2014 at 2:58 PM, Wei Mi wrote:
> This is the updated testcase.
Does my patch fix the original problem?
> Thanks,
> Wei.
>
> ===
> --- testsuite/gcc.dg/pr58066.c (revision 0)
> +++ testsuite/gcc.dg/pr58066.c (revision
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 } } } } */
+/*
Oh, I see. Thanks!
Wei.
On Wed, Mar 12, 2014 at 2:42 PM, H.J. Lu wrote:
> On Wed, Mar 12, 2014 at 2:36 PM, Wei Mi 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_expa
On Wed, Mar 12, 2014 at 2:36 PM, Wei Mi 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
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
On Wed, Mar 12, 2014 at 2:03 PM, Wei Mi wrote:
>> There are several problems with this:
>>
>> 1. It doesn't work with C.
>
> Ok, I will change the testcase using C.
>
>> 2. IA32 has the same issue and isn't fixed.
>
> I thought IA32 didn't have the same issue because abi only requires 32
> bit a
> There are several problems with this:
>
> 1. It doesn't work with C.
Ok, I will change the testcase using C.
> 2. IA32 has the same issue and isn't fixed.
I thought IA32 didn't have the same issue because abi only requires 32
bit alignment for stack starting address.
oh, I found the old pat
On Fri, Mar 7, 2014 at 2:33 PM, Wei Mi wrote:
> Yes, x32 has the same problem. It should be tested. Fixed.
>
> Thanks,
> Wei.
>
>
> On Fri, Mar 7, 2014 at 2:06 PM, H.J. Lu wrote:
>> On Fri, Mar 7, 2014 at 1:26 PM, Wei Mi wrote:
>>> Hi,
>>>
>>> This patch is to fix the problem described here:
>>>
Yes, x32 has the same problem. It should be tested. Fixed.
Thanks,
Wei.
On Fri, Mar 7, 2014 at 2:06 PM, H.J. Lu wrote:
> On Fri, Mar 7, 2014 at 1:26 PM, Wei Mi wrote:
>> Hi,
>>
>> This patch is to fix the problem described here:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>>
>> I foll
On Fri, Mar 7, 2014 at 1:26 PM, Wei Mi wrote:
> Hi,
>
> This patch is to fix the problem described here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>
> I follow Ian's suggestion and set
> ix86_tls_descriptor_calls_expanded_in_cfun in
> tls_global_dynamic_64_ and tls_local_dynamic_base_64_
Regression test is ok.
Thanks,
Wei.
On Fri, Mar 7, 2014 at 1:26 PM, Wei Mi wrote:
> Hi,
>
> This patch is to fix the problem described here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>
> I follow Ian's suggestion and set
> ix86_tls_descriptor_calls_expanded_in_cfun in
> tls_global_dyn
35 matches
Mail list logo
