[Bug target/64342] New: [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[Bug target/64342] New: [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[dominiq at lps dot ens.fr]

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

            Bug ID: 64342
           Summary: [5 Regression] Tests failing when compiled with '-m32
                    -fpic' after r216154.
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dominiq at lps dot ens.fr
                CC: hjl at gcc dot gnu.org, howarth at bromo dot med.uc.edu,
                    iains at gcc dot gnu.org, ienkovich at gcc dot gnu.org,
                    kyukhin at gcc dot gnu.org

The following failures have been caused by r216154 and reported at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c69

FAIL: gcc.target/i386/avx512f-kandnw-1.c scan-assembler-times kandnw[
\\\\t]+[^{\\n]*%k[0-7](?:\\n|[ \\\\t]+#) 1
FAIL: gcc.target/i386/funcspec-5.c (test for excess errors)
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not pop
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not push
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-times
addl\\t%[re]?dx, %[re]?ax 1
FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times
addpd\\t%xmm1, %xmm0 1
FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times
movapd\\t%xmm0, %xmm1 1
FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not pop
FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not push
FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-times
addl\\t%[re]?d[ix], %[re]?ax 1

They require to compile the tests with '-fpic -m32' and are still present at
r218812, see

https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02164.html
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02159.html

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[izamyatin at gmail dot com]

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

Igor Zamyatin <izamyatin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |izamyatin at gmail dot com,
                   |                            |vmakarov at redhat dot com

--- Comment #1 from Igor Zamyatin <izamyatin at gmail dot com> ---
avx512f-kandnw-1.c and funcspec-5.c seem to be non-PIC related issues. I asked
Kirill to look at them.

Others are not stability but more performance issues - generated code is less
effective than it should be - in one case for some reasons compiler uses
callee-saved ebx in PIC mode instead of edx in non-PIC mode and in xmm case
compiler uses stack in PIC mode instead of xmm register in non-PIC mode

I see that differencies between PIC and non-PIC modes start on reload pass so
I'd like Vlad to look at these cases

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

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

--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> ---
What's the status of this bug?  At least the failure of
gcc.target/i386/funcspec-5.c
occurs on several x86 targets (Darwin, Linux/x86, Solaris/x86) and no progess
whatsoever for more than a month!

  Rainer

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:

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

--- Comment #3 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Rainer Orth from comment #2)
> What's the status of this bug?  At least the failure of
> gcc.target/i386/funcspec-5.c
> occurs on several x86 targets (Darwin, Linux/x86, Solaris/x86) and no progess
> whatsoever for more than a month!

I've just submitted a patch for

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

The patch might fix this PR too.  Could you check it.

Thanks.

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

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

--- Comment #4 from vries at gcc dot gnu.org ---
Submitted patch for funcspec-5.c:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02162.html

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-24
     Ever confirmed|0                           |1

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I've just submitted a patch for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
>
> The patch might fix this PR too.  Could you check it.
>
> Thanks.

Unfortunately not.

> Submitted patch for funcspec-5.c:
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02162.html

This patch has no chance to fix the failures for the fuse-caller-save* tests.

The failures reported in comment 0 are still there at revision r220065 (I'll
test the patch for funcspec-5.c later today).

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
avx512f-kandnw-1.c fails with -fpic, because there's no kandnw instruction in
the .s file. In postreload, it's still there:
...
(insn 17 40 39 2 (parallel [
            (set (reg:HI 0 ax [105])
        (and:HI (not:HI (reg:HI 0 ax [105]))
                    (reg:HI 2 cx [orig:103 k2 ] [103])))
            (clobber (reg:CC 17 flags))
        ]) build/gcc/include/avx512fintrin.h:9995 386 {kandnhi}
     (nil))
...

Immediately afterwards, in split2, it disappears:
...
Splitting with gen_split_5282
scanning new insn with uid = 42.
scanning new insn with uid = 43.
deleting insn with uid = 17.
...

This is due to this split in i386.md (introduced in r202491):
...
(define_split
  [(set (match_operand:SWI12 0 "general_reg_operand")
        (and:SWI12
          (not:SWI12
            (match_dup 0))
          (match_operand:SWI12 1 "general_reg_operand")))
   (clobber (reg:CC FLAGS_REG))]
  "TARGET_AVX512F && !TARGET_BMI && reload_completed"
  [(set (match_dup 0)
        (not:HI (match_dup 0)))
   (parallel [(set (match_dup 0)
                   (and:HI (match_dup 0)
                           (match_dup 1)))
              (clobber (reg:CC FLAGS_REG))])])
...

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to Igor Zamyatin from comment #1)
> avx512f-kandnw-1.c and funcspec-5.c seem to be non-PIC related issues. I
> asked Kirill to look at them.
> 

I cannot reproduce the funcspec-5.c failure with r216154, so that failure was
unrelated (and fixed in r220079).

I can reproduce that avx512f-kandnw-1.c started failing with r216154, in -fpic
-m32 mode only. Given comment 6, it could be a benign case of different code
generation, split triggered, output scan failure.


> Others are not stability but more performance issues - generated code is
> less effective than it should be - in one case for some reasons compiler
> uses callee-saved ebx in PIC mode instead of edx in non-PIC mode and in xmm
> case compiler uses stack in PIC mode instead of xmm register in non-PIC mode
> 
> I see that differencies between PIC and non-PIC modes start on reload pass
> so I'd like Vlad to look at these cases

I can reproduce that fuse-caller-save.c started failing with r216154, in -fpic
-m32 mode only.

The code is less optimal with r216154:
...
 foo:
 .LFB1:
     .cfi_startproc
-    movl    %eax, %edx
+    pushl    %ebx
+    .cfi_def_cfa_offset 8
+    .cfi_offset 3, -8
+    movl    %eax, %ebx
     call    bar
-    addl    %edx, %eax
+    addl    %ebx, %eax
+    popl    %ebx
+    .cfi_restore 3
+    .cfi_def_cfa_offset 4
     ret
     .cfi_endproc
...

Before r216154, bx is considered clobbered in bar by
collect_fn_hard_reg_set_usage, because it's part of fixed_reg_set. With
r216154, bx is no longer part of fixed_reg_set, and bx becomes available for
register allocation in foo. I'm not familiar with the pic register code, so I
don't know whether this is safe.

Register allocation seems to progress similarly, up until this message in
reload, with seems to be directly related to the r216154 patch:
...
    Spill r86 after risky transformations
  Reassigning non-reload pseudos
           Assign 3 to r86 (freq=3000)
...

So, it seems the r216154 patch introduces a performance degradation for -m32
-fpic for the fuse-caller-save example.

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

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

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The failures are gone after r220296. However I think the "fix" (skipping the
test on pic targets) does not answer

> So, it seems the r216154 patch introduces a performance degradation
> for -m32 -fpic for the fuse-caller-save example.

Any comment before closing the PR as FIXED?

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Dominique d'Humieres from comment #8)
> The failures are gone after r220296. However I think the "fix" (skipping the
> test on pic targets) does not answer
> 
> > So, it seems the r216154 patch introduces a performance degradation
> > for -m32 -fpic for the fuse-caller-save example.
> 
> Any comment before closing the PR as FIXED?

The test fails due to different and orthogonal issue: RA chooses %ebx for a
temporary when -fpic is used:

        movl    %eax, %ebx
        call    bar
        addl    %ebx, %eax

The push and pop insns are from prologue/epilogue since call-saved reg is used
(%ebx), not due to save/restore the reg around the call:

(note 3 4 19 2 NOTE_INSN_FUNCTION_BEG)
(insn/f:TI 19 3 20 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0  S4 A8])
        (reg:SI 3 bx)) fuse-caller-save.c:16 66 {*pushsi2}
     (expr_list:REG_DEAD (reg:SI 3 bx)
        (nil)))
(note 20 19 2 2 NOTE_INSN_PROLOGUE_END)
...
(note 27 15 24 2 NOTE_INSN_EPILOGUE_BEG)
(insn/f:TI 24 27 25 2 (set (reg:SI 3 bx)
        (mem:SI (post_inc:SI (reg/f:SI 7 sp)) [0  S4 A8]))
fuse-caller-save.c:18 74 {*popsi1}
     (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
            (plus:SI (reg/f:SI 7 sp)
                (const_int 4 [0x4])))
        (expr_list:REG_CFA_RESTORE (reg:SI 3 bx)
            (nil))))

