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 <[email protected]> wrote: > Looking… > > > On Thu, Jun 20, 2013 at 3:19 PM, Eli Friedman <[email protected]>wrote: > >> On Thu, Jun 20, 2013 at 3:10 PM, Eli Friedman <[email protected]>wrote: >> >>> On Thu, Jun 20, 2013 at 2:46 PM, Nico Weber <[email protected]> wrote: >>> >>>> On Thu, Jun 20, 2013 at 2:29 PM, Eli Friedman >>>> <[email protected]>wrote: >>>> >>>>> On Thu, Jun 20, 2013 at 2:25 PM, Nico Weber <[email protected]>wrote: >>>>> >>>>>> Thanks for the quick review! >>>>>> >>>>>> On Thu, Jun 20, 2013 at 2:02 PM, Eli Friedman <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> On Thu, Jun 20, 2013 at 1:45 PM, Nico Weber <[email protected]>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 >> > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
