r259931 - [SystemZ] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

[Ulrich Weigand via cfe-commits]

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!


Bye,
Ulrich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160208/d434ea43/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atomic-predefines.c
Type: application/octet-stream
Size: 2691 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160208/d434ea43/attachment-0001.obj>