[Bug c/66782] New: Unable to run 64-bit wine after MS->SYSV register changes

[Bug c/66782] New: Unable to run 64-bit wine after MS->SYSV register changes

[austinenglish at gmail dot com]

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

            Bug ID: 66782
           Summary: Unable to run 64-bit wine after MS->SYSV register
                    changes
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: austinenglish at gmail dot com
  Target Milestone: ---

Regression, introduced by:
[austin@localhost gcc]$ git bisect bad
96c09a553634967a94b5fd4ec3c46b58ffca1700 is the first bad commit
commit 96c09a553634967a94b5fd4ec3c46b58ffca1700
Author: uros <uros@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Sun Sep 21 15:13:14 2014 +0000

        * config/i386/i386.c (ix86_expand_call): Generate MS->SYSV extra
        clobbered registers using clobber_reg.  Remove UNSPEC decoration.
        * config/i386/i386.md (unspec) <UNSPEC_MS_TO_SYSV_CALL>: Remove.
        (*call_rex64_ms_sysv): Remove.
        (*call_value_rex64_ms_sysv): Ditto.
        * config/i386/predicates.md (call_rex64_ms_sysv_operation): Remove.

    testsuite/ChangeLog:

        * gcc.target/i386/avx-vzeroupper-16.c (dg-final): Remove check
        for call_value_rex64_ms_sysv.
        * gcc.target/i386/avx-vzeroupper-17.c (dg-final): Ditto.
        * gcc.target/i386/avx-vzeroupper-18.c (dg-final): Remove check
        for call_rex64_ms_sysv.



    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215428
138bc75d-0d04-0410-961f-82ee72b054a4

:040000 040000 106752531e7926ba25b0617448d4ba45911c9dad
83a0c6ad4d406be569059bf7b59320804024d1c3 M      gcc


See downstream issue report here:
https://bugs.winehq.org/show_bug.cgi?id=38653

[Bug c/66782] Unable to run 64-bit wine after MS->SYSV register changes

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Adding clobbered registers explicitly is exactly the same as adding them to
call_fusage, so I don't see any problem here from the first sight.

Can you please provide a minimized testcase, following instructions at [1].
Unfortunately, I don't have access to Windows target, please provide a testcase
that fails on linux. You can decorate calls with __attribute__((ms_abi)) even
on linux.

[1] https://gcc.gnu.org/bugs/#report
>From gcc-bugs-return-491601-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 06 19:03:28 2015
Return-Path: <gcc-bugs-return-491601-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 116976 invoked by alias); 6 Jul 2015 19:03:28 -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 116853 invoked by uid 48); 6 Jul 2015 19:03:19 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/66773] sign-compare warning for == and != are pretty useless
Date: Mon, 06 Jul 2015 19:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.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:
Message-ID: <bug-66773-4-XEHGBPOuQs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66773-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66773-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-07/txt/msg00491.txt.bz2
Content-length: 178

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

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
It's always the boundary cases that matter most for security.

[Bug target/66782] Unable to run 64-bit wine after MS->SYSV register changes

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
CC maintainer.
>From gcc-bugs-return-491603-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 06 20:24:54 2015
Return-Path: <gcc-bugs-return-491603-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 76026 invoked by alias); 6 Jul 2015 20:24:54 -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 75998 invoked by uid 48); 6 Jul 2015 20:24:49 -0000
From: "mikulas at artax dot karlin.mff.cuni.cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
Date: Mon, 06 Jul 2015 20:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikulas at artax dot karlin.mff.cuni.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:
Message-ID: <bug-59767-4-n2AvyVIvG1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59767-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59767-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-07/txt/msg00493.txt.bz2
Content-length: 1545

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

--- Comment #7 from mikulas at artax dot karlin.mff.cuni.cz ---
#include <stdatomic.h>

atomic_int a = ATOMIC_VAR_INIT(0);
atomic_int b = ATOMIC_VAR_INIT(0);
atomic_int p = ATOMIC_VAR_INIT(0);

int thread_1(void)
{
        atomic_store_explicit(&b, 1, memory_order_relaxed);
        atomic_load_explicit(&p, memory_order_seq_cst);
        return atomic_load_explicit(&a, memory_order_relaxed);
}

