From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9F870386F82E; Wed, 29 Jul 2020 15:27:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9F870386F82E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1596036478; bh=uWxtkq+aTIY1Vhx9CRdyw1hq8KSTwX01mv/7ozaEtB4=; h=From:To:Subject:Date:From; b=c6IFvTCCcKRXPUs5O+lyAq877cgYoZYvPMvjUIa+nFEyakcLYAbjJ4514YpWUR2NN VRaPIbH3hh+Yd3h20Ml5/a4Zdha8WwBPxXFkgfs+9mttmplixoxzOZQNz1bkB/NbRn 704msmjXz1/VIR/qGdQ667m3ACIS0mY4Ivmvmf+Y= From: "matz at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/96373] New: SVE miscompilation on vectorized division loop, leading to FP exception Date: Wed, 29 Jul 2020 15:27:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: matz at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 15:27:58 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96373 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 vectorizati= on are enabled. You need glibc to show this, or a different way to enable tra= ps on floating point exceptions: % cat x.c #define _GNU_SOURCE #include void __attribute__((noinline, noclone)) div (double *d, double *s, int n) { for (;n; n--, d++, s++) *d =3D *d / *s; } extern int printf(const char*, ...); int main() { int i; double d[] =3D {1,2,3,4,5,6,7,8,9,10,11}; double s[] =3D {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 =3D 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=3Darmv8.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=3Darmv8.2-a+sve -O2 -ftree-vectorize x.c -lm && ./a.out= =20 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 trac= ked 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 zer= oed. Indeed that's what happens when the exception is thrown: % gdb ./a.out ... Program received signal SIGFPE, Arithmetic exception. (gdb) x/i $pc =3D> 0x400848 : fdiv z0.d, p1/m, z0.d, z1.d (gdb) p $p1 $1 =3D {255, 255, 255, 255, 255, 255, 255, 255} (gdb) p $z1.d.f $2 =3D {3, 2, 1, 0, 0, 0, 0, 0} When traps aren't enabled (the default is disabled) then these zero divisio= ns 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).=