On Mon, May 12, 2014 at 7:38 PM, Wei Mi w...@google.com 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 w...@google.com 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
r...@cebitec.uni-bielefeld.de wrote:
Wei Mi w...@google.com writes:
Thanks for trying the testcase. rtl scanning will be slightly better
than assembly scanning. So how about this one?
This one works
Wei Mi w...@google.com 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,
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
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
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).
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?
On Thu, May 8, 2014 at 12:59 AM, Wei Mi w...@google.com 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
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
On Thu, May 1, 2014 at 6:42 AM, Wei Mi w...@google.com 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
On Wed, Apr 30, 2014 at 11:44 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, May 1, 2014 at 6:42 AM, Wei Mi w...@google.com 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
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
On Wed, Mar 12, 2014 at 10:52 PM, Wei Mi w...@google.com 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.
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/
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,@progbits
.LCOLDB0:
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 the
On Thu, Mar 13, 2014 at 10:55 AM, Wei Mi w...@google.com 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
On Fri, Mar 7, 2014 at 2:33 PM, Wei Mi w...@google.com 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 hjl.to...@gmail.com wrote:
On Fri, Mar 7, 2014 at 1:26 PM, Wei Mi w...@google.com wrote:
Hi,
This patch is to fix
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 patch
On Wed, Mar 12, 2014 at 2:03 PM, Wei Mi w...@google.com 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
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
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?
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
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 } } } } */
+/* {
On Wed, Mar 12, 2014 at 2:58 PM, Wei Mi w...@google.com 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
On Wed, Mar 12, 2014 at 3:07 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Mar 12, 2014 at 2:58 PM, Wei Mi w...@google.com 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,
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 5:28 PM, Wei Mi w...@google.com 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
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
Regression test is ok.
Thanks,
Wei.
On Fri, Mar 7, 2014 at 1:26 PM, Wei Mi w...@google.com 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
On Fri, Mar 7, 2014 at 1:26 PM, Wei Mi w...@google.com 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_mode and
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 hjl.to...@gmail.com wrote:
On Fri, Mar 7, 2014 at 1:26 PM, Wei Mi w...@google.com wrote:
Hi,
This patch is to fix the problem described here:
34 matches
Mail list logo
