From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-117269-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 19026 invoked by alias); 15 Jul 2005 15:03:36 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 19016 invoked by uid 22791); 15 Jul 2005 15:03:32 -0000
Received: from rwcrmhc12.comcast.net (HELO rwcrmhc12.comcast.net) (216.148.227.85)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 15 Jul 2005 15:03:32 +0000
Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96])
          by comcast.net (rwcrmhc12) with SMTP
          id <20050715150328014004d5bue>; Fri, 15 Jul 2005 15:03:29 +0000
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Fri, 15 Jul 2005 15:03:00 -0000
Subject: Re: Where does the C standard describe overflow of signed
 integers?
From: Paul Schlie <schlie@comcast.net>
To: Georg Bauhaus <bauhaus@futureapps.de>
CC: Robert Dewar <dewar@adacore.com>,
	<gcc@gcc.gnu.org>
Message-ID: <BEFD487E.AD59%schlie@comcast.net>
In-Reply-To: <42D7B82B.7010102@futureapps.de>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-SW-Source: 2005-07/txt/msg00633.txt.bz2

> From: Georg Bauhaus <bauhaus@futureapps.de>
>> Paul Schlie wrote:
>>> From: Robert Dewar <dewar@adacore.com>
>>>> Paul Schlie wrote:
>>>> I don't contest that it may, I simply don't believe it should.
>>> you can't seriously mean that with respect to uninitialized
>>> variables. this would mean you could not put local variables in
>>> registers. the effect on code quality woul be awful!
>> Why would anyone care about the performance of an access to an
>> un-initialized variable? [..] although do
>> see substantial value in producing compiled code which is strictly
>> consistent with the specified program and native target behavior,
>> regardless of its portability.
> 
> You can have both, correctness and uninitialised local
> variables. For an impression of the difference in performance,
> and for a way to ensure correctness, I tried this
> (switch register/volatile in the declaration lines in comp
> and r to see the effects).

- which predominantly illustrates the effect of volatile semantics?

  int x, y, z;
  (vs.)
  int x=1, y=2, z=3;

  would illustrate the effect of potentially uninitialised local variables,
  along with the accesses specified to the uninitialised elements of buffer.

  in that circumstance, what optimizations would you advocate as beneficial?

> #include <stddef.h>
> #include <assert.h>
> 
> #define BUFFER_SIZE 1000  // must be > 0
> #define ITERATIONS 100000  // must be > 0
> 
> static inline int comp(const short, const short, const short);
> 
> /* pre: a has elements, that is hi > 0. Frequently called */
> int r(short a[], size_t hi)
> {
>   //register int x, y, z;
>   volatile int x=1, y=2, z=3;
> 
>   assert(hi > 0);
> 
>   for (size_t c=0; c < hi + 2; ++c) {
>     if (a[c]) {
>     jfssoae:
>       x = c + 3, y = z = a[c];
>       if (comp(x, y, z)) z = x - y;
>     }
>   }
>   return x + y + z;
> }
> 
> static inline int comp(const short x, const short y, const short z)
> {
>   //register int result = (x + y) == (x +  z);
>   volatile int result = (x + y) == (x +  z);
>   return result;
> }
> 
> int main()
> {
>   short buffer[BUFFER_SIZE];
>   int result;
> 
>   assert(ITERATIONS > 0);
> 
>   for (int runs = 0; runs < ITERATIONS; ++runs) {
>     result = r(buffer, BUFFER_SIZE);
>   }
>   return result;
> }
>