1. Assembler / Говнокод #20423

    −715

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    return instruction emitted twice with branch target inbetween
    
    function
    
    unsigned int fact( unsigned int n) { return n < 1 ? 1 : n*fact(n-1); }
    
    produces
    
    fact:
    .LFB0:
            .cfi_startproc
            testl   %edi, %edi
            movl    $1, %eax
            je      .L4
            .p2align 4,,10
            .p2align 3
    .L3:
            imull   %edi, %eax
            subl    $1, %edi
            jne     .L3
            rep ret # <-- this instruction can be removed
    .L4:
            rep ret
            .cfi_endproc
    .LFE0:
            .size   fact, .-fact
            .section        .text.unlikely

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71923 даже факториал не могут скомпилировать нормально

    Запостил: j123123, 25 Июля 2016

    Комментарии (56) RSS

    • Кстати, какой мудак заминусовал все говнокоды на ассемблере? Есть ли какой-нибудь говноплагин к браузеру, чтобы эти минусы игнорировать и можно было все говнокоды на ассемблере просматривать?
      Ответить
    • Другие мои багрепорты
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152 suboptimal load bytes to stack
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71343 missed optimization (can't "prove" shift and multiplication equivalence)
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68027 conditional statement and unnecessary register assignment
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123 [4.8 Regression] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66178 [4.9/5/6 Regression] Another label as values ICE in gen_reg_rtx, at emit-rtl.c:1059

      Кстати вы не подумайте, что это только gcc, в clang тоже хватает хуйни, просто я туда не репорчу и их компилятор не юзаю. Хотя кое-какие баги оптимизаций я находил, и internal compiler error вызывал даже
      Ответить
    • > даже факториал не могут скомпилировать нормально

      по моему ты фигней страдаешь. на 4.9/4.8 код выглядит нормально. а в продакшн пихать самую свежую версию компилера - тем более гцц - это ты просто напрашиваешься.

      с другой стороны: спасибо за усилия по тестированию :D
      Ответить
      • показать все, что скрыто> а в продакшн пихать самую свежую версию компилера - тем более гцц - это ты просто напрашиваешься.

        Это как? А какую тогда версию пихать? Предпоследнюю?
        Ответить
        • я с новой системой номеров версий еще не сжился, но в 4й ветке это `4.(actual_version-1).max(dotdotversion)` - работает на ура.

          с 5/6 версиями пока не приходилось работать - но это как по мне экспериментальные бранчи: народ инфраструктуру (в 5ке) и оптимайзер (в 6ке) перехуячивают.

          кошмары мискомпайлов с 4.9.1 все еще свежи в памяти. а 4.9.2 & 4.9.3 вроде в порядке. в chroot'овой системе у нас с 4.9.1 только сам GCC и собрался - все остальное сыпалось. в 4.9.2 были какие-то грабли с хидерами и пара прикладух не собиралась. 4.9.3 вроде работает - но внедренее отложили - продакшн тулчейн все еще на 4.8.2 сидит.
          Ответить
          • ЗЫ redhat федору с 5.3.1 (по традиции снэпшот из SCM) выпустил - testament to the RedHat's QA - у кучи народа просто нифига не запускалось после инсталяции, потому что пара модулей центральных гномовский были мискомпилированы. и им пришлось сделать по быструхе патч. коллега в офисе который хотел на свежий гном/плазма посмотреться долго плевался. но зато, мля, свежая версия GCC.
            Ответить
            • > мискомпилированы
              Типа гцц неправильный машинный код сгенерил?
              Ответить
              • насколько помню, оптимизации чего-то там криво съоптимизировали, и код просто криво работал. где-то бегал пост от редхатовцев по той паре багов.

                меня больше поразила реакция девелов на это - а именно спокойная и размереная: ну подумаешь что свеже выпущеный релиз из коробки не работает... фикс уже закомитили, просто нужно запустить апдейт - до которого добраться из-за этих багов не возможно - и все будет чики-пыки.
                Ответить
                • Надеюсь никогда не столкнусь с багами в кодогенерации или в процессоре. Не представляю, как дебажить такое в продакшене.
                  Ответить
                  • симптоматика простая: валится на валидном коде, и иногда это "фиксится" простыми синтаксичискими изменениями и/или мелким переписыванием куска кода. страшно только первые Н раз. юнит/коверадж тесты помогают, как и тестирование против старых версий компилера.

                    на самом деле если ты баги gcc от j123123 пролистывал, то ты бы заметил что он там реально очень сильно чем то страдает (то ли интерпретер, то ли генератор какой-то пишет). поэтому его баги достаточно уникальны.

                    у gcc достаточно большая коллекция тестов, и настоящие серьёзные баги встречаются крайне редко. (к примеру: clang в молодые году мог работающий софт компилировать (включая себя), но все равно обламывался на многих gcc тестах.) хотя у меня складывается впечатлнение что gcc-шники не так часто смотрятся в результаты "make test". смотрят может быть и да - но облом тестов не останавливает релиза.
                    Ответить
                    • > валится на валидном коде, и иногда это "фиксится" простыми синтаксичискими изменениями и/или мелким переписыванием куска кода
                      Для меня скорее повод поискать проезд по памяти в соседнем потоке))
                      Ответить
                      • и где у тебя в однопоточном приложении возьмётся соседний поток?))
                        Ответить
                        • Ну можно и не в соседнем, а в этом же. Или еще УБ какое.
                          А почему мы говорим об однопоточном приложении?
                          Ответить
                          • потому что после пары часов трахания с куском кода, ты его выносишь в helloworld.cc (у меня как правило tmpNNN.cc) и дебажишь там. или ты из тех кто все делает прямо в проекте, прямо в тех же сырцах, и никогда в IDE проект не переключаешь?
                            Ответить
                            • > ты его выносишь
                              Если код так легко выносится - может стоит там его и оставить и получить юнит-тест?
                              Ответить
    • Vanished
      Ответить
    • Раньше занятно было, а теперь одни нопы.
      Ответить
    • показать все, что скрытоЯ пошатывал дымоход Вашего поместья.
      Ответить
    • Хм, только сейчас заметил, что это сидящий человечек с головой утки, в которого летит копьё.
      Ответить
    • показать все, что скрытокто юзает асемблер
      У того хуй перемоло блендер
      Ответить
    • Тут тоже нужно минусовать.
      Ответить
    • Ja zasoriyau stok.
      Ответить
    • показать все, что скрытоРОССИЯ – ЭТО ВЕЛИКАЯ СКИФИЯ. СКИФСКАЯ ЦАРИЦА ТАМАРА БЫЛА РУССКОЙ ЦАРИЦЕЙ. ГОРЖУСЬ И ПОМНЮ!

      Этруски — “Это – Русские” — называли себя Туранцами. То, что они были голубоглазыми блондинами, никто не сомневается. А ШотландцЫ и Англо-Саксы в своих генеалогиях так и пишут своего первопредка как СКИФ. Тамара, изолганная как “Томирис” изображается на картине Итальянского художника Андреа дель Кастаньи (Andrea del Castagno) 1400 года, как Русская женщина с длинной русой косой и большими голубыми глазами. Итальянцы хорошо знали, кто есть кто, и Царя Соломона, например, они изображали, как негра.

      В слове “Томирис”, “ис” – это Греческое окончание, а так как наши Праматери Сар-Матки / Царь Матери / Амазонки всегда били Греков, то, конечно же, её имя было Тамара, а не Томирис. Тамара буквально означает ТА-МА-РА = “та/то/эта Мать РА / Русского”.
      А Кай-САКИ Киргиз-Стана и К
      Ответить

    Добавить комментарий