NikS: > по поводу #pragma warning (error:4700), pragma и причие нестандартные идиотизмы лучше не применять - будет меньше проблем при переходе на другой компилятор.

> - и все - надежность по отношению к неинициализированным указателям в VC++ гарантирована.

Гарантирована только глупая ругань на каждый чих. На этапе компиляции невозможно определить, что делается с указателем.
Тем более, само понятие "неинициализированный указатель" -- ерудна на постном масле. Указатели по умолчанию инициализируются нулем, к вашему сведению.

> Можно ваще любую функцию без return. 

Привет AC! Кстати нашел я свой изначальный примерчик 
с исключение throw(A) в своей кодопомойке.

#pragma warning (error:4700)

#include <iostream>

using namespace std;

class A
{
public:
    int x;
    void Info();
};


void A::Info()
{
    cout << "No Antichrist!" << endl;
}


void f(A *a) throw (A)
{
    if (a->x == 666)
    {
        throw A();
    }

    a->x = 1;
}

main()
{
    A *a;

    a = new A;
    
    try 
    {

       if (a == NULL)
       {
           throw "Sorry";
       }
       a->x = 666;
       f(a); 

       std::cout << a->x << std::endl;
    }
    catch (char *s)
    {
       cout << s << endl;
    }
    catch (A aex)
    {
       aex.Info();
    }

    cout << "Finished" << endl;
}

C:\Demo\aaa>cl /GX /WX c2.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

c2.cpp
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:c2.exe
c2.obj

C:\Demo\aaa>c2
No Antichrist!
Finished


C:\Demo\aaa>icl -WX -GX c2.cpp
Intel(R) C++ Compiler for 32-bit applications, Version 7.0   Build 20021018Z
Copyright (C) 1985-2002 Intel Corporation.  All rights reserved.
30 DAY EVALUATION LICENSE

c2.cpp
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:c2.exe
c2.obj

C:\Demo\aaa>c2
No Antichrist!
Finished

(По материалам MSDN, Burzum, Mayhem, Emperor & LOR;-))

NikS.

AC, насчет инициализации указателей нулем ты погорячился имхо...

насчет #pragma я тоже не соглашусь: #pragma comment(lib, "...") - весьма удобная (и правильная) вещь.

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

з.ы.: а если вспомнить отношение компиляторов к шаблонам, то кросс-компиляторность и С++ я бы рядом не ставил.

>Кстати нашел я свой изначальный примерчик с исключение throw(A) в своей кодопомойке.

А теперь подумайте, хе-хе, чем этот примерчик отличается от того, что было раньше, и осознанно ли вы раньше написали throw (A), или так, для прикола, потому что так видели где-то? :)
Я типа одного не могу понять -- вы хотите что-то доказать, или просто выражаете свое постижение новых для вас фич языка?

Производительность <реально> падает в два раза.
Условные команды, как и все остальные выполняются спекулятивно.
Пока мы узнаем результат сравнения, нам нужно чем-то заполнять конвейер (более 20 стадий для Р4).
Для оптимизации циклов условные переходы назад процессор
предсказывает как происходящие (вариант -О1: переход назад)
и выбирает далее команды по адресу перехода,
а происходящие вперед (вариант -О3) это mispredict и прерывание конвейера. Только с четвертого раза буфер истории поймет, что не нужно производить первый переход, но и то поймет не всегда
(буфер предсказаний ограничен, или другой переход занимает нужную строку буфера). Так что как ни крути хороший цикл это один условный переход назад и все.

Intel 7 и #pragma

Intel тоже надежный компайлер 

#pragma warning (error:...) - стандартная feature,
и это беда анонимусов-"Юпитеров", если они ее не знают.
Пускай идут подучиться в "Специалист.ру"


#pragma warning (error:592)

#include <iostream>

typedef struct tagA
{
    int x;
}
A;

void f(A *a) throw (A)
{
    a->x = 1;
}

main(int argc, char *argv[])
{
    A *a;

//    a = new A;

    f(a); 
    std::cout << a->x << std::endl;
}


