[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