[Bug target/86731] New: [8 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[jcowgill+gcc at jcowgill dot uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

            Bug ID: 86731
           Summary: [8 Regression] Miscompiles vec_sl at -O3 with -fwrapv
                    on ppc64el
           Product: gcc
           Version: 8.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jcowgill+gcc at jcowgill dot uk
  Target Milestone: ---

FFmpeg was hit by a bug which causes strange results when the optimized altivec
routines are compiled with -O3 and -fwrapv (which is used when FFmpeg is
configured with --toolchain=hardened). This bug only occurs with GCC 8.

Simplified extract which shows the bug:

#include <altivec.h>

vector unsigned int splat(void)
{
        vector unsigned int mzero = vec_splat_u32(-1);
        return (vector unsigned int) vec_sl(mzero, mzero);
}

The goal is to create a constant vector with each element containing 0x80000000
(== -0.0f). If I am reading the altivec manual correctly, the above code is
valid because the second argument to vec_sl should interpreted modulo 32 (ie as
31 in this case).

With gcc-7 this generates this correct code:
0000000000000000 <splat>:
   0:   8c 03 5f 10     vspltisw v2,-1
   4:   84 11 42 10     vslw    v2,v2,v2
   8:   20 00 80 4e     blr

When compiled with "gcc-8 -O3 -fwrapv -c altivectest.c" this wrong code is
produced:
0000000000000000 <splat>:
   0:   8c 03 5f 10     vspltisw v2,-1
   4:   20 00 80 4e     blr

====

If I pass -fdump-tree-all, I can see that the vec_sl gets transformed into a
normal left shift. My guess (which may be wrong) is that gcc is treating this
shift as UB because it is trying to shift > 32 bits.