gcc-6.3: Backport patch to fix ICE on ARM

Submitted by Khem Raj on Oct. 7, 2017, 5:29 p.m. | Patch ID: 144754

Details

Message ID 20171007172923.36429-1-raj.khem@gmail.com
State Master Next
Commit d2631f45a057c53797b7ba657662f35f66a2b04e
Headers show

Commit Message

Khem Raj Oct. 7, 2017, 5:29 p.m.
Fixes
internal compiler error: Max. number of generated reload insns per insn is achieved (90)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-6.3.inc              |  1 +
 ...-relax-the-restriction-on-subreg-reload-f.patch | 51 ++++++++++++++++++++++
 2 files changed, 52 insertions(+)
 create mode 100644 meta/recipes-devtools/gcc/gcc-6.3/0056-LRA-PR70904-relax-the-restriction-on-subreg-reload-f.patch

Patch hide | download patch | download mbox

diff --git a/meta/recipes-devtools/gcc/gcc-6.3.inc b/meta/recipes-devtools/gcc/gcc-6.3.inc
index ec6d8cdac1..e569e0220b 100644
--- a/meta/recipes-devtools/gcc/gcc-6.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.3.inc
@@ -75,6 +75,7 @@  SRC_URI = "\
            file://0048-sync-gcc-stddef.h-with-musl.patch \
            file://0054_all_nopie-all-flags.patch \
            file://0055-unwind_h-glibc26.patch \
+           file://0056-LRA-PR70904-relax-the-restriction-on-subreg-reload-f.patch \
            ${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git a/meta/recipes-devtools/gcc/gcc-6.3/0056-LRA-PR70904-relax-the-restriction-on-subreg-reload-f.patch b/meta/recipes-devtools/gcc/gcc-6.3/0056-LRA-PR70904-relax-the-restriction-on-subreg-reload-f.patch
new file mode 100644
index 0000000000..231f147619
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-6.3/0056-LRA-PR70904-relax-the-restriction-on-subreg-reload-f.patch
@@ -0,0 +1,51 @@ 
+From a582b0a53d1dc8604a201348b99ca8de48784e7e Mon Sep 17 00:00:00 2001
+From: jiwang <jiwang@138bc75d-0d04-0410-961f-82ee72b054a4>
+Date: Thu, 12 May 2016 17:00:52 +0000
+Subject: [PATCH] [LRA] PR70904, relax the restriction on subreg reload for
+ wide mode
+
+2016-05-12  Jiong Wang  <jiong.wang@arm.com>
+
+gcc/
+  PR rtl-optimization/70904
+  * lra-constraint.c (process_addr_reg): Relax the restriction on
+  subreg reload for wide mode.
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236181 138bc75d-0d04-0410-961f-82ee72b054a4
+---
+Upstream-Status: Backport
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+
+ gcc/lra-constraints.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
+index f96fd458e23..73fb72a2ea5 100644
+--- a/gcc/lra-constraints.c
++++ b/gcc/lra-constraints.c
+@@ -1326,7 +1326,21 @@ process_addr_reg (rtx *loc, bool check_only_p, rtx_insn **before, rtx_insn **aft
+ 
+   subreg_p = GET_CODE (*loc) == SUBREG;
+   if (subreg_p)
+-    loc = &SUBREG_REG (*loc);
++    {
++      reg = SUBREG_REG (*loc);
++      mode = GET_MODE (reg);
++
++      /* For mode with size bigger than ptr_mode, there unlikely to be "mov"
++	 between two registers with different classes, but there normally will
++	 be "mov" which transfers element of vector register into the general
++	 register, and this normally will be a subreg which should be reloaded
++	 as a whole.  This is particularly likely to be triggered when
++	 -fno-split-wide-types specified.  */
++      if (in_class_p (reg, cl, &new_class)
++	  || GET_MODE_SIZE (mode) <= GET_MODE_SIZE (ptr_mode))
++       loc = &SUBREG_REG (*loc);
++    }
++
+   reg = *loc;
+   mode = GET_MODE (reg);
+   if (! REG_P (reg))
+-- 
+2.14.2
+

Comments

Andre McCurdy Oct. 10, 2017, 5:59 p.m.
On Sat, Oct 7, 2017 at 10:29 AM, Khem Raj <raj.khem@gmail.com> wrote:
> Fixes
> internal compiler error: Max. number of generated reload insns per insn is achieved (90)

Is there a plan to update gcc 6.3 -> 6.4 in OE 2.5?

> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
Khem Raj Oct. 10, 2017, 7:04 p.m.
On Tue, Oct 10, 2017 at 10:59 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Sat, Oct 7, 2017 at 10:29 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> Fixes
>> internal compiler error: Max. number of generated reload insns per insn is achieved (90)
>
> Is there a plan to update gcc 6.3 -> 6.4 in OE 2.5?

actually, I was thinking of not touching 6.x at all since it solely
for backward compatibility
so upgrading it might cause issues for users, and since we do not test
it actively, we would
not know them. I would rather keep it to the version we have once
tested but I am open
to maintaining an upgraded version if community thinks that is
beneficial for them. there
wont be any testing on it in 2.5 release cycle,

>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
Andre McCurdy Oct. 10, 2017, 7:55 p.m.
On Tue, Oct 10, 2017 at 12:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Oct 10, 2017 at 10:59 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Sat, Oct 7, 2017 at 10:29 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>> Fixes
>>> internal compiler error: Max. number of generated reload insns per insn is achieved (90)
>>
>> Is there a plan to update gcc 6.3 -> 6.4 in OE 2.5?
>
> actually, I was thinking of not touching 6.x at all since it solely
> for backward compatibility
> so upgrading it might cause issues for users

gcc 6.3 to 6.4 isn't really an upgrade in the sense of any new
features, it's just bug fixes, some of which look somewhat important:

  https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.4

Since gcc 6.x is now well into the maintenance phase, I'd be inclined
to think that the risk -vs- reward odds of taking these upstream fixes
is pretty good.

>, and since we do not test
> it actively, we would
> not know them. I would rather keep it to the version we have once
> tested but I am open
> to maintaining an upgraded version if community thinks that is
> beneficial for them. there
> wont be any testing on it in 2.5 release cycle,

Just having the upgrade available to the community is useful, even if
there are no guarantees or testing. I've backporting gcc 6.3 into my
morty branch as it fixes build issues with musl. Morty with gcc 6.3 is
not a combination which was ever officially supported or tested
upstream, but I very much appreciate the fact that upgrading gcc 6.2
to 6.3 in morty only requires a few cherry-picks :-)

