Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

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

 



On 6/5/20 12:31 PM, Jeff Law wrote:
On Fri, 2020-06-05 at 16:23 +0000, devel-request@xxxxxxxxxxxxxxxxxxxxxxx wrote:
Date: Fri, 5 Jun 2020 11:15:39 -0500
From: Steven Munroe <munroesj52@xxxxxxxxx>
Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
	Change
To: devel@xxxxxxxxxxxxxxxxxxxxxxx
Message-ID:
	<CAPrKuAohVppTu_B4GDoxSMW=KzXTq_m13utpOZocCOK0xOzzcw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"

I would also add that Clang/LLVM is missing some of the newer C
language revisions at least for the pppc64le target.

Both IEEE/ISO  _Float128 and _Decimalxx support is missing. Ie the
type is not supported or if supported basic arithmetic and math.h
support is missing. Also finding bugs for in-line assembly and missing
constraints needed to work around the missing language features.

Also Clang's poor support for constant folding makes using __int128
(and vector __int128) harder than it needs to be.

This is a significant impact for enabling my project (PVECLIB) for
Clang. As-is a number of project features have been disabled for
Clang.
Clearly your upstream project is still using GCC then and as such the Fedora
package would continue to use GCC.

We're not changing the default here.  We're just removing the anti Clang/LLVM
policy and allowing upstreams to select the compiler that best suits their needs.
Clearly Clang/LLVM is not the right choice for your project.

This looks fine, but why not add to the policy that for upstream projects that have no defined preference of compiler, the package have to use GCC in order to have at least some standard and not let the packager bias be the rule, unless some measurable advantage is found to use LLVM




I think Clang needs more time to cook.
I'd respectfully disagree.  There are certain features that GCC supports that
Clang does not and vice-versa.  But broadly they are comparable.  What this means
is some projects that are using bleeding edge features may have a hard need for
one toolchain or the other.  And the proposal I've made accounts for that by
allowing the upstream project to select the compiler.  In your case it would be
GCC.  For others it could well be Clang/LLVM.

jeff



_______________________________________________
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

_______________________________________________
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