Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

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
 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
>  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
>>  wrote:
>> > Committed as r260710.
>> >
>> >
>> > On Fri, Feb 12, 2016 at 9:53 AM, Hubert Tong
>> >  wrote:
>> >>
>> >> Thanks Jorge. I'll work on committing this today.
>> >>
>> >> -- HT
>> >>
>> >> On Fri, Feb 12, 2016 at 12:10 AM, Jorge Teixeira
>> >>  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
>> >>>  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
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> > You'll also need to change  to only provide DECIMAL_DIG
>> >>> >> > in
>> >>> >> > C99
>> >>> >> > onwards.
>> >>> >> Done!
>> >>> >>
>> >>> >> > All of our -std versions are that standard plus 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Hubert Tong via cfe-commits]

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 
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
>  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
> >  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
> >>  wrote:
> >> > Committed as r260710.
> >> >
> >> >
> >> > On Fri, Feb 12, 2016 at 9:53 AM, Hubert Tong
> >> >  wrote:
> >> >>
> >> >> Thanks Jorge. I'll work on committing this today.
> >> >>
> >> >> -- HT
> >> >>
> >> >> On Fri, Feb 12, 2016 at 12:10 AM, Jorge Teixeira
> >> >>  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 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

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

Jorge

On Sat, Feb 13, 2016 at 5:28 PM, Hubert Tong
 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 
> 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
>>  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
>> >  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
>> >>  wrote:
>> >> > Committed as r260710.
>> >> >
>> >> >
>> >> > On Fri, Feb 12, 2016 at 9:53 AM, Hubert Tong
>> >> >  wrote:
>> >> >>
>> >> >> Thanks Jorge. I'll work on committing this today.
>> >> >>
>> >> >> -- HT
>> >> >>
>> >> >> On Fri, Feb 12, 2016 at 12:10 AM, Jorge Teixeira
>> >> >>  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
>> >> 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Hubert Tong via cfe-commits]

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.

-- HT

On Sat, Feb 13, 2016 at 6:00 PM, Jorge Teixeira 
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
>  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
> >>  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
> >> >  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 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

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
 wrote:
> On Sat, Feb 13, 2016 at 7:10 PM, Hubert Tong
>  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
>>  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
>>>  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
>>> > 
>>> > 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
>>> >>  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
>>> >> >  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 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Hubert Tong via cfe-commits]

Thanks Jorge. I'll work on committing this today.

-- HT

On Fri, Feb 12, 2016 at 12:10 AM, Jorge Teixeira  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
>  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  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.X * 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
> >> 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

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
 wrote:
> Committed as r260710.
>
>
> On Fri, Feb 12, 2016 at 9:53 AM, Hubert Tong
>  wrote:
>>
>> Thanks Jorge. I'll work on committing this today.
>>
>> -- HT
>>
>> On Fri, Feb 12, 2016 at 12:10 AM, Jorge Teixeira
>>  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
>>>  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
>>> > 
>>> > wrote:
>>> >>
>>> >> > You'll also need to change  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 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

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.

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.

Thanks for the help,

JT

On Tue, Feb 9, 2016 at 5:56 PM, Richard Smith  wrote:
> On Tue, Feb 9, 2016 at 2:43 PM, Jorge Teixeira
>  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  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
>>>  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 
 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
>  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
> >  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

// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 %s
// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
// expected-no-diagnostics

/* Basic conformance checks against the N1570 draft of C11 Std. */
/*
5.2.4.2.2p11, pp. 30
*/
#include 
#if ((__STDC_VERSION__ >= 201112L) || !defined(__STRICT_ANSI__))

#ifndef FLT_RADIX
#error "Mandatory macro FLT_RADIX is 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Richard Smith via cfe-commits]

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
 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  wrote:
>> On Tue, Feb 9, 2016 at 2:43 PM, Jorge Teixeira
>>  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  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
  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 
> 
> 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
>>  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
>> >  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
>> >> 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Richard Smith via cfe-commits]

On Thu, Feb 11, 2016 at 3:42 PM, Jorge Teixeira
 wrote:
> Richard,
>
> Thanks and got it re: test filename and hosted mode.
>
> 1) AFAIK, C89/C90 does not define DECIMAL_DIG, so here is a revised
> patch, with minor comment modifications to explicitly list the (draft)
> normative references that I used.

