После шести месяцев разработки подготовлен (http://lists.llvm.org/pipermail/llvm-announce/2016-September...) релиз проекта LLVM 3.9 (http://llvm.org/) (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.В новом выпуске добавлен оптимизатор ThinLTO, обеспечена совместимость с ABI libstdc++ (GCC), реализована поддержка всех возможностей OpenCL 2.0 и возможностей OpenMP 4.5, не связанных с привлечением дополнительных аппаратных вычислительных устройств, добавлен инструмент clang-include-fixer, в компоновщике lld существенно улучшена поддержка ELF и добавлена начальная поддержка LTO-оптимизаций LTO.
Улучшения (http://llvm.org/releases/3.9.0/tools/clang/docs/ReleaseNotes...) в Clang 3.9:- Расширены средства диагностики Clang, позволяющие выявлять больше проблем и более точно формулировать их суть. Добавлено новое предупреждение "-Wcomma", диагностирующее применение встроенного оператора ",", а также предупреждения "-Wfloat-overflow-conversion" и
"-Wfloat-zero-conversion" для выявления переполнения при преобразовании числа с плавающей запятой в целое и преобразования ненулевого числа с плавающей запятой в нулевое целое значение;
- Реализована полная поддержка всех возможностей стандарта OpenCL 2.0 (https://www.opennet.me/opennews/art.shtml?num=38476), в том числе в новой версии появилась встроенная функция Pipe, поддержка динамического параллелизма, добавлены функции преобразования адресного пространства to_{global/local/private}, поддержка атрибута nosvm и pragma opencl_unroll_hint. Также улучшены средства диагностики и генерации блоков Clang, используемых в коде ядра OpenCL;- Реализованы все возможности стандарта OpenMP 4.5 (https://www.opennet.me/opennews/art.shtml?num=43412) (Open Multi-Processing), предоставляющего средства для применения методов параллельного программирования в программах на языках Си и Си++, за исключение средств для привлечения дополнительных аппаратных обработчиков (offloading). Значительно улучшено качество генерации конструкций OpenMP, что позволило получать на выходе заметно более быстрый и стабильный код;
- Добавлена поддержка фреймворка RenderScript (https://developer.android.com/guide/topics/renderscript/comp...) (включается опцией "-x renderscript" или при обработке файлов с расширением ".rs");
- Расширена экспериментальная поддержка будущего стандарта C++1z, (-std=c++1z), например, добавлены атрибуты [[fallthrough]], [[nodiscard]] и [[maybe_unused]], реализована возможность объединённой инициализации классов с базовыми классами;- В статический анализатор добавлена проверка некорректного использования MPI API в C и C++, добавлены проверки утечек памяти и обращений к уже освобождённым блокам на платформе Windows. В состав включена экспеиментальная реализация утилиты scan-build, переписанная на языке Python.
- Добавлен новый интструмент clang-include-fixer, позволяющий автоматически вставить недостающие директивы "#include";
- В linter clang-tidy добавлена (http://llvm.org/releases/3.9.0/tools/clang/tools/extra/docs/...) большая порция новых проверок;
Основные новшества (http://llvm.org/releases/3.9.0/docs/ReleaseNotes.html) LLVM 3.9:- Компоновщик LLD доведён (http://llvm.org/releases/3.9.0/tools/lld/docs/ReleaseNotes.html) до рабочего состояния и теперь может связывать реальные приложения в формате ELF, включая сам LLVM и Clang, а также большинство приложений пространства пользователя FreeBSD. В LLD также добавлена поддержка оптимизации на этапе связывания (LTO) и объединение идентичных блоков кода. В дополнение к ранее поддерживаемым архитектурам x86, x86-64, MIPS, PowerPC и PPC64, добавлена поддержка ARM/Thumb, x32 ABI и MIPS N64 ABI;
- Обеспечена совместимость с GCC ABI. Многие дистрибутивы Linux (Fedora, Debian, Ubuntu) перешли на использование нового GCC ABI для обхода несовместимостей с C++11 в libstdc++, что, в свою очередь, обернулось появлением несовместимостей (https://llvm.org/bugs/show_bug.cgi?id=23529) с другими компиляторами, в том числе с Clang. В LLVM 3.9 добавлены патчи для решения возникших проблем;
- Добавлена поддержка ThinLTO (http://blog.llvm.org/2016/06/thinlto-scalable-and-incrementa...) для выполнения оптимизации на этапе связывания, который может быть активирован при компиляции и связывании с опцией "-flto=thin". При использовании ThinLTO LTO-оптимизация разделена на три части: генерация промежуточного кода на этапе компиляции, запуск плагина Thin в компоновщике для комбинирования суммарных данных и выполнения общего анализа, и запуск бэкенда ThinLTO для применения оптимизаций в параллельном режиме;- Внесены многочисленные улучшения в бэкенды для архитектур ARM, AArch64, MIPS и PowerPC. В том числе добавлена поддержка процессоров Qualcomm Kryo, Broadcom Vulcan и Cortex-R8;
- Для архитектуры x86 добавлена поддержка CPU Intel под кодовыми именами Skylake Server и Knights Landing, примечательных наличием инструкций AVX-512;
- В бэкенд AMDGPU добавлена поддержка образов шейдеров OpenGL, хранилища буферов, атомарных счётчиков и вычислительных расширений шейдеров. Прекращена поддержка Mesa 11.0.x (требуется Mesa 12 (https://www.opennet.me/opennews/art.shtml?num=44757));
- Прекращена поддержка сборочной системы autoconf в пользу CMake. Для сборки LLVM теперь требуется CMake 3.4.3 или более новая версия.
URL: http://lists.llvm.org/pipermail/llvm-announce/2016-September...
Новость: http://www.opennet.me/opennews/art.shtml?num=45072
Clang может собрать ядро linux?
LLVMLinux - пока только с некоторым набором патчей (три десятка примерно).
> Clang может собрать ядро linux?Не так. Правильный вопрос: может ли ядро Линукс быть очищено от gcc-зависимостей и прочего мусора, чтобы его можно было бы собирать правильными компиляторами с внятной системой команд и внятными сообщениями об ошибках, не говоря о прочих преимуществах clang.
Да, clang может собирать ядра ОСей общего назначения. Тому подтверждение давным давно собираемый clang-ом мейнстрим FreeBSD.
Это не проблема сообщества LLVM разбираться в этой куче бардака под названием "код ядра Linux".
Это проблема сообщества Linux привести в порядок кодовую базу своего ядра.
Иными словами: пока нет, т.к. в коде Linux есть специфические для GCC вещи.// другой Аноним
Это не проблема сообщества Linux разбираться с кривыми недокомпиляторами.
> Это не проблема сообщества Linux разбираться с кривыми недокомпиляторами.Зеркальная реплика по форме "сам дурак" - это похоже все, на что вы надеетесь, чтобы хоть как-то попытаться унять вашу боль. Других аргументов у вас нет.
Боль тут демонстрируют как раз поклонники шланга.Ответьте пожалуйста на простой вопрос: какую пользу получат разработчики ядра от возни с переписыванием фрагментов кода в которых используются gcc-специфичные расширения ?
> Боль тут демонстрируют как раз поклонники шланга.
> Ответьте пожалуйста на простой вопрос: какую пользу получат разработчики ядра от возни
> с переписыванием фрагментов кода в которых используются gcc-специфичные расширения ?Польза — от возможности подтвердить правильность написанного кода больше чем одним компилятором. Возможность в дальнейшем выяснить, где слабое звено (код, компилятор1, компилятор2,.., компиляторN), если что-то перестало работать, и исправить его.
> Польза — от возможности подтвердить правильность написанного кода больше чем одним
> компилятором.Ядро Linux - никогда и не декларировало совместимость с стандартами си. Оно слишком системное чтобы быть всего лишь стандартным си.
Очевидный пример: в стандартном си вообще нельзя декларировать и использовать функции с переменным количеством аргументов. А в gcc такое расширение есть очень давно и оно таки удобное.
> Возможность в дальнейшем выяснить, где слабое звено (код, компилятор1, компилятор2,..,
> компиляторN), если что-то перестало работать, и исправить его.А заодно получить проприетарный тулчейн в рыло "потому что лицензия позволяет" под кучу железяк. Скомпилят под какую-нибудь федору 15-й версии, и хоть на ушах стой но подымай именно эту хню. Потому что ни подо что другое тулчайн не существует.
> Очевидный пример: в стандартном си вообще нельзя декларировать и использовать функции с переменным количеством аргументов. А в gcc такое расширение есть очень давно и оно таки удобное.http://www.gnu.org/software/libc/manual/html_node/Variadic-F...
Стандартная библиотека, а расширение gcc.
> а расширение gcc"а не расширение gcc", конечно
> Очевидный пример: в стандартном си вообще нельзя декларировать и использовать функции с
> переменным количеством аргументов. А в gcc такое расширение есть очень давно
> и оно таки удобное.Наверно, printf & co. нам всем приснился, да?
>Ядро Linux - никогда и не декларировало совместимость с стандартами си. Оно слишком системное чтобы быть всего лишь стандартным си."Компилятор всего лишь инструмент". Да, было.
>Очевидный пример: в стандартном си вообще нельзя декларировать и использовать функции с переменным количеством аргументов.
Как же тогда работает printf()??? Наверное это магия!
>А заодно получить проприетарный тулчейн в рыло "потому что лицензия позволяет" под кучу железяк.
Вот этот бред вообще не распарсил. Какой такой "проприетарный тулчейн"? С чего бы ему взятся?
>Скомпилят под какую-нибудь федору 15-й версии, и хоть на ушах стой но подымай именно эту хню. Потому что ни подо что другое тулчайн не существует.
Эх сколько я тулчейнов чудных видел в эмбедовке! Ах какие ископаемые там были gcc!!! ИЧСХ в бинаре и только под ископаемое окружение.
> Ответьте пожалуйста на простой вопрос: какую пользу получат разработчики ядра от возни с переписыванием фрагментов кода в которых используются gcc-специфичные расширения ?А кто сказал, что они (разработчики ядра Linux) должны получить от этого пользу. Было сказано, что это их проблемы. Вот во FreeBSD проблем с переходом на другой компилятор особо не было и код переписывать не пришлось.
О пользе заговорили вы. Значит вам clang пользы не приносит. И если у вас от этого ничего не болит, тогда зачем вам знать, какая другим польза от clang.
Другой вопрос, какую пользу они (разработчики ядра Linux) получили от того, что привязали ядро к конкретному компилятору, наплевав на стандарты языка. А потом вдруг появился другой компилятор, такой что некоторые до сих упорно продолжают доказывать, что от него якобы пользы нет.
> Боль тут демонстрируют как раз поклонники шланга.
Если вы уверены что у вас боли нет, тогда у вас не должно быть причин для беспокойства.
Поклонники, да, обычно всегда испытывают боль. Просто кроме поклонников есть ещё и специалисты, которые умеют пользоваться без поклонения. Видимо вы об этом не знали.
> А кто сказал, что они (разработчики ядра Linux) должны получить от этого пользу.Тогда зачем им этим заниматься. Они как бы шлангофилам ничем не обязаны.
> Вот во FreeBSD проблем с переходом на другой компилятор особо не было и код переписывать не пришлось.
Никому не интересная возня в песочнице.
> Другой вопрос, какую пользу они (разработчики ядра Linux) получили от того, что привязали ядро к конкретному компилятору, наплевав на стандарты языка.
В стандартах языка хотя бы asm() есть ?
> Просто кроме поклонников есть ещё и специалисты, которые умеют пользоваться без поклонения. Видимо вы об этом не знали.
Как мило. Особенно после всех вами написанных бредней.
В стандартах языка Си asm() и функции с переменным числом аргументов присутствуют. А вы явно не знаете этого языка.
И что, в стандарте описана передача значений в регистрах в/из ассебмлерного кода ?Кстати причем здесь вообще функции с переменным числом аргументов ? Это единственное что вы знаете в C ?
Про переменное число аргументов это случайность. Выше было сообщение, где утверждается, что этого нет в стандарте, я по невнимательности сюда про это ответил. Я не утверждаю, что я знаю Си на 100% и что умею им на все 100% пользоваться. Но ваше ошибочное утверждение, что asm() нет в стандарте, указывает на то, что вы сами не сильно разбираетесь в это языке.
> И что, в стандарте описана передача значений в регистрах в/из ассебмлерного кода ?Это описано в спецификации ABI, которую обязаны поддерживать все компиляторы, которые совместимы с целевой платформой. Так что да, это описано в стандарте, хоть и не самого языка.
>> И что, в стандарте описана передача значений в регистрах в/из ассебмлерного кода ?
> Это описано в спецификации ABI, которую обязаны поддерживать все компиляторы, которые совместимы
> с целевой платформой. Так что да, это описано в стандарте, хоть
> и не самого языка.:-) Нет, не часть ABI "для всех компиляторов"...
(У gcc кстати и синтаксис asm не совсем стандартный. Хотя и правильный...)
>>> И что, в стандарте описана передача значений в регистрах в/из ассебмлерного кода ?
>> Это описано в спецификации ABI, которую обязаны поддерживать все компиляторы, которые совместимы
>> с целевой платформой. Так что да, это описано в стандарте, хоть
>> и не самого языка.
> :-) Нет, не часть ABI "для всех компиляторов"...
> (У gcc кстати и синтаксис asm не совсем стандартный. Хотя и правильный...)Гм... Тогда уж самый Ъ это синтаксис непосредственно орт Intel. А не от AT&T
> В стандартах языка Си asm() и функции с переменным числом аргументов присутствуют.А реально такой код может собрать только gcc и в меньшей степени шланг. Про всякие студии даже говорить неудобно. Ты уверен что в какой-нибудь студии или интел ц - asm() работает? И если да то хоть как-то совместим по синтаксису с тем что gcc использует?
> А вы явно не знаете этого языка.
Да как сказать? Мои знания в этом языке мне не нравятся и можно их здорово улучшить. Чем я и занимаюсь. Ты вот можешь показать какой стандарт определяет asm().
> А кто сказал, что они (разработчики ядра Linux) должны получить от этого
> пользу. Было сказано, что это их проблемы.У них как раз нет проблем. Они этим не страдают, они этим наслаждаются, используя полезные фичи gcc с пылу с жару. Без них они все-равно буксовали бы по черному. Им и асм местами нужен, и функции с переменным числом параметров и прочие явно нестандартные вещи.
А фрибсд как раз таки один большой кусок проблем. Как система вообще.
> А фрибсд как раз таки один большой кусок проблем. Как система вообще.Назовите несколько проблем FreeBSD.
> Назовите несколько проблем FreeBSD.- Нет нормального пакетника. Ну как, пакетник технически уже есть. Но пакетами пользоваться в нормальном виде вы не умеете и не лечитесь. Толку с такого пакетника?
- Виртуализация в пролете. Не надо своими альфа-версиями махать. Когда они будут сравнимы по фичам, скорости и стабильности с остальными решениями и на этом кто-то рискнет здоровьем запиливать продакшны - тогда и поговорим.
- Поддержка железа хромая. На десктопе дров для половины GPU нет. То что нвидия вам блоб закинула под пару архитектур - вообще не ваша заслуга ни разу.
- Экосистема - куча проприетарного жлобья. Которое больше всего боится что конкурент на их технологиях разовьется. FFFUUU.
- Комьюнити под стать. Ну вот изен. Изен расскажет как все круто. Но при первой же проблеме - процитирует ман или просто сыбет в кусты. Зарулить проблему и решить задачу все это убогое блеяние никому разумеется не поможет. В школе может и не учат, но на все ситуации манов не напишешь. И не всегда удается опереться на предыдущий опыт.
- Сказки такизадумано и решимпроблемупотомапокажритечтодали - устарели и не катят.
> - Виртуализация в пролете.вот тут не соглашусь. jail'ы вполне себе аналог openvz. но требуют больше ручной работы, чем бинарные дистрибутивы. и да, контейнеризация эффективнее паравиртуализации, факт.
> вот тут не соглашусь. jail'ы вполне себе аналог openvz.Только openvz был пригоден для продакшна на продажу 10 лет назад. И это был шаг вперед по сравнению с shared помойками. А jails где были?
А сейчас хостинги все чаще продают full virt. Так изоляция лучше, клиент полностью рулит своим окружением, не мыкаясь с тем вгрузит ли админ нужный модуль и вообще запуская ос какая ему там удобна. Оверхеда конечно больше, зато меньше напряга клиентам и саппорту а сервера один черт мощные, с SSD и проч. Вычисления и память могут быть под 95-99% запросто. IO похуже, разумеется. Но со всякими продвинутостями типа virtio во все поля может быть и довольно прилично уже.
> ручной работы, чем бинарные дистрибутивы.
За такие вещи бзды послали даже всякие яхи и опачи.
> и да, контейнеризация эффективнее паравиртуализации, факт.
Это так, но зато хуже изоляция и одно ядро на всех что накладывает некие технические лимиты. Как то - разная конфигурация кернелспейса становится невозможна.
да какбе десять лет назад уже были и jails, и solaris zones.> А сейчас хостинги все чаще продают full virt.
ага. а вот внутри их всё чаще тот же докер, т.е. возврат к контейнеризации, но с немного другой стороны.
> да какбе десять лет назад уже были и jails, и solaris zones.Только jails тогда IIRC совсем не умели лимиты а-ля OVZ и виртуалихацию сети. А без этого хрен такой контейнер продашь хомякам на растерзание. А солярис 10 лет назад был IIRC проприетарный. Это было приговором для технологии уже тогда. А сегодня проприетарщики просто нерукопожатные типы.
> ага. а вот внутри их всё чаще тот же докер, т.е. возврат
> к контейнеризации, но с немного другой стороны.Докера используют для своих сервисов обычно, а не на продажу. Они чуть более дружелюбные и менее требовательные чем рандомные хомяки с рандомным крапом в качестве workload-a. Full virt хорош тем что хомяк получает квант ресурсов а что на них он запустит, с каким ядром и конфигурацией этого - его проблемы. Меньше недовольства хомякам и меньше головняка саппортам.
>> да какбе десять лет назад уже были и jails, и solaris zones.
> Только jails тогда IIRC совсем не умели лимиты а-ля OVZ и виртуалихацию
> сети.Jails лимитились как и юзеры - через общий login.conf, если не ошибаюсь.
OVZ тогда была проприетарной и в общем случае нуждалась в допиливании под конкретный дистрибутив (нужно было заменять родное ядро Linux на проприетарное).
Виртуализации сети до недавнего времени в jail не было, был общий сетевой стэк, подозреваю, использовалось тэгирование трафика и его лимитирование средствами пакетного фильтра.> А без этого хрен такой контейнер продашь хомякам на растерзание.
Да вот ведь, и Jail's покупали!
> Да вот ведь, и Jail's покупали!Видно все раскупили - не осталось уже практически...
> Докера используют для своих сервисов обычно, а не на продажу.да вы и про heroku, небось, ещё не слышали, хотя уже шесть лет прошло.
>> вот тут не соглашусь. jail'ы вполне себе аналог openvz.
> Только openvz был пригоден для продакшна на продажу 10 лет назад. И
> это был шаг вперед по сравнению с shared помойками. А jails
> где были?Jails и были в продакшене с начала 2000-х. Только IBM выделила в это же время на GNU/Linux около миллиарда долларов, и все метнулись их осваивать, не разбирая дороги, что называется. Такой хайп поднялся, а про работающие решения забыли.
Следующий шаг к просветлению - задуматься, почему ИБМ выделела на гну.линукс, а не на бзд.
> Jails и были в продакшене с начала 2000-х. Только IBM выделила в
> это же время на GNU/Linux около миллиарда долларов,А могли бы и бздам дать. Если бы их проект не был невнятной академкуетой для сферического вакуума, с невменяемым управлением проектом и непонятным вектором развития.
> и все метнулись их осваивать, не разбирая дороги, что называется.
"Когда дают - нужно брать, от других не отставать" (с).
> Такой хайп поднялся, а про работающие решения забыли.
Потому что нахрен никому не надо геморрой и камлания на системный культ в качестве решения их задач.
>> Назовите несколько проблем FreeBSD.
> - Нет нормального пакетника. Ну как, пакетник технически уже есть. Но пакетами
> пользоваться в нормальном виде вы не умеете и не лечитесь. Толку с такого пакетника?Просветите нас что не умеет pkg из того что умеет "нормальный" пакетник. Мне очень интересно.
> - Виртуализация в пролете. Не надо своими альфа-версиями махать. Когда они будут
> сравнимы по фичам, скорости и стабильности с остальными решениями и на
> этом кто-то рискнет здоровьем запиливать продакшны - тогда и поговорим.
> - Поддержка железа хромая. На десктопе дров для половины GPU нет. То
> что нвидия вам блоб закинула под пару архитектур - вообще не
> ваша заслуга ни разу.Как и не линукса заслуга, правда?
> - Экосистема - куча проприетарного жлобья. Которое больше всего боится что конкурент
> на их технологиях разовьется. FFFUUU.Утизьбозезьмой! Патчи от "врага №1" приняли? Приняли! Все. Смиритесь. Microsoft тоже часть экосистемы. Про Android еще можем вспомнить и кто ТАМ экосистему формирует (со всем сопутствующим типа драйверов на SOC/GPU и т.д.) Qualcomm они безудержные альтруисты навеки преданые идеям СПО :))))
> - Комьюнити под стать. Ну вот изен. Изен расскажет как все круто.
> Но при первой же проблеме - процитирует ман или просто сыбет
> в кусты. Зарулить проблему и решить задачу все это убогое блеяние
> никому разумеется не поможет. В школе может и не учат, но
> на все ситуации манов не напишешь. И не всегда удается опереться
> на предыдущий опыт.Ну, комьюнити, чей стиль общения укладывается в фразу "because fuck you" оно как- бы специфично, не? Общаясь в LKML знать что тебя вполне могут обозвать говнюком и послать по матушке оно удовольствие не для всех. Ну не всех людей оно устраивает.
> - Сказки такизадумано и решимпроблемупотомапокажритечтодали - устарели и не катят.
> что не умеет pkg из того что умеет "нормальный" пакетниккак минимум:
- разделение порта по пакетам (devel, runtime, profile, etc)
- его нельзя обновлять по крону, обязательно поломается. а в debian stable можно потому, что у них есть понятие stable. а в freebsd для портов только current. да, я помню минорный апгрейд redis, который внезапно сменил api и всё перестало работать
- подключение дополнительных репозитариев, кроме штатного
>> что не умеет pkg из того что умеет "нормальный" пакетник
> как минимум:
> - разделение порта по пакетам (devel, runtime, profile, etc)Брр... apt get головного мозга.
Пакеты создаются в процессе сборки посредством правил make.
pkg.tar.xz являеться контейнером, что укажешь pkgng, то в нем и будет.# ls -d1 /usr/bsdports/databases/postgresql95*
/usr/bsdports/databases/postgresql95-client
/usr/bsdports/databases/postgresql95-contrib
/usr/bsdports/databases/postgresql95-docs
/usr/bsdports/databases/postgresql95-pgtcl
/usr/bsdports/databases/postgresql95-plperl
/usr/bsdports/databases/postgresql95-plpython
/usr/bsdports/databases/postgresql95-pltcl
/usr/bsdports/databases/postgresql95-server> - его нельзя обновлять по крону, обязательно поломается.
Ты админ локалхоста?
Первый вопрос который я задаю таким товарищам, когда они пытаются применить свои великие познания локалхостера в предприятии, а нахера вы обновляете систему? Реальные цели?>а в freebsd для портов только current. да, я помню минорный апгрейд redis, который внезапно сменил api и всё перестало работать
Да, я помню, когда трахался с компиляцией perl 5.18 и шлейфом за ним и с ним, для debian stable, потому что
1 кто-то в debian решил что все круто, _у нас_ все совместимо, у нас будет perl 5.20, но вот проблема - в этой версии довольно сильно поменяли обработку шаблонов и еще по мелочи,
2 такой же умник как ты решил обновить систему, ведь все круто, можно обновлять по крону,
3 и в результате деятельность пары сотен людей стала колом на день. И хорошо что только на день.
Ты получаешь систему как общественный продукт по нулевой стоимости "как есть", со всеми ее политиками и особенностями, и и ожидаешь что кто будет решать твои проблемы с приложениями?
Ты хоть один PR написал?И еще, погугли таки по буквам "управление конфигурациями".
>>> что не умеет pkg из того что умеет "нормальный" пакетник
>> как минимум:
>> - разделение порта по пакетам (devel, runtime, profile, etc)
> Брр... apt get головного мозга.
> Пакеты создаются в процессе сборки посредством правил make.
> pkg.tar.xz являеться контейнером, что укажешь pkgng, то в нем и будет.Вы не поняли. Речь шла о возможности раздробить пакет с исходным кодом, из которого порт собирается, на несколько пакетов. В системе на основе бинарных пакетов Вы можете выделить всё, что необходимо для рантайма - в один пакет. Всё, что необходимо для сборки - в другой. Фишка в том, что для пользования программой, вовсе не обязательно иметь в системе заголовочные файлы, объектники и т.д.
>> - его нельзя обновлять по крону, обязательно поломается.
> Ты админ локалхоста?
> Первый вопрос который я задаю таким товарищам, когда они пытаются применить свои
> великие познания локалхостера в предприятии, а нахера вы обновляете систему? Реальные
> цели?Ну например для своевременного получения обновлений безопасности, чтобы они оказались на боевом сервере "как только так сразу". Например, в debian, Вы можете включить спокойно включить например автоматические security-updates, и вероятность того, что у вас что-то поломается - почти нулевая, потому что таким образом вы будете получать только обновления безопасности.
> Да, я помню, когда трахался с компиляцией perl 5.18 и шлейфом за ним и с ним, для debian stable, потому что
Вы же могли просто откатиться на 5.18 и зафиксировать его гвоздиком (pin it!)... И вместо этого Вы собирали perl 5.18 самостоятельно? Вы понимаете, что Вы тот ещё деструктор? Надеюсь, что Вы хотя бы checkinstall-ом устанавливали. Иначе там после Вас дикая помойка осталась, которую крайне проблемно вычистить.
>> что не умеет pkg из того что умеет "нормальный" пакетник
> как минимум:
> - разделение порта по пакетам (devel, runtime, profile, etc)У нас точнее отделяются мухи от котлет - http://www.freshports.org/search.php?stype=name&method=prefi...
> - его нельзя обновлять по крону, обязательно поломается.
Необязательно.
> можно потому, что у них есть понятие stable. а в freebsd
> для портов только current. да, я помню минорный апгрейд redis, который
> внезапно сменил api и всё перестало работатьПоэтому нужно читать /usr/ports/UPDATING, чтобы отслеживать ключевые изменения.
> - подключение дополнительных репозитариев, кроме штатного
Прикинь, оно есть с 9.x версии: http://vasilisc.com/freebsd-pkg-repository
> Нет нормального пакетника. Ну как, пакетник технически уже есть.
> Виртуализация в пролете...
> Когда они будут сравнимы по фичам...
> Поддержка железа хромая...В чем конкретно проблема?
Ты хотел использовать FreeBSD в своих решения и не по ряду причин не смог?
Какие конкретно? Не смог запустить bhyve? Не справился с установкой пакетов?Ты копируешь дистрибутив по нулевой стоимости, и ожидаешь что кто-то будет заниматься твоими проблемами, в том числе вопросами твоего обучения?
Но ведь ты и в глаза ни одну *BSD OS не видел?
> Комьюнити под стать.
> Но при первой же проблеме - процитирует манТы не знаешь английский в базовом уровне?
RTFM - Read The Facking Manual
Читай же это гребаное руководство.Этой абреввиатуре уже лет 40 точно.
В моей практике, по руковоству FreeBSD системой управляют
совсем далекие от IT разработки люди.
>> А фрибсд как раз таки один большой кусок проблем. Как система вообще.
> Назовите несколько проблем FreeBSD.Ты.
User294, опять ты?> функции с переменным числом параметров
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
7.15 Variable arguments <stdarg.h>
Просто интересно, можете привести примеры gcc-зависимостей?
Сразу видно, что вы компиляторами пользоваться не умеете.Чтобы увидеть примеры зависимостей от GCC в коде ядра Linux - для этого достаточно запустить на этом коде любой другой компилятор, отличный от GCC.
Почему вы думаете FreeBSD удалось практически сразу перевести на CLANG? Потому что они сразу они изначально придерживались стандартов языка C. А не полагались на веру в единственно правильный компилятор. И сейчас не полагаются. Появится копилятор лучше CLANG - им будет несложно перейти на него.
Ты чего на личности то сваливаешься?
Умеет он или нет — про это твоё мнение не спрашивали. Пример gcc-зависимостей давай приводи раз вылез.
> Ты чего на личности то сваливаешься?
> Умеет он или нет — про это твоё мнение не спрашивали. Пример gcc-зависимостей давай приводи раз вылез.А вы значит ещё один, чья личность не позволяет определить зависимости кода от компилятора при наличии доступа к коду и компилятору. И вам нужны другие личности, которые бы эти самые зависимости привели.
> давай приводи раз вылез.
И раз уж ваша личность вылезла с требованием привести зависимости, когда их и так можно получить самостоятельно, тогда уж приведите пожалуйста необходимость самого приведения. Проще говоря, зачем вам понадобилось, чтобы вам это привели? И что вы с резузультатом этого приведения собирались делать? И вообще, какой именно ущерб вы усмотрели для своей личности? Ну, раз уж вы вылезли со своей личностью.
Демагог дешевый, тебя попросили привести конкретные примеры GCC-зависимостей.
> Демагог дешевый, тебя попросили привести конкретные примеры GCC-зависимостей.% portmaster graphics/vigra
...
===>>> graphics/vigra >> (5)===>>> The following actions will be taken if you choose to proceed:
Install graphics/vigra
Install graphics/OpenEXR
Install math/fftw3
Install lang/gcc
Install print/texinfo
Install math/fftw3-float
%
AVX-512 - сдаётся мне что оно сыро-глючно.
Учитывая что в sse и avx я нашёл пару багов:
_mm256_extract_epi8 возвращало нифига не 8 бит а все 16.
_mm_extract_epi8 как то коряво (тормозно) эмулировалась при сборке с версией sse где её нет.
А какие нибудь интересные нестандартные расширения как у гцц у шланга есть? И поддерживает ли он нестандарные расширения языков С и С++ от гцц?
гнушные расширения поддерживает процентов на 70. Насчёт его собственных - не в курсе
> А какие нибудь интересные нестандартные расширения как у гцц у шланга есть?Самой главной нестандартной фишкой CLANG явилась его полная поддержка стандартов языка C++. В то время как до этого "стандартом" других компиляторов было постоянно ломать стандарты языка, и не заботиться о поддержке стандартов, постоянно пытаясь доказывать что их собственные нестандартные фишки лучше чем у других.
Ничто не мешает делать нестандартные расширения. Другой вопрос, чтобы хотя бы один общий стандарт поддерживали.
> И поддерживает ли он нестандарные расширения языков С и С++ от гцц?
Частично поддерживает.
> Самой главной нестандартной фишкой CLANG явилась его полная поддержка стандартов языка C++Ты сабж то читал? Про ABI?
Только сейчас
> In the GCC 5.1 release libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list. These changes were necessary to conform to the 2011 C++ standard which forbids Copy-On-Write strings and requires lists to keep track of their size.https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a...
А вот что про это пишут для таких на "твоём" же шланге — http://libcxx.llvm.org
Секцию "Why a new C++ Standard Library for C++11?" читать до просветления.Тогда может и придёт понимание того, что о поддержке стандартов можно говорить только начиная с сабжа. Другими словами с "сегодня". А не со "вчера", "позавчера",.. "год назад",..
Все правильно, вы лишь подтвердили мои слова. Потому что в сообществе GCC, засуетились и стали поддерживать стандарты в догонку за CLANG.Это хорошо, что вы научились копипастить цитаты на английском, и приводить ссылки из Интернета. Теперь вам только осталось научиться понимать, что там написано. Способны ли вы самостоятельно своими словами объяснить, без невнятных намеков, что именно вам показалось несоответствующим действительности?
> Все правильно, вы лишь подтвердили мои слова. Потому что в сообществе GCC,
> засуетились и стали поддерживать стандарты в догонку за CLANG.И все бы ничего, если бы тыкавшие палочкой не обнаружили что и у gcc и у clang поддержка последних стандартов таки неполная. При этом у каждого по своему. И наверное как-то криво при этом с невозмутимой мордой втирать про ПОЛНУЮ поддержку стандартов.
Не полная. И с багами.
Но сабж (про апи. И с учетом млих мсылок выше) говорит, что шланг в догоняющих.
Может пока, х/з.
> Внесены многочисленные улучшения в бэкенды для архитектур ARMЭто хорошо. Недавно собрал md5deep для ARMv7, сначала с gcc 6.1, потом с clang 3.8. Вариант, собранный gcc, работает на 10-15% быстрее.
Тут как повезёт.
Я много экспериментировал с ГОСТ3411-2012, как чисто на С так и с SSE и AVX инстриктами.
Даже на С у меня были варианты на которых шланг работал быстрее а гцц медленнее и наоборот.
Скорость кода сгенеринного шланг 3.8 почти всегда не отличалась от 3.7, а вот 3.6 и 3.3 (или 3.4) отличались.
Кстати, может подскажете?
Когда-то смотрел бенчмарки gcc vs clang, и почти везде говорилось, что clang компилирует в 2-3 раза быстрее gcc. Я много чего собираю на одноплатнике, и хочется, чтобы компиляция шла быстрее. Собственно поэтому и решил поэкспериментировать с clang-ом. Попробовал у себя - разница есть, но намного меньше ожидаемой, процентов 10. Погуглил свежие бенчмарки - да, ситуация поменялась, теперь нет такой большой разницы в скорости сборки. Поэтому интересно, это gcc так сильно ускорили, или наоборот, clang так пожирнел?
Скорее второе. Новенькие проекты гордятся какие они шустрые и легковесные по сравнению с "динозаврами". Вот только лет через пять все снова встает на свои места. Потому что проекты тяжелые и медленные не потому что так кому-то захотелось, а потому что пришлось.
>>потому что пришлось.потому что объективная необходимость.
GCC серьёзно улучшили, а вот LLVM/Clang к 4.0 версии сильно разжирел.
Да-да, вантузного жабиста только и слушать.Стал просто реализовавать стандарты и.. о! Чудо! Стал толстеть.
Внезапно.
> Да-да, вантузного жабиста только и слушать.
> Стал просто реализовавать стандарты и.. о! Чудо! Стал толстеть.А то!
% du -d1 /usr/local/llvm37/
3,2M /usr/local/llvm37/bin
46M /usr/local/llvm37/lib
18K /usr/local/llvm37/libexec
219K /usr/local/llvm37/share
10M /usr/local/llvm37/include
59M /usr/local/llvm37/
% /usr/local/llvm37/bin/clang --version
clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-unknown-freebsd11.0
Thread model: posix% du -d1 /usr/local/llvm38
267K /usr/local/llvm38/share
11M /usr/local/llvm38/include
279M /usr/local/llvm38/bin
18K /usr/local/llvm38/libexec
124M /usr/local/llvm38/lib
415M /usr/local/llvm38
% /usr/local/llvm38/bin/clang --version
clang version 3.8.1 (tags/RELEASE_381/final)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/local/llvm38/bin% du -d1 /usr/local/llvm39
93K /usr/local/llvm39/share
12M /usr/local/llvm39/include
259M /usr/local/llvm39/bin
18K /usr/local/llvm39/libexec
149M /usr/local/llvm39/lib
420M /usr/local/llvm39
% /usr/local/llvm39/bin/clang --version
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/local/llvm39/bin
> Внезапно.% du -d1 /usr/local/llvm-devel/
163M /usr/local/llvm-devel/lib
124K /usr/local/llvm-devel/share
354M /usr/local/llvm-devel/bin
12M /usr/local/llvm-devel/include
18K /usr/local/llvm-devel/libexec
530M /usr/local/llvm-devel/
% /usr/local/llvm-devel/bin/clang --version
clang version 4.0.0
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/local/llvm-devel/bin
Ну ты и спамер. А зачем тебе 3 шланга? Ты что, сантехник?
> Ну ты и спамер. А зачем тебе 3 шланга? Ты что, сантехник?llvm37 завязан на DRI2/Mesa/libEGL 11.2.2, используемых в xorg-server-1.17.4 для программно-аппаратного ускорения графики свободных драйверов.
Остальные версии llvm пробую использовать в качестве замены системного LLVM/Clang 3.8.0. (Пока удалось скомпилировать только ядро, базовую систему не получается)
> Пока удалось скомпилировать только ядро, базовую систему не получаетсяПомнится в гцц с ядром подобные детские проблемы были в районе 2.95.
Нда.. давно это было.
> Помнится в гцц с ядром подобные детские проблемы были в районе 2.95.
> Нда.. давно это было.О! БээСДэшники собирали своё ядро чем-то другим??
Чем?!
И кто-что их заставило на этот богомерзкий гцц??!
> О! БээСДэшники собирали своё ядро чем-то другим??:D
Ну это смотря какие.
Некоторые конЪпилятЪ javac. Да ещё и под вантузом
>> Пока удалось скомпилировать только ядро, базовую систему не получается
> Помнится в гцц с ядром подобные детские проблемы были в районе 2.95.
> Нда.. давно это было.Всё-таки мне удалось скомпилировать не только ядро, но и базовую систему FreeBSD 11.0-PRERELEASE с помощью свежего LLVM/Clang 3.8.1, установленным из дерева портов: http://www.freshports.org/devel/llvm38/
Опции сборки:
CLANG : on
COMPILER_RT : on
DOCS : off
EXTRAS : on
GOLD : off
LIT : off
LLD : on
LLDB : off
OPENMP : on
Что даёт опция EXTRAS?
Имеет смысл задействовать GOLD?
Если у тебя дофига ресурсов и ты хочешь ощутить себя конкретной билдфермой - попробуй LTO. Смысл такой что линкер делает дополнительный анализ и вырубает весь неиспользуемый код на фазе линковки. В результате бинари как минимум заметно меньше по размеру, что хорошо во всех отношениях. В лучшем случае еще и чуть быстрее из-за увеличения cache hit проца. Ах да, что взамен? Медленная линковка, жрущая ресурсы как танк соляру.
> Если у тебя дофига ресурсовУ меня старенький процессор, на котором я всего лишь хочу ускорить компиляцию и сократить время апдейтов из сорцов.
Пока добился того, что вынес систему компиляции из базовой системы "наружу", и она стала независима; скорость компиляции ядра и системы возросла в три раза — теперь нужно полтора часа вместо четырёх с половиной.
> Пока добился того, что вынес систему компиляции из базовой системы "наружу", и
> она стала независима; скорость компиляции ядра и системы возросла в три
> раза — теперь нужно полтора часа вместо четырёх с половиной.А зачем ты венду перекомпилируешь?
> А зачем ты венду перекомпилируешь?Чтобы перестать пить коньяк по утрам!
>Что даёт опция EXTRAS?несколько дополнительных утилит - clang-tidy, clang-format, clang-include-fixer, и что там еще есть в clang-tools-extra.
>>Что даёт опция EXTRAS?
> несколько дополнительных утилит - clang-tidy, clang-format, clang-include-fixer, и что
> там еще есть в clang-tools-extra.А что они дают дополнительно? Это утилиты только для разработчика полезны, когда там хочется поковыряться в коде, что-то дополнительно посмотреть-оптимизировать?
>> Пока удалось скомпилировать только ядро, базовую систему не получается
> Помнится в гцц с ядром подобные детские проблемы были в районе 2.95.С каких это пор у лапчатых есть еще и "база"?
> Нда.. давно это было.Ну хоть бы иногда lkml почитывали, что ли:
http://lkml.iu.edu/hypermail/linux/kernel/0407.1/0517.html
> Re: GCC 3.4 and broken inlining.http://lkml.iu.edu/hypermail/linux/kernel/1101.0/03126.html
> Re: [PATCH] fix miscompiling with GCC 4.5 -finline-functionshttp://lkml.iu.edu/hypermail/linux/kernel/1407.3/00650.html
> Re: Random panic in load_balance() with 3.16-rc
> From: Linus Torvalds
> Ok, so I'm looking at the code generation and your compiler is pure and utter *shit*.
> Adding Jakub to the cc, because gcc-4.9.0 seems to be terminally broken.https://lkml.org/lkml/2015/4/14/576
> Subject [PATCH] compiler: add support for gcc 6
>gcc has recently bumped its major version and this is causing kernel build errors.
Баги с "генеральной линией партии" не путаем, да, лапчатый?
> Баги с "генеральной линией партии" не путаем, да, лапчатый?Теплое с мягким, как некоторые, сравнивая? Не, не путаем. Кстати, как знаток генеральных линий объяснит вот это:
https://lists.freebsd.org/pipermail/svn-src-head/2016-July/0...
> Log:
> Do not use -fformat-extensions with non-base versions of gcc
> This unbreaks compiling the kernel/modules with non-base gcc (4.8,
> 5.0, etc) if MK_FORMAT_EXTENSIONS=yes (the default).
> llvm37 завязан на DRI2/Mesa/libEGL 11.2.2,Насколько я помню он и с 3.8 нормально живет, при том если это для амдшек - в 3.8 и оптимизация получше и багов меньше.
Алё! Речь шла о скорости компиляции.
При чём тут размер, занимаемый в ФС?
> Когда-то смотрел бенчмарки gcc vs clang, и почти везде говорилось, что clang
> компилирует в 2-3 раза быстрее gcc.Пока он хреново оптимизировал код - так и было. А как оптимизатор стал сравним по качеству кода с gcc, так и скорость компиляции обвалилась до тех же величин. Можешь на форониксе посмотреть. Они иногда бенчат это и там видно что в каждой версии шланг становился все медленнее.
> Я много чего собираю на одноплатнике, и хочется, чтобы компиляция шла быстрее.
Чудес не бывает: если компиляция проходит быстрее, значит фаза оптимизации выдаст лажовый код. В том же gcc -O0 компилит в разы быстрее -O3, но качество кода тебе не понравится. Зачем тебе пухлый и тормозной код на одноплатнике? :)
> поэкспериментировать с clang-ом. Попробовал у себя - разница есть, но намного
> меньше ожидаемой, процентов 10. Погуглил свежие бенчмарки - да, ситуация поменялась,Когда он был быстрый - он и код генерил тяп-ляп. Чудес не бывает. Или кто тратит ресурсы на оптимизацию кода или таки получает неоптимальный код.
> теперь нет такой большой разницы в скорости сборки. Поэтому интересно, это
> gcc так сильно ускорили, или наоборот, clang так пожирнел?И то и другое. GCC подперло конкуренцией и он серьезно улучшился. Clang пытался стать конкурентоспособным по качеству кода и неизбежно затормозился.
Спасибо за ответ, Аноним. В таком случае останусь на gcc. Развернул на десктопе кросс-компилятор, подключил к одноплатнику как узел distcc - стало собирать в несколько раз быстрее.
> Это хорошо. Недавно собрал md5deep для ARMv7, сначала с gcc 6.1, потом
> с clang 3.8. Вариант, собранный gcc, работает на 10-15% быстрее.Подожди, ща они напрягутся и оптимизнут. И скорость компиляции станет как у gcc 4.7 :)
Меньшая скорость может быть благодаря лучшей обработке - больше проверок/диангостик/предупреждений, например, или просчет вариантов оптимизаций.Т.е. это не тот параметр, который надо вытягивать любой ценой и выставлять 10-15% как победу. Можно в любой момент выкинуть кучу проверок и получить 300% прироста за счет кривости и неподдержки чего-нибудь в языке.
Появление clang мотивировалось глючностью, монолитностью (сложности разделения на модули), замусоренностью кода (заплатка на заплатке) GCC, а не претензиями к его скорости.
LLVM/Clang 3.9 спокойно собирает ядро FreeBSD 11.0-PRERELEASE, а вот собрать мир не получается - останавливается на libpam-зависимости libc.
> LLVM/Clang 3.9 спокойно собирает ядро FreeBSD 11.0-PRERELEASE, а вот собрать мир не
> получается - останавливается на libpam-зависимости libc.Нашла коса на камень...
Наконец-то на радеонах не надо ставить гитовскую версию.
Fortran мерзавцы добавили, как в прошлом году обещали ??
Не добавили. Однозначно, - мерзавцы !
CLANG первые сделали нормальную поддержку стандартов С++ (без тонн собственных несовместимых расширений остальных компиляторов) и вменяемую диагностику ошибок/предупреждений.Они первые сделали модульность, позволившую появиться куче инструментария, их использующего - кто как парсер, кто как генератор бинарников. Это не просто компилятор, это еще LLVM - инфраструктура для множества языков.
Без конкуренции с ним GCC сейчас был бы намного хуже, поэтому вопли фанатов GCC о ненужности - совершенно неуместны.
Кто может подсказать, куда копать в этой стоп-ошибке:/usr/local/llvm39/bin/clang -c -O2 -pipe -fno-strict-aliasing -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.isp.o -MTisp.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/isp/isp.c
/usr/src/sys/dev/isp/isp.c:4650:17: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4669:16: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4751:16: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4839:16: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4849:17: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4863:17: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4873:17: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4883:17: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4907:17: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4919:16: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4944:16: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4955:16: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
/usr/src/sys/dev/isp/isp.c:4977:17: error: passing an object that undergoes
default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, ctl);
^
/usr/src/sys/dev/isp/isp.c:4630:39: note: parameter of type 'ispctl_t' is
declared here
isp_control(ispsoftc_t *isp, ispctl_t ctl, ...)
^
13 errors generated.
*** Error code 1Stop.
Причём при компиляции ядра с помощью LLVM/Clang 3.8.1 этой ошибки нет, всё нормально компилируется. Конфигурация в обоих случаях одна и та же.
> Кто может подсказать, куда копать в этой стоп-ошибке:добавить к CFLAGS += -Wno-error=varargs
Теперь другая ошибка:/usr/local/llvm39/bin/clang -Wno-error=varargs -c -O2 -pipe -fno-strict-aliasing -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.ppb_1284.o -MTppb_1284.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/ppbus/ppb_1284.c
/usr/src/sys/dev/ppbus/ppb_1284.c:296:46: error: implicit conversion from 'int'
to 'char' changes value from 144 to -112 [-Werror,-Wconstant-conversion]
if ((error = do_peripheral_wait(bus, SELECT | nBUSY, 0))) {
~~~~~~~~~~~~~~~~~~ ~~~~~~~^~~~~~~
/usr/src/sys/dev/ppbus/ppb_1284.c:785:48: error: implicit conversion from 'int'
to 'char' changes value from 240 to -16 [-Werror,-Wconstant-conversion]
if (do_1284_wait(bus, nACK | SELECT | PERROR | nBUSY,
~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
/usr/src/sys/dev/ppbus/ppb_1284.c:786:29: error: implicit conversion from 'int'
to 'char' changes value from 240 to -16 [-Werror,-Wconstant-conversion]
nACK | SELECT | PERROR | nBUSY)) {
~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
/usr/src/sys/dev/ppbus/ppb_1284.c:841:37: error: implicit conversion from 'int'
to 'char' changes value from 200 to -56 [-Werror,-Wconstant-conversion]
if (do_1284_wait(bus, nACK | nBUSY | nFAULT, nFAULT)) {
~~~~~~~~~~~~ ~~~~~~~~~~~~~^~~~~~~~
4 errors generated.
*** Error code 1Stop.
https://wiki.freebsd.org/BuildingFreeBSDWithClang
см.
NO_WERROR=
WERROR=