C:\Demo\intel>icl c1.cpp
Intel(R) C++ Compiler for 32-bit applications, Version 7.0   Build 20021018Z
Copyright (C) 1985-2002 Intel Corporation.  All rights reserved.

c1.cpp
c1.cpp(22): error: variable "a" is used before its value is set
      f(a);
        ^

compilation aborted for c1.cpp (code 2)


NikS.

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

з.ы.: попробуй заменить for() на while() интереса ради.

>новых для вас фич языка

Неизвестно, что выпадет в "лотерейке" - лучше копнуть поглубже. Могу, кстати, привести реальный интересный тестовый примерчик, который надо решить за 2 минуты.

Ну а злящиеся анонимусы развлекают меня - "собака лает - караван идет". ;-)) Без них скучно. ;-(

NikS.

Попробовал заменить for на while, тоже самое. Тут ведь не синтаксический анализатор постарался, а оптимизатор, причем не -О1, а сам -О3. Где-то в нем сидит информация, что fxch - это круто, вот он и перестраивает FPU код. А неверное предсказание на каждой итерации цикла - это примерно 20-25 пропущенных тактов, а сам цикл имеет примерно столько же команд, так что в два раза и будет. Видимо придется мне с CBuilder переходить на Visual C... Говорят крут он и все могет. Мне нюансы стандарта С++ не интересны. И дебуггер не мое хобби, считаю что ошибки нужно ловить читая программу, а не посмертные записки дампа. Мне важно чтоб код был оптимален. А тут GCC откровенно сплоховал. Вы уж меня разубедите примерами.

> ерудна на постном масле. Указатели по умолчанию инициализируются нулем, к вашему сведению. 


Хммм! Для Intel это так. Для Intel...

#include <iostream>

class A
{
public:
    int x;
};

void f(A *a) throw (A)
{
    a->x = 1;
}

main(int argc, char *argv[])
{
    A *a1;
    A *a2 = NULL;

    std::cout << a1 << std::endl;
    std::cout << a2 << std::endl;
}


C:\Demo\intel>cl -GX init.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

init.cpp
c:\demo\intel\init.cpp(19) : warning C4700: local variable 'a1' used without hav
ing been initialized
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:init.exe
init.obj

C:\Demo\intel>init
00421EEF
00000000


C:\Demo\intel>icl -GX init.cpp
Intel(R) C++ Compiler for 32-bit applications, Version 7.0   Build 20021018Z
Copyright (C) 1985-2002 Intel Corporation.  All rights reserved.

init.cpp
init.cpp(19): warning #592: variable "a1" is used before its value is set
      std::cout << a1 << std::endl;
                   ^

Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:init.exe
init.obj

C:\Demo\intel>init.exe
00000000
00000000

А то мне вчера один "знаток" все вещал "причем тут компайлер, все
компайлеры одинаковыеб ты НикС - дурак, а я умный! Все компайлеры
одинаковые!!!"
Как звали, кстати, этого умного кекса? Эх, тоеретики... ;-((


NikS.

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

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

И все таки. Почему вот это компилируется и РАБОТАЕТ???
#include <stdio.h>
main()
{
int *p; // неинициализирован!!!
*p = 1;
printf("%d\n", *p);
return 0;
}

$ gcc test.c
$ ./a.out
1
Более того
$ gcc -Wall test.c
$ ./a.out
1
А вот если
$ gcc -O test.c
то
$ ./a.out
Segmentation fault
Это нормально???
Версия gcc = 3.2.1

Хотелось бы также узнать, как в этой ситуации себя веде gcc 3.3

VC хорошо оптимизирует. еще бы со стандартами не дурил - цены б ему не было. а тебя я не понял. ты собираешься переходить с С-билдера, а код у тебя генерируется при помощи GCC. ты на чем пишешь-то? ;)

если пишешь только под винды и не забиваешь голову вопросами лицензий - ставь MSVC и пользуйся им. пока в дебри С++ не полезешь - проблем не будет.

>Могу, кстати, привести реальный интересный тестовый примерчик, который надо решить за 2 минуты.

Ну давайте. Что там у вас за примеры?

>ставь MSVC и пользуйся им. пока в дебри С++ не полезешь -

Дебри С++ пожалуй уже неактуальны. Все равно компилятора, "хорошо" поддерживающего С++-навороты и генерящего для них хороший код, стараниями интела нет. Так что, generic programming и все шаблонные навороты видимо скоро уйдут на свалку истории.

Пример - "мат в три хода":

#include <iostream>

using namespace std;

class A
{
public:
   A() { cout << "ctorA" << endl; }
   ~A() { cout << "dtorA" << endl; }
};

class B : public A
{
public:
   B() { cout << "ctorB" << endl; }
   ~B() { cout << "dtorB" << endl; }
};

class C : public B
{
public:
   C() { cout << "ctorC" << endl; }
   ~C() { cout << "dtorC" << endl; }
};


main()
{
 // 
 // 
 // 
}

Поставьте три строчки, дабы был вывод:

ctorA
ctorB
ctorC
ctorA
ctorB
ctorC
dtorA
dtorC
dtorB
dtorA

(На компьютере gcc, cl, icl, icc нету ;-( ;-))


NikS.

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

А я бы Intel использовал, о чем я всегда говорил:

#include <iostream>

using namespace std;

class A
{
public:
    int x;
};


void f(A *a) throw (A)
{
    a->x = 1;
}

main()
{
    A *a;
//  a = new A;
    try {
       if (a == NULL)
           throw "NULL";
       a->x = 11;
       f(a); 
       std::cout << a->x << std::endl;
    } catch (char *s) {
       cout << s << endl;
    }
    cout << "Finished" << endl;
}


C:\Demo\aaa>icl intelrulez.cpp
Intel(R) C++ Compiler for 32-bit applications, Version 7.0   Build 20021018Z
Copyright (C) 1985-2002 Intel Corporation.  All rights reserved.
30 DAY EVALUATION LICENSE

intelrulez.cpp
intelrulez.cpp(23): warning #583: C++ exception handler found but GX option not
present
      try
      ^

intelrulez.cpp(26): warning #592: variable "a" is used before its value is set
         if (a == NULL)
             ^

Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:intelrulez.exe
intelrulez.obj

C:\Demo\aaa>intelrulez.exe
NULL
Finished

NikS.

"При чем тут компилятор" (с) (цитата)

2Monk

> Почему вот это компилируется и РАБОТАЕТ???

За подобный вопрос меня 4 месяца назад хотели съесть. Живьем!

На самом деле Intel выдаст ошибку:

"monk.exe has encountered a problem and needs to close. We are sorry for the inconvenience."

а MS VC++ будет работать.

Но меня вчера опять хотели за подобный вопрос на жаркое отправить.;-((( "Ведь все компиляторы одинаковы! При чем тут компилятор?"

NikS.

> Сходите на "Савеловскую", поговорите с народом про AS/400,
> а потом снова сюда вылезайте.

Если они отказались от того говна, которое было раньше - я очень рад.

ПисАл на Borland C, потом CBuilder, потому что другого не было (университет). Достало.
Visual С нормального (стабильного и бесплатного) на CD найти негде.
По сети ~700 Мб качать...
Не в Киев же за ним ехать.
Да и почитав заранее документацию, не узнал я, есть ли в нем то, что мне нужно для вычислительных расчетов: управление выравниванием, управление набором команд (FPU или SSE2) и пр.
А GCC вроде как везде переносим и это там есть.
Хочется, однако, на GCC работать.
Скачал себе MinGW: GCC (3.2) для Windows.
Вполне нормально работает, лучше Builder, но иногда заморочки вроде вот таких циклов бывают.
Документацию по GCC прочитал - ..здец.
400 страниц только command line options.
Какую-то оптимизацию бы отключить,
которая лажается и заменяет fld на fxch, да и все дела.
Может кто знает?
И вот еще. Как пренаправить вывод ошибок в файл. В CBuilder я писал
make >out и все дела.
А GCC работает через stdout, а ошибки сливает на stderr.
Как его то переопределить, да еще сказать,
чтобы и препроцессор, и асм и линкер туда же лили? А то 100 ошибок, а я вижу только последние...

> Ну а злящиеся анонимусы развлекают меня - "собака лает - караван
> идет". ;-)) Без них скучно. ;-(

NikS, глупышка, ты не поймёшь одного - что здесь обсуждение новости, а не обсуждение твоего похода в бауманку на сдачу экзамена. Иди хотя бы в форум-Development. Лучше конечно нахер, но на это зрители уже и не надеются.

2Monk:

#include <iostream> 

main() 
{ 
    int *p;
    *p = 1; 
    std::cout << *p << std::endl;
} 

Кстати не будет работать и в M$VC++. Вылетит.


NikS.

2 Niks:

> Поставьте три строчки, дабы был вывод:

Легко и не думая :-)

Первая строчка - "(*"
Последняя - "*)"
В конец файла добавляем прямой вывод (ограничений на длину строки нет :) )

>Поставьте три строчки, дабы был вывод:

А что, это называется интересный пример?
C c1;
C* c2 = new C;
c2->A::~A();

> Лучше конечно <...>, но на это зрители уже и не надеются. 

А, опять пришел клоун-анонимус, облажавшийся с main() return и 
#pragma warning! ;-))))

Ну клоун, давайте объясняйте про 

#include <stdio.h> 
main() 
{ 
int *p; // неинициализирован!!! 
*p = 1; 
printf("%d\n", *p); 
return 0; 
} 

посмотрим ваши познания J.Alger'а. Ответ-то, детка, на поверхности.

NikS.

ЗЫ. Вы не один тут облажавшийся. Примерчик мой с инициализацией в 
icl и cl вместе с клоуном crz изучайте, "теоретики".


NikS.

> А то мне вчера один "знаток" все вещал "причем тут компайлер, все компайлеры одинаковыеб ты НикС - дурак, а я умный! Все компайлеры одинаковые!!!"

Вот пиздюк, аж ох-еваю. Про "Все компайлеры одинаковые" это ты сам выдумал и на других вешаешь. Про "причем тут компайлер" это была совершенно законная фраза ибо как тебя уже ткнули в рожу стандартом, поведение _программы_ при разыменовании NULL не определено. Про компилятор в этой ситуации вообще речи нет, поскольку тут и стандартов не надо, а просто соображалкой подумать, что компилер в общем случае не может предсказать место где в переменной NULL появится. Да тебе AC уже толково объяснил - если не понимаешь - это клиника. Ну а насчет "НикС - дурак, а я умный" это конечно тоже твое творение но я все больше к нему склоняюсь.

2AC

У них:

C c;
A *a = new C;
delete a;

Только у них, естественно код, а потом вопрос, что будет. ;-))

Также вопросики есть, как использовать "упреждающие" указатели 
(4 варианта) 

Ну и типа:

Which two methods are exposed by the Dispatch interface but not exposed by the IUnknown interface?

A. Queryinterface 
B. GetTypeInfo 
C. Invoke 
D. AddRef 

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

Есть ли специальный тест по GCC - не знаю. LPI - это более
администрирование.

NikS.

>> Почему вот это компилируется и РАБОТАЕТ???

Дизассемблируй да посмотри. Или прогони под valgrind и убедись, как оно "работает". В одном случае указатель по случайке смотрит в разрешенную для записи область памяти, далее может ее и портим слегка но не фатально. В другом случае просто не повезло. В обоих случаях это вообще не показатель а типичная плавающая ошибка, которая где как проявляется.

> За подобный вопрос меня 4 месяца назад хотели съесть. Живьем!

Таких кретинов ссылать надо подальше , а есть это отравиться можно.

> И вот еще. Как пренаправить вывод ошибок в файл. В CBuilder я писал make >out и все дела.
> А GCC работает через stdout, а ошибки сливает на stderr.
> Как его то переопределить, да еще сказать,
> чтобы и препроцессор, и асм и линкер туда же лили? А то 100 ошибок, а я вижу только последние...

Ты прикалываешься что ли? man bash или вкратце make>out 2>&1

Да не лажайтесь вы опять так, клоун-теоретик:

C:\Demo\msvc>init.exe
00421EEF
00000000

C:\Demo\intel>init.exe
00000000
00000000

мало вам, что c main() и #pragma облажались по полной!

Вы мне _цитату_ из стандарта приведите, и докажите, что
это стандарт, а не бред больной головы анонимуса-аникейщика.
Жду 10 минут. Отчет времени пошел.

PS. Да, очередной шут-матершинник на форуме завелся!;-)))
Луговский только отличался оригинальностью мышления и большей 
виртуозностью в сквернословии. А вы - дилетант по сравнению с ним.


