LINUX.ORG.RU

Линус подумывает о возможности перехода на другой компилятор C


0

0

В списках рассылки LKML и gcc была интересная дискуссия о не совсем корректной с точки зрения пользователей оптимизации, производимой gcc. Эта оптимизация (замена условной записи в память на чтение, условную модификацию и безусловную запись обратно) потенциально может нарушить семантику блокировок в многопоточных программах (потребовать для корректной работы программы блокировку в том месте, где данные в памяти, казалось бы, не изменяются), но формально не противоречит стандарту языка C.

Линус подумывает о переходе на другой компилятор, в связи со слишком частым повторением такой ситуации, когда разработчики gcc занимаются юридическими выкрутасами с языком (language-lawyering) вместо решения реальных проблем пользователей gcc.

Примечательно, что на возможность такого рода неприятностей с блокировками в связи с недостаточной определенностью стандартов на язык C было указано еще два года назад в статье "Threads Cannot Be Implemented As a Library" (автор: Hans Boehm).

>>> Начало дискуссии в LKML

Ответ на: комментарий от atoku

>Да, очевидно, что Линус чем-то очень раздражен в сообществе.

Это довольно взаимно. Linus устал. Ему давно пора на покой. Уже брежневщиной попахивать стало. И маразмом.

anonymous
()
Ответ на: комментарий от anonymous

>И маразмом.

Маразмом в первую очередь. Пора ему уже на покой. Линус R.I.P.

anonymous
()

а чего ? клево - система контроля версий для ядра своя, компилятор для ядра свой, еще давайте редактор свой, набор утилит и так далее ;)

идиотство - нет я не спорю - в gcc есть проблемы, но давайте адекватно подходить к проблеме - и не делать громких заяв. Да и вообще GNU что то сдает, давайте лучше сделаем еще одну альтернативу linux - допилим hurd - ибо тут альтернатив нет.

а так gcc компилит подо все на чем биты считаются - найдите еще по размарху такой же компилятор? с такой же открытостью и расширяемостью - я не спорю что можно сделать свое, да и я могу написать компилятор - да и еще много кто - но кто напишет *хороший* компилятор с удобоваримой архитектурой ? Это килочеловекочасы потраченные с сомнительной перспективой.

Давайте тогда лучше что то на основе gcc делать если уж так не нравится, при этом работая с командой gcc разработчиков.

alphex_kaanoken ★★★
()
Ответ на: комментарий от Absurd

>А что на i386 перед каждым выфетчиванием long long'а из памяти захватывается неявный мьютекс?

Кури стандарт С/С++ на тему семантики volatile. Никаких гарантий относительно потокобезопасности этот спецификатор не даёт.

anonymous
()
Ответ на: комментарий от Vadim_Z

> Есть еще tcc (tiny c compiler) под LGPL.

Развитие вышеупомянутого 2-килобайтного OTCC :) Он даже ядро собирает. Правда, нужны дополнительные скрипты...

acheron ★★★★
()

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

lester ★★★★
()

Линусу нужно пойти поговорить с начальством этих разработчиков (большая часть из них наняты RedHat и Novell) и всё утрясётся. Я вообще не понимаю как люди, которые практически работают в одной компании (в двух, но они там перемешаны) над разными проектами не могут договорится.

Я представил себе как разработчики MS Office (или Windows™) жалуются что их код не компилируется из-за бажности Visual C++ или их программы не работают в бажной винде.

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

MS предлагает свои расширения стандарта, почему GNU этого не делает? http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1264.pdf

yurikoles ★★★
()
Ответ на: комментарий от lester

>все кто наезжал на Линуса пусть убьются об стену

Линупс уже давно попердывает в сторону комьюнити, пора бы уже компьюнити послать его нах.

anonymous
()

интересно, сколько денежек Линусу Балмер предлагает за разрыв с GNU и началом юр.процессов по засуживанию тех, кто юзает марку Linux (R) ?

hexenlord
()
Ответ на: комментарий от anonymous

>>А что на i386 перед каждым выфетчиванием long long'а из памяти захватывается неявный мьютекс?

>Кури стандарт С/С++ на тему семантики volatile. Никаких гарантий относительно потокобезопасности этот спецификатор не даёт.

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

Absurd ★★★
()
Ответ на: комментарий от kto_tama

в редхате уже давно есть такое подразделение (и в эппле, и в ибеме и много где еще)

anonymous
()
Ответ на: комментарий от kto_tama

>линусу надо только пальцем щелкнуть - и где-нибудь в недрах редхата >тут-же появится подразделение , которое будет заниматься днем и >ночью только гцц , и ничем более

Да не надо ему щелкать...они там давно все запатчили...:))
(См. список патчей RH для gcc)

GlorySmith
()
Ответ на: комментарий от kto_tama

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

http://www.linux.org.ru/view-message.jsp?msgid=1882650

Спроси у него :)

Zubok ★★★★★
()
Ответ на: комментарий от yurikoles

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

IMHO, замечательный для опредёлённого круга задач компилятор и к тому же _очень_ быстрый, бинарники получаются меньше по размеру, чем у других. Правда, все оптимизации целиком ложаться на плечи программиста, никакой конвейерной оптимизации и т.п. Если втупую с Си переписать код - будет на 20-30% медленнее VC-шного в тех же циклах, к примеру. И на x86 повязан

frame ★★★
()
Ответ на: комментарий от lester

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

Дело не в компиляторе. Линус в последнее время стал срываться по поводу и без повода, порождая кучу флейма, слухов и кривотолков. Технический специалист всегда должен действовать с точки зрения целесообразности, а не своих предпочтений и фобий. И он именно исходя из этой позиции, должен быть аккуратен в своих фразах. Ну и мыслях тоже, наверное. Ибо он руководит, наверное, крупнейшим публичным проектом в истории и является лицом медийным. А он позволяет себе постучать ботинком по кафедре по поводу Gnome, C++, ООП, FSF... Если он перестал соотносить свои действия с последствиями, значит и до реальных проблем недалеко. И вообще, несмотря на то, что разработка FOSS-проекта, а особенно такого крупного, как kernel и требует авторитарного рута, это не значит что он должен сидеть на верхушке вечно. Вернее это даже означает что он _не_ должен сидеть там вечно. Глаз замыливается, костность появляется...

anonymous
()
Ответ на: комментарий от anonymous

При этом ему не запрещается иметь собственное мнение, если кто-то делает сенсацию из этого мнения - это его дело

lester ★★★★
()

Кстати, Линус же ядром занимается, а в ядре всё на спин-блокировках, они на асме написаны :)

AsphyX ★★★
()
Ответ на: комментарий от anonymous

Я вот еще добавлю. Много лет назад Линус, как наш президент, сказал что он не болеет ни за один дистрибутив, а болеет за весь Linux. И не отдает никому предпочтений. Но некоторое время назад, он сказал, что не пользуется Debian, потому что ниасилил его инсталлятор. Вы меня извините, но его осили даже шимпанзе. Ничего не остается, как сказать "старость - не радость" и пожать плечами.

anonymous
()
Ответ на: комментарий от Deleted

> Все, капец пингвину!

> Закончится все пресс-релизом:

> Sun обсуждает возможность выпуска Studio под лицензией GPL... ;-)

Обсуждает, и это будет сделано, когда студию допилят до возможности собрать и линукс, и соляру. Пока есть проблемы, но не с поддержкой гнусных расширений синтаксиса, а с ресурсоемкостью при сборке очень больших проектов типа KDE. Ява и нетбинзы уже вышли под GPL.

Насколько я помню, ICC умеет собирать ядро, но не умеет собирать KDE.

В отношении лицензий: сановский компилятор бесплатный, коды частично доступны. Интеловский компилятор бесплатный для некоммерческих применений и платный для коммерческих, коды недоступны. Интеловский компилятор имеет ОЧЕНЬ ХОРОШУЮ поддержку возможностей интеловских процов (поддерживаются ВСЕ возможности), для совместимых процов генерит код кое-как.

orlusha
()
Ответ на: комментарий от anonymous

> Насколько я понимаю, с GPL у всех вышеперечисленных совместима только OpenWatcom License. Так что вариантов не очень много.

Линус в мыслях не привязан к GPL. Вспомните, как он сказал "Хачу" и стал использовать Bitkeeper. И сколько сообщество ни призывало его к разуму, он слушать ничего не хотел. Легко может взять и перейти на закрытый компилятор.

annonymous ★★
()
Ответ на: комментарий от anonymous

> Вы меня извините, но его осили даже шимпанзе.

Руки прочь от Линуса! Линус не занимается monkey business!!!

annonymous ★★
()
Ответ на: комментарий от orlusha

> Пока есть проблемы, но не с поддержкой гнусных расширений синтаксиса, а с ресурсоемкостью при сборке очень больших проектов типа KDE.

А что у них своё есть это всё меньше KDE что ли?

atrus ★★★★★
()
Ответ на: комментарий от atrus

>> Пока есть проблемы, но не с поддержкой гнусных расширений синтаксиса, а с ресурсоемкостью при сборке очень больших проектов типа KDE.

>А что у них своё есть это всё меньше KDE что ли?

Написанная троллями процедура сборки KDE приводит вначале к образованию исходного файла на C++ размером около 500 МБ (!!!), который скармливается компилятору. Гнусь это съедает, студия - нет (не хватает оперативной памяти). Солярка собирается из кусков существенно меньшего размера. Если большой исходник нарезать на куски, собрать KDE студией можно, но процедура сборки НЕ БУДЕТ оригинальной.

orlusha
()

Единственно правильная реализация блокировок - на сокетах. Все остальные реализации от быдлокодеров дефективны бай дезигн.

anonymous
()
Ответ на: комментарий от anonymous_incognito

Linus тот ещё мэн, судя по всему он свой компилятор решил забубенить.

NonHuman ★★★
()

