The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз набора компиляторов GCC 13, opennews (??), 26-Апр-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


67. "Релиз набора компиляторов GCC 13"  +3 +/
Сообщение от Аноним (74), 26-Апр-23, 21:51 
> А зачем он нужен? По-моему 0/1, проще чем false/true.

Например:


uint8_t var1 = 256;
if (var1) do_something(); // Хоть var1 не ноль на вид, там 0 и сюда не попадем!


bool var1 = 256;
if (var1) do_something(); // А вот тут будет вызвано (var1 == true)

Секрет в том false залекларен как 0, true как 1, а все что больше обрубается при матеметике до 1. И в принципе можно при статическом анализе варнинги кидать если там более 1. Меньше места для прострела пяток в целом. Просто более специфицированный под задачу begavior, более уместный.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

106. "Релиз набора компиляторов GCC 13"  +1 +/
Сообщение от _kp (ok), 27-Апр-23, 01:03 
>>uint8_t var1 = 256

На подобное заведомое переполнение gcc ругается.
И когда из большего типа в меньше без приведения типа присваивают, тоже ругается.

Про bool - верно.

Ответить | Правка | Наверх | Cообщить модератору

123. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Аноним (123), 27-Апр-23, 05:58 
> На подобное заведомое переполнение gcc ругается

И это если повезёт. Недавно искал проблему в коде, где

> printf("%d == %d (%d)\n", a, b, a == b);

выводило то ли "9 == 11 (1)", то ли "11 == 11 (0)" просто из-за такого вот неопределённого поведения где-то рядом в коде, после которого компиятор получил карт-бланш на любые извращения в целях копеечной оптимизации.

Ответить | Правка | Наверх | Cообщить модератору

246. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Аноним (-), 28-Апр-23, 00:08 
> На подобное заведомое переполнение gcc ругается.

Это был простейший пример. В реальном коде будет нечто ближе к:


uint8_t var1 = 255;
...
var1++;
if (var1) ... // Ну и вот кто тут про ноль из-за mod(2^8) math подумает? :)

...и на это ругаться уже не будет в общем случае.

> И когда из большего типа в меньше без приведения типа присваивают, тоже ругается.

Если кто храбрый -Wconversion ему в руки, узнаете много нового о своем коде и его (без)глючности и (без)опасности в плане работы с целыми числами.

> Про bool - верно.

Его все же специально сделали для логических выражовываний, с inеeger'ами это не сколько более стремное занятие.

Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

276. "Релиз набора компиляторов GCC 13"  +/
Сообщение от _kp (ok), 28-Апр-23, 10:23 

> Если кто храбрый -Wconversion ему в руки,

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

Ответить | Правка | Наверх | Cообщить модератору

333. "Релиз набора компиляторов GCC 13"  +1 +/
Сообщение от Аноним (237), 01-Май-23, 00:30 
> Да, 90% бестолковых предупреждений,

Вообще-то вполне толковых, а то что часто прокатывает и так - на самом деле без гарантий и благодаря вот этой штуке дурных багов математики отловлено немеряно. А где ну вот очень надо что-то странное - явно кастовать, не халявить. Хотя система типов в си все же весьма специфичная, и вон то лишь хайлайтит это дело, не более.

> но для своего кода, так использую, иногда помогает же.

Сильно повышает качество кода. И я про него узнал от Ian Colett - автора LZ4, в его бложике о том как писать код качественнее и надежнее.

> и если типы совпадают по размеру, то по мнению компилятора сойдёт и так.

Это какой-то совсем нишевой случай. Для pointer vs integer вопли есть, struct'ы логично юзать через typedef'ы и так чужой структ совсем скормить без явного желания нереально.

Ответить | Правка | Наверх | Cообщить модератору

342. "Релиз набора компиляторов GCC 13"  +/
Сообщение от _kp (ok), 01-Май-23, 10:33 
>> Да, 90% бестолковых предупреждений,
> Вообще-то вполне толковых,

Вообще то, в первую очередь интересует отлов ошибочного присваивания не тому типу, хоть и того размера, а не приведения типов. Хотя в коде предназначенном для сборки для 32 и 64 битных систем, грабли найдутся и там.
Но, поскольку лучше по максимуму отловить проблемы на стадии компиляции, а не из багрепортов, то мне более приемлимы  "бестолковые" предупреждения. И исходник считается вменяемым, если нет предупреждений при включении практически всех опций, кроме Wpedantic.

Ответить | Правка | Наверх | Cообщить модератору

347. "Релиз набора компиляторов GCC 13"  +1 +/
Сообщение от Аноним (-), 02-Май-23, 03:43 
> Вообще то, в первую очередь интересует отлов ошибочного присваивания не тому типу,
> хоть и того размера, а не приведения типов.

А что это за ситуации вообще? Мной это не распознается как какая-то типовая проблема, чтобы "в первую очередь" волновало. Нельзя ли конкретных примеров как, где и почему это является заметной проблемой?

> Хотя в коде предназначенном для сборки для 32 и 64 битных систем,
> грабли найдутся и там.

В нормально написаном портабельном коде там вообще грабель не должно быть. Для себя я предпочитаю C99 и конкретные размеры типов, для точно определенного диапазона значений, так что платформа либо предоставляет мне ЭТО либо "out of luck" (с 99го года почти четверть века прошла).

> Но, поскольку лучше по максимуму отловить проблемы на стадии компиляции, а не
> из багрепортов, то мне более приемлимы  "бестолковые" предупреждения.

Я даже false alarm статических анализаторов затыкаю. Потому что не прочь поразвлечься всяким микроконтроллерным и управляющим и последнее что я хочу это баги в таких применениях. В этом месте параноидальные варнинги и статический анализ очень хорошая идея.

> И исходник считается вменяемым, если нет предупреждений при включении
> практически всех опций, кроме Wpedantic.

Я переживаю как минимум Wall, Wpedaitic, Wconverson и как минимум cppcheck еще. Если кто-то из них недоволен, это еще не релизное качество.

Ответить | Правка | Наверх | Cообщить модератору

349. "Релиз набора компиляторов GCC 13"  +/
Сообщение от _kp (ok), 02-Май-23, 12:35 
>> Вообще то, в первую очередь интересует отлов ошибочного присваивания не тому типу,

Это считай руко%опство в проектах которые пишут несколько человек, и особенно в разное время, и оно плохо плохо обнаружимо, и может даже вполне работать.. пока не тронешь.

> В нормально написаном портабельном коде там вообще грабель не должно быть.

Чужой код в принципе не бывает нормальным, и особенно тот в котором попросили исправить "мелочи" или доработать. Шутка, но с долей правды.


Ответить | Правка | Наверх | Cообщить модератору

352. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Аноним (58), 07-Май-23, 07:39 
> Это считай руко%опство в проектах которые пишут несколько человек, и особенно в
> разное время, и оно плохо плохо обнаружимо, и может даже вполне
> работать.. пока не тронешь.

Мне пример этого интересен, как бы это могло выглядеть. Потому что сходу баг такого типа не припоминается особо. И хотелось бы понять как и почему это образуется и (если это выглядит правдоподобно) как этого можно было бы избегать.

> Чужой код в принципе не бывает нормальным, и особенно тот в котором
> попросили исправить "мелочи" или доработать. Шутка, но с долей правды.

На самом деле чужой код бывает очень разным. От г-на до мегарулеза. При том иногда все и сразу, за некоторый код хочется наградить кодера медалью и расстрелять.

Ответить | Правка | Наверх | Cообщить модератору

113. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Ванёк (?), 27-Апр-23, 02:14 
Если использовать uint8_t как bool, то производительность упадёт. Лучше использовать uint32_t - производительность выше.
Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

122. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Аноним (123), 27-Апр-23, 05:55 
> Лучше использовать uint32_t - производительность выше

А если использовать 64 байта и выравнивать на 64 байта, то автоматом избавимся ещё и от проблем с мультипроцессорностью из-за доступа нескольких ядер к одной строке кеша.

Ответить | Правка | Наверх | Cообщить модератору

160. "Релиз набора компиляторов GCC 13"  +1 +/
Сообщение от n00by (ok), 27-Апр-23, 11:46 
А что там такое может храниться может на практике, что разные ядра лезут в смежные ячейки?
Ответить | Правка | Наверх | Cообщить модератору

157. "Релиз набора компиляторов GCC 13"  +1 +/
Сообщение от _kp (ok), 27-Апр-23, 11:17 
> Если использовать uint8_t как bool, то производительность упадёт. Лучше использовать uint32_t
> - производительность выше.

Для intel 32bit - да. А других архитектурах может быть быстрее.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

190. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Ванёк (?), 27-Апр-23, 14:59 
На x86_64 операции с uint32_t будут быстрее, чем с uint8_t и uint16_t.
Ответить | Правка | Наверх | Cообщить модератору

204. "Релиз набора компиляторов GCC 13"  +/
Сообщение от фф (?), 27-Апр-23, 16:25 
а на AVR?
Ответить | Правка | Наверх | Cообщить модератору

213. "Релиз набора компиляторов GCC 13"  +/
Сообщение от _kp (ok), 27-Апр-23, 17:12 
> а на AVR?

Вы сами догадываетсь.

На Cortex и Risc-v 32bit 8/16 битный bool быстрее 32х битного.

Ответить | Правка | Наверх | Cообщить модератору

221. "Релиз набора компиляторов GCC 13"  +/
Сообщение от n00by (ok), 27-Апр-23, 18:15 
> На x86_64 операции с uint32_t будут быстрее, чем с uint8_t и uint16_t.

Когда будут и кто обещал? Пока операции с регистрами занимают одинаковое количество тактов (uint16_t не беру в расчёт, это почти не используют), а чтение из памяти в сумме быстрее для компактных данных.

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

231. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Ванёк (?), 27-Апр-23, 22:04 
> Когда будут и кто обещал?

См. документацию по ассемблеру x86_64.

