Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Fri, Apr 04, 2014 at 10:38:49AM -0500, Bill Schmidt wrote: Thanks to everyone who helped with development, testing, and review of the patch set! I've committed the changes to 4.8 this morning. Note that patch 15/26 was rejected as not really germane to this series and has been submitted separately by Peter Bergner. While trying to merge this to redhat/gcc-4_8-branch, I've so far noticed that you have merged in the r199972 change (apparently without ChangeLog entry), without r202642 change that reverted it later on. Can you please revert that one liner change? Jakub
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, Apr 09, 2014 at 11:51:54AM +0200, Jakub Jelinek wrote: On Fri, Apr 04, 2014 at 10:38:49AM -0500, Bill Schmidt wrote: Thanks to everyone who helped with development, testing, and review of the patch set! I've committed the changes to 4.8 this morning. Note that patch 15/26 was rejected as not really germane to this series and has been submitted separately by Peter Bergner. While trying to merge this to redhat/gcc-4_8-branch, I've so far noticed that you have merged in the r199972 change (apparently without ChangeLog entry), without r202642 change that reverted it later on. Can you please revert that one liner change? Another issue is bad toplevel ChangeLog entries. 2014-04-04 Bill Schmidt wschm...@linux.vnet.ibm.com Backport from mainline 2013-11-22 Ulrich Weigand ulrich.weig...@de.ibm.com * libgo/config/libtool.m4: Update to mainline version. * libgo/configure: Regenerate. 2013-11-17 Ulrich Weigand ulrich.weig...@de.ibm.com * libgo/config/libtool.m4: Update to mainline version. * libgo/configure: Regenerate. 2013-11-15 Ulrich Weigand ulrich.weig...@de.ibm.com * libtool.m4: Update to mainline version. * libjava/libltdl/acinclude.m4: Likewise. * gcc/configure: Regenerate. * boehm-gc/configure: Regenerate. * libatomic/configure: Regenerate. * libbacktrace/configure: Regenerate. * libffi/configure: Regenerate. * libgfortran/configure: Regenerate. * libgomp/configure: Regenerate. * libitm/configure: Regenerate. * libjava/configure: Regenerate. * libjava/libltdl/configure: Regenerate. * libjava/classpath/configure: Regenerate. * libmudflap/configure: Regenerate. * libobjc/configure: Regenerate. * libquadmath/configure: Regenerate. * libsanitizer/configure: Regenerate. * libssp/configure: Regenerate. * libstdc++-v3/configure: Regenerate. * lto-plugin/configure: Regenerate. * zlib/configure: Regenerate. Except for the libtool.m4 change, which is a toplevel change, all those changes are to files in subdirectories which have their own ChangeLog file (or in case of libjava/classpath ChangeLog.gcj), the ChangeLog entries should go into those directories rather than the toplevel ChangeLog. Jakub
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, 2014-04-09 at 11:51 +0200, Jakub Jelinek wrote: On Fri, Apr 04, 2014 at 10:38:49AM -0500, Bill Schmidt wrote: Thanks to everyone who helped with development, testing, and review of the patch set! I've committed the changes to 4.8 this morning. Note that patch 15/26 was rejected as not really germane to this series and has been submitted separately by Peter Bergner. While trying to merge this to redhat/gcc-4_8-branch, I've so far noticed that you have merged in the r199972 change (apparently without ChangeLog entry), without r202642 change that reverted it later on. Can you please revert that one liner change? Hm, yes. Sorry for the oversight! Testing the revert now and will check it in shortly. Thanks, Bill Jakub
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, 2014-04-09 at 12:03 +0200, Jakub Jelinek wrote: Another issue is bad toplevel ChangeLog entries. 2014-04-04 Bill Schmidt wschm...@linux.vnet.ibm.com Backport from mainline 2013-11-22 Ulrich Weigand ulrich.weig...@de.ibm.com * libgo/config/libtool.m4: Update to mainline version. * libgo/configure: Regenerate. 2013-11-17 Ulrich Weigand ulrich.weig...@de.ibm.com * libgo/config/libtool.m4: Update to mainline version. * libgo/configure: Regenerate. 2013-11-15 Ulrich Weigand ulrich.weig...@de.ibm.com * libtool.m4: Update to mainline version. * libjava/libltdl/acinclude.m4: Likewise. * gcc/configure: Regenerate. * boehm-gc/configure: Regenerate. * libatomic/configure: Regenerate. * libbacktrace/configure: Regenerate. * libffi/configure: Regenerate. * libgfortran/configure: Regenerate. * libgomp/configure: Regenerate. * libitm/configure: Regenerate. * libjava/configure: Regenerate. * libjava/libltdl/configure: Regenerate. * libjava/classpath/configure: Regenerate. * libmudflap/configure: Regenerate. * libobjc/configure: Regenerate. * libquadmath/configure: Regenerate. * libsanitizer/configure: Regenerate. * libssp/configure: Regenerate. * libstdc++-v3/configure: Regenerate. * lto-plugin/configure: Regenerate. * zlib/configure: Regenerate. Except for the libtool.m4 change, which is a toplevel change, all those changes are to files in subdirectories which have their own ChangeLog file (or in case of libjava/classpath ChangeLog.gcj), the ChangeLog entries should go into those directories rather than the toplevel ChangeLog. Ah, right. I had meant to fix this before committing the patch set and dropped the ball. One question: Where are ChangeLog entries supposed to go for libgo? There doesn't seem to be any kind of ChangeLog file for that component. Thanks, Bill Jakub
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, Apr 09, 2014 at 10:27:33AM -0500, Bill Schmidt wrote: Ah, right. I had meant to fix this before committing the patch set and dropped the ball. Thanks. One question: Where are ChangeLog entries supposed to go for libgo? There doesn't seem to be any kind of ChangeLog file for that component. Probably nowhere. Jakub
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
Cleaned up as r209249. On Wed, 2014-04-09 at 17:28 +0200, Jakub Jelinek wrote: On Wed, Apr 09, 2014 at 10:27:33AM -0500, Bill Schmidt wrote: Ah, right. I had meant to fix this before committing the patch set and dropped the ball. Thanks. One question: Where are ChangeLog entries supposed to go for libgo? There doesn't seem to be any kind of ChangeLog file for that component. Probably nowhere. Jakub
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
Cleaned up as r209250. On Wed, 2014-04-09 at 11:51 +0200, Jakub Jelinek wrote: On Fri, Apr 04, 2014 at 10:38:49AM -0500, Bill Schmidt wrote: Thanks to everyone who helped with development, testing, and review of the patch set! I've committed the changes to 4.8 this morning. Note that patch 15/26 was rejected as not really germane to this series and has been submitted separately by Peter Bergner. While trying to merge this to redhat/gcc-4_8-branch, I've so far noticed that you have merged in the r199972 change (apparently without ChangeLog entry), without r202642 change that reverted it later on. Can you please revert that one liner change? Jakub
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
Thanks to everyone who helped with development, testing, and review of the patch set! I've committed the changes to 4.8 this morning. Note that patch 15/26 was rejected as not really germane to this series and has been submitted separately by Peter Bergner. 209087 1/26 diff-p8 209088 2/26 diff-p8-htm 209089 3/26 diff-le-config 209090 4/26 diff-le-libtool 209091 5/26 diff-le-tests 209093 6/26 diff-le-dfp 209094 7/26 diff-le-vector 209095 8/26 diff-abi-compat 209096 9/26 diff-abi-calls 209098 10/26 diff-abi-elfv2 209099 11/26 diff-abi-gotest 209100 12/26 diff-le-align 209102 13/26 diff-abi-libffi 209103 14/26 diff-dfp-abs 209104 16/26 diff-pr56843 209105 17/26 diff-direct-move 209106 18/26 diff-le-config-2 209107 19/26 diff-quad-memory 209108 20/26 diff-lra 209109 21/26 diff-le-vector-api 209110 22/26 diff-mcall 209111 23/26 diff-pr60137-pr60203 209112 24/26 diff-reload 209113 25/26 diff-v1ti 209114 26/26 diff-trunk-missing 209115 27/26 diff-aix 209116 28/26 diff-pr60735 209117 29/26 diff-vecdoc Thanks, Bill On Thu, 2014-04-03 at 10:24 -0400, David Edelsohn wrote: On Wed, Mar 19, 2014 at 3:23 PM, Bill Schmidt wschm...@linux.vnet.ibm.com wrote: Hi, Support for Power8 features and the new powerpc64le-linux-gnu target, including the ELFv2 ABI, has been developed up till now on the ibm/gcc-4_8-branch. It was appropriate to use this separate branch while the support was unstable, but this branch will not represent a particularly good support mechanism for distributions going forward. Most distros are set up to pull from the major release branches, and having a separate branch for one target is quite inconvenient. Also, the ibm/gcc-4_8-branch's original purpose is to serve as the code base for IBM's Advance Toolchain 7.0. Over time the two purposes that the branch currently serves will diverge and make things even more complicated. The code is now tested and stable enough that we are ready to backport this support to the FSF 4.8 branch. This patch series constitutes that backport. Almost all of the changes are specific to PowerPC portions of the code, and for those patches I am only CCing David. However, some of the patches require changes to common code, and for these I will CC Richard and Jakub. Three of these are slightly unrelated but necessary patches, one to enable decimal float ABS builtins, and two others to fix PR54537 and PR56843. In addition there are patches that update configuration files throughout for the new target, and some small changes in common call support (call.c, expr.h, function.c) to support how the new ABI handles calls. I realize it is unusual to backport such a large amount of code, but we have been asked by distribution partners to do this, and we feel it makes good sense for long-term support. I have tested the patch series by applying it to a clean FSF 4.8 branch and comparing the test results against those from the IBM 4.8 branch on three systems: * Power8, little endian (--mcpu=power8) * Power8, big endian (--mcpu=power8) * Power7, big endian (--mcpu=power7) I also checked a recursive diff against the two source directories to ensure that no patches were missed. Thanks, Bill [ 1/26] diff-p8 [ 2/26] diff-p8-htm [ 3/26] diff-le-config [ 4/26] diff-le-libtool [ 5/26] diff-le-tests [ 6/26] diff-le-dfp [ 7/26] diff-le-vector [ 8/26] diff-abi-compat [ 9/26] diff-abi-calls [10/26] diff-abi-elfv2 [11/26] diff-abi-gotest [12/26] diff-le-align [13/26] diff-abi-libffi [14/26] diff-dfp-abs [15/26] diff-pr54537 [16/26] diff-pr56843 [17/26] diff-direct-move [18/26] diff-le-config-2 [19/26] diff-quad-memory [20/26] diff-lra [21/26] diff-le-vector-api [22/26] diff-mcall [23/26] diff-pr60137-pr60203 [24/26] diff-reload [25/26] diff-v1ti [26/26] diff-trunk-missing With the positive feedback from Darwin and RTEMS, the additional backports for AIX and the bug fix for SPE, I am going to approve this patch series. There is a remaining issue with e600, but IBM LTC cannot reproduce it. If IBM can get more information, it can be addressed in a later patch to trunk and 4.8 branch. Thanks, David
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, Mar 19, 2014 at 3:23 PM, Bill Schmidt wschm...@linux.vnet.ibm.com wrote: Hi, Support for Power8 features and the new powerpc64le-linux-gnu target, including the ELFv2 ABI, has been developed up till now on the ibm/gcc-4_8-branch. It was appropriate to use this separate branch while the support was unstable, but this branch will not represent a particularly good support mechanism for distributions going forward. Most distros are set up to pull from the major release branches, and having a separate branch for one target is quite inconvenient. Also, the ibm/gcc-4_8-branch's original purpose is to serve as the code base for IBM's Advance Toolchain 7.0. Over time the two purposes that the branch currently serves will diverge and make things even more complicated. The code is now tested and stable enough that we are ready to backport this support to the FSF 4.8 branch. This patch series constitutes that backport. Almost all of the changes are specific to PowerPC portions of the code, and for those patches I am only CCing David. However, some of the patches require changes to common code, and for these I will CC Richard and Jakub. Three of these are slightly unrelated but necessary patches, one to enable decimal float ABS builtins, and two others to fix PR54537 and PR56843. In addition there are patches that update configuration files throughout for the new target, and some small changes in common call support (call.c, expr.h, function.c) to support how the new ABI handles calls. I realize it is unusual to backport such a large amount of code, but we have been asked by distribution partners to do this, and we feel it makes good sense for long-term support. I have tested the patch series by applying it to a clean FSF 4.8 branch and comparing the test results against those from the IBM 4.8 branch on three systems: * Power8, little endian (--mcpu=power8) * Power8, big endian (--mcpu=power8) * Power7, big endian (--mcpu=power7) I also checked a recursive diff against the two source directories to ensure that no patches were missed. Thanks, Bill [ 1/26] diff-p8 [ 2/26] diff-p8-htm [ 3/26] diff-le-config [ 4/26] diff-le-libtool [ 5/26] diff-le-tests [ 6/26] diff-le-dfp [ 7/26] diff-le-vector [ 8/26] diff-abi-compat [ 9/26] diff-abi-calls [10/26] diff-abi-elfv2 [11/26] diff-abi-gotest [12/26] diff-le-align [13/26] diff-abi-libffi [14/26] diff-dfp-abs [15/26] diff-pr54537 [16/26] diff-pr56843 [17/26] diff-direct-move [18/26] diff-le-config-2 [19/26] diff-quad-memory [20/26] diff-lra [21/26] diff-le-vector-api [22/26] diff-mcall [23/26] diff-pr60137-pr60203 [24/26] diff-reload [25/26] diff-v1ti [26/26] diff-trunk-missing With the positive feedback from Darwin and RTEMS, the additional backports for AIX and the bug fix for SPE, I am going to approve this patch series. There is a remaining issue with e600, but IBM LTC cannot reproduce it. If IBM can get more information, it can be addressed in a later patch to trunk and 4.8 branch. Thanks, David
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On 21/03/2014 1:05 pm, Bill Schmidt wrote: For convenience of those who have kindly agreed to test the patch series, here is the entire series as a single compressed patch. Note that this does not include patch 15/26, which we've agreed to submit separately. I have tested the patch with RTEMS head and see no change with our test results. Chris
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
Hi Bill, On 21 Mar 2014, at 02:05, Bill Schmidt wrote: For convenience of those who have kindly agreed to test the patch series, here is the entire series as a single compressed patch. Note that this does not include patch 15/26, which we've agreed to submit separately. To assess this on powerpc-apple-darwin9: - applied this series as per the attached archive. (You might wish to double-check for white-space issues, git complained about a few of the patches). - built tested all langs including obj-c++ and Ada (but NOT Java), (G5, m32/m64). I see no regressions related to this patch series*** ... as far as I'm concerned, the series presents no apparent issue for PPC/Darwin. cheers, Iain *** NOTE: JFTR, applying the series shows an apparent regression in g++/torture/pr45843.C @ -O3. however analysis of the case shows that it's just exposing a pre-existing issue (apparently, we don't check well-enough for alignment constraints before choosing ld with a LO14 reloc). Bill On Wed, 2014-03-19 at 14:23 -0500, Bill Schmidt wrote: Hi, Support for Power8 features and the new powerpc64le-linux-gnu target, including the ELFv2 ABI, has been developed up till now on the ibm/gcc-4_8-branch. It was appropriate to use this separate branch while the support was unstable, but this branch will not represent a particularly good support mechanism for distributions going forward. Most distros are set up to pull from the major release branches, and having a separate branch for one target is quite inconvenient. Also, the ibm/gcc-4_8-branch's original purpose is to serve as the code base for IBM's Advance Toolchain 7.0. Over time the two purposes that the branch currently serves will diverge and make things even more complicated. The code is now tested and stable enough that we are ready to backport this support to the FSF 4.8 branch. This patch series constitutes that backport. Almost all of the changes are specific to PowerPC portions of the code, and for those patches I am only CCing David. However, some of the patches require changes to common code, and for these I will CC Richard and Jakub. Three of these are slightly unrelated but necessary patches, one to enable decimal float ABS builtins, and two others to fix PR54537 and PR56843. In addition there are patches that update configuration files throughout for the new target, and some small changes in common call support (call.c, expr.h, function.c) to support how the new ABI handles calls. I realize it is unusual to backport such a large amount of code, but we have been asked by distribution partners to do this, and we feel it makes good sense for long-term support. I have tested the patch series by applying it to a clean FSF 4.8 branch and comparing the test results against those from the IBM 4.8 branch on three systems: * Power8, little endian (--mcpu=power8) * Power8, big endian (--mcpu=power8) * Power7, big endian (--mcpu=power7) I also checked a recursive diff against the two source directories to ensure that no patches were missed. Thanks, Bill [ 1/26] diff-p8 [ 2/26] diff-p8-htm [ 3/26] diff-le-config [ 4/26] diff-le-libtool [ 5/26] diff-le-tests [ 6/26] diff-le-dfp [ 7/26] diff-le-vector [ 8/26] diff-abi-compat [ 9/26] diff-abi-calls [10/26] diff-abi-elfv2 [11/26] diff-abi-gotest [12/26] diff-le-align [13/26] diff-abi-libffi [14/26] diff-dfp-abs [15/26] diff-pr54537 [16/26] diff-pr56843 [17/26] diff-direct-move [18/26] diff-le-config-2 [19/26] diff-quad-memory [20/26] diff-lra [21/26] diff-le-vector-api [22/26] diff-mcall [23/26] diff-pr60137-pr60203 [24/26] diff-reload [25/26] diff-v1ti [26/26] diff-trunk-missing 4_8-backport-single.patch.bz2
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
Alan Modra wrote: On Wed, Mar 19, 2014 at 03:35:59PM -0600, Jeff Law wrote: On 03/19/14 15:03, Bill Schmidt wrote: The three pieces that are somewhat controversial for non-powerpc targets are 9/26, 10/26, 15/26. * Uli and Alan, can you speak to any concerns for 9/26? I've got no concerns about 9/26. Uli, Alan and myself worked through this pretty thoroughly. I've had those in the back of my mind as something we're going to want to make sure to pull in. Thanks Jeff. I don't have any concern over 9/26, it's quite conservative like most of the ELFv2 implementation. When we were looking at parameter passing changes we didn't go as far as we could. For example, we still pass fp to varargs functions in both fp regs and on the stack, when only the stack will be used by a callee correctly implementing either ELFv2 or ELFv1 ABIs. Another thing that we didn't change is that sibcalls can be allowed in more cases than the current code allows. I concur with Jeff and Alan that 9/26 should be safe. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, 2014-03-19 at 16:03 -0500, Bill Schmidt wrote: On Wed, 2014-03-19 at 21:05 +0100, Jakub Jelinek wrote: I guess the most important question is what guarantees there are that it won't affect non-powerpc* ports too much (my main concern is the 9/26 patch, plus the C++ FE / libstdc++ changes), and how much does this affect code generation and overall stability of the PowerPC big endian existing targets. * 15/26 might be one we can do without. I need to check with Peter Bergner, who originally backported Fabien's patch, but unfortunately he is on vacation. That patch fixed a problem that originated on an x86 platform. I can try respinning the patch series without this one and see what breaks, or if Peter happens to see this while he's on vacation, perhaps he can comment. This was a fix to bring GCC into agreement with XLC++ and clang wrt the test case in PR54537. The XL team also had complained separately that they couldn't compile programs that included the header file tr1/cmath because it contained that bug. That said, this fix is not required for POWER8 or LE support, so if the RMs don't want this backported to the FSF 4.8 tree, I'm ok with that. That being said, we will ask the 4.8 based distros to pick up this patch since it fixes a bug that XL cannot workaround. Peter
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Thu, Mar 20, 2014 at 04:25:54PM -0500, Peter Bergner wrote: On Wed, 2014-03-19 at 16:03 -0500, Bill Schmidt wrote: On Wed, 2014-03-19 at 21:05 +0100, Jakub Jelinek wrote: I guess the most important question is what guarantees there are that it won't affect non-powerpc* ports too much (my main concern is the 9/26 patch, plus the C++ FE / libstdc++ changes), and how much does this affect code generation and overall stability of the PowerPC big endian existing targets. * 15/26 might be one we can do without. I need to check with Peter Bergner, who originally backported Fabien's patch, but unfortunately he is on vacation. That patch fixed a problem that originated on an x86 platform. I can try respinning the patch series without this one and see what breaks, or if Peter happens to see this while he's on vacation, perhaps he can comment. This was a fix to bring GCC into agreement with XLC++ and clang wrt the test case in PR54537. The XL team also had complained separately that they couldn't compile programs that included the header file tr1/cmath because it contained that bug. That said, this fix is not required for POWER8 or LE support, so if the RMs don't want this backported to the FSF 4.8 tree, I'm ok with that. That being said, we will ask the 4.8 based distros to pick up this patch since it fixes a bug that XL cannot workaround. IMHO it shouldn't be backported as part of the POWER8/LE series, it seems unrelated. If the C++ and libstdc++ maintainers agree that it should be backported, then it can be, but please do it independently on the rest of the backports. Jakub
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On 03/19/14 21:18, Alan Modra wrote: implementing either ELFv2 or ELFv1 ABIs. Another thing that we didn't change is that sibcalls can be allowed in more cases than the current code allows. Right. IIRC we deferred allowing more sibcalls until the next stage1 out of an abundance of caution. jeff
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, Mar 19, 2014 at 02:23:58PM -0500, Bill Schmidt wrote: Support for Power8 features and the new powerpc64le-linux-gnu target, including the ELFv2 ABI, has been developed up till now on the ibm/gcc-4_8-branch. It was appropriate to use this separate branch while the support was unstable, but this branch will not represent a particularly good support mechanism for distributions going forward. Most distros are set up to pull from the major release branches, and having a separate branch for one target is quite inconvenient. Also, the ibm/gcc-4_8-branch's original purpose is to serve as the code base for IBM's Advance Toolchain 7.0. Over time the two purposes that the branch currently serves will diverge and make things even more complicated. The code is now tested and stable enough that we are ready to backport this support to the FSF 4.8 branch. This patch series constitutes that backport. I guess the most important question is what guarantees there are that it won't affect non-powerpc* ports too much (my main concern is the 9/26 patch, plus the C++ FE / libstdc++ changes), and how much does this affect code generation and overall stability of the PowerPC big endian existing targets. Jakub
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, Mar 19, 2014 at 4:05 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Mar 19, 2014 at 02:23:58PM -0500, Bill Schmidt wrote: Support for Power8 features and the new powerpc64le-linux-gnu target, including the ELFv2 ABI, has been developed up till now on the ibm/gcc-4_8-branch. It was appropriate to use this separate branch while the support was unstable, but this branch will not represent a particularly good support mechanism for distributions going forward. Most distros are set up to pull from the major release branches, and having a separate branch for one target is quite inconvenient. Also, the ibm/gcc-4_8-branch's original purpose is to serve as the code base for IBM's Advance Toolchain 7.0. Over time the two purposes that the branch currently serves will diverge and make things even more complicated. The code is now tested and stable enough that we are ready to backport this support to the FSF 4.8 branch. This patch series constitutes that backport. I guess the most important question is what guarantees there are that it won't affect non-powerpc* ports too much (my main concern is the 9/26 patch, plus the C++ FE / libstdc++ changes), and how much does this affect code generation and overall stability of the PowerPC big endian existing targets. Before this patch is approved, we are going to thoroughly confirm that it does not harm any other PowerPC targets (big endian PowerLinux, eABI, nor AIX). Any help with testng from the PPC eABI community is appreciated. - David
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, 2014-03-19 at 21:05 +0100, Jakub Jelinek wrote: I guess the most important question is what guarantees there are that it won't affect non-powerpc* ports too much (my main concern is the 9/26 patch, plus the C++ FE / libstdc++ changes), and how much does this affect code generation and overall stability of the PowerPC big endian existing targets. Jakub The three pieces that are somewhat controversial for non-powerpc targets are 9/26, 10/26, 15/26. * Uli and Alan, can you speak to any concerns for 9/26? * 10/26 hits libstdc++, but only in a minor way for the extract_symvers script; it adds a sed to ignore a string added for powerpc64le, so shouldn't be a problem. * 15/26 might be one we can do without. I need to check with Peter Bergner, who originally backported Fabien's patch, but unfortunately he is on vacation. That patch fixed a problem that originated on an x86 platform. I can try respinning the patch series without this one and see what breaks, or if Peter happens to see this while he's on vacation, perhaps he can comment. For PowerPC targets, I have already checked out powerpc64-linux (big endian). As David mentioned, I need to apply the patch series on an AIX machine and test it before this can be accepted. We don't have any way of testing the eabi stuff, so community help would be very much appreciated there. Thanks, Bill
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, 2014-03-19 at 16:03 -0500, Bill Schmidt wrote: On Wed, 2014-03-19 at 21:05 +0100, Jakub Jelinek wrote: I guess the most important question is what guarantees there are that it won't affect non-powerpc* ports too much (my main concern is the 9/26 patch, plus the C++ FE / libstdc++ changes), and how much does this affect code generation and overall stability of the PowerPC big endian existing targets. Jakub The three pieces that are somewhat controversial for non-powerpc targets are 9/26, 10/26, 15/26. I forgot to mention that these bits have all been upstream in trunk since last autumn, so there's been quite a bit of burn-in at that level. Obviously that is not the same as being burned in on 4.8, but it does help provide a bit of confidence. Bill * Uli and Alan, can you speak to any concerns for 9/26? * 10/26 hits libstdc++, but only in a minor way for the extract_symvers script; it adds a sed to ignore a string added for powerpc64le, so shouldn't be a problem. * 15/26 might be one we can do without. I need to check with Peter Bergner, who originally backported Fabien's patch, but unfortunately he is on vacation. That patch fixed a problem that originated on an x86 platform. I can try respinning the patch series without this one and see what breaks, or if Peter happens to see this while he's on vacation, perhaps he can comment. For PowerPC targets, I have already checked out powerpc64-linux (big endian). As David mentioned, I need to apply the patch series on an AIX machine and test it before this can be accepted. We don't have any way of testing the eabi stuff, so community help would be very much appreciated there. Thanks, Bill
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On 03/19/14 15:03, Bill Schmidt wrote: On Wed, 2014-03-19 at 21:05 +0100, Jakub Jelinek wrote: I guess the most important question is what guarantees there are that it won't affect non-powerpc* ports too much (my main concern is the 9/26 patch, plus the C++ FE / libstdc++ changes), and how much does this affect code generation and overall stability of the PowerPC big endian existing targets. Jakub The three pieces that are somewhat controversial for non-powerpc targets are 9/26, 10/26, 15/26. * Uli and Alan, can you speak to any concerns for 9/26? I've got no concerns about 9/26. Uli, Alan and myself worked through this pretty thoroughly. I've had those in the back of my mind as something we're going to want to make sure to pull in. Jeff
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
On Wed, Mar 19, 2014 at 03:35:59PM -0600, Jeff Law wrote: On 03/19/14 15:03, Bill Schmidt wrote: On Wed, 2014-03-19 at 21:05 +0100, Jakub Jelinek wrote: I guess the most important question is what guarantees there are that it won't affect non-powerpc* ports too much (my main concern is the 9/26 patch, plus the C++ FE / libstdc++ changes), and how much does this affect code generation and overall stability of the PowerPC big endian existing targets. Jakub The three pieces that are somewhat controversial for non-powerpc targets are 9/26, 10/26, 15/26. * Uli and Alan, can you speak to any concerns for 9/26? I've got no concerns about 9/26. Uli, Alan and myself worked through this pretty thoroughly. I've had those in the back of my mind as something we're going to want to make sure to pull in. Thanks Jeff. I don't have any concern over 9/26, it's quite conservative like most of the ELFv2 implementation. When we were looking at parameter passing changes we didn't go as far as we could. For example, we still pass fp to varargs functions in both fp regs and on the stack, when only the stack will be used by a callee correctly implementing either ELFv2 or ELFv1 ABIs. Another thing that we didn't change is that sibcalls can be allowed in more cases than the current code allows. -- Alan Modra Australia Development Lab, IBM
