Re: gcc прототипы встроенных (вернее необходимых) функций
В Fri, 21 Oct 2011 12:12:18 +0400
"Dmitry E. Oboukhov" пишет:
> есть gcc. по некоторым причинам не можем использовать stdlib и libgcc.
> стартап код свой итп
>
> если в проекте написать
>
> struct s_a {
> int a;
> int b;
> ...
> };
>
> struct s_a c, d;
>
> ...
>
> c = d;
>
> то будет неявно вызвана функция memcpy и если таковой в проекте нет,
> то линкер будет ругаться.
>
> ну положим ман на memcpy есть и мы ее написали.
>
> двигаемся дальше
>
> int a, b;
>
> ...
>
> d = a / b;
>
> процессор не умеет деления, поэтому
> ругается что нет функций __aeabi_uidivmod __aeabi_idivmod
>
> и вот вопрос, а где в документации посмотреть прототипы этих функций?
Наверное это что-то общее. Вот в pdf для ARMов.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0043c/index.html
--
Best Regards,
Yuri Kozlov
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111021125239.7aeba...@keeper.home.local
Re: gcc прототипы встроенных (вернее необходимых) функций
21 октября 2011 г. 15:12 пользователь Dmitry E. Oboukhov написал: > есть gcc. по некоторым причинам не можем использовать stdlib и libgcc. > стартап код свой итп эмбедщики, так бы сразу и сказали. > то будет неявно вызвана функция memcpy и если таковой в проекте нет, > то линкер будет ругаться. > процессор не умеет деления, поэтому > ругается что нет функций __aeabi_uidivmod __aeabi_idivmod > > и вот вопрос, а где в документации посмотреть прототипы этих функций? В исходниках gcc.
Re: gcc прототипы встроенных (вернее необходимых) функций
On Fri, Oct 21, 2011 at 12:12:18PM +0400, Dmitry E. Oboukhov wrote: > двигаемся дальше > > int a, b; > > ... > > d = a / b; > > процессор не умеет деления, поэтому > ругается что нет функций __aeabi_uidivmod __aeabi_idivmod > > и вот вопрос, а где в документации посмотреть прототипы этих функций? http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043c/IHI0043C_rtabi.pdf ? -- WBR, wRAR signature.asc Description: Digital signature
Re: GCC генерирует неправи льный код?
On 2010.03.15 20:57, Serhiy Storchaka wrote: Oleksandr Gavenko wrote: Недавно же стала доступна "The New C Standard. An Economicand Cultural Commentary" http://www.knosof.co.uk/cbook/cbook.html Очень понравился список в разделе Tools. Особенно первый пункт. Который на http://www.redhat.com/ указывает? Мне понравился Epsilon - http://www.lugaru.com/ Зачем платить за недоЕмакс? -- С уважением, Александр Гавенко. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9f94ba.4020...@bifit.com.ua
Re: GCC генерирует неправильный код?
Oleksandr Gavenko wrote: > Недавно же стала доступна > > "The New C Standard. An Economicand Cultural Commentary" > > http://www.knosof.co.uk/cbook/cbook.html Очень понравился список в разделе Tools. Особенно первый пункт. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hnlvtm$u2...@dough.gmane.org
Re: GCC генерирует неправильный код?
Dmitry Nezhevenko wrote: > Нет, это то что выдает sizeof(). Туда, например, можно безопасно положить > указатель. Разве? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hnlvjj$u2...@dough.gmane.org
Re: GCC генерирует непр авильный код?
On 14.03.2010 14:24, Василий Дьяконов wrote: > переменную не инициализировать, то в ней - мусор, который полностью не > перезаписыватся fscanf'ом. btw, просто присвоить 0 перед scanf НЕДОСТАТОЧНО. На big endian оно сломается. Надо таки использовать совместимый формат и тип (или поменять тип на unsigned int, или поменять формат на %zu [C99]) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hnksor$m0...@dough.gmane.org
Re: GCC генерирует непр авильный код?
On 2010.03.15 at 09:31:13 +0200, Oleksandr Gavenko wrote: >> Мне почему-то всегда казалось, что size_t -- это unsigned int. Надо >> найти ту книгу Шилда, по которой я учил Си, тогда не было ни Си99, ни >> АМД 64 бит. >> > > До 2005 учить Си надо было по The C Programming Language (aka "K&R"). И сейчас УЧИТЬ надо по ней. В сочетании с "The Unix Programming Enironment" Кернигана и Пайка. > Недавно же стала доступна > > "The New C Standard. An Economicand Cultural Commentary" А это - не для того чтобы учить, это для того чтобы прочитать, уже выучив, и подкорректировать представления. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100315083532.ga25...@wagner.pp.ru
Re: GCC генерирует неправи льный код?
On 2010.03.14 15:20, Hleb Valoshka wrote: On 3/14/10, Ekimov Alexandr wrote: fscanf(f, "%u",&n); Я с С не знаю, но знаком чуток с С++. Скорее всего ошибка в вашем коде, gcc лажает редко. вы объявляете переменную типа size_t, а потом fscanf говорите, что она unsigned int. Для AMD64 size_t будет иметь размер 64 бита(как и указатели) ,а unsigned int 32 бита. Проверьте это. Мне почему-то всегда казалось, что size_t -- это unsigned int. Надо найти ту книгу Шилда, по которой я учил Си, тогда не было ни Си99, ни АМД 64 бит. До 2005 учить Си надо было по The C Programming Language (aka "K&R"). Недавно же стала доступна "The New C Standard. An Economicand Cultural Commentary" http://www.knosof.co.uk/cbook/cbook.html Ну и FAQ с драфтами пролистать. -- С уважением, Александр Гавенко. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9de241.8090...@bifit.com.ua
Re: GCC генерирует непр авильный код?
> Виноват ли gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2, или что-то другое? Может > процессор не видит связи между участками кода и распаралеливает неправильно? У > меня amd64, возможно проблема в этом, т.к. параметры в функции передаются не > через стэк, а через регистры. > > Собрал для проверки mingw32 -- работает правильно. > http://en.wikipedia.org/wiki/Size_t Обратите внимание на то, что "The actual type of size_t is platform-dependent; a common mistake is to assume size_t is the same as unsigned int, which can lead to programming errors,[3] particularly as 64-bit architectures become more prevalent. According to the 1999 ISO C standard (C99), size_t is an unsigned integer type of at least 16 bit (see sections 7.17 and 7.18.3)." Вы же при вводе предполагаете, что size_t - unsigned int, при этом если переменную не инициализировать, то в ней - мусор, который полностью не перезаписыватся fscanf'ом. -- С уважением, Василий Дьяконов (Fireball) mailto:fireb...@programist.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9cc76e.7020...@programist.ru
Re: GCC генерирует непр авильный код?
On 2010.03.14 at 15:20:35 +0200, Hleb Valoshka wrote: > On 3/14/10, Ekimov Alexandr wrote: > >>fscanf(f, "%u", &n); > > Я с С не знаю, но знаком чуток с С++. Скорее всего ошибка в вашем коде, gcc > > лажает редко. вы объявляете переменную типа size_t, а потом fscanf > > говорите, > > что она unsigned int. Для AMD64 size_t будет иметь размер 64 бита(как и > > указатели) ,а unsigned int 32 бита. Проверьте это. > > Мне почему-то всегда казалось, что size_t -- это unsigned int. Надо > найти ту книгу Шилда, по которой я учил Си, тогда не было ни Си99, ни > АМД 64 бит. И выкинуть ее в помойку. А лучше сжечь, чтобы бомжи в помойке не нашли и не нахватались таких глупостей. В языке C никто никому ничего не обещал про размеры разных целых типов, кроме того что sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long). Архитектуры, на которых sizeof(char) == sizeof(short) == sizeof(long), насколько я помню, существовали задолго до того, как авторы подобных книг, считающие что "процессор может быть любым, если он совместим с i386", впервые в жизни увидели компьютер. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100314174226.gb25...@wagner.pp.ru
Re: GCC генерирует непр авильный код?
On Sun, Mar 14, 2010 at 10:21:54AM +0200, globus wrote:
> Вот кусок кода:
>
> size_t n /*= 0*/;
> /* тут пропущены проверки переданных в ф-ю параметров */
> fscanf(f, "%u", &n);
> printf("n==%u\n", n); /* для отладки */
> if ((n > K_MAX_ITEMS) || (n == 0))
> {
> printf("ERROR: n==%u\n", n); /* тжс */
> *error = K_BAD_SIZE;
> goto quit;
> }
>
> if ((stab = malloc(n * sizeof(Stab))) == NULL)
>
> Код проверки if ((n > K_MAX_ITEMS) || (n == 0)) работает некорректно! Т.е.
> fscanf читает из файла, напр., 3, printf его выводит, а if возвращает true,
> хотя должен false (K_MAX_ITEMS==1024)! Если убрать этот if, то malloc не может
> выделить память (для n==3 всего лишь 432 байта).
А вы собирайте вашу программу с -Wall, и GCC вам любезно расскажет, что
с вашим кодом не так.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100314154201.ga27...@skuller.net
Re: GCC генерирует непр авильный код?
On Sun, Mar 14, 2010 at 03:20:35PM +0200, Hleb Valoshka wrote: > > Я с С не знаю, но знаком чуток с С++. Скорее всего ошибка в вашем коде, gcc > > лажает редко. вы объявляете переменную типа size_t, а потом fscanf > > говорите, > > что она unsigned int. Для AMD64 size_t будет иметь размер 64 бита(как и > > указатели) ,а unsigned int 32 бита. Проверьте это. > > Мне почему-то всегда казалось, что size_t -- это unsigned int. Надо > найти ту книгу Шилда, по которой я учил Си, тогда не было ни Си99, ни > АМД 64 бит. > Нет, это то что выдает sizeof(). Туда, например, можно безопасно положить указатель. -- WBR, Dmitry signature.asc Description: Digital signature
Re: GCC генерирует неправильны й код?
On 3/14/10, Ekimov Alexandr wrote: >> fscanf(f, "%u", &n); > Я с С не знаю, но знаком чуток с С++. Скорее всего ошибка в вашем коде, gcc > лажает редко. вы объявляете переменную типа size_t, а потом fscanf > говорите, > что она unsigned int. Для AMD64 size_t будет иметь размер 64 бита(как и > указатели) ,а unsigned int 32 бита. Проверьте это. Мне почему-то всегда казалось, что size_t -- это unsigned int. Надо найти ту книгу Шилда, по которой я учил Си, тогда не было ни Си99, ни АМД 64 бит. -- http://375gnu.wordpress.com
Re: GCC генерирует неправильный код?
В сообщении от Воскресенье 14 марта 2010 11:21:54 автор globus написал: > Писал примитивную програмку на Си, курсач для знакомой, но это не важно. > Есть там кусок кода, который читает записи из файла: первая строка -- > количество записей, последующие -- собственно "полезные" записи. > > Вот кусок кода: > > size_t n /*= 0*/; > /* тут пропущены проверки переданных в ф-ю параметров */ > fscanf(f, "%u", &n); Я с С не знаю, но знаком чуток с С++. Скорее всего ошибка в вашем коде, gcc лажает редко. вы объявляете переменную типа size_t, а потом fscanf говорите, что она unsigned int. Для AMD64 size_t будет иметь размер 64 бита(как и указатели) ,а unsigned int 32 бита. Проверьте это.
Re: GCC генерирует непр авильный код?
On Sun, Mar 14, 2010 at 10:21:54AM +0200, globus wrote:
>
> Писал примитивную програмку на Си, курсач для знакомой, но это не важно. Есть
> там кусок кода, который читает записи из файла: первая строка -- количество
> записей, последующие -- собственно "полезные" записи.
>
> Вот кусок кода:
>
> size_t n /*= 0*/;
> /* тут пропущены проверки переданных в ф-ю параметров */
> fscanf(f, "%u", &n);
> printf("n==%u\n", n); /* для отладки */
> if ((n > K_MAX_ITEMS) || (n == 0))
> {
> printf("ERROR: n==%u\n", n); /* тжс */
> *error = K_BAD_SIZE;
> goto quit;
> }
>
> if ((stab = malloc(n * sizeof(Stab))) == NULL)
[skipped]
> Виноват ли gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2, или что-то другое?
Виноват программист, не понимающий разницы между unsigned int и size_t.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100314113231.ga30...@kaiba.homelan
Re: GCC генерирует неправ ильный код?
globus <375...@gmail.com> writes:
>
> size_t n /*= 0*/;
> /* тут пропущены проверки переданных в ф-ю параметров */
> fscanf(f, "%u", &n);
> printf("n==%u\n", n); /* для отладки */
> if ((n > K_MAX_ITEMS) || (n == 0))
> {
> printf("ERROR: n==%u\n", n); /* тжс */
> *error = K_BAD_SIZE;
> goto quit;
> }
>
> if ((stab = malloc(n * sizeof(Stab))) == NULL)
>
> Код проверки if ((n > K_MAX_ITEMS) || (n == 0)) работает некорректно! Т.е.
> fscanf читает из файла, напр., 3, printf его выводит, а if возвращает true,
> хотя должен false (K_MAX_ITEMS==1024)! Если убрать этот if, то malloc не может
> выделить память (для n==3 всего лишь 432 байта).
>
> А если инициализировать n в 0 (в декларации, или перед fscanf), то всё
> работает
> правильно.
> Виноват ли gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2, или что-то другое?
Код делает ровно то, что в нём написано: записывает в половину
переменной значение, прочитанное из файла. А мусор во второй половине
переменной его трогать никто не просил. И о том, что написать там
хотели что-то другое, компилятор может только догадываться.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871vfnjg5u@sghpc.golosunov.pp.ru
Re: gcc vs g++
On Tue, 05.05.2009 17:28:54 , Oleksandr Gavenko wrote: > Тихон Тарнавский wrote: >>> Заранее спасибо. >> t:~$ gcc -o tmp/test tmp/test.c >> /tmp/ccxBRvaA.o: In function `main': >> test.c:(.text+0x21): undefined reference to `ceil' >> collect2: выполнение ld завершилось с кодом возврата 1 >> t:~$ gcc -lm -o tmp/test tmp/test.c >> t:~$ >> > Оу, оу, оу - СЕРЕЗНАЯ ошибка Спасибо. Ошибка механическая на самом деле: вместо просто "вверх" нажал автоматически gcc"вверх" -- и курсор вместо конца аргументов оказался в их начале. -- С уважением, Тихон Тарнавский. http://linuxforum.ru http://posix.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: gcc vs g++
Тихон Тарнавский wrote: Заранее спасибо. t:~$ gcc -o tmp/test tmp/test.c /tmp/ccxBRvaA.o: In function `main': test.c:(.text+0x21): undefined reference to `ceil' collect2: выполнение ld завершилось с кодом возврата 1 t:~$ gcc -lm -o tmp/test tmp/test.c t:~$ Оу, оу, оу - СЕРЕЗНАЯ ошибка, читаем класический труд, посвященный этой одной из миллиарда штучек, о которой надо знать http://webpages.charter.net/ppluzhnikov/linker.html -- С уважением, Александр Гавенко. Компания "БИФИТ". Сайт: www.bifit.com.ua Тел:+38 (0562) 23-23-14, 23-31-00 E-mail: gave...@bifit.com.ua -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: gcc vs g++
On Tue, May 05, 2009 at 02:01:36PM +0400, Vasil'ev Michail wrote: > -->gcc -o test test.c > /tmp/cc41kOdl.o: In function `main': > test.c:(.text+0x21): undefined reference to `ceil' > collect2: ld returned 1 exit status NAME ceil, ceilf, ceill - ceiling function: smallest integral value not less than argument SYNOPSIS #include double ceil(double x); float ceilf(float x); long double ceill(long double x); Link with -lm. ^ > Почему этот код не компилируется? При этом > g++ -o test test.c > работает нормально. g++ подключает libm самостоятельно вместе со своим C++-рантаймом. -- Andrey V. Kiselev -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: gcc vs g++
On Tue, 05.05.2009 14:01:36 , Vasil'ev Michail wrote:
> Здравствуйте!
>
> Возникла странная проблема.
>
> --(~/calc_with_fedotchev/calc/experimental)--
> -->cat test.c
> #include
> #include
>
> int main()
> {
> double res;
> double inp = 3.1415;
> res = ceil(inp);
> return 0;
> }
> --(~/calc_with_fedotchev/calc/experimental)--
> -->gcc -o test test.c
> /tmp/cc41kOdl.o: In function `main':
> test.c:(.text+0x21): undefined reference to `ceil'
> collect2: ld returned 1 exit status
>
> Почему этот код не компилируется? При этом
> g++ -o test test.c
> работает нормально. Debian Lenny 5.0.1, gcc из репозитория.
> В чём может быть проблема?
>
> Заранее спасибо.
t:~$ gcc -o tmp/test tmp/test.c
/tmp/ccxBRvaA.o: In function `main':
test.c:(.text+0x21): undefined reference to `ceil'
collect2: выполнение ld завершилось с кодом возврата 1
t:~$ gcc -lm -o tmp/test tmp/test.c
t:~$
--
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: gcc vs g++
Twas brillig at 14:01:36 05.05.2009 UTC+04 when dlia-sp...@mail.ru did gyre and gimble: VM> Почему этот код не компилируется? -lm В мане написано. --
Re: gcc-2.96
On Mon, Oct 09, 2006 at 12:10:05PM +0400, Max Dmitrichenko wrote: > В сообщении от 9 Октябрь 2006 11:59 Yauhen Kharuzhy написал(a): > > > > > > Может кто подскажет где можно найти gcc 2.96? > > > Или собрать его из SRPM > > > > А можно поинтересоваться задачей, требующей именно 2.96? > > Ну нужно человеку и всё. Если допустим есть проект, который годами > писался с использованием 2.9x, то скомпилить его 4.1-ым - это отдельная > задача со своей трудоемкостью, а главное не факт, что оно потом будет > нахаляву работать. Неговоря о том, что последние gcc невероятно тормозные > и жадные до памяти, по сравнению с gcc-2.95. Так что если оптимальность > кода не критична, то есть определенный смак от старого gcc. Просто именно 2.96 --- это странно. Хотя ответ уже получен, что нужно собрать либу для редхата. -- Yauhen Kharuzhy jekhor _at_ gmail.com JID: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-2.96
В сообщении от 9 Октябрь 2006 11:59 Yauhen Kharuzhy написал(a): > > > > Может кто подскажет где можно найти gcc 2.96? > > Или собрать его из SRPM > > А можно поинтересоваться задачей, требующей именно 2.96? Ну нужно человеку и всё. Если допустим есть проект, который годами писался с использованием 2.9x, то скомпилить его 4.1-ым - это отдельная задача со своей трудоемкостью, а главное не факт, что оно потом будет нахаляву работать. Неговоря о том, что последние gcc невероятно тормозные и жадные до памяти, по сравнению с gcc-2.95. Так что если оптимальность кода не критична, то есть определенный смак от старого gcc. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-2.96
Hi Yauhen, * Yauhen Kharuzhy <[EMAIL PROTECTED]> * 2006-10-09 11:01: > > Или собрать его из SRPM > > А можно поинтересоваться задачей, требующей именно 2.96? Собрать C++ so под RH 7.3. -- Best regards, Sergey Chumakov 2:450/77[.43] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-2.96
Hi Nefedov.Yuri, * [EMAIL PROTECTED] <[EMAIL PROTECTED]> * 2006-10-09 10:56: > >Может кто подскажет где можно найти gcc 2.96? > >Или собрать его из SRPM > Вообще-то имеется > debian/pool/main/g/gcc-2.96/ > Вот там и взять и собрать. Попробую конечно. Только настораживает, что .deb собирается только под ia64. -- Best regards, Sergey Chumakov 2:450/77[.43] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-2.96
On Mon, Oct 09, 2006 at 10:21:06AM +0300, Sergey Chumakov wrote: > Hi All, > > Может кто подскажет где можно найти gcc 2.96? > Или собрать его из SRPM А можно поинтересоваться задачей, требующей именно 2.96? -- Yauhen Kharuzhy jekhor _at_ gmail.com JID: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-2.96
On Mon, 9 Oct 2006, Sergey Chumakov wrote: Hi All, Может кто подскажет где можно найти gcc 2.96? Или собрать его из SRPM Вообще-то имеется debian/pool/main/g/gcc-2.96/ Вот там и взять и собрать. Успехов. Юра.
Re: gcc-2.95 vs gcc-3.x
Привет, я решил проблему немного по-другому: прочитал тут: http://community.core-sdi.com/~juliano/dtors-ru.html про __attribute__ ((constructor)) и инициализировал в конструкторе. Не знаю только, это правильно или нет. Интересно, что в предыдущем примере не инициализит только как static. Андрей - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Thursday, May 26, 2005 11:27 AM Subject: Re: gcc-2.95 vs gcc-3.x > On Thu, 26 May 2005, Andrei Emeltchenko wrote: > > > Hi, > > sorry for this post, but somehow it is self-explained > > > ... skip > > > => gcc-3.2 -pedantic init_test.c > init_test.c:20: warning: obsolete use of designated initializer with `:' > init_test.c:21: warning: obsolete use of designated initializer with `:' > init_test.c:22: warning: ISO C89 forbids compound literals > init_test.c:22: warning: ISO C forbids casts to union type > init_test.c:22: initializer element is not constant > init_test.c:22: (near initialization for `union_table[0]') > > comment the line with (union _union1) > > => gcc-3.2 -pedantic init_test.c > init_test.c:20: warning: obsolete use of designated initializer with `:' > init_test.c:21: warning: obsolete use of designated initializer with `:' > init_test.c:22: warning: ISO C89 forbids compound literals > > Does it work? > Yura. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-2.95 vs gcc-3.x
On Thu, 26 May 2005, Andrei Emeltchenko wrote: Hi, sorry for this post, but somehow it is self-explained ... skip => gcc-3.2 -pedantic init_test.c init_test.c:20: warning: obsolete use of designated initializer with `:' init_test.c:21: warning: obsolete use of designated initializer with `:' init_test.c:22: warning: ISO C89 forbids compound literals init_test.c:22: warning: ISO C forbids casts to union type init_test.c:22: initializer element is not constant init_test.c:22: (near initialization for `union_table[0]') comment the line with (union _union1) => gcc-3.2 -pedantic init_test.c init_test.c:20: warning: obsolete use of designated initializer with `:' init_test.c:21: warning: obsolete use of designated initializer with `:' init_test.c:22: warning: ISO C89 forbids compound literals Does it work? Yura. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-2.95 vs gcc-3.x
Hi,
sorry for this post, but somehow it is self-explained
- Original Message -
From: "Andrei Emeltchenko" <[EMAIL PROTECTED]>
To:
Sent: Thursday, May 26, 2005 9:57 AM
Subject: gcc-2.95 vs gcc-3.x
gcc-2.95
gcc-3.4
---
[EMAIL PROTECTED]:gcc-bug$ gcc-3.4 init-test.c
init-test.c:23: error: initializer element is not constant
init-test.c:23: error: (near initialization for `union_table[0]')
[EMAIL PROTECTED]:gcc-bug$ gcc-2.95 init-test.c
---
[EMAIL PROTECTED]:gcc-bug$ cat init-test.c
struct _struct1 {
int i;
int j;
};
struct _struct2 {
int a;
int b;
};
union _union1 {
struct _struct1 struct1;
struct _struct2 struct2;
};
static union _union1 union_table[] = {
(union _union1)
(struct _struct1)
{
i: 1,
j: 2,
},
};
int main(void) {
return 0;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-2.95 vs gcc-3.x
Hi,
sorry for this post, but somehow it is self-explained
- Original Message -
From: "Andrei Emeltchenko" <[EMAIL PROTECTED]>
To:
Sent: Thursday, May 26, 2005 9:57 AM
Subject: gcc-2.95 vs gcc-3.x
gcc-2.95
gcc-3.4
---
[EMAIL PROTECTED]:gcc-bug$ gcc-3.4 init-test.c
init-test.c:23: error: initializer element is not constant
init-test.c:23: error: (near initialization for `union_table[0]')
[EMAIL PROTECTED]:gcc-bug$ gcc-2.95 init-test.c
---
[EMAIL PROTECTED]:gcc-bug$ cat init-test.c
struct _struct1 {
int i;
int j;
};
struct _struct2 {
int a;
int b;
};
union _union1 {
struct _struct1 struct1;
struct _struct2 struct2;
};
static union _union1 union_table[] = {
(union _union1)
(struct _struct1)
{
i: 1,
j: 2,
},
};
int main(void) {
return 0;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc bug?
On 2004.11.18 at 14:25:17 +0300, Dmitry E. Oboukhov wrote: > > Разработчиком пакета задумано, что /usr/bin/gcc в sarge показывает на > > 3.3. Переставление ее - руками ли, ногами ли, - за счет юзера, > > разработчики дистрибутива в этом случае багрепорты вправе не > > принимать... > а править мейк тоже нехорошо (пакет ведь собираем, а на другой системе > могут не пересобрать) > и как быть? В таких размерах править - CC=gcc-3.4 перед configure в debian/rules - вполне допустимая правка. Которые берутся на другой системе собирать, должны быть подготовлены к тому, чтобы подобные вещи учитывать.
Re: gcc bug?
Petrov Dmithriy -> debian-russian@lists.debian.org @ Thu, 18 Nov 2004 21:53:26 +0300: PD> Я чего-то не понимаю. Зачем всё-таки нужен char data[0], почему не PD> использовать char *data? char data[0] имеет с раздачи правильный адрес - сразу за включающей его структурой. char *data надо еще отдельно инициализировать. -- Artem Chuprina RFC2822: <[EMAIL PROTECTED]>, FIDO: 2:5020/122.256, Jabber: [EMAIL PROTECTED]
Re: gcc bug?
> --
> | flags |
> ||
> | length |
> ||
> | data |
> | |
> --
>
> struct pkt
> {
> uint32_t flags;
> uint32_t length;
> chardata[0];// data[1] для старых компиляторов
> };
>
>
> struct pkt* create_pkt( size_t data_length )
> {
> struct pkt* pkt =
> (struct pkt*) malloc( sizeof(struct pkt) + data_length );
>
> if (pkt != NULL)
> {
> pkt->flags = PKT_NODELAY;
> pkt->length = data_length;
> memset( pkt->data, 0, data_length );
> pkt->data[4] = 'r';
> pkt->data[5] = 't';
> pkt->data[6] = 'f';
> pkt->data[7] = 'm';
> }
>
> returm pkt;
> }
>
>
> Код непереносим, поскольку sizeof(struct pkt) будет давать разные
> значения даже для разных версий gcc, но здесь мы не об этом.
>
> Разумеется, это можно сделать и другими способами, но эстетическое
> чувство программистов вынуждает их желать работать с данными пакета
> обращаясь к члену структуры (так код лучше выглядит), а не извращаясь с
> указателями и кастами struct в char.
>
> До "изобретения" массивов с нулевой длиной приходилось пользоваться
> массивами с единичной длиной.
это ужасно!
я начинаю понимать отчего так много глючных программ на свете :-\
Re: gcc bug?
On Thursday 18 November 2004 16:59, Dmitry A. Fedorov wrote:
> On Thu, 18 Nov 2004, Dmitry E. Oboukhov wrote:
> > в чем смысл масива с нулевой длиной кроме как использование
> > идентификатора как указателя?
> > можете привести пример?
> struct pkt
> {
> uint32_t flags;
> uint32_t length;
> chardata[0];// data[1] для старых компиляторов
> };
> struct pkt* create_pkt( size_t data_length )
> {
> struct pkt* pkt =
> (struct pkt*) malloc( sizeof(struct pkt) + data_length );
>
> if (pkt != NULL)
> {
> pkt->flags = PKT_NODELAY;
> pkt->length = data_length;
> memset( pkt->data, 0, data_length );
> pkt->data[4] = 'r';
> pkt->data[5] = 't';
> pkt->data[6] = 'f';
> pkt->data[7] = 'm';
> }
>
> returm pkt;
> }
>
Я чего-то не понимаю. Зачем всё-таки нужен char data[0], почему не
использовать char *data?
Re: gcc bug?
On Thu, 18 Nov 2004, Dmitry E. Oboukhov wrote:
> в чем смысл масива с нулевой длиной кроме как использование
> идентификатора как указателя?
> можете привести пример?
> C не поддерживает динамическое изменение размеров массива и где можно
> применить массив с нулевой длиной я понять не могу
--
| flags |
||
| length |
||
| data |
| |
--
struct pkt
{
uint32_t flags;
uint32_t length;
chardata[0];// data[1] для старых компиляторов
};
struct pkt* create_pkt( size_t data_length )
{
struct pkt* pkt =
(struct pkt*) malloc( sizeof(struct pkt) + data_length );
if (pkt != NULL)
{
pkt->flags = PKT_NODELAY;
pkt->length = data_length;
memset( pkt->data, 0, data_length );
pkt->data[4] = 'r';
pkt->data[5] = 't';
pkt->data[6] = 'f';
pkt->data[7] = 'm';
}
returm pkt;
}
Код непереносим, поскольку sizeof(struct pkt) будет давать разные
значения даже для разных версий gcc, но здесь мы не об этом.
Разумеется, это можно сделать и другими способами, но эстетическое
чувство программистов вынуждает их желать работать с данными пакета
обращаясь к члену структуры (так код лучше выглядит), а не извращаясь с
указателями и кастами struct в char.
До "изобретения" массивов с нулевой длиной приходилось пользоваться
массивами с единичной длиной.
> struct
> {
> unsigned char byte[0];
>
> int data1;
> char data2;
> ...
> } a;
> чтобы обращаться к a.data1 как к a.byte[0], a.byte[1]... ?
Фу!
> и что компилятор ТАКОЕ допускает?!
В языке C индексы и границы массивов не контролируются, оставляя это на
совести программиста.
> > Если виртуальная память закончилась, она ненастоящая.
> наверно китайская подделка?
Виртуальная память - такой вид памяти, чъе происхождение
нисколько не влияет на ее качество.
--
Если уж гайка есть, она должна быть затянута до конца
Re: gcc bug?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 18 Nov 2004
16:08:43 +0300:
>> > в смысле компилятор будет ругаться на применение любого индекса с ним?
>> > или что?
>>
>> Не обязан.
>>
>> Эту конструкцию применяют обычно в конце структур заголовок - данные,
>> чтобы можно было сослаться на начало данных без извращений с адресной
>> арифметикой.
DEO> то есть что-то вроде
DEO> struct
DEO> {
DEO> unsigned char byte[0];
DEO> int data1;
DEO> char data2;
DEO> ...
DEO> } a;
DEO> чтобы обращаться к a.data1 как к a.byte[0], a.byte[1]... ?
Нет. struct {
int data1;
char data2;
unsigned char byte[0];
}
и дальше в памяти расположены собственно данные из этого byte, а сколько
их - знает только приложение.
DEO> и что компилятор ТАКОЕ допускает?!
Ну да. Пол-винды так написано, например.
--
Artem Chuprina
RFC2822: <[EMAIL PROTECTED]>, FIDO: 2:5020/122.256, Jabber: [EMAIL PROTECTED]
Re: gcc bug?
> DEO> я сейчас просто пропатчил пакет до того, что он 3.3 собирается, но он > DEO> собирается 3.4 и не патченный, причем те конструкции на которых валится > DEO> 3.3 3.4 не считает ошибочными > DEO> то есть у меня сейчас получился пакет с жесткой зависимостью на 3.4 > > Почему бы и нет? Раз от плюсовых библиотек 3.4 он все равно зависит? кроме глюков компилера в данном случае 3.4 не нужен кроме того я проверил - все собирается на 2.95 и 3.0
Re: gcc bug?
> > а править мейк тоже нехорошо (пакет ведь собираем, а на другой системе
> > могут не пересобрать)
> > и как быть?
>
> make CC=gcc3.4 CFLAGS='-pipe -O3 -g0 -w' и так далее в debian/rules
>
> configure из среды берет или также как make в зависимости от версии.
>
> Наличие gcc3 проверять перед тем.
>
> > PPS: кстати, знатоки плюсов, объясните мне смысл конструкции:
> > int a[0]={};
> >
> > это что просто указатель, который можно юзать только как указатель?
>
> Это не плюсы, это C.
>
> Это массив с нулевой длиной и его инициализация.
>
> Указатели и массивы - совсем разные вещи. Путаница у вас "классическая",
> хорошо известная.
то что массив я вижу
я не понимаю смысла
в чем смысл масива с нулевой длиной кроме как использование
идентификатора как указателя?
можете привести пример?
C не поддерживает динамическое изменение размеров массива и где можно
применить массив с нулевой длиной я понять не могу
>
> > в смысле компилятор будет ругаться на применение любого индекса с ним?
> > или что?
>
> Не обязан.
>
> Эту конструкцию применяют обычно в конце структур заголовок - данные,
> чтобы можно было сослаться на начало данных без извращений с адресной
> арифметикой.
то есть что-то вроде
struct
{
unsigned char byte[0];
int data1;
char data2;
...
} a;
чтобы обращаться к a.data1 как к a.byte[0], a.byte[1]... ?
и что компилятор ТАКОЕ допускает?!
по моему это большее извращение чем ((unsigned char *)&a)[index]
> Если виртуальная память закончилась, она ненастоящая.
наверно китайская подделка?
;)
Re: gcc bug?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 18 Nov 2004 14:25:17 +0300: DEO> я сейчас просто пропатчил пакет до того, что он 3.3 собирается, но он DEO> собирается 3.4 и не патченный, причем те конструкции на которых валится DEO> 3.3 3.4 не считает ошибочными DEO> то есть у меня сейчас получился пакет с жесткой зависимостью на 3.4 Почему бы и нет? Раз от плюсовых библиотек 3.4 он все равно зависит? -- Artem Chuprina RFC2822: <[EMAIL PROTECTED]>, FIDO: 2:5020/122.256, Jabber: [EMAIL PROTECTED]
Re: gcc bug?
On Thu, 18 Nov 2004, Dmitry E. Oboukhov wrote:
> а править мейк тоже нехорошо (пакет ведь собираем, а на другой системе
> могут не пересобрать)
> и как быть?
make CC=gcc3.4 CFLAGS='-pipe -O3 -g0 -w' и так далее в debian/rules
configure из среды берет или также как make в зависимости от версии.
Наличие gcc3 проверять перед тем.
> PPS: кстати, знатоки плюсов, объясните мне смысл конструкции:
> int a[0]={};
>
> это что просто указатель, который можно юзать только как указатель?
Это не плюсы, это C.
Это массив с нулевой длиной и его инициализация.
Указатели и массивы - совсем разные вещи. Путаница у вас "классическая",
хорошо известная.
> в смысле компилятор будет ругаться на применение любого индекса с ним?
> или что?
Не обязан.
Эту конструкцию применяют обычно в конце структур заголовок - данные,
чтобы можно было сослаться на начало данных без извращений с адресной
арифметикой.
--
Если виртуальная память закончилась, она ненастоящая.
Re: gcc bug?
> >> >> 3.3 - да. В 3.4 пофиксено. Так что багрепорт можно уже не посылать.
> >> DEO> я поставил 3.4.2 и он тоже падает
> >>
> >> Он не падает. Он честно ругается, что так писать нельзя.
> >> gcc-3.4 --version
> >> gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-2)
> >> Copyright (C) 2004 Free Software Foundation, Inc.
> >> This is free software; see the source for copying conditions. There is NO
> >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> >>
> >> DEO> PS: а как менять в Дебиане версию gcc?
> >> DEO> update-alternatives похоже не про то или я что-то не допонял?
> >>
> >> Никак не менять. Разные версии gcc замечательно уживаются между собой,
> >> надо только указывать нужный компилятор. update-alternatives в данном
> >> случае будет только источником граблей из-за несовместимости 3.3 и 3.4
> >> по меньшей мере по плюсовым библиотекам.
> DEO> гм я не про то
> DEO> а про ссылку /usr/bin/gcc
> DEO> ее руками планируется переставлять на нужную версию?
>
> Разработчиком пакета задумано, что /usr/bin/gcc в sarge показывает на
> 3.3. Переставление ее - руками ли, ногами ли, - за счет юзера,
> разработчики дистрибутива в этом случае багрепорты вправе не
> принимать...
а править мейк тоже нехорошо (пакет ведь собираем, а на другой системе
могут не пересобрать)
и как быть?
я сейчас просто пропатчил пакет до того, что он 3.3 собирается, но он
собирается 3.4 и не патченный, причем те конструкции на которых валится
3.3 3.4 не считает ошибочными
то есть у меня сейчас получился пакет с жесткой зависимостью на 3.4
PPS: кстати, знатоки плюсов, объясните мне смысл конструкции:
int a[0]={};
это что просто указатель, который можно юзать только как указатель?
в смысле компилятор будет ругаться на применение любого индекса с ним?
или что?
Re: gcc bug?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 18 Nov 2004 02:06:09 +0300: >> >> 3.3 - да. В 3.4 пофиксено. Так что багрепорт можно уже не посылать. >> DEO> я поставил 3.4.2 и он тоже падает >> >> Он не падает. Он честно ругается, что так писать нельзя. >> gcc-3.4 --version >> gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-2) >> Copyright (C) 2004 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> DEO> PS: а как менять в Дебиане версию gcc? >> DEO> update-alternatives похоже не про то или я что-то не допонял? >> >> Никак не менять. Разные версии gcc замечательно уживаются между собой, >> надо только указывать нужный компилятор. update-alternatives в данном >> случае будет только источником граблей из-за несовместимости 3.3 и 3.4 >> по меньшей мере по плюсовым библиотекам. DEO> гм я не про то DEO> а про ссылку /usr/bin/gcc DEO> ее руками планируется переставлять на нужную версию? Разработчиком пакета задумано, что /usr/bin/gcc в sarge показывает на 3.3. Переставление ее - руками ли, ногами ли, - за счет юзера, разработчики дистрибутива в этом случае багрепорты вправе не принимать... -- Artem Chuprina <[EMAIL PROTECTED]> FIDO: 2:5020/122.256
Re: gcc bug?
> > Никак не менять. Разные версии gcc замечательно уживаются > > между собой, надо только указывать нужный компилятор. > > update-alternatives в данном случае будет только источником > > граблей из-за несовместимости 3.3 и 3.4 по меньшей мере по > > плюсовым библиотекам. > > А у нас разрулили... :) а с нестабильностью у вас так и не придумали чего делать ;)
Re: gcc bug?
> >> 3.3 - да. В 3.4 пофиксено. Так что багрепорт можно уже не посылать. > DEO> я поставил 3.4.2 и он тоже падает > > Он не падает. Он честно ругается, что так писать нельзя. > gcc-3.4 --version > gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-2) > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > DEO> PS: а как менять в Дебиане версию gcc? > DEO> update-alternatives похоже не про то или я что-то не допонял? > > Никак не менять. Разные версии gcc замечательно уживаются между собой, > надо только указывать нужный компилятор. update-alternatives в данном > случае будет только источником граблей из-за несовместимости 3.3 и 3.4 > по меньшей мере по плюсовым библиотекам. гм я не про то а про ссылку /usr/bin/gcc ее руками планируется переставлять на нужную версию?
Re: gcc bug?
On Wed, Nov 17, 2004 at 10:29:46PM +0300, Artem Chuprina wrote: > Никак не менять. Разные версии gcc замечательно уживаются > между собой, надо только указывать нужный компилятор. > update-alternatives в данном случае будет только источником > граблей из-за несовместимости 3.3 и 3.4 по меньшей мере по > плюсовым библиотекам. А у нас разрулили... :) -- WBR, Michael Shigorin <[EMAIL PROTECTED]> -- Linux.Kiev http://www.linux.kiev.ua/
Re: gcc bug?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Wed, 17 Nov 2004 20:51:32 +0300: >> 3.3 - да. В 3.4 пофиксено. Так что багрепорт можно уже не посылать. DEO> я поставил 3.4.2 и он тоже падает Он не падает. Он честно ругается, что так писать нельзя. gcc-3.4 --version gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-2) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. DEO> PS: а как менять в Дебиане версию gcc? DEO> update-alternatives похоже не про то или я что-то не допонял? Никак не менять. Разные версии gcc замечательно уживаются между собой, надо только указывать нужный компилятор. update-alternatives в данном случае будет только источником граблей из-за несовместимости 3.3 и 3.4 по меньшей мере по плюсовым библиотекам. -- Artem Chuprina RFC2822: <[EMAIL PROTECTED]>, FIDO: 2:5020/122.256, Jabber: [EMAIL PROTECTED]
Re: gcc bug?
> >> >> А вот если в одном
> >> >> - то да, надо сделать что просили.
> >> DEO> кто бы мне помог
> >> DEO> я в английском не настолько силен, чтобы письма писать
> >> DEO> (читать читаю, а вот формулировать...)
> >>
> >> DEO> собственно за этим в рассылку и обратился
> >>
> >> Ну, если читаешь, то в info gcc должно быть более подробное объяснение,
> >> что надо класть с багрепортом. Там и формулировать-то особо ничего не
> >> надо. Но в принципе, если ты соберешь все необходимые данные и напишешь
> >> письмо по-русски, я готов тебе его перевести. Мой английский тоже не
> >> ахти, но понять - поймут.
>
> DEO> Артем, если не трудно
> DEO> я тут немножко повозился с исходниками
> DEO> и несколько модифицировал текст, вызывающий вылет, вот он:
>
> DEO> начало файла
> DEO> static int vaulgens_kinds[0] = {
> DEO> };
> DEO> конец файла
>
> DEO> попробуй скомпилить повторится ли?
>
> 3.3 - да. В 3.4 пофиксено. Так что багрепорт можно уже не посылать.
я поставил 3.4.2 и он тоже падает
какой конкретно 3.4 работает?
PS: а как менять в Дебиане версию gcc?
update-alternatives похоже не про то или я что-то не допонял?
Re: gcc bug?
On Tue, 16 Nov 2004 17:47:26 +0300
"Dmitry E. Oboukhov" <[EMAIL PROTECTED]> wrote:
>кто нибудь собирал FreeHDL?
>http://freehdl.seul.org/
>http://cran.mit.edu/~enaroska/freehdl.tar.gz
>
>gcc 3.2, 3.3 стабильно падает в интернал-еррор и просит отправить
>отчет
>та же бага на генте (просил товарища попробовать собрать)
Чтобы собиралась поставь вместо 0 - 1 :)
static tree_kind vaulgens_kinds[1] = {
};
речь не об ошибка в программе, а о сабже
:)
Будет ли после этого работать программа -- не знаю :)
это я запланировал вечерком проделать
в туду так сказать
:)
Там ещё одна такая же и в одном месте const надо убрать.
Regards,
Yuri Kozlov
Re: gcc bug?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Tue, 16 Nov 2004
17:26:49 +0300:
>> >> А вот если в одном
>> >> - то да, надо сделать что просили.
>> DEO> кто бы мне помог
>> DEO> я в английском не настолько силен, чтобы письма писать
>> DEO> (читать читаю, а вот формулировать...)
>>
>> DEO> собственно за этим в рассылку и обратился
>>
>> Ну, если читаешь, то в info gcc должно быть более подробное объяснение,
>> что надо класть с багрепортом. Там и формулировать-то особо ничего не
>> надо. Но в принципе, если ты соберешь все необходимые данные и напишешь
>> письмо по-русски, я готов тебе его перевести. Мой английский тоже не
>> ахти, но понять - поймут.
DEO> Артем, если не трудно
DEO> я тут немножко повозился с исходниками
DEO> и несколько модифицировал текст, вызывающий вылет, вот он:
DEO> начало файла
DEO> static int vaulgens_kinds[0] = {
DEO> };
DEO> конец файла
DEO> попробуй скомпилить повторится ли?
3.3 - да. В 3.4 пофиксено. Так что багрепорт можно уже не посылать.
--
Artem Chuprina
RFC2822: <[EMAIL PROTECTED]>, FIDO: 2:5020/122.256, Jabber: [EMAIL PROTECTED]
Re: gcc bug?
> >кто нибудь собирал FreeHDL?
> >http://freehdl.seul.org/
> >http://cran.mit.edu/~enaroska/freehdl.tar.gz
> >
> >gcc 3.2, 3.3 стабильно падает в интернал-еррор и просит отправить
> >отчет
> >та же бага на генте (просил товарища попробовать собрать)
>
> Чтобы собиралась поставь вместо 0 - 1 :)
>
> static tree_kind vaulgens_kinds[1] = {
> };
речь не об ошибка в программе, а о сабже
:)
>
> Будет ли после этого работать программа -- не знаю :)
это я запланировал вечерком проделать
в туду так сказать
:)
Re: gcc bug?
On Tue, 16 Nov 2004 01:04:46 +0300
"Dmitry E. Oboukhov" <[EMAIL PROTECTED]> wrote:
кто нибудь собирал FreeHDL?
http://freehdl.seul.org/
http://cran.mit.edu/~enaroska/freehdl.tar.gz
gcc 3.2, 3.3 стабильно падает в интернал-еррор и просит отправить
отчет
та же бага на генте (просил товарища попробовать собрать)
Чтобы собиралась поставь вместо 0 - 1 :)
static tree_kind vaulgens_kinds[1] = {
};
Будет ли после этого работать программа -- не знаю :)
Regards,
Yuri Kozlov
Re: gcc bug?
> >> А вот если в одном
> >> - то да, надо сделать что просили.
> DEO> кто бы мне помог
> DEO> я в английском не настолько силен, чтобы письма писать
> DEO> (читать читаю, а вот формулировать...)
>
> DEO> собственно за этим в рассылку и обратился
>
> Ну, если читаешь, то в info gcc должно быть более подробное объяснение,
> что надо класть с багрепортом. Там и формулировать-то особо ничего не
> надо. Но в принципе, если ты соберешь все необходимые данные и напишешь
> письмо по-русски, я готов тебе его перевести. Мой английский тоже не
> ахти, но понять - поймут.
Артем, если не трудно
я тут немножко повозился с исходниками
и несколько модифицировал текст, вызывающий вылет, вот он:
начало файла
static int vaulgens_kinds[0] = {
};
конец файла
попробуй скомпилить повторится ли?
вот мой опыт:
dimka:[/home/dimka]$ g++ -o test.o test.cc
test.cc:2: internal compiler error: in tree_low_cst, at tree.c:3255
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.
dimka:[/home/dimka]$ gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-2)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
PPS: в исходниках конечно структуры а не int итп
но вылет точно такой же
PPPS: я бы конечно такое объявление не делал (в своей программе),
до меня трудно доходит зачем сие может понадобиться
но компилер на таком падать не должен
Re: gcc bug?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Tue, 16 Nov 2004 16:18:38 +0300: >> А вот если в одном >> - то да, надо сделать что просили. DEO> кто бы мне помог DEO> я в английском не настолько силен, чтобы письма писать DEO> (читать читаю, а вот формулировать...) DEO> собственно за этим в рассылку и обратился Ну, если читаешь, то в info gcc должно быть более подробное объяснение, что надо класть с багрепортом. Там и формулировать-то особо ничего не надо. Но в принципе, если ты соберешь все необходимые данные и напишешь письмо по-русски, я готов тебе его перевести. Мой английский тоже не ахти, но понять - поймут. -- Artem Chuprina RFC2822: <[EMAIL PROTECTED]>, FIDO: 2:5020/122.256, Jabber: [EMAIL PROTECTED]
Re: gcc bug?
> DEO> кто нибудь собирал FreeHDL? > DEO> http://freehdl.seul.org/ > DEO> http://cran.mit.edu/~enaroska/freehdl.tar.gz > > DEO> gcc 3.2, 3.3 стабильно падает в интернал-еррор и просит отправить отчет > DEO> та же бага на генте (просил товарища попробовать собрать) > > Он стабильно падает (для одного и того же компилятора) в одном и том же > месте? он стабильно падает на одном и том же месте для даже разных компиляторов (3.2, 3.3) и даже на другом дистрибутиве (какой там компилятор точно не знаю, имхо 3.3.4) > Ибо если в разных, но на одном и том же железе, то это скорее > всего, значит, что надо память по гарантии менять... > А вот если в одном > - то да, надо сделать что просили. кто бы мне помог я в английском не настолько силен, чтобы письма писать (читать читаю, а вот формулировать...) собственно за этим в рассылку и обратился
Re: gcc bug?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Tue, 16 Nov 2004 01:04:46 +0300: DEO> кто нибудь собирал FreeHDL? DEO> http://freehdl.seul.org/ DEO> http://cran.mit.edu/~enaroska/freehdl.tar.gz DEO> gcc 3.2, 3.3 стабильно падает в интернал-еррор и просит отправить отчет DEO> та же бага на генте (просил товарища попробовать собрать) Он стабильно падает (для одного и того же компилятора) в одном и том же месте? Ибо если в разных, но на одном и том же железе, то это скорее всего, значит, что надо память по гарантии менять... А вот если в одном - то да, надо сделать что просили. -- Artem Chuprina RFC2822: <[EMAIL PROTECTED]>, FIDO: 2:5020/122.256, Jabber: [EMAIL PROTECTED]
Re: gcc bug?
> gcc 3.2, 3.3 стабильно падает в интернал-еррор и просит отправить отчет Ну так отправь, раз просит. Баги в софте - они такие, пока никто не печётся, сами не исправляются ... Баги в компиляторе тут не исключение.
Re: gcc -s
10010100100100101::06.05.2004::011000100100100010000100010 Привет, Victor! > Удаляется отладочная информация, необходимая чтобы gdb по этому файлу > лазить. Если исходный файл собирался с -g то повлияет, и очень сильно. Если скомпилирована без опции -g все равно повлияет, хотя и не так сильно. Проверил на собственном опыте: gcc quest.c -o quest # размер бинарника 5.8 Кб gcc quest.c -o quest -g # размер бинарника 21 Кб gcc quest.c -o quest -s # пазмер бинарника 3.8 Кб Такое вот "маленькое" открытие я сегодня для себя совершил! :)) Тема закрыта. -- С уважением, php-coder (mailto:php-coder[at]ngs[dot]ru) Registered Linux User #327594 Debian 3.0 r2 (kernel 2.4.26) 010010010010010001010101100::Linux RuleZz!::10001001000100010001000111
Re: gcc -s
On 2004.05.05 at 12:46:27 +0700, php-coder wrote: > 10010100100100101::05.05.2004::011000100100100010000100010 > > Привет, Linuxоиды! > > Прочитал про опции компилятора > (http://www.sbor.net/linux-doc/lib/prog/gcc27/gcc1-2.html) > и возник один вопросик. > > "Опции Линковки > -s > Удаляет все символьные таблицы и информацию о перемещениях из > исполняемого файла." > > Не совсем понимаю что именно удаляется и скажется ли это как-то на > размере бинарника? Спасибо... Удаляется отладочная информация, необходимая чтобы gdb по этому файлу лазить. Если исходный файл собирался с -g то повлияет, и очень сильно. Эта опция эквивалентна вызову команды strip на скомпилированный бинарник. можно поэкспериментировать и убедиться.
Re: gcc
On Sat, 13 Mar 2004, Alex Riesen wrote: > > Схема построения загружаемого модуля, включающего куски, > > распространяемые без исходников такова: > > причём тут схема? Оно или работает как его написали, или нет. Хочу - > делаю с прокладками, хочу - с памперсами. Ругаться можно сколько угодно, > Так или иначе - что-то пойдёт криво, и надо будет перекомпилить _весь_ > драйвер с нужным компилятором, и командной строкой к нему, и набором > общесистемных параметров типа pe или smp, что, если разобраться, убивает > идею предкомпилированых драйверов нафиг. Вышеупомянутая схема с прокладкой как раз и позволяет им существовать в правильной форме. Для остальных проблем существуют package managers.
Re: gcc
Dmitry A. Fedorov, Sat, Mar 13, 2004 14:03:03 +0100: > On Sat, 13 Mar 2004, Alex Riesen wrote: > > > > Эту запись вставляет компилятор безо всякого участия со стороны линукса, > > > она есть в любом .o файле от gcc. > > > > я имел ввиду секцию .modinfo вообще и vermagic в частности. > > Схема построения загружаемого модуля, включающего куски, > распространяемые без исходников такова: > причём тут схема? Оно или работает как его написали, или нет. Хочу - делаю с прокладками, хочу - с памперсами. Ругаться можно сколько угодно, проконтролировать и запретить нельзя (да и не нужно). Что с системой уже не всё в порядке - юзер узнает (или по тому что система завалилась, или tainted увидит). Попытается жаловаться - ему скажут куда сходить. Второй раз он сам пошлёт тех писателей нафиг. И все довольны. А то, что памперс скомпилирован с правильным компилером, или весь драйвер - ничего не меняет. Технически. Лицензии никого не интересуют, если очень надо, а драйвера от хорошей жизни не пишут. Так или иначе - что-то пойдёт криво, и надо будет перекомпилить _весь_ драйвер с нужным компилятором, и командной строкой к нему, и набором общесистемных параметров типа pe или smp, что, если разобраться, убивает идею предкомпилированых драйверов нафиг. Так что если человек хочет помучаться (или кому-то хочется его помучать) - на здоровье.
Re: gcc
On Fri, Mar 12, 2004 at 01:06:42PM +0300, Victor B. Wagner wrote:
> > > AK> Во-первых, это имеет значение только в случае C++.
^^^
> > $ cat a.cpp
>
> > extern int test();
> >
> > int main ()
> > {
> > return test();
> > }
> >
> > $ cat b.cpp
> > int test()
> > {
> > return 0;
> > }
> >
> > $ g++-2.95 a.cpp -c -o a.o
> > $ g++-3.3 b.cpp -c -o b.o
> > $ g++-3.3 a.o b.o -o c.exe
> > a.o(.text+0x7): In function `main':
> > : undefined reference to `test(void)'
> > collect2: ld returned 1 exit status
> > $ g++-3.3 a.cpp -c -o a.o
> > $ g++-3.3 a.o b.o -o c.exe
>
> Это же C++. С++ не совместимо. А объяви ты эту фунцию test в обоих
> файлах как extern "C", или просто переименуй файлы в *.c - проблем не
> будет.
Виктор, читать надо внимательнее.
--
Andrey V. Kiselev
Home phone: +7 812 5274898 ICQ# 26871517
Re: gcc
On 2004.03.11 at 10:22:49 +0300, Andrey Kiselev wrote:
> On Wed, Mar 10, 2004 at 01:03:41PM +0300, Dmitry Skorinko wrote:
> > >> а для каких версий gcc требуется перекомпиляция? Ну то есть есть у
> > >> меня объектный файл, компильнутый допустим в Gcc 3.2.0 его к
> > >> объектам 2.95.3 прилинковать то прилинкуешь, только работать ниче не
> > >> будет.
> > AK> Во-первых, это имеет значение только в случае C++. Во-вторых, ты
> > AK> получишь ошибку на этапе линковки, а не во время исполнения.
> >
> > Ну вот прям щас взял и слинковал 2 объекта, скомпилированных в 3.2.2 с
> > одним, скомпилированным в 2.95.4 ..
> > типа тиго: ld -r a3.o b3.o c2.o -o d.o - нормально все..
>
> $ cat a.cpp
> extern int test();
>
> int main ()
> {
> return test();
> }
>
> $ cat b.cpp
> int test()
> {
> return 0;
> }
>
> $ g++-2.95 a.cpp -c -o a.o
> $ g++-3.3 b.cpp -c -o b.o
> $ g++-3.3 a.o b.o -o c.exe
> a.o(.text+0x7): In function `main':
> : undefined reference to `test(void)'
> collect2: ld returned 1 exit status
> $ g++-3.3 a.cpp -c -o a.o
> $ g++-3.3 a.o b.o -o c.exe
Это же C++. С++ не совместимо. А объяви ты эту фунцию test в обоих
файлах как extern "C", или просто переименуй файлы в *.c - проблем не
будет.
Re: gcc
On Wed, Mar 10, 2004 at 01:03:41PM +0300, Dmitry Skorinko wrote:
> >> а для каких версий gcc требуется перекомпиляция? Ну то есть есть у
> >> меня объектный файл, компильнутый допустим в Gcc 3.2.0 его к
> >> объектам 2.95.3 прилинковать то прилинкуешь, только работать ниче не
> >> будет.
> AK> Во-первых, это имеет значение только в случае C++. Во-вторых, ты
> AK> получишь ошибку на этапе линковки, а не во время исполнения.
>
> Ну вот прям щас взял и слинковал 2 объекта, скомпилированных в 3.2.2 с
> одним, скомпилированным в 2.95.4 ..
> типа тиго: ld -r a3.o b3.o c2.o -o d.o - нормально все..
$ cat a.cpp
extern int test();
int main ()
{
return test();
}
$ cat b.cpp
int test()
{
return 0;
}
$ g++-2.95 a.cpp -c -o a.o
$ g++-3.3 b.cpp -c -o b.o
$ g++-3.3 a.o b.o -o c.exe
a.o(.text+0x7): In function `main':
: undefined reference to `test(void)'
collect2: ld returned 1 exit status
$ g++-3.3 a.cpp -c -o a.o
$ g++-3.3 a.o b.o -o c.exe
> так различия только, когда 2 и 3??
Между 2.x и 3.x
--
Andrey V. Kiselev
Home phone: +7 812 5274898 ICQ# 26871517
Re: gcc
On Wed, Mar 10, 2004 at 12:06:34PM +0300, Dmitry Skorinko wrote: > а для каких версий gcc требуется перекомпиляция? Ну то есть есть у > меня объектный файл, компильнутый допустим в Gcc 3.2.0 его к > объектам 2.95.3 прилинковать то прилинкуешь, только работать ниче не > будет. Во-первых, это имеет значение только в случае C++. Во-вторых, ты получишь ошибку на этапе линковки, а не во время исполнения. -- Andrey V. Kiselev Home phone: +7 812 5274898 ICQ# 26871517
Re: gcc?
>В сообщении от 12 Июнь 2003 08:16 Yury Yurevich написал: <> >> Есть научная программа, которае нечто считает; стОит ли >> замарачиваться на вытягивание из сети gcc-3.2, даст ли это к-л >> преимущества по сравнению с gcc 2.95/3.0.4 на athlon/p4? >> Time-stepping? Ну 10% по скорости выполнения может даст. Скачай интелловский компилятор получишь >50%. Интеловский компилятор даже на атлоне обыгрывает например компилятор от Portland Gr >~ 20% rgds
Re: gcc?
В сообщении от 12 Июнь 2003 08:16 Yury Yurevich написал: > Hi, debian-russian! > > Господа, объясните мне, пожайлуста, объясните мне ситуацию с различными > версиями gcc. > > Итак, если есть проц (P4 или Athlon -- не важно, важно, что в > march/mcpu для gcc-2.95 нет упоминания о них), значит ли это что, при > компиляции я максимум добиваюсь оптимизации для абстрактного i686? на сколько я помню, под атлон оптимезация включается с помощью march/mcpu = K7 на gcc-2.95 такая опция есть. . . > > Есть научная программа, которае нечто считает; стОит ли > замарачиваться на вытягивание из сети gcc-3.2, даст ли это к-л > преимущества по сравнению с gcc 2.95/3.0.4 на athlon/p4? > > Теперь о компиляции ядра: почему его стоит собирать только с gcc-2.95?
Re: gcc?
îÅ ÚÎÁÀ. ÷ÞÅÒÁ ÓÏÂÉÒÁÌ 2.4.21-rc8 Ó ÐÏÍÏÝØÀ 3.3- ×Ó£ ïë. /
Re: gcc?
Доброго времени суток! Было дело, что 12 Июн 2003 в 09:16 Yury Yurevich писал(а): > Теперь о компиляции ядра: почему его стоит собирать только с gcc-2.95? Так почему же? -- Best regards, Yury Yurevich
Re: gcc?
On Fri, 13 Jun 2003, Yury Yurevich wrote: > Доброго времени суток! > Было дело, что 12 Июн 2003 в 12:07 > Yuri Nefedov писал(а): > > > По своему опыту работы с "научными программами" могу сказать, > > что опции компилятора вообще, а опции относящиеся к процессору > > в особенности, ничего не меняют (+/- 5% не в счет). > > Могу поспорить, поскольку для P4 для win-компилятора (vc6 vs. icc) > включение оптимизации дает прирост в 2-5 раз (!!), а для AthlonXP: ~1.5 > раза. В vc6 оптимизация под pentium и под скорость. Для IntelC > последовательно включались SSE1/2 (для атлона, соответственно, только > SSE1). > > Хотелось попробовать, какие скорости будет показывать gcc ;)) Может ли > включение флагов MMX/SSE/3DNow (AFAIK, появилились в gcc-3.2) на lin > аналогично увеличить скорость? > > И вопрос: если я поставлю оптимизацию под атлон (march, mcpu, 3dnow, > etc), то значит ли это, что откомпиленная прога не запуститься на p4? > Кстати, и есть ли разница в скорости выполнения проги при компиляции > share/static? > > P.S. Мерялось не на бенчмарках, а на "живых" приложениях ( а) Расчет > инерционных и фрикционных коэффициентов для уравнений Ланжевена в > трехмерной модели; б) расчет функционалов потенциальной энергии в модели > жидкой капли с диффузным краем в трехмерном случае [расчет небольшого > количества точек, ~2% от 396526]) ; влияние дисковой подсистемы > нивелировалось (измерения шли не со времени запуска программы, а со > времени подгрузки всех данных с винта); измерения производились > секундомером. > > P.P.S. Не малую роль играет фортран; за неимением intel fortran compiler > ;)) измерения не проводились. А правда, что g77 имеет такие же флаги > оптимизации, как и g++? > > -- > Best regards, Yury Yurevich > > Доброе утро, Yuri. Ну возможно я и "несколько преувеличил" :). Однако, надо помнить, что использование SSE1 и 3Dnow ускоряет только single-precision операции, (давненько мне такие программы не попадались). У 3Dnow есть еще неприятная особенность, что оно не придерживается стандартов IEEE для чисел с плавающей точкой. Как я помню, например, при делении на ноль не будет nan образовываться. То есть пользоваться конечно можно, но в 100% работающих программах. SSE2 - несколько лучше, но имеется оно только у P4, у которого FPU довольно слабый, мягко говоря. Честно говоря сам на них никогда не работал, не знаю. Очень руки чешутся попробовать athlon64, как там с fp дела обстоят. С переносимостью проблема. Как я понимаю, собрав с 3Dnow на P4 уже не запустишь, и т.д. Для g77 я обычно ставлю -O -funroll-loops -mcpu=i686 -malign-double Какие-то опции общие с g++, какие-то нет. В общем info g77 Успехов, Юра.
Re: gcc?
Доброго времени суток! Было дело, что 12 Июн 2003 в 12:07 Yuri Nefedov писал(а): > По своему опыту работы с "научными программами" могу сказать, > что опции компилятора вообще, а опции относящиеся к процессору > в особенности, ничего не меняют (+/- 5% не в счет). Могу поспорить, поскольку для P4 для win-компилятора (vc6 vs. icc) включение оптимизации дает прирост в 2-5 раз (!!), а для AthlonXP: ~1.5 раза. В vc6 оптимизация под pentium и под скорость. Для IntelC последовательно включались SSE1/2 (для атлона, соответственно, только SSE1). Хотелось попробовать, какие скорости будет показывать gcc ;)) Может ли включение флагов MMX/SSE/3DNow (AFAIK, появилились в gcc-3.2) на lin аналогично увеличить скорость? И вопрос: если я поставлю оптимизацию под атлон (march, mcpu, 3dnow, etc), то значит ли это, что откомпиленная прога не запуститься на p4? Кстати, и есть ли разница в скорости выполнения проги при компиляции share/static? P.S. Мерялось не на бенчмарках, а на "живых" приложениях ( а) Расчет инерционных и фрикционных коэффициентов для уравнений Ланжевена в трехмерной модели; б) расчет функционалов потенциальной энергии в модели жидкой капли с диффузным краем в трехмерном случае [расчет небольшого количества точек, ~2% от 396526]) ; влияние дисковой подсистемы нивелировалось (измерения шли не со времени запуска программы, а со времени подгрузки всех данных с винта); измерения производились секундомером. P.P.S. Не малую роль играет фортран; за неимением intel fortran compiler ;)) измерения не проводились. А правда, что g77 имеет такие же флаги оптимизации, как и g++? -- Best regards, Yury Yurevich
Re: gcc?
On Thu, 12 Jun 2003, Yury Yurevich wrote: > Hi, debian-russian! > > Господа, объясните мне, пожайлуста, объясните мне ситуацию с различными > версиями gcc. > > Итак, если есть проц (P4 или Athlon -- не важно, важно, что в > march/mcpu для gcc-2.95 нет упоминания о них), значит ли это что, при > компиляции я максимум добиваюсь оптимизации для абстрактного i686? > > Есть научная программа, которае нечто считает; стОит ли > замарачиваться на вытягивание из сети gcc-3.2, даст ли это к-л > преимущества по сравнению с gcc 2.95/3.0.4 на athlon/p4? > > Теперь о компиляции ядра: почему его стоит собирать только с gcc-2.95? > > -- > Best regards, Yury Yurevich > > Hi, По своему опыту работы с "научными программами" могу сказать, что опции компилятора вообще, а опции относящиеся к процессору в особенности, ничего не меняют (+/- 5% не в счет). Ну не умеют еще компиляторы мысли отгадывать. Если написано криво, и в цикле каждый раз вызывается никому не нужная функция... Часто подход к написанию, - главное что бы цифра вылезла, а будет это день считаться или пять минут.., - значит пора новую машину покупать. Общая кривизна кода близка к абсолютной. Правда, есть исключения в виде lapack, вернее blas, который специально оптимизируют под отдельные процессоры. Но тут опять скорее не компилятор важен, а нужную библиотеки надо найти. (Это в сторону atlas надо смотреть) С новым компилятором связываться стоит скорее не из-за скорости, а потому как, все равно рано или позно, на него перебираться прийдется. Плюс, к синтаксису (для с++) он более строгий, - смотришь ошибки сами собой вылезут. Удачи. Юра.
Re: gcc-default ->gcc-3.2
On Thu, 10 Apr 2003, Victor B. Wagner wrote: > On 2003.04.10 at 19:54:42 +0300, Pasha Kustov wrote: > > > Хочу сделать default-ными gcc-3.2 и g++-3.2. Есть ли более корректный > > способ вместо изменения цели ссылки /usr/bin/gcc.real??? > > -- > > Pasha Kustovmailto:[EMAIL PROTECTED] > > IATP System Administrator Assistant > > Можно в Makefile конкретного проекта в CFLAGS -V 3.2 > добавить. Только номер версии надо точный, который прописан в имени > соответствующей поддиректории /usr/lib/gcc-lib/i386-linux > > Не скажу что этот способ более корректный. Ну нет бы им сразу > через alternatives это сделать. Запостить что-ли им багу. Причем в оба > пакета сразу... > > Как то уже поднимался этот вопрос. Ответ был, что gcc-2.95 это "system compiler", a gcc-3.x - это "user compiler" и системный не может быть легко заменен. Слишком много от него зависит, а часть пакетов просто не будут с ним собираться. Возможно, сейчас ситуация изменилась, но все же идеологически правильно, не трогать системный компилятор. В конце концов, достаточно в путях прописать первой директорию, где лежит gcc-3.x и по умолчанию именно он и будет вызываться. Успехов. Юра
Re: gcc-default ->gcc-3.2
Привет, коллеги. On Thu, Apr 10, 2003 at 07:54:42PM +0300, Pasha Kustov wrote: > Хочу сделать default-ными gcc-3.2 и g++-3.2. Есть ли более корректный > способ вместо изменения цели ссылки /usr/bin/gcc.real??? Хороший повод собрать свой пакет :) Берёшь исходники gcc-defaults и расставляешь версии как нравится. В последних версиях из sid уже так, как хочешь, прописано. > Pasha Kustov mailto:[EMAIL PROTECTED] > IATP System Administrator Assistant Auf Wiederlesenophil aka Д-р Антикоммуний -- Oleg P. Philon http://gomelug.agava.ru/articles Linux Lab, Gomel, Belarus mailto:[EMAIL PROTECTED] http://anticommunist.narod.ru mailto:[EMAIL PROTECTED]
Re: gcc-default ->gcc-3.2
On 2003.04.10 at 19:54:42 +0300, Pasha Kustov wrote: > Хочу сделать default-ными gcc-3.2 и g++-3.2. Есть ли более корректный > способ вместо изменения цели ссылки /usr/bin/gcc.real??? > -- > Pasha Kustov mailto:[EMAIL PROTECTED] > IATP System Administrator Assistant Можно в Makefile конкретного проекта в CFLAGS -V 3.2 добавить. Только номер версии надо точный, который прописан в имени соответствующей поддиректории /usr/lib/gcc-lib/i386-linux Не скажу что этот способ более корректный. Ну нет бы им сразу через alternatives это сделать. Запостить что-ли им багу. Причем в оба пакета сразу...
Re: gcc-default ->gcc-3.2
В письме от 10 Апрель 2003 20:54 Pasha Kustov написал: > Хочу сделать default-ными gcc-3.2 и g++-3.2. Есть ли более корректный > способ вместо изменения цели ссылки /usr/bin/gcc.real??? изменение ссылки с помощью update-alternatives(8) ? -- Alexey Ozeritsky email1: [EMAIL PROTECTED] email2: [EMAIL PROTECTED] web: http://make-install.ifirst.ru | icq: UIN 52034320
Re: gcc and kernel in unstable
Hello Wartan Hachaturow, Once you wrote about "Re: gcc and kernel in unstable": > On Fri, Jan 10, 2003 at 11:07:45PM +0300, Alexander Kotelnikov wrote: > > > AC> Собственно вопрос - ядро (2.4.20) этим компилятором собирать можно - или > > AC> есть какие-то тонкости. Или на первое время оставить gcc-2.95 для сборки > > AC> ядра ? > > > > Можно. Иногда только им и можно. > > Это когда же "только им и можно"? ;) 2.4.20-pre7 -- Any statement is incorrect.
Re: gcc and kernel in unstable
On Fri, Jan 10, 2003 at 11:07:45PM +0300, Alexander Kotelnikov wrote: > AC> Собственно вопрос - ядро (2.4.20) этим компилятором собирать можно - или > AC> есть какие-то тонкости. Или на первое время оставить gcc-2.95 для сборки > AC> ядра ? > > Можно. Иногда только им и можно. Это когда же "только им и можно"? ;) -- Regards, Wartan. "Computers are not intelligent. They only think they are."
Re: gcc and kernel in unstable
On Saturday 11 January 2003 22:03, Andrey Nekrasov wrote: > > +++-- > > ii gcc 3.2.2-0The GNU C > > compiler. ii gcc-2.95 2.95.4-15 The GNU > > C compiler. > > > > Собственно вопрос - ядро (2.4.20) этим компилятором собирать можно - или > > есть какие-то тонкости. Или на первое время оставить gcc-2.95 для сборки > > ядра ? > > некоторые из 2.4.19/20pre вообще не собираются gcc-2.95, только 3.2.x А про какие-то из 2.4.х последние говорили, что они паникуют, если их собрать gcc 3.2 WBR Separator --- http://www.E-mail.ru - КСВЬХИ пНЯЯХИЯЙХИ АЕЯОКЮРМШИ ОНВРНБШИ ЯЕПБХЯ. лХМХЛСЛ ПЕЙКЮЛШ, ЙЮМЮК 100 ЛА/Я, ЪЫХЙ 10 лА, SMTP/POP3, ЮБРННРБЕРВХЙ, ГЮЫХРЮ НР ЯОЮЛЮ Х БХПСЯНБ, ОЕПЕЮДПЕЯЮЖХЪ, ОПНБЕПЙЮ НПТНЦПЮТХХ Х ЛМНЦНЕ ДПСЦНЕ.
Re: gcc and kernel in unstable
Hello Andrey Chernomyrdin, > +++-- > ii gcc 3.2.2-0The GNU C compiler. > ii gcc-2.95 2.95.4-15 The GNU C compiler. > > Собственно вопрос - ядро (2.4.20) этим компилятором собирать можно - или > есть какие-то тонкости. Или на первое время оставить gcc-2.95 для сборки > ядра ? некоторые из 2.4.19/20pre вообще не собираются gcc-2.95, только 3.2.x -- Any statement is incorrect.
Re: gcc and kernel in unstable
В письме от 10 Январь 2003 22:24 Michael Shigorin написал: > On Fri, Jan 10, 2003 at 10:07:38PM +0300, Alexey Ozeritsky wrote: > > у меня тут есть машина с SuSE8.1, там по-умолчанию gcc 3.2.0, > > вся система им собрана (включая ядро), работает всё отлично. > > У меня сейчас вся система 3.2.1 под i586 собрана. Сдается, не > настолько zippy, как 2.96/i586. Есть какие-то ощущения по > производительности? есть показания unixbench'а раньше на этой машине стоял SuSE7.3, ядро 2.4.16 из обновлений, компилятор gcc 2.95.3, всё собрано было под i486 (ядро под i586) unixbench показывал 255.5 SuSE8.1, ядро 2.4.19 из поставки дистрибутива, gcc 3.2, сборка под i586 результат - 316.7 -- Alexey Ozeritsky email1 [EMAIL PROTECTED] email2 [EMAIL PROTECTED] web http://make-install.by.ru icq UIN 52034320
Re: gcc and kernel in unstable
Andrey Chernomyrdin wrote: Собственно вопрос - ядро (2.4.20) этим компилятором собирать можно - или есть какие-то тонкости. Или на первое время оставить gcc-2.95 для сборки ядра ? Я с помощью 3.2 компилировал 2.4.19. Работает вполне: uptime > 30 days, load avg < 0.1 - на Pentium 133 в качестве рутера. Только у меня gcc и ядро были сконфигурированы вручную. -- Andrei Sosnin http://zzx.ath.cx
Re: gcc and kernel in unstable
> On Fri, 10 Jan 2003 19:23:38 +0300 > "AC" == Andrey Chernomyrdin <[EMAIL PROTECTED]> wrote: AC> AC> День добрый! AC> Вот после очередного обновления системы обнаружил что gcc по-умолчанию стал: AC> % gcc --version AC> gcc (GCC) 3.2.2 20021231 (Debian prerelease) AC> Copyright (C) 2002 Free Software Foundation, Inc. AC> This is free software; see the source for copying conditions. There is NO AC> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. AC> AC> % dpkg -l 'gcc*' AC> Desired=Unknown/Install/Remove/Purge/Hold AC> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed AC> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: AC> uppercase=bad) AC> ||/ Name Version AC> Description AC> +++-- AC> ii gcc 3.2.2-0The GNU C compiler. AC> ii gcc-2.95 2.95.4-15 The GNU C compiler. Хм.. а gcc-3.x нет? Странно. AC> Собственно вопрос - ядро (2.4.20) этим компилятором собирать можно - или AC> есть какие-то тонкости. Или на первое время оставить gcc-2.95 для сборки AC> ядра ? Можно. Иногда только им и можно. -- Alexander Kotelnikov Saint-Petersburg, Russia
Re: gcc and kernel in unstable
On Fri, Jan 10, 2003 at 10:07:38PM +0300, Alexey Ozeritsky wrote: > у меня тут есть машина с SuSE8.1, там по-умолчанию gcc 3.2.0, > вся система им собрана (включая ядро), работает всё отлично. У меня сейчас вся система 3.2.1 под i586 собрана. Сдается, не настолько zippy, как 2.96/i586. Есть какие-то ощущения по производительности? -- WBR, Michael Shigorin <[EMAIL PROTECTED]> -- Linux.Kiev http://www.linux.kiev.ua/
Re: gcc and kernel in unstable
В письме от 10 Январь 2003 19:23 Andrey Chernomyrdin написал: > Собственно вопрос - ядро (2.4.20) этим компилятором собирать можно - или > есть какие-то тонкости. Или на первое время оставить gcc-2.95 для сборки > ядра ? можно. у меня тут есть машина с SuSE8.1, там по-умолчанию gcc 3.2.0, вся система им собрана (включая ядро), работает всё отлично. -- Alexey Ozeritsky email1 [EMAIL PROTECTED] email2 [EMAIL PROTECTED] web http://make-install.by.ru icq UIN 52034320
Re: gcc-3.2
On Wed, Nov 13, 2002 at 04:34:46PM +0300, Yury Koshkaroff wrote: > Будет ли какой резон им систему пересобирать, в плане > производительности например ? Есть подозрение, что для ядра точно плохо, ну и в общем сдается, что 2.96 -- острее заточен. Вот так :-( (можно поискать на http://altlinux.ru/pipermail/devel, не так давно разборы полетов насчет ядер и были) -- WBR, Michael Shigorin <[EMAIL PROTECTED]> -- Linux.Kiev http://www.linux.kiev.ua/
Re: gcc-3.2
Victor Wagner <[EMAIL PROTECTED]> writes: > On 2002.11.13 at 16:34:46 +0300, Yury Koshkaroff wrote: > > > > > Всем привет. > > > > А вот кто что думает о переходе на gcc-3.2 ? > > > > Есть ли смысл его на Woody ставить ? > > Если ты точно знаешь, что есть такие фичи в стандарте C++, которые не > поддерживаются более ранними GCC, и собираешься, причем по делу, эти > фичи в своей программе использовать, то ставь. Только не основным > компилятором. > > > Будет ли какой резон им систему пересобирать, в плане > > производительности например ? > > Нет, конечно. Это смотря под какую платформу, imho. В 3.X по сравнению с 2.X добавили много оптимизаций под платформы, отличные от x86... и чем больше X, тем этих оптимизаций больше, а отлажены они лучше... я на своем домашнем iBook'е перешел на gcc3.2, причем пересобрал всю систему, включая libc... -- Valentin Podlovchenko <[EMAIL PROTECTED]> +7(095) 787-2058,787-2056(fax) PGP: 0x54FAFB96
Re: gcc-3.2
On 2002.11.13 at 16:34:46 +0300, Yury Koshkaroff wrote: > > Всем привет. > > А вот кто что думает о переходе на gcc-3.2 ? > > Есть ли смысл его на Woody ставить ? Если ты точно знаешь, что есть такие фичи в стандарте C++, которые не поддерживаются более ранними GCC, и собираешься, причем по делу, эти фичи в своей программе использовать, то ставь. Только не основным компилятором. > Будет ли какой резон им систему пересобирать, в плане производительности > например ? Нет, конечно. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: gcc-3.2
13 Ноябрь 2002 16:51, Paul Romanchenko написал: > У третьей гнуси несовместим ABI, поэтому пересобирать придется _все_ > (включая libc). Поэтому о собранных пакетах с тырнета можно забыть. > imho. Ответ неверный. У него C++ ABI несовместимый. Пересобирать придется только C++ - пакеты. -- Alexander Kogan AutoWave Processes Group Institute of Applied Physics RAS
Re: gcc-3.2
У третьей гнуси несовместим ABI, поэтому пересобирать придется _все_ (включая libc). Поэтому о собранных пакетах с тырнета можно забыть. imho. Nov 13, Yury Koshkaroff: > > Всем привет. > > А вот кто что думает о переходе на gcc-3.2 ? > > Есть ли смысл его на Woody ставить ? > Будет ли какой резон им систему пересобирать, в плане производительности > например ? > > С уважением Юрий Кошкаров > > > -- :wq Paul S. Romanchenko (rmrfchik)
Re: gcc
On Thu, Mar 28, 2002 at 11:22:18PM +0500, Eugene Korovin wrote: > > Сабж ? Или это только у меня ? > > [ skipped ] > Последний snapshot gcc 3.1 не валится : main.cpp: In constructor `ResItem::ResItem()': main.cpp:7: class `ResItem' does not have any field named `template class std::map' main.cpp: In member function `void ResItem::print()': main.cpp:8: `cout' undeclared (first use this function) main.cpp:8: (Each undeclared identifier is reported only once for each function it appears in.) -- With best wishes, Nick Orlov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Fri, 29 Mar 2002, Alexei Khlebnikov wrote:
> On Thu, 28 Mar 2002 23:22:18 +0500
> Eugene Korovin <[EMAIL PROTECTED]> wrote:
>
>
> EK> Сабж ? Или это только у меня ?
>
> EK> $cat test.cc
> EK> #include
> EK> #include
>
> EK> class ResItem : public std::map
> EK> {
> EK> public:
> EK> ResItem() : std::map() {};
> EK> void print() { cout << "hello\n"; }
> EK> };
>
> EK> int main()
> EK> {
> EK> ResItem a;
> EK> a.print();
>
> EK> return 0;
> EK> }
>
> EK> Знаю, что там ошибка, но:
>
> EK> $gcc -v test.cc
> EK> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
> EK> gcc version 2.95.4 20011002 (Debian prerelease)
> EK> /usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c++ -v -D__GNUC__=2
> -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__
> -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux
> -Asystem(posix) -D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386
> -D__i386__ test.cc /tmp/ccz4c5vn.ii
> EK> GNU CPP version 2.95.4 20011002 (Debian prerelease) (i386 Linux/ELF)
> EK> #include "..." search starts here:
> EK> #include <...> search starts here:
> EK> /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3
> EK> /usr/local/include
> EK> /usr/lib/gcc-lib/i386-linux/2.95.4/include
> EK> /usr/include
> EK> End of search list.
> EK> The following default directories have been omitted from the search path:
> EK> /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
> EK> End of omitted list.
> EK> /usr/lib/gcc-lib/i386-linux/2.95.4/cc1plus /tmp/ccz4c5vn.ii -quiet
> -dumpbase test.cc -version -o /tmp/ccUImZxI.s
> EK> GNU C++ version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled
> by GNU C version 2.95.4 20011002 (Debian prerelease).
> EK> test.cc:5: Internal compiler error.
> EK> test.cc:5: Please submit a full bug report.
> EK> test.cc:5: Internal compiler error:
> EK> test.cc:5: See http://www.gnu.org/software/gcc/bugs.html> for
> instructions.
>
>
> Да, у меня также. Версия gcc, правда другая. Самый что ни на есть ICE. И с
> gcc, и с
> g++, и с g++-3.0 (у меня 3.0.2-2). Пиши bug-report в
> debian-gcc@lists.debian.org
> и в GNATS.
>
> А где там ошибка? Разве что std:: перед cout пропущено, но компилятор до
> этого, в
> конструкторе, валится.
std::map это вообще-то шаблон.
Best regards,
-Vlad
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Thu, 28 Mar 2002 23:22:18 +0500
Eugene Korovin <[EMAIL PROTECTED]> wrote:
EK> Сабж ? Или это только у меня ?
EK> $cat test.cc
EK> #include
EK> #include
EK> class ResItem : public std::map
EK> {
EK> public:
EK> ResItem() : std::map() {};
EK> void print() { cout << "hello\n"; }
EK> };
EK> int main()
EK> {
EK> ResItem a;
EK> a.print();
EK> return 0;
EK> }
EK> Знаю, что там ошибка, но:
EK> $gcc -v test.cc
EK> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
EK> gcc version 2.95.4 20011002 (Debian prerelease)
EK> /usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c++ -v -D__GNUC__=2
-D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__
-Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux
-Asystem(posix) -D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386
-D__i386__ test.cc /tmp/ccz4c5vn.ii
EK> GNU CPP version 2.95.4 20011002 (Debian prerelease) (i386 Linux/ELF)
EK> #include "..." search starts here:
EK> #include <...> search starts here:
EK> /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3
EK> /usr/local/include
EK> /usr/lib/gcc-lib/i386-linux/2.95.4/include
EK> /usr/include
EK> End of search list.
EK> The following default directories have been omitted from the search path:
EK> /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
EK> End of omitted list.
EK> /usr/lib/gcc-lib/i386-linux/2.95.4/cc1plus /tmp/ccz4c5vn.ii -quiet
-dumpbase test.cc -version -o /tmp/ccUImZxI.s
EK> GNU C++ version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled
by GNU C version 2.95.4 20011002 (Debian prerelease).
EK> test.cc:5: Internal compiler error.
EK> test.cc:5: Please submit a full bug report.
EK> test.cc:5: Internal compiler error:
EK> test.cc:5: See http://www.gnu.org/software/gcc/bugs.html> for
instructions.
Да, у меня также. Версия gcc, правда другая. Самый что ни на есть ICE. И с gcc,
и с
g++, и с g++-3.0 (у меня 3.0.2-2). Пиши bug-report в debian-gcc@lists.debian.org
и в GNATS.
А где там ошибка? Разве что std:: перед cout пропущено, но компилятор до этого,
в
конструкторе, валится.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc and 'warning: multi-character character constant'
On Thu, 13 Sep 2001 20:31:22 +0400
"Andrey Chernomyrdin" <[EMAIL PROTECTED]> wrote:
> Hi!
>
> Вот тут есть чужая програмка в которой есть присваивания типа:
>
> unsigned short inti = 'ab';
>
> На эти присваивания gcc ругается:
> warning: multi-character character constant
>
> Как-бы это убрать (в смысле warning-и) или как это сделать наиболее
> портабельно.
>
Видимо, как-то так:
===
#include
#include
int main(int argc, char **argv) {
unsigned short int i = 'ab';
unsigned short int j = ('a' << CHAR_BIT) | 'b' ;
printf("i=%u j=%u\n",(unsigned)i,(unsigned)j);
return 0;
}
===
i=24930 j=24930
Всего хорошего.
--
Dmitry Tsitelov
mailto:[EMAIL PROTECTED]
Re: gcc 3.0.2 pre
Nick Orlov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Здравствуйте, CuPoTKa. Вы писали Friday, September 07, 2001, 8:11:48 AM: C> Nick Orlov wrote: Здравствуйте, Alexei. Вы писали Tuesday, September 04, 2001, 1:24:56 PM: AK> Nick Orlov wrote: AK> Эх, GNU. Там же практически везде чистый С. Согласен, но есть и плюсовые вещи. Например DDD. AK> Если делать нефиг, собери может еще blackbox и расскажи как там. AK> Хорошая штучка. Особенно для слабой машины и 3-кнопочной мышки. правда с ним у меня возникли проблемы. после некоторых исправлений gcc 3.0.1 он собрался, но работать не захотел :( AK> Ого. Ты исправлял ошибки в gcc ? AK> Можно попробовать пересобрать DDD без оптимизации, очень может быть что AK> заработает. В DDD :) Я имел ввиду что собирал DDD используя gcc-3.0.1 :) сорри за confusing код gcc я не трогал. хотя кое-что в STL я для себя правил :)) C> Я с сабжем "работаю" ядро собирал. ICE еще в жизни невидал (правда я C> раньше в stable FreeBSD жил :) ) а в дебиане недавно. Короче как C> говорится, старое уже забыл, а новое еще не выучил. Kernel я собирал с C> 3.0.1 deb пакетом. Собралось без проблем правда больше ругалось C> warnings. С -O9 kernel не бутился (правда может это не gcc а kernel код C> не рассчитан на это). Может не по адресу вопрос, но ты не пытался его собрать с - --program-suffix=-3.0.2 например? У меня например этот ключик - как мертвому припарки :( И кстати, может это только на HPUX глюк, но у меня вместо того чтобы поставить 1 бинарник и наделать на него симлинков ставится 4 бинарника (я о hppa2.0w-hp-hpux11.00-g++, hppa2.0w-hp-hpux11.00-c++, g++, c++) Неаккуратно как то, если учесть что у меня в HOME места не так и много. А черт его знает, что оно там ставит, так как я собирал его [gcc] не сам, а ставил готовый пакет. Я посмотрел, что имеется в /usr/bin и там имеем два бинарника компайлера один c++-3.0.2, второй g++-3.0.2 и всякие симлинки на них. Однако имеется еще один файл gccbug-3.0 (кто бы это мог быть?). Вроде больше ничего не нашел. Хотя бог его знает, что там ставится. А ключик --program-suffix=-3.0.2 это есть такой новый ключик компилятора? А можете поподробней, что он делает или где почитать? -- , /.---| `| ___ (=\. /-. \ |\/\_|"| | B R C |_\ |;-| ; e e u | / \| |_/ \ S G P | )/\/ \ t a o | ( '| \ | R T |\_ / \ d K |/ \_.--\ S a \|(|\` | | \ | | '. | / \ jgs \ \.__.__.-._)
Re: gcc 3.0.2 pre
Nick Orlov wrote: >Здравствуйте, Alexei. > >Вы писали Tuesday, September 04, 2001, 1:24:56 PM: > >AK> Nick Orlov wrote: > >>>AK> Эх, GNU. Там же практически везде чистый С. >>> >>>Согласен, >>>но есть и плюсовые вещи. >>>Например DDD. >>> > >AK> Если делать нефиг, собери может еще blackbox и расскажи как там. >AK> Хорошая штучка. Особенно для слабой машины и 3-кнопочной мышки. > > >>>правда с ним у меня возникли проблемы. >>>после некоторых исправлений gcc 3.0.1 он собрался, но работать не захотел :( >>> > >AK> Ого. Ты исправлял ошибки в gcc ? >AK> Можно попробовать пересобрать DDD без оптимизации, очень может быть что >AK> заработает. > >В DDD :) >Я имел ввиду что собирал DDD используя gcc-3.0.1 :) сорри за confusing > >код gcc я не трогал. >хотя кое-что в STL я для себя правил :)) > Я с сабжем "работаю" ядро собирал. ICE еще в жизни невидал (правда я раньше в stable FreeBSD жил :) ) а в дебиане недавно. Короче как говорится, старое уже забыл, а новое еще не выучил. Kernel я собирал с 3.0.1 deb пакетом. Собралось без проблем правда больше ругалось warnings. С -O9 kernel не бутился (правда может это не gcc а kernel код не рассчитан на это).
Re: gcc 3.0.2 pre
Nick Orlov wrote: > AK> Эх, GNU. Там же практически везде чистый С. > > Согласен, > но есть и плюсовые вещи. > Например DDD. Если делать нефиг, собери может еще blackbox и расскажи как там. Хорошая штучка. Особенно для слабой машины и 3-кнопочной мышки. > правда с ним у меня возникли проблемы. > после некоторых исправлений gcc 3.0.1 он собрался, но работать не захотел :( Ого. Ты исправлял ошибки в gcc ? Можно попробовать пересобрать DDD без оптимизации, очень может быть что заработает.
Re: gcc 3.0.2 pre
Nick Orlov wrote: > AK> Вообще, насколько сложный у тебя код? > > ну как > почти весь GNU пересобран под HPUX :) Эх, GNU. Там же практически везде чистый С.
Re: gcc 3.0.2 pre
Nick Orlov wrote: > >> и, кстати, нескромный вопрос: что такое "ICE" ? > AK> Internal Compiler Error > Ни разу не было :) А было так, что прога, покомпиляная без оптимизации работала на ура, а с оптимизацией грохалась? Вообще, насколько сложный у тебя код?
