From dev-return-6995-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Tue Mar 04 20:40:57 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 55066 invoked from network); 4 Mar 2008 20:40:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2008 20:40:57 -0000 Received: (qmail 10020 invoked by uid 500); 4 Mar 2008 20:40:53 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 10007 invoked by uid 500); 4 Mar 2008 20:40:52 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 9998 invoked by uid 99); 4 Mar 2008 20:40:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Mar 2008 12:40:52 -0800 X-ASF-Spam-Status: No, hits=1.8 required=10.0 tests=SPF_PASS,SUBJ_ALL_CAPS X-Spam-Check-By: apache.org Received-SPF: pass (nike.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; Tue, 04 Mar 2008 20:40:06 +0000 Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com [10.22.129.22]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m24KePFo027248 for ; Tue, 4 Mar 2008 20:40:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] STDCXX-423 Date: Tue, 4 Mar 2008 13:40:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] STDCXX-423 Thread-Index: Achz9sHsimvcAUEiS8ij4pTzAifjKAKP61lQ References: <47B228E7.8090300@roguewave.com> <47BA5DD2.9010605@roguewave.com> <47BC7ED5.2030003@roguewave.com> From: "Scott Zhong" To: X-Virus-Checked: Checked by ClamAV on apache.org > -----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 >=20 > 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. >=20 > 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) =3D=3D 4) with 29 bits for the value, 1 bit for > the sign, and 2 bits of padding. >=20 I had overlooked that fact, thank you for reminding me. > > > >>> template > >>> unsigned compute_byte_size() > >>> { > >>> T max =3D T (one); > >>> unsigned byte =3D 0; > >>> for (; T (max * 128) > max; max *=3D 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? >=20 > 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 =3D=3D y) holds. >=20 Would this suffice? template unsigned compute_byte_size() { T max =3D T (one); T current =3D T (one); unsigned byte =3D 0; for (int I =3D 1; T (current * 2) > max; current *=3D 2, max *=3D 2, = i++) { if (i > 8 ) {byte++; i =3D 1; } } return byte; } > Martin