[Bug c++/49039] New: LLVM StringRef miscompilation with -O2

[Bug c++/49039] New: LLVM StringRef miscompilation with -O2

[ismail at namtrac dot org]

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

           Summary: LLVM StringRef miscompilation with -O2
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ismail@namtrac.org


Hi;

This is extracted from http://llvm.org/bugs/show_bug.cgi?id=9858 . I'll attach
the testcase from Nick Lewycky.

[/work/stuff]> g++ pr9858.cc 

[/work/stuff]> ./a.out 

[/work/stuff]> g++ -O2 pr9858.cc

[/work/stuff]> ./a.out          
[1]    2459 segmentation fault  ./a.out

[Bug c++/49039] LLVM StringRef miscompilation with -O2

[ismail at namtrac dot org]

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

--- Comment #1 from İsmail "cartman" Dönmez <ismail at namtrac dot org> 2011-05-18 09:29:32 UTC ---
Created attachment 24279
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24279
Testcase.

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |4.5.3
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2011.05.18 09:44:38
     Ever Confirmed|0                           |1
            Summary|LLVM StringRef              |[4.6/4.7 Regression] LLVM
                   |miscompilation with -O2     |StringRef miscompilation
                   |                            |with -O2
   Target Milestone|---                         |4.6.1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-18 09:44:38 UTC ---
Confirmed.

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-18 11:56:45 UTC ---
-O -ftree-vrp is broken, -O works.  VRP1 performs quite some jump threading.

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-18 14:27:08 UTC ---
Strange, I can't reproduce the segfault on x86_64-linux on the trunk and in 4.6
it doesn't segfault for me, but fails the assertion (-O2 or -O1 -ftree-vrp,
with -O1 or -O0 it works).

The problem seems to have started with:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164136
and got on the trunk fixed or made latent with:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171386

Smaller testcase without any includes:

template <class T1, class T2>
struct pair
{
  T1 first;
  T2 second;
  pair (const T1 & a, const T2 & b):first (a), second (b) {}
};

template <class T1, class T2>
inline pair <T1, T2>
make_pair (T1 x, T2 y)
{
  return pair <T1, T2> (x, y);
}

typedef __SIZE_TYPE__ size_t;
struct S
{
  const char *Data;
  size_t Length;
  static size_t min (size_t a, size_t b) { return a < b ? a : b; }
  static size_t max (size_t a, size_t b) { return a > b ? a : b; }
  S () :Data (0), Length (0) { }
  S (const char *Str) : Data (Str), Length (__builtin_strlen (Str)) {}
  S (const char *data, size_t length) : Data (data), Length (length) {}
  bool empty () const { return Length == 0; }
  size_t size () const { return Length; }
  S slice (size_t Start, size_t End) const
  {
    Start = min (Start, Length);
    End = min (max (Start, End), Length);
    return S (Data + Start, End - Start);
  }
  pair <S, S> split (char Separator) const
  {
    size_t Idx = find (Separator);
    if (Idx == ~size_t (0))
      return make_pair (*this, S ());
    return make_pair (slice (0, Idx), slice (Idx + 1, ~size_t (0)));
  }
  size_t find (char C, size_t From = 0) const
  {
    for (size_t i = min (From, Length), e = Length; i != e; ++i)
      if (Data[i] == C)
    return i;
    return ~size_t (0);
  }
};

void
Test (const char *arg)
{
  S Desc (arg);
  while (!Desc.empty ())
    {
      pair <S, S> Split = Desc.split ('-');
      S Token = Split.first;
      Desc = Split.second;
      if (Token.empty ())
    continue;
      Split = Token.split (':');
      S Specifier = Split.first;
      if (Specifier.empty ())
    __builtin_abort ();
    }
}

int
main ()
{
  Test ("-");
  return 0;
}

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-18 15:43:33 UTC ---
Apparently the second vrp pass incorrectly optimizes away the
if (Token.empty ()) continue;
test.

We have:

...
  Split$Length_126 = MIN_EXPR <Idx_44, Desc$Length_99>;
  if (Split$Length_126 == 0)
    goto <bb 17>;
  else
    goto <bb 9>;