So, please open a new PR due to RA issue: since %edx was allocated for PIC
register (but later removed), another call-used (%ecx) should be used here.
>From gcc-bugs-return-475616-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 31 14:06:03 2015
Return-Path: <gcc-bugs-return-475616-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16400 invoked by alias); 31 Jan 2015 14:06:03 -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 10768 invoked by uid 48); 31 Jan 2015 14:06:00 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64884] New: [5 Regression] FAIL: g++.dg/tm/pr47573.C  -std=gnu++98 (test for excess errors) on x86_64-apple-darwin*
Date: Sat, 31 Jan 2015 14:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: UNCONFIRMED
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 cc cf_gcchost cf_gcctarget cf_gccbuild
Message-ID: <bug-64884-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-01/txt/msg03610.txt.bz2
Content-length: 1073

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

            Bug ID: 64884
           Summary: [5 Regression] FAIL: g++.dg/tm/pr47573.C  -std=gnu++98
                    (test for excess errors) on x86_64-apple-darwin*
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dominiq at lps dot ens.fr
                CC: fxcoudert at gcc dot gnu.org, howarth at bromo dot med.uc.edu,
                    hubicka at gcc dot gnu.org, iains at gcc dot gnu.org
              Host: x86_64-apple-darwin*
            Target: x86_64-apple-darwin*
             Build: x86_64-apple-darwin*