You'll also need to change  to only provide DECIMAL_DIG in C99 onwards.

> 2) This might also be a good time to ask you what does clang aim for
> regarding C89/C90, since there are a few "updates" to it, namely
> Technical Corrigendum 1 (ISO/IEC 9899 TCOR1), 1994, Technical
> Corrigendum 2 (ISO/IEC 9899 TCOR2), 1996, and Normative Addendum (aka
> Amendment) 1, 1994 (sometimes known as C94/C95).

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

> Also, please clarify
> how they all relate to __STRICT_ANSI__ and whether the use of
> __STDC_VERSION__ <= 199409L should be encouraged/avoided.
> I assume that for C99 and C11 clang aims for the latest approved TC,
> and possibly a few approved but yet unpublished Defect Reports.

That's correct.

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

Testing __STDC_VERSION__ for C94 makes sense if you're trying to
detect whether Amendment 1 features should be provided.

> I could not find the above info on any docs, so perhaps it could be
> added in www/compatibility.html.
> For completion purposes, the GCC extension modes gnu90, gnu99, etc.
> should also be mentioned, although anything other than "unsupported"
> would open a new can of worms.
>
> 3) Lastly, can you expand on the removal of the *_MIN_EXP comparison
> (http://reviews.llvm.org/rL260610)? From N1570, 6.2.5p10:
> "The set of values of the type float is a subset of the set of values
> of the type double; the set of values of the type double is a subset
> of the set of values of the type long double". So if a larger-width
> type must be able to represent all narrower-width types values, would
> it not also imply that the min normalized exp for larger width types
> must be either equal or more negative?

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.X * 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.

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

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Richard Smith via cfe-commits]

On Thu, Feb 11, 2016 at 4:53 PM, Jorge Teixeira
 wrote:
>> You'll also need to change  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?

Yes, that's the idea.

>> 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.X * 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, committed as r260639.

(In future, it's preferable to submit a single patch for all affected
files rather than one patch per file.)

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

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

> You'll also need to change  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.X * 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  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
>>>  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  
 wrote:
> On Tue, Feb 9, 2016 at 2:43 PM, Jorge Teixeira
>  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 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

Richard,

Thanks and got it re: test filename and hosted mode.

1) AFAIK, C89/C90 does not define DECIMAL_DIG, so here is a revised
patch, with minor comment modifications to explicitly list the (draft)
normative references that I used.

2) This might also be a good time to ask you what does clang aim for
regarding C89/C90, since there are a few "updates" to it, namely
Technical Corrigendum 1 (ISO/IEC 9899 TCOR1), 1994, Technical
Corrigendum 2 (ISO/IEC 9899 TCOR2), 1996, and Normative Addendum (aka
Amendment) 1, 1994 (sometimes known as C94/C95). Also, please clarify
how they all relate to __STRICT_ANSI__ and whether the use of
__STDC_VERSION__ <= 199409L should be encouraged/avoided.
I assume that for C99 and C11 clang aims for the latest approved TC,
and possibly a few approved but yet unpublished Defect Reports.

I could not find the above info on any docs, so perhaps it could be
added in www/compatibility.html.
For completion purposes, the GCC extension modes gnu90, gnu99, etc.
should also be mentioned, although anything other than "unsupported"
would open a new can of worms.

3) Lastly, can you expand on the removal of the *_MIN_EXP comparison
(http://reviews.llvm.org/rL260610)? From N1570, 6.2.5p10:
"The set of values of the type float is a subset of the set of values
of the type double; the set of values of the type double is a subset
of the set of values of the type long double". So if a larger-width
type must be able to represent all narrower-width types values, would
it not also imply that the min normalized exp for larger width types
must be either equal or more negative?

>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  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
>  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  wrote:
>>> On Tue, Feb 9, 2016 at 2:43 PM, Jorge Teixeira
>>>  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. 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Hubert Tong via cfe-commits]

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

> > You'll also need to change  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.X * 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 
> 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
> >>>  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 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

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
 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 
> wrote:
>>
>> > You'll also need to change  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.X * 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 
>> >> 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
>> >>>  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 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

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.

JT

On Tue, Feb 9, 2016 at 3:58 PM, Richard Smith  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
>  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 
>> 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
>>>  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
>>> >  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
>>
/* From N1570 draft of C11 Std. */
/* 5.2.4.2.2p11, pp. 30 */

