[Ubuntu 16.04] Enable P9 toolchain

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1522410/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

This bug is currently not actionable. No information about which packages require updates to support POWER9, or upstream revisions/commits where this support is available, or when these will be released.

Marking incomplete for now.

------- Comment From <email address hidden> 2016-01-13 11:18 EDT-------
(In reply to comment #17)
> This bug is currently not actionable. No information about which packages
> require updates to support POWER9, or upstream revisions/commits where this
> support is available, or when these will be released.
>
> Marking incomplete for now.

The toolchain is made up of the important binutils, GCC and GLIBC packages. Secondarily, you can add GDB to the list, but it's POWER9 disassembler support is inherited from binutils.

From my recollection, Ububtu 16.04 will use binutils 2.26, GCC 5.x and GLIBC 2.23 versions.
Binutils 2.26 contains full POWER9 support, so no patches are required for that. GLIBC 2.23 currently has all of the POWER9 support we'll be able to deliver in time for 16.04, so no patches are required for that either. The only package that requires backports if GCC and those are already available in out IBM GCC 5 branch which Canonical is already pulling from. We are only missing which patches from that branch has Canonical pulled and which haven't. Maybe they have pulled them all?

Given the above, I don't think marking this feature as incomplete is appropriate.

On Wed, Jan 13, 2016 at 08:10:43PM -0000, bugproxy wrote:
> The toolchain is made up of the important binutils, GCC and GLIBC
> packages. Secondarily, you can add GDB to the list, but it's POWER9
> disassembler support is inherited from binutils.

> From my recollection, Ububtu 16.04 will use binutils 2.26, GCC 5.x and
> GLIBC 2.23 versions. Binutils 2.26 contains full POWER9 support, so no
> patches are required for that. GLIBC 2.23 currently has all of the POWER9
> support we'll be able to deliver in time for 16.04, so no patches are
> required for that either. The only package that requires backports if GCC
> and those are already available in out IBM GCC 5 branch which Canonical is
> already pulling from. We are only missing which patches from that branch
> has Canonical pulled and which haven't. Maybe they have pulled them all?

As far as I'm aware, we are not currently pulling any gcc patches directly
from IBM, but only using the code that is included in the upstream gcc-5
branch. Can you please point us at the revision on the IBM gcc-5 branch
that contains the necessary P9 support, so we can evaluate this for
inclusion?

------- Comment From <email address hidden> 2016-01-13 18:45 EDT-------
(In reply to comment #20)
> As far as I'm aware, we are not currently pulling any gcc patches directly
> from IBM, but only using the code that is included in the upstream gcc-5
> branch. Can you please point us at the revision on the IBM gcc-5 branch
> that contains the necessary P9 support, so we can evaluate this for
> inclusion?

Just to be clear, the IBM GCC 5 branch is:

svn+ssh://gcc.gnu.org/svn/gcc/branches/ibm/gcc-5-branch

We basically want all non merge revisions since we created the branch. They include our current set of P9 backports. We'll be committing more soon, so keep an eye out for those. The backported patches also include several revisions adding split stack support which is important for good GO performance and we'd like those picked up as well.

Being pedantic, the following revisions are the backports we'd like you to pick up as of today...like I said, there are more coming:

------------------------------------------------------------------------
r230917 | meissner | 2015-11-25 17:38:03 -0600 (Wed, 25 Nov 2015) | 1 line

Add power9 patch #10 (scalar d-form support)

------------------------------------------------------------------------
r230684 | meissner | 2015-11-20 16:21:10 -0600 (Fri, 20 Nov 2015) | 1 line

Backport gcc power9 patch #8

------------------------------------------------------------------------
r230682 | meissner | 2015-11-20 16:11:29 -0600 (Fri, 20 Nov 2015) | 1 line

Backport gcc power9 patches 7

------------------------------------------------------------------------
r230680 | meissner | 2015-11-20 15:42:07 -0600 (Fri, 20 Nov 2015) | 1 line

Backport gcc power9 patches 2-5

------------------------------------------------------------------------
r230676 | meissner | 2015-11-20 14:48:38 -0600 (Fri, 20 Nov 2015) | 1 line

backport power9 patch #1

------------------------------------------------------------------------
r229493 | boger | 2015-10-28 11:00:46 -0500 (Wed, 28 Oct 2015) | 21 lines

Backport of r229009

PR66870 PowerPC64 Enable gold linker with split stack

A powerpc-linux/powerpc64-linux biarch compiler can default to either
-m32 or -m64, and we need to notice both -m32 and -m64 on the gccgo
command line. It's also possible to build a -m64 only compiler, so in
that case we can define TARGET_CAN_SPLIT_STACK.

gcc/
PR go/66870
* config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Don't define.
* config/rs6000/linux64.h (TARGET_CAN_SPLIT_STACK): Define.
(TARGET_CAN_SPLIT_STACK_64BIT): Define.
gcc/go/
PR go/66870
* gospec.c (saw_opt_m32): Rename to..
(is_m64): ..this, initialised by TARGET_CAN_SPLIT_STACK_64BIT.
Update uses.
(lang_specific_driver): Set is_m64 if OPT_m64, clear if OPT_m32.

------------------------------------------------------------------------
r228623 | boger | 2015-10-08 14:21:45 -0500 (Thu, 08 Oct 2015) | 15 lines

Backport of rev 228311

PR target/66870
* config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Define.
* configure.ac: Define HAVE_GOLD_ALTERNATE_SPLIT_STACK on Power
based on gold linker version.
* gcc.c: Add -fuse-ld=gold to STACK_SPLIT_SPEC if
HAVE_GOLD_ALTERNATE_SPLIT_STACK defined...

------- Comment From <email address hidden> 2016-01-14 09:54 EDT-------
Also, please pick up r232360 by wschmidt which was committed last night after Peter's previous comment.

I see some regressions when building from the ibm branch:

@@ -26,14 +26,15 @@
 FAIL: g++.dg/opt/pr65554.C -std=gnu++14 (test for excess errors)
 XPASS: g++.dg/tls/thread_local-order2.C -std=c++11 execution test
 XPASS: g++.dg/tls/thread_local-order2.C -std=c++14 execution test
+FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O2 output pattern test
+FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -O0 output pattern test
+FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -O3 -g output pattern test
 FAIL: c-c++-common/ubsan/float-cast-overflow-8.c -O2 output pattern test
 FAIL: c-c++-common/ubsan/float-cast-overflow-8.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test
 FAIL: c-c++-common/ubsan/float-cast-overflow-8.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O0 output pattern test
-FAIL: c-c++-common/ubsan/overflow-mul-4.c -O1 output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O2 output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test
-FAIL: c-c++-common/ubsan/overflow-mul-4.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O3 -fomit-frame-pointer output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O3 -fomit-frame-pointer -funroll-loops output pattern test

@@ -143,8 +143,8 @@
 FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI" 1
 FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "p_[0-9]* <" 1
 FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -O0 output pattern test
-FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -O1 output pattern test
-FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test
+FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -O2 output pattern test
+FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -Os output pattern test
 FAIL: c-c++-common/ubsan/float-cast-overflow-8.c -O2 output pattern test
 FAIL: c-c++-common/ubsan/float-cast-overflow-8.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test
 FAIL: c-c++-common/ubsan/float-cast-overflow-8.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test
@@ -153,7 +153,6 @@
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O2 output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test
-FAIL: c-c++-common/ubsan/overflow-mul-4.c -O3 -fomit-frame-pointer output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions output pattern test
 FAIL: c-c++-common/ubsan/overflow-mul-4.c -O3 -fomit-frame-pointer -funroll-loops output pattern t...

------- Comment From <email address hidden> 2016-01-14 11:27 EDT-------
The ubsan overflow tests seem to have some issues with rounding, which make them a little unpredictable as the compiler changes. See PR63361 for an example bug report from a different architecture. It's unlikely that there's anything serious here, at first glance. If the reason for failure is the same kind of "outside the range of representative values" message having the wrong count, I wouldn't worry about it. But I can't tell whether that's the case.

This bug was fixed in the package gcc-5 - 5.3.1-6ubuntu1

---------------
gcc-5 (5.3.1-6ubuntu1) xenial; urgency=medium

  * Add POWER9 support, taken from the ibm/gcc-5-branch. LP: #1522410.

gcc-5 (5.3.1-6) unstable; urgency=medium

  * Update to SVN 20160114 (r232387, 5.3.1) from the gcc-5-branch.
  * Build native gnat on sh4. Closes: #809498.
  * Relax libgcjjit-5-dev dependency on libgccjit0.
  * Apply proposed patch for PR target/69187 (armhf). LP: #1533101.
  * Update libgnatvsn/libgnatprj conflicts.
  * Update the Linaro support to the 5-2016.01 snapshot.
  * GCC Linaro: Revert commits causing regressions PR1980 and PR1982.

 -- Matthias Klose <email address hidden> Thu, 14 Jan 2016 22:01:58 +0100

------- Comment From <email address hidden> 2016-01-19 11:09 EDT-------
The feature is not working. Using

gcc version 5.3.1 20160112 (Ubuntu 5.3.1-5ubuntu3)

I attempted to compile a program with -mcpu=power9. Results:

? src gcc -mcpu=power9 -O3 p9-lxvx-stxvx-1.c
gcc: error: unrecognized argument in option ?-mcpu=power9?
gcc: note: valid arguments to ?-mcpu=? are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e native power3 power4 power5 power5+ power6 power6x power7 power8 powerpc powerpc64 powerpc64le rs64 titan

So at least one important patch is missing. The trunk patch to enable -mcpu=power9 is:

2015-11-09 Michael Meissner <email address hidden>
Peter Bergner <email address hidden>

* config/rs6000/rs6000.opt (-mpower9-fusion): Add new switches for
ISA 3.0 (power9).
(-mpower9-vector): Likewise.
(-mpower9-dform): Likewise.
(-mpower9-minmax): Likewise.
(-mtoc-fusion): Likewise.
(-mmodulo): Likewise.
(-mfloat128-hardware): Likewise.

* config/rs6000/rs6000-cpus.def (ISA_3_0_MASKS_SERVER): Add option
mask for ISA 3.0 (power9).
(POWERPC_MASKS): Add new ISA 3.0 switches.
(power9 cpu): Add power9 cpu.

* config/rs6000/rs6000.h (ASM_CPU_POWER9_SPEC): Add support for power9.
(ASM_CPU_SPEC): Likewise.
(EXTRA_SPECS): Likewise.

* config/rs6000/rs6000-opts.h (enum processor_type): Add
PROCESSOR_POWER9.

* config/rs6000/rs6000.c (power9_cost): Initial cost setup for power9.
(rs6000_debug_reg_global): Add support for power9 fusion.
(rs6000_setup_reg_addr_masks): Cache mode size.
(rs6000_option_override_internal): Until real power9 tuning is
added, use -mtune=power8 for -mcpu=power9.
(rs6000_setup_reg_addr_masks): Do not allow pre-increment,
pre-decrement, or pre-modify on SFmode/DFmode if we allow the use
of Altivec registers.
(rs6000_option_override_internal): Add support for ISA 3.0 switches.
(rs6000_loop_align): Add support for power9 cpu.
(rs6000_file_start): Likewise.
(rs6000_adjust_cost): Likewise.
(rs6000_issue_rate): Likewise.
(insn_must_be_first_in_group): Likewise.
(insn_must_be_last_in_group): Likewise.
(force_new_group): Likewise.
(rs6000_register_move_cost): Likewise.
(rs6000_opt_masks): Likewise.

* config/rs6000/rs6000.md (cpu attribute): Add power9.
* config/rs6000/rs6000-tables.opt: Regenerate.

* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
_ARCH_PWR9 if power9 support is available.

* config/rs6000/aix61.h (ASM_CPU_SPEC): Add power9.
* config/rs6000/aix53.h (ASM_CPU_SPEC): Likewise.

* configure.ac: Determine if the assembler supports the ISA 3.0
instructions.
* config.in (HAVE_AS_POWER9): Likewise.
* configure: Regenerate.

* doc/invoke.texi (RS/6000 and PowerPC Options): Document ISA 3.0
switches.

In branches/ibm/gcc-5-branch, I see that this patch is present:

2015-11-20 Michael Meissner <email address hidden>

Back port from trunk
2015-11-09 Michael Meissner <email address hidden>
Peter Bergner <email address hidden>

* config/rs6000/rs6000.opt (-mpower9-fusion): Add new switches for
etc.

So at least this patch was not picked...

Hello,

As per https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1522410/comments/9 the power9 cpu option is added in the gcc-5 (5.3.1-6ubuntu1) package.

Could you please upgrade to 5.3.1-6ubuntu1 first, and verify that that's the version installed on disk, before validating this feature?

$ dpkg-query -W gcc-5
gcc-5 5.3.1-6ubuntu1

Regards,

Dimitri.

------- Comment From <email address hidden> 2016-01-19 15:41 EDT-------
Thanks, Dmitri! Sorry about that. Now that I am testing the correct packages, everything appears to be looking good. I've verified a variety of the patches are present, including split-stack support, POWER9 binutils, and various code generation examples.

We will continue to backport patches to branches/ibm/gcc-5-branch, so if you are able to pick up any more of them before your toolchain freeze, that would be great. Otherwise what's present is dandy.

One thing I noticed that was a bit odd. After installing gccgo-5, I found that to use the gccgo compiler I had to invoke it as "gccgo-5", rather than just "gccgo". I assume this will cause problems with scripts assuming that gccgo is the correct executable name. Can this please be fixed?

Thanks,
Bill

------- Comment From <email address hidden> 2016-01-19 17:14 EDT-------
Mike Meissner backported two more POWER9 patches for GCC with r232591.

On 19.01.2016 21:49, bugproxy wrote:
> One thing I noticed that was a bit odd. After installing gccgo-5, I
> found that to use the gccgo compiler I had to invoke it as "gccgo-5",
> rather than just "gccgo". I assume this will cause problems with
> scripts assuming that gccgo is the correct executable name. Can this
> please be fixed?

apt-get install gccgo should provide the unversioned binaries.

On 19.01.2016 23:19, bugproxy wrote:
> ------- Comment From <email address hidden> 2016-01-19 17:14 EDT-------
> Mike Meissner backported two more POWER9 patches for GCC with r232591.

I'll pull that for the next upload.

------- Comment From <email address hidden> 2016-01-19 18:26 EDT-------
Ah, I might have only searched for gccgo-5 as a package after finding that I needed gcc-5. Probably user error, then.

------- Comment From <email address hidden> 2016-01-20 18:46 EDT-------
Matthias,

I committed yet another patch backported from mainline we would like for Canonical to pick up. This patch adds support for the __builtin_cpu_is() and __builtin_cpu_supports() builtins which give fast access to our AT_PLATFORM and AT_HWCAP{,2} values.

------------------------------------------------------------------------
r232639 | bergner | 2016-01-20 17:39:41 -0600 (Wed, 20 Jan 2016) | 30 lines

gcc/
Backport from mainline:
2016-01-20 Peter Bergner <email address hidden>

* config/rs6000/ppc-auxv.h: New file.
* config/rs6000/rs6000-builtin.def (cpu_init): Add new builtin.
(cpu_is): Likewise.
(cpu_supports): Likewise.
* config/rs6000/rs6000.c: include "ppc-auxv.h".
(cpu_is_info): New variable.
(cpu_supports_info): Likewise.
(tcb_verification_symbol): Likewise.
(cpu_builtin_p): Likewise.
(cpu_expand_builtin): New function.
(rs6000_expand_ternop_builtin): Add support for CPU builtin functions.
(rs6000_init_builtins): Likewise.
(rs6000_elf_file_end): Emit HWCAP in TCB verification symbol.
* config/rs6000/rs6000.h (TLS_REGNUM): New define.
* configure.ac (gcc_cv_libc_provides_hwcap_in_tcb): New test.
* configure: Regenerate.
* config.in: Likewise.
* doc/extend.texi (PowerPC Built-in Functions): Document
__builtin_cpu_init, __builtin_cpu_is and __builtin_cpu_supports.

gcc/testsuite/
Backport from mainline:
2016-01-20 Peter Bergner <email address hidden>

* gcc.target/powerpc/cpu-builtin-1.c: New test.

I am wondering how to proceed with this missing patch? Should we open a new launchpad bug for this extra fix, or, could we reopen this feature to have a new package released containing this fix?

------- Comment From <email address hidden> 2016-01-21 09:57 EDT-------
(In reply to comment #40)
> I am wondering how to proceed with this missing patch? Should we open a new
> launchpad bug for this extra fix, or, could we reopen this feature to have a
> new package released containing this fix?

Relevant to this question, Mike Meissner is hoping to backport a series of patches to add support for IEEE-128 floating-point in the next few days. After that we should be done adding things, because GCC has entered stage 4 and we won't be able to create any more patches to backport. So please advise about the best way to handle Peter's patch and Mike's upcoming ones. Thanks!

------- Comment From <email address hidden> 2016-01-22 16:24 EDT-------
Mike's patch for IEEE 128-bit floating point support has been added to the branches/ibm/gcc-5-branch as r232747. It's a sizeable patch (about 6K lines).

This is the last patch that we're requesting that Canonical accept for GCC. Thanks!

would it be possible to merge the gcc-5-branch into the ibm/gcc-5-branch again?

------- Comment From <email address hidden> 2016-01-25 11:32 EDT-------
(In reply to comment #46)
> would it be possible to merge the gcc-5-branch into the ibm/gcc-5-branch again?

Done and committed.

I will mention that I saw one new testsuite failure (UNRESOLVED failures for derived_constructor_comps_6.f90) when comparing the IBM 5 branch with the IBM 5 with the merge. Looking into that, that was a new test case in FSF 5 that we just pulled in and it has a syntax error which I'll push to FSF 5 before merging into the IBM 5 branch. So basically, the merge looks good to me.