Hubert,

Ok on keeping the tests simple.
I removed the parentheses and transformed the fp checks into _Static_assert.

JT



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

Reply via email to