----- Original Message ----- > From: "Ulrich Weigand" <ulrich.weig...@de.ibm.com> > To: "Hal Finkel" <hfin...@anl.gov> > Cc: cfe-commits@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 <hfin...@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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
