From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13239 invoked by alias); 26 Mar 2015 15:09:31 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 13196 invoked by uid 48); 26 Mar 2015 15:09:27 -0000 From: "ethouris at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/65448] Allow for cascade includes in error messages 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: c++ X-Bugzilla-Version: 4.9.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ethouris at gmail dot com X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg02983.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65448 --- Comment #2 from Michal Malecki --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #1) > Which tools? Shouldn't those tools be fixed instead?=20 The problem is that it's very easy to interpret the format that every line matches: :[:]: This is generally understood by all tools, and it's a format that can be al= so easily generated. This is a simple and general rule that can be claimed acr= oss the tools and it has been used as an informal standard since always. Anythi= ng 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 pref= er > 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, whi= le leaving the default behavior as is, should that not be clear enough. Just l= ike 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=65581 --- Comment #5 from Rainer Emrich --- (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