[Bug rtl-optimization/66444] New: [5/6 Regression] Miscompilation of Xen since r211078

[Bug rtl-optimization/66444] New: [5/6 Regression] Miscompilation of Xen since r211078

[jakub at gcc dot gnu.org]

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

            Bug ID: 66444
           Summary: [5/6 Regression] Miscompilation of Xen since r211078
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: vmakarov at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---

void foo (unsigned long);
int bar (unsigned long);
unsigned long a, c, d, f, g;
volatile void *b;
int e;
struct S { unsigned long p, q, r; void *v; };
void fn2 (struct S *x);

__attribute__((noinline, noclone)) void *
fn1 (struct S *x)
{
  unsigned long y = x->q;
  unsigned long z = a;
  do
    {
      if ((x->q + 2 & 1UL << 63 - 10) <= 2)
return (void *) 0;
    }
  while (y = z != x->q);
  return x->v ? x->v : (void *) 0;
}

int
baz (void)
{
  foo (f);
  struct S *x = (struct S *) 0xe000000000UL;
  x += bar (f);
  fn1 (x);
  fn2 (x);
  return 0;
}

reduced from Xen is miscompiled at -O2 starting with r211078 on x86_64-linux.
Still in *.optimized dump we have:
  _6 = bar (f.0_4);
  _7 = (long unsigned int) _6;
  _8 = _7 * 32;
  x_9 = 962072674304B + _8;
  fn1 (x_9);
  fn2 (x_9);
(note the same value, constant + 32 * result of bar) is passed to both fn1 and
fn2.
But starting with *.reload we get:
        movabsq $962072674304, %r8
        salq    $5, %rax
        leaq    (%r8,%rax), %rdi
        call    fn1
        movq    %r8, %rdi
        call    fn2
which is wrong, it passes just the constant, without the added 32 * bar (), to
the second function.

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-06
   Target Milestone|---                         |5.2
     Ever confirmed|0                           |1

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |vries at gcc dot gnu.org

