From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZf7U-0006XG-Gv for qemu-devel@nongnu.org; Tue, 07 May 2013 06:27:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZf7P-0000PG-7v for qemu-devel@nongnu.org; Tue, 07 May 2013 06:27:40 -0400 References: <86sj20rql4.fsf@shell.gmplib.org> <5187ECAD.4050901@suse.de> <86obcorn76.fsf@shell.gmplib.org> <15FCEEAE-FE2D-44B9-9DC3-5419B29D5B16@suse.de> From: Torbjorn Granlund Sender: tg@gmplib.org Date: Tue, 07 May 2013 12:27:33 +0200 In-Reply-To: <15FCEEAE-FE2D-44B9-9DC3-5419B29D5B16@suse.de> (Alexander Graf's message of "Tue\, 7 May 2013 00\:14\:47 +0200") Message-ID: <86a9o7qe3u.fsf_-_@shell.gmplib.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [Qemu-devel] Incorrect handling of more PPC64 insns List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org --=-=-= Alexander Graf writes: There's a certain chance that happens, yes. We don't have instruction test suites for the PPC target. There certainly are more bugs. GMP still crashes all over the place. I have semi-isolated one more. Extracted stand-alone sources: --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=bug-qemu-ppc-again.c #include #include typedef unsigned long long mp_limb_t; #define GMP_LIMB_BITS 64 #define GMP_NAIL_BITS 0 #define GMP_NUMB_MAX (~(mp_limb_t) 0) #define CNST_LIMB(C) ((mp_limb_t) C##LL) #define GMP_NUMB_CEIL_MAX_DIV3 (GMP_NUMB_MAX / 3 + 1) #define SHIFTHIGH(x) ((x) << GMP_LIMB_BITS/2) #define SHIFTLOW(x) ((x) >> GMP_LIMB_BITS/2) #define LOWMASK (((mp_limb_t) 1 << GMP_LIMB_BITS/2)-1) #define HIGHMASK SHIFTHIGH(LOWMASK) #define LOWPART(x) ((x) & LOWMASK) #define HIGHPART(x) SHIFTLOW((x) & HIGHMASK) mp_limb_t foo (mp_limb_t *lo, mp_limb_t x, mp_limb_t y) { mp_limb_t hi, s; *lo = LOWPART(x) * LOWPART(y); hi = HIGHPART(x) * HIGHPART(y); s = LOWPART(x) * HIGHPART(y); hi += HIGHPART(s); s = SHIFTHIGH(LOWPART(s)); *lo += s; hi += (*lo < s); s = HIGHPART(x) * LOWPART(y); hi += HIGHPART(s); s = SHIFTHIGH(LOWPART(s)); *lo += s; hi += (*lo < s); return hi; } int main (int argc, char *argv[]) { mp_limb_t hi, lo; hi = foo (&lo, GMP_NUMB_CEIL_MAX_DIV3, CNST_LIMB(3) << GMP_NAIL_BITS); if (hi < 1) printf ("GMP_NUMB_CEIL_MAX_DIV3 too small\n"); return 0; } --=-=-= Asm code generated on gcc110 from the source file: --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=bug-qemu-ppc-again.s .file "bug-qemu-ppc-again.c" .section ".text" .align 2 .globl foo .type foo, @function foo: rldimi 6,5,32,0 rldimi 8,7,32,0 li 9,-1 rldicl 9,9,0,32 and 10,6,9 and 9,8,9 srdi 6,6,32 srdi 8,8,32 mulld 5,8,6 mulld 8,8,10 sldi 4,8,32 mulld 10,9,10 add 10,4,10 mulld 9,9,6 srdi 8,8,32 srdi 7,9,32 add 7,8,7 add 7,7,5 cmpld 7,4,10 mfcr 4 rlwinm 4,4,30,1 add 8,7,4 sldi 4,9,32 add 10,10,4 std 10,0(3) cmpld 7,4,10 mfcr 4 rlwinm 4,4,30,1 add 4,8,4 srdi 3,4,32 blr .size foo,.-foo .align 2 .globl main .type main, @function main: stwu 1,-32(1) mflr 0 stw 0,36(1) addi 3,1,8 lis 5,0x5555 ori 5,5,21845 lis 6,0x5555 ori 6,6,21846 li 7,0 li 8,3 bl foo rldimi 4,3,32,0 cmpdi 7,4,0 bne 7,.L3 lis 3,.LC0@ha la 3,.LC0@l(3) bl puts .L3: li 3,0 lwz 0,36(1) mtlr 0 addi 1,1,32 blr .size main,.-main .section .rodata.str1.8,"aMS",@progbits,1 .align 3 .LC0: .string "GMP_NUMB_CEIL_MAX_DIV3 too small" .ident "GCC: (GNU) 4.7.2 20121109 (Red Hat 4.7.2-8)" .section .note.GNU-stack,"",@progbits --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Generate executable and execute: gcc -m32 -mpowerpc64 bug-qemu-ppc-again.s && ./a.out This runs silently as it should on real hardware. Under qemu (from 2013-05-02 plus the rldcl patch) I incorrectly get the error message: GMP_NUMB_CEIL_MAX_DIV3 too small This seems reproducible every time, unlike most qemu bugs that hit GMP. I haven't isolated this bug to a single instruction, but if rldcl was untested, expecting all of there here used rldicl rldimi rlwinm to be tested is perhaps over-optimistic? --=20 Torbj=C3=B6rn --=-=-=--