jww*_*jww 25 c++ gcc pragma openmp compiler-warnings
我们最近启用-Wall
了一个项目.当GCC处于4.7或更高(或Clang)时启用它,因为我们可以GCC diagnostic
用来管理提升警告的输出.我们希望从源代码管理它们,而不是通过命令行参数.(我们不想污染命令行,或者要求库用户重新发现需要的内容).
下GCC 4.8和5.1,我们正在捕捉的用于GCC诊断块中禁用的警告-Wunused-variable
,-Wunused-value
,-Wunused-function
和-Wunknown-pragmas
.两个GCC都接受-fopenmp
,并且都定义_OPENMP
为响应它,所以我相当肯定它我们永远不应该看到-Wunknown-pragmas
响应#prgam omp ...
(它被禁用,但它不是未知).
g++ -DNDEBUG -g2 -O3 -Wall -march=native -pipe -c nbtheory.cpp
nbtheory.cpp:655:0: warning: ignoring #pragma omp parallel [-Wunknown-pragmas]
#pragma omp parallel
^
nbtheory.cpp:656:0: warning: ignoring #pragma omp sections [-Wunknown-pragmas]
#pragma omp sections
^
...
Run Code Online (Sandbox Code Playgroud)
在这种特殊情况下,文件nbtheroy.cpp
具有以下保护措施以帮助管理该警告(仅显示相关部分,但您可以从GitHub链接中查看所有内容):
// Defines GCC_DIAGNOSTIC_AWARE if GCC 4.7 or above.
#include <misc.h>
...
#if GCC_DIAGNOSTIC_AWARE
# pragma GCC diagnostic ignored "-Wunknown-pragmas"
#endif
...
Integer ModularRoot(const Integer &a, const Integer &dp, const Integer &dq,
const Integer &p, const Integer &q, const Integer &u)
{
Integer p2, q2;
#pragma omp parallel
#pragma omp sections
{
#pragma omp section
p2 = ModularExponentiation((a % p), dp, p);
#pragma omp section
q2 = ModularExponentiation((a % q), dq, q);
}
return CRT(p2, p, q2, q, u);
}
...
Run Code Online (Sandbox Code Playgroud)
因为文件*.cpp
(它实际上是翻译单元),所以我们不会#pragma GCC diagnostic push
在开头和#pragma GCC diagnostic pop
结尾执行a .(但是,对于包含的头文件,我们这样做).(我们也尝试过这样做,但没有帮助).
这是GCC_DIAGNOSTIC_AWARE
(来自misc.h
):
// Used to suppress some warnings in some header and implementation files.
// Some platforms, like CentOS and OpenBSD, use old compilers that don't understand -Wno-unknown-pragma.
#define GCC_DIAGNOSTIC_AWARE ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7)) || defined(__clang__))
Run Code Online (Sandbox Code Playgroud)
我知道守卫正在工作,因为#error
在块中添加a 会导致错误.此外,评论出警卫并呼唤#pragma GCC diagnostic ignored "-Wunknown-pragmas"
并没有帮助.最后,它在Clang下工作正常.
我也遇到它用于其他的警告,如-Wunused-variable
,-Wunused-value
和-Wunused-function
.我真的不想像潜在的重复建议那样污染命令行.
如何使用该GCC pragma diagnostic
机制按预期工作,以便在使用时使GCC下的警告静音-Wall
?
相关的,如果你想重现它(它的GNUmakefile,不需要配置或autotools):
git clone https://github.com/weidai11/cryptopp.git cryptopp-warn
cd cryptopp-warn
make
Run Code Online (Sandbox Code Playgroud)
编辑:我们签入了一个禁用-Wall
除Clang之外的补丁.如果要重现旧行为,则:
git clone https://github.com/weidai11/cryptopp.git cryptopp-warn
cd cryptopp-warn
export CXXFLAGS="-g2 -O3 -DNDEBUG -Wall"
make
Run Code Online (Sandbox Code Playgroud)
pax*_*blo 14
这似乎gcc
至少是一个错误.以下代码:
#pragma GCC diagnostic ignored "-Wunknown-pragmas"
#pragma GCC diagnostic ignored "-Wuninitialized"
int fn(void) {
#pragma xyzzy
int x;
return x;
}
int main (void) {
return fn();
}
Run Code Online (Sandbox Code Playgroud)
没有问题忽略未初始化的x
值,但仍然抱怨pragma(没有uninitialized
pragma,它会产生一个x
你所期望的警告).
如果您将命令行选项更改为-Wall -Wno-unknown-pragmas
,则它会忽略它.对于您的特定情况,这是可以的,因为您希望它应用于整个翻译单元,但它不允许从#pragma
方法中获得的细粒度控制(如果它有效).
我去提出关于GCC的错误报告,但发现它已经存在(#53431).
虽然该特定错误与其相关-Wundef
,但其中一条注释中的代码段表明它可能适用于影响预处理器的所有变体(稍加修改以强调):
C++解析器在处理编译指示之前使用lexes(和 preprocesses),而C解析器在处理pragma时处理它们.
我们必须以某种方式解析这些编译也是在
cp/parser.c:631
.也许一个人可以做类似于我们的工作cp_parser_initial_pragma
,但在循环内只处理pragma诊断.当然,需要一些试验和错误才能做到正确.如果你们中的任何一个想尝试并需要一些帮助,请在这里或邮件列表中询问.
这就解释了为什么我们没有看到相同的问题-Wuninitialized
,因为它是在编译过程的后期阶段,在预处理结束时激活编译指示之后检测到的.
所以,如果你想以更及时的方式看待它(它是在三年前提出来的),我建议(就像我一样)讨论GCC bugzilla网站试图获得一些曝光.