Re: using C11's _Atomic()

On Tue, Jun 02, 2026 at 09:55:42AM +1000, Tony Cook wrote:
> > This would be compiled and run *twice*, once using the C compiler, and
> > once using the C++ compiler (does Configure locate a C++ compiler?)
> 
> Configure doesn't.
> 
> When working on cpphdrcheck.t I found at least one working C compiler
> whose C++ friend didn't build trivial C++11 code, so I'm worried this
> may prevent Configure succeeding if the C++ compiler is broken.
> 
> It might be better to just make the C++ side `#error` if
> ATOMIC_INT_LOCK_FREE and ATOMIC_POINTER_LOCK_FREE don't have
> appropriate values, which seems unlikely.
> 
> Or static assert sizeof(int) == sizeof(PERL_ATOMIC(int)) and similarly
> for pointers.

My main concern at the moment is to avoid breaking perl just to fix a
relatively obscure race condition in threads->kill(). I think I would
prefer the build process to always skip atomics rather than risk producing
a perl which, for example, can no longer compile C++ XS code.

How about the following modified proposal:

1) we add a Configure probe for a C++ compiler (stealing the logic from
cpphdrcheck.t and/or ExtUtils::CppGuess), but manually overrideable via
Configure -Dxyz=g++ say. (Need to think of a suitable xyz - cpp being
already taken). This value could be used to simplify cpphdrcheck.t, and
might be handy for C++ XS writers.

2) We probe for atomics using a C test file. 

3) If successful, and if a C++ compiler was found, we also probe using a
C++ test file. If also successful, we set PERL_USE_ATOMIC

I'm not very clear on what to do on non-Configure systems. I vaguely
understand that Windows uses canned configs. How do they alter their
behaviour based on compiler type and version?