The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Основанные на GCC проекты JIT-компилятора и расширения, испо..., opennews (??), 04-Окт-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


58. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Аноним (-), 04-Окт-13, 14:05 
>> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
> Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь,
> заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или
> вообще какой-нить ARM. Поэтому программа явно не может таскать с собой
> для этого предкомпилированный код.

Вы прям так спрашиваете как будто arisu разбирается в компьютерах и не просто так брякнул.

Ответить | Правка | Наверх | Cообщить модератору

76. "Основанные на GCC проекты JIT-компилятора и расширения,..."  –2 +/–
Сообщение от Аноним (-), 04-Окт-13, 19:21 
не мешай ему дилетанствовать c самовлюбленным апломбом, вон уже чуть ниже поток полился про "ощущения чуйств" на тему GCC. Замени GCC и LLVM на Коллайдер и систему жизнеобеспечения автономного модуля на Марсе, впрочем и митохондрии подойдут - суть не поменяется. Костьми ляжет, но ни слова не дождешься о конкретных проверяемых сущностях.
Ответить | Правка | Наверх | Cообщить модератору

77. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +6 +/–
Сообщение от arisu (ok), 04-Окт-13, 19:29 
(пожимает плечами) конкретная сущность — это намертво зависающий движок регулярок, нежно портированый из plan9 и допиленый. тупой шланг не врубается, что inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре (хотя никакого const там нет), поэтому сначала переменную где-то кэширует, а потом использует её старое значение. в итоге получается бесконечный цикл вида «jmp $». чего лично я от компилятора такого возраста никак не ожидал и был несколько в офигее, когда софтина подвисла, слопав весь процессор.

но я понимаю, что для тебя «я наступил на баг в компиляторе» — ситуация вообще невозможная, потому что твой «приветмир» без ворнингов вообще не собирается. какие уж там баги компилятора…

Ответить | Правка | Наверх | Cообщить модератору

84. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +1 +/–
Сообщение от Аноним (-), 05-Окт-13, 11:34 
Красиво приложил :).
> нежно портированый из plan9 и допиленый. тyпой шланг не врубается,

Мсье, что вы, как можно, эппл на такие навороты не рассчитывал. Так что будем слушать вопли фанатиков "это не нyжно!!!111".

Ответить | Правка | Наверх | Cообщить модератору

90. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 05-Окт-13, 12:09 
вот, кстати, только что в списке рассылки Lua пришло:
> I got burned by that particular clang version. At least on 32-bit
> platforms, it makes a mess of compiling something relatively
> straightforward like Lua 5.2.  You will have to switch off
> optimization for liolib.c for it to work.
Ответить | Правка | Наверх | Cообщить модератору

141. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Аноним (-), 10-Окт-13, 11:55 
> вот, кстати, только что в списке рассылки Lua пришло:

Справедливости ради - почитай логи коммитов к амдшному окрытому драйверу :). GCC там тоже  досталось на орехи, пришлось баг воркэраундить :)

Ответить | Правка | Наверх | Cообщить модератору

145. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 10-Окт-13, 12:04 
так я и на gcc-шные баги наступал. как-нибудь под настроение — если вспомню — и его попинаю. но кланг пинать забавней.
Ответить | Правка | Наверх | Cообщить модератору

95. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 05-Окт-13, 19:31 
> тупой шланг не врубается, что
> inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре

Это какая версия компилятора? Т.е. код

struct z_t
{
    int a;
    int b;
};

inline void f( z_t * z)
{
    z.a = 1.0;
}

он откомпилирует неправильно?

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

96. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +1 +/–
Сообщение от arisu (ok), 05-Окт-13, 19:37 
> Это какая версия компилятора?

3.3.

> он откомпилирует неправильно?

не знаю и проверять лень. там функция несколько сложнее, возвращает тоже структуру и используется в виде funcall(ss)->fld = ss->fld1, при этом ss->fld1 внутри функции меняется. но шланг этого не понимает, и использует старое значение.

p.s. собственно, после раздумий я не уверен, ошибка ли это компилятора, или идиотизм стандарта с очередной «неопределённой последовательностью». но принцип least surprise явно поломан, это раз. и два — если поведение неопределено, то компилятор должен плюнуть предупреждением.

Ответить | Правка | Наверх | Cообщить модератору

109. "Основанные на GCC проекты JIT-компилятора и расширения,..."  –1 +/–
Сообщение от annulen (ok), 07-Окт-13, 14:33 
>> Это какая версия компилятора?
> 3.3.
>> он откомпилирует неправильно?
> не знаю и проверять лень. там функция несколько сложнее, возвращает тоже структуру
> и используется в виде funcall(ss)->fld = ss->fld1, при этом ss->fld1 внутри
> функции меняется. но шланг этого не понимает, и использует старое значение.

Выкладывай отпрепроцессенный файл и опции компиляции, я проверю.

Ответить | Правка | Наверх | Cообщить модератору

126. "Основанные на GCC проекты JIT-компилятора и расширения,..."  –1 +/–
Сообщение от Аноним (-), 07-Окт-13, 21:08 
Не выложит, это принципиально. Будет тот же графоманский поток околокомпьютеорных мыслей. Очень правдоподобный для не слишком дотошных, но не практике принципе не проверяемый. Вся суть аризу. "я ощущаю что этот концептуальный подход нелогичен, скучен и приличный человек не будет пользоваться". Спроси про делали и конкретные строки кода или патч - получишь в ответ еще более пространный графоманский водевиль с оскорблениями. Гланвое - ни строки кода.
Ответить | Правка | Наверх | Cообщить модератору

131. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +1 +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:38 
> Не выложит, это принципиально. Будет тот же графоманский поток околокомпьютеорных мыслей.

Милый Аноним, вы тоже не понимаете, что заниматься социальными игрищами, надев маску, нельзя?

Ответить | Правка | Наверх | Cообщить модератору

134. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:58 
> Выкладывай отпрепроцессенный файл и опции компиляции, я проверю.

http://www.opennet.ru/openforum/vsluhforumID3/91996.html#133

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

137. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 07-Окт-13, 22:03 
ты мне гешефт поломал, кстати: я-то надеялся, что денег дадут за сэмпл.
Ответить | Правка | Наверх | Cообщить модератору

128. "Основанные на GCC проекты JIT-компилятора и расширения,..."  –1 +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:19 
> p.s. собственно, после раздумий я не уверен, ошибка ли это компилятора, или
> идиотизм стандарта с очередной «неопределённой последовательностью». но принцип
> least surprise явно поломан, это раз. и два — если поведение
> неопределено, то компилятор должен плюнуть предупреждением.

В том виде, что ты написал, это очень похоже на неопределённое поведение. Причём тут даже C++-ом не пахнет, чистый C.

И, мне кажется, что именно в таких местах мы и получаем пользу от clang'а.

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

129. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 07-Окт-13, 21:31 
> Причём тут даже C++-ом не пахнет, чистый C.

я про си и говорил.

> И, мне кажется, что именно в таких местах мы и получаем пользу
> от clang'а.

нулевую. польза — это если бы меня преупреждением обругали. а так — молча делают фигню. почему фигню? потому что принцип «наименьшего сюрприза» диктует ровно обратное тому, что делает кланг. я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет), но в приличных домах о явно неприличном поведении принято предупреждать. молчат же оба — и кланг, и гцц.

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

Ответить | Правка | Наверх | Cообщить модератору

130. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:37 
> нулевую. польза — это если бы меня преупреждением обругали.

Стат. анализатор у clang'а говно, хотя попробуй, прогони его, авось ругнётся. А для предупреждения эта штука слишком сложна - нужно проанализировать код внутри функции и убедиться, что таки да - меняет поле.

> я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет)

Язык C староват очень.

Ответить | Правка | Наверх | Cообщить модератору

132. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +1 +/–
Сообщение от arisu (ok), 07-Окт-13, 21:56 
>> нулевую. польза — это если бы меня преупреждением обругали.
> Стат. анализатор у clang'а говно, хотя попробуй, прогони его, авось ругнётся.

его, вроде, отдельно собирать надо. потом попробую как-нибудь, git всё помнит, если что.

> для предупреждения эта штука слишком сложна — нужно проанализировать код внутри
> функции и убедиться, что таки да — меняет поле.

ну, там сразу перед return'ом ++ стоит, в принципе, ничего заковыристого. обычный data flow analysis, его и так делают.

>> я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет)
> Язык C староват очень.

дык вон недавно очередную ревизию стандарта приняли. фигни насовали, полезного — ноль. ну почему, например, не стандартизировать 2's-complement integer arithmetic? почему integer overflow не прописать? да куча софта пользуется тем, что это стандарт де-факто (хоть хэш-функции взять — куча на этом подвязана). почему не добавить конструкцию для проверки флажка переполнения, который есть у подавляющего большинства процессоров? это ведь офигенно упростило бы те же проверки на переполнение, которые можно было бы делать постфактум.

вот зачем в очередной раз пересматривать стандарт, чтобы бережно не добавлять туда ничего более-менее полезного irl? какого чёрта было плевать на уже введённый в ISO C90 __inline__ и сделать идиотское _Noreturn вместо __noreturn__? да ну их в анус, академиков сферических. я для себя давно решил, что стандарт — это gnu99, со всеми его вкусными расширениями.

Ответить | Правка | Наверх | Cообщить модератору

135. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 07-Окт-13, 22:00 
> его, вроде, отдельно собирать надо. потом попробую как-нибудь, git всё помнит, если
> что.

Уже не надо - http://www.opennet.ru/openforum/vsluhforumID3/91996.html#133

Ответить | Правка | Наверх | Cообщить модератору

133. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от Vkni (ok), 07-Окт-13, 21:57 
Программа:
8><----------------------------------------------><8

typedef struct SSS
{
    int a, b;
} SS;

SS * f( SS* ss)
{
    ss->a = 2;
    return ss;
}

int main( int argv, char ** argc)
{
   SS ss;
   ss.a = 1;
   ss.b = 3;

   f( &ss)->b = ss.a;

   return ss.b;
}

8><----------------------------------------------><8

Компиляция:

[vkni@t60 Arisu.clang]$ gcc test.c -o gcc
[vkni@t60 Arisu.clang]$ clang test.c -o clang

Как запускать:

[vkni@t60 Arisu.clang]$ ./gcc ; echo $?
2
[vkni@t60 Arisu.clang]$ ./clang ; echo $?
1

Версия gcc: x86_64-alt-linux-gcc (GCC) 4.7.2 20121109 (ALT Linux 4.7.2-alt7)

Версия clang: clang version 3.3 (tags/RELEASE_33/final)

Анализатор clang'а ошибок не выявил: scan-build: No bugs found.

Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

136. "Основанные на GCC проекты JIT-компилятора и расширения,..."  +/–
Сообщение от arisu (ok), 07-Окт-13, 22:00 
благодарю. могу от себя добавить, что gcc 4.8.1 на x86 тоже никаких ворнингов не даёт. я, кстати, с -O2 собирал.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру