Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

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

 



On Mon, Apr 26, 2021 at 09:51:50AM -0600, Jeff Law wrote:
> 
> On 4/24/2021 8:26 AM, Michael Catanzaro wrote:
> > On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek
> > <jakub@xxxxxxxxxx> wrote:
> > > I'll be probably repeating myself, but the two compilers are known to be
> > > ABI incompatible in very important ways, none of the
> > > https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207
> > > 
> > > bugs have been touched since last time this was discussed and I'm
> > > not aware
> > > of any ABI compatibility testing between the two compilers.
> > > So if some library packages switch compilers and programs using those
> > > libraries don't or vice versa, this proposal has quite high risks of
> > > introducing hard to debug debugs.
> > 
> > Perhaps this proposal should be revisited in the future when there are
> > fewer scary ABI bugs.
> 
> That's not really a scary ABI bug.   There's disagreement about a fairly
> unusual case involving extension of 8 bit arguments and some issues with 128

There is disagreement on passing all 8-bit and 16-bit arguments by value on
x86_64, which in many cases works just by pure luck because GCC often
emits the extension even on the caller side where it is not mandated by the psABI,
while LLVM relies on an extension the psABI doesn't guarantee.
Several packages already ran into this in the past, I don't think we can
ignore that one.

The va_arg passing bug for __int128 is less important, sure, most packages
don't use 128-bit integers and if they do, they rarely pass it through
va_arg.  But having 8-bit and 16-bit arguments on ABI boundaries is very
common.

That is one thing and the other one is that the interoperability testing
between the two compilers wasn't really performed, so besides those known
bugs there can be unknown ones.

	Jakub
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[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