Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <50479467.6050903@hates.ms>
Date: Wed, 05 Sep 2012 14:05:27 -0400
From: Liviu Nicoara <nikkoara@hates.ms>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
 rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: Intel C++ bug reports?
References: <F9F2BE0F-0920-4620-A813-79CBA698BE5D@hates.ms>
 <5046AA04.7070508@gmail.com>
In-Reply-To: <5046AA04.7070508@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09/04/12 21:25, Martin Sebor wrote:
> On 09/04/2012 07:02 PM, Liviu Nicoara wrote:
>>
>> While configuring the library on my x86_64 machine, I ran into what appears to be a code generation compiler bug which affects LIMITS.cpp test -- the test cycles ad infinitum because of the incorrect test marked below:
>
> Looking at the test below, though, it depends on undefined behavior
> (signed overflow) so there's no compiler bug. Making max volatile
> fools icc just enough to produce the expected output (while still
> relying on undefined behavior). It would be good to clean it up,
> though. I think computing UINT_MAX instead and shifting it right
> by the number of sign bits (i.e., 1) should work.


FWIW, I like the current implementation more. It seems to me that, by using a bitwise logical shift of the corresponding unsigned integer, followed by a conversion to the signed integer, we'd make an assumption about the representation of signed integers. But a shifting implementation should be relatively easy to add.

Liviu