int thread_2(void)
{
        atomic_store_explicit(&a, 1, memory_order_relaxed);
        atomic_load_explicit(&p, memory_order_seq_cst);
        return atomic_load_explicit(&b, memory_order_relaxed);
}

See for example this. Suppose that thread_1 and thread_2 are executed
concurrently. If memory_order_seq_cst were a proper full memory barrier, it
would be impossible that both functions return 0. Because you omit the barrier
on read of variable p, it is possible that both functions return 0.

thread_1 is compiled into
        movl    $1, b(%rip)
        movl    p(%rip), %eax
        movl    a(%rip), %eax
        ret
thread_2 is compiled into
        movl    $1, a(%rip)
        movl    p(%rip), %eax
        movl    b(%rip), %eax
        ret
... and the processor is free to move the writes past reads, resulting in both
functions returning zero.

Does the standard allow this behavior? I don't really know. I don't understand
the standard. Please tell me - how do you decide, by interpreting claims in the
section 7.17.3 of the C11 standard, whether the above outcome is allowed or
not?

[Bug target/66782] Unable to run 64-bit wine after MS->SYSV register changes

[marcus at jet dot franken.de]

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

--- Comment #3 from marcus at jet dot franken.de ---
Created attachment 35927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35927&action=edit
testcase-min.i

gcc -S -fPIC -O2 -g testcase.i -o testcase.s

there will be a pattern to spot the miscompilation:

        call    strlen@PLT
.LVL27:
        movq    40(%rsp), %rcx
        movq    %rsi, %rdx

However %rsi is clobbered by strlen and should not have been used here.

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
            Version|5.1.0                       |6.0
           Keywords|                            |ra
   Last reconfirmed|                            |2015-07-08
          Component|target                      |rtl-optimization
                 CC|                            |ubizjak at gmail dot com,
                   |                            |vmakarov at gcc dot gnu.org
     Ever confirmed|0                           |1
            Summary|Unable to run 64-bit wine   |[5/6 Regression] Unable to
                   |after MS->SYSV register     |run 64-bit wine after
                   |changes                     |MS->SYSV register changes
   Target Milestone|---                         |5.2

--- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> ---
When compiled with "-O2 -fPIC", we have following sequence in _.ira dump:

  ...
  211: r225:DI=[frame:DI-0x80]
      REG_EQUIV [frame:DI-0x80]
  212: {r224:DI=r225:DI-r89:DI;clobber flags:CC;}
      REG_DEAD r225:DI
      REG_UNUSED flags:CC
      REG_EQUAL [frame:DI-0x80]-r89:DI
  213: [r111:DI+r224:DI]=0x36646d61
  214: [r111:DI+r224:DI+0x4]=0x34
      REG_DEAD r224:DI
  215: r121:DI=[frame:DI-0x80]
  216: di:DI=r111:DI
  217: ax:DI=call [`strlen'] argc:0
      REG_DEAD di:DI
      REG_CALL_DECL `strlen'
      REG_EH_REGION 0
  218: r227:DI=ax:DI
      REG_DEAD ax:DI
  221: {r229:DI=r111:DI+r227:DI;clobber flags:CC;}
      REG_DEAD r227:DI
      REG_UNUSED flags:CC
  222: {r230:DI=r89:DI-r121:DI;clobber flags:CC;}
      REG_UNUSED flags:CC
  ...

and following in _.reload dump:
  ...
  211: NOTE_INSN_DELETED
  591: di:DI=[sp:DI+0x70]
  633: si:DI=[sp:DI+0x18]
  593: dx:DI=si:DI
  212: {di:DI=di:DI-dx:DI;clobber flags:CC;}
      REG_EQUAL [frame:DI-0x80]-r89:DI
  592: ax:DI=di:DI
  213: [bp:DI+ax:DI]=0x36646d61
  214: [bp:DI+ax:DI+0x4]=0x34
  215: cx:DI=[sp:DI+0x70]
  631: [sp:DI+0x28]=cx:DI
  216: di:DI=bp:DI
  217: ax:DI=call [`strlen'] argc:0
      REG_CALL_DECL `strlen'
      REG_EH_REGION 0
  218: ax:DI=ax:DI
  221: {di:DI=bp:DI+ax:DI;clobber flags:CC;}
  594: dx:DI=si:DI
  632: cx:DI=[sp:DI+0x28]
  222: {dx:DI=dx:DI-cx:DI;clobber flags:CC;}
  ...

Please note (insn 594) that uses clobbered SI register, although the call insn
clobbers it:

(call_insn/i 217 216 218 25 (set (reg:DI 0 ax)
        (call (mem:QI (symbol_ref:DI ("strlen") [flags 0x41]  <function_decl
0x2b7e7ae707e0 strlen>) [0 __builtin_strlen S1 A8])
            (const_int 0 [0]))) pr66782.i:96 656 {*call_value}
     (expr_list:REG_CALL_DECL (symbol_ref:DI ("strlen") [flags 0x41] 
<function_decl 0x2b7e7ae707e0 strlen>)
        (expr_list:REG_EH_REGION (const_int 0 [0])
            (nil)))
    (expr_list (clobber (reg:TI 52 xmm15))
        (expr_list (clobber (reg:TI 51 xmm14))
            (expr_list (clobber (reg:TI 50 xmm13))
                (expr_list (clobber (reg:TI 49 xmm12))
                    (expr_list (clobber (reg:TI 48 xmm11))
                        (expr_list (clobber (reg:TI 47 xmm10))
                            (expr_list (clobber (reg:TI 46 xmm9))
                                (expr_list (clobber (reg:TI 45 xmm8))
                                    (expr_list (clobber (reg:TI 28 xmm7))
                                        (expr_list (clobber (reg:TI 27 xmm6))
                                            (expr_list (clobber (reg:DI 5 di))
                                                (expr_list (clobber (reg:DI 4
si))
                                                    (expr_list:DI (use (reg:DI
5 di))
                                                        (nil)))))))))))))))

Confirmed with latest 6.0 mainline [trunk revision 225533] as RA problem.

CC RA expert.
>From gcc-bugs-return-491715-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 08 08:26:55 2015
Return-Path: <gcc-bugs-return-491715-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 107246 invoked by alias); 8 Jul 2015 08:26:53 -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 107212 invoked by uid 48); 8 Jul 2015 08:26:49 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug web/66802] New: Some of the Bugzilla Bug fields descriptions do not reflect GCC development
Date: Wed, 08 Jul 2015 08:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: web
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak 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-66802-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-07/txt/msg00605.txt.bz2
Content-length: 827

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

            Bug ID: 66802
           Summary: Some of the Bugzilla Bug fields descriptions do not
                    reflect GCC development
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: web
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Some of the "Bug Fields" descriptions [1] do not reflect reality. STATUS and
RESOLUTION descriptions are not correct.

IMO, Priority and Severity fields also need a better description - at least the
criteria for Priority and Severity selections, and who can set these fields
(Release Managers?).

[1] https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
The difference when clobbers are implemented with direct clobbers (I'll attach
the patch) is:

(---): Unpatched compiler, usign fusage clobbers
(+++): Patched compiler, using direct clobbers

--- pr66782_.s  2015-07-08 12:35:40.000000000 +0200
+++ pr66782.s   2015-07-08 12:37:21.000000000 +0200
@@ -260,10 +260,9 @@
        subq    %rax, %rdx
        movq    %rax, %rsi
        call    memcpy@PLT
-       movq    24(%rsp), %rsi
        movq    112(%rsp), %rdi
+       subq    24(%rsp), %rdi
        movl    $52, %edx
-       subq    %rsi, %rdi
        movw    %dx, 4(%rbp,%rdi)
        movl    $912551265, 0(%rbp,%rdi)
        movq    %rbp, %rdi
@@ -271,7 +270,7 @@
        movq    %rcx, 40(%rsp)
        call    strlen@PLT
        movq    40(%rsp), %rcx
-       movq    %rsi, %rdx
+       movq    24(%rsp), %rdx
        leaq    0(%rbp,%rax), %rdi
        subq    %rcx, %rdx
        addq    32(%rsp), %rdx
>From gcc-bugs-return-491742-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 08 11:18:26 2015
Return-Path: <gcc-bugs-return-491742-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 51290 invoked by alias); 8 Jul 2015 11:18:25 -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 51213 invoked by uid 48); 8 Jul 2015 11:18:16 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes
Date: Wed, 08 Jul 2015 11:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-66782-4-K5Vtijpkev@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66782-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66782-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg00632.txt.bz2
Content-length: 378

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

