http://gcc.gnu.org/gcc-3.3/changes.html#obsolete_systems
Also, some individual systems have been obsoleted:
o VMS, vax-*-vms*

Вот так, выкидывают поддержку VMS:)

Да, там бы не мешало повыкидать еще много чего - оставили бы минимум платформ да довели до ума...

ЗЫ 3.4 (CVS) постабильней вроде (чисто субьективное мнение)

предыдущему анониму

нет, не так,
чисто мое, красноглазое субъективное мнение.
Так поточнее.

Смешно слышать такие фразы от людей, даже туманно не представляющих себе работу компилятора, и не умеющих программировать.
Что такое стабильность gcc? То что он в core не падает ;))?

Стабильней - значит делает правильный код. Напомнить как "мудит" gcc версии менее чем 2.4.96 ?

Да блин - оно и видно как "программит" этот "спец" знающий нетуманно принцып работы компилера 8) Брысь под лавку, чмо в перьях - и не встревай когда дяди базарят про вещи недоступные твоему скудному умишку.

http://gcc.gnu.org/gcc-3.3/changes.html#3.3.1

Нехилый такой bug fixes списочек.

### - правильное пиво !
а вот что такое правильный код ;)
опа, тыб еще про 1.x вспомнил ;)

короче, красноглазые нах#$ !

Гм, сдвиги по сравнению с 3.3 несомненно имеются - надо будет погонять на каком нибудь монстроидальном пакете с хорошей оптимизацией ....

* 11198 -O2 -frename-registers generates wrong code (aliasing problem)

* 11304 Wrong code production with -fomit-frame-pointer

* 11381 volatile memory access optimized away

* 11536 [strength-reduce] -O2 optimization produces wrong code

* 11557 constant folding bug generates wrong code

-fssa к сожалению пашет по прежнему криво

Предыдущий пост - кстати, как спецом для пернатого нетуманного "знатока"

примеры кода давай тогда

будем думать, обсуждать

>>Стабильней - значит делает правильный код. Напомнить как "мудит" gcc версии >>менее чем 2.4.96 ?

а что есть официальный релиз с номером 2.4.96?(шапковое поделие не имеется в виду)

На gnu.org такой версии не знают. Версии x.96 ходили как специализированные под разные платформы - или же в качестве поделок от линукс-мэйкеров и представляли собой запаченный по самое нехочу тот или иной релиз gcc.

Зы Там кстати какието перемены грядут - alpha.gnu.org в дауне, на ftp.gnu.org можно лицезреть довольно любопытную картину например в каталоге sed :)

>>>примеры кода давай тогда ...

Для начала изучаем и осмысливаем результат cc1 --help. А потом пытаемся применить хотя бы малюсенькую часть этого великолепия, например к MPlayer :)

MandrakeSecurity Multi Network Routing :))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) ))))))))))

Собрал Х под сабжем - размер ужался (2-3%) по отношению к 3.3/3.2.3 Глюков оптимизации не наблюдал (как было отмечено -fssa не пашет)

2anonymous (*) (2003-08-09 22:24:28.373678)

>Стабильней - значит делает правильный код. Напомнить как "мудит" gcc версии менее чем 2.4.96 ?


Нет такой версии мил человек.
Ты наверно с 2.96 спутал
2.95.3 - очень даже стабилен
2.7, 2.8 тоже были неплохи, c++ правда там отставал чуть-чуть

1.1.2 eggs был отличен и с c++, от него кстати и происходят ветки gcc >2.95

Я бы сказал, не gcc > 2.95, а gcc >= 2.95 :)

Вот несколько реальных встреченных мной имоими колегами примеров неправильной генерации.

(1) Обявляешь в стеке еще одну переменную, и стек увеличивается на 4K что для ядра иногда равнозначно смерти (3.2 или 3.3 pre).
(2) Неправильно генерится код для работы с 64bit значениями для 32bit -ных архитектур.
(3) Там где встречается копирование структур например

