From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119929 invoked by alias); 23 Sep 2015 07:02:52 -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 119884 invoked by uid 48); 23 Sep 2015 07:02:47 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/67192] Backward-goto in loop can get wrong line number Date: Wed, 23 Sep 2015 07:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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: cc 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-09/txt/msg01838.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67192 Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsm28 at gcc dot gnu.org, | |rth at gcc dot gnu.org --- Comment #13 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Patrick Palka from comment #12) > Would it be a good idea to make the C frontend behave more like the C++ > frontend w.r.t. updating input_location? The behavior of the C++ frontend > seems more sensible to me. And I think such a change would fix this PR. As far as I know, everything that reduces spurious differences between C and C++ FEs is welcome. Lexing at start-up is supposedly faster, thus any chang= es in that direction should be acceptable (but I'm not a C maintainer, so bett= er ask them). I'm afraid that wholesale changing the C FE behavior is going to lead to a = lot of subtle regressions. Using something like c_parser_peek_token_keep_input_location allows changing the code case by ca= se and being able to point out which commit introduced a bug. Removing uses of input_location throughout the compiler would also help. For example, by passing an explicit location to c_finish_loop and using that for the exit node. >>From gcc-bugs-return-497861-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 23 07:03:54 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 121929 invoked by alias); 23 Sep 2015 07:03:53 -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 121886 invoked by uid 48); 23 Sep 2015 07:03:49 -0000 From: "trippels at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for Date: Wed, 23 Sep 2015 07:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: trippels at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: miyuki at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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-09/txt/msg01839.txt.bz2 Content-length: 440 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67649 Markus Trippelsdorf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #14 from Markus Trippelsdorf --- fixed