LINUX.ORG.RU

GCC 4.2.0


0

0

Вышла новая версия open source набора компиляторов GCC, в котором было исправлено большое количество разнообразных ошибок.

Кроме этого, были ужесточены требования к синтаксису языков, добавлена возможность generic оптимизаций под все процессоры x86, добавлена защита от арифметического переполнения и многое другое.

Список изменений:
http://gcc.gnu.org/gcc-4.2/changes.html
Исправленные ошибки:
http://gcc.gnu.org/bugzilla/buglist.c...

Скачать: ftp://gcc.gnu.org/pub/gcc/releases/gc...
Зеркала: http://gcc.gnu.org/mirrors.html

>>> Подробности

★★★★★

Проверено: maxcom ()

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

eveel ★★
()

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

Sectoid ★★★★★
()

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

May 13, 2007

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

anonymous
()

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

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

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

Korwin ★★★
()
Ответ на: комментарий от anonymous

>May 13, 2007

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

Sectoid ★★★★★
()
Ответ на: комментарий от anonymous

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

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

Korwin ★★★
()
Ответ на: комментарий от vimmer

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Alan_Steel ★★
()
Ответ на: комментарий от anonymous

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

nightfog
()
Ответ на: комментарий от anonymous

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

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

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

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

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

anonymous
()
Ответ на: комментарий от Korwin

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

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

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

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

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

>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 и всё равно это не будет багом.

Davidov ★★★★
()

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

anonymous
()
Ответ на: комментарий от Legioner

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

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

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

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

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

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

mky ★★★★★
()
Ответ на: комментарий от mky

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

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

Sectoid ★★★★★
()
Ответ на: комментарий от mky

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

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

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

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

Legioner ★★★★★
()

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

Lumi ★★★★★
()
Ответ на: комментарий от Legioner

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

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

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

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


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

Korwin ★★★
()
Ответ на: комментарий от Legioner

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

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

kss ★★★★★
()
Ответ на: комментарий от Legioner

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

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

Korwin ★★★
()
Ответ на: комментарий от Legioner

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

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

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

anonymous
()
Ответ на: комментарий от kss

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

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

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

Sectoid ★★★★★
()
Ответ на: комментарий от Legioner

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

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

Led ★★★☆☆
()
Ответ на: комментарий от Korwin

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

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

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

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

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

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

Legioner ★★★★★
()
Ответ на: комментарий от Sectoid

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

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

Led ★★★☆☆
()
Ответ на: комментарий от anonymous

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

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

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

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

Legioner ★★★★★
()

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

скорбим...

anonymous
()
Ответ на: комментарий от Led

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

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

Led ★★★☆☆
()
Ответ на: комментарий от Legioner

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

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

Led ★★★☆☆
()
Ответ на: комментарий от Led

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

Legioner ★★★★★
()

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

anonymous
()
Ответ на: комментарий от vimmer

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

- Вычисляем ++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 перед _всем_ вычислением выражением, либо после _всего_.

KRoN73 ★★★★★
()

уряяяяя 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;
}

MaratIK
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.