>>
>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>> ---
Khem Raj Oct. 10, 2017, 8:13 p.m.
On Tue, Oct 10, 2017 at 12:55 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Tue, Oct 10, 2017 at 12:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, Oct 10, 2017 at 10:59 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>> On Sat, Oct 7, 2017 at 10:29 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> Fixes
>>>> internal compiler error: Max. number of generated reload insns per insn is achieved (90)
>>>
>>> Is there a plan to update gcc 6.3 -> 6.4 in OE 2.5?
>>
>> actually, I was thinking of not touching 6.x at all since it solely
>> for backward compatibility
>> so upgrading it might cause issues for users
>
> gcc 6.3 to 6.4 isn't really an upgrade in the sense of any new
> features, it's just bug fixes, some of which look somewhat important:
>
>   https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.4
>
> Since gcc 6.x is now well into the maintenance phase, I'd be inclined
> to think that the risk -vs- reward odds of taking these upstream fixes
> is pretty good.

I think we understand that its a bug fix only, however, upstream is not
validating gcc 6.x releases against OE-Core, and OE community isnt
doing that either. Invariably, while low, there are chances
of regressions specific to OE

>
>>, and since we do not test
>> it actively, we would
>> not know them. I would rather keep it to the version we have once
>> tested but I am open
>> to maintaining an upgraded version if community thinks that is
>> beneficial for them. there
>> wont be any testing on it in 2.5 release cycle,
>
> Just having the upgrade available to the community is useful, even if
> there are no guarantees or testing. I've backporting gcc 6.3 into my
> morty branch as it fixes build issues with musl. Morty with gcc 6.3 is
> not a combination which was ever officially supported or tested
> upstream, but I very much appreciate the fact that upgrading gcc 6.2
> to 6.3 in morty only requires a few cherry-picks :-)

I am open for if there are more like minded folks who think this will be a good
thing to have. so all listening please chime in

>
>>>
>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>> ---
Otavio Salvador Oct. 10, 2017, 8:31 p.m.
On Tue, Oct 10, 2017 at 5:13 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Oct 10, 2017 at 12:55 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> Just having the upgrade available to the community is useful, even if
>> there are no guarantees or testing. I've backporting gcc 6.3 into my
>> morty branch as it fixes build issues with musl. Morty with gcc 6.3 is
>> not a combination which was ever officially supported or tested
>> upstream, but I very much appreciate the fact that upgrading gcc 6.2
>> to 6.3 in morty only requires a few cherry-picks :-)
>
> I am open for if there are more like minded folks who think this will be a good
> thing to have. so all listening please chime in

I'd prefer for 2.5 time frame to drop gcc 6 as 2.4 can be seen as an
upgrade path to it.

If possible I'd prefer to add clang to oe-core than support multiple
versions of gcc.
Khem Raj Oct. 10, 2017, 10:51 p.m.
On Tue, Oct 10, 2017 at 1:31 PM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> On Tue, Oct 10, 2017 at 5:13 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, Oct 10, 2017 at 12:55 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>> Just having the upgrade available to the community is useful, even if
>>> there are no guarantees or testing. I've backporting gcc 6.3 into my
>>> morty branch as it fixes build issues with musl. Morty with gcc 6.3 is
>>> not a combination which was ever officially supported or tested
>>> upstream, but I very much appreciate the fact that upgrading gcc 6.2
>>> to 6.3 in morty only requires a few cherry-picks :-)
>>
>> I am open for if there are more like minded folks who think this will be a good
>> thing to have. so all listening please chime in
>
> I'd prefer for 2.5 time frame to drop gcc 6 as 2.4 can be seen as an
> upgrade path to it.

I think it probably it a fine idea to update it so it can be
cherry-picked for backport
to prior releases, if we do that cherry-pick officially or not can be
discussed later
then we can delete it. Usually we keep two versions of gcc available
to keep migration tail
if gcc8 comes out with in 2.5 release timeframe we might drop 6.x

Now on clang, I think thats a fine idea. We need some upvotes on
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9417

>
> If possible I'd prefer to add clang to oe-core than support multiple
> versions of gcc.
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750