[Bug c++/65448] Allow for cascade includes in error messages

["ethouris at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448

--- Comment #2 from Michal Malecki <ethouris at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #1)

> Which tools? Shouldn't those tools be fixed instead? 

The problem is that it's very easy to interpret the format that every line
matches:

<filename>:<line>[:<column>]: <error message>

This is generally understood by all tools, and it's a format that can be also
easily generated. This is a simple and general rule that can be claimed across
the tools and it has been used as an informal standard since always. Anything
that doesn't match this format is generally treated as "to be ignored" or
simply "not a compiler error message" (for example, an echoed command line from
make). These lines starting with "In file included from" do not undergo any
stable format definition and are not easy parseable, especially if we regard
that the message isn't necessarily in English.

> Perhaps this would have been a better way to do it (although I would prefer
> the notes after the error, and it could just not say "note:", to be
> consistent with what we do for template instantiations),

Whatever. I just gave this as an example - at least be it something that
matches the above format.

> if we could start over again, but now GCC has always behaved like this,

So you can imagine how sick and tired some are :D

Actually I'm using gcc since about 2.6 version and I cannot recall any tool
that understands these "In file included from" messages.

> if we change it, it may break other tools.

Should there be any - but even if, I think I spoke about "having an option to
change the format". I meant command-line option to change the behavior, while
leaving the default behavior as is, should that not be clear enough. Just like
there's for example a -fmessage-length option.

BTW. If I'm not mistaken, there are more cases, when error messages from the
compiler may be interesting, but they don't match the error message format and
are therefore skipped by the tools.
>From gcc-bugs-return-481840-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 26 15:12:39 2015
Return-Path: <gcc-bugs-return-481840-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21539 invoked by alias); 26 Mar 2015 15:12:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21492 invoked by uid 48); 26 Mar 2015 15:12:35 -0000
From: "rainer@emrich-ebersheim.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'
Date: Thu, 26 Mar 2015 15:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rainer@emrich-ebersheim.de
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65581-4-RZ3iNAhtxB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65581-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65581-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02984.txt.bz2
Content-length: 588

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide581

--- Comment #5 from Rainer Emrich <rainer@emrich-ebersheim.de> ---
(In reply to Kai Tietz from comment #4)
> This issue is related to building of crt. so it doesn't have something to do
> with gcc's lto in first hand.

That leaves the question, why on earth is this only exposed by current trunk?
I did a quick check. The issue is present on trunk with all mingw-w64 runtimes
I tested, back to October last year. OTOH 4.9.2 and 4.8.4 are fine with my
current mingw-w64 runtime.

So, what's the issue? I'm a little bit nervous.

Rainer