[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

["noloader at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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 :)