gcc-6.3: Backport patch to fix ICE on ARM
PATCH 1/1 gcc-6.3: Backport patch to fix ICE on ARM
Fixes
internal compiler error: Max. number of generated reload insns per insn is achieved (90)
--- 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
meta/recipes-devtools/gcc/gcc-6.3.inc +1 -0
@@ -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 = "\
meta/recipes-devtools/gcc/gcc-6.3/0056-LRA-PR70904-relax-the-restriction-on-subreg-reload-f.patch new file +51 -0
51 lines not on this page · raw message
Signature · 1 line
2.14.2
Quoted 2 lines · Khem Raj
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?
Quoted 2 lines
Signed-off-by Khem Raj <[email protected]>---
Quoted 5 lines · Andre McCurdy
Quoted 2 lines · Khem Raj
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,
Quoted 3 lines
Quoted 3 lines
Signed-off-by Khem Raj <[email protected]>---
Quoted 10 lines · Khem Raj
Quoted 5 lines · Andre McCurdy
Quoted 2 lines · Khem Raj
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.
Quoted 7 lines
, 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 :-)
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Signed-off-by Khem Raj <[email protected]>---
Quoted 12 lines · Andre McCurdy
Quoted 10 lines · Khem Raj
Quoted 5 lines · Andre McCurdy
Quoted 2 lines · Khem Raj
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
Quoted 8 lines
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
Quoted 9 lines
Quoted 8 lines
, 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,
Quoted 6 lines
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Signed-off-by Khem Raj <[email protected]>---
Quoted 10 lines · Khem Raj
Quoted 6 lines · Andre McCurdy
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.
Signature · 3 lines
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
Quoted 9 lines · Otavio Salvador
Quoted 8 lines · Khem Raj
Quoted 6 lines · Andre McCurdy
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 :-)
Quoted 5 lines
Quoted 2 lines
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
Quoted 8 lines
If possible I'd prefer to add clang to oe-core than support multiple versions of gcc.
--
Otavio SalvadorO.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750