struct a {
int arr[100];
};

struct b {
int arr[100];
};

void some_func(struct a *a1, struct b *b1) {
*a = *b;
}

*a = *b вместо пересылки данных, генеится вызов libc-функции memcpy (3.2 или 3.3 pre если включена дебаг информация)

(4) Глюк с typedef выровняных типов в gcc-2.95.x.

>Обявляешь в стеке еще одну переменную, и стек увеличивается на 4K По-моему логично при нехватке памяти выделять ее страницами. Или нет?

> *a = *b вместо пересылки данных, генеится вызов libc-функции memcpy (3.2 или 3.3 pre если включена дебаг информация) А что там еще должно/может генерироваться?

anonymous (*) (2003-08-11 18:49:11.467606) respect

anonymous (*) (2003-08-11 19:05:43.997436) true, man ;)

>>>По-моему логично при нехватке памяти выделять ее страницами. Или нет?

Нет конечно. Стек должен углубляться на размер локального мусора. Иначе проблем не перечесть.

мусор это куча ? ты знаешь стек и куча немного типа разные вещи...

> *a = *b вместо пересылки данных, генеится вызов libc-функции memcpy (3.2 или 3.3 pre если включена дебаг информация) А что там еще должно/может генерироваться? Там должен генериться код пересылки данных. А если я не хочу линковаться на libc и юзаю -nostdlib?

ты вообще в код когда нибудь заглядывал до этого? так делает не только GCC

если не хочешь libc, пиши свою memcpy, а кроме libc есть еще много разных (newlib например)

>Обявляешь в стеке еще одну переменную, и стек увеличивается на 4K По-моему логично при нехватке памяти выделять ее страницами. Или нет?

Нет конечно. Думаешь на кой хер ядро компилится с флажком -mpreferred-stack-boundary=2? Там стека кот наплакал, 6K примерно, и если ты по исчерпании 4К хапнешь еще 4K на свою переменную int то ядру кранты однозначные.

>>>ты вообще в код когда нибудь заглядывал до этого? так делает не >>>только GCC >>>если не хочешь libc, пиши свою memcpy, а кроме libc есть еще много >>>разных (newlib например) в 3.3 релизе этого нет между тем. И правильно, нефиг совать то что я не прошу

Почему тогда это работает? Если стек такой маленький, оно должно в кору падать.

#include <iostream> long my_cool_f() { const long size = 1000000; long a[size]; for(long i=0; i!=size; ++i) a[i] = i; long count = 0; for(long i=0; i!=size; ++i) count += a[i]; return count; }; int main() { std::cout << my_cool_f() << std::endl; return 0; }

Повторю пост, так как предыдущий нечитаем.

#include <iostream>

long my_cool_f()

{

const long size = 10000000;

long a[size];

for(long i=0; i!=size; ++i)

a[i] = i;

long count = 0;

for(long i=0; i!=size; ++i)

count += a[i];

return count;

};

int main()

{

std::cout << my_cool_f() << std::endl;

return 0;

}

В ядре стек маленький. Там дескриптор процесса и его кернел стек лежат в двух соседних страницах.

> Почему тогда это работает? Если стек такой маленький, оно должно в кору падать.

Чувак, ты следи за темой. Какой в баню std:: и прочие iostream? Разговор идет про kernel space а не про user space.

>в 3.3 релизе этого нет между тем.

если это правда (в чем я, впрочем, сомневаюсь ;-) ) то это значит что они всего-лишь импортировали часть libc функций (со всеми архитектурными зависимостями) в компилятор в inline виде, что для embedded систем совсем не "good idea"

> И правильно, нефиг совать то что я не прошу

а никто и не "сует", повторяю: не хочешь libc - пиши memcpy и memcmp сам - медленные или глючные (или и то и другое) ;-)))

for (i = 0; i < sz; i++) *dest++ = *src++;