| Message ID | 20171007172923.36429-1-raj.khem@gmail.com |
|---|---|
| State | Accepted |
| Commit | d2631f45a057c53797b7ba657662f35f66a2b04e |
| Headers | show |
| Series | gcc-6.3: Backport patch to fix ICE on ARM | expand |
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> > --- -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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> >> --- -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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> >>> --- -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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> >>>> --- -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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. -- 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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 +
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 -- 2.14.2 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core