Ответить | Правка | Наверх | Cообщить модератору

271. "Релиз набора компиляторов GCC 13"  +/
Сообщение от n00by (ok), 28-Апр-23, 08:40 
>> Когда будут и кто обещал?
> См. документацию по ассемблеру x86_64.

Зачем я буду смотреть всякую чепуху, какую Вы и процитировать стесняетесь? Я смотрю 64-ia-32-architectures-optimization-manual.pdf (см. цитату в №222), AMD_Athlon_Processor_x86_Code_Optimization_Guide.pdf и Software Optimization Guide for AMD Family 17h Processors-55723_3_01_0.zip

Ответить | Правка | Наверх | Cообщить модератору

222. "Релиз набора компиляторов GCC 13"  +1 +/
Сообщение от n00by (ok), 27-Апр-23, 18:21 
>> Если использовать uint8_t как bool, то производительность упадёт. Лучше использовать uint32_t
>> - производительность выше.
> Для intel 32bit - да. А других архитектурах может быть быстрее.

Из относительно современных нашёл такое только для Atom (не путать с Silvermont и более новыми - 45 nm Intel Atom processors introduced Intel Atom microarchitecture. The same microarchitecture also used in 32 nm Intel Atom processor)

D.3.3.5
Parameter Passing
Due to the limited situations of load-to-store forwarding support in Intel Atom microarchitecture, param-
eter passing via the stack places restrictions on optimal usage by the callee function. For example, “bool”
and “char” data usually are pushed onto the stack as 32-bit data, a callee function that reads “bool” or
“char” data off the stack will face store-forwarding delay and causing the memory operation to be re-
issued.
Compiler should recognize this limitation and generate prolog for callee function to read 32-bit data
instead of smaller sizes.

Assembly/Compiler Coding Rule 18. (MH impact, M generality) For Intel Atom processors, “bool”
and “char” value should be passed onto and read off the stack as 32-bit data.

Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

247. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Аноним (-), 28-Апр-23, 00:12 
> Если использовать uint8_t как bool, то производительность упадёт. Лучше использовать uint32_t
> - производительность выше.

Вот прям так универсально? Ну попробуйте свой совет на AVR. И получите пролет по скорости в разы. Компилеру виднее как bool оформить потребно на его платформе в вон тех гарантиях. Переумничать компилер? Вы скорее пятки себе прострелите с таким уровнем знаний.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

151. "Релиз набора компиляторов GCC 13"  –1 +/
Сообщение от fidoman (ok), 27-Апр-23, 10:24 
"uint8_t var1 = 256;"

И в этом весь C. Сделать для быстрого косособачинга кривую функцию компилятора (обрезание типов молча) и гору ad-hoc библиотечных функций. Заявить этот набор "стандартом". 30 лет со всем этим мяснить, порождая горы прог и утилит, дырявых в самых неожиданных местах. Через 30 лет начать пытаться сделать из этого Паскаль с C-синтаксисом.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

184. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Пользователь чебурнетаemail (?), 27-Апр-23, 14:22 
> И в этом весь C. Сделать для быстрого косособачинга кривую функцию компилятора
> (обрезание типов молча) и гору ad-hoc библиотечных функций. Заявить этот набор
> "стандартом". 30 лет со всем этим мяснить, порождая горы прог и
> утилит, дырявых в самых неожиданных местах. Через 30 лет начать пытаться
> сделать из этого Паскаль с C-синтаксисом.

А теперь ещё раз и по-русски.

Ответить | Правка | Наверх | Cообщить модератору

264. "Релиз набора компиляторов GCC 13"  +/
Сообщение от _ (??), 28-Апр-23, 05:23 
дитё порвало ( | )  :-D
сию конструкцию засунуть в компилятор и понять что не собеётся, ума (предсказуемо) - не хватило :)
Ответить | Правка | Наверх | Cообщить модератору

272. "Релиз набора компиляторов GCC 13"  +/
Сообщение от n00by (ok), 28-Апр-23, 08:50 
И соберётся и запустится. Эффект окажется для некоторых неожиданным. Особенно для перепутавших компилятор с линкером.
Ответить | Правка | Наверх | Cообщить модератору

334. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Аноним (237), 01-Май-23, 00:31 
> сию конструкцию засунуть в компилятор и понять что не собеётся, ума (предсказуемо)
> - не хватило :)

Соберется, но в современных компилерах warning выдаст.

Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

249. "Релиз набора компиляторов GCC 13"  +/
Сообщение от Аноним (-), 28-Апр-23, 00:14 
> И в этом весь C. Сделать для быстрого косособачинга кривую функцию компилятора
> (обрезание типов молча)

Не угадал, де факто там варнинг в современных компилерах будет. Но как утрированый пример сойдет, влом было кодить обман варнинга в утрированом примере, извини.

> утилит, дырявых в самых неожиданных местах. Через 30 лет начать пытаться
> сделать из этого Паскаль с C-синтаксисом.

Где там и чего от паскаля вообще? Это я как прогавший на паскале спрашиваю.

Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру