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: Jakub Jelinek <jakub at redhat dot com>
- To: Jason Merrill <jason 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 09:42:51 +0100
- 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>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
Jakub