<bb 9>:
  # Split$16$Length_97 = PHI <Split$16$Length_43(8)>
  # Split$16$Data_98 = PHI <Split$16$Data_45(8)>
  # Desc$Data_133 = PHI <Desc$Data_101(8)>
  # Split$Length_51 = PHI <Split$Length_126(8)>
...

in *.reassoc2.

*.vrp2 says:
Split$Length_24: ~[0, 0]  EQUIVALENCES: { Split$Length_126 } (1 elements)
Idx_44: VARYING
Split$Length_51: ~[0, 0]  EQUIVALENCES: { Split$Length_126 } (1 elements)
Desc$Length_99: VARYING
Split$Length_126: ~[0, 0]
...
Folding predicate Split$Length_126 == 0 to 0

Idx_44 and Desc$Length_99 are correctly VARYING, and it is correct
that Split$Length_51 is ~[0, 0], but it isn't equivalent to Split$Length_126
in the sense that it has to have the exact same value range.

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-18 16:04:51 UTC ---
BTW, on the trunk it isn't really fixed, but actually made even worse.  Not
only is the _126 == 0 test optimized into false, but additionally the test
above call to abort is optimized away too.
So, if main calls Test (":-"); instead of Test ("-"); (then the testcase should
abort rather than succeed), then for trunk with -O2 it incorrectly exits with 0
status.

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-18 16:46:09 UTC ---
Ok, I think I see the bug.  extract_range_from_binary_expr
is called with MIN_EXPR, where vr0 is ~[-1UL, -1UL] and vr1 is ~[0, 0]
and performs:
      /* For operations that make the resulting range directly
         proportional to the original ranges, apply the operation to
         the same end of each range.  */
      min = vrp_int_const_binop (code, vr0.min, vr1.min);
      max = vrp_int_const_binop (code, vr0.max, vr1.max);
which for MIN_EXPR unsurprisingly gives min 0 max 0 and thus returns ~[0, 0]
although it should have been VARYING in this case.  For PLUS we already give up
for VR_ANTI_RANGE earlier:
      if (code == PLUS_EXPR && vr0.type == VR_ANTI_RANGE)
        {
          set_value_range_to_varying (vr);
          return;
        }
but we don't do so for MIN_EXPR/MAX_EXPR.  For MAX_EXPR the same ranges will
give similarly incorrect result:
MAX_EXPR <~[-1UL, -1UL], ~[0, 0]> will yield ~[-1UL, -1UL] instead of correct
VARYING.  So, either we can just remove "code == PLUS_EXPR && " and give up
with VR_ANTI_RANGE always, or if there is a way to do something better we could
do so.  I'll think about it some more.  E.g. for MIN_EXPR/MAX_EXPR, if the anti
ranges are the same we can certainly return that anti range instead of VARYING.

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-18 16:55:20 UTC ---
Shorter testcase:

/* PR tree-optimization/49039 */
extern void abort (void);
int cnt;

__attribute__((noinline, noclone)) void
foo (unsigned int x, unsigned int y)
{
  unsigned int minv, maxv;
  if (x == 0 || y == -1U)
    return;
  minv = x < y ? x : y;
  maxv = x > y ? x : y;
  if (minv == 0)
    ++cnt;
  if (maxv == -1U)
    ++cnt;
}

int
main ()
{
  foo (-1U, 0);
  if (cnt != 2)
    abort ();
  return 0;
}

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-18 17:40:24 UTC ---
Created attachment 24286
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24286
gcc46-pr49039.patch

Untested fix.

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-18 20:43:48 UTC ---
Author: jakub
Date: Wed May 18 20:43:44 2011
New Revision: 173877

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173877
Log:
    PR tree-optimization/49039
    * tree-vrp.c (extract_range_from_binary_expr): For
    MIN_EXPR <~[a, b], ~[c, d]> and MAX_EXPR <~[a, b], ~[c, d]>
    return ~[MAX_EXPR <a, c>, MIN_EXPR <b, d>].

    * gcc.c-torture/execute/pr49039.c: New test.
    * gcc.dg/tree-ssa/pr49039.c: New test.
    * g++.dg/torture/pr49039.C: New test.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr49039.C
    branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr49039.c
    branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr49039.c
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/tree-vrp.c

