Re: [Mingw-w64-public] __builtin_isnanl() and invalid x87 80-bit floating point numbers

[Liu Hao]

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.

[David Grayson]

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.

[Mateusz]

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

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

[Liu Hao]

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.

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.



-- 
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