You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@mynewt.apache.org by "Sheela (JIRA)" <ji...@apache.org> on 2017/06/02 18:25:04 UTC
[jira] [Assigned] (MYNEWT-746) Sim - Floating point calculations
sometimes incorrect
[ https://issues.apache.org/jira/browse/MYNEWT-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sheela reassigned MYNEWT-746:
-----------------------------
Assignee: Christopher Collins
> Sim - Floating point calculations sometimes incorrect
> -----------------------------------------------------
>
> Key: MYNEWT-746
> URL: https://issues.apache.org/jira/browse/MYNEWT-746
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Reporter: Christopher Collins
> Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> *Note: this problem does not occur in OS X; it has only been seen in Linux.*
> In sim, some floating point calculations yield wildly incorrect results (usually 0 or NaN). The cause appears to be that the floating point registers are not restored when longjmp() is called. If subsequent code tries to use an intermediate value stored in a floating point register, the result is indeterminate.
> There is a gcc / clang compiler option which mostly solves this problem: *-ffloat-store*:
> {quote}
> -ffloat-store
> Do not store floating point variables in registers, and inhibit other options that might change whether a floating point value is taken from a register or memory.
> This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a double is supposed to have. Similarly for the x86 architecture. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point. Use -ffloat-store for such programs, after modifying them to store all pertinent intermediate computations into variables.
> {quote}
> The problems disappeared when I started using this option. However, it seems there is still the occasional miscalculation, as a test failure just occurred due to an incorrect floating point value. In this case, assigning {{18.0}} to an int yielded the value {{-2147483648}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)