The following functions are implemented:
letf2, gttf2, netf2, getf2, eqtf2, lttf2, __unordtf2
Details
- Reviewers
- None
- Commits
- rL205312: Add support for IEEE754 quad precision comparison functions.
Diff Detail
Event Timeline
Since we use __uint128_t type, which is undefined in 32-bit machine toolchain, we enable these functions only when using 64-bit machine.
We assume sizeof(long double)=16 (IEEE-754 128-bit format)
SIZEOF_LONG_DOUBLE=8 in SPARC and SIZEOF_LONG_DOUBLE=16 in SPARC64
SIZEOF_INT128 =16 is also defined in SPARC64, so these funcitons can be compiled in SPARC64
Could you specify the situation about when the problem occurs? Thanks
OK, forget my comment. I misremembered the sate of 32bit SPARC. Ideally, __uint128_t would be supported on all targets, but that's a fundamentally different question.
Can you add a define similar to CRT_HAS_128BIT to flag whether a platform should use this code? x86_64 uses 80bit long double, so it doesn't match. Checking LDBL_MANT_DIG == 113 or so would be a good first approximiation.
introduce CRT_LDBL_128BIT
I will upload patches for other functions if my modifications are what you want, thanks.
Hi GuanHong Liu,
Thank you for working on this!
This set of patches looks good, but because I don't contribute regularly to compiler-rt, I will defer to other reviewers to stamp the final LGTM.
Dmitri
lib/builtins/comparetf2.c | ||
---|---|---|
70–76 | Could you sink the comment into the else {} block? It is not immediately obvious that the 'if' statement continues there. |
Hi GuanHong Liu,
I don't know if you noticed, but Joerg signed off on this patch, so please commit!
Dmitri
Hi Dmitri
I don't have commit authority, could you help me to commit them? thanks.
GuanHong
Joerg,
Since this patch depends on D2796, which is owned by you, I will defer to you on this patch.
Dmitri
I want to ask that whether our patches (including D2796, which is owned by Joerg now) can be commited?
Thanks,
GuanHong
Sorry, I thought I had it committed already. No objections from me, but I can't test this.
Could you sink the comment into the else {} block? It is not immediately obvious that the 'if' statement continues there.