http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50310
--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-07 08:25:44 UTC --- (In reply to comment #1) > While this exact testcase is a recent regression, caused by > http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178480 > > double s1[4], s2[4], s3[4]; > > void > foo (void) > { > int i; > for (i = 0; i < 4; i++) > s3[i] = !__builtin_isunordered (s1[i], s2[i]) && s1[i] != s2[i] ? -1.0 : > 0.0; > } > > ICEd for some time already (e.g. with -O3 -mavx or on powerpc64 with -O3 > -mvsx). > The problem is that vcond isn't supported for all possible conditions (LTGT in > this case) on all targets, the sse.md pattern just ICEs if the expanding > routine fails, on powerpc64 it ICEs in the middle end because it FAILed. So, > to fix this either vcond conditions would need to test for the unsupported > condition codes and the vectorizer would need to use the condition, or all > targets that provide vcond* patterns would need to support all possible > condition codes. We could for now strip the number of supported comparison codes down and remove the irregular ones, giving expand_vec_cond_expr_p a comparison code argument. Or split the vcond<mode><mode> pattern into different ones for each comparison code (ugh).
