https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83332
--- Comment #2 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Possibly a similar reason as x86, vect_cond_mixed is set but you cannot do
> V2DIV2DF mixed condition handling?
That appears to be the case:
proc check_effective_target_vect_cond_mixed { } {
global et_vect_cond_mixed_saved
global et_index
if [info exists et_vect_cond_mixed_saved($et_index)] {
verbose "check_effective_target_vect_cond_mixed: using cached result" 2
} else {
set et_vect_cond_mixed_saved($et_index) 0
if { [istarget i?86-*-*] || [istarget x86_64-*-*]
|| [istarget aarch64*-*-*]
|| [istarget powerpc*-*-*]
|| ([istarget mips*-*-*]
&& [et-is-effective-target mips_msa])
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vx]) } {
set et_vect_cond_mixed_saved($et_index) 1
}
}
but so far as I can tell the PPC back end does not have any vcond<m1><m2>
patterns where m1 != m2.
So is the target-supports check a total lie, so that we should remove the
powerpc*-*-* clause there? That's what the documentation would seem to imply.
