public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: bjh21@netbsd.org
To: gcc-gnats@gcc.gnu.org
Subject: optimization/4733: Incorrect code when aliasing double and struct on ARM -O2
Date: Mon, 29 Oct 2001 09:26:00 -0000	[thread overview]
Message-ID: <E15yG0g-00054n-00@wraith.csi.cam.ac.uk> (raw)

>Number:         4733
>Category:       optimization
>Synopsis:       Incorrect code when aliasing double and struct on ARM -O2
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 29 09:26:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Ben Harris
>Release:        3.1 20011023 (experimental)
>Organization:
The NetBSD Project
>Environment:
System: Linux wraith 2.4.12 #13 Mon Oct 29 11:21:47 GMT 2001 i686 unknown
Architecture: i686

host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: arm-unknown-elf
configured with: ./configure --target=arm-unknown-elf
>Description:
Compiling the code below with -O2 generates, at the start of the function:

        sub     sp, sp, #8
        mov     r2, #2032
        ldrh    r3, [sp, #6]    @ movhi
        add     r2, r2, #15
        and     r3, r2, r3, lsr #4
        cmp     r3, r2
        stmia   sp, {r0-r1}

As far as I can see, this allocates eight bytes of stack, loads from
it (ldrh), messes around a bit and then stores the value it was
expecting to load (stmia).  Obviously the stmia shouldn't have been
moved to after the ldrh.  This problem also exists in GCC 3.0.1 and
the NetBSD version of GCC 2.95.3 (where I first found it).

>How-To-Repeat:
use "./cc1 -O2"

typedef	unsigned int	u_int;
struct ieee_double {
	u_int	dbl_fracl;
	u_int	dbl_frach:20;
	u_int	dbl_exp:11;
	u_int	dbl_sign:1;
};
int
isinf (d)
	double d;
{
	register struct ieee_double *p = (struct ieee_double *)(void *)&d;

	return (p->dbl_exp == 2047  &&
	    (p->dbl_frach == 0 && p->dbl_fracl == 0));
}

>Fix:

-fno-schedule-insns -fno-schedule-insns2 causes the problem to go away.
>Release-Note:
>Audit-Trail:
>Unformatted:


             reply	other threads:[~2001-10-29  9:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-29  9:26 bjh21 [this message]
2001-10-29  9:56 Richard Earnshaw
2001-10-29 10:16 Ben Harris
2002-02-04 13:29 toon

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=E15yG0g-00054n-00@wraith.csi.cam.ac.uk \
    --to=bjh21@netbsd.org \
    --cc=gcc-gnats@gcc.gnu.org \
    /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: link
Be 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).