[Bug middle-end/60102] New: powerpc fp-bit ices at dwf_regno

[Bug middle-end/60102] New: powerpc fp-bit ices at dwf_regno

[paulo@matos-sorge.com]

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

            Bug ID: 60102
           Summary: powerpc fp-bit ices at dwf_regno
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: paulo@matos-sorge.com

Created attachment 32073
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32073&action=edit
Testcase

This might be a dup of PR52372 or PR57933 but since I am not sure I am opening
a new bug.

When trying to compile powerpc libgcc fp-bit I get an ICE using trunk:

$ /home/pmatos/projects/EXTERNAL/GCC/builds/gcc-trunk_powerpc/./gcc/cc1
-fpreprocessed fp-bit.i -quiet -dumpbase fp-bit.c -msoft-float -mcpu=8540
-auxbase-strip _addsub_df.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector
-fvisibility=hidden -o fp-bit.s
GNU C (GCC) version 4.9.0 20140205 (experimental) (powerpc-eabispe)
        compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20140205 (experimental) (powerpc-eabispe)
        compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 52229a64c376a95d997a16c551e2c79f
fp-bit.i: In function ‘fn3’:
fp-bit.i:27:1: internal compiler error: in dwf_regno, at dwarf2cfi.c:909
 }
 ^
0x786749 dwf_regno
        ../../../gcc-trunk/gcc/dwarf2cfi.c:909
0x78696b dwarf2out_flush_queued_reg_saves
        ../../../gcc-trunk/gcc/dwarf2cfi.c:988
0x789981 scan_trace
        ../../../gcc-trunk/gcc/dwarf2cfi.c:2522
0x789ab2 create_cfi_notes
        ../../../gcc-trunk/gcc/dwarf2cfi.c:2565
0x78a553 execute_dwarf2_frame
        ../../../gcc-trunk/gcc/dwarf2cfi.c:2925
0x78b402 execute
        ../../../gcc-trunk/gcc/dwarf2cfi.c:3421
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



