Hi! On Sat, Jan 23, 2021 at 09:41:23AM +0100, Jakub Jelinek wrote: > On Fri, Jan 22, 2021 at 06:56:37PM -0600, Segher Boessenkool wrote: > > So what is the actual error here? This whole union stuff is because we > > *do* want proper aliasing, afaics. > > The reading through union is not where the problem is, the problem > was in the reading through VALUE_TYPE, because the testcase does: > int e[4]; > ... > e[0] = (~source1[0]) & source2[0]; > e[1] = (~source1[1]) & source2[1]; > e[2] = (~source1[2]) & source2[2]; > e[3] = (~source1[3]) & source2[3]; > > if (check_union128 (u, (float *)e))
Right, that should use such a union as well, or similar. Most of the other similar mechanics in the testcase are because we *do* want proper alising rules, so it would be a shame to throw it all away now. > So check_union128 reads through VALUE_TYPE of float, but the variable > has dynamic type int[4]. Even making a e union of int[4] and float[4] > and passing address of the float field in it wouldn't be correct, > but e.g. having another variable with float[4] type and memcpying > e into it would work too. So: > int e[4]; > float f[4]; > ... > e[0] = (~source1[0]) & source2[0]; > e[1] = (~source1[1]) & source2[1]; > e[2] = (~source1[2]) & source2[2]; > e[3] = (~source1[3]) & source2[3]; > memcpy (f, e, sizeof (e)); > > if (check_union128 (u, f)) That, or have the function take a pointer-to-union, or make "e" a union itself. All should work. > The reason I chose the "no-strict-aliasing" attribute (and already > committed based on Richi's ack) was consistency with the i386 > testcase. I can change both. Yes please. Thanks! Segher