Fix for PR15318: AsmPrinter crashes with assertion

Chad Rosier mcrosier at apple.com
Tue Mar 19 09:50:40 PDT 2013


Hao,
Seems like a reasonable change, but perhaps John could comment on why he chose to force a minimum precision of 32.

Also, please add a test case before committing.

 Chad

On Mar 19, 2013, at 2:43 AM, Hao Liu <Hao.Liu at arm.com> wrote:

> Hi,
>  
> Please consider patch in attachment as fix for PR15318: AsmPrinter crashes with assertion.
> http://llvm.org/bugs/show_bug.cgi?id=15318
>  
> APFloat::toString tries to print floating point in decimal string. It calculates the precision and padding of the output format. At the end of the AdjustPrecision function, it truncates the significand down to its active bit count but always keeps it never drop below 32 bits.
>  
> BitWidth of significand is larger than active bits, but it is not always larger than 32. E.g. when the 64bit value 0x41EFFFFFE0000000 is read and called toString(), the BitWidth of significand is smaller than 32. Then truncating the significand to 32 will cause an assertion failure (it always assert width < BitWidth).
>  
> The fix is very simple, just remove the “don’t try to drop below 32” operation. Always truncate it to the active bits.
>  
> I just find it’s no need to keep significand above 32. The AdjustPrecision function does useless thing, which causes the assertion failure.
>  
>  
> Thanks,
> -Hao
>  
> <APFloat.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130319/dac1505b/attachment.html>


More information about the llvm-commits mailing list