问题是我们是否引入了未定义的行为来触发优化器,或者我们可以针对 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
编译。神螺栓示例:https://gcc.godbolt.org/z/4VijKb
当模块0x0
时调用module->child()
程序崩溃。检查汇编程序时,我们注意到if (module != nullptr)
在walk
开始时被跳过了。有一个检查cleanup
,对work
的调用似乎是无条件的,这会导致尝试从无效指针中提取child_
。
在以下情况下,将在汇编中重新建立检查(并且代码似乎有效):
-O1
上的两个优化中的任何一个都会被取消。if(!cleanup)
体被移除。(cerr
无副作用)if(cleanup)
体被移除。(内存泄漏,但我认为它算作可观察到的行为变化)walk
在"不清理"if
之前调用。(操作顺序)cleanup
类型从int
更改为bool
。(类型更改 - 但我认为没有可观察到的行为更改)。- 插入之前和
if(!cleanup)
的无条件cerr << "text";
。(也是一个可观察到的变化。
这似乎是尾递归和nullptr
检查删除的奇怪组合,导致错误的代码。可能walk
根据cleanup
检查被拆分为同级函数并被错误地缝合(?
UB的两个候选人是:
- 暗示编译器
module
是非nullptr
的,但我看不到编译器可以推断结果的方法。 - 在
bool
上下文中使用int
,但它是合法的 AFAIK。
FWIWclang
似乎产生了正确的运行时,gcc 8.3
也存在用于检查的程序集。9.1
,trunk
不是。我们手头没有任何 gcc 专家,所以我们不知道为什么优化器会被误导。
它看起来确实像一个GCC错误。我已经盯着这段代码一段时间了,我找不到任何问题。
这也可以用gcc
重现,而不仅仅是g++
。如果您用 C 语言编写此内容的最小版本,GCC 开发人员可能会更容易进行调查。此 C 代码在 GCC 9.1.0 上为我重现了该问题,-O1 -foptimize-sibling-calls -ftree-vrp
:
#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);
}