[Bug c++/49039] [4.3/4.4/4.5 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|4.5.3                       |
            Version|4.6.0                       |4.6.1
   Target Milestone|4.6.1                       |4.3.6
            Summary|[4.6/4.7 Regression] LLVM   |[4.3/4.4/4.5 Regression]
                   |StringRef miscompilation    |LLVM StringRef
                   |with -O2                    |miscompilation with -O2

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-18 20:46:10 UTC ---
Fixed for 4.6+ so far.  The execute/pr49039.c testcase fails in 4.3/4.4/4.5 too
though and worked in 4.2, so regression on those branches too.

[Bug c++/49039] [4.6/4.7 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-18 20:39:08 UTC ---
Author: jakub
Date: Wed May 18 20:39:05 2011
New Revision: 173876

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173876
Log:
    PR tree-optimization/49039
    * tree-vrp.c (extract_range_from_binary_expr): For
    MIN_EXPR <~[a, b], ~[c, d]> and MAX_EXPR <~[a, b], ~[c, d]>
    return ~[MAX_EXPR <a, c>, MIN_EXPR <b, d>].

    * gcc.c-torture/execute/pr49039.c: New test.
    * gcc.dg/tree-ssa/pr49039.c: New test.
    * g++.dg/torture/pr49039.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/torture/pr49039.C
    trunk/gcc/testsuite/gcc.c-torture/execute/pr49039.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr49039.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vrp.c

[Bug c++/49039] [4.3/4.4/4.5 Regression] LLVM StringRef miscompilation with -O2

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/49039] [4.3/4.4/4.5 Regression] LLVM StringRef miscompilation with -O2

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.6                       |4.4.7

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-06-27 12:14:51 UTC ---
4.3 branch is being closed, moving to 4.4.7 target.

[Bug c++/49039] [4.4/4.5 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-19 12:44:49 UTC ---
Author: jakub
Date: Tue Jul 19 12:44:46 2011
New Revision: 176448

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176448
Log:
    Backport from mainline
    2011-05-18  Jakub Jelinek  <jakub@redhat.com>

    PR tree-optimization/49039
    * tree-vrp.c (extract_range_from_binary_expr): For
    MIN_EXPR <~[a, b], ~[c, d]> and MAX_EXPR <~[a, b], ~[c, d]>
    return ~[MAX_EXPR <a, c>, MIN_EXPR <b, d>].

    * gcc.c-torture/execute/pr49039.c: New test.
    * gcc.dg/tree-ssa/pr49039.c: New test.
    * g++.dg/torture/pr49039.C: New test.

Added:
    branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr49039.C
    branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr49039.c
    branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr49039.c
Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/gcc/tree-vrp.c

[Bug c++/49039] [4.4/4.5 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-19 19:27:34 UTC ---
Author: jakub
Date: Tue Jul 19 19:27:30 2011
New Revision: 176481

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176481
Log:
    Backport from mainline
    2011-05-18  Jakub Jelinek  <jakub@redhat.com>

    PR tree-optimization/49039
    * tree-vrp.c (extract_range_from_binary_expr): For
    MIN_EXPR <~[a, b], ~[c, d]> and MAX_EXPR <~[a, b], ~[c, d]>
    return ~[MAX_EXPR <a, c>, MIN_EXPR <b, d>].

    * gcc.c-torture/execute/pr49039.c: New test.
    * gcc.dg/tree-ssa/pr49039.c: New test.
    * g++.dg/torture/pr49039.C: New test.

Added:
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr49039.C
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr49039.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/tree-ssa/pr49039.c
Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_4-branch/gcc/tree-vrp.c

[Bug c++/49039] [4.4/4.5 Regression] LLVM StringRef miscompilation with -O2

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-19 19:49:48 UTC ---
Fixed.