[Bug target/96373] New: SVE miscompilation on vectorized division loop, leading to FP exception

[Bug target/96373] New: SVE miscompilation on vectorized division loop, leading to FP exception

[matz at gcc dot gnu.org]

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

            Bug ID: 96373
           Summary: SVE miscompilation on vectorized division loop,
                    leading to FP exception
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: matz at gcc dot gnu.org
  Target Milestone: ---

I believe gcc-10 miscompiles the following program when SVE and vectorization
are enabled.  You need glibc to show this, or a different way to enable traps
on floating point exceptions:

% cat x.c
#define _GNU_SOURCE
#include <fenv.h>
void __attribute__((noinline, noclone)) div (double *d, double *s, int n)
{
  for (;n; n--, d++, s++)
    *d = *d / *s;
}

extern int printf(const char*, ...);

int main()
{
  int i;
  double d[] = {1,2,3,4,5,6,7,8,9,10,11};
  double s[] = {11,10,9,8,7,6,5,4,3,2,1};
  //fesetenv(FE_NOMASK_ENV);
  feenableexcept(FE_DIVBYZERO|FE_INVALID);
  div(d, s, 11);
  for (i = 0; i < 11; i++)
    printf(" %f", d[i]);
  printf("\n");
  return 0;
}

% gcc-10 --version
gcc-10 (SUSE Linux) 10.2.1 20200723 [revision
677b80db41f5345b32ce18cd000e45ea39b80d8f]

% gcc-10 -g -march=armv8.2-a -O2 -ftree-vectorize x.c -lm && ./a.out
 0.090909 0.200000 0.333333 0.500000 0.714286 1.000000 1.400000 2.000000
3.000000 5.000000 11.000000

% gcc-10 -g -march=armv8.2-a+sve -O2 -ftree-vectorize  x.c -lm && ./a.out 
Floating point exception (core dumped)

I think the code speaks for itself, excerpt from div():

        whilelo p0.d, wzr, w2
        ptrue   p1.b, all
        .p2align 3,,7
.L4:
        ld1d    z0.d, p0/z, [x0, x3, lsl 3]
        ld1d    z1.d, p0/z, [x1, x3, lsl 3]
        fdiv    z0.d, p1/m, z0.d, z1.d
        st1d    z0.d, p0, [x0, x3, lsl 3]
        incd    x3
        whilelo p0.d, w3, w2
        b.any   .L4

So, it enables all lanes in p1, while the active lanes in the loop are tracked
in p0.  In particular non-active lanes from the load are zeroed.  The
division uses p1 and hence divides all lanes, including those that were zeroed.

Indeed that's what happens when the exception is thrown:

% gdb ./a.out
...
Program received signal SIGFPE, Arithmetic exception.
(gdb) x/i $pc
=> 0x400848 <div+56>:   fdiv    z0.d, p1/m, z0.d, z1.d
(gdb) p $p1
$1 = {255, 255, 255, 255, 255, 255, 255, 255}
(gdb) p $z1.d.f
$2 = {3, 2, 1, 0, 0, 0, 0, 0}

When traps aren't enabled (the default is disabled) then these zero divisions
simply lead to NaNs in the respective lanes, and as in further instructions
the p0 predicate is used that's of no issue as those are ignored then.

But if traps are enabled this leads to an incorrect FPE trap.

The same behaviour occurs already with gcc-9.  I haven't tested master.

We noticed this within OpenFOAM on SVE capable hardware, but divisions in
vectorizable contexts should occur reasonably often for this to be a serious
problem.  (traps on exceptions aren't enabled very often, though, so this
bug will be hidden often).

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2020-08-04
     Ever confirmed|0                           |1

--- Comment #1 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
I could have sworn there was a reason why we didn't do this,
on the basis that we already failed to take FP exceptions into
account when vectorising normal gassigns.  But I can't remember
what the reason was now, or find any notes about it. :-(

Anyway, we have all the infrastructure to do it, so it should
be easy to fix.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to rsandifo@gcc.gnu.org from comment #1)
> I could have sworn there was a reason why we didn't do this,
> on the basis that we already failed to take FP exceptions into
> account when vectorising normal gassigns.  But I can't remember
> what the reason was now, or find any notes about it. :-(

Well, we refuse to if-convert a stmt that can possibly trap.
whilelo is like "if-conversion" here.  Not sure what's the reason
to ever excempt stmts from the while mask.

> Anyway, we have all the infrastructure to do it, so it should
> be easy to fix.

So for if-conversion it is

  if ((! gimple_vuse (stmt)
       || gimple_could_trap_p_1 (stmt, false, false)
       || ! ifcvt_memrefs_wont_trap (stmt, refs))
      && gimple_could_trap_p (stmt))
    {
      if (ifcvt_can_predicate (stmt))
        {
          gimple_set_plf (stmt, GF_PLF_2, true);
          need_to_predicate = true;
          return true;

which means for non-memory gimple_could_trap_p (stmt) - sth you can
easily check I guess.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[matz at gcc dot gnu.org]

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

--- Comment #3 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> which means for non-memory gimple_could_trap_p (stmt) - sth you can
> easily check I guess.

Just note that _all_ floating point operations, not just divisions, can trap
(without fast-math).  You never know if the user enabled stops for any of the
FP exceptions (overflow, underflow, inexact, invalid op, div-by-zero).  So, on
SVE that means all FP operations need to use the loop mask.

(Of course enabling stops for something like inexact/xflow is silly, so punting
on that might be fine)

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> (In reply to rsandifo@gcc.gnu.org from comment #1)
> > I could have sworn there was a reason why we didn't do this,
> > on the basis that we already failed to take FP exceptions into
> > account when vectorising normal gassigns.  But I can't remember
> > what the reason was now, or find any notes about it. :-(
> 
> Well, we refuse to if-convert a stmt that can possibly trap.
> whilelo is like "if-conversion" here.  Not sure what's the reason
> to ever excempt stmts from the while mask.
Exempting them is mostly an optimisation.  After vectorisation
we lose the information about whether the predication is optional
or required for correctness, so we have to assume that it's
required for correctness.

> > Anyway, we have all the infrastructure to do it, so it should
> > be easy to fix.
> 
> So for if-conversion it is
> 
>   if ((! gimple_vuse (stmt)
>        || gimple_could_trap_p_1 (stmt, false, false)
>        || ! ifcvt_memrefs_wont_trap (stmt, refs))
>       && gimple_could_trap_p (stmt))
>     {
>       if (ifcvt_can_predicate (stmt))
>         {
>           gimple_set_plf (stmt, GF_PLF_2, true);
>           need_to_predicate = true;
>           return true;
> 
> which means for non-memory gimple_could_trap_p (stmt) - sth you can
> easily check I guess.
Yeah.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[schwab@linux-m68k.org]

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

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
> Just note that _all_ floating point operations, not just divisions, can trap
> (without fast-math).  You never know if the user enabled stops for any of
> the FP exceptions (overflow, underflow, inexact, invalid op, div-by-zero). 

You need #pragma STDC FENV_ACCESS ON for that, otherwise it's undefined
behaviour.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
FWIW, I think the reason I mentioned for skimping on this originally
was that we don't e.g. prevent if-conversion of:

void
foo (int *c, float *f)
{
  for (int i = 0; i < 16; ++i)
    f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i];
}

for -O2 -ftree-vectorize -fno-math-errno.  So it seemed like things
weren't very consistent.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
> 
> --- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> FWIW, I think the reason I mentioned for skimping on this originally
> was that we don't e.g. prevent if-conversion of:
> 
> void
> foo (int *c, float *f)
> {
>   for (int i = 0; i < 16; ++i)
>     f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i];
> }
> 
> for -O2 -ftree-vectorize -fno-math-errno.  So it seemed like things
> weren't very consistent.

I think that's a bug in if-conversion - gimple_could_trap_p only
says that the call instruction itself doesn't trap, it doesn't
say anything about something in the callee body.  You should need
-fno-trapping-math to get the above if-converted.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #7)
> On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
> > 
> > --- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> > FWIW, I think the reason I mentioned for skimping on this originally
> > was that we don't e.g. prevent if-conversion of:
> > 
> > void
> > foo (int *c, float *f)
> > {
> >   for (int i = 0; i < 16; ++i)
> >     f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i];
> > }
> > 
> > for -O2 -ftree-vectorize -fno-math-errno.  So it seemed like things
> > weren't very consistent.
> 
> I think that's a bug in if-conversion - gimple_could_trap_p only
> says that the call instruction itself doesn't trap, it doesn't
> say anything about something in the callee body.
When's that distinction useful in practice though?  It seems odd
that an FP x / y is seen as potentially trapping, but a function
call that wraps (or might wrap) an FP x / y isn't.

> You should need -fno-trapping-math to get the above if-converted.
Is there an existing ECF flag that we can check?  ECF_NOTHROW is
related but seems different enough not to be reliable.

And is trapping a “side effect“ for the purposes of:

/* Nonzero if this is a call to a function whose return value depends           
   solely on its arguments, has no side effects, and does not read              
   global memory.  This corresponds to TREE_READONLY for function               
   decls.  */
#define ECF_CONST                 (1 << 0)

I.e. can a function still be const (on the basis that a given
argument always produces the same result) while still trapping
for some arguments?  What about pure, where the trapping might
come from a memory dereference?

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
> 
> --- Comment #8 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #7)
> > On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
> > > 
> > > --- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> > > FWIW, I think the reason I mentioned for skimping on this originally
> > > was that we don't e.g. prevent if-conversion of:
> > > 
> > > void
> > > foo (int *c, float *f)
> > > {
> > >   for (int i = 0; i < 16; ++i)
> > >     f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i];
> > > }
> > > 
> > > for -O2 -ftree-vectorize -fno-math-errno.  So it seemed like things
> > > weren't very consistent.
> > 
> > I think that's a bug in if-conversion - gimple_could_trap_p only
> > says that the call instruction itself doesn't trap, it doesn't
> > say anything about something in the callee body.
> When's that distinction useful in practice though?  It seems odd
> that an FP x / y is seen as potentially trapping, but a function
> call that wraps (or might wrap) an FP x / y isn't.
> 
> > You should need -fno-trapping-math to get the above if-converted.
> Is there an existing ECF flag that we can check?  ECF_NOTHROW is
> related but seems different enough not to be reliable.
> 
> And is trapping a “side effect“ for the purposes of:

Yes, I think trapping would be a gimple_has_side_effects effect.

No, I don't think NOTRHOW covers this.  On GENERIC we have
TREE_THIS_NOTRAP but it's not even specified for CALL_EXPR.

> /* Nonzero if this is a call to a function whose return value depends           
>    solely on its arguments, has no side effects, and does not read              
>    global memory.  This corresponds to TREE_READONLY for function               
>    decls.  */
> #define ECF_CONST                 (1 << 0)
> 
> I.e. can a function still be const (on the basis that a given
> argument always produces the same result) while still trapping
> for some arguments?  What about pure, where the trapping might
> come from a memory dereference?

How do we represent sNaNs with -fnon-call-exceptions?  That is,

 y_1 = x_2 + 1.;

may trap.  Does

 foo (x_2);

get transformed to

 tem_3 = x_2;
 foo (tem_3);

and the SSA assignment now traps dependent on whether the call
ABI requires pushing x_2 to a stack slot (which might trap)?

sNaNs are odd anyway I guess.

But yes, a pure function can still trap (and also throw).

I think we don't have a good notion for trappingness of calls
and I do expect inconsistencies here.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[matz at gcc dot gnu.org]

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

--- Comment #10 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #5)
> > Just note that _all_ floating point operations, not just divisions, can trap
> > (without fast-math).  You never know if the user enabled stops for any of
> > the FP exceptions (overflow, underflow, inexact, invalid op, div-by-zero). 
> 
> You need #pragma STDC FENV_ACCESS ON for that, otherwise it's undefined
> behaviour.

Sure, that's for operations that occur due to normal abstract machine
evaluations.  The point here is that we introduce operations that aren't in the
original
program (for the testcase on "array elements" after [10]), and if we do so
those
must be unobservable.  These pragmas don't give license to introduce additional
faults that can't possibly have happened in the abstract machine.  (To see
this, replace all arrays elements by 1.0, then the FP operations are all exact,
we still get SIGFPE).

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[matz at gcc dot gnu.org]

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

--- Comment #11 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #9)
> How do we represent sNaNs with -fnon-call-exceptions?  That is,

I think we're currently simply buggy at various stages as soon as sNaNs are
involved _and_ STDC FENV_ACCESS is ON.

>  y_1 = x_2 + 1.;
> 
> may trap.  Does
> 
>  foo (x_2);
> 
> get transformed to
> 
>  tem_3 = x_2;
>  foo (tem_3);
> 
> and the SSA assignment now traps dependent on whether the call
> ABI requires pushing x_2 to a stack slot (which might trap)?

If copying a sNaN (to registers or memory) signals an invalid-op depends on the
CPU (and is implementation defined in ieee754).  And GCC doesn't necessarily
preserve such signals even on CPUs that do signal (if there are any), because
it could e.g. use integer stores to transfer the bit patterns.

> sNaNs are odd anyway I guess.

> But yes, a pure function can still trap (and also throw).
> 
> I think we don't have a good notion for trappingness of calls
> and I do expect inconsistencies here.

__builtin_sqrtf isn't an arbitrary call.  FP operations aren't arbitrary
expressions.

We don't really have the problem of generating calls to arbitrary
arguments out of the blue, not even with non-throwing calls.  I'm not sure if
we should mix this problem here with that more generic problem.

Btw, that we if-convert calls to builtinf_sqrt is indeed a bug without
special options giving a license for that.  But doing that for the original
testcase instead of the division would _not_ be a problem on SVE: the inactive
lanes are zeroed and that doesn't signal anything for square root.

(We could perhaps extend the meaning of -fno-math-errno to give this license,
i.e. guarantee that the user hasn't enabled stops for any FP exceptions; but
that might be too aggressive).

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |evatux at gmail dot com

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 108378 has been marked as a duplicate of this bug. ***

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---

  vect__1.9_40 = .MASK_LOAD (_13, 64B, loop_mask_39);
  _15 = &MEM <vector([2,2]) double> [(double *)s_9(D) + ivtmp_48 * 8];
  vect__2.12_43 = .MASK_LOAD (_15, 64B, loop_mask_39);
  vect__3.13_44 = vect__1.9_40 / vect__2.12_43;
  .MASK_STORE (_13, 64B, loop_mask_39, vect__3.13_44);

The divide should have been masked using the loop_mask_39 too.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:7486fe153adaa868f36248b72f3e78d18b1b3ba1

commit r13-5458-g7486fe153adaa868f36248b72f3e78d18b1b3ba1
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Fri Jan 27 17:03:51 2023 +0000

    Add support for conditional xorsign [PR96373]

    This patch is an optimisation, but it's also a prerequisite for
    fixing PR96373 without regressing vect-xorsign_exec.c.

    Currently the vectoriser vectorises:

      for (i = 0; i < N; i++)
        r[i] = a[i] * __builtin_copysignf (1.0f, b[i]);

    as two unconditional operations (copysign and mult).
    tree-ssa-math-opts.cc later combines them into an "xorsign" function.
    This works for both Advanced SIMD and SVE.

    However, with the fix for PR96373, the vectoriser will instead
    generate a conditional multiplication (IFN_COND_MUL).  Something then
    needs to fold copysign & IFN_COND_MUL to the equivalent of a conditional
    xorsign.  Three obvious options were:

    (1) Extend tree-ssa-math-opts.cc.
    (2) Do the fold in match.pd.
    (3) Leave it to rtl combine.

    I'm against (3), because this isn't a target-specific optimisation.
    (1) would be possible, but would involve open-coding a lot of what
    match.pd does for us.  And, in contrast to doing the current
    tree-ssa-math-opts.cc optimisation in match.pd, there should be
    no danger of (2) happening too early.  If we have an IFN_COND_MUL
    then we're already past the stage of simplifying the original
    source code.

    There was also a choice between adding a conditional xorsign ifn
    and simply open-coding the xorsign.  The latter seems simpler,
    and means less boiler-plate for target-specific code.

    The signed_or_unsigned_type_for change is needed to make sure
    that we stay in "SVE space" when doing the optimisation on 128-bit
    fixed-length SVE.

    gcc/
            PR tree-optimization/96373
            * tree.h (sign_mask_for): Declare.
            * tree.cc (sign_mask_for): New function.
            (signed_or_unsigned_type_for): For vector types, try to use the
            related_int_vector_mode.
            * genmatch.cc (commutative_op): Handle conditional internal
functions.
            * match.pd: Fold an IFN_COND_MUL+copysign into an IFN_COND_XOR+and.

    gcc/testsuite/
            PR tree-optimization/96373
            * gcc.target/aarch64/sve/cond_xorsign_1.c: New test.
            * gcc.target/aarch64/sve/cond_xorsign_2.c: Likewise.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:4f5a1198065dc078f8099db628da7b06a2666f34

commit r13-5978-g4f5a1198065dc078f8099db628da7b06a2666f34
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Feb 13 20:03:26 2023 -0600

    rs6000/test: Adjust some test cases on partial vector [PR96373]

    As Richard pointed out in [1] and the testing on Power10, the
    proposed fix for PR96373 requires some updates on a few rs6000
    test cases which adopt partial vector.  This patch is to fix
    all of them with one extra option "-fno-trapping-math" as
    Richard suggested.

    Besides, the original test case also failed on Power10 without
    Richard's proposed fix, this patch adds it together for a bit
    better testing coverage.

    [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610728.html

            PR target/96373

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/p9-vec-length-epil-1.c: Add
-fno-trapping-math.
            * gcc.target/powerpc/p9-vec-length-epil-2.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-3.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-4.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-5.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-6.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-8.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-1.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-2.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-3.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-4.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-5.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-6.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-8.c: Likewise.
            * gcc.target/powerpc/pr96373.c: New test.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:b9c78605039f839f3c79ad8fca4f60ea9a5654ed

commit r13-5979-gb9c78605039f839f3c79ad8fca4f60ea9a5654ed
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Tue Feb 14 09:18:07 2023 +0000

    vect: Make partial trapping ops use predication [PR96373]

    PR96373 points out that a predicated SVE loop currently converts
    trapping unconditional ops into unpredicated vector ops.  Doing
    the operation on inactive lanes can then raise an exception.

    As discussed in the PR trail, we aren't 100% consistent about
    whether we preserve traps or not.  But the direction of travel
    is clearly to improve that rather than live with it.  This patch
    tries to do that for the SVE case.

    Doing this regresses gcc.target/aarch64/sve/fabd_1.c.  I've added
    -fno-trapping-math for now and filed PR108571 to track it.
    A similar problem applies to fsubr_1.c.

    I think this is likely to regress Power 10, since conditional
    operations are only available for masked loops.  I think we'll
    need to add -fno-trapping-math to any affected testcases,
    but I don't have a Power 10 system to test on.

    gcc/
            PR tree-optimization/96373
            * tree-vect-stmts.cc (vectorizable_operation): Predicate trapping
            operations on the loop mask.  Reject partial vectors if this isn't
            possible.

    gcc/testsuite/
            PR tree-optimization/96373
            PR tree-optimization/108571
            * gcc.target/aarch64/sve/fabd_1.c: Add -fno-trapping-math.
            * gcc.target/aarch64/sve/fsubr_1.c: Likewise.
            * gcc.target/aarch64/sve/fmul_1.c: Expect predicate ops.
            * gcc.target/aarch64/sve/fp_arith_1.c: Likewise.

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:cea4b90f8305df681d322315a9c30e3924e1e79d

commit r12-9206-gcea4b90f8305df681d322315a9c30e3924e1e79d
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Feb 13 20:03:26 2023 -0600

    rs6000/test: Adjust some test cases on partial vector [PR96373]

    As Richard pointed out in [1] and the testing on Power10, the
    proposed fix for PR96373 requires some updates on a few rs6000
    test cases which adopt partial vector.  This patch is to fix
    all of them with one extra option "-fno-trapping-math" as
    Richard suggested.

    Besides, the original test case also failed on Power10 without
    Richard's proposed fix, this patch adds it together for a bit
    better testing coverage.

    [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610728.html

            PR target/96373

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/p9-vec-length-epil-1.c: Add
-fno-trapping-math.
            * gcc.target/powerpc/p9-vec-length-epil-2.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-3.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-4.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-5.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-6.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-8.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-1.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-2.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-3.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-4.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-5.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-6.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-8.c: Likewise.
            * gcc.target/powerpc/pr96373.c: New test.

    (cherry picked from commit 4f5a1198065dc078f8099db628da7b06a2666f34)

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:cf3d95cce379f3260ad27264de0398e2ed1db2ea

commit r11-10549-gcf3d95cce379f3260ad27264de0398e2ed1db2ea
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Feb 13 20:03:26 2023 -0600

    rs6000/test: Adjust some test cases on partial vector [PR96373]

    As Richard pointed out in [1] and the testing on Power10, the
    proposed fix for PR96373 requires some updates on a few rs6000
    test cases which adopt partial vector.  This patch is to fix
    all of them with one extra option "-fno-trapping-math" as
    Richard suggested.

    Besides, the original test case also failed on Power10 without
    Richard's proposed fix, this patch adds it together for a bit
    better testing coverage.

    [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610728.html

            PR target/96373

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/p9-vec-length-epil-1.c: Add
-fno-trapping-math.
            * gcc.target/powerpc/p9-vec-length-epil-2.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-3.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-4.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-5.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-6.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-epil-8.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-1.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-2.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-3.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-4.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-5.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-6.c: Likewise.
            * gcc.target/powerpc/p9-vec-length-full-8.c: Likewise.
            * gcc.target/powerpc/pr96373.c: New test.

    (cherry picked from commit 4f5a1198065dc078f8099db628da7b06a2666f34)

[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:e11513c7688f583d1f4d0961d79d8aa775add03d

commit r12-9384-ge11513c7688f583d1f4d0961d79d8aa775add03d
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Mon Apr 3 09:57:09 2023 +0100

    vect: Make partial trapping ops use predication [PR96373]

    PR96373 points out that a predicated SVE loop currently converts
    trapping unconditional ops into unpredicated vector ops.  Doing
    the operation on inactive lanes can then raise an exception.

    As discussed in the PR trail, we aren't 100% consistent about
    whether we preserve traps or not.  But the direction of travel
    is clearly to improve that rather than live with it.  This patch
    tries to do that for the SVE case.

    Doing this regresses gcc.target/aarch64/sve/fabd_1.c.  I've added
    -fno-trapping-math for now and filed PR108571 to track it.
    A similar problem applies to fsubr_1.c.

    I think this is likely to regress Power 10, since conditional
    operations are only available for masked loops.  I think we'll
    need to add -fno-trapping-math to any affected testcases,
    but I don't have a Power 10 system to test on.

    gcc/
            PR tree-optimization/96373
            PR tree-optimization/108979
            * tree-vect-stmts.cc (vectorizable_operation): Predicate trapping
            operations on the loop mask.  Reject partial vectors if this isn't
            possible.  Don't mask operations on invariants.

    gcc/testsuite/
            PR tree-optimization/96373
            PR tree-optimization/108571
            PR tree-optimization/108979
            * gcc.target/aarch64/sve/fabd_1.c: Add -fno-trapping-math.
            * gcc.target/aarch64/sve/fsubr_1.c: Likewise.
            * gcc.target/aarch64/sve/fmul_1.c: Expect predicate ops.
            * gcc.target/aarch64/sve/fp_arith_1.c: Likewise.
            * gfortran.dg/vect/pr108979.f90: New test.

[Bug target/96373] [10/11 Regression] SVE miscompilation on vectorized division loop, leading to FP exception

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|---                         |11.4

[Bug target/96373] [10/11 Regression] SVE miscompilation on vectorized division loop, leading to FP exception

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.

[Bug target/96373] [11 Regression] SVE miscompilation on vectorized division loop, leading to FP exception

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kawakami.k at fujitsu dot com

--- Comment #21 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 105922 has been marked as a duplicate of this bug. ***