即使在GCC编译器中，没有显式指定三字符属性，三字符也无法被编译。
#include<stdio.h>
int main()
{
int a=4;
if((a==4) ??! (a==5))
printf("\nHello world!");
return 0;
}
这个程序保存为try.c，只有在我们指定gcc -Wall -trigraphs try.c时才能在GCC编译器中编译，并且仍然显示警告。
你能列举一些编译器，它们可以处理三字符组并且不会产生任何错误或警告吗？
三字符组(trigraphs)是由1989年的ANSI C标准引入的，后来所有的C标准都保留了它们（到目前为止,即将发布的C23标准将放弃它们）。它们也出现在1998年发布的第一个ISO C++标准中，并且在后来的所有C++标准中包括C++14。(感谢Jonathan Leffler和dyp查找细节并指出C++17版本已删除三字符组)。
引用C++17标准草稿：
对原始特性的影响：使用三字符组的有效C++2014代码可能在这个国际标准中无效或者具有不同的语义。如果它们出现在原始字符串字面值之外，实现可以选择按照C++2014中指定的方式翻译三字符组，作为从物理源文件字符到基本源字符集的实现定义映射的一部分。
在任一语言中，它们都不是可选功能（在C++17之前）; 所有符合标准的编译器必须支持它们，并按照相应的语言标准进行解释。
例如，如果这个程序：
#include <stdio.h>
int main(void) {
if ('|' == '??!') {
puts("ok");
}
else {
puts("oops");
}
return 0;
}
如果输出了oops，那么你的编译器就不符合规范。
但是许多C编译器默认情况下并不完全符合标准。只要编译器能够以某种方式符合标准，这对于标准来说就足够了。（gcc需要使用-pedantic和-std=...来实现这一点。）
即使编译器完全符合规范，标准也没有禁止编译器警告任何它喜欢的内容。符合规范的C编译器必须诊断任何语法规则或约束的违反，但它可以发出任意数量的额外警告 - 它不必区分必需的诊断和其他警告。
三字符组很少被使用。绝大多数开发系统直接支持三字符组替换的所有字符：#、[、\、]、^、{、|、}、~。
事实上，三字符组被错误地使用的次数很可能比它们被正确使用的次数还要多：
fprintf(stderr, "What just happened here??!\n");
关于可能改变程序含义的三字符序列（相对于如果该语言没有三字符序列将会具有的含义）的警告，这是符合ISO标准并且在我的观点中也是非常合理的。大多数编译器可能都有选项来关闭此类警告。
相反地，对于一个不实现三字符序列的C++17编译器，警告那些在C++14或更早版本中被视为三字符序列的序列或提供支持三字符序列的选项都是合理的。同样，为禁用此类警告提供选项也是一件好事。
GCC对三字符组很敏感。您必须显式启用它们：
gcc -trigraphs ...
GCC 4.7.1手册表示:
-trigraphs支持ISO C三字符(trigraphs)。选项
-ansi(以及严格的ISO C一致性的-std选项)暗示了-trigraphs。
手册还提到:
-Wtrigraphs如果遇到可能改变程序含义的三字符(trigraphs)，则发出警告(不会警告在注释中的三字符)。此警告由
-Wall启用。
三字符序列在编译的早期阶段就被转换了，甚至可以在字符串字面量中替换。这使得由三字符序列转换引起的错误非常难以检测（如果您考虑使用日志进行调试，并且在源代码中找到输出，则情况最糟）。
您看到的警告将帮助您快速发现可能的罪魁祸首，以跟踪错误的来源。基本上它是在“警告”您某些东西可能不像您想象的那样。
<和{。你和你的代码不太可能遇到这样的系统。 - user149341