--- Comment #1 from vries at gcc dot gnu.org ---
Tentative patch:
...
diff --git a/gcc/postreload.c b/gcc/postreload.c
index 7ecca15..1cc7b14 100644
--- a/gcc/postreload.c
+++ b/gcc/postreload.c
@@ -1352,9 +1352,12 @@ reload_combine (void)
       if (CALL_P (insn))
        {
          rtx link;
+         HARD_REG_SET used_regs;
+
+         get_call_reg_set_usage (insn, &used_regs, call_used_reg_set);

          for (r = 0; r < FIRST_PSEUDO_REGISTER; r++)
-           if (call_used_regs[r])
+           if (TEST_HARD_REG_BIT (used_regs, r))
              {
                reg_state[r].use_index = RELOAD_COMBINE_MAX_USES;
                reg_state[r].store_ruid = reload_combine_ruid;
...

Output with patch:
...
        movabsq $962072674304, %r8
        salq    $5, %rax
        addq    %rax, %r8
        movq    %r8, %rdi
        call    fn1
        movq    %r8, %rdi
        call    fn2
...

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Looks like reload_cse_move2add could use a similar fix.

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The testcase has been reduced from much larger testcase, the content of the
fn1 function matters only for the IPA-RA analysis, so can be changed to
something else, and the other functions supposedly can be defined in a
dg-additional-sources file.  Though, the hardcoding of the constant in the
pointer arithmetics makes it more difficult (the testcase would have to
simulate there is something mapped at that address (or mmap there something -
the constant can be changed to something more suitable).

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
Created attachment 35713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35713&action=edit
tentative patch with testcase

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> The testcase has been reduced from much larger testcase, the content of the
> fn1 function matters only for the IPA-RA analysis, so can be changed to
> something else, and the other functions supposedly can be defined in a
> dg-additional-sources file.  Though, the hardcoding of the constant in the
> pointer arithmetics makes it more difficult (the testcase would have to
> simulate there is something mapped at that address (or mmap there something
> - the constant can be changed to something more suitable).

I managed to write the testcase in such a way that it doesn't dereference the
hardcoded pointer.

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The 0xe000000000UL constant is probably not very good for ilp32 targets.  Try
some < 4GB one if it still reproduces without the patch, or conditionalize it
on __SIZEOF_POINTER__.

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
> The 0xe000000000UL constant is probably not very good for ilp32 targets. 
> Try some < 4GB one if it still reproduces without the patch, or
> conditionalize it on __SIZEOF_POINTER__.

I've tried with 0xe0000000U. The m64 case still reproduces. 

With -m32 -mregparm=1 we get:
...
        .cfi_startproc
        call    bar
        sall    $4, %eax
        leal    -536870912(%eax), %edx
        movl    %edx, %eax
        call    fn1
        movl    %edx, %eax
        call    fn2
        xorl    %eax, %eax
        ret
...
The reload_combine doesn't trigger for this case.

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to vries from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > The 0xe000000000UL constant is probably not very good for ilp32 targets. 
> > Try some < 4GB one if it still reproduces without the patch, or
> > conditionalize it on __SIZEOF_POINTER__.
> 
> I've tried with 0xe0000000U. The m64 case still reproduces. 
> 
> With -m32 -mregparm=1 we get:
> ...
>       	.cfi_startproc
>         call    bar
>         sall    $4, %eax
>         leal    -536870912(%eax), %edx
> 	movl    %edx, %eax
>         call    fn1
>         movl    %edx, %eax
>         call    fn2
>         xorl    %eax, %eax
>         ret
> ...
> The reload_combine doesn't trigger for this case.

It is very well possible it triggers only on x86_64-linux (or perhaps some
other 64-bit targets), but still it would be better if the testcase could be
compiled and run everywhere, so I'm all for using 0xe0000000UL or similar
constant instead.
>From gcc-bugs-return-488319-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 08 09:44:15 2015
Return-Path: <gcc-bugs-return-488319-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26020 invoked by alias); 8 Jun 2015 09:44:14 -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 26002 invoked by uid 48); 8 Jun 2015 09:44:08 -0000
From: "morandidodo at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66456] New: regex memory corruption on large input strings
Date: Mon, 08 Jun 2015 09:44: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: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: morandidodo 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-66456-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/msg00651.txt.bz2
Content-length: 1449

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

            Bug ID: 66456
           Summary: regex memory corruption on large input strings
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: morandidodo at gmail dot com
  Target Milestone: ---

I noticed a memory corruption with regex when using long input strings in
combination with multiple occurrences of a pattern. I built a simple testcase
to verify that.

regex_fault.cpp:

#include <regex>
#include <iostream>

int main()
{
    static const std::regex reFloats(R"(^(\s*-?\d+\.\d+)+\s*$)");

    std::string input;
    std::getline(std::cin, input);
    if(std::regex_match(input, reFloats))
        std::cout << "List of floats matched." << std::endl;

    return 0;
}

$ g++ -Wall -Wextra -std=c++11 regex_fault.cpp -o regex_fault
$ echo "0.000 1.000 2.000" | ./regex_fault
List of floats matched.

$ OUT=""; for i in `seq 10000`; do OUT="$OUT 0.0000"; done; echo $OUT |
./regex_fault
Segmentation fault

The problem occurs also with the non-capture version of the regex. It does not
matter if I append the "-fno-strict-aliasing -fwrapv" flags to the compiler
options.
I do not know if this is a duplicate of 61582 or not.
I am using the last version of GCC supplied by Arch Linux on a x86_64 machine.

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #9 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00553.html

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Jun  8 16:59:31 2015
New Revision: 224240

URL: https://gcc.gnu.org/viewcvs?rev=224240&root=gcc&view=rev
Log:
Handle -fipa-ra in reload_combine

2015-06-08  Tom de Vries  <tom@codesourcery.com>

        PR rtl-optimization/66444
        * postreload.c (reload_combine): Use get_call_reg_set_usage instead of
        call_used_regs.

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

Added:
    trunk/gcc/testsuite/gcc.dg/pr66444.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/postreload.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Jun  8 17:09:08 2015
New Revision: 224241

URL: https://gcc.gnu.org/viewcvs?rev=224241&root=gcc&view=rev
Log:
Handle -fipa-ra in reload_combine

2015-06-08  Tom de Vries  <tom@codesourcery.com>

        backport from mainline:
        2015-06-08  Tom de Vries  <tom@codesourcery.com>

        PR rtl-optimization/66444
        * postreload.c (reload_combine): Use get_call_reg_set_usage instead of
        call_used_regs.

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

Added:
    branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr66444.c
Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/postreload.c
    branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
patch with test-case committed to trunk and backported to gcc-5-branch. Marking
resolved-fixed.

[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

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

--- Comment #13 from vries at gcc dot gnu.org ---
(In reply to vries from comment #2)
> Looks like reload_cse_move2add could use a similar fix.

Filed spinoff bug PR66463 - review uses of call_used_regs and
regs_invalidated_by_call