<div dir="ltr"><div><div>Hi Jorge,<br><br></div>I do not intend to "overcomplicate" the testing as you put it, so there will be cases which are not caught by these tests.<br>For *_MAX, if overflow occurs to the maximum 
positive finite value (assuming no infinities), then it is possible for 
that value to be less than 10^37 and the test will miss it.<br></div><div>Remember: Richard pointed out that the value of the internally defined macros are the subject of more extensive testing.<br></div><div><br></div><div>Anyhow, I also missed that Clang does not accept floating-point evaluation in preprocessor expressions (something the C++ committee is planning to remove), so it seems the testing will need to switch to use _Static_assert.<br><br></div><div>-- HT<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 13, 2016 at 6:00 PM, Jorge Teixeira <span dir="ltr"><<a href="mailto:j.lopes.teixeira@gmail.com" target="_blank">j.lopes.teixeira@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Hubert.<br>
<br>
I'm curious to see how you will handle corner cases without library<br>
support, such as unsigned/signed zero and 0+x cases, with abs(x) <<br>
EPS.<br></blockquote><div>abs(x) < EPS does not mean that 0+x underflows to zero. :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How does the parser/preprocessor interpret fp literals that are too<br>
"precise" for that machine but are fine for other targets (cross<br>
compile)? Example: clang is on some machine that uses 64bits long<br>
double and the code is for another machine with intel extended<br>
precision 80bits. I assume the Arbitrary Precision part of the APfloat<br>
name was not chosen randomly, but it is not clear to me how that<br>
affects the comparison operators inside the #if directives.<br></blockquote><div>The intention is for the target type to be emulated. This emulation has been problematic for PPCDoubleDouble since the number of mantissa bits vary (there are at least 107 bits--most people stick with saying 106--except at the extremely high and low magnitude ranges, but there can be many more bits caused by a run of 0's or 1's between the two doubles).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jorge<br>
<br>
On Sat, Feb 13, 2016 at 5:28 PM, Hubert Tong<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
> Hi Jorge,<br>
><br>
> Looks fine to me. I'll work on committing this (with minor changes) over the<br>
> weekend.<br>
> Basically, I intend to remove some extraneous parentheses and adjust the<br>
> *_EPSILON, *_MIN and *_TRUE_MIN checks to reject values equal to 0.<br>
><br>
> -- HT<br>
><br>
><br>
> On Sat, Feb 13, 2016 at 2:33 PM, Jorge Teixeira <<a href="mailto:j.lopes.teixeira@gmail.com">j.lopes.teixeira@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hubert,<br>
>><br>
>> You're right about the *_MIN relationships, and I fixed them on the<br>
>> attached patch.<br>
>><br>
>> As for the enums, since there we're not even testing if the literals<br>
>> are integers or fp numbers, and the Std. already reserves ranges for<br>
>> implementation-specific values for some macros, it felt more natural<br>
>> to simply test the boundary. The only exception would be<br>
>> *_HAS_SUBNORM, for which only three values are allowed. The attached<br>
>> patch implements this.<br>
>><br>
>> Jorge<br>
>><br>
>><br>
>> On Sat, Feb 13, 2016 at 11:21 AM, Hubert Tong<br>
>> <<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
>> > +#if ((FLT_MIN < DBL_MIN) || (DBL_MIN < LDBL_MIN))<br>
>> > +    #error "Mandatory macros {FLT,DBL,LDBL}_MIN are invalid."<br>
>> > This value again depends on the minimum exponent, and so the<br>
>> > relationship<br>
>> > being tested here is not required to hold.<br>
>> > +#endif<br>
>> ><br>
>> > For the enumeration-like cases, perhaps it would be better to test that<br>
>> > the<br>
>> > value is one of the specific values.<br>
>> ><br>
>> > -- HT<br>
>> ><br>
>> > On Fri, Feb 12, 2016 at 11:39 PM, Jorge Teixeira<br>
>> > <<a href="mailto:j.lopes.teixeira@gmail.com">j.lopes.teixeira@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> I decided to strike while the iron was hot and add the remaining tests<br>
>> >> for float.h.<br>
>> >><br>
>> >> 1) clang was missing the C11 mandatory *_HAS_SUBNORM macros, so I<br>
>> >> added them. The internal underscored versions are *_HAS_DENORM, and<br>
>> >> the Std. defines only "subnormal" and "unnormalized", so there could<br>
>> >> be, in theory, a discrepancy. I tried to learn more about APfloat<br>
>> >> supported types (IEEEsingle,PPCDoubleDouble,etc.) and how the<br>
>> >> underscored macros are generated in<br>
>> >> /lib/Preprocessor/InitPreprocessor.cpp, but it was inconclusive<br>
>> >> whether *_HAS_DENORM was added to mean subnormal like C11 expects, or<br>
>> >> not normalized. If the former, all is good, if the latter, my patch is<br>
>> >> wrong and C11 compliance is not achieved - the solution would be to<br>
>> >> study all supported fp implementations and add a new macro stating<br>
>> >> only the subnormal capabilities.<br>
>> >><br>
>> >> 2) FLT_EVAL_METHOD was only introduced in C99, so I changed float.h<br>
>> >> and float.c to reflect that.<br>
>> >><br>
>> >> 3) To help ensure that all macros were tested, I reordered them in<br>
>> >> float.h and float.c to match the C11 section. This added a little<br>
>> >> noise to this diff, but should be a one-off thing and simplify<br>
>> >> maintenance if further tests or new macros are added in the future.<br>
>> >><br>
>> >> 4) The tests for the remaining macros in float.h were added. I have<br>
>> >> some reservations about the ones involving floating point literals<br>
>> >> (*_MAX, *_EPSILON, *_MIN, *_TRUE_MIN) due to the conversions and<br>
>> >> rounding among the types. Not sure how to improve them without making<br>
>> >> assumptions and/or overcomplicating the test<br>
>> >><br>
>> >><br>
>> >> (<a href="https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/" rel="noreferrer" target="_blank">https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/</a>).<br>
>> >><br>
>> >> 5) There were no meaningful fp changes in the Technical Corrigenda for<br>
>> >> C89, so the current tests (c89,c99,c11) should suffice. Not sure if<br>
>> >> gnuxx modes are affected, but I don't expect them to define<br>
>> >> __STRICT_ANSI__, so all macros should be exposed and tested<br>
>> >> successfully.<br>
>> >><br>
>> >><br>
>> >> Cheers,<br>
>> >><br>
>> >> JT<br>
>> >><br>
>> >> On Fri, Feb 12, 2016 at 2:32 PM, Hubert Tong<br>
>> >> <<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
>> >> > Committed as r260710.<br>
>> >> ><br>
>> >> ><br>
>> >> > On Fri, Feb 12, 2016 at 9:53 AM, Hubert Tong<br>
>> >> > <<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
>> >> >><br>
>> >> >> Thanks Jorge. I'll work on committing this today.<br>
>> >> >><br>
>> >> >> -- HT<br>
>> >> >><br>
>> >> >> On Fri, Feb 12, 2016 at 12:10 AM, Jorge Teixeira<br>
>> >> >> <<a href="mailto:j.lopes.teixeira@gmail.com">j.lopes.teixeira@gmail.com</a>> wrote:<br>
>> >> >>><br>
>> >> >>> Hubert,<br>
>> >> >>><br>
>> >> >>> Thanks for the code review. Over the weekend I'll try to learn a<br>
>> >> >>> bit<br>
>> >> >>> more about using Phabricator, but for now I'll reply here, and<br>
>> >> >>> attach<br>
>> >> >>> a new patch.<br>
>> >> >>><br>
>> >> >>> a) *_MANT_DIG < 1 --> *_MANT_DIG < 2<br>
>> >> >>> That is a stricter check and I agree with your rationale. Done.<br>
>> >> >>><br>
>> >> >>> b) _MIN_EXP --> FLT_MIN_EXP<br>
>> >> >>> Done.<br>
>> >> >>><br>
>> >> >>> c) Remove _MIN_EXP and _MIN_10_EXP FLT,DBL,LDBL comparisons<br>
>> >> >>> Yes, as you and Richard pointed out the added mantissa bits can<br>
>> >> >>> compensate for the lack of increase of the exponent.<br>
>> >> >>> Already fixed in <a href="http://reviews.llvm.org/rL260639" rel="noreferrer" target="_blank">http://reviews.llvm.org/rL260639</a>.<br>
>> >> >>><br>
>> >> >>> d) *_MAX_EXP and *_MIN_EXP 2,-2 --> 1,-1<br>
>> >> >>> Done.<br>
>> >> >>><br>
>> >> >>> Richard, will do re: single patch for multiple files. Also, can you<br>
>> >> >>> close the bug report? Even if more tests for float.h get<br>
>> >> >>> added/changed, the original problem has been solved.<br>
>> >> >>><br>
>> >> >>> JT<br>
>> >> >>><br>
>> >> >>><br>
>> >> >>> On Thu, Feb 11, 2016 at 8:38 PM, Hubert Tong<br>
>> >> >>> <<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
>> >> >>> > Hi Jorge,<br>
>> >> >>> ><br>
>> >> >>> > I responded to the initial commit with some comments here:<br>
>> >> >>> > <a href="http://reviews.llvm.org/rL260577" rel="noreferrer" target="_blank">http://reviews.llvm.org/rL260577</a><br>
>> >> >>> ><br>
>> >> >>> > -- HT<br>
>> >> >>> ><br>
>> >> >>> > On Thu, Feb 11, 2016 at 7:53 PM, Jorge Teixeira<br>
>> >> >>> > <<a href="mailto:j.lopes.teixeira@gmail.com">j.lopes.teixeira@gmail.com</a>><br>
>> >> >>> > wrote:<br>
>> >> >>> >><br>
>> >> >>> >> > You'll also need to change <float.h> to only provide<br>
>> >> >>> >> > DECIMAL_DIG<br>
>> >> >>> >> > in<br>
>> >> >>> >> > C99<br>
>> >> >>> >> > onwards.<br>
>> >> >>> >> Done!<br>
>> >> >>> >><br>
>> >> >>> >> > All of our -std versions are that standard plus applicable<br>
>> >> >>> >> > Defect<br>
>> >> >>> >> > Reports. So -std=c89 includes TC1 and TC2, but not Amendment 1<br>
>> >> >>> >> > (we<br>
>> >> >>> >> > have -std=c94 for that, but the only difference from our C89<br>
>> >> >>> >> > mode<br>
>> >> >>> >> > is<br>
>> >> >>> >> > the addition of digraphs).<br>
>> >> >>> >> I'll try to find the c89 TC2 and check if anything changed<br>
>> >> >>> >> regarding<br>
>> >> >>> >> these macros (unlikely).<br>
>> >> >>> >><br>
>> >> >>> >> > __STRICT_ANSI__ is defined if Clang has not been asked to<br>
>> >> >>> >> > provide<br>
>> >> >>> >> > extensions (either GNU extensions, perhaps via a flag like<br>
>> >> >>> >> > -std=gnu99,<br>
>> >> >>> >> > or MS extensions), and is used by C library headers to<br>
>> >> >>> >> > determine<br>
>> >> >>> >> > that<br>
>> >> >>> >> > they should provide a strictly-conforming set of declarations<br>
>> >> >>> >> > without<br>
>> >> >>> >> > extensions.<br>
>> >> >>> >> Ok, so if !defined(__STRICT__ANSI__) clang should always expose<br>
>> >> >>> >> "as<br>
>> >> >>> >> much as possible", including stuff from later versions of the<br>
>> >> >>> >> Std.<br>
>> >> >>> >> and/or eventual extensions, just as it now on float.h and<br>
>> >> >>> >> float.c,<br>
>> >> >>> >> right?<br>
>> >> >>> >><br>
>> >> >>> >> > Testing __STDC_VERSION__ for C94 makes sense if you're trying<br>
>> >> >>> >> > to<br>
>> >> >>> >> > detect whether Amendment 1 features should be provided.<br>
>> >> >>> >> Since this will affect only digraphs, I guess there is no need<br>
>> >> >>> >> (for<br>
>> >> >>> >> float.h, float.c).<br>
>> >> >>> >><br>
>> >> >>> >> >> 3) Lastly, can you expand (...)<br>
>> >> >>> >> ><br>
>> >> >>> >> > No, it does not mean that.<br>
>> >> >>> >> ><br>
>> >> >>> >> > For PPC64, long double is (sometimes) modeled as a pair of<br>
>> >> >>> >> > doubles.<br>
>> >> >>> >> > Under that model, the smallest normalized value for long<br>
>> >> >>> >> > double<br>
>> >> >>> >> > is<br>
>> >> >>> >> > actually larger than the smallest normalized value for double<br>
>> >> >>> >> > (remember that for a normalized value with exponent E, all<br>
>> >> >>> >> > numbers<br>
>> >> >>> >> > of<br>
>> >> >>> >> > the form 1.XXXXX * 2^E, with the right number of mantissa<br>
>> >> >>> >> > digits,<br>
>> >> >>> >> > are<br>
>> >> >>> >> > exactly representable, so increasing the number of mantissa<br>
>> >> >>> >> > bits<br>
>> >> >>> >> > without changing the number of exponent bits increases the<br>
>> >> >>> >> > magnitude<br>
>> >> >>> >> > of the smallest normalized positive number).<br>
>> >> >>> >> ><br>
>> >> >>> >> > The set of values of long double in this model *is* a superset<br>
>> >> >>> >> > of<br>
>> >> >>> >> > the<br>
>> >> >>> >> > set of values of double.<br>
>> >> >>> >> ><br>
>> >> >>> >> I see now, and removed the bogus tests. The patch should now<br>
>> >> >>> >> test<br>
>> >> >>> >> cleanly unless something needs DECIMAL_DIG but did not set the<br>
>> >> >>> >> appropriate std. level, or defined __STRICT__ANSI__.<br>
>> >> >>> >><br>
>> >> >>> >> Thanks for the learning experience,<br>
>> >> >>> >><br>
>> >> >>> >> JT<br>
>> >> >>> >><br>
>> >> >>> >><br>
>> >> >>> >><br>
>> >> >>> >> >> From /test/Preprocessor/init.cpp:<br>
>> >> >>> >> >> // PPC64:#define __DBL_MIN_EXP__ (-1021)<br>
>> >> >>> >> >> // PPC64:#define __FLT_MIN_EXP__ (-125)<br>
>> >> >>> >> >> // PPC64:#define __LDBL_MIN_EXP__ (-968)<br>
>> >> >>> >> >><br>
>> >> >>> >> >> This issue happened before<br>
>> >> >>> >> >><br>
>> >> >>> >> >><br>
>> >> >>> >> >><br>
>> >> >>> >> >> (<a href="https://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00262.html" rel="noreferrer" target="_blank">https://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00262.html</a>,<br>
>> >> >>> >> >> <a href="http://www.openwall.com/lists/musl/2013/11/15/1" rel="noreferrer" target="_blank">http://www.openwall.com/lists/musl/2013/11/15/1</a>), but all it<br>
>> >> >>> >> >> means<br>
>> >> >>> >> >> is<br>
>> >> >>> >> >> that ppc64 is not compliant with C without soft-float. The<br>
>> >> >>> >> >> test<br>
>> >> >>> >> >> is<br>
>> >> >>> >> >> valid and should stay, and if someone tries to compile for<br>
>> >> >>> >> >> ppc64<br>
>> >> >>> >> >> in<br>
>> >> >>> >> >> c89, c99 or c11 modes, clang should 1) use soft float (bad<br>
>> >> >>> >> >> idea),<br>
>> >> >>> >> >> 2)<br>
>> >> >>> >> >> issue a diagnostic saying that that arch cannot meet the<br>
>> >> >>> >> >> desired<br>
>> >> >>> >> >> C<br>
>> >> >>> >> >> standard without a big performance penalty - the diag should<br>
>> >> >>> >> >> be<br>
>> >> >>> >> >> suppressible with some special cmd line argument.<br>
>> >> >>> >> >> Thus, I added the tests back and the FAIL for PPC64 for the<br>
>> >> >>> >> >> time<br>
>> >> >>> >> >> being, with a comment. If you know of a way to skip only the<br>
>> >> >>> >> >> specific<br>
>> >> >>> >> >> *_MIN_EXP and *_MIN_10_EXP tests, please add it, because<br>
>> >> >>> >> >> there<br>
>> >> >>> >> >> might<br>
>> >> >>> >> >> be more similar cases in the future.<br>
>> >> >>> >> >><br>
>> >> >>> >> >> JT<br>
>> >> >>> >> >><br>
>> >> >>> >> >> On Thu, Feb 11, 2016 at 3:04 PM, Richard Smith<br>
>> >> >>> >> >> <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> >> >>> >> >> wrote:<br>
>> >> >>> >> >>> Thanks, I modified the test to also test C89 and C99 modes<br>
>> >> >>> >> >>> and<br>
>> >> >>> >> >>> committed this as r260577.<br>
>> >> >>> >> >>><br>
>> >> >>> >> >>> On Thu, Feb 11, 2016 at 11:29 AM, Jorge Teixeira<br>
>> >> >>> >> >>> <<a href="mailto:j.lopes.teixeira@gmail.com">j.lopes.teixeira@gmail.com</a>> wrote:<br>
>> >> >>> >> >>>> Here is a revised test, which I renamed to<br>
>> >> >>> >> >>>> c11-5_2_4_2_2p11.c<br>
>> >> >>> >> >>>> instead<br>
>> >> >>> >> >>>> of float.c because I am only checking a subset of what the<br>
>> >> >>> >> >>>> standard<br>
>> >> >>> >> >>>> mandates for float.h, and because there were similar<br>
>> >> >>> >> >>>> precedents,<br>
>> >> >>> >> >>>> like<br>
>> >> >>> >> >>>> test/Preprocessor/c99-*.c. Feel free to override, though.<br>
>> >> >>> >> >>><br>
>> >> >>> >> >>> test/Preprocessor/c99-* are an aberration. The goal would be<br>
>> >> >>> >> >>> that<br>
>> >> >>> >> >>> this<br>
>> >> >>> >> >>> test grows to cover all of the parts of float.h that we<br>
>> >> >>> >> >>> define,<br>
>> >> >>> >> >>> so<br>
>> >> >>> >> >>> float.c seems like the appropriate name for it.<br>
>> >> >>> >> >>><br>
>> >> >>> >> >>>> The first part checks for basic compliance with the<br>
>> >> >>> >> >>>> referred<br>
>> >> >>> >> >>>> C11<br>
>> >> >>> >> >>>> paragraph, the second for internal consistency between the<br>
>> >> >>> >> >>>> underscored<br>
>> >> >>> >> >>>> and exposed versions of the macros.<br>
>> >> >>> >> >>>> No attempt was made to support C99 or C89.<br>
>> >> >>> >> >>>><br>
>> >> >>> >> >>>> I am not very clear on the proper use of the whole lit.py /<br>
>> >> >>> >> >>>> RUN<br>
>> >> >>> >> >>>> framework, so someone should really confirm if what I wrote<br>
>> >> >>> >> >>>> is<br>
>> >> >>> >> >>>> correct. The goal was to test both hosted and freestanding<br>
>> >> >>> >> >>>> implementations with C11, and expect no diagnostics from<br>
>> >> >>> >> >>>> either.<br>
>> >> >>> >> >>><br>
>> >> >>> >> >>> We generally avoid testing hosted mode, because we don't<br>
>> >> >>> >> >>> want<br>
>> >> >>> >> >>> the<br>
>> >> >>> >> >>> success of our tests to depend on the libc installed on the<br>
>> >> >>> >> >>> host<br>
>> >> >>> >> >>> system.<br>
>> >> >>> >> >>><br>
>> >> >>> >> >>>> Thanks for the help,<br>
>> >> >>> >> >>>><br>
>> >> >>> >> >>>> JT<br>
>> >> >>> >> >>>><br>
>> >> >>> >> >>>> On Tue, Feb 9, 2016 at 5:56 PM, Richard Smith<br>
>> >> >>> >> >>>> <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> >> >>> >> >>>> wrote:<br>
>> >> >>> >> >>>>> On Tue, Feb 9, 2016 at 2:43 PM, Jorge Teixeira<br>
>> >> >>> >> >>>>> <<a href="mailto:j.lopes.teixeira@gmail.com">j.lopes.teixeira@gmail.com</a>> wrote:<br>
>> >> >>> >> >>>>>> Richard,<br>
>> >> >>> >> >>>>>><br>
>> >> >>> >> >>>>>> Can you be more specific?<br>
>> >> >>> >> >>>>>><br>
>> >> >>> >> >>>>>> I assume you mean something like my newly attached .h<br>
>> >> >>> >> >>>>>> file<br>
>> >> >>> >> >>>>>> that<br>
>> >> >>> >> >>>>>> tests<br>
>> >> >>> >> >>>>>> very basic implementation compliance (i.e., it's<br>
>> >> >>> >> >>>>>> required,<br>
>> >> >>> >> >>>>>> but<br>
>> >> >>> >> >>>>>> not<br>
>> >> >>> >> >>>>>> sufficient), but I would need a bit more guidance about<br>
>> >> >>> >> >>>>>> the<br>
>> >> >>> >> >>>>>> structure<br>
>> >> >>> >> >>>>>> of the file, how to perform the tests, and where to<br>
>> >> >>> >> >>>>>> exactly<br>
>> >> >>> >> >>>>>> place<br>
>> >> >>> >> >>>>>> and<br>
>> >> >>> >> >>>>>> name the file within test/Headers.<br>
>> >> >>> >> >>>>>><br>
>> >> >>> >> >>>>>> I some sort of template exists, or if someone else takes<br>
>> >> >>> >> >>>>>> point<br>
>> >> >>> >> >>>>>> and<br>
>> >> >>> >> >>>>>> makes it, I can "port" the attached p11 test cases. I am<br>
>> >> >>> >> >>>>>> unsure<br>
>> >> >>> >> >>>>>> of<br>
>> >> >>> >> >>>>>> how<br>
>> >> >>> >> >>>>>> to perform a more normative compliance - for example, to<br>
>> >> >>> >> >>>>>> assert<br>
>> >> >>> >> >>>>>> that<br>
>> >> >>> >> >>>>>> LDBL_DECIMAL_DIG is 21 on x86-64 and that indeed those<br>
>> >> >>> >> >>>>>> many<br>
>> >> >>> >> >>>>>> digits<br>
>> >> >>> >> >>>>>> are<br>
>> >> >>> >> >>>>>> guaranteed to be correct, etc. This is probably not<br>
>> >> >>> >> >>>>>> possible<br>
>> >> >>> >> >>>>>> /<br>
>> >> >>> >> >>>>>> does<br>
>> >> >>> >> >>>>>> not make sense.<br>
>> >> >>> >> >>>>><br>
>> >> >>> >> >>>>> That looks like a decent basic test for this. The test<br>
>> >> >>> >> >>>>> should<br>
>> >> >>> >> >>>>> be<br>
>> >> >>> >> >>>>> named<br>
>> >> >>> >> >>>>> something like test/Headers/float.c, and needs to contain<br>
>> >> >>> >> >>>>> a<br>
>> >> >>> >> >>>>> "RUN:"<br>
>> >> >>> >> >>>>> line so that the test runner infrastructure knows how to<br>
>> >> >>> >> >>>>> run<br>
>> >> >>> >> >>>>> it.<br>
>> >> >>> >> >>>>> You<br>
>> >> >>> >> >>>>> can look at test/Header/limits.cpp for an example of how<br>
>> >> >>> >> >>>>> this<br>
>> >> >>> >> >>>>> works.<br>
>> >> >>> >> >>>>><br>
>> >> >>> >> >>>>> We already have platform-specific tests that<br>
>> >> >>> >> >>>>> __LDBL_DECIMAL_DIG__ is<br>
>> >> >>> >> >>>>> the right value, so you could test the values are correct<br>
>> >> >>> >> >>>>> by<br>
>> >> >>> >> >>>>> checking<br>
>> >> >>> >> >>>>> that LDBL_DECIMAL_DIG == __LDBL_DECIMAL_DIG__.<br>
>> >> >>> >> >>>>><br>
>> >> >>> >> >>>>>> JT<br>
>> >> >>> >> >>>>>><br>
>> >> >>> >> >>>>>> On Tue, Feb 9, 2016 at 3:58 PM, Richard Smith<br>
>> >> >>> >> >>>>>> <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>> >> >>> >> >>>>>>> Patch looks good. Please also add a testcase to<br>
>> >> >>> >> >>>>>>> test/Headers.<br>
>> >> >>> >> >>>>>>><br>
>> >> >>> >> >>>>>>> On Tue, Feb 9, 2016 at 12:08 PM, Hubert Tong via<br>
>> >> >>> >> >>>>>>> cfe-commits<br>
>> >> >>> >> >>>>>>> <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
>> >> >>> >> >>>>>>>> I see no immediate issue with this patch, but I am not<br>
>> >> >>> >> >>>>>>>> one<br>
>> >> >>> >> >>>>>>>> of<br>
>> >> >>> >> >>>>>>>> the<br>
>> >> >>> >> >>>>>>>> usual<br>
>> >> >>> >> >>>>>>>> reviewers for this part of the code base.<br>
>> >> >>> >> >>>>>>>><br>
>> >> >>> >> >>>>>>>> -- HT<br>
>> >> >>> >> >>>>>>>><br>
>> >> >>> >> >>>>>>>><br>
>> >> >>> >> >>>>>>>> On Tue, Feb 9, 2016 at 2:56 PM, Jorge Teixeira<br>
>> >> >>> >> >>>>>>>> <<a href="mailto:j.lopes.teixeira@gmail.com">j.lopes.teixeira@gmail.com</a>><br>
>> >> >>> >> >>>>>>>> wrote:<br>
>> >> >>> >> >>>>>>>>><br>
>> >> >>> >> >>>>>>>>> Thanks Hubert. Somehow I omitted that prefix when<br>
>> >> >>> >> >>>>>>>>> typing<br>
>> >> >>> >> >>>>>>>>> the<br>
>> >> >>> >> >>>>>>>>> macros,<br>
>> >> >>> >> >>>>>>>>> and I did not noticed it when I was testing because on<br>
>> >> >>> >> >>>>>>>>> my<br>
>> >> >>> >> >>>>>>>>> arch<br>
>> >> >>> >> >>>>>>>>> DECIMAL_DIG is defined to be the LDBL version...<br>
>> >> >>> >> >>>>>>>>><br>
>> >> >>> >> >>>>>>>>> Updated patch is attached.<br>
>> >> >>> >> >>>>>>>>><br>
>> >> >>> >> >>>>>>>>> JT<br>
>> >> >>> >> >>>>>>>>><br>
>> >> >>> >> >>>>>>>>> On Tue, Feb 9, 2016 at 1:41 PM, Hubert Tong<br>
>> >> >>> >> >>>>>>>>> <<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
>> >> >>> >> >>>>>>>>> > There is a __LDBL_DECIMAL_DIG__ predefined macro.<br>
>> >> >>> >> >>>>>>>>> > __DECIMAL_DIG__ will<br>
>> >> >>> >> >>>>>>>>> > not<br>
>> >> >>> >> >>>>>>>>> > always be the same as __LDBL_DECIMAL_DIG__.<br>
>> >> >>> >> >>>>>>>>> ><br>
>> >> >>> >> >>>>>>>>> > -- HT<br>
>> >> >>> >> >>>>>>>>> ><br>
>> >> >>> >> >>>>>>>>> > On Mon, Feb 8, 2016 at 11:26 PM, Jorge Teixeira via<br>
>> >> >>> >> >>>>>>>>> > cfe-commits<br>
>> >> >>> >> >>>>>>>>> > <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >> Hi, I filed the bug<br>
>> >> >>> >> >>>>>>>>> >> (<a href="https://llvm.org/bugs/show_bug.cgi?id=26283" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=26283</a>) some<br>
>> >> >>> >> >>>>>>>>> >> time ago and nobody picked it up, so here is a<br>
>> >> >>> >> >>>>>>>>> >> trivial<br>
>> >> >>> >> >>>>>>>>> >> patch<br>
>> >> >>> >> >>>>>>>>> >> exposing<br>
>> >> >>> >> >>>>>>>>> >> the missing macros, that to the best of my ability<br>
>> >> >>> >> >>>>>>>>> >> were<br>
>> >> >>> >> >>>>>>>>> >> already<br>
>> >> >>> >> >>>>>>>>> >> present as the internal underscored versions.<br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >> Perhaps a more general bug about C11 floating point<br>
>> >> >>> >> >>>>>>>>> >> (lack<br>
>> >> >>> >> >>>>>>>>> >> of)<br>
>> >> >>> >> >>>>>>>>> >> conformance should be filed, so that some form of<br>
>> >> >>> >> >>>>>>>>> >> unit<br>
>> >> >>> >> >>>>>>>>> >> test/macro<br>
>> >> >>> >> >>>>>>>>> >> validation could be worked on, but this patch does<br>
>> >> >>> >> >>>>>>>>> >> scratch my<br>
>> >> >>> >> >>>>>>>>> >> current<br>
>> >> >>> >> >>>>>>>>> >> itch.<br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >> Successfully tested on x86-64 Xubuntu 14.04 with<br>
>> >> >>> >> >>>>>>>>> >> clang<br>
>> >> >>> >> >>>>>>>>> >> 3.8<br>
>> >> >>> >> >>>>>>>>> >> from the<br>
>> >> >>> >> >>>>>>>>> >> ppa, patched with the attached diff.<br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >> First contribution, so feel free to suggest<br>
>> >> >>> >> >>>>>>>>> >> improvements<br>
>> >> >>> >> >>>>>>>>> >> or<br>
>> >> >>> >> >>>>>>>>> >> point to<br>
>> >> >>> >> >>>>>>>>> >> more detailed step-by-step instructions/guidelines.<br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >> Cheers,<br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >> JT<br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >> _______________________________________________<br>
>> >> >>> >> >>>>>>>>> >> cfe-commits mailing list<br>
>> >> >>> >> >>>>>>>>> >> <a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
>> >> >>> >> >>>>>>>>> >><br>
>> >> >>> >> >>>>>>>>> ><br>
>> >> >>> >> >>>>>>>><br>
>> >> >>> >> >>>>>>>><br>
>> >> >>> >> >>>>>>>><br>
>> >> >>> >> >>>>>>>> _______________________________________________<br>
>> >> >>> >> >>>>>>>> cfe-commits mailing list<br>
>> >> >>> >> >>>>>>>> <a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
>> >> >>> >> >>>>>>>><br>
>> >> >>> >> >>>>>>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
>> >> >>> >> >>>>>>>><br>
>> >> >>> ><br>
>> >> >>> ><br>
>> >> >><br>
>> >> >><br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>