The OpenNET Project / Index page

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

Обсуждение возможных планов развития GCC 5.0

20.03.2012 17:57

Среди разработчиков набора компиляторов GCC развернулась обширная дискуссия о планах и задачах для будущей ветки GCC 5.0. При этом основной темой размышлений о возможных путях развития GCC, стало его обсуждение в контексте стремительно набирающего популярность проекта LLVM (Low Level Virtual Machine).

Так, активный разработчик GCC Дэвид Малкольм (David Malcolm) из компании Red Hat подробно изложил своё видение будущего проекта, которое сводится к предложению переписать GCC с Си на Си++, разработать полноценный API для подключения плагинов, а также в движении GCC в сторону более модульной структуры – реализации базовой части в виде набора самодостаточных библиотек.

Идея заключается в том, что подобные библиотеки, из которых будет состоять GCC 5, смогут очень легко внедряться в приложения, так же легко, как это делается в LLVM. Дэвид, в частности, заявляет: "Я очень надеюсь, что GCC будет двигаться в сторону коллекции библиотек, которые могут быть свободно внедрены в любые лицензионно-совместимые приложения. LLVM завоевала популярность для случаев, где нужна JIT-компиляция. Я понимаю, что JIT-компиляция сильно отличается от классического предварительного компилирования, которого придерживается проект GCC. В идеале, GCC превратится в набор разделяемых библиотек, которые могут быть слинкованы как статически, так и динамически. Запускаемые файлы превращаются в тонкую обертку, которая лишь вызывает нужные библиотеки".

Приведение GCC к модульной структуре - это очень сложная задача. Поэтому Дэвид добавляет: "Подобная переработка архитектуры сегодняшнего GCC очень сложна (быть может, даже и невозможна), хотя бы потому, что мы не можем однозначно решить, какому отдельному модулю какой код компилятора должен принадлежать. Важно в первую очередь принять некую карту развития - при этом, вероятно, придётся смириться с тем, что модульный GCC 5 будет обладать меньшей функциональностью, чем текущий GCC, будет менее оптимизированным и менее мощным. Я не знаю, возможно ли это осуществить вообще (поэтому я иногда очень пессимистичен к этому проекту), в том числе потому, что многие оплачиваемые разработчики GCC работают на компании, которые не допустят столь масштабных изменений".

Кроме того, препятствием для потенциального сближения GCC и LLVM является то, что компиляторы LLVM поставляются под более либеральной лицензией BSD, которая более любима компаниями и более совместима со сторонним программным обеспечением, тогда как GCC распространяется под лицензией GPLv3, вносящей ряд ограничений при связывании библиотек. Даже если разработчики и согласятся в будущем сфокусироваться на модульности будущего GCC, это потребует немало времени.

  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
