[Bug target/54300] New: [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[Bug target/54300] New: [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[eric.batut at allegorithmic dot com]

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

             Bug #: 54300
           Summary: [4.7/4.8 Regression] Erroneous optimization causes
                    wrong Neon data management
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: eric.batut@allegorithmic.com


Created attachment 28044
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28044
Small repro case

Using gcc trunk at rev 190381, compiled with the Android NDK r8b build-gcc.sh
script (so an arm-linux-androideabi target) and the command line below, the
attached repro case generates wrong code:

arm-linux-androideabi-g++ -march=armv7-a -mfloat-abi=softfp -mfpu=vfp
-mfpu=neon -marm -O2 test.cpp -S -o test.s

The core loop is pasted below:
    for(unsigned int sv=0 ; sv!=dv0 ; sv=(sv+s1v)&smask_v)
    {
        int32x4_t s;
        s = vmovl_s16(vget_low_s16(_loadlo_8i16((cv8i16*)_Inp, sv )));
        c = vaddq_s32(c, s);
    }

8 bytes are fetched from "_Inp (in bytes) + sv", then sign-extended from 4
16bits values to 4 32bits values, then accumulated in "c".

The generated assembly code for the loop is:
.L3:
    add    r4, r0, ip
    vmov.i32    d18, #0  @ v4hi   <= d18 is full of 0's
    add    ip, ip, r2
    vld1.16    {d19}, [r4:64]            <= d19 holds useful data
    and    ip, ip, r5
    cmp    r3, ip
    vswp    d18, d19                  <= d19 is now full of 0's
    vmovl.s16    q9, d19           <= d19 (full of 0's) gets expanded
    vadd.i32    q8, q8, q9        <= q9 is always zero when accumulated
    bne    .L3

When using "-O1" or "-O2 -fno-gcse", correct code is generated:
.L3:
    add    r4, r0, ip
    add    ip, ip, r2
    and    ip, ip, r5
    vld1.16    {d18}, [r4:64]            <= d18 holds useful data
    cmp    r3, ip
    vmovl.s16    q9, d18           <= d18 is sign-extended
    vadd.i32    q8, q8, q9        <= q9 is accumulated
    bne    .L3

This also happens with gcc 4.7.1, but not with gcc 4.6

Also, in the loadlo_8i16 function, if we replace the call to zero_64 by the
proper vdup_n_s16(0), then correct code is generated at -O2.

The (stripped down in the repro case) _v16u8_ and _v8u8_ structures are the way
we implemented some kind of compiler-performed polymorphism for Neon variables,
since not all ARM compilers have -flax-vector-conversions.

[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-08-18
   Target Milestone|---                         |4.7.2
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-08-18 08:12:11 UTC ---
Your testcase is quite convoluted but it looks you may be violating C
type-based aliasing rules.  Thus, try -fno-strict-aliasing.

[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[eric.batut at allegorithmic dot com]

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

--- Comment #2 from Eric Batut <eric.batut at allegorithmic dot com> 2012-08-20 16:11:35 UTC ---
(In reply to comment #1)

Hi Richard

Using "-O2 -fno-strict-aliasing" generates the exact same (incorrect) code.

> Your testcase is quite convoluted but it looks you may be violating C
> type-based aliasing rules.  Thus, try -fno-strict-aliasing.

[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
      Known to work|                            |4.6.3
     Ever Confirmed|1                           |0

[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.2                       |4.7.3

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-20 10:20:58 UTC ---
GCC 4.7.2 has been released.

[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[eric.batut at allegorithmic dot com]

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

--- Comment #4 from Eric Batut <eric.batut at allegorithmic dot com> 2012-10-25 12:56:33 UTC ---
I did the test with -fno-strict-aliasing and the exact same problem occur.
Do I need to provide more information on this issue for it to move to the
"Confirmed" state?

Best Regards,
Eric

[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Target|arm                         |arm*-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|2012-08-18 00:00:00         |2012-10-25
                 CC|                            |rearnsha at gcc dot gnu.org
     Ever Confirmed|0                           |1
      Known to fail|                            |4.7.2, 4.8.0

[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[rguenth at gcc dot gnu.org]

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

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

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

[Bug target/54300] [4.7 Regression] Erroneous optimization causes wrong Neon data management

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.8.0
            Summary|[4.7/4.8 Regression]        |[4.7 Regression] Erroneous
                   |Erroneous optimization      |optimization causes wrong
                   |causes wrong Neon data      |Neon data management
                   |management                  |
      Known to fail|4.8.0                       |

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-10 22:19:25 UTC ---
I could not reproduce this in a modified 4.7.0 which has patches from the
trunk.
I think it was fixed by http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01732.html
.

[Bug target/54300] [4.7 Regression] Erroneous optimization causes wrong Neon data management

[eric.batut at allegorithmic dot com]

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

--- Comment #6 from Eric Batut <eric.batut at allegorithmic dot com> 2013-01-11 10:42:04 UTC ---
The patch by Christophe Lyon in the linked email was applied on trunk by Ramana
at rev 188951 (June 25th 2012), but gcc-trunk still fails as of today (rev
195102). The vswp instruction that causes d19 to be 0 before being used
afterwards is still generated.

Don't know about 4.7.x, though.

So unless my test is wrong (same command line and same test case as in the
original bug report), 4.8.0 should not be in the "Known to work" field. Did you
try with trunk ?



(In reply to comment #5)
> I could not reproduce this in a modified 4.7.0 which has patches from the
> trunk.
> I think it was fixed by http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01732.html
> .

[Bug target/54300] [4.7 Regression] Erroneous optimization causes wrong Neon data management

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.3                       |4.7.4

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-11 07:59:36 UTC ---
GCC 4.7.3 is being released, adjusting target milestone.

[Bug target/54300] [4.7 Regression] Erroneous optimization causes wrong Neon data management

[eric.batut at allegorithmic dot com]

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

Eric Batut <eric.batut at allegorithmic dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|4.8.0                       |
      Known to fail|                            |4.8.0

--- Comment #8 from Eric Batut <eric.batut at allegorithmic dot com> ---
This still happens with the gcc 4.8 that was released in the Android NDK r9.
I moved 4.8.0 from the "Known to work" field to the "Known to fail" field.

[Bug rtl-optimization/54300] [4.7 Regression] Erroneous optimization causes wrong Neon data management

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |rtl-optimization
      Known to fail|                            |4.9.0

--- Comment #9 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
This is regcprop messing up.  After the ce3 pass we have:

(insn 18 30 73 4 (set (reg:V4HI 54 d19 [orig:113 D.16370 ] [113])
        (unspec:V4HI [
                (mem:V4HI (reg:SI 14 lr [128]) [0 MEM[(const
__builtin_neon_hi[4] *)_21]+0 S8 A16])
            ] UNSPEC_VLD1))
/work/rearnsha/scratch/gnu/gcc/trunk/gcc/include/arm_neon.h:8019 1662
{neon_vld1v4hi}
     (nil))
(insn 73 18 27 4 (parallel [
            (set (reg:V4HI 52 d18 [ D.16372 ])
                (reg:V4HI 54 d19 [orig:113 D.16370 ] [113]))
            (set (reg:V4HI 54 d19 [ D.16372+8 ])
                (reg:V4HI 52 d18 [orig:120 D.16370 ] [120]))
        ]) /work/rearnsha/scratch/gnu/gcc/trunk/gcc/include/arm_neon.h:5783
1429 {*neon_vswpv4hi}
     (expr_list:REG_UNUSED (reg:V4HI 54 d19 [ D.16372+8 ])
        (nil)))
(insn 27 73 31 4 (set (reg:V4SI 52 d18 [orig:118 D.16373 ] [118])
        (unspec:V4SI [
                (reg:V4HI 52 d18 [orig:115 D.16372 ] [115])
                (const_int 1 [0x1])
            ] UNSPEC_VMOVL))
/work/rearnsha/scratch/gnu/gcc/trunk/gcc/include/arm_neon.h:6183 1470
{neon_vmovlv4hi}
     (nil))

and regcprop substitues d19 for d18 in insn 27, missing the fact that insn 73
is swapping the two values (thus clobbering the old d19 value).  Giving:

(insn 27 73 31 4 (set (reg:V4SI 52 d18 [orig:118 D.16373 ] [118])
        (unspec:V4SI [
                (reg:V4HI 54 d19 [orig:115 D.16372 ] [115])
                (const_int 1 [0x1])
            ] UNSPEC_VMOVL))
/work/rearnsha/scratch/gnu/gcc/trunk/gcc/include/arm_neon.h:6183 1470
{neon_vmovlv4hi}
     (nil))

[Bug rtl-optimization/54300] [4.7, 4.8, 4.9 Regression] regcprop incorrectly looks through parallel register swap operation

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

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

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> and regcprop substitues d19 for d18 in insn 27, missing the fact that insn
> 73 is swapping the two values (thus clobbering the old d19 value).

It's probably fooled by single_set returning the first set of the insn because
of the REG_UNUSED note.  I wonder whether it's a generic pitfall of single_set.

[Bug rtl-optimization/54300] [4.7, 4.8, 4.9 Regression] regcprop incorrectly looks through parallel register swap operation

[rearnsha at gcc dot gnu.org]

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

--- Comment #11 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #10)
> > and regcprop substitues d19 for d18 in insn 27, missing the fact that insn
> > 73 is swapping the two values (thus clobbering the old d19 value).
> 
> It's probably fooled by single_set returning the first set of the insn
> because of the REG_UNUSED note.  I wonder whether it's a generic pitfall of
> single_set.

Hmm, interesting.  Perhaps single_set should not do this if the dead set
clobbers an input.

[Bug rtl-optimization/54300] [4.7, 4.8, 4.9 Regression] regcprop incorrectly looks through parallel register swap operation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Hmm, interesting.  Perhaps single_set should not do this if the dead set
> clobbers an input.

Yes, that seems to be a sensible proposal, but single_set is an old thing.

[Bug rtl-optimization/54300] [4.7, 4.8, 4.9 Regression] regcprop incorrectly looks through parallel register swap operation

[rearnsha at gcc dot gnu.org]

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

--- Comment #13 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Author: rearnsha
Date: Wed Nov 20 13:55:04 2013
New Revision: 205117

URL: http://gcc.gnu.org/viewcvs?rev=205117&root=gcc&view=rev
Log:
PR rtl-optimization/54300

gcc/

    PR rtl-optimization/54300
    * regcprop.c (copyprop_hardreg_forward_1): Ensure any unused
    outputs in a single-set are killed from the value chains.

gcc/testsuite:

    PR rtl-optimization/54300
    * gcc.target/arm/pr54300.C: New test.


Added:
    trunk/gcc/testsuite/gcc.target/arm/pr54300.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/regcprop.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steven at gcc dot gnu.org
      Known to work|                            |4.9.0
            Summary|[4.7, 4.8, 4.9 Regression]  |[4.7, 4.8 Regression]
                   |regcprop incorrectly looks  |regcprop incorrectly looks
                   |through parallel register   |through parallel register
                   |swap operation              |swap operation
      Known to fail|4.9.0                       |

--- Comment #14 from Steven Bosscher <steven at gcc dot gnu.org> ---
fixed on trunk, see comment #13

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[rearnsha at gcc dot gnu.org]

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

--- Comment #15 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Author: rearnsha
Date: Mon Dec  9 14:54:00 2013
New Revision: 205807

URL: http://gcc.gnu.org/viewcvs?rev=205807&root=gcc&view=rev
Log:
    PR rtl-optimization/54300

gcc/

    PR rtl-optimization/54300
    * regcprop.c (copyprop_hardreg_forward_1): Ensure any unused
    outputs in a single-set are killed from the value chains.

gcc/testsuite:

    PR rtl-optimization/54300
    * gcc.target/arm/pr54300.C: New test.


Added:
    trunk/gcc/testsuite/gcc.target/arm/ldrd-strd-offset.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[rearnsha at gcc dot gnu.org]

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

--- Comment #16 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Author: rearnsha
Date: Thu Jan  9 15:18:55 2014
New Revision: 206466

URL: http://gcc.gnu.org/viewcvs?rev=206466&root=gcc&view=rev
Log:
    PR rtl-optimization/54300

gcc:
    * regcprop.c (copyprop_hardreg_forward_1): Ensure any unused
    outputs in a single-set are killed from the value chains.

gcc/testsuite:
    * gcc.target/arm/pr54300.C: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/arm/pr54300.C
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/regcprop.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[rearnsha at gcc dot gnu.org]

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

--- Comment #17 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Author: rearnsha
Date: Fri Jan 10 16:54:43 2014
New Revision: 206533

URL: http://gcc.gnu.org/viewcvs?rev=206533&root=gcc&view=rev
Log:
PR rtl-optimization/54300

gcc:
    * regcprop.c (copyprop_hardreg_forward_1): Ensure any unused
    outputs in a single-set are killed from the value chains.
gcc/testsuite:
    * gcc.target/arm/pr54300.C: New test.

Added:
    branches/gcc-4_7-branch/gcc/testsuite/gcc.target/arm/pr54300.C
Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/regcprop.c
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

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

--- Comment #18 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Fixed on all active branches

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[gregory.0xf0 at gmail dot com]

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

gregory.0xf0 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gregory.0xf0 at gmail dot com

--- Comment #19 from gregory.0xf0 at gmail dot com ---
(In reply to Richard Earnshaw from comment #15)
> Author: rearnsha
> Date: Mon Dec  9 14:54:00 2013
> New Revision: 205807
> 
> URL: http://gcc.gnu.org/viewcvs?rev=205807&root=gcc&view=rev
> Log:
> 	PR rtl-optimization/54300
> 
> gcc/
> 
> 	PR rtl-optimization/54300
> 	* regcprop.c (copyprop_hardreg_forward_1): Ensure any unused
> 	outputs in a single-set are killed from the value chains.
> 
> gcc/testsuite:
> 
> 	PR rtl-optimization/54300
> 	* gcc.target/arm/pr54300.C: New test.
> 
> 
> Added:
>     trunk/gcc/testsuite/gcc.target/arm/ldrd-strd-offset.c
> Modified:
>     trunk/gcc/ChangeLog
>     trunk/gcc/config/arm/arm.c
>     trunk/gcc/testsuite/ChangeLog

There probably isn't much that can be done to fix this now, but in case anyone
else was confused because this change was tagged with PR 54300, it looks like
this change ended up with the wrong commit message (changelog is correct). 
FMI: https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00850.html
>From gcc-bugs-return-459439-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 29 03:12:42 2014
Return-Path: <gcc-bugs-return-459439-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6072 invoked by alias); 29 Aug 2014 03:12:42 -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 6049 invoked by uid 55); 29 Aug 2014 03:12:38 -0000
From: "dmalcolm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192
Date: Fri, 29 Aug 2014 03:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dmalcolm 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: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62300-4-kRhOBTAxIH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62300-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62300-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: 2014-08/txt/msg01936.txt.bz2
Content-length: 496

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

--- Comment #5 from dmalcolm at gcc dot gnu.org ---
Author: dmalcolm
Date: Fri Aug 29 03:12:01 2014
New Revision: 214714

URL: https://gcc.gnu.org/viewcvs?rev!4714&root=gcc&view=rev
Log:
    PR bootstrap/62300
    * function.c (assign_parm_setup_reg): Remove erroneous checked
    cast to rtx_insn * on result of gen_extend_insn in favor of
    introducing a new local rtx "pat".


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/function.c