Message ID | 20110126193731.GK2724@tyan-ft48-01.lab.bos.redhat.com |
---|---|
State | New |
Headers | show |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/11 12:37, Jakub Jelinek wrote: > Hi! > > As discussed in the PR, if a non-shareable constant is force_const_mem > and the original expression is used elsewhere in the IL (e.g. in REG_EQUAL > or REG_EQUIV note), unshare_all_rtl doesn't unshare it, but modification of > the IL might result in changes of the constant in theory and if > avoid_constant_pool_reference result is then pushed somewhere else into the > IL, we get RTL sharing errors (as on arm on this testcase). Well, one could easily argue that using the original expression in the REG_EQUAL note is incorrect as well. In fact, looking over all the calls to set_unique_reg_note shows that most either copy the value or generate a new one. I think that means we actually want both the varasm.c and the expr.c change to avoid incorrect sharing. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNQMp1AAoJEBRtltQi2kC7LW4H/2MsJOnqPuZx+vKT5+4DCBYT dwq6/4buU/Vbr3JOMHxNg+9FFKpC3s2gwl9N1JcsFPvBZw5XOgTuLZXR2KHoL4ub xhF4Of1UaDIPsVZvxJnCA905ArHbIxKVELHgitWcvyIkGcJXV9u2/XXWBy27H5Ie QvSc0ojBmEulqPnzI4r2UBlAFgKyix3OPEiZP/k8LEXAidVsezl4tB1T+kba6NtY 26Aq6mLiJ8kNQJIUjlv1I8a/pt9dMTP+Begvclro7x178caPIts+qhbucwNSHCf8 6jZbt6tm5JWUz87tzLtzC1/4rGvMuJXdpyvYUc7ul3LCe9KUNHGGxTbF359jRus= =Vzz3 -----END PGP SIGNATURE-----
On Wed, Jan 26, 2011 at 06:29:25PM -0700, Jeff Law wrote: > > As discussed in the PR, if a non-shareable constant is force_const_mem > > and the original expression is used elsewhere in the IL (e.g. in REG_EQUAL > > or REG_EQUIV note), unshare_all_rtl doesn't unshare it, but modification of > > the IL might result in changes of the constant in theory and if > > avoid_constant_pool_reference result is then pushed somewhere else into the > > IL, we get RTL sharing errors (as on arm on this testcase). > Well, one could easily argue that using the original expression in the > REG_EQUAL note is incorrect as well. In fact, looking over all the > calls to set_unique_reg_note shows that most either copy the value or > generate a new one. > > I think that means we actually want both the varasm.c and the expr.c > change to avoid incorrect sharing. I think the reason why most of the set_unique_reg_note calls copy_rtx is that the pattern is usually kept in the insn (or in some other insn). In the emit_move_insn case it specifically tests that the pattern is not there (well, some weird target could embed it in some unspec or something), the reason I changed force_const_mem was to deal with any other uses of force_const_mem. But I guess if you strongly prefer to have it in both places I can test a patch. Jakub
--- gcc/varasm.c.jj 2011-01-25 12:58:41.000000000 +0100 +++ gcc/varasm.c 2011-01-26 14:07:50.635389932 +0100 @@ -3518,7 +3518,7 @@ force_const_mem (enum machine_mode mode, pool->offset &= ~ ((align / BITS_PER_UNIT) - 1); desc->next = NULL; - desc->constant = tmp.constant; + desc->constant = copy_rtx (tmp.constant); desc->offset = pool->offset; desc->hash = hash; desc->mode = mode; --- gcc/testsuite/gcc.dg/tls/pr42894.c.jj 2011-01-26 16:29:13.765389223 +0100 +++ gcc/testsuite/gcc.dg/tls/pr42894.c 2011-01-26 16:31:46.830433380 +0100 @@ -0,0 +1,12 @@ +/* PR target/42894 */ +/* { dg-do compile } */ +/* { dg-options "-march=armv5te -mthumb" { target arm*-*-* } } */ +/* { dg-require-effective-target tls } */ + +extern __thread int t; + +void +foo (int a) +{ + t = a; +}