[PATCH] Fixing a corner-case bug in lib call optimization

[Nick Lewycky]

Gao, Yunzhong wrote:
> Hi Nick,
> Thanks for reviewing the patch.
> I will change the type conversion to "unsigned char" instead; that should make
> the result deterministic.
> I feel that this is probably still not an ideal solution because the host machine
> might have a different size for "char" type than the target machine, but in the
> llvm backend I did not find a way to extract the size of target "char" type. I
> would guess that machines with non-8-bit bytes are rare nowadays? Since
> the patch is only intended for a corner-case comparing a value with zero, it
> might suffice using a cast to "unsigned char" or even "(value&  255)".
> What do you think?

Actually, I was thinking about this some more and isn't the testcase you 
posted undefined behaviour?

The C standard specifies that it gets converted from int to char. That 
conversion will produce an implementation-defined result when the int is 
not in range of a char. Now for the crazy part -- isn't it true that 
there is no rule requiring a value in the abstract machine of C (or C++) 
to actually fit in the number of bits allotted? Given the right setup, 
you can have char x == 1000 evaluate to true (even assuming 8-bit char), 
and no undefined behaviour, merely implementation-defined results.

Maybe I'm crazy?

Nick

> - Gao.
>
> ________________________________________
> From: Nick Lewycky [nicholas at mxc.ca]
> Sent: Monday, August 12, 2013 11:09 AM
> To: reviews+D1279+public+b2efa1ad64fbca2e at llvm-reviews.chandlerc.com
> Cc: Gao, Yunzhong; llvm-commits at cs.uiuc.edu
> Subject: Re: [PATCH] Fixing a corner-case bug in lib call optimization
>
> Yunzhong Gao wrote:
>>
>>     ping.
>>     Does this patch look good to go in?
>>
>> http://llvm-reviews.chandlerc.com/D1279
>
> If the value doesn't fit into a 'char', the result of the conversion to
> char will be implementation-defined. Could you please make it something
> that is guaranteed to be deterministic?
>
> Nick
>
>