__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

Andrew Haley aph@redhat.com
Fri Jun 30 08:40:00 GMT 2017


On 29/06/17 20:46, Alexander Monakov wrote:
> On Thu, 29 Jun 2017, Andrew Haley wrote:
>> On 29/06/17 18:35, Alexander Monakov wrote:
>>> I think a practical approach is to give the user a degree of control by
>>> introducing a tri-state compiler option controlling how double-word atomics
>>> are to be emitted:
>>
>> I see what you mean, but I think it's a very bad idea for command line
>> options to fundamentally affect language semantics in this way.  Sure,
>> they can control optimization and processor versions, but change the
>> behaviour of what a program means?  Is that a good thing?
> 
> I'm not sure what you mean here. The first option preserves the lousy status
> quo, the third option does not introduce traps, so as far as I can tell only
> the second option does something that counts as "affecting language semantics",
> by *potentially* introducing traps.

Indeed it does.

> But if the program by construction never executes an atomic load on a readonly
> object in the first place, implementing the load via CAS is not observable on
> the language level.

Well, yes, but you can execute an atomic load on a read-only section, so
it is observable; and thus the command-line options have an
effect on semantics.

> So consider that the second option helps to communicate to the compiler this
> non-trivial guarantee, which the optimizer cannot easily deduce on its own.
> And there's plenty of such options with similar motivation: -fwhole-program,
> -fno-math-errno, -fno-exceptions, etc. They all tell the compiler something
> it cannot know, improve code generation, lead to breakage if misused.

Perhaps so.  However, it would make more sense and be more maintainable
if, rather than use a command-line option, a variable attribute was used
to tell the compiler what this program is supposed to mean.  IMO.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the Gcc-help mailing list