_Pragma(string) --- broken implementation?

Hi, I need to define a portable _Pragma(“omp …”).
This could have be done by
#define STRINGIFy(n) #n
#define STRINGIFY(n) STRINGIFy(n)
#define PRAGMA_OMP(args) _Pragma(STRINGIFY(omp args))
and it works with many compilers, but not with pgcc 13.6.
pgcc complaints on use of the PRAGMA_OMP(parallel) thus:

PGC-S-0269-_Pragma requires one argument which must be a string (x.c: 10)

If instead of preprocessor stringification I use _Pragma(“omp parallel”) in that place, everything works fine.

When I try to see if PRAGMA_OMP is expanded wrong, pgcc -E just complaints with the above error and eats up the expansion of the macro definition.

When I replace _Pragma with X_Pragma I can see that cpp expansion goes correctly.

I therefore conclude that _Pragma is processed before its argument string is formed by the preprocessor.

Could you advise what to do with this issue?

Hi dima2011,

Per the C99 standard, section 6.10.9, the _Pragma operator only accepts a string literal or via macro expansion with the following form:

define PRAGMA_OMP(args) PRAGMA(omp args)
define PRAGMA(x) _Pragma(#x)

PRAGMA_OMP(foo)

  • Mat

Hi Mat,

Thank you very much for the solution and for the reference to the section in C99 standard. This means, with respect to _Pragma operator the PGI compiler is the most standard conforming compiler of those few I know.

Regards
Dima

Hi Dima,

_Pragma is problematic since it’s poorly defined in the standard, hence, there’s wide variation in it’s implementation. We certainly can try to accommodate you, though it seems to me that your version is more complex than what’s shown in the standard. Do you wish me to add a feature request?

  • Mat

Hi Mat,

I don’t see a need in feature request, since the solution you have given works just fine in all my cases. And I do not see cases where forming a string for _Pragma would be a problem. So, no need in FR.

Thanks
Dima