[Bug debug/67192] New: Backward-goto in loop can get wrong line number

[Bug debug/67192] New: Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

            Bug ID: 67192
           Summary: Backward-goto in loop can get wrong line number
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arnez at linux dot vnet.ibm.com
  Target Milestone: ---

This bug causes a number of failures in the GDB test suite, e.g. with
checkpoint.exp.  I can reproduce it with the command line:

    gcc -fdump-tree-gimple-lineno -o foo.o -c -g foo.c

==== foo.c ====
extern int bar(void);
extern int baz(void);

extern int foo(int x);

int foo(int x)
{
  for (;;)
    {
      if (bar ())
        break;
      baz ();
    }
  baz (); /* Line 14. */
}

==== foo.c.004t.gimple ====
foo (int x)
[foo.c:7:1] {
  int D.1415;

  <D.1413>:
  [foo.c:10:11] D.1415 = bar ();
  [foo.c:10:10] if (D.1415 != 0) goto <D.1416>; else goto <D.1417>;
  <D.1416>:
  [foo.c:11:2] goto <D.1412>;
  <D.1417>:
  [foo.c:12:7] baz ();
  [foo.c:14:3] goto <D.1413>; /* <== WRONG! Should be [foo.c:13:5]. */
  <D.1412>:
  [foo.c:14:3] baz ();
}

[Bug debug/67192] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

Andreas Arnez <arnez at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmalcolm at redhat dot com

--- Comment #1 from Andreas Arnez <arnez at linux dot vnet.ibm.com> ---
Bisecting reveals that the problem was introduced with SVN commit #223098 on
trunk: "Implement -Wmisleading-indentation", by David Malcolm.

[Bug debug/67192] Backward-goto in loop can get wrong line number

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Confirmed; comparing output of build of
  r223097 (5c5c1f00cfc6fb2f2e6e3721629ee0391a9a95b4)
with
  r223098 (e5f01cbafce70120afe8f73df099dcc2796adcd7)

--- ../../../gcc-git-pr67192/build/gcc/foo.c.004t.gimple        2015-08-18
11:36:05.071129504 -0400
+++ foo.c.004t.gimple   2015-08-18 11:36:45.525201946 -0400
@@ -9,7 +9,7 @@ foo (int x)
   [../../foo.c:11:2] goto <D.1839>;
   <D.1844>:
   [../../foo.c:12:7] baz ();
-  [../../foo.c:13:5] goto <D.1840>;
+  [../../foo.c:14:3] goto <D.1840>;
   <D.1839>:
   [../../foo.c:14:3] baz ();
 }

[Bug debug/67192] Backward-goto in loop can get wrong line number

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Created attachment 36203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36203&action=edit
Patch

The issue seems to be in here in c_parser_for_statement:

  warn_for_misleading_indentation (for_loc, body_loc,
                                   c_parser_peek_token (parser)->location,
                                   c_parser_peek_token (parser)->type,
                                   "for");

where the calls to c_parser_peek_token can lead to input_location being
changed.

The attached patch (barely tested) restores the previous location for the
"goto" by saving and restoring input_location.

[Bug debug/67192] Backward-goto in loop can get wrong line number

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Problem also affects while statements; reproduced using example from comment #0
w with "for (;;)" replaced with "while (1)"

[Bug debug/67192] Backward-goto in loop can get wrong line number

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #3)
> Created attachment 36203 [details]
> Patch
> 
> The issue seems to be in here in c_parser_for_statement:
> 
>   warn_for_misleading_indentation (for_loc, body_loc,
> 				   c_parser_peek_token (parser)->location,
> 				   c_parser_peek_token (parser)->type,
> 				   "for");
> 
> where the calls to c_parser_peek_token can lead to input_location being
> changed.
> 
> The attached patch (barely tested) restores the previous location for the
> "goto" by saving and restoring input_location.

