https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302
--- Comment #5 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Andrew Stubbs from comment #4) > Yes, that's what the simd-math-3* tests do. Ah, OK. > The simd-math-5* tests are explicitly supposed to be doing this in the > context of the autovectorizer. > > If these tests are being compiled as (newly) intended then we should change > the expected results. > > So, questions: > > 1. Are the new results actually correct? (So far I only know that being > different is expected.) I believe so. We now do the division in 32 bits, as in the original gimple. > 2. Is there some other testcase form that would exercise the previously > intended routines? It should be possible in languages that don't have C's integer promotion rules, if you're up for some Ada or Rust. > 3. Is the new behaviour configurable? I don't think the 16-bit shift bug> > ever existed on GCN (in which "short" vectors actually have excess bits in > each lane, much like scalar registers do). Not AFAIK. The problem is that the gimple→gimple transformation changes the gimple-level semantics of the code. Shifts by out-of-range values are undefined rather than target-defined. (And in other cases that's useful, because it means we don't need to preserve whatever value the target happens to give for an out-of-range shift.)
