This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64


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.

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.

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.

Alexander


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]