Будет ли Linux официально поддерживать компиляцию в Clang?

А пользователю и не нужно держать компиляторы. На рабочих компах, на домашних или на серверах компиляторы почти никогда не нужно держать. Это только для разработчиков и энтузиастов.

Суть претензий в том, что GCC <> C поэтому затачивание под GCC это отказ от стандартов в пользу продвижения GCC.

Я за GCC и против Clang, потому что последний слишком большой со всей инфраструктурой поддержки.

А пользователю и не нужно держать компиляторы. На рабочих компах, на домашних или на серверах компиляторы почти никогда не нужно держать. Это только для разработчиков и энтузиастов.

Наивный.

GCC - вовсе не стандарт и на нём свет клином не сошёлся.

А я и не говорил, что GCC - стандарт. Я сказал, что GCC - стандарт де-факто конкретно для ядра Linux.

Если кто-то захотел поддержку clang - это не значит, что все разрабы должны сразу бросится её реализовывать. Хотите - пишите и согласуйте патчи. Если кто-то не хочет этим заниматься - это его право.

Пока в этом треде я видел твои возмущения, но не видел твои патчи.

...и гентушников.

Но GCC не может быть EEE, поскольку, при желании, другие компиляторы могут реализовать все эти недостающие костыли. Код LLVM и Clang останется открытым даже если злобная корпорация пингвинов RedHat напишет свою проприетарную модификацию, без которой ядро продолжит компилироваться как и раньше. Хорошо, корпорация пингвинов может сделать и свою модификацию ядра (уже делает), которое, на этот раз, потребует проприетарную версию Clang, которой нет в CentOS. Что мешает переписать эту открытую модификацию ядра на открытом синтаксисе, который поймёт и открытая версия Clang и ортодоксально кашерный GCC? Что мешает, при необходимости и реальной полезности, реализовать эту новую функциональность компилятора под открытой лицензией?

А речь не только о пользователях.

Пиши патчи.

Наверное в том, что Clang лучше или может стать лучше gcc в ближайшее время. Например сообщения об ошибках и предупреждения в Clang изначально лучше, чем в gcc. Ну и кроме того за Clang стоят корпорации, без которых Linux - ничто.

Вот и высрался человек. Закрывайте тред.

А я и не говорил, что GCC - стандарт. Я сказал, что GCC - стандарт де-факто конкретно для ядра Linux.

Я говорил именно об этом. То, что ядро компилируется только GCC не делает последний каким-то стандартом, даже де-факто. Это всего лишь данность, которая может измениться в любой момент (смотри ниже), потому что какой-то принципиальной привязки к GCC в ядре не существует. Она исключительно историческая.

Если кто-то захотел поддержку clang - это не значит, что все разрабы должны сразу бросится её реализовывать. Хотите - пишите и согласуйте патчи. Если кто-то не хочет этим заниматься - это его право.

Пока в этом треде я видел твои возмущения, но не видел твои патчи.

Уже несколько раз писал, что коммиты в ядре, с упоминанием Clang, не редкость уже сейчас. Более того ничего Clang специфичного реализовывать не надо. Надо лишь отказаться от нескольких GCC-специфичных костылей.

Я за GCC и против Clang, потому что последний слишком большой со всей инфраструктурой поддержки.

Ты уже ушёл с FreeBSD?

То, что ядро компилируется только GCC не делает последний каким-то стандартом, даже де-факто.

Ты понимаешь смысл слова «де-факто»?

Надо лишь отказаться от нескольких GCC-специфичных костылей.

О, отлично. Кому надо?

Что мешает переписать эту открытую модификацию ядра на открытом синтаксисе, который поймёт и открытая версия Clang и ортодоксально кашерный GCC?

Ну это то, что и озвучивалось в общем-то. Альтернатива - сохранять приверженность GCC и не трогать те куски кода, которые заточены под то, что компилятор GCC. В этой ситуации ты вынуждаешь пользователя использовать GCC в качестве компилятора C, замещая таким образом стандарт C на «набор фич GCC». Это примерно то, что проделывала MS во времена IE4 - вместо стандартов на куче страниц был ActiveX и IE-специфичный код.

Вопрос не в том, что бы быть «за Clang». Вопрос в том, что GCC-специфичных фич не должно быть.

