https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943
--- Comment #4 from Jeffrey Walton <noloader at gmail dot com> --- (In reply to Andrew Pinski from comment #3) > The warning is correct though, maybe it should add a message about needing > -fopenmp to have them to be known. >From a dumb user's point of view (folks like me): that behavior squashes a lot of the benefit of cross-platform sources and using parallel tasks. I think the OpenMP folks feel about the same. From http://openmp.org/wp/openmp-specifications/ and http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf: Each directive starts with #pragma omp. The remainder of the directive follows the conventions of the C and C++ standards for compiler directives. In particular, white space can be used before and after the #, and sometimes white space must be used to separate the words in a directive. Preprocessing tokens following the #pragma omp are subject to macro replacement. There's no expectation that a conforming compiler will issue a warning for #pragma omp when -fopenmp is not in effect. In fact, I can't find authority to issue a warning from a conforming compiler. I think it would be much better to always accept `#pragma omp` *if* the compiler supports OpenMP, regardless of the status of `-fopenmp`. Conversely, if the compiler does not support OpenMP, then always issue an unknown pragma warning (modulo expected behavior of the diagnostic). Speaking from experience, OpenBSD and Cygwin get into an odd area where they advertise support for OpenMP by accepting -fopenmp and defining _OPENMP, but then fail to compile the program. But I think that's a different issue. (For what its worth, I understand the compiler writers are always right. They are demi-gods in my little corner of the universe :)
