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

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.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.