NikS.

-----

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

-----

Слыш онанизмус! Ты сегодня у нас дежурным клоуном?

2gcc-teapot:

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

RTFM, блин ;)

"your_command.exe > output.msg 2> output.err"
См. MSDN на предмет "Redirecting Error Messages from Command Prompt: STDERR/STDOUT".

> мало вам, что c main() и #pragma облажались по полной!

какая еще прагма) это писал другой анонимус -))

>В другом случае просто не повезло. 


Нам повезло, что клоун на форум пожаловал. Ну и умора!

Элджера, почитайте, юный гений!

В чем разница, убогий, книжек не читающий:


#include <stdio.h> 

main() 
{ 
    int *p;
    *p = 1; 
     printf("%d\n", *p); 
} 


#include <iostream> 

main() 
{ 
    int *p;
    *p = 1; 
    std::cout << *p << std::endl;
} 

???

NikS

>У них: C c; A *a = new C; delete a;

Мой код круче:)) Он будет работать и для виртуальных деструкторов.

> В чем разница, убогий, книжек не читающий:

А чего ты свой код задним числом подтыкаешь? Я говорил только про тест monk-a.

2 Клоун-анонимус

> А чего ты свой код задним числом подтыкаешь? Я говорил только про тест monk-a.

Не не могу! Просто цирк! ;-))))

