This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Fix for PR58201
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Richard Biener <rguenther at suse dot de>, Bernd Schmidt <bernds at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, jason at redhat dot com
- Date: Sat, 7 Sep 2013 13:16:04 +0200
- Subject: Re: [RFC] Fix for PR58201
- Authentication-results: sourceware.org; auth=none
- References: <20130904160409 dot GF20687 at kam dot mff dot cuni dot cz> <52276493 dot 9070706 at codesourcery dot com> <20130904170918 dot GI20687 at kam dot mff dot cuni dot cz> <c1c2f51e-89b8-4632-a075-3f82464e973c at email dot android dot com> <20130905230516 dot GB14285 at kam dot mff dot cuni dot cz> <5229FC71 dot 2090709 at oracle dot com> <20130907080308 dot GA8074 at kam dot mff dot cuni dot cz> <20130907082846 dot GC4841 at kam dot mff dot cuni dot cz> <522AEB26 dot 5060701 at oracle dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Sat, Sep 07, 2013 at 11:00:22AM +0200, Paolo Carlini wrote:
> and thanks for the analysis, now I understand the issue a little more.
> On 09/07/2013 10:28 AM, Jan Hubicka wrote:
> >So it is just an accident that the line info is output sanely (if
> >line 9 is sane, I don't exactly know)
> I would say that in general it's definitely sane, because that is
> the instantiation point. And 10 is wrong, too late, it points to the
> closing bracket.
> However, I notice that clang doesn't even try to output a message
> having to do with line 9: if I understand correctly, if that
> operator cannot be mangled, that happens unconditionally, isn't
> something that may succeed. Thus I wonder if, instead of outputting
> garbage line numbers we could at least suppress in such cases the
> whole "In instantiation of..." part of the diagnostic, it would be
> better than garbage. Do we have a mechanism for that?
> Now I also understand that this should be a very uncommon error
> message, but, I'm wondering, is it possible that other errors, for
> other issues, are also affected? That is, other diagnostic happening
> very late and sensitive to the recent rework?
As I wrote in the PR, IMHO mangle_decl should
location_t save_location = input_location;
input_location = DECL_SOURCE_LOCATION (decl);
input_location = save_location;
around the call, and perhaps also all the error calls inside of
mangle.c should be actually error_at (EXPR_LOC_OR_HERE (expr), ...),
so that if expr has locus, it will print it at that point, otherwise
will use locus of the decl.