Bug 854253 - Incorporate ppc64p7 arch and %{power64} macro into gcc spec
Incorporate ppc64p7 arch and %{power64} macro into gcc spec
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
18
ppc64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: f18-ppc64p7
  Show dependency treegraph
 
Reported: 2012-09-04 09:42 EDT by Brent Baude
Modified: 2014-02-05 07:08 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 07:08:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch gcc spec for ppc64p7 (15.41 KB, patch)
2012-09-04 09:42 EDT, Brent Baude
no flags Details | Diff

  None (edit)
Description Brent Baude 2012-09-04 09:42:04 EDT
Created attachment 609692 [details]
patch gcc spec for ppc64p7

RPM (as of 4.9.1.3-6.fc17) now honors a %{power64} macro that leads to additional subarchitectures  (ppc64p7 -- optimized arch for POWER7) coming in F18.  The gcc spec has to be altered slightly to take advantage of this.  Namely, many (but not all) of the ifarch ppc64s use the %{power64} macro. 

I also included two additional changes.

1) In order to get the gcc_target_platform set properly for ppc64p7, I added ppc64p7 to the condition to manually set it to gcc_target_platform ppc64-%{_vendor}-%{_target_os}
2) For ppc64p7, I conditionally add --with-cpu=power7 to configure.

A patch to the spec will also be provided.

As a side note, it might be warranted to conditionally clean up some of the stuff like this:

        --with-cpu-32=power4 --with-tune-32=power6 --with-cpu-64=power4 --with-tune-64=power6 \

I'm happy to participate in that if you'd like.
Comment 1 Jakub Jelinek 2012-09-05 11:45:52 EDT
The patch is wrong.  If something, ppc64p7 should be just used for selected subpackages of gcc and gcc* should still be *.ppc64.rpm, in any case needs to default to the lowest supported CPU by the distro.  So, if your goal is power7 optimize libgcc, libstdc++ (or what else?), then it just needs hacking up so that just those subpackages are built.
Comment 2 Karsten Hopp 2012-09-05 12:14:58 EDT
Jakub: We'll ship ppc64p7 packages in addition to the ppc64 packages that will run on all supported CPUs. ppc64p7 packages will be installed on Power7 (or newer) processors only.
Did I understand you correctly that you'd prefer a ppc64 main package with ppc64p7 subpackages in addition to the 'normal' ppc64 subpackages ? That'll be a lot more effort and complicate the spec file quite a lot. Letting koji just build another arch and then rely on yum to install the correct (ppc64p7 or ppc64) package will be a much cleaner solution.

Please read https://fedoraproject.org/wiki/Features/Power7Subarch for more information
Comment 3 Jakub Jelinek 2012-09-05 12:26:16 EDT
So you want to build everything as ppc, ppc64 and ppc64p7, then pick a subset of the binary ppc64p7 packages and include it in the composes alongside with ppc64 (and ppc) rpms?  That is not exactly what used to be done for i386 vs. i586 vs. i686 back when i686 wasn't the base level - only selected performance critical packages were built as i586 or i686 back then.  I must say I'd strongly prefer not to build gcc-* subpackages (but perhaps some lib* subpackages of gcc) as ppc64p7 at all, having a compiler that would default to power7 as oldest supported ISA, even if it was just installable from koji, could result in lots of troubles.  At the spec file level it could be just define some macro which would say set of arches for which only lib* subpackages would be built, then just %ifnarch %{auxarches} around the files sections of the non- -n subpackages (plus perhaps some rm to shrink debuginfo for the auxiliary arches).
A few years ago e.g. glibc spec file created just selected subpackages of glibc as i686 and the rest only for the base arch.
Comment 4 Fedora End Of Life 2013-12-21 03:50:03 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 5 Fedora End Of Life 2014-02-05 07:08:36 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.