После шести месяцев разработки представлен (http://lists.llvm.org/pipermail/llvm-announce/2017-September... релиз проекта LLVM 5.0 (http://llvm.org/) (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.Напомним, что в соответствии с новой нумерацией версий (https://www.opennet.ru/opennews/art.shtml?num=45690) осуществлён уход от разделения значительных и функциональных выпусков. В каждом функциональном обновлении теперь меняется первая цифра (например, весной следующего года состоится релиз LLVM 6.0.0). Для обеспечения совместимости с существующими системами разбора номеров версий LLVM корректирующие обновления, как и раньше приводят к увеличению третьей цифры (5.0.1, 5.0.2, 5.0.3).
Из новых возможностей LLVM 5.0 отмечается полная реализация стандарта C++17 (https://www.opennet.ru/opennews/art.shtml?num=47153), поддержка сопрограмм в C++, реализация GNU-расширения для неявного скалярного преобразования в вектор, новые оптимизации и средства диагностики ошибок.
Улучшения (http://releases.llvm.org/5.0.0/tools/clang/docs/ReleaseNotes... в Clang 5.0:
- Поддержка расширения (http://open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4680.pdf) для использования сопрограмм (http://releases.llvm.org/5.0.0/docs/Coroutines.html) в коде на C++ (пример кода (https://wandbox.org/permlink/Dth1IO5q8Oe31ew2)). Для включения следует использовать опции "-fcoroutines-ts -stdlib=libc++";- Обеспечена полная поддержка стандарта C++17. Для активации режима C++17 следует использовать флаг "-std=c++17" ("-std=c++1z" оставлен для обеспечения совместимости);
- Новые возможности для диагностики:
- "-Wcast-qual" для проверки корректности приведения типов в Си-стиле для C++;
- "-Wunused-lambda-capture" для выявления переменных, захваченных лямбда-выражением, но не используемых в теле лямбда-выражения;
- "-Wstrict-prototypes" для выявления не-прототипных функций, определений блоков и типов в Си и Objective-C;- "-Wunguarded-availability" для информирования об использовании новых API, которые были представлены в системе, версия которой новее версии системы, заданной в качестве целевой. Также добавлен сокращённый вариант "-Wunguarded-availability-new", который охватывает проверку версий API, выпущенных после macOS 10.13, iOS 11, tvOS 11 и watchOS 4;
- "-Wdocumentation" - позволяет использовать в комментариях директивы
\param и \returns для задания типа указателя для блока или функции;
- Добавлен новый флаг компилятора "--autocomplete" для вывода списка флагов и их аргументов для применения в системах автодополнения ввода;
- Объявлены устаревшими и игнорируются флаги "-fslp-vectorize-aggressive" (заменён нормальным векторизатором SLP) и
"-fno-slp-vectorize-aggressive" (данное поведение теперь всегда используется по умолчанию);- Добавлена новая pragma attribute для применения атрибута к нескольким декларациям;
- Для языков Си++ и Си реализовано GNU-расширение для неявного скалярного преобразования в вектор. Пример преобразования скалярного значения в вектор (ко всем элементам вектора "a" будет прибавлено 5):typedef unsigned v4i32 __attribute__((vector_size(16)));
v4i32 foo(v4i32 a) {
return a + 5;
}- Clang 5 станет последним выпуском, в котором по умолчанию используется режим "-std=gnu++98" при использовании совместимого с GCC драйвера clang++. Начиная со следующего выпуска будет применяться режим "-std=gnu++14" для совместимости с поведением новых выпусков GCC. Пользователям рекомендуется добавить в файлы сборки опции для явного определения используемой версии стандарта;
- Устранена порция ошибок в реализации OpenCL, расширен тестовый набор для OpenCL, расширена диагностика, в руководство добавлена документация по OpenCL. Обеспечена поддержка расширения cl_khr_subgroups и атрибута intel_reqd_sub_group_size. В CIndex добавлены типы OpenCL;
- В clang-format добавлена опция BreakBeforeInheritanceComma для подстановки разрывов после ":" и "," при определении класса. Опция включена по умолчанию при выборе стиля оформления кода Mozilla. Обеспечено выравнивание комментариев. Обеспечена автоматическая подстановка комменария с именем пространства имён в конце его определения;
class MyClass
: public X
, public Y {
};/* line 1
* line 2
*/namespace A {
int i;
int j;
} // namespace A- В Libclang обеспечена поддержка автодополнения кода для следующих конструкций C++: static_assert, alignas, constexpr, final, noexcept, override и thread_local. Добавлено автодополнения для членов зависимых классов;
- В linter clang-tidy добавлена большая порция (http://releases.llvm.org/5.0.0/tools/clang/tools/extra/docs/... новых проверок, реализованы новые модули bugpron и hicpp;
- В статическом анализаторе добавлена поддержка автоматического доказателя теорем Z3 (https://github.com/Z3Prover/z3), созданного в Microsoft Research для верификации кода своих продуктов. По сравнению с предлагаемым по умолчанию доказателем теорем Z3 работает примерно в 15 раз медленнее, но позволяет обрабатывать более сложные запросы. Для включения Z3 требуется сборка с опцией "CLANG_ANALYZER_BUILD_Z3=ON" и указание флагов "-Xanalyzer -analyzer-constraints=z3";- Расширены возможности компонента UBSan (Undefined Behavior Sanitizer) с реализацией детектора неопределенного поведения (http://ru.wikipedia.org/wiki/%D0%9D%D0%B... выявляющего во время выполнения программы ситуации, когда поведение программы становится неопределенным:
- Добавлены и включены по умолчанию новые средства для проверки переполнения указателей (-fsanitize=pointer-overflow).
- Реализованы проверки для определения нарушения аннотаций о значениях NULL (-fsanitize=nullability) в аргументах функций, операциях присвоения и значениях return.
- Обеспечено определение некорректной загрузки из битовых полей (bitfields) и булевых наборов ObjC.- В биндингах для языка Python обеспечена поддержка обеих веток - Python 2 и Python 3.
Основные новшества (http://llvm.org/releases/5.0.0/docs/ReleaseNotes.html) LLVM 5.0:
- В компоновщике LLD решены (http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.h... многие проблемы с совместимостью, реализован более читаемый формат сообщений об ошибках, добавлена опция "-Map" для вывода схемы с сопоставлением входных файлов с результирующим файлом, значительно ускорена работа опции "--gdb-index ", добавлена поддержка нестандартных перестановок R_X86_64_8 и R_X86_64_16, по умолчанию обеспечено заполнение добавочных блоков в текстовых сегментах инструкцией INT3 вместо нулевых байтов. Добавлены новые опции: -compress-debug-sections, -emit-relocs, -error-unresolved-symbols, -exclude-libs, -filter, -no-dynamic-linker, -no-export-dynamic, -no-fatal-warnings, -print-map, -warn-unresolved-symbols, -z nocopyreloc, -z notext, -z rodynamic;
- В оптимизаторе циклов Polly, поддерживающем несколько техник оптимизации циклов и позволяющем организовать автоматическое распараллеливание кода с задействованием OpenMP, обеспечена (http://releases.llvm.org/5.0.0/tools/polly/docs/ReleaseNotes... поддержка компиляции всех компонентов платформы Android и пакета FFMPEG;
- Представлена новая библиотека BinaryFormat, в которую перемещены определения структуры file_magic и функций identify_magic, а также структур и определений для форматов DWARF, ELF, COFF, WASM и MachO;
- Утилита llvm-pdbdump...URL: http://lists.llvm.org/pipermail/llvm-announce/2017-September...
Новость: https://www.opennet.ru/opennews/art.shtml?num=47154
> После шести месяцев разработкиТеперь будут номер инкрементировать каждые полгода?
Да, судя по "весной следующего года состоится релиз LLVM 6.0.0".
>> После шести месяцев разработки
> Теперь будут номер инкрементировать каждые полгода?Они уже совсем Большие и GCC-совместимые: https://www.opennet.ru/openforum/vsluhforumID3/102196.html#21 _Умные_!
У них Нумерация!!11111
Помнится кое-кто раньше все твердил, что CLANG никогда даже близко не сравнится с GCC!
)))
Кто ж мог подозревать, что в компилятор, единственным преимуществом которого декларировали скорость компиляции начнут вставлять патчи от Мелкомягких, которые будут замедлять работу его статического анализатора в 15 раз. Таким нечестным приемом Шланг действительно сможет обойти всех по показателю время работы. :)
> Кто ж мог подозревать, что в компилятор, единственным преимуществом которого декларировали скорость компиляции начнут вставлять патчи от Мелкомягких, которые будут замедлять работу его статического анализатора в 15 раз.То есть вы уверены:
- что это декларировалось как единственное преимуществом;
- что в GCC нет патчей от MS только потому что это открыто не афишируется.Как и все жертвы радикального маркетинга (по причине собственной некомпетентности), хоть от GNU, хоть от MS, вам кажется честным тот, кто больше всех кричит, что он якобы честный, а вовсе не тот, кто честно говорит все как есть, даже если большинству это не нравится.
> - что в GCC нет патчей от MS только потому что
> это открыто не афишируется.Да, пусть. Лишь бы здорове ^W CLA FSF-у под/для GPLv3+ отписали.
Компиляция и статистический анализ - это вещи разные.
К тому же непонятна сходу полезность/бесполезность более лучшего, но и более медленного анализатора.
> статистический анализстатический
> Помнится кое-кто раньше все твердил, что CLANG никогда даже близко не сравнится
> с GCC!
> )))Да, теперь шлангистам есть, чем ответить: они усиленно форсят сравнение.
Очень люблю ту часть, где они считают __проценты__, сколько ещё ядра fbsd [или чего у них там] не собирает их binutils-замена. "80% совместимости", представляете?!
>> Помнится кое-кто раньше все твердил, что CLANG никогда даже близко не сравнится с GCC!
>> )))
>
> Да, теперь шлангистам есть, чем ответить: они усиленно форсят сравнение.
> Очень люблю ту часть, где они считают __проценты__, сколько ещё ядра fbsd [или чего у них там] не собирает их binutils-замена. "80% совместимости", представляете?!Так это были вы что ли? А то я уже забыл, кто именно.
А еще помнится, кто-то вначале твердил, что clang никогда не сможет собрать ядро ОС. Тоже не помню, кто именно так говорил, помню только что он очень упорно стоял на своем.
Самое интересное, чем всех этих людей так задевает сам факт существования llvm/clang?
>кто-то вначале твердил, что clang никогда не сможет собрать
> ядро ОС. Тоже не помню, кто именно так говорил, помню только
> что он очень упорно стоял на своем.Сам придумал, сам поспорил? Сам-о-стоятеный!
> Самое интересное, чем всех этих людей так задевает сам факт существования llvm/clang?
Вы не понимаете, над Вами смеются. Я ж говорю, мажорно-позитивная новость.
Очень радует, как проприертарщики переписывают GPL-код. Очень!! Потеют, пыжатся. Мо-лод-цы же. GPL работает.
>>кто-то вначале твердил, что clang никогда не сможет собрать ядро ОС. Тоже не помню, кто именно так говорил, помню только что он очень упорно стоял на своем.
>
> Сам придумал, сам поспорил? Сам-о-стоятеный!Боитесь, что про вас плохо подумают?
Про тех, кто плохо думет, не разбираясь, обычно тоже плохо думают, без разбору.>> Самое интересное, чем всех этих людей так задевает сам факт существования llvm/clang?
>
> Вы не понимаете, над Вами смеются. Я ж говорю, мажорно-позитивная новость.Андреи Митрофановы смеются над Анонимом.
> Очень радует, как проприертарщики переписывают GPL-код. Очень!! Потеют, пыжатся. Мо-лод-цы же. GPL работает.
Все-таки похоже это был кто-то из Андреев Митровановых.
> Очень радует, как проприертарщики переписывают GPL-код. Очень!! Потеют, пыжатся. Мо-лод-цы
> же. GPL работает.Митрофанов, вы что-то сегодня рановато газовать начали. какой gpl код, кто переписывает? сгоняйте молодого за закуской, если самому ходить лень.
>> Очень радует, как проприертарщики переписывают GPL-код. Очень!! Потеют, пыжатся. Мо-лод-цы
> Митрофанов, вы что-то сегодня рановато газовать начали. какой gpl код, кто переписывает?
> сгоняйте молодого за закуской, если самому ходить лень.Мозги совсем пропил, проецирующий, родной? wiki.freebsd.org/GPLinBase
---"пьяные финны ... над фамилиями чехов."
MIT, BSD for-ever. Нет gpl. Ограничивать свободу ради свободы - это то ещё извращение.
Мир свободного ПО уже устоялся и 80 давно прошли GPL изжила себя, вот. Да и тем более ей уже и во вред начинаются пользоваться. Лол.
> MIT, BSD for-ever. Нет gpl. Ограничивать свободу ради свободы - это то
> ещё извращение.Ты пишешь это с xBSD? А то и с macos-x?? Чем докажешь?!
> Мир свободного ПО уже устоялся и 80 давно прошли GPL изжила себя,
> вот. Да и тем более ей уже и во вред начинаются
> пользоваться._Тебе_-то во вред? И друзьям твоим проприертарным?
Я повторю, коль медленно доходит: GPL работает.
Та-ачта-а, "изжила" = враньё.
>Лол.
Отставить нервные смешки в строю. Сми-и-ир... на! Прожолжаем экзекуции.
>> Самое интересное, чем всех этих людей так задевает сам факт существования llvm/clang?
>
> Вы не понимаете, над Вами смеются. Я ж говорю, мажорно-позитивная новость.
>>
>> Андреи Митрофановы смеются над Анонимом....
>>Лол.
>
> Отставить нервные смешки в строю. Сми-и-ир... на! Прожолжаем экзекуции.Здесь уже Андреи Митрофановы пытаются подражать Анониму.
И судя по количеству постов, которые Андреи Митрофановы тратят на каждую новость про LLVM, им все-таки очень мешает само существование как пермиссивных лицензий, так и продуктов на основе этих лицензий.
> MIT, BSD for-ever. Нет gpl. Ограничивать свободу ради свободы - это то ещё извращение.
>Мир свободного ПО уже устоялся и 80 давно прошли GPL изжила себя, вот. Да и тем более ей уже и во вред начинаются пользоваться. Лол.
>>
>> _Тебе_-то во вред? И друзьям твоим проприертарным?
>> Я повторю, коль медленно доходит: GPL работает.
>> Та-ачта-а, "изжила" = враньё.Аноним корректирует свою нейронную сеть...
Допустим, GPL вполне себя оправдывает в определенных социальных слоях. И действительно _работает_, точнее ее адепты продолжают _работать_ (больше). То есть вопрос в том, к какому сообществу кто принадлежит.
> Ограничивать свободу ради свободы - это то ещё извращение.
А здесь Аноним по-прежнему согласен сам с собой.
>> MIT, BSD for-ever. Нет gpl. Ограничивать свободу ради свободы - это то
>> ещё извращение.
> Ты пишешь это с xBSD? А то и с macos-x?? Чем
> докажешь?!
>> Мир свободного ПО уже устоялся и 80 давно прошли GPL изжила себя,
>> вот. Да и тем более ей уже и во вред начинаются
>> пользоваться.
> _Тебе_-то во вред? И друзьям твоим проприертарным?
> Я повторю, коль медленно доходит: GPL работает.в сортире? или где? посмотри наконец-то статистику - под MIT/BSDL/X11/Apache создается больше открытых проектов чем под всеми версиями GPL.
>>> MIT, BSD for-ever. Нет gpl. Ограничивать свободу ради свободы - это то
>> Я повторю, коль медленно доходит: GPL работает.
> в сортире? или где?Да. Твоя голова -- очередной тому пример.
>посмотри наконец-то статистику - под MIT/BSDL/X11/Apache создается
> больше открытых проектов чем под всеми версиями GPL.Враньё! Оно же -- статистика от прихвостней микрософта блэкдаков.
https://lwn.net/Articles/731722/
> Они уже совсем Большие и ...Что "совсем Большие" --- это точно. Не затруднит размер этого дела для публики огласить?
инвест...финансовые спекулянты по другому не понимают.
А жрать разработчикам что-то надо.
>GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода),Скромные, работящие ребяты. Мо-лод-цы.
Очень мажорно и пятнично. Ура.
> - В статическом анализаторе добавлена поддержка автоматического доказателя теорем Z3
> созданного в Microsoft Research для верификации кода своих продуктов. По
> сравнению с предлагаемым по умолчанию доказателем теорем Z3 работает примерно в
> 15 раз медленнее, но позволяет обрабатывать более сложные запросы. Для включенияУжо-то GPLv3+ - ники-то обзавидуются!1 Микрософт!1111 Невиданный успех и прорыв.
...
> архитектуры x86 добавлена поддержка CPU Intel Goldmont,"Что такое `сколопендра`, я не знаю. Но звучит красиво!"
сколопендра - это многоножка, если от Msft, то человеческая :-D
> сколопендра - это многоножка, если от Msft, то человеческая :-DНадо прекращать писать на опенет. Говорят, мазги разжижает....
https://www.anekdot.ru/id/-112521043/
https://otvet.mail.ru/question/55886760
>> сколопендра - это многоножка, если от Msft, то человеческая :-D
> Надо прекращать писать на опенет. Говорят, мазги разжижает....
> https://www.anekdot.ru/id/-112521043/
> https://otvet.mail.ru/question/55886760закусывать надо, Митрофанов, закусывать.
Мажорно и пятнично - потому что 5-я мажорная версия?
Пусть пилят. Даже мне, пользователю GCC, от них есть польза -- в моей любимой IDE кусок Шланга используется для реалтаймового парсинга кода.
да и открытые драйвера на видео (кроме intel) активно его используют
Местным аналитикам, все что не жпл то враг народа...
> GCC-совместимогоНе хватает звёздочки и мелкого шрифта: "только вложенные функции и VLA будут примерно никогда".
> и VLA будут примерно никогдаДа есть оно [variable length arrays] там. И для сишного – поддержка С99 все же "обязывает". И для плюсов (вроде как по умолчанию, пока не отключишь с помощью "-Werror=vla").
> только вложенные функции и VLA будут примерно никогдаВложенные функции в C требуют исполняемого стека. Или ещё какой-то ёмкости, которая одновременно write и execute. В C++/rust ещё можно выкрутиться имея разные типы указателей для функций захватывающих окружение на стеке и для функций не захватывающих его, но в C так не удастся. Точнее опять же можно, сделать и это (через расширение языка), но не тем способом, как это сделано в gcc.
И кому нужны такие вложенные функции? Их никто и не пользует.
Честно говоря, вообще не понимаю смысла во вложенных функциях в С.
Единственное, что приходит в голову - в комбинации с другим gcc-расширением, statement expressions, можно изобразить типа-лямбды; но учитывая, что лямбды получатся локальные (валидные только в скоупе функции, где они объявлены), их не получится использовать там, где они особо бы пригодились - как колбэки в FSM-серверах на libevent/libev/libuv, - польза очень сомнительная.
"Честно говоря, вообще не понимаю смысла во вложенных функциях в С.
Единственное, что приходит в голову - в комбинации с другим gcc-расширением, statement expressions, можно изобразить типа-лямбды; но учитывая, что лямбды получатся локальные (валидные только в скоупе функции, где они объявлены), их не получится использовать там, где они особо бы пригодились - как колбэки в FSM-серверах на libevent/libev/libuv, - польза очень сомнительная."
Мне лично очень нехватало вложеных функций после ухода с Паскаля/Дельфы. Заменять их приходилось костылями, к коим с течением времени привык настолько что они кажутся теперь не костылями а родными протезами.
это прекрасная штука. то что они отсутствуют в С/С++ илюстрирует родовую травму этих языков.
Так что да - если вы никогда не програмировали с ними, то вьехать в их необходимость получится только с опытом.
Я программирую в основном на языках, где есть полноценные замыкания. Польза от них настолько очевидна, что не обсуждается. А вот польза от банальных вложенных функций не ясна.
>А вот польза от банальных вложенных функций не ясна.фложенная функция видит контекст своего вызова - локальные переменные функции-родителя в их числе. это примерно тоже самое что и метод структуры/класса. только вместо класса - локальные переменные родителя. сейчас для того чтобы передать контекст, надо делать структуру, и ее передавать ссылкой. а вложенной функции, в паскале например, всей этой возни не нужно - даже затрат на передачу контекста нет, ибо контекст получается через стек.
собственно по статье в вике https://ru.wikipedia.org/wiki/%D0%97%D0%...
"замыкание" и вложенная функция это одно и тоже.
только тут есть один нюанс - замыкание в своем самом гибком варианте реализуемо в языках интерпретируемых. в компилирующем языке, реализовать такое поведение можно только тяжелыми костылями (поэтому досихпор замыканий нормальных и не было, если это не шаблоны). а вот вложенная функция - как раз легко реализуема, и без затрат по коду/производительности.
> bugpronхехе, pron
Правильно ли я понял, что теперь можно на лету компилировать C/C++ код и интерпретировать его?
теперь это когда?
Вот-вот, и я о том же подумал.
С другой стороны непонятно почему бы не взять Lua, Python или %любимый AST интерпретатор со своим GIL и другими удобствами% ?
Кто-нибудь использует LLVM под Windows? Я скачал официальные бинари clang, попробовал скомпилить свой проект. Компилит в 18 раз медленнее mingw, жуть какая-то. Может я что-то не так делаю? поделитесь успешным опытом.На Mac,FreeBSD такой херни не было, компилил шустро и даже быстрее gcc.
> Компилит в 18 раз медленнее mingw, жуть какая-то.Вендузятник должен страдать.
Отлично! Нужная вещь. Ждемс в бэкпортах.
http://apt.llvm.org/
> http://apt.llvm.org/Спасибо. Хотя их и так перекладывают в стандартные бэкпорты, но с задержкой.
А при помощи Clang можно скомпилировать ядро Линукса? Невозможно! А вот, коллекция компиляторов GNU GCC может скомпилировать ядро Линукса. Да что там говорить, GNU GCC -- это основная компилирующая лошадка линуксоида.
Он не может компилировать только потому что разработчики ядра решили использовать по максимуму внутренние возможности gcc.
Скорей баги, чем возможности.
если у разработчиков ядра - не хватает мозгов использовать только стандарт языка, а обязательно нужны GNU расширения - то кто им доктор ?
gnu расширения в llvm в общем сохранены. Баги, из-за которых компилируется в принципе неправильный код - не все, поскольку это clean room разработка, и копирует только то, что либо документировано, либо удается легко обнаружить.
Это называется вендорлок, чувак. Такая вот типасвобода.
> А при помощи Clang можно скомпилировать ядро Линукса? Невозможно! А вот, коллекция
> компиляторов GNU GCC может скомпилировать ядро Линукса. Да что там говорить,
> GNU GCC -- это основная компилирующая лошадка линуксоида.А ядро фрибзди компилируется как шлангом, так и gcc. Какие нетривиальные выводы сделает из этого анонимный эксперт?
> А ядро фрибзди компилируется как шлангом, так и gcc.а давно пробовали? А запустить скомпилированное? На x86 архитектуре?
world WITHOUT_CLANG, насколько я знаю, сломан уже в 10.0
>> А ядро фрибзди компилируется как шлангом, так и gcc.
> а давно пробовали? А запустить скомпилированное? На x86 архитектуре?А где-то с полгодика назад. И да, запустилось и проработало с пару неделек.
> world WITHOUT_CLANG, насколько я знаю, сломан уже в 10.0Про мир я в курсе - обратите внимание на "ядро" в "ядро фрибзди".
> Про мир я в курсехотя, казалось бы - должно быть ровно наоборот - уж если где и быть подобным граблям, то уж никак не в коде bin/ls. Аднакаж...
(специально для проспавших первый урок, которые щас набигут - нет, это не код плохой, это gcc в freebsd 4.2.1 2007го года, последний с еще не анально-огороженной лицензией, сейчас уже неудивительно, что люди перестают специально обращать внимание на совместимость с его багами)
>> Про мир я в курсе
> хотя, казалось бы - должно быть ровно наоборот - уж если где
> и быть подобным граблям, то уж никак не в коде bin/ls.
> Аднакаж...LLVM. Не собирается шлангом.
Ну и шланго-специфические опции типа -fsanitize=safe-stack, на которых спотыкается gcc.
Или когда gcc упорно и не смотря на вполне правильно выглядящий -isystem= в env читает заголовочные файлы из /usr/local/include. Потом ... а потом мне надоело маяться этим самым.
> LLVM. Не собирается GCC.
> LLVM. Не собирается шлангом. [gcc'ем на самом деле]ну так у большинства, полагаю, WITHOUT для того и был, чтобы LLVM и не [пере]собирать - поскольку он плюсовый, то его пересборка даже на мощном ядре занимает дофига времени, процентов 80 от общего world, а не потому что мы за мир во всем мире и против проклятых проприетарастов.
сейчас, увы, пользы от WITHOUT_CLANG/LLVM около нуля.
> Поддержка расширения для использования сопрограмм в коде на C++ (пример кода).Ужас какой-то. Интересно посмотреть на код, который будет сгенрирован в результате.