вообще-то человеку ответили сразу - используй volatile :)
да и плохой стиль это - глобальные переменные с тредами мешать :)

anonymous
()

Мде. Лишь бы не на яву перешли. А то тоже тема - залабать программку, которая конвертнет код с С на жабский. =) И тогда все будут ставить по 16 гигов памяти на компы. =) Лафа производителям железа.

schakal
()
Ответ на: комментарий от yurikoles

> Нужно тогда присмотреться к диалекту cyclone. Может быть сейчас на ранней стадии присоединится к проекту

AFAIK, этот проект уже мертв. К сожалению.

tailgunner ★★★★★
()

А есть еще свободный компилятор, который столько же платформ поддерживает??? Кроме того есть в ядре вещи, использующие специфику gcc.

skwish ★★
()
Ответ на: комментарий от skwish

> Но некоторое время назад, он сказал, что не пользуется Debian, потому что ниасилил его инсталлятор. Значит линус не знал slackware :(

splinter ★★★★★
()
Ответ на: комментарий от lester

Мда... прочитал новость, повелся на провокацию, сходил по ссылке, успокоился. А вы тут панику развели.

skwish ★★
()

Ну вы блин даете. Хоть где-то в сообщении от Линуса написано, что он перейдет на что-то другое? Нет. Он просто выразил свои опасения. Согласитесь, что ему будет неприятно, если из-за безделия ребят, которые пишут gcc. Начнутся проблемы с проектом, которому он, получается, посвятил большую часть жизни.

Bismark
()
Ответ на: комментарий от anonymous

>так вроде ж LLVM упомянул, и кстати в gcc рассылке поговаривали про то что надо тоже на LLVM перейти, но потом скатились на lto. Оптимизация там лучше во всех отношениях, не хватает только разработчиков.

Сайт LLVM нашёл, а где можно почитать про lto? Что за зверь?

GladAlex ★★★★★
()

А g77 тоже выкинут? И чем заменят?

joshua
()
Ответ на: комментарий от akira_ag

>The BSD people are adopting pcc [1] which is a rewritten version of some C compiler originally developed in the late 70s. And yeah, it's basically because they think gcc is becoming too painful to live with [2]. 1. http://pcc.ludd.ltu.se/ 2. http://www.thejemreport.com/mambo/content/view/369/

Да печально:

>TdR: But that's never really been the agenda, see. Some people think we hate GNU code. But the thing is we hate large code, and buggy code that upstream does not maintain. That's the real problem... gcc gets about 5-6% slower every release, has new bugs, generates crappy code, and drives us nuts. This is just an attempt to see if something better can show up.

GladAlex ★★★★★
()
Ответ на: комментарий от anonymous

>LLVM круто, а ГЦЦ ф топку

>A compiler infrastructure - LLVM is also a collection of source code that implements the language and compilation strategy. The primary components of the LLVM infrastructure are a GCC-based C & C++ front-end, a link-time optimization framework with a growing set of global and interprocedural analyses and transformations, static back-ends for the X86, X86-64, PowerPC 32/64, ARM, Thumb, IA-64, Alpha and SPARC architectures, a back-end which emits portable C code, and a Just-In-Time compiler for X86, X86-64, PowerPC 32/64 processors.

GladAlex ★★★★★
()
Ответ на: комментарий от anonymous

> надо форкать gcc и писать компилятор для сборки ядра Linux.

Этого нового компилятора ни у кого не будет, ядро будет распространятся бинарно, ну и закроется в итоге.

ip1981 ☆☆
()
Ответ на: комментарий от Bismark

В топку Linux! Даешь снова MINIX!

:)

anonymous
()

Да интересно. Linus:

>But I have to admit that for the last five years or so, I've really wanted some other compiler team to come up with a good open-source compiler. Exactly due to issues like this (Q: "Gcc creates bogus code that doesn't work!" A: "It's not bogus, it's technically allowed by the language specs that don't talk about xyz, the fact that it doesn't work isn't our problem").

>I think the OpenBSD people decided to actually do something about this, and I suspect it had *nothing* to do with license issues, and everything to do with these kinds of problems. I wish them all the luck, although personally I think LLVM is a much more interesting project.

http://llvm.org/

GladAlex ★★★★★
()

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

Ну вот, изначальная кривость и убогость языка С и начала вылазить боком по крупному. Массовые взломы серверов из-за кривой обработки входящих данных ничему не научили. Теперь при переходе на многоядерные камни еще не то вылезет! Используйте нормальные языки и будет всем щастье :)

anonymous
()
Ответ на: комментарий от anonymous

>Используйте нормальные языки и будет всем щастье :)

А что ты понимаешь под нормальными языками?

anonymous
()

Странно, что никто не вспомнил Borland C++? К тому же у него просто шикарное IDE, которого в gcc нет и в помине.

Sun-ch
()
Ответ на: комментарий от Sun-ch

>Странно, что никто не вспомнил Borland C++? К тому же у него просто шикарное IDE, которого в gcc нет и в помине.

Всё, тушите свет!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.