[LLVMdev] [Clang] Reasons for lack of -fsingle-precision-constant support? Alternatives?

[Philip Reames]

On 07/15/2015 05:01 AM, ed at modk.it wrote:
> Hi All,
>
> Clang lacks support for the -fsingle-precision-constant flag.  Are 
> there specific reasons for this or is it just waiting to be implemented?
>
> This flag is especially important in the embedded world. From 
> http://processors.wiki.ti.com/index.php/Floating_Point_Optimization#float_vs._double_vs._long_double 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__processors.wiki.ti.com_index.php_Floating-5FPoint-5FOptimization-23float-5Fvs.-5Fdouble-5Fvs.-5Flong-5Fdouble&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=SziAjiSP8N_rg2b1QO6yqe6DPgAQ-gYuJ_OnsXjdwQo&s=q4wtrH7nx201oaODowm17ir7UAGlp2RfLweJDCQuXLA&e=>:
>
> /Once all of your data is defined as float, there are still cases 
> where you may unknowingly cause the compiler to generate double 
> precision operations. The most common issue is when floating point 
> literals such as 3.14159 are used. In C these literals are of type 
> double, and if they are used in an expression consisting of single 
> precision operands, the operations will be promoted to double 
> precision. The proper way to specify a single precision literal is to 
> use an 'f' suffix, 3.14159f./
> /
> /
> While defining literals without the 'f' suffix may point to 
> performance issues, in our case the target crashes when the 'f' is 
> omitted.  This is an end user programmable system where we can't 
> expect users to add the 'f'.  I don't fully understand why this occurs 
> (this is a bare metal system where user code is run by a quasi-OS 
> which is maintained by a different team and itself is compiled with a 
> different compiler so it's hard to track down) we remedied this with 
> the -fsingle-precision-constant in gcc.  Now that we're moving to 
> clang/llvm we need a solution and expecting the user to add 'f' is not 
> going to work.
Another approach might be to add a dedicated warning (off by default) 
which warns or errors on these cases.  It also seems like a case where a 
clang-tidy rewrite rule could help.
>
> Any thoughts?
>
> Thanks,
> Ed
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150715/41ae2163/attachment.html>