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

[Nico Weber]

The crash is fixed in r184498. I see what you mean. I suppose I could
insert another special case in Sema::InvalidOperands(), that'd help with
this problem but it again probably wouldn't catch everything.

Maybe it's good enough to have an ok diag for decls?


On Thu, Jun 20, 2013 at 3:41 PM, Nico Weber <thakis at chromium.org> wrote:

> Looking…
>
>
> On Thu, Jun 20, 2013 at 3:19 PM, Eli Friedman <eli.friedman at gmail.com>wrote:
>
>> 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/08df86dd/attachment.html>