I will attach the fp-bit.i reduced version.
>From gcc-bugs-return-442902-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 06 21:17:05 2014
Return-Path: <gcc-bugs-return-442902-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10515 invoked by alias); 6 Feb 2014 21:17:05 -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 10467 invoked by uid 48); 6 Feb 2014 21:17:01 -0000
From: "thatcadguy at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60088] Segfault when using quad precision and -march=native on  gfortran
Date: Thu, 06 Feb 2014 21:17: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.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thatcadguy at gmail dot com
X-Bugzilla-Status: WAITING
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-60088-4-PPzLQDQVyW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60088-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60088-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-02/txt/msg00659.txt.bz2
Content-length: 340

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`088

--- Comment #11 from Jacob Abel <thatcadguy at gmail dot com> ---
The culprit that -march=native activates on my Core i7 laptop is -mavx.
Compiling with -mavx causes the segfault, without is fine. Unfortunately, that
flag was not set on my other laptop, so might be multiple issues here.

[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno

[sebastian.huber@embedded-brains.de]

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

Sebastian Huber <sebastian.huber@embedded-brains.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sebastian.huber@embedded-br
                   |                            |ains.de

--- Comment #1 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
I can confirm this problem on the GCC 4.9.0 release.  This is a bit unfortunate
since on 2014-04-17 everything was fine:

http://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01349.html

[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno

[sebastian.huber@embedded-brains.de]

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

--- Comment #2 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
Sorry, but my test run on 2014-04-17 used --disable-multilib, so it didn't
build the multilib in question.  So the problem was also present on 2014-04-17.

[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |patrick at motec dot com.au

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 60945 has been marked as a duplicate of this bug. ***

[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno

[sebastian.huber@embedded-brains.de]

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

--- Comment #4 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
I had to go back a bit to find a problematic commit:

3983036a8b6b2710c57777194f21507819a73553 is the first bad commit
commit 3983036a8b6b2710c57777194f21507819a73553
Author: chrbr <chrbr@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Tue May 21 07:48:08 2013 +0000

    2013-05-21  Christian Bruel  <christian.bruel@st.com>

            * dwarf2out.c (multiple_reg_loc_descriptor): Use dbx_reg_number for
            spanning registers. LEAF_REG_REMAP is supported only for contiguous
            registers. Set register size out of the PARALLEL loop.



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

:040000 040000 434a95d8d10d5196bc464622e1741164eb2f5d79
06baa9f87c6c993c6cd76d187246db20f793098e M      gcc

If I revert this patch on the current 4.9 branch, then I still get an ICE:

fp-bit.c: In function '_fpadd_parts':
fp-bit.c:738:1: internal compiler error: in dwf_regno, at dwarf2cfi.c:909
 }
 ^
0x405adf dwf_regno
        /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:909
0x532cdb dwf_regno
        /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:909
0x532cdb dwarf2out_flush_queued_reg_saves
        /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:990
0x534cf3 scan_trace
        /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2415
0x535308 create_cfi_notes
        /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2565
0x535308 execute_dwarf2_frame
        /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2925
0x535308 execute
        /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:3421
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno

[cesar at codesourcery dot com]

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

Cesar Philippidis <cesar at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cesar at codesourcery dot com

--- Comment #6 from Cesar Philippidis <cesar at codesourcery dot com> ---
I've found a similar problem with dwf_regno() when I tried to bootstrap a
ppc-eabispe compiler. The problem there is the register aliasing of r0 between
32 and 64-bit modes. The rs6000 backend uses pseudo registers to disambiguate
those two usages. 

I've posted a patch here
<http://gcc.gnu.org/ml/gcc-patches/2014-04/msg02064.html>, but it hasn't been
reviewed yet.

[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno

[sandra at codesourcery dot com]

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

Sandra Loosemore <sandra at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandra at codesourcery dot com

--- Comment #7 from Sandra Loosemore <sandra at codesourcery dot com> ---
I ran into the same problem compiling fp-bit.c.  Cesar's patch isn't enough to
fix my build on its own -- I also had to revert the r199132 patch Sebastian
pointed at in comment 4 to avoid another assertion failure in dbx_reg_number()
later on.

[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno

[raj.khem at gmail dot com]

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

--- Comment #8 from Khem Raj <raj.khem at gmail dot com> ---
(In reply to Sandra Loosemore from comment #7)
> I ran into the same problem compiling fp-bit.c.  Cesar's patch isn't enough
> to fix my build on its own -- I also had to revert the r199132 patch
> Sebastian pointed at in comment 4 to avoid another assertion failure in
> dbx_reg_number() later on.


After these two commits I get another ICE

powerpc-oe-linux-gnuspe-gcc  -m32 -mcpu=8548 -mabi=spe -mspe
-mfloat-gprs=double
--sysroot=/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/sysroots/p1022ds
-O2 -pipe -g -feliminate-unused-debug-types -O2  -O2 -pipe -g
-feliminate-unused-debug-types -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC
-mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I. -I.
-I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work/ppce500v2-oe-linux-gnuspe/libgcc/4.9.0-r0/gcc-4.9.0/build.powerpc-oe-linux-gnuspe.powerpc-oe-linux-gnuspe/powerpc-oe-linux-gnuspe/libgcc/../.././gcc
-I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc
-I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/.
-I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../gcc
-I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../include
-I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/dpd
-I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber
-DHAVE_CC_TLS  -o decLibrary.o -MT decLibrary.o -MD -MP -MF decLibrary.dep -c
/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c
/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c:
In function 'isinfd64':
/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c:60:1:
error: unrecognizable insn:
 }
 ^
(insn 2 4 3 2 (set (reg/v:DD 128 [ arg ])
        (reg:DD 3 3 [ arg ]))
/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c:53
-1
     (nil))
/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c:60:1:
internal compiler error: in extract_insn, at recog.c:2202
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno

[sandra at codesourcery dot com]

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

--- Comment #9 from Sandra Loosemore <sandra at codesourcery dot com> ---
I've been looking at this a little bit more.

DWARF_FRAME_REGNUM is specifically documented to take a hard register number as
its operand, so the assertion in dwf_regno is at least consistent with that. 
The one in dbx_reg_number is more dubious, since neither LEAF_REG_REMAP or
DBX_REGISTER_NUMBER are documented to require a hard register number.

So: either the powerpc backend is broken to be using a pseudo in this context,
or else the documentation for DWARF_FRAME_REGNUM should be changed to permit
this and the assertions (as necessary) moved into the target-specific
implementations of these macros.

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.1
            Summary|powerpc fp-bit ices at      |[4.9/4.10 Regression]
                   |dwf_regno                   |powerpc fp-bit ices at
                   |                            |dwf_regno

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Please specify more exactly the affected target triplet and specify a
known-to-work version.

Marking as regression for now.

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[sebastian.huber@embedded-brains.de]

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

--- Comment #11 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
(In reply to Richard Biener from comment #10)
> Please specify more exactly the affected target triplet and specify a
> known-to-work version.
> 
> Marking as regression for now.

A target is for example "powerpc-eabispe" or "powerpc-rtems".

Known to work are GCC 4.8.0, 4.8.1, 4.8.2 and 4.8.3.

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[uweigand at gcc dot gnu.org]

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

--- Comment #12 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(In reply to Sandra Loosemore from comment #9)
> I've been looking at this a little bit more.
> 
> DWARF_FRAME_REGNUM is specifically documented to take a hard register number
> as its operand, so the assertion in dwf_regno is at least consistent with
> that.  The one in dbx_reg_number is more dubious, since neither
> LEAF_REG_REMAP or DBX_REGISTER_NUMBER are documented to require a hard
> register number.
> 
> So: either the powerpc backend is broken to be using a pseudo in this
> context, or else the documentation for DWARF_FRAME_REGNUM should be changed
> to permit this and the assertions (as necessary) moved into the
> target-specific implementations of these macros.

All those routines are supposed to implement mappings from GCC internal hard
register numbers to some externally-defined number scheme (DWARF, DBX, ...), so
it is consistent that they only accept hard register numbers.

The rs6000 back-end isn't actually attempting to use a "pseudo", they're just
using a quick hack there: apparently, with SPE registers, GCC internal hard
registers 0 .. 31 may be backed by a pair of external registers in debug info,
where the high element of the pair gets a DWARF number in the 1200 ... 1231
range.

The rs6000_dwarf_register_span attempts to implement that by returning a
PARALLEL of two registers.  Now, according to the rules, those both ought to be
hard registers.  However, there is no GCC internal number defined for the high
part of the pair.  The back-end used to hack around that by simply using the
DWARF number (in the 1200 ... 1231) range as "hard" regno, combined with
another hack in rs6000_dbx_register_number that then just passes that number
through unchanged to the DWARF assembler output.

This all worked as long as the middle-end didn't look too closely at those
PARALLELs ... but with those extra asserts, it now fails.

I guess I don't quite understand why there aren't real GCC hard regnos to cover
those SPE high parts ... that seems the cleanest solution.   Not sure if this
was done to avoid some drawback I'm not seeing right now ...

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[ams at gcc dot gnu.org]

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

Andrew Stubbs <ams at gcc dot gnu.org> changed:

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

--- Comment #13 from Andrew Stubbs <ams at gcc dot gnu.org> ---
(In reply to Khem Raj from comment #8)
> error: unrecognizable insn:
>  }
>  ^
> (insn 2 4 3 2 (set (reg/v:DD 128 [ arg ])
>         (reg:DD 3 3 [ arg ]))

This is PR57353.

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[rohitarulraj at gmail dot com]

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

Rohit <rohitarulraj at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rohitarulraj at gmail dot com

--- Comment #14 from Rohit <rohitarulraj at gmail dot com> ---
I have tried to handle this as per comment #12.
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00513.html

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[edmarwjr at gcc dot gnu.org]

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

--- Comment #16 from edmarwjr at gcc dot gnu.org ---
Author: edmarwjr
Date: Mon Aug  4 16:34:34 2014
New Revision: 213596

URL: https://gcc.gnu.org/viewcvs?rev=213596&root=gcc&view=rev
Log:
    PR target/60102

[libgcc]
2014-07-31  Rohit  <rohitarulraj@freescale.com>
    * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update
      based on change in SPE high register numbers and 3 HTM registers.

[gcc]
2014-07-31  Rohit  <rohitarulraj@freescale.com>
    * config/rs6000/rs6000.c
      (rs6000_reg_names) : Add SPE high register names.
      (alt_reg_names) : Likewise.
      (rs6000_dwarf_register_span) : For SPE high registers, replace
      dwarf register numbers with GCC hard register numbers.
      (rs6000_init_dwarf_reg_sizes_extra) : Likewise.
      (rs6000_dbx_register_number): For SPE high registers, return dwarf
      register number for the corresponding GCC hard register number.

    * config/rs6000/rs6000.h
      (FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard
      register numbers for SPE high registers.
      (DWARF_FRAME_REGISTERS) :  Likewise.
      (DWARF_REG_TO_UNWIND_COLUMN) : Likewise.
      (DWARF_FRAME_REGNUM) : Likewise.
      (FIXED_REGISTERS) : Likewise.
      (CALL_USED_REGISTERS) : Likewise.
      (CALL_REALLY_USED_REGISTERS) : Likewise.
      (REG_ALLOC_ORDER) : Likewise.
      (enum reg_class) : Likewise.
      (REG_CLASS_NAMES) : Likewise.
      (REG_CLASS_CONTENTS) : Likewise.
      (SPE_HIGH_REGNO_P) : New macro to identify SPE high registers.    

    * gcc.target/powerpc/pr60102.c: New testcase.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c
    trunk/gcc/config/rs6000/rs6000.h
    trunk/gcc/config/rs6000/rs6000.md
    trunk/libgcc/ChangeLog
    trunk/libgcc/config/rs6000/linux-unwind.h

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[edmarwjr at gcc dot gnu.org]

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

--- Comment #17 from edmarwjr at gcc dot gnu.org ---
Author: edmarwjr
Date: Mon Aug  4 16:48:53 2014
New Revision: 213597

URL: https://gcc.gnu.org/viewcvs?rev=213597&root=gcc&view=rev
Log:
    PR target/60102

[libgcc]
2014-08-04  Rohit  <rohitarulraj@freescale.com>
    * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update
      based on change in SPE high register numbers and 3 HTM registers.

[gcc]
2014-08-04  Rohit  <rohitarulraj@freescale.com>
    * config/rs6000/rs6000.c
      (rs6000_reg_names) : Add SPE high register names.
      (alt_reg_names) : Likewise.
      (rs6000_dwarf_register_span) : For SPE high registers, replace
      dwarf register numbers with GCC hard register numbers.
      (rs6000_init_dwarf_reg_sizes_extra) : Likewise.
      (rs6000_dbx_register_number): For SPE high registers, return dwarf
      register number for the corresponding GCC hard register number.

    * config/rs6000/rs6000.h
      (FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard
      register numbers for SPE high registers.
      (DWARF_FRAME_REGISTERS) :  Likewise.
      (DWARF_REG_TO_UNWIND_COLUMN) : Likewise.
      (DWARF_FRAME_REGNUM) : Likewise.
      (FIXED_REGISTERS) : Likewise.
      (CALL_USED_REGISTERS) : Likewise.
      (CALL_REALLY_USED_REGISTERS) : Likewise.
      (REG_ALLOC_ORDER) : Likewise.
      (enum reg_class) : Likewise.
      (REG_CLASS_NAMES) : Likewise.
      (REG_CLASS_CONTENTS) : Likewise.
      (SPE_HIGH_REGNO_P) : New macro to identify SPE high registers.    

[gcc/testsuite]
2014-08-04  Rohit  <rohitarulraj@freescale.com>
    * gcc.target/powerpc/pr60102.c: New testcase.


Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr60102.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c
    branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.h
    branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.md
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_9-branch/libgcc/ChangeLog
    branches/gcc-4_9-branch/libgcc/config/rs6000/linux-unwind.h

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[edmarwjr at gcc dot gnu.org]

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

--- Comment #18 from edmarwjr at gcc dot gnu.org ---
Author: edmarwjr
Date: Mon Aug  4 16:55:07 2014
New Revision: 213598

URL: https://gcc.gnu.org/viewcvs?rev=213598&root=gcc&view=rev
Log:
[gcc/testsuite]
2014-08-04  Rohit  <rohitarulraj@freescale.com>

    PR target/60102
    * gcc.target/powerpc/pr60102.c: New testcase.


Added:
    trunk/gcc/testsuite/gcc.target/powerpc/pr60102.c
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/60102] [4.9/5 Regression] powerpc fp-bit ices at dwf_regno

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.9.3

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.2 has been released.

[Bug middle-end/60102] [4.9/5 Regression] powerpc fp-bit ices at dwf_regno

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-23
                 CC|                            |fxcoudert at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #20 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
The commits from comments #16 and #17 broke the compiler (and bootstrap) on
powerpc-apple-darwin9: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703

[Bug middle-end/60102] [4.9/5 Regression] powerpc fp-bit ices at dwf_regno

[fxcoudert at gmail dot com]

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

--- Comment #22 from fxcoudert at gmail dot com <fxcoudert at gmail dot com> ---
> Sorry. The "REGISTER_NAMES" macro that was updated in "rs6000.h" file gets
> redefined in "darwin.h" file. I can provide the required patch, but I don't
> have a darwin machine to test the changes.

If you upload a patch on the bugzilla entry, I will test it.

FX

[Bug middle-end/60102] [4.9/5 Regression] powerpc fp-bit ices at dwf_regno

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
Sounds like fallout on the 4.9 branch is not fixed yet (ppc-darwin bootstrap
fail) but the original bug is fixed?  Please open new bugs for new issues.

[Bug middle-end/60102] [4.9/5 Regression] powerpc fp-bit ices at dwf_regno

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

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

--- Comment #24 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #23)
> Sounds like fallout on the 4.9 branch is not fixed yet (ppc-darwin bootstrap
> fail) but the original bug is fixed?  Please open new bugs for new issues.

That looks like it. The ppc-darwin issues (4.9 and trunk) were reported there:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703