On Mar 30, 2011, at 9:05 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> MEM_REFs which can represent type punning on lhs don't force
> non-gimple types to be addressable. This causes various problems
> in the expander, which wasn't prepared to handle that.
>
> This patch tries to fix what I've found and adds a bunch of
> testcases. The original report was with just -O2 on some large testcase
> from Eigen, most of the testcases have -fno-tree-sra just because
> I've given up on delta when it stopped reducing at 32KB.
>
> The first problem (the one from Eigen) is _mm_store_pd into
> a std::complex<double> var, which is a single field and thus
> has DCmode TYPE_MODE. As starting with 4.6 that var is not
> TREE_ADDRESSABLE, its DECL_RTL is a CONCAT, and for assignments
> to concat expand_assignment was expecting either that
> from has COMPLEX_TYPE (and matching mode to the store), or
> that it is a real or imaginary subpart store, thus when
> trying to store a V2DF mode value it expected it to be
> real part store (bitpos == 0) and tried to set a DFmode pseudo
> from V2DFmode rtx.
> Further testing revealed that it is possible to hit many other
> cases with CONCAT destination, it can be a store of just a few bits,
> or can overlap parts of both real and imaginary, or be partially
> out of bounds.
> The patch handles the case from Eigen - bitpos == 0 bitsize ==
> GET_MODE_BITSIZE (GET_MODE (to_rtx)) non-COMPLEX_TYPE by setting
> each half separately, if it is a store which is not touching
> one of the parts by just adjusting bitpos for the imaginary
> case and storing just to one of the parts (this is
> the bitpos + bitsize < half_bitsize resp. bitpos >= half_bitsize
> case) and finally adds a generic slow one for the very unusual
> cases with partial overlap of both.
>
> After testing it with the testcases I wrote, I found a bunch of
> other ICEs though, and reproduced them even without CONCAT
> on the LHS (the testcases below which don't contain any _Complex
> keyword).
> --- gcc/testsuite/gcc.dg/pr48335-2.c.jj 2011-03-30 10:57:29.000000000
> +0200
> +++ gcc/testsuite/gcc.dg/pr48335-2.c 2011-03-29 18:27:53.000000000 +0200
> @@ -0,0 +1,58 @@
> +/* PR middle-end/48335 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fno-tree-sra" } */
> +
> +typedef long long T __attribute__((may_alias, aligned (1)));
> +typedef short U __attribute__((may_alias, aligned (1)));
> +
> +struct S
> +{
> + _Complex float d __attribute__((aligned (8)));
> +};
> +
> +void bar (struct S);
> +
> +void
> +f1 (T x)
> +{
> + struct S s;
> + *(T *) ((char *) &s.d + 1) = x;
> + __real__ s.d *= 7.0;
> + bar (s);
> +}
> +
> +void
> +f2 (int x)
> +{
> + struct S s = { .d = 0.0f };
> + ((U *)((char *) &s.d + 1))[0] = x;
> + __real__ s.d *= 7.0;
> + bar (s);
> +}
> +
> +void
> +f3 (int x)
> +{
> + struct S s = { .d = 0.0f };
> + ((U *)((char *) &s.d + 1))[1] = x;
> + __real__ s.d *= 7.0;
> + bar (s);
> +}
> +
> +void
> +f4 (int x)
> +{
> + struct S s = { .d = 0.0f };
> + ((U *)((char *) &s.d + 1))[2] = x;
> + __real__ s.d *= 7.0;
> + bar (s);
> +}
> +
> +void
> +f5 (int x)
> +{
> + struct S s = { .d = 0.0f };
> + ((U *)((char *) &s.d + 1))[3] = x;
> + __real__ s.d *= 7.0;
> + bar (s);
> +}
So, this test case writes outside the bounds of s. I think it is a nice test
case for a missed diagnostic of some form, but for code that is supposed to
compile, kinda hate it.
Thoughts?
