From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 5FCE33858436; Mon, 28 Nov 2022 13:57:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5FCE33858436
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1669643823;
	bh=rb8FdU6PduQmTW4jC4LuQrm38rcQkghKfLejAiLjUrM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=lP1WCEYOPyJHRe10Qh6u53uYbEtaUYX/kOWsdxdxdVcK8a8hYrAYdIvKM+R8bPjaC
	 87szNAKmLRJ34nqSxCDSOOSP9jgrSOJXj7f6fL7QgJHzFo4fOJw/TSDsP2X/O378fo
	 SUauogFNI3j4zT3pb/anZPcaBw9VZUL5re6BVkFA=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite
 fails on FPU arithmetics
Date: Mon, 28 Nov 2022 13:57:02 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107879-4-hIXcTrcAdD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107879-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107879-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is the foperator_mult::op{1,2}_range and can be seen even on:
double
foo (double x, double y)
{
  double z =3D x * y;
  if (z =3D=3D 0.0)
    return x;
  return 42.0;
}
testcase.
2->3  (T) x_2(D) :      [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
2->3  (T) y_3(D) :      [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
2->3  (T) z_4 :         [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
On the true edge of z =3D=3D 0.0, we have [-0., 0.] range for z_4, that is =
correct,
but getting from lhs [-0., 0.] and op2 range VARYING to [-0., 0.] is wrong.
We get that because we compute the range in that case as [-0., 0.] / VARYIN=
G,
and for division it is actually correct, [-0., 0.] divided by anything non-=
NAN
non-zero is still [-0., 0.], and [-0., 0.] divided by [-0., 0.] is NAN.
Plus we have the (IMHO still correct) implication that if a result is not N=
AN,
then neither operand could be NAN.

So I'm afraid back to the drawing board on when we can use division for
multiplication reverse ranges and when we can use multiplication for divisi=
on
reverse ranges (and whether it is ok to use minus/plus for plus/minus rever=
se
operations).=