Question

问题是我们是否引入了使优化程序跳闸的未定义行为，还是可以针对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，但这是合法的AFAIK。

FWIW clang似乎产生正确的运行时，gcc 8.3也具有用于检查的程序集。 9.1和trunk不是。我们手头没有gcc专家，所以我们不知道为什么会误导优化器。

Answer 1

它看起来确实像是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);
}

未定义的行为或gcc优化错误

1 个答案: