Re: devel Digest, Vol 190, Issue 186

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 19, 2019 at 4:14 PM Jeff Law <law@xxxxxxxxxx> wrote:
>
> On Thu, 2019-12-19 at 21:56 +0000, devel-
> request@xxxxxxxxxxxxxxxxxxxxxxx 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.
>

Martin Liška is the one I've primarily interfaced with throughout the
implementation.

I don't know if you know about this, but there's a tracker bug for
LTO-related failures: https://bugzilla.opensuse.org/1133084

We should probably make sure this is cross-referenced as LTO is
implemented in Fedora.

> >
> > 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.
>
>

Are we going to use the same %_lto_cflags mechanism that was
implemented in openSUSE, or are we going to do something different?

> >
> > 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.
>

I'd like to see at *least* AArch64 spun to see how well this goes. I'm
reasonably confident that POWER8+ would be fine, since we don't have
ppc64be anymore (and I *know* that one was broken, since I reported it
years ago: https://bugzilla.redhat.com/1515934).


-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux