[llvm-commits] [PATCH] Fix various instances of undefined behavior

[Ahmed Charles]

FDIS 5.6/4 suggests that floating point isn't special:

The binary / operator yields the quotient, and the binary % operator
yields the remainder from the division of the first expression by the
second. If the second operand of / or % is zero the behavior is
undefined. For integral operands the / operator yields the algebraic
quotient with any fractional part discarded;[81] if the quotient a/b
is representable in the type of the result, (a/b)*b + a%b is equal to
a.

81) This is often called truncation towards zero.

Is there somewhere else that gives floating point different semantics?

On Wed, Oct 12, 2011 at 4:28 PM, Ahmed Charles <ahmedcharles at gmail.com> wrote:
> I'll do that later after merging your changes and doing another round of tests.
>
> On Wed, Oct 12, 2011 at 4:24 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Wed, Oct 12, 2011 at 1:50 AM, Ahmed Charles <ahmedcharles at gmail.com> wrote:
>>> Similar patch with stuff found compiling boost. The one in APFloat
>>> seems like an actual bug. "make check-all" passes for all of these
>>> changes.
>>>
>>> On Tue, Oct 11, 2011 at 9:17 PM, Ahmed Charles <ahmedcharles at gmail.com> wrote:
>>>> I'm not sure if each instance is a bug, other than simply executing
>>>> undefined behavior (which meets my personal bar), but some of them
>>>> actually seem like logic bugs or typos. Please review and commit some
>>>> or all of the changes.
>>
>> I committed changes to APFloat, EarlyCSE, DenseMapInfo.h, and
>> SelectionDAGBuilder.cpp.
>>
>> For the LSR ones, I'm not entirely sure what the intent is; the math
>> seems a bit suspicious.
>>
>> For the change to lib/Analysis/ProfileEstimatorPass.cpp, as far as I
>> know, a floating-point divide-by-zero is not undefined behavior.
>>
>> For everything else, would you mind consolidating the remaining
>> changes into a single patch?
>>
>> -Eli
>>
>
>
>
> --
> Ahmed Charles
>



-- 
Ahmed Charles