This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64
On 30/06/17 09:40, Andrew Haley wrote:
> 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.
Which was the point of my proposal yesterday. You need a new type which
the compiler knows has never been placed in a a read-only section.
There's no mechanism for achieving that with the existing type because
legacy objects will always exist. And furthermore, such legacy objects
will use a different locking mechanism on such types.
R.
>
>> 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.
>