Re: [Mingw-w64-public] __builtin_isnanl() and invalid x87 80-bit floating point numbers
On 2017/5/16 0:43, Vincent Lefevre wrote: > On 2017-05-15 22:35:33 +0800, Liu Hao wrote: >> Yeah but `printf()` from glibc doesn't think it is a NaN... From >> your point of view, is this a glibc bug? > > I think so. If I understand correctly, the output of floating-point > data in glibc is handled in stdio-common/printf_fp.c, which uses: > > extern mp_size_t __mpn_extract_long_double (mp_ptr res_ptr, mp_size_t size, > int *expt, int *is_neg, > long double value); > > The code is one of (not sure): >sysdeps/i386/ldbl2mpn.c >sysdeps/ieee754/ldbl-96/ldbl2mpn.c > > In sysdeps/i386/ldbl2mpn.c only, there is a special case for > "pseudo zero" (no comments about the choice of the behavior, > though), which was added here: > > commit 835abc5c0dfd1ba8aabeb52d46793b13702c708b > Author: Ulrich Drepper > Date: 2007-06-08 02:50:59 + > > [BZ #4586] > > 2007-06-06 Jakub Jelinek > BZ #4586 > * sysdeps/i386/ldbl2mpn.c (__mpn_extract_long_double): Treat > pseudo-zeros as zero. > * sysdeps/x86_64/ldbl2mpn.c: New file. > * sysdeps/ia64/ldbl2mpn.c: New file. > > This corresponds to Bruno Haible's bug report: > >https://sourceware.org/bugzilla/show_bug.cgi?id=4586 > > (though this was for IA64). He said: > >Additionally, the printf results for pseudo-NaN and pseudo-Inf >should better be "nan", because these numbers behave like NaNs >in comparisons, as you can see from the program's output. > > Not sure about the reason of the current choice. > It seems that MinGW-w64 is suffering from the same problem. I CC'd both. Looking forward to other people's opinion. Reference: https://gcc.gnu.org/ml/gcc-help/2017-05/msg00123.html -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
If I were a mingw-w64 committer, I probably wouldn't make that change, but I am OK with it. An argument in favor of that change is that it isn't too hard to just use sed or carefully-placed #defines to fix any Microsoft-style code that uses __in and __out. (It's not ideal, but not terrible.) And once we get libstdc++ to stop using those names, we could undo the change. And if we do change mingw-w64, I agree the way to do it is to comment out the __in and __out lines in driverspecs.h, rather than reverting the patch I posted at the beginning of this thread. --David On Mon, May 15, 2017 at 1:57 AM, Mateusz wrote: > W dniu 2017-05-15 o 08:51, Liu Hao pisze: >> On 2017/5/11 23:11, Kai Tietz wrote: >>> I would prefer this too, but I don't believe that we can convince >>> libstdc++ maintainers to modify their code for this. Sadly the MS' >>> platform sdk defines a lot of stuff, which collides some times with >>> some projects. We made about this already a lot of bad experiences >>> ... especially in context of MIDL ... defining >>> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ... >>> Nevertheless it might be worth a try to ask libstdc++ people for those >>> __in A good argument (and bad one too) might be that the double >>> underscore symbols are reserved to compilers/system headers. And >>> well, C++ headers aren't really system headers, which is in general >>> just a POV ;) >> I suggest we comment out `__in` and `__out` from _driverspecs.h_. The >> compatibility with GNU libstdc++ and LLVM libcxx is more essential than >> that with Windows in my opinion. > > +1 > >> >> These macros are defined after including _windows.h_ from official >> Windows SDK, as shown in this example: >> >> >> E:\Desktop>cat test.c >> #include >> #include >> >> int main(){ >> #if defined(__in) >> puts("__in is defined."); >> #else >> puts("__in is not defined."); >> #endif >> } >> >> E:\Desktop>cl test.c /nologo /Fea.exe >> test.c >> >> E:\Desktop>cat test.c >> #include >> #include >> >> int main(){ >> #if defined(__in) >> puts("__in is defined."); >> #else >> puts("__in is not defined."); >> #endif >> } >> >> E:\Desktop>cl test.c /nologo /Fe:a.exe >> test.c >> >> E:\Desktop>a.exe >> __in is defined. >> >> E:\Desktop>gcc test.c >> >> E:\Desktop>a.exe >> __in is not defined. >> >> >> > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
W dniu 2017-05-15 o 08:51, Liu Hao pisze: > On 2017/5/11 23:11, Kai Tietz wrote: >> I would prefer this too, but I don't believe that we can convince >> libstdc++ maintainers to modify their code for this. Sadly the MS' >> platform sdk defines a lot of stuff, which collides some times with >> some projects. We made about this already a lot of bad experiences >> ... especially in context of MIDL ... defining >> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ... >> Nevertheless it might be worth a try to ask libstdc++ people for those >> __in A good argument (and bad one too) might be that the double >> underscore symbols are reserved to compilers/system headers. And >> well, C++ headers aren't really system headers, which is in general >> just a POV ;) > I suggest we comment out `__in` and `__out` from _driverspecs.h_. The > compatibility with GNU libstdc++ and LLVM libcxx is more essential than > that with Windows in my opinion. +1 > > These macros are defined after including _windows.h_ from official > Windows SDK, as shown in this example: > > > E:\Desktop>cat test.c > #include > #include > > int main(){ > #if defined(__in) > puts("__in is defined."); > #else > puts("__in is not defined."); > #endif > } > > E:\Desktop>cl test.c /nologo /Fea.exe > test.c > > E:\Desktop>cat test.c > #include > #include > > int main(){ > #if defined(__in) > puts("__in is defined."); > #else > puts("__in is not defined."); > #endif > } > > E:\Desktop>cl test.c /nologo /Fe:a.exe > test.c > > E:\Desktop>a.exe > __in is defined. > > E:\Desktop>gcc test.c > > E:\Desktop>a.exe > __in is not defined. > > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public