https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103165
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584035.html * * * Note the remark in https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584042.html regarding preserving spacing with the stringified _Pragma. This is not handled by the patch, nor are strings with prefixes like L"...". Currently, _cpp_do__Pragma calls get__Pragma_string – and the latter strips off all padding, but still keeps the prefix info via CPP_{,W,UTF8}STRING{,16,32}. Of course after evaluating that string via destringize_and_run -> do_pragma, the string and, hence, its type is gone. The question is – for this issue and also for PR90400 – whether the string should be kept for longer as string and only later destringize_and_run (or used as is); at least when the pragma space/name is not registered, this seems to make sense - such that it is properly handled with '-E' (→ PR90400). Now that CPP_PRAGMA supports 'flags & PRAGMA_OP', it can be distinguished from CPP_PRAGMA in macro.c and it could be workable? — Note: Requires to check whether there are any issues with delaying it – or whether that's actually the proper way of doing it.