--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> ---
Created attachment 35931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35931&action=edit
Workaround patch that reintroduces direct call clobbers

The patch vs. [trunk revision 225533] can be used as a workaround until the
real problem is fixed.
>From gcc-bugs-return-491743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 08 11:25:16 2015
Return-Path: <gcc-bugs-return-491743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 79517 invoked by alias); 8 Jul 2015 11:25:15 -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 79426 invoked by uid 55); 8 Jul 2015 11:25:11 -0000
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/61820] 32-bit g++.dg/ipa/pr61160-3.C execution failure
Date: Wed, 08 Jul 2015 11:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jamborm at gcc dot gnu.org
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-61820-4-XD6si5d7dG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61820-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61820-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-07/txt/msg00633.txt.bz2
Content-length: 681

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

--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Author: jamborm
Date: Wed Jul  8 11:24:38 2015
New Revision: 225543

URL: https://gcc.gnu.org/viewcvs?rev"5543&root=gcc&view=rev
Log:
Make gcc/testsuite/g++.dg/ipa/pr61160-3.C main return zero.

2015-07-08  Martin Jambor  <mjambor@suse.cz>

        PR ipa/61820
        Backport from mainline r212915
        2014-07-22  Martin Jambor  <mjambor@suse.cz>

        PR ipa/61160
        * g++.dg/ipa/pr61160-3.C (main): Return zero.


Modified:
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr61160-3.C

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[matz at gcc dot gnu.org]

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

Michael Matz <matz at gcc dot gnu.org> changed:

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

--- Comment #9 from Michael Matz <matz at gcc dot gnu.org> ---
FWIW, it's the inheritance code that breaks this.  From the reload (aka lra)
dump:

      Creating newreg=380 from oldreg=89, assigning class GENERAL_REGS to
inheritance r380
    Original reg change 89->380 (bb25):
  593: r342:DI=r380:DI
    Add inheritance<-original before:
  633: r380:DI=r89:DI

    Inheritance reuse change 89->380 (bb25):
  594: r343:DI=r380:DI

r89 is the original register that is live over the call, and which didn't
get a hardreg.  insn 593 and 633 are an optional reload for an insn (212)
_before_ the call, insn 594 is a (inheritance) reload insn _after_ the call
(for insn 222), ala this:


(insn 633 591 593 25 (set (reg:DI 4 si [orig:89 D.1995 ] [89])
        (mem/c:DI (plus:DI (reg/f:DI 7 sp)
                (const_int 24 [0x18])) [11 %sfp+-216 S8 A64])) wine.c:95 85
{*movdi_internal}
     (nil))
(insn 593 633 212 25 (set (reg:DI 1 dx [orig:89 D.1995 ] [89])
        (reg:DI 4 si [orig:89 D.1995 ] [89])) wine.c:95 85 {*movdi_internal}
     (nil))
(insn 212 593 592 25 (parallel [
            (set (reg:DI 5 di [orig:224 D.1995 ] [224])
                (minus:DI (reg:DI 5 di [orig:224 D.1995 ] [224])
                    (reg:DI 1 dx [orig:89 D.1995 ] [89])))
            (clobber (reg:CC 17 flags))
        ]) wine.c:95 259 {*subdi_1}
     (expr_list:REG_EQUAL (minus:DI (mem/f/c:DI (plus:DI (reg/f:DI 20 frame)
                    (const_int -128 [0xffffffffffffff80])) [2 arch.ptr+0 S8
A128
])
            (reg:DI 89 [ D.1995 ]))
        (nil)))

... more insn, amongst them insn 217, the call insn clobbering reg 4 aka SI ...

(insn 594 221 632 25 (set (reg:DI 1 dx [orig:230 D.1995 ] [230])
        (reg:DI 4 si [orig:89 D.1995 ] [89])) wine.c:96 85 {*movdi_internal}
     (nil))
(insn 632 594 222 25 (set (reg/f:DI 2 cx [orig:121 D.1996 ] [121])
        (mem/c:DI (plus:DI (reg/f:DI 7 sp)
                (const_int 40 [0x28])) [11 %sfp+-200 S8 A64])) wine.c:96 85
{*movdi_internal}
     (nil))
