[Bug middle-end/43631] New: var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[Bug middle-end/43631] New: var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu dot org]

Seen on ia64-unknown-linux, but probably reproducible elsewhere, also:

$ cat t.c
typedef unsigned int UDItype __attribute__ ((mode (DI)));
typedef int TItype __attribute__ ((mode (TI)));

struct DWstruct {UDItype low, high;};
typedef union
{
  struct DWstruct s;
  TItype ll;
} DWunion;

TItype
__multi3 (TItype u, TItype v)
{
  const DWunion uu = {.ll = u};
  const DWunion vv = {.ll = v};
  DWunion w = {.ll = ({DWunion __w; __asm__ ("xma.hu %0 = %2, %3, f0\n\txma.l
%1 = %2, %3, f0" : "=&f" (__w.s.high), "=f" (__w.s.low) : "f" (uu.s.low), "f"
(vv.s.low)); __w.ll; })};
  w.s.high += (uu.s.low * vv.s.high + uu.s.high * vv.s.low);
  return w.ll;
}
$ ./cc1 -quiet -g -O2 t.c
t.c: In function '__multi3':
t.c:19:1: error: insn 111 outside of basic blocks has non-NULL bb field
t.c:19:1: error: insn 110 outside of basic blocks has non-NULL bb field
t.c:19: confused by earlier errors, bailing out


Needs a patch to var-tracking.c to expose the problem:
Index: var-tracking.c
===================================================================
--- var-tracking.c      (revision 157942)
+++ var-tracking.c      (working copy)
@@ -115,6 +115,8 @@
 #include "pointer-set.h"
 #include "recog.h"