The given patch was on top of r223098
(e5f01cbafce70120afe8f73df099dcc2796adcd7), but doesn't apply to trunk; r226477
(9255be07ea1ac0e2f2991aa11cfc892474add3b2) changed the internal API for this,
so the save/restore of input_location would need updating for this.
>From gcc-bugs-return-495107-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 18 16:22:36 2015
Return-Path: <gcc-bugs-return-495107-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24050 invoked by alias); 18 Aug 2015 16:22:35 -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 23995 invoked by uid 48); 18 Aug 2015 16:22:32 -0000
From: "cubbi at cubbi dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67259] New: list-initialization of a reference fails to initialize char array from string literal
Date: Tue, 18 Aug 2015 16:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cubbi at cubbi dot 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-67259-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-08/txt/msg01249.txt.bz2
Content-length: 1223

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

            Bug ID: 67259
           Summary: list-initialization of a reference fails to initialize
                    char array from string literal
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cubbi at cubbi dot org
  Target Milestone: ---

The following is accepted by clang, intel, and msvc, but fails to compile with
gcc (HEAD 6.0.0 20150817)

struct agg { char str[20]; };
int main() {
    const agg& r {"foo"};
}

with the following diagnostic:

prog.cc: In function 'int main()':
prog.cc:3:24: error: invalid initialization of reference of type 'const agg&'
from expression of type '<brace-enclosed initializer list>'
     const agg& r {"foo"};
                        ^
prog.cc:3:16: warning: unused variable 'r' [-Wunused-variable]
     const agg& r {"foo"};
                ^
(this also prevents agg x; x = { "foo" };)

it appears to be one of the consequences of the changes to list initialization
recently made by http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1467

[Bug debug/67192] Backward-goto in loop can get wrong line number

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #36203|0                           |1
        is obsolete|                            |

--- Comment #6 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Created attachment 36204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36204&action=edit
Updated patch

Patch against trunk, saving/restoring input_location around the call to
c_parser_peek_token (parser) when populating token_indent_info.

[Bug debug/67192] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

--- Comment #7 from Andreas Arnez <arnez at linux dot vnet.ibm.com> ---
(In reply to David Malcolm from comment #3)

> The issue seems to be in here in c_parser_for_statement:
> 
>   warn_for_misleading_indentation (for_loc, body_loc,
> 				   c_parser_peek_token (parser)->location,
> 				   c_parser_peek_token (parser)->type,
> 				   "for");
> 
> where the calls to c_parser_peek_token can lead to input_location being
> changed.

I'm curious why this would lead to the problem seen, and whether that's working
as intended.  When looking at c_finish_loop(), I see:
              SET_EXPR_LOCATION (t, start_locus);
where t seems to be the GOTO_EXPR for the backward-goto and start_locus is the
location of the beginning of the loop.  Naively I would conclude that the
GOTO_EXPR is intended to have the location of the *beginning* of the loop.  But
neither before nor after your patch this seems to be the case?
>From gcc-bugs-return-495113-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 18 17:16:20 2015
Return-Path: <gcc-bugs-return-495113-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 88287 invoked by alias); 18 Aug 2015 17:16:20 -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 79470 invoked by uid 48); 18 Aug 2015 17:16:16 -0000
From: "moritz at klammler dot eu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67104] [5 regression] Constant expression factory function initializes std::array with static storage duration strangely
Date: Tue, 18 Aug 2015 17:16: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: 5.1.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: moritz at klammler dot eu
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67104-4-bvUVU8sUoK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67104-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67104-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-08/txt/msg01255.txt.bz2
Content-length: 168

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

--- Comment #14 from Moritz Klammler <moritz at klammler dot eu> ---
Thank you for taking care of this so quickly.

[Bug debug/67192] Backward-goto in loop can get wrong line number

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andreas Arnez from comment #7)
> I'm curious why this would lead to the problem seen, and whether that's
> working as intended.  When looking at c_finish_loop(), I see:
> 	      SET_EXPR_LOCATION (t, start_locus);
> where t seems to be the GOTO_EXPR for the backward-goto and start_locus is
> the location of the beginning of the loop.  Naively I would conclude that
> the GOTO_EXPR is intended to have the location of the *beginning* of the
> loop.  But neither before nor after your patch this seems to be the case?

No, it is the goto that corresponds to the loop exit:

      /* If we have an exit condition, then we build an IF with gotos either
         out of the loop, or to the top of it.  If there's no exit condition,
         then we just build a jump back to the top.  */
      exit = build_and_jump (&LABEL_EXPR_LABEL (top));

