r259931 - [SystemZ] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

[Hal Finkel via cfe-commits]

----- Original Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: cfe-commits at lists.llvm.org
> Sent: Monday, February 8, 2016 7:53:29 AM
> Subject: Re: r259931 - [SystemZ] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros
> 
> Hal Finkel <hfinkel at anl.gov> wrote on 05.02.2016 23:14:54:
> 
> > Just a general comment: I believe we've now fixed this bug for at
> > least four different architectures (each time as a separate
> > effort).
> 
> Yes. Unfortunately I only noticed that after I'd already spent half
> a day debugging the problem from scratch on System Z :-/
> 
> > Is there some kind of auditing we could do to make sure we don't
> > run
> > into this again?
> 
> Well, on GCC common code automatically predefines the macro if and
> only if the back end actually implements the corresponding builtin
> without an external function call. We cannot really do that in LLVM
> due to the stronger separation between front end and back end here.
> 
> However, I guess we could at least provide a *test case* that
> verifies
> that front end and back end make the same choice. This would have to
> be a test case that runs a full compile (from un-preprocessed source
> straight through to assembler output) so we can verify the
> interaction
> of front end and back end, which I guess is frowned upon these days
> ...
> 
> The following example implements one idea I came up with:
> (See attached file: atomic-predefines.c)
> 
> It is neither perfectly complete (it only checks the current target,
> not all; and it doesn't check any variants of the current target,
> e.g. different CPU types), nor is it perfectly safe (some targets
> could theoretically emit weird code to implement a function call
> that would throw off the heuristics in this test).
> 
> In addition, I noticed when running it against some of the more
> obscure targets like Hexagon, the test actually triggers internal
> errors in the back end, so those probably ought to be fixed first.
> 
> Any suggestions to improve this test welcome!

We generally notice this when we try to use some part of the C++ standard library (std::atomic or std::thread as I recall). Could we have something in the test-suite that uses that functionality in a way likely to expose this bug?

 -Hal

> 
> 
> Bye,
> Ulrich
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory