__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