however, that exit does not have a valid location, thus it is added at add_stmt
a few lines below:

  if (CAN_HAVE_LOCATION_P (t) && code != LABEL_EXPR)
    {
      if (!EXPR_HAS_LOCATION (t))
        SET_EXPR_LOCATION (t, input_location);
    }

It is surprising that c_parser_peek_token changes input_location and this
doesn't mess up everything else. I wonder what is the benefit of having
input_location at all if we need to keep saving and restoring it all the time.

Does GCC work at all if input_location is saved and restored in
c_parser_peek_token? I guess not, it seems too much still relies in
input_location being magically right.
>From gcc-bugs-return-495125-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 18 19:56:58 2015
Return-Path: <gcc-bugs-return-495125-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 119616 invoked by alias); 18 Aug 2015 19:56:58 -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 119572 invoked by uid 55); 18 Aug 2015 19:56:54 -0000
From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
Date: Tue, 18 Aug 2015 19:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: fxcoudert at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: fxcoudert at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66936-4-WBIQ1xmV6g@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66936-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66936-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-08/txt/msg01267.txt.bz2
Content-length: 462

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

--- Comment #19 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Author: fxcoudert
Date: Tue Aug 18 19:56:20 2015
New Revision: 226988

URL: https://gcc.gnu.org/viewcvs?rev"6988&root=gcc&view=rev
Log:
        PR libfortran/66936
        * io/unix.c (__MINGW32__): Undefine HAVE_UMASK.

Modified:
    branches/gcc-5-branch/libgfortran/ChangeLog
    branches/gcc-5-branch/libgfortran/io/unix.c

[Bug debug/67192] Backward-goto in loop can get wrong line number

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #9 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #6)
> Created attachment 36204 [details]
> Updated patch
> 
> Patch against trunk, saving/restoring input_location around the call to
> c_parser_peek_token (parser) when populating token_indent_info.

I think c_parser_set_source_position_from_token and
cp_lexer_set_source_position_from_token exist for this purpose.

[Bug debug/67192] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

--- Comment #11 from Andreas Arnez <arnez at linux dot vnet.ibm.com> ---
Any news here?  AFAIK the problem still exists.

[Bug debug/67192] Backward-goto in loop can get wrong line number

[ppalka at gcc dot gnu.org]

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

--- Comment #12 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to Manuel López-Ibáñez from comment #8)
> > Does GCC work at all if input_location is saved and restored in
> > c_parser_peek_token? I guess not, it seems too much still relies in
> > input_location being magically right.
> 
> Perhaps you can add c_parser_peek_token_keep_input_location and use that
> where you are peeking the next token.

In the C++ frontend it looks like the entire file is lexed at startup and so
the cp_lexer_peek_token method does not change input_location (since
input_location is updated as a side effect of lexing a new token).  Instead,
the cp_lexer_consume_token method is responsible for updating input_location.

In the C frontend it looks like the reverse happens: tokens are lexed on demand
and so the c_parser_peek_token method does update input_location (as a side
effect of lexing the next token) and c_parser_consume_token does not change
input_location.

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.
>From gcc-bugs-return-497846-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 23 01:32:52 2015
Return-Path: <gcc-bugs-return-497846-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22887 invoked by alias); 23 Sep 2015 01:32:52 -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 22827 invoked by uid 48); 23 Sep 2015 01:32:47 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/67391] [SH] Convert clrt addc to normal add insn
Date: Wed, 23 Sep 2015 01:32: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo 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:
Message-ID: <bug-67391-4-aKHi0w9szu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67391-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67391-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-09/txt/msg01824.txt.bz2
Content-length: 824

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

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #3)
>
> Ugh, those checks look just wrong and I can't remind why I've
> added them.  33707 didn't do that and checked overlapping at
> the split condition only.  Perhaps I mixed up the final patch
> with the one of test codes to collect CSiBE results.  You can
> install the above patch as the rather obvious one, though I'm
> running "make -k check" on sh4-unknown-linux-gnu.  Sorry for
> adding that thinko.

No problem.  I'd like to wait for your test results though before committing.

I've just checked, the code is also present in GCC 5.  Because of the funny
side effects even with LRA disabled (this PR) I'd like to backport this to the
GCC 5 branch, too.

