问题是我们是否引入了使优化器出错的未定义行为,或者我们可以针对 gcc 提交错误报告吗?
很抱歉没有更好的标题,但它非常脆弱,我们几乎可以肯定这是一个错误。最简单的示例不是我们最喜欢的设计,但它基于崩溃的生产代码:
#include <iostream>
struct Node
{
Node(Node* parent) {
if(parent) {
parent->child_ = this;
}
}
Node* child()
{
return child_;
}
Node* child_ = nullptr;
};
void walk(Node* module, int cleanup) {
if(module != nullptr) {
if(!cleanup) {
std::cerr << "No cleanup";
}
walk(module->child(), cleanup);
if(cleanup) {
delete module;
}
}
}
int main (){
Node* top = new Node(nullptr);
Node* child = new Node(top);
walk(top,1);
}
编译为-O1 -foptimize-sibling-calls -ftree-vrp
。 Godbolt 示例:https://gcc.godbolt.org/z/4VijKb
调用 module->child()
时程序崩溃当模块为0x0
时。检查汇编器我们注意到 if (module != nullptr)
在 walk
的开头被跳过。有一张支票cleanup
并调用work
似乎是无条件的,这导致试图拉 child_
来自无效指针。
如果满足以下条件,则在汇编中重新建立检查(并且代码似乎可以工作):
- 超过
-O1
的两项优化中的任意一项被带走了。 - 正文
if(!cleanup)
已移除。 (cerr
没有副作用) - 正文
if(cleanup)
已移除。 (内存泄漏,但我认为这算作可观察到的行为变化) -
walk
在“无清理”之前调用if
。 (操作顺序) -
cleanup
类型更改为bool
来自int
。 (类型改变 - 但我认为没有可观察到的行为改变)。 - 插入无条件
cerr << "text";
之前和if(!cleanup)
。 (也是一个可观察到的变化。)
这似乎是尾递归和 nullptr
的奇怪组合检查导致错误代码的删除。可能walk
根据 cleanup
分成同级函数检查并缝合错误(?)。
UB 的两名候选人是:
- 提示编译器
module
是非nullptr
,但我没有看到编译器可以推断结果的方法。 - 使用
int
在bool
上下文,但据我所知这是合法的。
FWIW clang
似乎产生了正确的运行时,gcc 8.3
还有用于检查的组件。 9.1
和trunk
不是。我们手头没有任何 gcc 专家,所以我们不知道为什么优化器会被误导。
最佳答案
它看起来确实像一个 GCC 错误。我盯着这段代码看了一会儿,没有发现它有什么问题。
这也可以用 gcc
重现,而不仅仅是 g++
。如果您用 C 编写此代码的最小版本,GCC 开发人员可能会更容易进行调查。此 C 代码使用 -O1 -foptimize-sibling-calls -ftree-vrp 在 GCC 9.1.0 上为我重现了该问题
:
#include <stdio.h>
#include <stdlib.h>
struct Node
{
struct Node* child;
};
void walk(struct Node* module, int cleanup)
{
if (module == NULL) {
return;
}
if (!cleanup) {
puts("No cleanup");
}
walk(module->child, cleanup);
if (cleanup) {
free(module);
}
}
int main()
{
struct Node* node = malloc(sizeof(struct Node));
node->child = NULL;
walk(node, 1);
}
关于c++ - 未定义的行为或 gcc 优化错误,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56655137/