The test g++.dg/tm/pr47573.C has started to fail on x86_64-apple-darwin*
between revisions r218633 (OK) and r218641 (fail), likely r218640. The error is

/opt/gcc/work/gcc/testsuite/g++.dg/tm/pr47573.C:17:39: error: unsafe function
call 'allocator<_Tp>::allocator() [with _Tp = char]' within 'transaction_safe'
function

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #9)

> So, please open a new PR due to RA issue: since %edx was allocated for PIC
> register (but later removed), another call-used (%ecx) should be used here.

I opened PR 64895.
>From gcc-bugs-return-475696-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 01 13:50:26 2015
Return-Path: <gcc-bugs-return-475696-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5255 invoked by alias); 1 Feb 2015 13:50: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 5205 invoked by uid 48); 1 Feb 2015 13:50:22 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
Date: Sun, 01 Feb 2015 13:50: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.8.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-55252-4-CHFnjfwmNr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55252-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55252-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-02/txt/msg00029.txt.bz2
Content-length: 437

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

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It would be less of a pain if -Wsystem-headers caused both locations to be
printed, but it doesn't, so sometimes the only option is to dump the
preprocessed source without line markers and then compile that to get two
locations, then map the location in the preprocessed source back to a line in
the original source.

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> avx512f-kandnw-1.c and funcspec-5.c seem to be non-PIC related issues.
> I asked Kirill to look at them.

At r220588 avx512f-kandnw-1.c is still failing. AFAICT it is a problem with the
regexp.
I also see a similar failure with avx512f-gather-5.c.

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> At r220588 avx512f-kandnw-1.c is still failing. AFAICT it is a problem
> with the regexp.
> I also see a similar failure with avx512f-gather-5.c.

[Book15] f90/bug% egrep "kandnw[^\{\n]*%k[0-7]" avx512f-kandnw-1.s
    kandnw    %k1, %k0, %k0
[Book15] f90/bug% egrep "gather[^\n]*zmm[0-9]\{%k[1-7]\}" avx512f-gather-5.s
    vgatherdps    (%rsi,%zmm0,4), %zmm2{%k2}
    vgatherdps    (%rdx,%zmm0,4), %zmm1{%k3}

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com
           Assignee|unassigned at gcc dot gnu.org      |vmakarov at redhat dot com

--- Comment #13 from Jeffrey A. Law <law at redhat dot com> ---
AFACIT only one issue is left, namely avx512f-kandnw-1.c when compiled with
-mavx512f -m32 does not generate a kandnw instruction.

This appears to be some kind of register allocation issue.

In the IRA dump we have:

ssigning 69 to a1r105
Assigning 70 to a5r103
Assigning 69 to a6r101
Disposition:
   10:r87  l0     0    3:r91  l0    22    4:r92  l0    23    2:r93  l0    21
    9:r100 l0    21    6:r101 l0    69    8:r102 l0     0    5:r103 l0    70
    7:r104 l0     1    1:r105 l0    69    0:r110 l0    21

Which is basically what we want for insn 17 to generate the proper insn:

(insn 17 11 19 2 (parallel [
            (set (reg:HI 105)
                (and:HI (not:HI (reg:HI 101 [ k1 ]))
                    (reg:HI 103 [ k2 ])))
            (clobber (reg:CC 17 flags))
        ]) ./include/avx512fintrin.h:9995 388 {kandnhi}
     (expr_list:REG_DEAD (reg:HI 103 [ k2 ])
        (expr_list:REG_DEAD (reg:HI 101 [ k1 ])
            (expr_list:REG_UNUSED (reg:CC 17 flags)
                (nil)))))

LRA comes along and mucks things up.  It seems to initially do the right thing:

         Choosing alt 2 in insn 17:  (0) !k  (1) k  (2) k {kandnhi}


Then later:

********** Assignment #1: **********

    Spill r101 after risky transformations
         Assigning to 117 (cl=MASK_EVEX_REGS, orig=105, freq=2000, tfirst=117,
tfreq=2000)...
           Assign 71 to reload r117 (freq=2000)
  Reassigning non-reload pseudos
           Assign 0 to r101 (freq=2000)

Note the Assign 0 to r101, at this point we're going to lose badly.

         Choosing alt 1 in insn 17:  (0) &r  (1) 0  (2) r {kandnhi}
      Creating newreg=118 from oldreg=105, assigning class GENERAL_REGS to r118
      Creating newreg=119 from oldreg=103, assigning class GENERAL_REGS to r119

With insn 17 looking like:

(insn 17 40 39 2 (parallel [
            (set (reg:HI 0 ax [105])
                (and:HI (not:HI (reg:HI 0 ax [105]))
                    (reg:HI 2 cx [orig:103 k2 ] [103])))
            (clobber (reg:CC 17 flags))
        ]) ./include/avx512fintrin.h:9995 388 {kandnhi}
     (nil))

with input & output reloads to get things into the k registers and of course no
kandnw instruction since we end up doing the logical operation in the general
purpose registers.

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law <law at redhat dot com> ---
Created attachment 34958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34958&action=edit
testcase

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[vmakarov at gcc dot gnu.org]

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

--- Comment #15 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Jeff, thanks for the detail analysis.  It helped me a lot.  I am working on the
patch fixing the problem.  I hope it will be ready today.

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[vmakarov at gcc dot gnu.org]

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

--- Comment #16 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Thu Mar  5 19:43:11 2015
New Revision: 221223

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

    PR target/64342
    * lra-assigns.c (find_hard_regno_for): Rename to
    find_hard_regno_for_1.  Add a new parameter.
    (find_hard_regno_for): New function using find_hard_regno_for_1.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-assigns.c

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

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

--- Comment #17 from Jeffrey A. Law <law at redhat dot com> ---
Resolved by Vlad's LRA change to the trunk.

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342
Bug 64342 depends on bug 64895, which changed state.

Bug 64895 Summary: RA picks the wrong register for -fipa-ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895

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

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342
Bug 64342 depends on bug 64895, which changed state.

Bug 64895 Summary: RA picks the wrong register for -fipa-ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895

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