Автор новости: Igor Savchuk
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/33396-gcc
Ключевые слова: gcc, llvm
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (77) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 18:33, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    А стоит ли оно того?
     
     
  • 2.3, EUGENE (?), 18:35, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Поживем увидем, сейчас нельзя так просто ответь на этот вопрос
     
  • 2.5, paulus (ok), 18:46, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +23 +/
    Как нам пояснили это того стоит ибо переписанный на Си++ "модульный GCC 5 по сравнению с текущим GCC, - будет обладать меньшей функциональностью, будет также менее оптимизированным и менее мощным, чем сегодняшний GCC". Возможно я не прав, но когда коту делать нечего он...
     
     
  • 3.21, an. (?), 20:23, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вы опустили весьма важную часть библиотеки, из которых будет состоять GCC 5, с... большой текст свёрнут, показать
     
     
  • 4.23, dimqua (ok), 21:08, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А что генерирует наиболее оптимальный?
     
     
  • 5.25, Anonymus (?), 21:33, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Intel, PathScale, NAG
     
     
  • 6.31, sam002 (ok), 22:33, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Сильно зависит от написания. Многие тесты синтетические, а для реальных проектов быстродействие гуляет в обе стороны. Опять же опенсёрс, а значит все проблемы известны и их можно избегать и исправлять.
     
     
  • 7.62, Anonymus (?), 02:01, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Path64, GPL v3
     
     
  • 8.74, Аноним (-), 04:44, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но очень уж на AMD ориентирован Это конечно лучше чем блоб от интеля, но получа... текст свёрнут, показать
     
     
  • 9.89, Anonymus (?), 17:03, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    У AMD Open64, а это Pathscale Path64, более ранний форк того же SGI компилятора ... текст свёрнут, показать
     
  • 6.64, Аноним (-), 04:22, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Intel, PathScale, NAG

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

     
  • 5.56, an. (?), 00:52, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    для Win - MS VC
     
     
  • 6.78, Anonymouss (?), 06:23, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Спорно, бывает и наоборот.
     
  • 6.116, fr0ster (ok), 21:41, 23/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это шутка юмора?
     

  • 1.2, EUGENE (?), 18:34, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Правильной дорогой идете ребята. Вообщем ждем новостей, а еще лучше релизов GCC
     
  • 1.4, Zenittur (?), 18:40, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А где обсуждение-то читать? В гиперссылке "обсуждение" дано как раз небольшое сообщение этого самого работника Red Hat, которое полностью переведено. Про модульность и наступающий LLVM. И всё. Где узнать что возможно появится в GCC 5.0?
     
     
  • 2.6, Аноним (-), 19:05, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Расслку никогда не читал? Тыкаешь там "Thread Index" и читаешь сообщения по интересующей теме.
     

  • 1.7, Аноним (-), 19:07, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –13 +/
    > Кроме того, препятствием для потенциального сближения GCC и LLVM является то, что компиляторы LLVM поставляются под более либеральной лицензией BSD, которая более любима компаниями и более совместима со сторонним программным обеспечением, тогда как GCC распространяется под лицензией GPLv3,

    И тут GPL v3 мешает...

     
     
  • 2.33, sam002 (ok), 22:38, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И тут GPL v3 мешает...

    Они продавят и все стандарты(особенно юридические) будут считаться с v3. Надеюсь, что это не затянется и будет реализовано после пересмотра патентования ПО.

     
  • 2.39, zhenya_k (?), 23:24, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не мешает, а помогает.
    Не в последнюю очередь благодаря этой лицензии появился LLVM.
     
     
  • 3.48, Аноним (-), 23:44, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не в последнюю очередь благодаря этой лицензии появился LLVM.

    Ну так любители тивоизировать девайсы и вообще ставить юзеров раком - всегда лазейку найдут.

     
     
  • 4.65, Аноним (-), 04:23, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну так любители тивоизировать девайсы и вообще ставить юзеров раком - всегда лазейку найдут.

    Так пусть ищут ее своим ходом :)


     
  • 3.100, kshetragia (ok), 07:59, 22/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тонко )
     
  • 2.75, Аноним (-), 04:45, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И тут GPL v3 мешает...

    Да, ужасная лицензия. Не дает хапугам код зажимать. Вы только подумайте, какие негодяи!

     
     
     
    Часть нити удалена модератором

  • 4.29, Аноним (-), 22:14, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > рано ещё при текущих трендах шланг заборет гцц, однако есть вероятность что
    > к тому времени на плюсах будут писать 2 деда

    При текущих трендах, шланг может кого-то побороть только по части продайкт-плейсмента.
    Технические достоинства и недостатки - ничто, авторитет яббла - все.

     
  • 3.103, Аноним (-), 15:17, 22/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ужастная лицензия - позволяет стороннему дяде присвоить мой код - если я хочу просто пользоваться его библиотекой - не изменяя ее.
    Так же как ужастная для компилятора - что не компилируй - на выходе получаем GPL v3 и можно смело присваивать себе код.
     
     
  • 4.106, анонимус (??), 16:48, 22/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >позволяет стороннему дяде присвоить мой код - если я хочу просто пользоваться его библиотекой - не изменяя ее

    не согласен - пиши свою либу. или ищи под лгпл или иной

    >что не компилируй - на выходе получаем GPL v3 и можно смело присваивать себе код

    у гцц есть оговорка насчёт выхлопа, так что не надо тут

     
     
  • 5.122, Аноним (-), 19:50, 25/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > у гцц есть оговорка насчёт выхлопа, так что не надо тут

    Нету. почитай лицензию на gcc. Любой проект использующий внутренне состояние gcc - обязан быть под gpl.
    и linking expection - добавили только после воплей, а не просто так.

     
     
  • 6.124, arisu (ok), 19:59, 25/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    внутренности — естественно.

    а исключение давно было, просто потерялось при переводе на GPLv3. ты знаешь, что такое «ошибка», нет? никто не идеален, все ошибаются. недосмотрели. починили. в чём проблема-то?

     

  • 1.9, Eugene.Shiyanov (?), 19:28, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Не понимаю, как переход на С++ сможет решить проблемы?

    http://blogerator.ru/page/oop_why-objects-have-failed

     
     
  • 2.15, kuku (?), 19:39, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Просто они незнают что в С++ делается больше
    ошибок чем в С.
    Может они хотят учиться на своих ошибках ?..
     
     
  • 3.34, Анонимный эксперт (?), 22:52, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Разрабы GCC дураки, а ты умный - понятно.
     
  • 3.80, тоже Аноним (ok), 08:41, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Да, вам можно говорить об ошибках, вы в курсе.
    Пять ошибок в двух предложениях - это твердый профессиональный уровень!
     
  • 2.18, Аноним (-), 19:47, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Комментарии к статье доставляют :)
     
  • 2.112, arisu (ok), 15:19, 23/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Не понимаю, как переход на С++ сможет решить проблемы?

    это ж redhat, там поттеринг скоро всех перекусает.

     

  • 1.11, Аноним (-), 19:31, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    если бы gcc 1.4 был написан на C++ имхо лиукса бы небыло
     
     
  • 2.13, Andrey Mitrofanov (?), 19:34, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а если бы Кениган & Ричи писали компилятор C++, то и С бы не было. вместе с UNIX TM.
     
     
  • 3.24, saNdro (?), 21:28, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну вообще-то Страуструп изначально только прикрутил классы к вполне себе нормальному С. Банально расширил функционал.
     

  • 1.14, кевин (?), 19:37, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    тыц ура к 5 версии и гцц будет фрэймворком
     
     
  • 2.58, an. (?), 00:57, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то речь шла о библиотеке, что не совсем тоже самое, что и фреймворк. Надеюсь, все же, что фреймворком он не будет...
     

  • 1.17, BratSinot (?), 19:45, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Так, активный разработчик GCC Дэвид Малкольм (David Malcolm) из компании Red Hat подробно изложил своё видение будущего проекта, которое сводится к предложению переписать GCC с Си на Си++

    Забавный он человек. Шансов на это 0. Максимум, они будут использовать строго определенные фичи (о чем разработчики когда-то говорили).

     
  • 1.32, Vova (??), 22:38, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Имхо, сильно громкое заявление, переписать такой величины проэкт, практически на другой язык - весьма трудоёмкая задача. Оно-то конечно правильно, С++ и удобней для таких задач и гибче, но... Мало верится что-то :)
     
     
  • 2.118, Аноним (-), 13:23, 24/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    насчет удобней - крайне спорный вопрос ибо ясно, что удобнее CL и ML пока еще ничего не придумано, однако ж никто не переписывает тонны кода на них только потому, что они "удобнее" (кому конкретно? для чего конкретно?)
     
     
  • 3.119, arisu (ok), 13:25, 24/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    да ну. ассемблер всё равно лучше всех.
     

  • 1.40, xxx (??), 23:31, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    >Важно в первую очередь принять некую карту развития - при этом, вероятно, придётся смириться с тем, что модульный GCC 5 будет обладать меньшей функциональностью, чем текущий GCC, будет менее оптимизированным и менее мощным.

    Мне кажется это будет капец. Если он будет менее мощным и оптимизированным, то пока они его доведут до удовлетворительного состояния, Clang + llvm обойдут на повороте и уйдут в отрыв.

    На мой взляд главные плюсы GCC:
    * Поддержка огромного числа архитектур, быстрое включение этой поддержки после анонса.
    * Очень качественная, фактически, эталонная поддержка основных ЯП и их стандартов: С, С++, Fortran.
    * Генерирует оптимальный код, мощная оптимизация.

    Вот в улучшениее всего этого и нужно двигаться. Но никак не за счет ухудшения существующих позиций.

     
     
  • 2.47, Аноним (-), 23:44, 20/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > На мой взляд главные плюсы GCC:
    > * Поддержка огромного числа архитектур, быстрое включение этой поддержки после анонса.
    > * Очень качественная, фактически, эталонная поддержка основных ЯП и их стандартов: С,
    > С++, Fortran.

    Это стеб тонкий? тогда почитай-те что такое GCC-измы и что такое GNU-89 который реализует gcc.
    Нефига не эталонная поддержка это C.

     
     
  • 3.60, an. (?), 01:02, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну с эталонной, пожалуй это немного перебор. Но все же с ней считаются (например, есть всякие воркэраунды вокруг багов компайлера для Boost, STLPorts и других библиотек). Что касается llvm, например, то пока он вынужден все корректно поддерживать (что, впрочем, может и к лучшему).
     
  • 3.84, xxx (??), 10:54, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В чем-то согласен С другой стороны, не используй GCC-измы GCC же не виноват, ч... большой текст свёрнут, показать
     
     
  • 4.94, Аноним (-), 18:07, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и вообще ты знаешь компилятор лучше?

    тот же intel, тот же openwatcom.

    > И ещё по-поводу стандарта. На мой взгляд сообществу GCC, равно как и
    > Clang/llvm, давно пора лобировать прохождение своих расширений в стандарт. Я лучше
    > буду видеть в с тандарте __attribute__((packed)) - единственное расширение, что приходится
    > часто использовать, чем всякие _Noreturn и нити (если было и добавлять
    > нити, то уж на базе pthreads).

    за attribute((packed) и пересылку по сети и диск я бы голову отбивал.
    non aligned access получить как 2 байта по сети переслать. и всякие _Noreturn - это хня.
    даже от likely/unlikely в kernel стали избавляться ибо выигрыш там мизерный - если есть.

     
     
  • 5.99, xxx (??), 22:52, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >тот же intel, тот же openwatcom.

    Т.е лучше копилятора чем GCC ты не знаешь, по крайней мере в плане поддержки различных архитектур и стандарта С.

    http://www.openwatcom.org/index.php/C99_Compliance
    >C99 compatibility is an undocumented feature, since the implementation is not complete.

    Ты им вообще пользовался? Чем он вообще лучше?

    >за attribute((packed) и пересылку по сети и диск я бы голову отбивал.

    Лучше не пробуй, а то свою отобьешь, или уже?

    >non aligned access получить как 2 байта по сети переслать

    Настолько геморно?! Или есть способ попроще, просвети.

    >и всякие _Noreturn - это хня.

    Хня, не хня - в стандарт вошло. Меня лично заглавная "N" раздражает.

     
     
  • 6.104, Аноним (-), 15:22, 22/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Хуже не знаю Ты посмотри какой код он генерит для IA-64, а потом сравни с Intel... большой текст свёрнут, показать
     
  • 5.113, arisu (ok), 15:22, 23/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > non aligned access получить как 2 байта по сети переслать

    nobody cares. кажется, разработчики железа забыли, что это железо для людей, а не наоборот. если какая-то архитектура умывается слезами от невыравненого доступа — это её личные проблемы. а я, например, не буду заниматься ерундой, доставая из int'а два char'а руками. и не собираюсь тратить — тоже например — четыре байта там, где хватает двух.

     
     
  • 6.120, Аноним (-), 23:16, 24/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Железо скорее для компиляторов, а компиляторы уже для людей. Если попросить проц не умничать и дать компилятору решать, что, куда и в каком порядке (а это у него может получиться значительно лучше, т.к. можно неспеша разглядывать большую кучу кода), может получиться интересно по быстродействию и энергопотреблению. Вроде что-то подобное и сделали в IA-64
     
     
  • 7.121, arisu (ok), 04:37, 25/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Железо скорее для компиляторов, а компиляторы уже для людей.

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

    > Вроде что-то подобное и сделали в IA-64

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

     
  • 6.123, Аноним (-), 19:54, 25/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> non aligned access получить как 2 байта по сети переслать
    > nobody cares. кажется, разработчики железа забыли, что это железо для людей, а
    > не наоборот. если какая-то архитектура умывается слезами от невыравненого доступа —
    > это её личные проблемы. а я, например, не буду заниматься ерундой,
    > доставая из int'а два char'а руками. и не собираюсь тратить —
    > тоже например — четыре байта там, где хватает двух.

    Да да да. Не стоит прикрывать свою не проф пригодность красивыми словами - ламер.

    Покачай еще свои права в конторе которая пишет мультиплатформеный код - скажи начальнику - это неправильная архитектура - я ее поддерживать не хочу. И вылетай оттуда пинком под зад - с заслуженным диагнозом "не проф пригоден".

     
     
  • 7.125, arisu (ok), 20:00, 25/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    благодарю, я уж лучше продолжу работать в своей конторе. и пинками вышибать тех, кто считает, что задача человека — делать работу за компилятор.
     
  • 3.86, Аноним (-), 12:29, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Нефига не эталонная поддержка это C.

    Он поддерживает кучу архитектур, при том все это доступно в сырцах и я могу себе накрайняк сам сбилдить бинарь генерящий код под экзотичную архитектуру. А вот у других  поддерживается 1-2 архитектуры, а в половине случаев еще и сорц "забывают" выдать. Так что жрите бинарь под неудобные вам операционки или GTFO. Я предпочитаю второе т.к. есть gcc.

     
     
  • 4.87, Аноним (-), 15:17, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    как твой топик связан с тем что у GCC не эталонная поддержка C ?
    у того же CLANG и то лучше поддержка стандартов C.
     
     
  • 5.90, Crazy Alex (ok), 17:49, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Речь о том, что GCC можно использовать как стандарт де-факто - он есть практически везде.
     
     
  • 6.91, Аноним (-), 18:02, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    везде есть свои компиляторы. И если не писать код под GCC - то код получится переносим между компиляторами - чего не может себе позволить gcc.
    Особенно интересный вариант когда код перестает собираться разными версиями компилятора.
     
     
  • 7.97, annulen (ok), 22:25, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >везде есть свои компиляторы.

    Но для многих embedded-платформ GCC - единственный компилятор, поддерживаемый вендором.

     
     
  • 8.109, Aesthetus Animus (ok), 02:08, 23/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Например Для каких это embedded платформ gcc единстсвенный компилятор ... текст свёрнут, показать
     

  • 1.77, inferrna (?), 05:30, 21/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Можно взять LLVM и дописать модулями недостающий до gcc функционал под GPL лицензией. Это будет проще, чем переписывать всё на крестах и лучше, чем "будет обладать меньшей функциональностью, чем текущий GCC, будет менее оптимизированным и менее мощным".
     
     
  • 2.98, annulen (ok), 22:26, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Можно взять LLVM и дописать модулями недостающий до gcc функционал под GPL
    > лицензией.

    А лучше под BSD, чтобы не плодить форки.

     

  • 1.81, Аноним (-), 10:00, 21/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Дядя бредит похоже. Никто не будет переписывать настолько большой проект, может сделают бранч и там будут эксперименты ставить, сомневаюсь что это будет GCC 5, скорее какой-нибудь GCC-alternative 5.

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

     
     
  • 2.117, fr0ster (ok), 09:36, 24/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > По поводу лицензий - всем корпорациям GNU GPL как бельмо на глазу,
    > ведь не дает закрывать и продавать чужой труд, ай ай ай,
    > какие плохие свободные разработчики, не дают свой труд закрывать и продавать.
    > Поэтому они так и радеют за BSDL, бздунишки уже привыкли к
    > рабству.

    Не всем корпорациям, а малой части делающей профит именно на закрытости сырцов.
    Большей части корпораций ЖоПЛь это защита инвестиций и очень полезная лицензия.
    А для тех, кому нет денег и времени на патентные войны, вообще манна небесная.

     

  • 1.83, alex.h (??), 10:30, 21/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С таким объёмом изменений лучше новый проект начинать, по крайней мере, не будет той стадии, что старое уже сломали, а новое ещё не сделали.
     
  • 1.88, Sauron (??), 15:30, 21/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    По ходу проект в тупик зашел, #gccкапец видимо не за горами.
    ЗЫ
    Надо было лицензию на LGPL менять! Компилятор слишком нужная вещь, чтобы для него GPLv3 юзать.
     
  • 1.95, Аноним (-), 18:07, 21/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    срочно нужен аналог LLVM под GPLv3 и выше. сделать и потом перетягивать туда парсер из gcc, оптимизатор, кодогенратор и тд. а не ломать все и хоронить
     
     
  • 2.101, kshetragia (ok), 08:06, 22/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В который раз говорю - поздно пить боржоми. Такая недальновидность - вообще характерная черта GPL щиков.
     
     
  • 3.102, Andrey Mitrofanov (?), 09:19, 22/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > В который раз говорю -

    Да, мы поняли: ты тоже _только разговариваешь.

     
     
  • 4.126, kshetragia (ok), 12:03, 26/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Боюсь до тебя мне далеко по части разговоров.
     

  • 1.105, Kodir (ok), 15:25, 22/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > "Подобная переработка архитектуры сегодняшнего GCC очень сложна (быть может, даже и невозможна)

    Поэтому нет смысла тыкать труп ГЦЦ - нужно все силы бросить на LLVM.
    Причём никто не просит "убивать" ГЦЦ - пусть и дальше "компилирует под 100 архитектур", но развивать нужно правильную кодовую базу! А у ГЦЦ она - такое же фуфло, как ядро линукса - монолитное гуано.

    > хотя бы потому, что мы не можем однозначно решить к какому отдельному модулю, какой код компилятора должен принадлежать.

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

    А вообще, надо D развивать, а не эти тухлые концепции! :)

     
     
  • 2.107, Аноним (-), 17:26, 22/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > понятно, что не всё так просто, но разве компилятор настолько неразрывен, что невозможно провести декомпозицию?

    Гцц значительно старше LLVM, ему не один десяток лет. Изначально хорошая архитектура со временем часто обрастает костылями, а переписывать с нуля это добро охотников мало

     
     
  • 3.108, Andrey Mitrofanov (?), 18:17, 22/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Гцц значительно старше LLVM, ему не один десяток лет.

    ""GCC celebrates 25 years with the 4.7.0 release
    http://lwn.net/Articles/487956/rss

    > Изначально хорошая архитектура со временем часто обрастает костылями,

    Вам, безусловно, виднее.

    BTW, GNU screen-у тоже стукнуло 25 http://noone.org/blog/English/Computer/Shell/Happy%2520Birthday%252

     
  • 2.115, arisu (ok), 15:28, 23/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а у тебя, конечно, есть компилятор и ядро с идеальными архитектурами. не покажешь ли?
     

  • 1.110, Аноним (110), 09:26, 23/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    у LLVM своя делянка, у гцц своя. не понимаю, зачем лезть в чужую делянку ? своя что ль мала ? Надеюсь завернут они все эти чудо изменения и будет все по прежнему - поддержка тонны платформ и нормальный с.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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