Martin J. O'Riordan via llvm-dev
2017-Sep-25 12:35 UTC
[llvm-dev] '__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>
Friedman, Eli via llvm-dev
2017-Sep-25 17:46 UTC
[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/1324d00f/attachment-0001.html>
Martin J. O'Riordan via llvm-dev
2017-Sep-25 18:40 UTC
[llvm-dev] '__builtin_nanl' and soft-FP64 support
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>