Comments 33
Видя такие топики на хабре я очень жалею, что не могу отдать недельное количество голосов за карму автору топика.
Чё-то жёсткий сегодня денёк на O2 приколы :) Сам недавно 6 часов в SIGSEGV убил ради того чтобы узнать "-O2 implies -fstrict-aliasing", челябинский алиасинг я минимум от -O3 ожидал. Еще и вылезло на жёстком reorder через инлайны (варнинга не было), включая reorder вокруг отладочных printf'ов, что хрен поймёшь когда конкретно оно падает :) пришлось лепить __asm__ __volatile__ ("" ::: «memory»); барьеры вокруг отладочного вывода.
в MS написали о баге?
Написал только что, спасибо за подсказку.
Могу рассказать о своём опыте. Нашел 3-4 неприятных бага в WPF. Сначала запостил на форумы MSDN (англоязычные, само собой). Там посоветовали отправить баги в Microsoft Connect. Отправил. Так они там 2 уже года и висят, со статусом Active.
это печально, учитывая то, что WPF является одной из ключевых технологий MS…
Вы проверьте или бампните баги — они вообще правят но не всегда ставят статусы…
Продуктовые команды знают о багах на connect.microsoft.com, есть приоритеты, видимо, что ваши баги пока не такие приоритетные, в плане не так много случаев затрагивают. Вообще, продуктовые команды очень хорошо прислушиваются к запросам кастомеров.
Я положительно отношусь к MS, но тем не менее не очень верится про приоритеты. Взять тот же баг с windows phone, который затрагивает кучу пользователей (достаточно погуглить, все форумы, касающиеся wp7 усеяны сообщением о баге), связанный с зависанием телефона в режиме плеера после обновления Mango. Первые рапорты в MS пошли как только Mango стало доступно для разработчиков, до сих пор не починили, а времени прошло с того момента очень прилично.
Причем судя по форумам — это один из очень немногих багов, и самый досаждающий, что не дает усомниться в его приоритетности.
Причем судя по форумам — это один из очень немногих багов, и самый досаждающий, что не дает усомниться в его приоритетности.
То что я нашел — в общем-то не критические баги:
— Самое противное — игнорирование языковых настроек. Всегда используется системная локаль по умолчанию (форматы времени, разделители чисел и т.д.). Вытекающие проблемы, думаю легко понять.
— Свойства UIElement IsArrangeValid/IsMeasureValid имеют значение TRUE до первого вызова Arrange/Measure.
— TextBox обрабатывает событие нажатия на return, даже если свойство AcceptsReturn = false.
— DateTimePicker теряет DateTime.Kind если его не указывать явно.
— Некорректно работает свойство UIElement.IsMouseOver если над элементом раположен PopUp — его значение равно — true если курсор находится в области PopUp'а.
— Если тип значения, передаваемого через Binding реализует ICommand, и Binding'у назначен конвертер, то при попытке передачи значения выбрасывается исключение.
Как-то так.
— Самое противное — игнорирование языковых настроек. Всегда используется системная локаль по умолчанию (форматы времени, разделители чисел и т.д.). Вытекающие проблемы, думаю легко понять.
— Свойства UIElement IsArrangeValid/IsMeasureValid имеют значение TRUE до первого вызова Arrange/Measure.
— TextBox обрабатывает событие нажатия на return, даже если свойство AcceptsReturn = false.
— DateTimePicker теряет DateTime.Kind если его не указывать явно.
— Некорректно работает свойство UIElement.IsMouseOver если над элементом раположен PopUp — его значение равно — true если курсор находится в области PopUp'а.
— Если тип значения, передаваемого через Binding реализует ICommand, и Binding'у назначен конвертер, то при попытке передачи значения выбрасывается исключение.
Как-то так.
Сначала пытался найти в коде undefined behaviour, но вроде тут всё просто и однозначно. Интересный баг.
P.S. В GCC 4.6.1 linux amd64 не проявляется.
P.S. В GCC 4.6.1 linux amd64 не проявляется.
Разработчики компилятора перемудрили с п. 5.8/3 стандарта C++, про implementation-defined правого сдвига знаковых типов.
Microsoft в данном случае гарантирует нормальный сдвиг:
msdn.microsoft.com/en-us/library/336xbhcz%28v=VS.100%29.aspx
Вот если бы x был отрицательным, то было бы «implementation-dependent».
msdn.microsoft.com/en-us/library/336xbhcz%28v=VS.100%29.aspx
Вот если бы x был отрицательным, то было бы «implementation-dependent».
Поменял в коде знаковый тип int на unsigned int, ошибка осталась.
Что-то я не понял. Почему виноват компилятор, если по Стандарту сдвиг вправо для знаковых типов не определён?
Цитата из Стандарта: «The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 / 2E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.»
Цитата из Стандарта: «The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 / 2E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.»
Специально для того, чтобы исключить этот недостаток сдвига знаковых — исправил int на unsigned int в двух местах: в параметрах функции f и в определении переменной x.
От этого ассемблерный код тоже поменялся в двух местах, вместо команды sar теперь shr, что и следовало ожидать, в ассемблере это тоже поправил.
Все остальное, влючая ошибку — осталось.
От этого ассемблерный код тоже поменялся в двух местах, вместо команды sar теперь shr, что и следовало ожидать, в ассемблере это тоже поправил.
Все остальное, влючая ошибку — осталось.
Был неправ. Число 0x76543210 — неотрицательное, на него этот пункт не распространяется.
Баг в компиляторе, да.
Баг в компиляторе, да.
Скажите, а почему x объявлен как static?
Изначально это был не просто int x, а целый массив int x[], который с помощью функции f() развертывался в другой массив char a[], более большой по размеру, но с которым в дальнейшем работать удобнее.
А объявлен массив x был static для того, чтобы не было лишнего копирования из сегмента _DATA в _STACK.
Например, вот так объявлять неправильно, будет лишнее копирование при каждом входе в функцию
(в данном случае это функция main) так как x лежит в стеке, а {1,2,3} в данных:
А вот так правильно, x в данных и {1,2,3} в данных, оба места совпадают, копирования не будет:
Но более того, если теперь взять и убрать static — то «ошибка -O2» исчезает.
То есть static — это важный элемент проблемного кода.
А объявлен массив x был static для того, чтобы не было лишнего копирования из сегмента _DATA в _STACK.
Например, вот так объявлять неправильно, будет лишнее копирование при каждом входе в функцию
(в данном случае это функция main) так как x лежит в стеке, а {1,2,3} в данных:
int x[3]={1,2,3};А вот так правильно, x в данных и {1,2,3} в данных, оба места совпадают, копирования не будет:
static int x[3]={1,2,3};Но более того, если теперь взять и убрать static — то «ошибка -O2» исчезает.
То есть static — это важный элемент проблемного кода.
При всём моём уважении к Майкрософту, в последнее вемя (начина с года 2005) отстают или не привносят в направление Visual Studio ничего особо нового. Баги правятся долго и муторно создавая при этом новые баги. В техподдержке вообще молодцы — «да, знаем, поправим». А когда это будет сделано, хз. Студия за это время пять раз переродиться успеет.
Ваши слова «Легко увидеть» под ассемблерными вставками очень сильно расстраивают некоторых программистов =)
Комментарии «Line 19», «Line 20» несколько сбивают с толку т.к. не соответствуют строкам приведённого ранее исходника.
Сразу обратил внимание на то, что результат работы цикла завистит от последовательности его выполнения выполнения — и действительно, в работающем примере такого нет.
Возможно компилятор, каким-то волшебным образом считает k константой на этапе оптимизации?
Возможно компилятор, каким-то волшебным образом считает k константой на этапе оптимизации?
Sign up to leave a comment.
Об одной ошибке оптимизации времени выполнения