Блог пользователя riadwaw

Автор riadwaw, 14 лет назад, По-русски
Писал задачу 38C из архива:

одинаковые посылки:

Под MS C++ зашло(попытка 457910)
Под g++ TL1 (попытки 457900,457912)

В чем может быть проблема?
  • Проголосовать: нравится
  • +7
  • Проголосовать: не нравится

14 лет назад, # |
  Проголосовать: нравится -37 Проголосовать: не нравится
Забей. Не знаю как КФ, а один из саратовских контестеров постоянно чудачит по этому поводу. Я лично уже привык: ТЛ на одном из компиляторов вовсе не означает ТЛ на другом. Иногда доходит до абсурда-на гнушнике может работать секунд по 5, на вижаке залетает за полторы, и наоборот
  • 14 лет назад, # ^ |
      Проголосовать: нравится +16 Проголосовать: не нравится
    Сереж, сначала посомтри о чем речь, потом отвечай. Там TL на 1 тесте.
  • 14 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится
    Ну если бы просто ТЛ был я бы не удивился, но тут пара сотен операций, на VS 30ms работает на всех теcтах, тут на первом > 2с.
14 лет назад, # |
Rev. 3   Проголосовать: нравится +6 Проголосовать: не нравится

Научился лечить, хотя и не понял что происходит. Надо закомментировать #define int li

UPD: Проявляется, когда l типа long long. С чем связанно не знаю.
14 лет назад, # |
Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

не туда
14 лет назад, # |
  Проголосовать: нравится +13 Проголосовать: не нравится
Бажная оптимизация цикла. Если вставить дебаг-оутпут, то проходит:

   for(int i=l;i<=100;++i){
        cerr << i;
        int ans=0;
        for(int j=0;j<n;++j){
            ans+=a[j]/i;
        }
        best=max(best,ans * i);
    }
  • 14 лет назад, # ^ |
      Проголосовать: нравится +12 Проголосовать: не нравится
    Чую codeforces может превратиться в микроцентр по отлавливанию небольших багов оптимизатора gcc.
14 лет назад, # |
  Проголосовать: нравится +5 Проголосовать: не нравится
Эта программа выдает число из входного, если оно больше десяти, и зависает (или делает 2^63 итераций) на кодефорсес, когда число меньше или равно.

#include <iostream>


// для mingw 4.6 32-bit

int main() {

    float ans; // подойдет любой тип, кроме [unsigned] int, short, char

    

    std::cin >> ans; // делаем так, чтобы компилятор не мог вычислить значение ans

    

    for (long long i = ans; i <= 10; i++) { // только long long [int]. unsigned работает нормально

        ans = ans; // в теле цикла нужно сделать присвоение в переменную ans

        // хотя в приведенном примере внутри цикла ничего не происходит,

        // оптимизатор не удаляет тело цикла

    }

    

    std::cout << ans; // ввод-вывод нужен чтобы оптимизатор не подумал будто программа вообще ничего не делает

    return 0;

}


Я так и не смог повторить этот баг на своем g++, поэтому не могу сказать, почему так происходит. Если у кого-то получится, поделитесь, пожалуйста, ассемблерным кодом. Ну или скажите кто-нибудь, что это известный баг.
  • 14 лет назад, # ^ |
      Проголосовать: нравится +6 Проголосовать: не нравится
    Оптимизатор генерирует бесконечный цикл (без -О2 код работает):
    L5:
    .p2align 4,,4
    jmp L5

14 лет назад, # |
Rev. 2   Проголосовать: нравится +12 Проголосовать: не нравится

дорожка уже проторена:

http://gcc.gnu.org/bugzilla/

:)

  • 14 лет назад, # ^ |
      Проголосовать: нравится +22 Проголосовать: не нравится

    Кстати, у меня ещё после прошлого бага созрела идея - написать стресс-тестирование для компиляторов. Генерить как-нибудь корректные программы с арифметическими операциями, примитивным использованием массивов и векторов, и рекурсией - и гонять на разных компиляторах, сравнивая ответы и время работы.

    Можно будет после финала попробовать сделать - хотя генерить случайные программы - видимо, совсем непросто.

13 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

Что же, раз никто так и не заслал в багтрекер, снова я "присвою" себе баг :)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49218

Пока статус только лишь "подтверждено".