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: Wed, 21 Mar 2018 12:01:58 -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>
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.
Jason