Жду цитаты из стандарта. Время!!! И не облажайтесь как со "стандартами" на return. ;-))

NikS.

2 gcc-teapot:

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

Зато Intel поспонсировала GCC Summit :-)
[возвращаясь-таки к теме новости]

Вопрос чайника:

main()
{
int *p;
*p = 1;
std::cout << *p << std::endl;
}

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

main()
{
std::cout << 1 << std::endl;
}

> Зато Intel поспонсировала GCC Summit :-)

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

Где обещанный мне стаандаааарт!!! ;-Q

Кстати, вопрос клоун-анонимусу: а как #pragma warning(...) заменить ключом компилятора? ;-))

NikS.

> Лучше бы они свой собственный компилятор поспонсировали

Ну так, я и глумлюсь почти над тем же :)

> Жду цитаты из стандарта. Время!!!

Ты не время меряй, идиот, а тред прочти внимательно, а не только то, что тебе нравится читать.

http://www.linux.org.ru/add_comment.jsp?topic=323260&replyto=323798&r...

> И не облажайтесь как со "стандартами" на return. ;-))

/me другой анонимус если че. Не надо нас всех в кучу валить.

>Разве не должен хороший компилер сам удалить чтение после записи, а затем аннулировать и саму запись, так как она не имеет побочных последствий?

Хорошие компиляторы действительно распространяют константы, но в этом примере все ж вопрос. Можно считать, что операция разыменования всегда дает побочный эффект.

>Не надо нас всех в кучу валить.

Подписываться надо глупыш!

Чтобы через 3 минуты цитата была в студии.

NikS.

"effect of dereferencing the null pointer"

Написано просто про то, что стандарт _отсутствует_ в данной области.
Просто каждый производитель имеет право здесь на свободу выбора.
А анонимусы могут читать руководство или НЕ читать, как клоун-анонимус.

Вот эта програма квакнется?

#include <iostream>

using namespace std;

class A
{
public:
    int x;
};


void f(A *a)
{
    a->x = 1;
}

main()
{
    A *a = NULL;

//    a = new A;
    
    try 
    {

       if (a == NULL)
       {
           throw "Sorry";
       }
       a->x = 666;
       f(a); 

       std::cout << a->x << std::endl;
    }
    catch (char *s)
    {
       cout << s << endl;
    }

    cout << "Finished" << endl;
}

а эта:

#include <iostream>

using namespace std;

class A
{
public:
    int x;
};


void f(A *a)
{
    a->x = 1;
}

main()
{
    A *a;

//    a = new A;
    
    try 
    {

       if (a == NULL)
       {
           throw "Sorry";
       }
       a->x = 666;
       f(a); 

       std::cout << a->x << std::endl;
    }
    catch (char *s)
    {
       cout << s << endl;
    }

    cout << "Finished" << endl;
}

???

А на Intel компиляторе?


NikS.

Так вот задаю вопрос анонимусу, который сегодня начал отмазываться.
В чем различие между:

#include <stdio.h> 

main() 
{ 
    int *p;
    *p = 1; 
    printf("%d\n", *p); 
} 

и

#include <iostream> 

main() 
{ 
    int *p;
    *p = 1; 
    std::cout << *p << std::endl;
} 

Чтобы завтра в 14:00 по Москве ответ был.

Кстати про ключ вместо прагмы warning(error:xxx) 
анонимус-матершинник мне не ответил - слинял, болтун! 


NikS.

Кстати, клоун-анонимус, даю подсказку. 
Что выдаст:


// Sorry за смешение стилей
#include <stdio.h> 
#include <iostream> 

main() 
{ 
    int *p;
    try{
       *p = 1; 
       printf("%d\n", *p); 
    } 
    catch(...)
    {
       std::cout << "Sorry!" << std::endl; 
    }
} 

С MSVC? С Intel? Мозги есть - думайте.


NikS.

Результат дизассемблирования:
#include <stdio.h>
int main() 
{ 
    int *p;
    *p = 1; 
     printf("%d\n", *p); 
     return 0;
}

Без параметров (кстати, а почему на эту плавающую ошибку даже предупреждения только при включенной оптимизации появляются???):
804833c:       55                      push   %ebp
804833d:       89 e5                   mov    %esp,%ebp
804833f:       83 ec 08                sub    $0x8,%esp
8048342:       83 e4 f0                and    $0xfffffff0,%esp 
8048345:       b8 00 00 00 00          mov    $0x0,%eax   //
804834a:       29 c4                   sub    %eax,%esp       // эти 2 строки неясно к чему
804834c:       8b 45 fc                mov    0xfffffffc(%ebp),%eax // eax = p
804834f:       c7 00 01 00 00 00       movl   $0x1,(%eax)          // *p = 1
8048355:       83 ec 08                sub    $0x8,%esp
8048358:       8b 45 fc                mov    0xfffffffc(%ebp),%eax
804835b:       ff 30                   pushl  (%eax)
804835d:       68 c8 83 04 08          push   $0x80483c8
8048362:       e8 01 ff ff ff          call   8048268 <_init+0x38>
8048367:       83 c4 10                add    $0x10,%esp
804836a:       b8 00 00 00 00          mov    $0x0,%eax
804836f:       c9                      leave
8048370:       c3                      ret

Теперь после оптимизации
8048340:       55                      push   %ebp
8048341:       89 e5                   mov    %esp,%ebp
8048343:       52                      push   %edx
8048344:       52                      push   %edx
8048345:       c7 00 01 00 00 00       movl   $0x1,(%eax) // в eax НИЧЕГО не записано, естественно в результате глюк...
804834b:       83 e4 f0                and    $0xfffffff0,%esp
804834e:       50                      push   %eax
804834f:       50                      push   %eax
8048350:       6a 01                   push   $0x1
8048352:       68 b8 83 04 08          push   $0x80483b8
8048357:       e8 0c ff ff ff          call   8048268 <_init+0x38>
804835c:       89 ec                   mov    %ebp,%esp
804835e:       31 c0                   xor    %eax,%eax
8048360:       5d                      pop    %ebp
8048361:       c3                      ret

С одной стороны после оптимизации ВООБЩЕ нет чтения памяти переменной p. С другой стороны без включения оптимизации нет предупреждения, что
будет глюк. Не зря при компиляции ядра запрещается менять парамтры оптимизации... да и версию компиляторо настоятельно рекомендуют брать ту
же, что и у авторов ядра. Нет бы в стандарт пару абзацев написать на эту тему, а то ни к селу, ни к городу.