On Thu, Mar 22, 2018 at 4:14 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Mar 21, 2018 at 12:01:58PM -0400, Jason Merrill wrote: >> On Wed, Mar 21, 2018 at 4:42 AM, Jakub Jelinek <ja...@redhat.com> wrote: >> > On Tue, Mar 20, 2018 at 05:00:34PM -0400, Jason Merrill wrote: >> >> On Mon, Mar 19, 2018 at 3:50 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> >> > +int a(__attribute__((b((int)__builtin_inf() * 1ULL / auto)))); >> >> >> >> This seems like another situation like 84610 and 84642 that Alex sent >> >> a patch for, of 'auto' in an attribute wrongly being treated as an >> >> implicit template parameter. As I suggested in response to his patch, >> >> we ought to disable auto_is_implicit_function_parm_p within an >> >> attribute-specifier. >> > >> > Ok, for this specific testcase I'll wait for Alex. That doesn't mean >> > the FIX_TRUNC_EXPR handling isn't completely wrong though. >> > So, shall we fix it anyway, or remove or just gcc_unreachable ()? >> > It was added in PR51150 (it couldn't work even at that point, >> > cp_build_unary_op would use wrong return type even back then), but the >> > testcase never invokes this anymore, uses CAST_EXPR, STATIC_CAST_EXPR etc. >> > instead. >> >> Hmm, I think remove. It should then hit the gcc_unreachable() in >> tsubst_copy. > > To my surprise, with latest Alex' changes tsubst_copy_and_build is still > called with FIX_TRUNC_EXPR (the (int) __builtin_inf () expression)
He hadn't yet checked in the relevant change, "Disable auto_is_implicit_function_template_parm_p while parsing attributes". That should happen soon. > but with > the following patch we don't ICE, because args is NULL and > tsubst_copy starts with: > 14945 if (t == NULL_TREE || t == error_mark_node || args == NULL_TREE) > 14946 return t; > So, do you still want the FIX_TRUNC_EXPR handling removed or fixed (as done > in the first patch)? Hmm, let's make it gcc_unreachable then. Jason
