This patch enables trigraphs on z/OS.
If going with an integrated update to the existing sentences, both of the original sentences would require an update (not just the first one). The first sentence is also meant to describe GCC's behavior, for which I am not sure there's a statement to be made for GCC on z/OS. I suggest to add an additional sentence instead.
I would like to point out that processing trigraphs when most platforms don't would be a portability concern. Clang appears to mitigate this somewhat with warnings.
Do we know if -fno-trigraphs is meaningfully functional on z/OS? I believe trigraph usage might need to be replaced to use digraphs in the system headers before using -fno-trigraphs can be expected to work in a real user application.
Can you modify clang/test/Frontend/trigraphs.cpp and clang/test/Lexer/cxx1z-trigraphs.cpp ? These tests are assuming trigraphs are disabled by -std=gnu++11 -fms-compatibility -std=c++1z, and it won't be the case here because on z/OS trigraphs are still enabled when these options are present.
Unfortunately we can't move away from this because the system headers currently use trigraphs. But we will definitely look into whether we can update these headers to not be dependent on trigraphs and improve portability.
With the current system headers, compiling with -fno-trigraphs would not work in a user application. As mentioned above, we will look into whether we can remove this dependency.
This strategy duplicates the trigraphs-enabled behaviour checks three times.
Plain -verify can be used along with a macro instead (without such duplication). This also allows the explicit -fno-trigraphs case to be added with little cost.
// RUN: ... // RUN: ... -ftrigraphs -DENABLED_TRIGRAPHS=1 // RUN: ... -fno-trigraphs -DENABLED_TRIGRAPHS=0 #ifdef __MVS__ #ifndef ENABLED_TRIGRAPHS #define ENABLED_TRIGRAPHS 1 #endif #endif #if !ENABLED_TRIGRAPHS // ... #else // ... #endif