This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Fix FIX_TRUNC_EXPR instantiation (PR c++/84942)
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Thu, 22 Mar 2018 14:02:01 -0400
- Subject: Re: [C++ PATCH] Fix FIX_TRUNC_EXPR instantiation (PR c++/84942)
- References: <20180319195041.GR8577@tucnak> <CADzB+2=H65k2RwsfA5OhuY3A_yyPCN==_NFZRMbn_S8D3ejPTQ@mail.gmail.com> <20180321084251.GG8577@tucnak> <CADzB+2ko=ZzkhH4MOorSmgN89gwxheBiHxy-=KPO+HO_V-XeNg@mail.gmail.com> <20180322081458.GQ8577@tucnak>
On Thu, Mar 22, 2018 at 4:14 AM, Jakub Jelinek <jakub@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 <jakub@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 <jakub@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