[Bug debug/67192] Backward-goto in loop can get wrong line number

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org,
                   |                            |rth at gcc dot gnu.org

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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 changes
in that direction should be acceptable (but I'm not a C maintainer, so better
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 case
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: <gcc-bugs-return-497861-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 121886 invoked by uid 48); 23 Sep 2015 07:03:49 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.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: <bug-67649-4-8K8S36DaYV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67649-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67649-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-09/txt/msg01839.txt.bz2
Content-length: 440

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
fixed

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |6.0

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Regression must have a target milestone (otherwise various scripts would not
recognize them as such, I think).
>From gcc-bugs-return-499043-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 08 16:44:30 2015
Return-Path: <gcc-bugs-return-499043-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 121013 invoked by alias); 8 Oct 2015 16:44:30 -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 120965 invoked by uid 48); 8 Oct 2015 16:44:27 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number
Date: Thu, 08 Oct 2015 16:44: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: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67192-4-m1ktvze3ga@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67192-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67192-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg00598.txt.bz2
Content-length: 416

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

--- Comment #15 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andreas Arnez from comment #11)
> Any news here?  AFAIK the problem still exists.

I still think the solution in comment #10 is the least invasive without being a
hack. But someone (you?) would need to submit a patch and get it approved by
the C maintainers.
>From gcc-bugs-return-499045-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 08 16:55:19 2015
Return-Path: <gcc-bugs-return-499045-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29900 invoked by alias); 8 Oct 2015 16:55:19 -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 27585 invoked by uid 48); 8 Oct 2015 16:55:15 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65913] [5 Regression] Linking failure without -latomic
Date: Thu, 08 Oct 2015 16:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-65913-4-D4abrngEoR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65913-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65913-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-10/txt/msg00600.txt.bz2
Content-length: 437

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 5.3 too.

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

--- Comment #16 from Andreas Arnez <arnez at linux dot vnet.ibm.com> ---
(In reply to Manuel López-Ibáñez from comment #15)
> (In reply to Andreas Arnez from comment #11)
> > Any news here?  AFAIK the problem still exists.
> 
> I still think the solution in comment #10 is the least invasive without
> being a hack. But someone (you?) would need to submit a patch and get it
> approved by the C maintainers.

Well, I'm rather a GDB- than a GCC developer.  My interest in this is to ensure
that GDB doesn't become completely useless ;-)
Also, I thought that David was a better candidate for fixing this because his
patch introduced the regression.

Anyway, if it helps speeding this up, and if nobody objects, I could give it a
try.  In this case I actually lean towards your suggestion from comment #13, to
pass an explicit location to c_finish_loop.  Somehow I don't like adding a
function like c_parser_peek_token_keep_input_location and then using it only
for this fix, just to get rid of it in the long run.  (Right?)
>From gcc-bugs-return-499082-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 09 10:54:13 2015
Return-Path: <gcc-bugs-return-499082-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21480 invoked by alias); 9 Oct 2015 10:54:12 -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 21427 invoked by uid 55); 9 Oct 2015 10:54:08 -0000
From: "ramana at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus
Date: Fri, 09 Oct 2015 10:54: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: ramana at gcc dot gnu.org
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-67366-4-DPQOTwtu8d@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67366-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67366-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-10/txt/msg00637.txt.bz2
Content-length: 1368

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

--- Comment #13 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Date: Fri Oct  9 10:53:31 2015
New Revision: 228643

URL: https://gcc.gnu.org/viewcvs?rev"8643&root=gcc&view=rev
Log:
[Patch PR target/67366 1/2] [ARM] - Add movmisalignhi / si patterns


This adds movmisalignhi and movmisalignsi expanders when unaligned
access is allowed by the architecture. This allows the mid-end
to expand to misaligned loads and stored.

Compared code generated for the Linux kernel and
it changes code generation for a handful of files all for the better
basically by reducing the stack usage.

Tested by :

1. armhf bootstrap and regression test - no regressions.
2.. arm-none-eabi cross build and regression test for

    {-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp}
    {-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard}
    {-marm/-mcpu=arm7tdmi/-mfloat-abi=soft}
    {-mthumb/-mcpu=arm7tdmi/-mfloat-abi=soft}

Will apply to trunk once 2/2 is approved.

regards
Ramana

2015-10-09  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR target/67366
        * config/arm/arm.md (movmisalign<mode>): New.
        * config/arm/iterators.md (HSI): New.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm.md
    trunk/gcc/config/arm/iterators.md

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[manu at gcc dot gnu.org]

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

