Return-Path: 
 <dev-return-7002-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 4865 invoked from network); 6 Mar 2008 00:19:50 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 6 Mar 2008 00:19:50 -0000
Received: (qmail 57470 invoked by uid 500); 6 Mar 2008 00:19:47 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 57453 invoked by uid 500); 6 Mar 2008 00:19:46 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:dev@stdcxx.apache.org>
List-Id: <dev.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 57444 invoked by uid 99); 6 Mar 2008 00:19:46 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Mar 2008 16:19:46 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Mar 2008 00:19:11 +0000
Received: from nebula.bco.roguewave.com ([10.70.3.27])
	by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m260JKK3015888
	for <dev@stdcxx.apache.org>; Thu, 6 Mar 2008 00:19:20 GMT
Message-ID: <47CF3885.3080108@roguewave.com>
Date: Wed, 05 Mar 2008 17:19:17 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: [PATCH] STDCXX-423
References: 
 <CFFDD219128FD94FB4F92B99F52D0A499A2B3A@exchmail01.Blue.Roguewave.Com>
 <47B228E7.8090300@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499A2B3E@exchmail01.Blue.Roguewave.Com>
 <47BA5DD2.9010605@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499A2B4B@exchmail01.Blue.Roguewave.Com>
 <47BC7ED5.2030003@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499A2B92@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A499A2B92@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Scott Zhong wrote:
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Wednesday, February 20, 2008 12:26 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: [PATCH] STDCXX-423
>>
>> Scott Zhong wrote:
>> [...]
>>>>> As I write this, I realize that the my function,
>>> compute_byte_size(),
>>>>> can be optimized to shift one bit to the next byte boundary.
>>>> I don't think we need to (or should) worry about optimizing config
>>>> tests. What we might want to do is use the template parameter in
>>>> the signature of the function for non-conforming compilers that
>>>> have trouble with these types of things.
>>> Sorry I meant to say that its more of a code fix than optimization.
>>> Sizeof() returns the number of bytes so the function should check
> each
>>> byte instead of each bit.
>> But not all bits of every byte need to contribute to the value
>> representation of the object. IIUC, there can be 4 byte ints
>> (i.e., sizeof(int) == 4) with 29 bits for the value, 1 bit for
>> the sign, and 2 bits of padding.
>>
> 
> I had overlooked that fact, thank you for reminding me.
> 
>>>>> template <class T>
>>>>> unsigned compute_byte_size()
>>>>> {
>>>>>     T max = T (one);
>>>>>     unsigned byte = 0;
>>>>>     for (; T (max * 128) > max; max *= 128) {
>>>> FWIW, for signed T the expression T(max * 128) > max has undefined
>>>> behavior in the presence of overflow. We've seen at least two (if
>>>> not three) compilers exploit this presumably in some aggressive
>>>> optimizations (see, for example, STDCXX-482). Since most (all?)
>>>> hardware simply wraps around in the presence of overflow we just
>>>> need to prevent the compiler optimization here.
>>> Would the volatile keyword in front of "max" be sufficient here?
>> It might help, but I'm not sure it's guaranteed to. All it usually
>> does is make the compiler generate code that reloads the value of
>> the object from memory into a register on each access. The stage
>> I'm concerned with takes place before code generation based on what
>> the compiler can prove about the program. For all signed x, the
>> compiler is free to assume that in (x * N) > x, the subexpression
>> (x * N) doesn't overflow and thus (x * N) is always guaranteed to
>> be greater than x (for N > 0). To prevent it from making such an
>> assumption we need to rewrite the expression like so: (x * N) > y
>> while initializing x and y to the same value in such a way that
>> the compiler cannot prove that (x == y) holds.
>>
> 
> Would this suffice?

This doesn't seem correct, not just because of the typo but because
it returns 3 for T = int (assuming one == 1). Even if it was correct
I'm not sure a smart optimizer couldn't make some assumptions about
the dependency between current and max (they are both modified using
exactly the same expression) that would cause the code to misbehave.

Martin

> 
> template <class T>
> unsigned compute_byte_size()
> {
>     T max = T (one);
>     T current = T (one);
>     unsigned byte = 0;
>     for (int I = 1; T (current * 2) > max; current *= 2, max *= 2, i++)
> {
>         if (i > 8 ) {byte++; i = 1; }
>     }
>     return byte;
> }
> 
> 
>> Martin
>