Re: devel Digest, Vol 190, Issue 186
On Thu, 2019-12-19 at 21:56 +0000, devel-
request(a)lists.fedoraproject.org wrote:
Neal,
> I'm generally happy with this idea. I'm one of
the maintainers of
> rpm-config-SUSE (the equivalent of redhat-rpm-config for SUSE
> distributions) and I somewhat saw the development of this feature
> across rpm, rpm-config-SUSE, and the implementation in openSUSE
> Tumbleweed.
Understood. FWIW, I work closely with Martin L, Martin J, Jan and
Richi @ SuSE. Martin L and I in particular coordinate on mass build
testing & related failure analysis and bugfixing.
> However, the implementation of LTO in openSUSE caused
major problems
> for "weaker" architectures like ARM and RISC-V. In Fedora, ARM is
> co-primary with the rest of the architectures (ARM is allowed to be
> broken in openSUSE from time to time). The major problems we
> encountered was increased miscompilation errors and timeouts due to
> builds taking even longer with LTO straining ARM build environments.
Yes. The 32bit architectures in particular are expected to be slightly
problematical due to the limited address space. Even with Jan's work
in this area, I expect things like firefox to simply be too big to
compile/link using LTO on the 32bit platforms.
When I discussed this with Martin L and one of the Ubuntu engineers
(Matthias) back in Sept, the general plan we agreed on was to first get
the Fedora test builds in reasonable shape on x86_64 that we could use
as a baseline (and we're just about there). Then do an i686 build for
comparison purposes.
For packages we find problematical on the 32bit platforms, we'll be
able to trivially opt-out of LTO for that package on those 32bit
platforms. It's a one-liner in the .spec file.
> And with RISC-V, is LTO even implemented well in GCC? In
OpenMandriva
> (where I help maintain rpm-openmandriva-setup, its equivalent of
> redhat-rpm-config), we're still using GCC for RISC-V since Clang is
> still horribly broken there, and we had to disable LTO to get a usable
> port going. Fedora RISC-V is going to be in for a world of pain if
> we're enabling it without any consideration for them.
GCC's implementation of LTO is target independent.
RISC-V really isn't on my radar at this point. Though if we have
issues specific to the code generator on RISC-V, I'm sure Jim Wilson
(SiFive) and I can work it out. We've been working together on GCC for
nearly 30 years at this point. I would _not_ expect RISC-V's code
generator to be as solid as other platforms simply because it hasn't
been used much yet.
> So what's the state of things for non-x86? Generally
speaking, my
> experience indicates everything is broken...
My tester is x86_64 based. There's no inherent reason it couldn't work
on another platform other than needing lots of machines to turn around
builds quickly enough to matter. My hope has always been to spin up
i686 and ppc64le as I can get access to reasonable hardware for those
targets.
I've spoken with ARM's & IBM's GCC engineers about this upcoming
change, they're aware and supportive of the plan. We typically lean
heavily on them to take care of any GCC issues that are specific to
their targets.
jeff