This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Fix for PR58201
- From: Jan Hubicka <hubicka at ucw dot cz>
- 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 11:09:09 +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>
> Hi Honza,
> 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?
It seems to be what older GCCs are doing, too.
> 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?
Any use of source_location from DECL_ASSEMBLER_NAME hanghook is wrong, since
source_location may point anywhere when the lazy mangling is triggered. It
surprised me that DECL_ASSEMBLER_NAME triggers error/warning messages. It is
up to backend when on at what symbols it will call it, so it is definitely
source of inconsistency. So from design point of view I would preffer C++
FE to output these errors somewhere else. But practicaly we can perhaps just
modify the message to not expect thelocation?
I am just leaving for flight to Pisa, will be back online at the hotel.