[patch] Lazily provide a __float128 type in -std=gnu++11 mode

Eli Friedman eli.friedman at gmail.com
Thu Jun 20 15:19:16 PDT 2013


On Thu, Jun 20, 2013 at 3:10 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Thu, Jun 20, 2013 at 2:46 PM, Nico Weber <thakis at chromium.org> wrote:
>
>> On Thu, Jun 20, 2013 at 2:29 PM, Eli Friedman <eli.friedman at gmail.com>wrote:
>>
>>> On Thu, Jun 20, 2013 at 2:25 PM, Nico Weber <thakis at chromium.org> wrote:
>>>
>>>> Thanks for the quick review!
>>>>
>>>> On Thu, Jun 20, 2013 at 2:02 PM, Eli Friedman <eli.friedman at gmail.com>wrote:
>>>>
>>>>>  On Thu, Jun 20, 2013 at 1:45 PM, Nico Weber <thakis at chromium.org>wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> the attached patch lazily inserts a __float128 type the first time
>>>>>> one is looked up. This is needed to compile libstdc++4.7+ headers in
>>>>>> -std=gnu++11 mode. This fixes PR13530, see that bug for more information.
>>>>>>
>>>>>> Ok?
>>>>>>
>>>>>
>>>>> Is there any particular reason you're checking for GNUMode?
>>>>>
>>>>
>>>> Yes, type_traits only adds __is_floating_pointer_helper<__float128> if
>>>> __STRICT_ANSI__ isn't defined. InitPreprocessor.cpp defines this exactly if
>>>> !GNUMode. I changed the test to check for __STRICT_ANSI__ to maybe make
>>>> this a bit clearer.
>>>>
>>>>
>>>>> "variable has incomplete type '__float128'" is a terrible error
>>>>> message if someone actually tries to use __float128 with clang.  Can we do
>>>>> better?
>>>>>
>>>>
>>>> We can, attached.
>>>>
>>>>
>>>>
>>> Not sure if this catches all cases, but it's probably good enough.
>>>
>>> Otherwise, looks fine.
>>>
>>
>> r184476, thanks!
>>
>> I looked through a few diags in DiagnosticSemaKind mentioning "incomplete
>> type", and the ones I checked all go through RequireCompleteType (I checked
>> err_incomplete_type err_typecheck_decl_incomplete_type
>> err_invalid_incomplete_type_use err_bad_dynamic_cast_incomplete
>> err_incomplete_typeid err_new_incomplete_type warn_delete_incomplete
>> err_catch_incomplete_ptr err_catch_incomplete_ref err_throw_incomplete
>> err_throw_incomplete_ptr err_incomplete_object_call)
>>
>>
>>
> We pretty consistently go through RequireCompleteType, yes.  I was more
> worried about something like "x + *y", where y is a __float128*; I don't
> think we actually use RequireCompleteType to produce a diagnostic in that
> case.
>


Just checked; the following crashes with your patch:

void f(int x, __float128*y) { x+*y; }

=Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130620/3055f8f4/attachment.html>


More information about the cfe-commits mailing list