При строгом следовании стандарту и отсутствию нестандартных фич вопрос сборки Linux Clang'ом остаётся на стороне исполнения Clang'ом стандарта.

Кто-то боится появления ActiveX в ядрах от RedHat?

Ну, не то чтобы «боюсь», но мне вот например неприятно когда на ядре написано «язык C», а по факту оно не собирается «компилятором С» соответствующим стандарту, а собирается только компилятором GCC.

Не потому, что я боюсь что это приведёт к невозможности открытой поддержки. По эстетическим причинам. И потому что это означает давление GCC на стандарт в ненадлежащей форме.

Также как мне не нравятся сайты, работающие только на Хроме.

При этом там уже давно есть:

include/linux/compiler-clang.h
include/linux/compiler-gcc.h
include/linux/compiler-intel.h

Обязательно будет.

Я за GCC и против Clang, потому что последний создан для того чтобы вытеснить GCC с экосистемы GNU/Linux.

исправил.

Раз уж тема о clang, то какие флаги оптимизации аналогичны флагам "-O3 --ffast-math -march=native" в gcc?

А закрытый не остается

-O3 --ffast-math -march=native

Задолго до шланга была уже подобная история с ядром linux и icc. Что-то изменилось с тех пор? Современное ядро linux это уже сколько там миллионов строк кода? Исправить всё это под все возможные компиляторы реально но нецелесообразно ибо никому не нужно и никто не оплатит эту титаническую затею.

Означает ли это, что Linux будет официально поддерживать компиляцию в Clang в ближайшем будущем?

А зачем? clang генерит более медленный машинный код, чем gcc. Мсье хочет ядро на amdgpu заранить?

А закрытый не остается

Ну и что? Он ведь не твой.

Если я автор - то мой.

Твоё лишь то, чего ты автор. Остальные модификации по любому не твои и они либо открытые и ты просто можешь ими пользоваться, либо закрытые и тогда не можешь пользоваться или должен заплатить. Наличие закрытых модификаций никак не ущемляет твои права на твой код и на твоё право его изменять и улучшать.

Не хочу начинать этот религиозный спор GPL vs BSD в 100500-й раз.

И чем она закончилась? include/linux/compiler-intel.h есть до сих пор.

Не хотел бы - не начинал бы.

И чем она закончилась?

Очевидно! Проект пилили но в целом как не собирало так и продолжает не собирать.

Твоё лишь то, чего ты автор.

Правильно.

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

Да, не ущемляет мои юридические права, а вот моральные права ущемляет. Главное чтобы так думало подавляющее большинство тех кто разрабатывает Clang/LLVM.

Не хочу начинать этот религиозный спор GPL vs BSD в 100500-й раз.

Нет это не религиозный спор. Просто, предельно ясна тактика тех, кто продвигает LLVM. Проблема в том, что безвольные лицензии типа «BSD» быстро умеют превращатся в проприетарную лицензию. У Clang/LLVM свободная лицензия вирусного типа.

Пусть «хозяева» Clang/LLVM выпустят свой продукт под лицензией GPL v3+. тогда и поговорим. А этого разумеется не будет. Слишком тёмные мысли у них, слишком далеко смотрят они. Но Столлмана они не обманут.

Начал a1batross (23.06.2018 16:26:46)

clang-5.0: error: unsupported option '--ffast-math'

-ffast-math нужно :)

https://clang.llvm.org/docs/UsersManual.html#cmdoption-ffast-math

ну, с одной чёрточкой, а не двумя же, как у gcc

А. Это была ленивая копипаста с тебя. У gcc она тоже одна.

двумя же, как у gcc

$ gcc --ffast-math
gcc: error: unrecognized command line option ‘--ffast-math’; did you mean ‘-ffast-math’?

значит, я по памяти не так вспомнил.

а вообще прикольно, один пример с разностной схемой даже за 4 секунды вместо 5 выполнил. Но надо бы пример модифицировать, чтобы начальные данные снаружи приходили, а не были вшиты в код, а то у меня подозрения, что основные оптимизации за счёт этого у обоих компиляторов.

И gcc для некоторых архитектур с опцией -march=native замедлять начинает.