public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Nathan Sidwell <nathan@codesourcery.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: c/7284: incorrectly simplifies leftshift followed by signed  power-of-2 division
Date: Fri, 12 Jul 2002 12:56:00 -0000	[thread overview]
Message-ID: <20020712195601.20155.qmail@sources.redhat.com> (raw)

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

From: Nathan Sidwell <nathan@codesourcery.com>
To: Al Grant <AlGrant@myrealbox.com>
Cc: nathan@cs.bris.ac.uk, falk.hueffner@student.uni-tuebingen.de,
   nathan@gcc.gnu.org, algrant@acm.org, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c/7284: incorrectly simplifies leftshift followed by signed 
 power-of-2 division
Date: Fri, 12 Jul 2002 20:45:50 +0100

 Al Grant wrote:
 > 
 > >you need to read more carefully.
 > >KnR 2 A7.8 says the same as C99,
 > 
 > You need to read more carefully.  K&R2 says something quite different from C99.  It says that in the absence of overflow, the operation is equivalent to a
 > multiplication.  It does _not_ say that if the multiplication overflows the result of the shift is undefined, let alone that program behavior is undefined.
 oops, how did I manage to misread that? A7 says that 'most existing C
 implementations ignore overflow in evaluation of signed integral
 expressions and assignemnts, but this behaviour is not guaranteed.'
 
 > >C++ says [5]/5 that if the result is not in the range >of representable values,
 > >the behaviour is undefined.
 > 
 > But left-shift is an operation on the representation, i.e. the bit pattern.
 The *implementation* of left-shift is an operation on representation.
 The abstract left shift operation applies to values.
 
 >  For signed left-shift (in C89 and C++) it is not defined any other way.
 C++ says it that the bit pattern is left shifted and vacated bit positions
 are zero filled. That we agree on. What we disagree is what happens to 
 bits 'falling off the top' (be they zero or one). I contend that if the
 exact result (which will require 32+c bits to represent), is not
 representable in 32 bits, then the behaviour is undefined (as [5]/5
 says). You contend that the result is reduced modulo 2^32. But then
 why does C++ then go on to say 'if E1 is unsigned type ...' to specify
 such a modulo reduction for unsigned types?
 
 >  How is it meaningful to talk about the representability of operations on the representation, and say that the result of such an operation might be unrepresentable?
 the left shift is independant of bit length, it is the truncation of the
 exact result to a representable format which gives the problem.
 
 > Representability is a property of the integers as numbers.
 Representability is a property of representation formats.
 
 > It might be meaningful to think about the result of such an operation
 > having a representation that did not correspond to any value (e.g. was
 > a trap representation) but a non-valued representation is a  totally
 > different concept from a non-representable value.  Besides, there are
 > no such integer representations on the platform for which I reported
 > the bug.
 that would be valid implementation of undefined behaviour.
 
 nathan
 
 -- 
 Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org


             reply	other threads:[~2002-07-12 19:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-12 12:56 Nathan Sidwell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-02-13 16:06 rearnsha
2002-07-12 10:06 Falk Hueffner
2002-07-12  9:46 Nathan Sidwell
2002-07-12  9:26 Falk Hueffner
2002-07-12  8:16 Falk Hueffner
2002-07-12  8:06 Al Grant
2002-07-12  7:12 nathan
2002-07-12  4:26 algrant

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=20020712195601.20155.qmail@sources.redhat.com \
    --to=nathan@codesourcery.com \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@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).