llvm dev - Sep 2017 - '__builtin_nanl' and soft-FP64 support

I am seeing failures in two tests after migrating to v5.0 final, these are:

std/language.support/support.limits/limits/numeric.limits.members/quiet_NaN.
pass.cpp

and:

std/language.support/support.limits/limits/numeric.limits.members/signaling_
NaN.pass.cpp

However, these are new tests and it turns out that the underlying problem is
that the builtin '__builtin_nanl("")' is returning the value
0x0000000000000000.  I tested this builtin with our v4.0 compiler and it has
the same problem, so this is not a regression but rather an existing bug
exposed by the new LibC++ implementation of '<limits>'.

 

But our implementation of FP64 is a software only implementation using the
FP64 support functions in 'compiler-rt' and we have no lowering actions
of
our own.

 

Where should I be looking to find out how to fix this?  Is it a CLang issue
of an LLVM issue?

 

Thanks,

 

            MartinO

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170925/3f506c83/attachment.html>

On 9/25/2017 5:35 AM, Martin J. O'Riordan via llvm-dev
wrote:
>
> I am seeing failures in two tests after migrating to v5.0 final, these 
> are:
>
>
std/language.support/support.limits/limits/numeric.limits.members/quiet_NaN.pass.cpp
>
> and:
>
>
std/language.support/support.limits/limits/numeric.limits.members/signaling_NaN.pass.cpp
>
> However, these are new tests and it turns out that the underlying 
> problem is that the builtin ‘__builtin_nanl(“”)’ is returning the 
> value 0x0000000000000000.  I tested this builtin with our v4.0 
> compiler and it has the same problem, so this is not a regression but 
> rather an existing bug exposed by the new LibC++ implementation of 
> ‘<limits>’.
>
> But our implementation of FP64 is a software only implementation using 
> the FP64 support functions in ‘compiler-rt’ and we have no lowering 
> actions of our own.
>
> Where should I be looking to find out how to fix this?  Is it a CLang 
> issue of an LLVM issue?
>
__builtin_nanl("") gets constant-folded by clang; if you look at the 
LLVM IR, you should see something like "double 0x7FF8000000000000". 
Where exactly is 0x0000000000000000 showing up?

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170925/1324d00f/attachment-0001.html>

Thanks Eli,

 

Hadn't thought of that.  Yes, it us present in the IR emitted from CLang, so
I'll have to see if I find where it changes by dumping the IR between
passes.

 

All the best,

 

            Martin

 

From: Friedman, Eli [mailto:efriedma at codeaurora.org] 
Sent: 25 September 2017 18:47
To: Martin J. O'Riordan <martin.oriordan at movidius.com>; 'LLVM
Developers'
<llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] '__builtin_nanl' and soft-FP64 support

 

On 9/25/2017 5:35 AM, Martin J. O'Riordan via llvm-dev wrote:

I am seeing failures in two tests after migrating to v5.0 final, these are:

std/language.support/support.limits/limits/numeric.limits.members/quiet_NaN.
pass.cpp

and:

std/language.support/support.limits/limits/numeric.limits.members/signaling_
NaN.pass.cpp

However, these are new tests and it turns out that the underlying problem is
that the builtin '__builtin_nanl("")' is returning the value
0x0000000000000000.  I tested this builtin with our v4.0 compiler and it has
the same problem, so this is not a regression but rather an existing bug
exposed by the new LibC++ implementation of '<limits>'.

 

But our implementation of FP64 is a software only implementation using the
FP64 support functions in 'compiler-rt' and we have no lowering actions
of
our own.

 

Where should I be looking to find out how to fix this?  Is it a CLang issue
of an LLVM issue?

 


__builtin_nanl("") gets constant-folded by clang; if you look at the
LLVM
IR, you should see something like "double 0x7FF8000000000000".  Where
exactly is 0x0000000000000000 showing up?

-Eli



-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170925/949c4a19/attachment.html>