+#undef ENABLE_CHECKING
+#define ENABLE_CHECKING 1
 /* var-tracking.c assumes that tree code with the same value as VALUE rtx code
    has no chance to appear in REG_EXPR/MEM_EXPRs and isn't a decl.
    Currently the value is the same as IDENTIFIER_NODE, which has such
@@ -8489,6 +8491,7 @@ variable_tracking_main (void)

   flag_var_tracking_assignments = save;

+  verify_flow_info ();
   return ret;
 }


This comes from emit_notes_for_differences. I have no idea what the purpose is
of the notes between basic blocks. Apparently the CFG has to be frozen at this
point, or the notes make no sense to begin with. But it's also not clear to me
where the notes should be emitted.

Help sought from a VTA guy, i.e. Jakub or Alexandre :-)


-- 
           Summary: var-tracking inserts notes with non-NULL BLOCK_FOR_INSN
                    in between basic blocks
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: wrong-debug
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: steven at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu dot org]

------- Comment #1 from steven at gcc dot gnu dot org  2010-07-17 22:56 -------
Jakub, please do not forget about this one for stage1 GCC 4.6.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-17 22:56:39
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Sun Feb  1 21:56:03 2015
New Revision: 220336

URL: https://gcc.gnu.org/viewcvs?rev=220336&root=gcc&view=rev
Log:
    Backported from mainline
    2015-01-27  Jakub Jelinek  <jakub@redhat.com>

    PR rtl-optimization/61058
    * jump.c (cleanup_barriers): Update basic block boundaries
    if BLOCK_FOR_INSN is non-NULL on PREV.

    * gcc.dg/pr61058.c: New test.

    2013-04-16  Steven Bosscher  <steven@gcc.gnu.org>

    PR middle-end/43631
    * jump.c (cleanup_barriers): Use reorder_insns_nobb to avoid making
    the moved barrier the tail of the basic block it follows.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr61058.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/jump.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shenhan at google dot com

--- Comment #27 from Uroš Bizjak <ubizjak at gmail dot com> ---
*** Bug 60141 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-474062-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 20 15:33:15 2015
Return-Path: <gcc-bugs-return-474062-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25267 invoked by alias); 20 Jan 2015 15:33: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 25052 invoked by uid 48); 20 Jan 2015 15:32:58 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/60141] ICE in i386.c distance_non_agu_define_in_bb
Date: Tue, 20 Jan 2015 15:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: RESOLVED
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 resolution
Message-ID: <bug-60141-4-xyMIi8DigM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60141-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60141-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-01/txt/msg02056.txt.bz2
Content-length: 773

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Teresa Johnson from comment #1)
> This appears to have been exposed, not caused, by the change to the
> pass ordering. It is in fact a duplicate of PR middle-end/43631, which
> was fixed on trunk by r197994 on 4/15/13. I will backport the fix to
> google-4_8.

Duplicate.

*** This bug has been marked as a duplicate of bug 43631 ***
>From gcc-bugs-return-474064-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 20 15:43:22 2015
Return-Path: <gcc-bugs-return-474064-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7814 invoked by alias); 20 Jan 2015 15:43:21 -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 7751 invoked by uid 48); 20 Jan 2015 15:43:14 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/63979] [openacc] undefined reference to main._omp_fn.x
Date: Tue, 20 Jan 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: other
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: openacc
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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 cc resolution
Message-ID: <bug-63979-4-c0UDxnKRi4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63979-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63979-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-01/txt/msg02058.txt.bz2
Content-length: 504

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |vries at gcc dot gnu.org
         Resolution|---                         |WORKSFORME

--- Comment #10 from vries at gcc dot gnu.org ---
Can't reproduce this with current trunk.

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Steven Bosscher <steven at gcc dot gnu.org> changed:

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

--- Comment #25 from Steven Bosscher <steven at gcc dot gnu.org> 2013-04-16 20:12:47 UTC ---
Three years. Three years! Apparently "wrong-debug" is more important
to fix than "wrong compiler"...  But oh well.  Fixed now.  var-tracking.c
now runs with TODO_verify_flow_info, so that the machine dependent reorg
passes don't inherit the messy excuse for a CFG that var-tracking used to
leave behind!

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #28673|0                           |1
        is obsolete|                            |
  Attachment #28890|0                           |1
        is obsolete|                            |
             Status|REOPENED                    |NEW
         AssignedTo|jakub at gcc dot gnu.org    |steven at gcc dot gnu.org

--- Comment #24 from Steven Bosscher <steven at gcc dot gnu.org> 2013-04-06 12:38:54 UTC ---
Created attachment 29814
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29814
Improve handling of BLOCK_FOR_INSN on notes

This is what I'm testing now. Looks good so far, so attaching here
in anticipation of success :-)

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #23 from Steven Bosscher <steven at gcc dot gnu.org> 2013-04-03 20:29:58 UTC ---
Time for another attempt please? Now that stage1 is open?

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |piotr5 at netscape dot net

--- Comment #22 from Uros Bizjak <ubizjak at gmail dot com> 2012-12-17 08:48:24 UTC ---
*** Bug 55714 has been marked as a duplicate of this bug. ***

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
   Target Milestone|---                         |4.9.0

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-12 10:00:55 UTC ---
Reopening, as the patch has been reverted.

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-12 09:56:28 UTC ---
Author: jakub
Date: Wed Dec 12 09:56:22 2012
New Revision: 194442

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194442
Log:
    PR target/55659
    Revert
    2012-12-11  Jakub Jelinek  <jakub@redhat.com>

    PR middle-end/43631
    * var-tracking.c (emit_note_insn_var_location): If insn is followed
    by BARRIER, put note after the BARRIER.
    (next_non_note_insn_var_location): Skip over BARRIERs.
    (emit_notes_in_bb): If call is followed by BARRIER, put note after
    the BARRIER.

    2012-12-06  Jakub Jelinek  <jakub@redhat.com>

    PR middle-end/43631
    * var-tracking.c (emit_note_insn_var_location, emit_notes_in_bb):
    Clear BLOCK_FOR_INSN on notes emitted in between basic blocks,
    don't adjust BB_END when inserting note after BB_END of some bb.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-11 10:49:24 UTC ---
Fixed.

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-11 10:41:55 UTC ---
Author: jakub
Date: Tue Dec 11 10:41:44 2012
New Revision: 194392

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194392
Log:
    PR middle-end/43631
    PR bootstrap/55615
    * var-tracking.c (emit_note_insn_var_location): If insn is followed
    by BARRIER, put note after the BARRIER.
    (next_non_note_insn_var_location): Skip over BARRIERs.
    (emit_notes_in_bb): If call is followed by BARRIER, put note after
    the BARRIER.

    * g++.dg/other/pr43631.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/other/pr43631.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/var-tracking.c

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #17 from Igor Zamyatin <izamyatin at gmail dot com> 2012-12-10 08:02:54 UTC ---
(In reply to comment #15)
> But, double checking dwarf2out.c reveals that we could indeed emit the notes
> after BARRIER instead if there is any.  So I'm leaning towards this patch.

Atom bootstrap is ok with this patch

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #16 from Uros Bizjak <ubizjak at gmail dot com> 2012-12-07 12:46:45 UTC ---
*** Bug 55615 has been marked as a duplicate of this bug. ***

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-07 12:11:24 UTC ---
Created attachment 28890
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28890
gcc48-pr43631.patch

No, initially I've fixed this up in cleanup_barriers, to allow
NOTE_INSN_CALL_ARG_LOCATION in between noreturn CALL_INSN and following
BARRIER, which is what var-tracking was emitting.
But, double checking dwarf2out.c reveals that we could indeed emit the notes
after BARRIER instead if there is any.  So I'm leaning towards this patch.

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #14 from Steven Bosscher <steven at gcc dot gnu.org> 2012-12-07 11:59:15 UTC ---
(In reply to comment #13)
> Please hold on with that, seems BB_END is BARRIER, which is wrong.
> Starting with distilling a testcase...

Perhaps Alex' is right that the real problem is in how BLOCK_FOR_INSN
is handled in add_insn_after and add_insn_before.  Jakub, does the
following make sense to you?

Index: emit-rtl.c
===================================================================
--- emit-rtl.c  (revision 194229)
+++ emit-rtl.c  (working copy)
@@ -3845,19 +3845,25 @@ add_insn_after (rtx insn, rtx after, bas
       gcc_assert (stack);
     }

-  if (!BARRIER_P (after)
-      && !BARRIER_P (insn)
-      && (bb = BLOCK_FOR_INSN (after)))
+  /* If the new insn is a barrier, bb should be NULL because a barrier
+     is never inside a basic block.  Also avoid emitting double barriers.  */
+  if (BARRIER_P (insn))
+    gcc_checking_assert (bb == NULL && !BARRIER_P (after));
+  /* Otherwise, try to deduce a basic block from AFTER.  */
+  else if (!bb
+          && !BARRIER_P (after)
+          && BLOCK_FOR_INSN (after) != NULL
+          && after != BB_END (BLOCK_FOR_INSN (after)))
+    bb = BLOCK_FOR_INSN (after);
+
+  if (bb)
     {
       set_block_for_insn (insn, bb);
       if (INSN_P (insn))
        df_insn_rescan (insn);
-      /* Should not happen as first in the BB is always
-        either NOTE or LABEL.  */
-      if (BB_END (bb) == after
-         /* Avoid clobbering of structure when creating new BB.  */
-         && !BARRIER_P (insn)
-         && !NOTE_INSN_BASIC_BLOCK_P (insn))
+      /* Move BB_END from AFTER to INSN unless INSN is a note (a note cannot
+        be the end a basic block).  */
+      if (BB_END (bb) == after && !NOTE_P (insn))
        BB_END (bb) = insn;
     }

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-07 10:30:30 UTC ---
Please hold on with that, seems BB_END is BARRIER, which is wrong.  Starting
with distilling a testcase...

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #12 from Igor Zamyatin <izamyatin at gmail dot com> 2012-12-07 10:24:04 UTC ---
Oh, right, in this case just more checks are needed for
distance_non_agu_define_in_bb in i386.c. I'll add them. Thanks!

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-07 10:22:05 UTC ---
Yeah, BLOCK_FOR_INSN is invalid on BARRIER, reproduced with a RTL checking
build now, where RTL checking fails.  Looking into it.

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[stevenb.gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #10 from stevenb.gcc at gmail dot com <stevenb.gcc at gmail dot com> 2012-12-07 10:16:49 UTC ---
On Fri, Dec 7, 2012 at 11:11 AM, izamyatin at gmail dot com wrote:
> Looks like there is some garbage in BLOCK_FOR_INSN field for barrier
> instruction...

A BARRIER  doesn't even have a BLOCK_FOR_INSN. It's not an insn, after all.

Where/how do you end up looking at BLOCK_FOR_INSN for a BARRIER?

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Igor Zamyatin <izamyatin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |izamyatin at gmail dot com

--- Comment #9 from Igor Zamyatin <izamyatin at gmail dot com> 2012-12-07 10:11:28 UTC ---
Fix led to bootstrap failure with --with-arch=core2 --with-cpu=atom flags. It
happens for
/export/gnu/import/git/gcc-test-ia32/bld/./gcc/xgcc -shared-libgcc
-B/export/gnu/import/git/gcc-test-ia32/bld/./gcc -nostdinc++
-L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src/.libs
-B/usr/local/i686-linux/bin/ -B/usr/local/i686-linux/lib/ -isystem
/usr/local/i686-linux/include -isystem /usr/local/i686-linux/sys-include
-I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/../libgcc
-I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux
-I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=eh_personality.lo -g -O2 -D_GNU_SOURCE -c
../../../../src-trunk/libstdc++-v3/libsupc++/eh_personality.cc  -fPIC -DPIC
-D_GLIBCXX_SHARED -o eh_personality.o

Stack is

0x8b290da distance_non_agu_define_in_bb
    ../../src-trunk/gcc/config/i386/i386.c:16945
0x8b2928f distance_non_agu_define
    ../../src-trunk/gcc/config/i386/i386.c:17003
0x8b2968f ix86_lea_outperforms
    ../../src-trunk/gcc/config/i386/i386.c:17169
0x8b29994 ix86_use_lea_for_mov(rtx_def*, rtx_def**)
    ../../src-trunk/gcc/config/i386/i386.c:17279
0x8c5704c output_78
    ../../src-trunk/gcc/config/i386/i386.md:2191
0x85a6ae7 get_insn_template(int, rtx_def*)
    ../../src-trunk/gcc/final.c:1939
0x85a7ee0 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
    ../../src-trunk/gcc/final.c:2792
0x85a69b1 final(rtx_def*, _IO_FILE*, int)
    ../../src-trunk/gcc/final.c:1908
0x85aa397 rest_of_handle_final
    ../../src-trunk/gcc/final.c:4271
Please submit a full bug report,

Looks like there is some garbage in BLOCK_FOR_INSN field for barrier
instruction...

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-06 14:47:26 UTC ---
Fixed.

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-06 14:38:10 UTC ---
Author: jakub
Date: Thu Dec  6 14:37:59 2012
New Revision: 194252

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194252
Log:
    PR middle-end/43631
    * var-tracking.c (emit_note_insn_var_location, emit_notes_in_bb):
    Clear BLOCK_FOR_INSN on notes emitted in between basic blocks,
    don't adjust BB_END when inserting note after BB_END of some bb.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> 2012-11-13 23:38:55 UTC ---
(In reply to comment #5)
> Created attachment 28673 [details]
> gcc48-pr43631.patch
> 
> Is this what you meant?

Yes, that's exactly what I meant, thanks!

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-13 10:50:17 UTC ---
Created attachment 28673
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28673
gcc48-pr43631.patch

Is this what you meant?  make check-gcc RUNTESTFLAGS=guality.exp doesn't ICE
with it anymore with verify_flow_info (); at the beginning as well as end of
variable_tracking_main.
The notes are intentionally in between bbs, and it is assumed that the cfg
doesn't change after var-tracking pass, otherwise targets should disable
var-tracking at its standard spot and perform it at the end of machine reorg
pass (as e.g. ia64 and a few other targets do).

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #4 from Steven Bosscher <steven at gcc dot gnu.org> 2012-03-17 00:05:48 UTC ---
(In reply to comment #3)
> Jakub, please do not forget about this one for stage1 GCC 4.7.

Jakub, please do not forget about this one for stage1 GCC 4.8.

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #3 from Steven Bosscher <steven at gcc dot gnu.org> 2011-03-28 17:18:25 UTC ---
Jakub, please do not forget about this one for stage1 GCC 4.7.

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631

--- Comment #2 from Steven Bosscher <steven at gcc dot gnu.org> 2010-12-17 21:43:13 UTC ---
Jakub, ping?