[Bug fortran/67936] New: Off-by-one columns in caret

["dmalcolm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 67936
           Summary: Off-by-one columns in caret
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In gcc/testsuite/gfortran.dg/associate_5.f03, if we enable
-fdiagnostics-show-caret, we get this diagnostic (amongst others):

associate_5.f03:33:6:

       y = 5 ! { dg-error "variable definition context" }
      1
associate_5.f03:32:20:

     ASSOCIATE (y => x) ! { dg-error "variable definition context" }
                    2
Error: Associate-name ‘y’ can not appear in a variable definition
context (assignment) at (1) because its target at (2) can not, either

Note how the carets 1 and 2 appear one column before the "y" and the "x" that
they refer to; I would have expected them to be one column to the right,
directly under the "y" and "x".

Noticed when porting Fortran to use a new implementation of
diagnostic_show_locus; this seems to be a pre-existing bug in the Fortran FE;
am updating my printer to faithfully print the (apparently erroneous)
locations.
>From gcc-bugs-return-499343-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 12 15:51:35 2015
Return-Path: <gcc-bugs-return-499343-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 90073 invoked by alias); 12 Oct 2015 15:51:34 -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 90038 invoked by uid 48); 12 Oct 2015 15:51:31 -0000
From: "Pidgeot18 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug gcov-profile/67937] New: gcov gives wrong results when negative counts are involved
Date: Mon, 12 Oct 2015 15:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: gcov-profile
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: Pidgeot18 at gmail dot com
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-67937-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/msg00898.txt.bz2
Content-length: 1673

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

            Bug ID: 67937
           Summary: gcov gives wrong results when negative counts are
                    involved
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: gcov-profile
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Pidgeot18 at gmail dot com
  Target Milestone: ---

This is hard to name correctly, since there's really a bigger bug here, and I'm
focusing on the lesser bug because it's easier for me to build a minimized test
case.

First the explanation: for whatever reason, sometimes gcov produces counts with
negative edges (that's a bug by itself). An minimized example of such a case
will be attached to the bug. In this scenario, the graph looks like this:

     1147 +-+ -42
   /----->|B|------\
  +-+     +-+     +-+
/>|A|      V 1189 |D| \
| +-+     +-+     +-+ |
|  \----->|C|------/  |
\     0   +-+ 1189    /
 \-------------------/
          23

(This is a result of an optimized loop, I don't have the corresponding code on
hand, sorry :-( ).

In this scenario, the loop detection code finds the following loops:
D -> A -> B -> C -> D: loop count = 23
D -> A -> B -> D: loop count = -42
D -> A -> C -> D: loop count = 0
A -> B -> C -> D -> A: loop count = 42
A -> B -> D -> A: loop count = 0
B -> C -> D -> A -> B: loop count = 0
C -> D -> A -> B -> C: loop count = 0

The last four loops are finding permutations of the three simple loops, which
is wrong (of course, the fact that one edge has a count of -42 in the first
place is wrong in the first place.