<div dir="rtl"><div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr">I am somewhat conflicted on this.</div><div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr"><br>
</div><div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr">Initially I wished the 80 bit long doubles to remain - why not use the HW Intel gave us?</div><div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr">
However, beyond the *scanf *printf* issues (as we learned not all of them are solved in MingW), I just found out that the latest Visual C++ 2013 provides additional C99 math functions such as acosh, acoshf, acoshl which is a good thing but the -l long double functions are 64 bit of course. Previously they did not provide the -l functions so that you could just provide them yourself say from the FreeBSD sources. Now however there is great source of confusion since they do provide -l functions in the VC runtime which do not work on 80 bit long doubles. The solution could be along the lines of __minw_printf but does not exist right now. </div>
<div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr"><br></div><div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr">So program compiled by clang -mingw32 would compile but produce wrong runtime results, just like printf without the __USE_MINGW_ANSI_STDIO defined. Not to mention __USE_MINGW_ANSI_STDIO is not even a default define in MingW.</div>
<div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr">These are <u>awful</u> silent bugs to find. Turns out there are lots of problems living with 80 bit long doubles in a 64 bit long double world!</div>
<div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr"><br></div><div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr">In addition, clang -mingw32 clang actually produces assembler code and calls on gcc to compile the assembler to object and link it while with -win32 it creates object by itself and calls upon link.exe to link, (possibly using lld in the future). So -win32 should be faster than -mingw32.</div>
<div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr"><br></div><div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr">For the same reasons clang (and libcxx) are highly compatible with the standard gcc on linux they should be highly compatible with standard VC on Windows. <br>
</div><div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr"><br></div><div style="font-family:arial,sans-serif;font-size:12.499999046325684px" dir="ltr">I now think that the first priority should be -win32 since - flawed or not - it is THE standard with Windows for others to follow. <br>
</div><div class="gmail_extra" dir="ltr"><br>Yaron</div><div class="gmail_extra" dir="ltr"><br><br><div class="gmail_quote"><div>2013/10/6 Anton Korobeynikov <span dir="ltr"><<a href="mailto:anton@korobeynikov.info" target="_blank">anton@korobeynikov.info</a>></span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Should definitely be both.<br>
<div><div class="h5"><br>
On Sun, Oct 6, 2013 at 2:54 AM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com">yaron.keren@gmail.com</a>> wrote:<br>
> The patch is required for target -mingw32 only since then clang makes 80 bit<br>
> long doubles but not for target -win since clang behaves like Visual C++ and<br>
> produces 64 bit long doubles.<br>
><br>
> So this got me thinking, where libcxx on Windows is heading -<br>
> target -mingw32 with MingW32 headers and 80 bit long doubles?<br>
> target -win with Visual C++ headers with 64 bit long doubles?<br>
> both?<br>
><br>
><br>
> Yaron<br>
><br>
><br>
><br>
> 2013/10/5 G M <<a href="mailto:gmisocpp@gmail.com">gmisocpp@gmail.com</a>><br>
>><br>
>> Hi Yaron<br>
>><br>
>> I looked at this problem quite a bit a while back, FYI MS's routines are<br>
>> different from the libcxx versions in other ways too.<br>
>><br>
>> I made some changes a while back to reduce and centralize some of the uses<br>
>> of snprintf in libcxx a while back in order to generally try to move towards<br>
>> what your patch proposes.<br>
>><br>
>> I generally approve of where you are going with this patch. I'll apply it<br>
>> on my machine this weekend and try your patch out and contrast it with VS<br>
>> builds with it and report soon in more detail.<br>
>><br>
>> I think it's a good area to focus on. Thanks for looking at this.<br>
>><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
><br>
<span class=""><font color="#888888"><br>
<br>
<br>
--<br>
With best regards, Anton Korobeynikov<br>
Faculty of Mathematics and Mechanics, Saint Petersburg State University<br>
</font></span></blockquote></div><br></div></div>