--- Comment #17 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andreas Arnez from comment #16)
> Well, I'm rather a GDB- than a GCC developer.  My interest in this is to
> ensure that GDB doesn't become completely useless ;-)
> Also, I thought that David was a better candidate for fixing this because
> his patch introduced the regression.

I cannot force anyone to do anything, I was just pointing out what would be a
good strategy to get the result that you want.

> Anyway, if it helps speeding this up, and if nobody objects, I could give it
> a try.  In this case I actually lean towards your suggestion from comment

Nobody will ever object to people fixing bugs ;)

> #13, to pass an explicit location to c_finish_loop.  Somehow I don't like
> adding a function like c_parser_peek_token_keep_input_location and then
> using it only for this fix, just to get rid of it in the long run.  (Right?)

Sure, I haven't looked at implications of both solutions in detail. The thing
to remember is that the only people you need to convince are the MAINTAINERS of
C FE. If you have never contributed to GCC, this may be useful:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

You may also send a WIP patch to gcc-patches@ and CC the C FE maintainers, just
to get some early feedback.
>From gcc-bugs-return-499085-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 09 10:59:11 2015
Return-Path: <gcc-bugs-return-499085-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31203 invoked by alias); 9 Oct 2015 10:59:11 -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 31155 invoked by uid 48); 9 Oct 2015 10:59:07 -0000
From: "ramana at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus
Date: Fri, 09 Oct 2015 10:59: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: ramana at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-67366-4-Z67BhP3OSt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67366-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67366-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-10/txt/msg00640.txt.bz2
Content-length: 535

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |6.0

--- Comment #14 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Fixed on trunk - Yann please try and let us know.

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[manu at gcc dot gnu.org]

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

--- Comment #19 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #18)
> The "simpler" progression seems to be to remove code like
> 
>   if (CAN_HAVE_LOCATION_P (t) && code != LABEL_EXPR)
>     {
>       if (!EXPR_HAS_LOCATION (t))
>         SET_EXPR_LOCATION (t, input_location);
>     }
> 
> esp. code using input_location "delayed".

But you need still to set a location there and many times it is not clear how
to pass down the correct location to that point.
>From gcc-bugs-return-499091-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 09 11:32:06 2015
Return-Path: <gcc-bugs-return-499091-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 90230 invoked by alias); 9 Oct 2015 11:32:05 -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 90189 invoked by uid 48); 9 Oct 2015 11:32:02 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67876] [6 Regression] ICE when compiling Firefox 38
Date: Fri, 09 Oct 2015 11:32: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: bug_status cf_reconfirmed_on cc short_desc everconfirmed
Message-ID: <bug-67876-4-QUWS7kmzDw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67876-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67876-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-10/txt/msg00646.txt.bz2
Content-length: 850

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-10-09
                 CC|                            |trippels at gcc dot gnu.org
            Summary|ICE when compiling Firefox  |[6 Regression] ICE when
                   |38                          |compiling Firefox 38
     Ever confirmed|0                           |1

--- Comment #3 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
template <typename, void()> class ScopedPtr;
template <typename T, void(&Destroyer)()> ScopedPtr < T, Destroyer> a;

Might be related to PR67164.

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

--- Comment #20 from Andreas Arnez <arnez at linux dot vnet.ibm.com> ---
Posted a patch that is not as ambitious as completely getting rid of
input_location, but also doesn't require a new function like
c_parser_peek_token_keep_input_location():

  https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01132.html

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

--- Comment #21 from Andreas Arnez <arnez at linux dot vnet.ibm.com> ---
(In reply to Andreas Arnez from comment #20)
> Posted a patch that is not as ambitious as completely getting rid of
> input_location, but also doesn't require a new function like
> c_parser_peek_token_keep_input_location():
> 
>   https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01132.html

After investigating this further I recognized that this patch doesn't cover all
cases where the backward-goto is wrongly located.  Thus I've created a version
that basically follows the suggestion from comment #13, to pass an explicit
location to c_finish_loop:

  https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02393.html

I haven't checked whether there are still other cases where add_stmt needs to
use input_location as the default location for the given statement.  It should
probably be one goal to get rid of this default handling.