(insn 222 632 596 25 (parallel [
            (set (reg:DI 1 dx [orig:230 D.1995 ] [230])
                (minus:DI (reg:DI 1 dx [orig:230 D.1995 ] [230])
                    (reg/f:DI 2 cx [orig:121 D.1996 ] [121])))
            (clobber (reg:CC 17 flags))
        ]) wine.c:96 259 {*subdi_1}
     (nil))

So, insn 594 reuses the inheritance register 380 from before the call
(setup in insn 633), so r380 is live over the call.  But LRA happily
does this to this reload inheritance reg:

         Assigning to 380 (cl=GENERAL_REGS, orig=89, freq=33, tfirst=340,
tfreq=66)...
           Assign 4 to inheritance r380 (freq=33)

Voila, hardreg 4 is assigned to r380, even though it lives over a clobber
of it.

I don't see any code in inherit_reload_reg or its caller inherit_in_ebb
that would look at CALL_INSN_FUNCTION_USAGE on any intervening insns,
between the inheritance setup and any of the next usage insns.

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
I've just started to work on it.

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #9)

> I don't see any code in inherit_reload_reg or its caller inherit_in_ebb
> that would look at CALL_INSN_FUNCTION_USAGE on any intervening insns,
> between the inheritance setup and any of the next usage insns.

Mike, thanks for the analysis.

Inheritance code has a simplified live analysis which is needed only when there
is inheritance beyond BB.

The full live analysis is done by code in lra-lives.c which is executed right
after inheritance but before the assignment code in lra-assigns.c.

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Vladimir Makarov from comment #11)
> (In reply to Michael Matz from comment #9)
> 
> > I don't see any code in inherit_reload_reg or its caller inherit_in_ebb
> > that would look at CALL_INSN_FUNCTION_USAGE on any intervening insns,
> > between the inheritance setup and any of the next usage insns.
> 
> Mike, thanks for the analysis.
> 
> Inheritance code has a simplified live analysis which is needed only when
> there is inheritance beyond BB.
> 
> The full live analysis is done by code in lra-lives.c which is executed
> right after inheritance but before the assignment code in lra-assigns.c.

Could this be related to PR 66626 where LRA ignores a clobbered register and
uses it directly?

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[vmakarov at gcc dot gnu.org]

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

--- Comment #13 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Thu Jul  9 15:39:53 2015
New Revision: 225618

URL: https://gcc.gnu.org/viewcvs?rev=225618&root=gcc&view=rev
Log:
2015-07-09  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-optimization/66782
        * lra-int.h (struct lra_insn_recog_data): Add comment about
        clobbered hard regs for arg_hard_regs.
        * lra.c (lra_set_insn_recog_data): Add clobbered hard regs.
        * lra-lives.c (process_bb_lives): Process clobbered hard regs.
        Add condition for processing used hard regs.
        * lra-constraints.c (update_ebb_live_info, inherit_in_ebb):
        Process clobbered hard regs.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c
    trunk/gcc/lra-int.h
    trunk/gcc/lra-lives.c
    trunk/gcc/lra.c

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[vmakarov at gcc dot gnu.org]

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

--- Comment #14 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Fri Jul 10 13:17:02 2015
New Revision: 225674

URL: https://gcc.gnu.org/viewcvs?rev=225674&root=gcc&view=rev
Log:
2015-07-10  Vladimir Makarov  <vmakarov@redhat.com>

        Backport from mainline
        2015-07-09  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-optimization/66782
        * lra-int.h (struct lra_insn_recog_data): Add comment about
        clobbered hard regs for arg_hard_regs.
        * lra.c (lra_set_insn_recog_data): Add clobbered hard regs.
        * lra-lives.c (process_bb_lives): Process clobbered hard regs.
        Add condition for processing used hard regs.
        * lra-constraints.c (update_ebb_live_info, inherit_in_ebb):
        Process clobbered hard regs.


Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/lra-constraints.c
    branches/gcc-5-branch/gcc/lra-int.h
    branches/gcc-5-branch/gcc/lra-lives.c
    branches/gcc-5-branch/gcc/lra.c

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |trippels at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #15 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
fixed

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[marcus at jet dot franken.de]

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

--- Comment #16 from marcus at jet dot franken.de ---
I can confirm that this testcase fixed here and in Wine.

I have however found another issue with register clobbering and opened a new
bug 66845 for it.