public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Kevin Ryde <user42@zip.com.au> To: gcc-gnats@gcc.gnu.org Cc: "Torbjörn Granlund" <tege@swox.com> Subject: optimization/9174: pentium4 double raw through union Date: Sat, 04 Jan 2003 21:26:00 -0000 [thread overview] Message-ID: <87znqg4nq6.fsf@zip.com.au> (raw) >Number: 9174 >Category: optimization >Synopsis: pentium4 double raw through union >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Sat Jan 04 13:26:00 PST 2003 >Closed-Date: >Last-Modified: >Originator: >Release: 3.2.1 >Organization: >Environment: System: FreeBSD binxxxxx.swox.se 4.6-STABLE FreeBSD 4.6-STABLE #1: Sun Sep 15 20:28:51 CEST 2002 tege@king.swox.se:/media/u/FreeBSD/RELENG_4/src/sys/compile/CLIENT i386 <machine, os, target, libraries (multiple lines)> host: i386-unknown-freebsd4.6 build: i386-unknown-freebsd4.6 target: i386-unknown-freebsd4.6 configured with: /u/gcc/gcc-3.2.1/configure --enable-languages=c,c++ >Description: Using a union to access the raw bytes of a double returns an incorrect part of the double when compiled with -O and -march=pentium4. >How-To-Repeat: The file foo.c below, compiled and run gcc -O -march=pentium4 foo.c ./a.out produces want 419D6F34 got 54000000 Whereas I believe the "want" value is correct and the "got" ought to be the same, which it is if compiled either without -O or without -march=pentium4. The program attempts to do a raw read of the high 32-bits of a double using an array of two "unsigned"s. The code seems to come out as fstpl -8(%ebp) movsd -8(%ebp), %xmm1 movd %xmm1, %eax I think movd here is incorrect. It ignores the "[1]" index on the u.s access, and instead returns the low half of the double. For what it's worth, this seems to occur the same when using a bitfield to access part of the double, which is how I struck it in some code that's part of the GMP MPFR library. Also for what it's worth, the test "d != 0" seems necessary to induce gcc to load the double onto the x87 stack then send it to an integer register. Incidentally, movsd+movd is not efficient, no doubt a plain movl could load from memory straight to eax. And the fstpl is unnecessary too, since the value in question is still in the parameters on the stack, and could be read direct from there into eax. Though perhaps it's a bit tricky to "see through" a union back to the original operand for a raw access. --=-=-= Content-Type: text/x-csrc Content-Disposition: attachment; filename=foo.c union dbl { double d; unsigned s[2]; }; unsigned foo (double d) { union dbl u; if (d != 0) { u.d = d; return u.s[1]; } else return 0; } int main (void) { double d = 123456789.0; union dbl u; u.d = d; printf ("want %X\n", u.s[1]); printf ("got %X\n", foo (d)); return 0; } --=-=-=-- >Fix: >Release-Note: >Audit-Trail: >Unformatted: --=-=-=
next reply other threads:[~2003-01-04 21:26 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-01-04 21:26 Kevin Ryde [this message] 2003-03-26 10:00 optimization/9174: [Pentium4] " ebotcazou
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87znqg4nq6.fsf@zip.com.au \ --to=user42@zip.com.au \ --cc=gcc-gnats@gcc.gnu.org \ --cc=tege@swox.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).