public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/4733: Incorrect code when aliasing double and struct on ARM -O2
@ 2001-10-29 10:16 Ben Harris
  0 siblings, 0 replies; 4+ messages in thread
From: Ben Harris @ 2001-10-29 10:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR optimization/4733; it has been noted by GNATS.

From: Ben Harris <bjh21@netbsd.org>
To: <Richard.Earnshaw@arm.com>
Cc: <gcc-gnats@gcc.gnu.org>
Subject: Re: optimization/4733: Incorrect code when aliasing double and 
 struct on ARM -O2
Date: Mon, 29 Oct 2001 18:08:14 +0000 (GMT)

 On Mon, 29 Oct 2001, Richard Earnshaw wrote:
 
 > Nope, this code violates the ANSI memory aliasing rules.
 
 Ah yes, I'd tried -fno-strict-aliasing on 2.95.3, but not on 20011023.
 Thanks.
 
 >  According to
 > ANSI, the only way to do this portably is to memcpy between the types;
 
 Yeah, that works.  The code it produces isn't all that wonderful, though:
 
 	...
         mov     r3, sp
         stmia   r3, {r0-r1}
         ldmia   r3, {r0, r1}
         add     r2, sp, #8
         stmia   r2, {r0, r1}
         mov     r2, #2032
         ldrh    r3, [sp, #14]   @ movhi
 	...
 
 -- 
 Ben Harris                                                   <bjh21@netbsd.org>
 Portmaster, NetBSD/arm26               <URL: http://www.netbsd.org/Ports/arm26/ >
 
 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: optimization/4733: Incorrect code when aliasing double and struct on ARM -O2
@ 2002-02-04 13:29 toon
  0 siblings, 0 replies; 4+ messages in thread
From: toon @ 2002-02-04 13:29 UTC (permalink / raw)
  To: bjh21, gcc-bugs, gcc-prs, nobody

Synopsis: Incorrect code when aliasing double and struct on ARM -O2

State-Changed-From-To: open->closed
State-Changed-By: toon
State-Changed-When: Mon Feb  4 13:29:02 2002
State-Changed-Why:
    User error.  The compiler is allowed to assume that the
    struct and the double aren't aliased.
    
    Use -fno-strict-aliasing if you want to compile this code
    with gcc.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4733


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: optimization/4733: Incorrect code when aliasing double and struct on ARM -O2
@ 2001-10-29  9:56 Richard Earnshaw
  0 siblings, 0 replies; 4+ messages in thread
From: Richard Earnshaw @ 2001-10-29  9:56 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR optimization/4733; it has been noted by GNATS.

From: Richard Earnshaw <rearnsha@arm.com>
To: bjh21@netbsd.org
Cc: gcc-gnats@gcc.gnu.org, Richard.Earnshaw@arm.com
Subject: Re: optimization/4733: Incorrect code when aliasing double and 
 struct on ARM -O2
Date: Mon, 29 Oct 2001 17:43:44 +0000

 > >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));
 > }
 
 Nope, this code violates the ANSI memory aliasing rules.  According to 
 ANSI, the only way to do this portably is to memcpy between the types; gcc 
 will do the right thing if you use a union, but not otherwise.
 
 R.
 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* optimization/4733: Incorrect code when aliasing double and struct on ARM -O2
@ 2001-10-29  9:26 bjh21
  0 siblings, 0 replies; 4+ messages in thread
From: bjh21 @ 2001-10-29  9:26 UTC (permalink / raw)
  To: gcc-gnats

>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:


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2002-02-04 21:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-29 10:16 optimization/4733: Incorrect code when aliasing double and struct on ARM -O2 Ben Harris
  -- strict thread matches above, loose matches on Subject: below --
2002-02-04 13:29 toon
2001-10-29  9:56 Richard Earnshaw
2001-10-29  9:26 bjh21

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).