Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate floating-point from to_chars #431

Closed
johnmcfarlane opened this issue Apr 26, 2019 · 7 comments
Closed

Eliminate floating-point from to_chars #431

johnmcfarlane opened this issue Apr 26, 2019 · 7 comments

Comments

@johnmcfarlane
Copy link
Owner

#340 (comment)

@johnmcfarlane
Copy link
Owner Author

here is a compiler error due to floating-point. Perhaps this can be used to isolate the floating-point instruction.

@elcojacobs do you have any idea where the floating-point is introduced? I compare to .0 here. Could it be a comparison with zero? If so, see if replacing .0 with Number{} helps.

@johnmcfarlane
Copy link
Owner Author

Also, I'm trying to build the project with armv7+nofp but both GCC7 and 8 produce an ICE:
https://circleci.com/gh/johnmcfarlane/cnl/3389

Don't suppose you have any experience disabling floating-point at the compiler level do you? I'd very much like to allow CNL to compile with no floating-point whatsoever.

@elcojacobs
Copy link

I'm compiling for arm cortex M3, so I changed godbolt to use -O3 -std=c++17 -march=armv7-m to be a close match.

https://godbolt.org/z/0g4Ykn

You can see in the godbolt output that __aeabi_dmul is used, a software multiply double (the m3 does not have hardware floating point).

I think you are right about the .0 comparison. Replacing it with Number{} seems to eliminate the floating point instructions!

@johnmcfarlane
Copy link
Owner Author

Thanks. If I can make use of floating-point be a compiler error I could sweep the entire library and make it float-proof but doing this by examining assembler output would make the task orders of magnitude more difficult to perform. I may file a bug against GCC at some point as this error would be incredibly useful.

In the meantime, please let me know anywhere you spot a problem and feel free to submit pull requests. In particular, I often initialize fixed_point objects with 0. because it's less prone to overflow. However the fixed_point{} approach should be equally valid.

@elcojacobs
Copy link

I tried to find a way to disable floating point altogether but cannot find it. It seems that the compilers only support choosing between hard (if available) or soft.
Maybe a workaround can be found by overriding the software floating point implementations with empty functions that cause a linker error.

@elcojacobs
Copy link

an alternative that can be automated is to let the compiler generate a map file and to use grep to scan it for soft float functions

@johnmcfarlane
Copy link
Owner Author

This post gives me hope that GCC can be persuaded to police use of floats. Pity this flag causes an ICE. Anyway, this specific case is fixed in develop now. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants