Re: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

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

 



On 30/06/17 10:32, Alexander Monakov wrote:
> On Fri, 30 Jun 2017, Richard Earnshaw (lists) wrote:
>> NO.  AN OPTION WILL NOT WORK.
>>
>> An option cannot fix up existing binary objects and change the ABI that
>> they expect.  You cannot force a recompile on all users so the ABI for
>> this type is NOW FIXED.
>>
>> Mixing objects with potentially different ABIs in play is a recipe for
>> disaster.
> 
> Sorry, but just to make sure there's no misunderstanding, let me just once
> remind you that this is no different from, say, -fno-exceptions: software
> projects can safely enable such options on their own (for the proposed option,
> if the program or library never exposes internally used atomic objects to
> external code).
> 
> Alexander
> 

Sorry, but it's *VERY* different.  The options you mention will lead to
a consisten run-time failure.

Getting the atomicity wrong will lead to random failures at runtime that
are almost impossible to track down due the nature of such race
conditions.  That's simply intolerable.

R.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux