Мотоцикл не заводится

[vak]

Ситуация как в старом анекдоте. Собранный компилятором Clang, парсер отлично работает, что с оптимизацией, что с отладкой. Собранный GCC в режиме отладки тоже работает. Но если GCC с оптимизацией - большинство тестов падает. Пробовал на Линуксе и на маке - одинаково. Не могу понять почему.

Comments

[archaicos]

Все -Wall -Wextra -pedantic добавил? Ещё можно отдельные функции пробовать запрещать оптимизировать через pragma (если чего нового не добавили). Отдельно ради прикола собрать на более старой системе со старым gcc.

[vak]

Вскрытие показало, что виновником была процедура занесения объекта в конец односвязного списка. Списки я сделал просто: если структура может находиться в списке, то её первый элемент должен называться "next" и хранить указатель на следующий элемент в списке. Типа такого:

struct Foo {
    struct Foo *next; 
    ...всё остальное...
};

Есть процедура, заносящая элемент в список:

struct Foo *list = NULL;
append_list(&list, new_foo());

Если процедуру определить примитивно в лоб, то всё работает:

void append_list(void *head, void *node)
{   
    if (!node)
        return;
    *(void**)node = NULL;
    
    // Find tail.
    void **tail = (void**) head;
    while (*tail) {
        tail = (void**) *tail;
    }
    *tail = node;
}

Но я решил было навести красоту и переделал через структуры для большей понятности:

void append_list(void *head_ptr, void *node_ptr)
{
    typedef struct List List;
    struct List {
        List *next; /* linked list */
    };

    if (!node_ptr)
        return;

    List **head = (List **) head_ptr;
    List *node = (List *) node_ptr;
    if (*head == NULL) {
        *head = node;
    } else {
        // Find tail.
        List *current = *head;
        while (current->next) {
            current = current->next;
        }
        current->next = node;
    }
    node->next = NULL;
}

Как оказалось, зря. GCC в режиме оптимизации решает, что структуру List снаружи не видно, и поэтому все эти действия нафиг не нужны. Просто всё выкидывает. 😀 Я пытался вставлять volatile в разные места - по барабану.

[ichthuss]

А если вьінести структуру List из функции? Понятно, что мусор в глобальном неймспейсе, но камон, єто ж си, там такого все равно навалом.

[vak]

Пробовал, не помогло.

[ichthuss]

Даже если структура присутствует в хедере? Оно на єтапе линковки его вьікидьівает, что ли?

[vak]

Дальше я не стал исследовать. Вряд ли на этапе линковки.

[spamsink]

Что у тебя за GCC? Есть же godbolt.org, на котором можно экспериментировать с разными версиями, разными опциями и пр. мгновенно.

https://godbolt.org/z/ve7sj3MoG

[vak]

На маке gcc 14.2, на Линуксе gcc 13.3. Godbolt штука полезная конечно, но мне проще unit тесты прогнать.

[spamsink]

А проверять, на какой версии ошибка появилась, и на какой она была исправлена, или проявляется ли ошибка в стандартной поставке, как ты с помощью юнит-тестов будешь?

Ты по ссылке прошел? Увидел, какой ассемблер порождается из твоей функции? Если у тебя другой, то дело не в GCC как таковом.

[vak]

Да у меня другая цель: чтобы парсер работал. В какой версии GCC ошибка и в чём она состоит - дело десятое.

[ichthuss]

Тут дело немного другое: приведение void* к List* допустимо только в том случае, если ранее этому void* присваивался указатель на List или 0. Иначе - undefined behavior. А это означает, что если компилятор может доказать, что ни при каких условиях фактическим параметром не мог оказаться указатель на List, то !node_ptr не может быть false, а, значит, оставшийся код можно выбросить.

[spamsink]

Так что же мешает компилятору в примере по ссылке на godbolt доказать, что указателем на тип, определённый внутри функции, фактический параметр не может быть в принципе, и соптимизировать эту функцию?

[ichthuss]

Ничего не мешает, но ничто и не обязывает.

[spamsink]

Загадка в том и заключается, чтобы найти разницу между случаем, когда компилятор захотел оптимизировать, и случаем, когда он не захотел.

[ichthuss]

Чисто из спортивного интереса - да, загадка интересная. Но вообще баловаться с undefined behavior - развлечение на любителя.