Jakub Jelinek wrote:
On Wed, Jan 07, 2009 at 11:38:55AM +0100, Paolo Bonzini wrote:
Which version of gcc did you use? gcc 4.1 (maybe and 4.2) will report
error. But gcc 4.3 compiles OK. I tested using x86_64 native gcc from
Debian unstable. __emutls_get_address is defined in libgcc even the
tar
On Wed, Jan 07, 2009 at 11:38:55AM +0100, Paolo Bonzini wrote:
>
> > Which version of gcc did you use? gcc 4.1 (maybe and 4.2) will report
> > error. But gcc 4.3 compiles OK. I tested using x86_64 native gcc from
> > Debian unstable. __emutls_get_address is defined in libgcc even the
> > target h
> Which version of gcc did you use? gcc 4.1 (maybe and 4.2) will report
> error. But gcc 4.3 compiles OK. I tested using x86_64 native gcc from
> Debian unstable. __emutls_get_address is defined in libgcc even the
> target has real TLS.
Uff... not my day. I used 4.2 (emutls was posted in 4.2 ti
Hi Paolo,
Paolo Bonzini wrote:
Both are same.
Ah, I see, the call is optimized out because __emutls_get_address is
const. You can try
__thread int a;
int main () {
return *(int *)__emutls_get_address ((void *)0) == a;
}
I don't have an emutls target at hand, but it does fail on Li
> Both are same.
Ah, I see, the call is optimized out because __emutls_get_address is
const. You can try
__thread int a;
int main () {
return *(int *)__emutls_get_address ((void *)0) == a;
}
I don't have an emutls target at hand, but it does fail on Linux.
Paolo
Hi Paolo,
Thanks for your review!
Paolo Bonzini wrote:
+AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
+ [if grep __emutls_get_address conftest.$ac_objext
>/dev/null ; then
grepping in a binary file is not portable. If this works it would be
> +AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
> + [if grep __emutls_get_address conftest.$ac_objext
> >/dev/null ; then
grepping in a binary file is not portable. If this works it would be
better:
AC_COMPILE_IFELSE([[__thread int a; int b;
ext
On Tue, Jan 06, 2009 at 01:12:08AM +0800, Jie Zhang wrote:
> >[...] Other alternatives would include having
> >emutls define something in addition to HAVE_TLS that activates the
> >!HAVE_TLS implementation in libmudflap/mf-hooks3.c.
>
> Thanks for your help! How about the attached patch, which fo
Hi Frank,
Frank Ch. Eigler wrote:
Jie Zhang writes:
To break the recursive loop, one solution is to force emutls to call
the real calloc. [...]
If it were acceptable to change emutls on account of mudflap, this
sort of thing could work. Other alternatives would include having
emutls define
Jie Zhang writes:
> I encountered a recursive call problem between libmudflap and emutls
> when testing libmudflap for Blackfin. But I think this issue affects
> all targets without TLS.
Thank you for the report.
> One libmudflap test case in the testsuite calls __wrap_calloc. In
> __wrap_callo
10 matches
Mail list logo
