我们最近为项目启用了-Wall
。当GCC处于4.7或更高(或Clang)时启用它,因为我们可以使用GCC diagnostic
来管理提升警告的输出。我们希望从源代码管理它们,并通过命令行参数 不 。 (我们不想污染命令行,或者要求库用户重新发现需要的内容。)
根据GCC 4.8和5.1,我们捕获的警告已在-Wunused-variable
,-Wunused-value
,-Wunused-function
和-Wunknown-pragmas
的GCC诊断模块中停用。两个海湾合作委员会接受-fopenmp
,并且都定义_OPENMP
以回应它,所以我很确定我们永远不会看到-Wunknown-pragmas
来回应#prgam omp ...
(它< em> 已禁用,但未未知。)
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
^
...
在这种特殊情况下,file nbtheroy.cpp
有以下警卫来帮助管理该警告(仅显示相关部分,但您可以查看the GitHub link中的所有内容):
// 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);
}
...
由于该文件为*.cpp
(实际上是 翻译单元),我们 不 执行{{1}在开始时和#pragma GCC diagnostic push
在结尾处。 (但是,对于包含的头文件,我们这样做)。 (我们也试过这样做,但没有用)。
这里是#pragma GCC diagnostic pop
(来自misc.h
):
GCC_DIAGNOSTIC_AWARE
我知道守卫正在工作,因为在块中添加// 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__))
会导致错误。此外,评论出警卫并呼唤#error
也无济于事。最后,它在Clang下工作正常。
我也遇到其他警告,例如#pragma GCC diagnostic ignored "-Wunknown-pragmas"
,-Wunused-variable
和-Wunused-value
。我 真的 不希望污染命令行,如同潜在的重复建议一样。
使用-Wunused-function
时,如何使GCC pragma diagnostic
机制按预期工作以在GCC下保持警告?
相关,如果要重现它(基于GNUmakefile,不需要配置或自动工具):
-Wall
编辑:我们签入了一个禁用git clone https://github.com/weidai11/cryptopp.git cryptopp-warn
cd cryptopp-warn
make
的补丁,但Clang除外。如果您想重现旧的行为,那么:
-Wall
答案 0 :(得分: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();
}
没有问题忽略未初始化的x
值,但仍然抱怨编译指示(没有uninitialized
编译指示,它会按照您的预期生成x
的警告。
如果将命令行选项更改为-Wall -Wno-unknown-pragmas
,则它会忽略它。对于您的特定情况,这是可以的,因为您希望它应用于整个翻译单元,但它不允许您从#pragma
方法获得的细粒度控制(如果它有效)。
我去了GCC的bug报告,但发现它已经存在(#53431)。
虽然该特定错误与-Wundef
有关,但其中一条评论中的片段表明它可能适用于影响预处理器的所有变体(稍加修改以强调):
在处理pragma之前,C ++解析器lexes(和 preprocesses),而C解析器在看到它们时处理pragma。
我们必须以某种方式在
cp/parser.c:631
中解析这些编译指示 。也许可以做一些类似于我们对cp_parser_initial_pragma
所做的事情,但是在循环内只处理pragma诊断。当然,需要一些试验和错误才能做到正确。如果你们中的任何一个想尝试并需要一些帮助,可以在这里或在邮件列表中询问。
这解释了为什么我们没有看到-Wuninitialized
的相同问题,因为它是在编译过程的后期阶段,在预处理结束时激活编译指示之后检测到的。
所以,如果你想以更及时的方式看待它(它是在三年前提出来的),我建议(正如我所知)讨论GCC bugzilla网站试图获得一些曝光。