On Thu, 7 Nov 2013, Jakub Jelinek wrote: > On Wed, Nov 06, 2013 at 10:07:36PM +0000, Joseph S. Myers wrote: > > The patch I've posted at > > <http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00493.html> is intended to > > be mainline-ready (with the hopes that other people may pick up the ObjC > > and OpenMP issues, and floating-point handling for non-x86 targets, once > > For OpenMP, the current standards (including 4.0) only cover C89/C99, but > not C11, so mixing C11 _Atomic with OpenMP is in the unspecified > category; sorry on any use of _Atomic with -fopenmp is too strict, but I > guess at least until the standard starts supporting C11 we are on our own to > define how the two features should coexist. I'd say it would be safest to > disallow _Atomic in most of the clauses at least for the time being, > allow it in shared clause. Because, what would be behavior of say > privatized _Atomic variable (or firstprivate, lastprivate, copyin, > reduction, ...)? > Also using _Atomic for say OpenMP loop iterators sounds weird (but, that is > essentially the matter of privatization too).
Well, I'm hoping that once the patch is reviewed and in mainline, someone with sufficient OpenMP expertise to make those decisions will deal with removing the sorry () and then disallowing atomics more selectively while using convert_lvalue_to_rvalue in any places where the OpenMP syntax productions parse an expression that may be an lvalue, allow atomics and need to convert it to an rvalue and so carry out an atomic load if it's an atomic lvalue. (And of course doing anything appropriate if there are cases where the OpenMP syntax is used to modify an atomic lvalue and so atomic stores / compound assignments are needed. And as I noted, checking TYPE_MAIN_VARIANT and TYPE_QUALS_NO_ADDR_SPACE uses for correctness in the presence of atomics.) -- Joseph S. Myers jos...@codesourcery.com
