GCC 4.2.0

Diff: ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.2.0/diffs/gcc-4.1.2-4.2.0.diff.bz2

deltup patch: http://dev.gentooexperimental.org/deltup/gcc-4.1.2.tar.bz2-gcc-4.2.0.tar.bz2.dtu

А на главной странице gcc.gnu.org пока пусто. Машину времени починили?

Ну просто неделя праздничных новостей: boost, gcc...

Жжешь !!! Как ты это перевел?

May 13, 2007

The GNU project and the GCC developers are pleased to announce the release of GCC 4.2.0.

> Кроме этого, были ужесточены требования к синтаксису языков,

Што опять?!?! Снова софт не будет компилиться без бубнов?

А если сырцы не поддерживаются автором, опять напильник в руки, блин.

Не нравится - слезай.

>May 13, 2007

А ебилдов всё нет... Эх, не та уже гента.... Где красноглазие?

А баг с '++i + ++i' пофиксили?

Ура!

> А баг с '++i + ++i' пофиксили?
А разве значение этой конструкции определено? В чём баг?

> Не нравится - слезай.

ути пути. какие мы обидчивые :)
Или предпочитаем держать голову в песке и не видить очевидного?

>А разве значение этой конструкции определено? В чём баг?

Конечно определено. правильный результат - 13.

++i + ++i = i+4
По-моему годится

А под Windows он работает?

> ++i + ++i = i+4
++i + ++i = 2i+4, сорри

Это Undefined behaviour AFAIR. Т.е. компилятор может выбирать любой порядок вычисления подвыражения.

>Конечно определено. правильный результат - 13. Учи мат. часть 14

++i + ++i = 2*(i+1)

++i + ++i = i+1 + i+2 = 2*i + 3

идиот, 2*(i+2)

++i + ++i = (2*i)+2

++i + ++i = 14

То что написали это

(i + 2) + (i + 2) == 2 * (i + 1)

Все же ++i + ++i - немного другое

Логически так:

(i + 1) + ((i + 1) + 1)

> Што опять?!?! Снова софт не будет компилиться без бубнов?

Ты не в ту сторону думаешь. Надо так: Ура! Больше багов отловится при компиляции!

> А если сырцы не поддерживаются автором, опять напильник в руки, блин.

Если сырца не поддерживаются, значит программа мертва. Вариантов несколько - оставить на машине компилятор, с которым программа компилируется, либо оживить программу.

Давайте закроем тему от анонимусов :) Я не могу на это смотреть.

>The subexpression i++ causes a side effect--it modifies i's value--which leads to undefined behavior since i is also referenced elsewhere in the same expression.

>undefined: Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended.

Так что gcc в этой ситуации может сделать даже rm $HOME и всё равно это не будет багом.

Отличная новость! А то вчера весь день обсуждали как Патриг (Бох!) посрался с гаимовцами (гамнюки).

Вы как власти Москвы хотите поступить и закрыть парад инакомыслящих анонимусов ? =)

http://img1.liveinternet.ru/images/attach/b/0/16663/16663373_march.jpg

>> Што опять?!?! Снова софт не будет компилиться без бубнов?

>Ты не в ту сторону думаешь. Надо так: Ура! Больше багов отловится при компиляции!

Это еще не доказано, Линус высказывался в смысле, что если бы ему был нужен "строгий" язык, он бы использовал Паскаль, а Си --- это для разных хаков.

>> А если сырцы не поддерживаются автором, опять напильник в руки, блин.

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

Оживить программу --- это делать форк и открывать новый проект (многим это не интересно), а иначе получится что каждый по отдельности "точит старый исходник напильником".

>Оживить программу --- это делать форк и открывать новый проект (многим это не интересно), а иначе получится что каждый по отдельности "точит старый исходник напильником".

Необязательно. Достаточно сделать патч и где-нибудь захостить.

> Это еще не доказано, Линус высказывался в смысле, что если бы ему был нужен "строгий" язык, он бы использовал Паскаль, а Си --- это для разных хаков.

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

> Оживить программу --- это делать форк и открывать новый проект (многим это не интересно), а иначе получится что каждый по отдельности "точит старый исходник напильником".

Ну не обязательно форк, можно связаться со старым разработчиком и договориться. Не думаю, что он будет против. А если не интересно, значит программа не очень то нужная.

Делтуповский дифф размером 8,3 мегабайба. Вот это я понимаю -- наваяли на славу. Респект и уважуха. Смотрю список закрытых ошибок...

> Ты не в ту сторону думаешь. Надо так: Ура! Больше багов отловится при компиляции!

Совершенно не факт.

> Если сырца не поддерживаются, значит программа мертва.
Некоторым программам/библиотекам нет смысла развиваться - они делают
свое четко специализированное дело хорошо и не являются комбайнами все-в -одном.

> Вариантов несколько - оставить на машине компилятор, с которым программа компилируется,
Держать зоопарк версий компиляторов это безусловно true way! Но по факту так и приходится делать :(


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

> он не позволяет программировать на низком уровне

Если речь об ассемблерных вставках, то это не так. В Паскале можно вставлять в программу куски на ассемблере. А в TurboPascal'е, вроде бы, можно было даже вставлять машинный код.

> А если не интересно, значит программа не очень то нужная.
Совершенно не факт.

Просто в таких ситуациях начинаешь искать альтернативы. Когда находишь, а когда сам пишешь.

> Я с этим не согласен. Производительность паскаля хуже, чем у С, он не позволяет программировать на низком уровне, у него слишком многословный синтаксис.

Глупости. Производительность зависит только от степени кривизны компилятора, программировать на низком уровне он прекрасно позволяет (и я лично писал на паскале драйверы).

Причем никому не приходит в голову хаять modula (вполне себе язык для системного программирования) или ada. Хотя это все языки одной группы.

>> он не позволяет программировать на низком уровне

>Если речь об ассемблерных вставках, то это не так. В Паскале можно вставлять в программу куски на ассемблере. А в TurboPascal'е, вроде бы, можно было даже вставлять машинный код.

А для чего был предуман C знаете? А как его ещё называют? Так вот, C часто называют "portable assembler". Почему его так называют и что это даёт тоже объяснять?

>Производительность паскаля хуже, чем у С, он не позволяет программировать на низком уровне, у него слишком многословный синтаксис. Неплохой язык для обучения (впрочем сейчас есть лучше), но сравнивать с С его не надо.

Это такое "дяденька с телевизора" говорил? Или знакомый хацкер-старшекласник рассказал?

> Совершенно не факт.

Если программа не соответствует общепринятому стандарту языка, на котором она написана, это баг. Не очень важный, но баг. gcc конечно хороший компилятор, но забывать про другие - не очень хорошо.

> Некоторым программам/библиотекам нет смысла развиваться - они делают свое четко специализированное дело хорошо и не являются комбайнами все-в -одном.

Поддержка не обязательно значит развитие. Поддержка = багфиксинг (да, в любой программе есть баги, даже в coreutils), в том числе поддержка программы в компилируемом состоянии.

> Иногда бывает проще написать с нуля, чем править чей-то код, особенно если использовались нюансы определенных версий.

Зависит от языка и профессионализма разработчика. Иногда - действительно проще. Но это вообще то не очень частый случай, чаще лучше править. Хоть это и не так интересно, как писать с нуля :)

>C часто называют "portable assembler". Почему его так называют и что это даёт тоже объяснять?

Объясни:) А также то, как сочетаются "portable assembler" и непределённости порядка вычисления (которые принудительно только через "одно место" обходятся).

> Глупости. Производительность зависит только от степени кривизны компилятора,

От языка это тоже зависит. С - это чуть ли не ассемблер. А например JavaScript заведомо медленней, чем С++, и это компилятор исправить не в состоянии.

> программировать на низком уровне он прекрасно позволяет (и я лично писал на паскале драйверы).

Мы говорим про разные паскали наверное. Я имел в виду оригинальный Виртовский паскаль. Его модификаций куча, турбо паскаль - достаточно интересный язык, но он во-первых проприетарный, во-вторых не поддержикается (АФАИК).

>The <?, >?, <?=, and >?= operators, deprecated in previous GCC releases, have been removed.

скорбим...

неопределенность порядка вычисления = больший простор компилятору для оптимизации.

Нету у меня знакомых хацкеров-старшеклассников, и телевизора нет :(

>неопределенность порядка вычисления = больший простор компилятору для оптимизации

А также нивелирование звания "assembler"

>Мы говорим про разные паскали наверное. Я имел в виду оригинальный Виртовский паскаль. Его модификаций куча

Т.е. ты изначально начал сравнивать "язык Паскаль" и "копилятор С", атеперь удивляешся, что тебя "мокают"?:)

Я сравнивал язык паскаль и язык С. Я могу дать ссылки на их стандарты, если кто-то не сможет их найти. Если имеля в виду турбо паскаль, то об этом стоило упомянуть, т.к. клонов паскаля достаточно много. Но вряд ли Линус имел в виду турбо паскаль.

Да, все же Патриг был прав.

Строго формально, по принципам разбора выражения в Си, логика должна быть такая.

- Вычисляем ++i (i=6, результат - в стеке)
- Выбираем операцию сложения
- Вычисляем ++i (i=7, результат - в стеке)
- Складываем (6+7=13)

Ибо строго оговорено, что ++i увеличивает значение и возвращает результат. А при сложении все операнды выполняются слева на право.

Аналогично для i++ + i++
- Вычисляем i++ (i=6, на стеке - 5)
- Выбираем операцию сложения
- Вычисляем i++ (i=7, на стеке - 6 )
- Складываем (5+6=11).

При чём во всех языках, где есть эти оператора, кроме Си, оно работает именно так. От PHP до Java :)

Что же получается в Си... В стандарте оно оговорено, как не определённость, а разные компиляторы выдают разные значения :D GCC, например, работает, ЕМНИП, с автоинкрементами атомарно. Т.е. увеличивает i перед _всем_ вычислением выражением, либо после _всего_.

уряяяяя OpenMP добавили!!!!

теперь можно писать так:
int main(int argc, char *argv[])
{
  int i, a[1000];
  #pragma omp parallel for
  for (i=0;i<N;i++) 
     a[i]= 2*i;
  return 0;
}