[Bug c/77265] New: Casting an extended precision long double "inf" to __float128 results in "nan"
sisyphus1 at optusnet dot com.au
gcc-bugzilla@gcc.gnu.org
Tue Aug 16 11:54:00 GMT 2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77265
Bug ID: 77265
Summary: Casting an extended precision long double "inf" to
__float128 results in "nan"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sisyphus1 at optusnet dot com.au
Target Milestone: ---
Created attachment 39463
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39463&action=edit
Demonstrates the bug that I've described
Hi,
First up ... I've nominated that this is "A problem with the C compiler front
end".
My apologies if that assessment is incorrect.
Attached is the demo program (bug492.c) which I've built on Ubuntu-16.04LTS
(gcc-5.4.0) with the command:
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -o bug492 bug492.c -lquadmath
The output of that program is:
inf inf
Looks like we have a NaN instead of Inf
inf nan
and I take it that demonstrates that an extended precision (80-bit) long double
+infinity, when cast to a __float128, is transformed into a NaN.
I originally reported this as a mingw-w64 bug (over a year ago) at:
https://sourceforge.net/p/mingw-w64/bugs/479/
It's only recently that I've encountered the same behaviour with gcc on linux.
(I think this might be because I generally use more modern versions of gcc on
Windows than I do on linux.)
I guess it might be considered as a somewhat minor quibble ... but it has
actually become quite a PITA for me.
Can something be done ? ... or do I just need to keep implementing workarounds
?
Thank you all for your excellent work.
Cheers,
Rob
More information about the Gcc-bugs
mailing list