#include 
#if __STDC_VERSION__ >= 201112L || !defined(__STRICT_ANSI__)

#ifndef	FLT_RADIX
	#error "Macro FLT_RADIX missing"
#elif	FLT_RADIX < 2
	# error "Macro FLT_RADIX invalid"
#endif


#ifndef FLT_MANT_DIG
	#error "Macro FLT_MANT_DIG missing"
#elif	FLT_MANT_DIG < 1
	# error "Macro FLT_MANT_DIG invalid"
#endif
#ifndef DBL_MANT_DIG
	#error "Macro DBL_MANT_DIG missing"
#elif	DBL_MANT_DIG < 1
	# error "Macro DBL_MANT_DIG invalid"
#endif
#ifndef LDBL_MANT_DIG
	#error "Macro LDBL_MANT_DIG missing"
#elif	LDBL_MANT_DIG < 1
	# error "Macro LDBL_MANT_DIG invalid"
#endif
#if (FLT_MANT_DIG > DBL_MANT_DIG) || (DBL_MANT_DIG > LDBL_MANT_DIG)
	#error "Macro(s) FLT_MANT_DIG, DBL_MANT_DIG, LDBL_MANT_DIG invalid"
#endif


#ifndef FLT_DECIMAL_DIG
	#error "Macro FLT_DECIMAL_DIG missing"
#elif	FLT_DECIMAL_DIG < 6
	# error "Macro FLT_DECIMAL_DIG invalid"
#endif
#ifndef DBL_DECIMAL_DIG
	#error "Macro DBL_DECIMAL_DIG missing"
#elif	DBL_DECIMAL_DIG < 10
	# error "Macro DBL_DECIMAL_DIG invalid"
#endif
#ifndef LDBL_DECIMAL_DIG
	#error "Macro LDBL_DECIMAL_DIG missing"
#elif	LDBL_DECIMAL_DIG < 10
	# error "Macro LDBL_DECIMAL_DIG invalid"
#endif
#if (FLT_DECIMAL_DIG > DBL_DECIMAL_DIG) || (DBL_DECIMAL_DIG > LDBL_DECIMAL_DIG)
	#error "Macro(s) FLT_DECIMAL_DIG, DBL_DECIMAL_DIG, LDBL_DECIMAL_DIG invalid"
#endif


#ifndef	DECIMAL_DIG
	#error "Macro DECIMAL_DIG missing"
#elif	DECIMAL_DIG < 10
	# error "Macro DECIMAL_DIG invalid"
#endif


#ifndef FLT_DIG
	#error "Macro FLT_DIG missing"
#elif	FLT_DIG < 6
	# error "Macro FLT_DIG invalid"
#endif
#ifndef DBL_DIG
	#error "Macro DBL_DIG missing"
#elif	DBL_DIG < 10
	# error "Macro DBL_DIG invalid"
#endif
#ifndef LDBL_DIG
	#error "Macro LDBL_DIG missing"
#elif	LDBL_DIG < 10
	# error "Macro LDBL_DIG invalid"
#endif
#if (FLT_DIG > DBL_DIG) || (DBL_DIG > LDBL_DIG)
	#error "Macro(s) FLT_DIG, DBL_DIG, LDBL_DIG invalid"
#endif


#ifndef FLT_MIN_EXP
	#error "Macro _MIN_EXP 

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Hubert Tong via cfe-commits]

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

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

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
 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
>  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
>>
>
Index: lib/Headers/float.h
===
--- lib/Headers/float.h	(revision 260263)
+++ lib/Headers/float.h	(working copy)
@@ -68,6 +68,9 @@
 #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
 
@@ -119,6 +122,9 @@
 #  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 */
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Hubert Tong via cfe-commits]

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

Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

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
Index: lib/Headers/float.h
===
--- lib/Headers/float.h	(revision 260194)
+++ lib/Headers/float.h	(working copy)
@@ -68,6 +68,9 @@
 #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
 
@@ -119,6 +122,9 @@
 #  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 __DECIMAL_DIG__
 #endif
 
 #endif /* __FLOAT_H */
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Richard Smith via cfe-commits]

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
 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 
> 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
>>  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
>> >  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
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Richard Smith via cfe-commits]

On Tue, Feb 9, 2016 at 2:43 PM, Jorge Teixeira
 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  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
>>  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 
>>> 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
  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
 >  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
>>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits