[Bug c/66415] New: ice in location_column_from_byte_offset

[Bug c/66415] New: ice in location_column_from_byte_offset

[dcb314 at hotmail dot com]

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

            Bug ID: 66415
           Summary: ice in location_column_from_byte_offset
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 35695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35695&action=edit
C source code

gcc trunk dated 20150603 does this with the attached code

ctfCompress.c: In function ‘ctfCompress2’:
ctfCompress.c:271:4: internal compiler error: Segmentation fault
0xbcea5f crash_signal
        ../../src/trunk/gcc/toplev.c:380
0x58af2b location_column_from_byte_offset
        ../../src/trunk/gcc/c-family/c-format.c:89
0x58af2b location_from_offset
        ../../src/trunk/gcc/c-family/c-format.c:148
0x58b126 format_type_warning
        ../../src/trunk/gcc/c-family/c-format.c:2683
0x58bb8c check_format_types
        ../../src/trunk/gcc/c-family/c-format.c:2627

c-format.c:89 is

  if (*c != '"')

so maybe a reasonable bodge is to ensure c != NULL before use.
>From gcc-bugs-return-488068-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 04 08:17:37 2015
Return-Path: <gcc-bugs-return-488068-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 82525 invoked by alias); 4 Jun 2015 08:17:37 -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 82510 invoked by uid 48); 4 Jun 2015 08:17:33 -0000
From: "neleai at seznam dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66416] New: Regression: string::find 3.5 times slower than memrchr
Date: Thu, 04 Jun 2015 08:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: neleai at seznam dot cz
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-66416-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-06/txt/msg00400.txt.bz2
Content-length: 1172

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

            Bug ID: 66416
           Summary: Regression: string::find 3.5 times slower than memrchr
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: neleai at seznam dot cz
  Target Milestone: ---

Same problem as with strstr also applies here. As we know length we could
compare that to memrchr. Again instead simply calling that an implementation is
3.5 times slower on my sandy_bridge.

#include <cstring>
#include <cstdlib>
#include <string>
using namespace std;

int
main()
{
  int i;
  char s[10000];
  for (i = 0; i < 10000; i++)
    s[i] = ((unsigned) rand() % 128) + 1;
  s[9999] = 0;
  int sum = 0;
  std::string foo = s;
  std::string bar;
  char *needle = strdup("needle");

  for (i = 0; i < 5000000; i++)
    {
      needle[0] = ((unsigned) rand() % 128) + 1;
#ifdef MEMRCHR
      sum += (long) memrchr(s, needle[0],9999);
#else
      sum += foo.find_last_of(needle[0]);
#endif
    }
  return sum;
}

[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-04
                 CC|                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |6.0
            Summary|ice in                      |[6 Regression] ice in
                   |location_column_from_byte_o |location_column_from_byte_o
                   |ffset                       |ffset
     Ever confirmed|0                           |1

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed.

The problem is that we don't check the return value of
location_get_source_line.

[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Thus:

--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -142,9 +142,11 @@ location_from_offset (location_t loc, int offset)
   expanded_location s = expand_location_to_spelling_point (loc);
   int line_width;
   const char *line = location_get_source_line (s, &line_width);
+  if (line == NULL)
+    return loc;
   line += s.column - 1 ;
   line_width -= s.column - 1;
-  unsigned int column = 
+  unsigned int column =
     location_column_from_byte_offset (line, line_width, (unsigned) offset);

   return linemap_position_for_loc_and_offset (line_table, loc, column);

Manuel, does that look fine to you?

Most likely started with r223470.  Trying to reduce ...

[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
void
fn1 (void)
{
  __builtin_printf                               
("xxxxxxxxxxxxxxxxx%dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx");
}

[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #2)
> Manuel, does that look fine to you?

I wonder why line is NULL, but even if it can only happen due to bugs in other
parts of the compiler, we should not ICE here. Thus, your patch is the right
thing to do in my opinion.
>From gcc-bugs-return-488080-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 04 09:18:24 2015
Return-Path: <gcc-bugs-return-488080-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 53001 invoked by alias); 4 Jun 2015 09:18:24 -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 52969 invoked by uid 48); 4 Jun 2015 09:18:20 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66418] New: Optimize set_intersection when one list is much smaller and the other has random access
Date: Thu, 04 Jun 2015 09:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: glisse 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: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-66418-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-06/txt/msg00412.txt.bz2
Content-length: 812

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

            Bug ID: 66418
           Summary: Optimize set_intersection when one list is much
                    smaller and the other has random access
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Computing the intersection of sorted lists of size N1 and N2 is done in time
N1+N2. When we have random access to the second list, it is also possible to
search each element of the first list in the second one in time N1*log(N2),
which is faster when N1 is much smaller than N2.

[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Oops, the patch does not fixed the reduced case, so something else is needed as
well :(.

[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Mon Jun  8 15:16:12 2015
New Revision: 224236

URL: https://gcc.gnu.org/viewcvs?rev=224236&root=gcc&view=rev
Log:
        PR c/66415
        * c-format.c (location_from_offset): Return LOC if LINE is null.

        * line-map.c (linemap_position_for_loc_and_offset): Remove
        linemap_assert_fails; reverse conditions.

        * gcc.dg/cpp/pr66415-1.c: New test.
        * gcc.dg/cpp/pr66415-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/cpp/pr66415-1.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr66415-2.c
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-format.c
    trunk/gcc/testsuite/ChangeLog
    trunk/libcpp/ChangeLog
    trunk/libcpp/line-map.c

[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #9 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.

[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Author: manu
Date: Mon Sep 21 14:52:09 2015
New Revision: 227975

URL: https://gcc.gnu.org/viewcvs?rev=227975&root=gcc&view=rev
Log:
Handle lines encoded into several maps in linemap_position_for_loc_and_offset

linemap_position_for_loc_and_offset() tries to generate a location_t
encoding a column offset from the current location, for example, point
to a certain character inside a string. This is trivial to do when the
new location "fits within" the map of the original location. However,
it may happen that the (long) line corresponding to the original
location is encoded in several maps, thus the new location should
actually be encoded in a subsequent map from the original location.
This patch detects this case and adjusts the map correspondingly.

(This shows that the line-map representation is quite wasteful in this
case, because line-maps always start at column 0. That is, map[0]
highest location may encode up to line 8 column 80, then
map[1]->start_location starts encoding at line 8 column 0. Thus, there
are two location_t values that point to the same source location.)

libcpp/ChangeLog:

2015-09-21  Manuel López-Ibáñez  <manu@gcc.gnu.org>

        PR c/66415
        * line-map.c (linemap_position_for_loc_and_offset): Handle the
        case of long lines encoded in multiple maps.

gcc/testsuite/ChangeLog:

2015-09-21  Manuel López-Ibáñez  <manu@gcc.gnu.org>

        PR c/66415
        * gcc.dg/cpp/pr66415-1.c: Test column number.



Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/cpp/pr66415-1.c
    trunk/libcpp/ChangeLog
    trunk/libcpp/line-map.c
>From gcc-bugs-return-497747-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 21 15:10:40 2015
Return-Path: <gcc-bugs-return-497747-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8678 invoked by alias); 21 Sep 2015 15:10:39 -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 8649 invoked by uid 48); 21 Sep 2015 15:10:36 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/67671] New: restrict pointer reference looses restrict
Date: Mon, 21 Sep 2015 15:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: vries 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-67671-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/msg01725.txt.bz2
Content-length: 1811

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

            Bug ID: 67671
           Summary: restrict pointer reference looses restrict
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test-case test.c:
...
void
f (int *__restrict__ &__restrict__ p)
{
  *p = 1;
}
...

When compiling the test-case with g++ -O2, we find one clique/base annotation
at ealias:
...
void f(int* __restrict__&) (intD.9 * restrict & restrict pD.2252)
{
  intD.9 * _3;

  # VUSE <.MEM_1(D)>
  # PT = nonlocal escaped
  _3 = MEM[(intD.9 * restrict &)p_2(D) clique 1 base 1];

  # .MEM_4 = VDEF <.MEM_1(D)>
  *_3 = 1;
...

If we write an equivalent example using a struct with pointer field instead:
...
struct ps {
  int *__restrict__ p;
}

f (struct ps &__restrict__ ps)
{
  *(ps.p) = 1;
}
...
we get two clique/base annotations at ealias (after fixing PR67666).

I think the two examples are similar enough to expect two clique/base
annotations at ealias for the first example.

Using this demonstrator patch, we manage that:
...
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 94016b9..fa7108a 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -5684,6 +5684,9 @@ create_variable_info_for_1 (tree decl, const char *name)
       vi->fullsize = tree_to_uhwi (declsize);
       vi->size = vi->fullsize;
       vi->is_full_var = true;
+      if (POINTER_TYPE_P (TREE_TYPE (decl))
+         && TYPE_RESTRICT (TREE_TYPE (decl)))
+       vi->only_restrict_pointers = 1;
       fieldstack.release ();
       return vi;
     }
...