This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR c++/21930: Conversions in diagnostics


On 13 Jun 2005, Gabriel Dos Reis wrote:
> Roger Sayle <roger@eyesopen.com> writes:
> | testc.C: In function 'void foo(const A<N>&) [with int N = 0]':
> | testc.C:13:   instantiated from here
> | testc.C:9: error: no match for 'operator-' in '-((const A<0>&)((const A<0>*)a))'
>
> It is an improvement, but it is awfull :-)

Hehe.  Agreed.


> I'll follow up with a patch that reduces the noise.
> Is there a way to tell from an CONVERT_EXPR whether it is explicit or
> front-end generated?

Not that I know of.  It might be sufficient to determine whether the
cast is required for correctness, or perhaps even eliminate it from
the trees generated by the C++ front-end if it isn't.  For the former,
using STRIP_NOPS on the operand of the first cast may be sufficient.


> | template<int N>
> | void foo(const A<N> &a)
> | { -A<N>(a); } // { dg-error "\\(\\(const A<0>\\*\\)a\\)" "" }
>
> I think, you should just test for "-"...

The intention was to add a test that passed after this patch but
failed without it.  i.e. I wanted to explicitly test whether the
CONVERT_EXPR was handled and that it didn't generate a unary plus.
Testing for just "-" doesn't verify that the PR remains resolved.

If it's OK with you, I'll go ahead and check in the testcase as
written, and you can adjust the regular expression when you apply
the follow-up "noise reduction" patch, you describe above?


Thanks for the speedy review,

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]