public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: amodra@bigpond.net.au (Alan Modra)
To: Martin Rivers <rivers@lexmark.com>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: 3.3.2 mips/ppc compiler bug?
Date: Wed, 31 Dec 2003 01:08:00 -0000	[thread overview]
Message-ID: <20031230221908.GD22998@bubble.sa.bigpond.net.au> (raw)
In-Reply-To: <3FF078CD.D0B3BED8@lpdev.prtdev.lexmark.com>

On Mon, Dec 29, 2003 at 01:56:13PM -0500, Martin Rivers wrote:
> However, it seems reasonable that the generation of the value
> of y using the division approach should not result in the same value as cmdxy.

No.  Your problem is that the shift left operator for signed integers
does not have defined overflow semantics.  Thus for int x, x << n is
not necessarily truncated to an int when x << n appears in an
intermediate expression.

It so happens that gcc currently does truncate (x << n) >> n, but from
my reading of ISO/IEC 9899:1999 it would not need to, while
(x << n) / (1 << n) is not truncated.  You're relying on undefined
behaviour.

Note also that the shift right operator is also undefined on negative
signed values.  Most people don't seem to know that a shift right
may not propagate sign bits.  Unsigned values _do_ have defined
overflow semantics, so you should change your program to use unsigned
ints.  If you really need to handle negative values then sign
extend values using something like the following example for an
18 bit field:

 y = (((unsigned int) x & 0x3ffff) ^ 0x20000) - 0x20000;

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


      parent reply	other threads:[~2003-12-30 22:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-29 20:50 Martin Rivers
2003-12-30  9:58 ` Falk Hueffner
2003-12-31  1:08 ` Alan Modra [this message]

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=20031230221908.GD22998@bubble.sa.bigpond.net.au \
    --to=amodra@bigpond.net.au \
    --cc=gcc-bugs@gcc.gnu.org \
    --cc=rivers@lexmark.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: 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).