The OpenNET Project / Index page

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

Анонсирован проект LLVMLinux, нацеленный на обеспечение сборки ядра Linux при помощи Clang

12.09.2012 11:06

В списке рассылки разработчиков LLVM публично анонсирован проект LLVMLinux, созданный под покровительством организации Linux Foundation для обеспечения сборки ядра Linux с использованием компилятора Clang. Проект LLVMLinux сформирован на основе ряда разрозненных инициатив, в рамках которых осуществлялись попытки решения проблем при сборке ядра с использованием Clang. В частности, учтены наработки проекта lll-project, команды разработчиков PAX и консорциума Linaro.

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

Отправной точкой LLVMLinux послужила работа по задействованию Clang для сборки ядра Linux для платформы ARM, выполненная консорциумом Linaro в рамках инициативы по улучшению поддержки архитектуры ARM в Linux. На основе порта для ARM были подготовлены аналогичные порты для архитектур i586 и x86_64. В дальнейшем спектр поддерживаемых архитектур планируется расширить (например, добавить поддержку MIPS, PowerPC), если найдутся заинтересованные в подобной работе лица.

Проект LLVMLinux охватывает два направления - решение проблем в ядре Linux при сборке с использованием Clang (уход от использования GNU-расширений, специфичных для GCC)) и адаптация Clang для особенностей ядра. Созданные разработчиками LLVMLinux патчи активно продвигаются в upstream-проекты - ядро Linux и LLVM/Clang. В конечном итоге, планируется из коробки обеспечить формирование полностью работоспособных Clang-сборок ядра Linux, а также обеспечить работу тестового окружения для постоянного мониторинга за появлением регрессивных изменений, проявляющихся при сборке в Clang.

Для упрощения формирования сборочного окружения и кросс-компиляции ядра с использованием Clang подготовлен специальный сборочный инструментарий. Сборки ядра для архитектур ARM, i586 и x86_64, за редким исключением, полностью работоспособны и позволяют получить рабочие системы, но ещё требуют большой работы по тестированию и выявлению неявных проблем, поэтому подобные сборки пока не рекомендуются для применения в конечных продуктах.

Из наблюдаемых при сборке ядра с использованием Clang проблем, которые пытается решить проект LLVMLinux, отмечаются:

  • Использование массивов переменной длины в некоторых структурах ядра (SELinux, Posix ACL, IPSec, eCrypt);
  • Kbuild, который завязан на особенностях GCC;
  • Использование явных регистровых переменных;
  • Использование расширенных аннотаций __refdata;
  • Применение EXPORT_SYMBOL в inline-функциях;
  • Вывод в Clang сообщений об ошибках из-за переопределения POSIX-функций в ядре;
  • Использование неподдерживаемых в Clang флагов компиляции: "-fdelete-null-pointer-checks", "--fno-inline-functions-called-once", "--Wno-unused-but-set-variable" и "--mabi=aapcs-linux".


  1. Главная ссылка к новости (http://lists.cs.uiuc.edu/piper...)
  2. OpenNews: Продемонстрирован запуск openSUSE с ядром Linux, собранным при помощи Clang
  3. OpenNews: Эксперимент по пересборке Debian с использованием Clang показал неожиданно хорошие результаты
  4. OpenNews: В Clang обеспечена возможность сборки Linux-ядра 2.6.36
  5. OpenNews: На базе Sparse создан LLVM-бэкенд, нацеленный на пересборку ядра Linux
  6. OpenNews: Обеспечена возможность сборки LibreOffice компилятором Clang
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: llvmlinux, clang, kernel, build
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (62) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Писёв (?), 11:49, 12/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    В арче еще в апреля 2011 собирали - https://aur.archlinux.org/packages.php?ID=48519
     
     
  • 2.9, Аноним (-), 13:39, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > В арче еще в апреля 2011 собирали - https://aur.archlinux.org/packages.php?ID=48519

    Только после такой сборки половина модулей не работала.

     
     
  • 3.10, Аноним (-), 13:42, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> В арче еще в апреля 2011 собирали - https://aur.archlinux.org/packages.php?ID=48519
    > Только после такой сборки половина модулей не работала.

    и грузилась система только в консоль, X-ы не стартовали из-за проблем с драйверами.

     

  • 1.2, Аноним (-), 11:50, 12/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Только бы не в ущерб производительности, все это специфичны фишечки GCC не просто так использовались
     
     
  • 2.14, Аноним (-), 14:07, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    "Использовались". Прошедшее время. Тогда все эти специфичные фишечки GCC создавались потому, что в стандарте Си они отсутствовали. Сейчас, когда многое из необходимого есть в стандарте, использовать специфичные для компилятора решения нет смысла.
     
     
  • 3.40, Писёв (?), 17:23, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Многое используется и сейчас, не надо ля-ля. Нулевые массивы, ожидание ветвления, красивые функции.. Много чего.
     
     
  • 4.61, Аноним (-), 12:12, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    массивы 0 длины - в стандарте,
    ожидание ветвления - уже удаляют, как-то вот оно больше мешает - чем помогает.

    Красивые функции? это что такое..

     

  • 1.3, Геста (?), 11:56, 12/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    gcc быстрее, но clang надежнее? бросаем-подбираем?
     
     
  • 2.11, Vkni (ok), 13:44, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +13 +/
    > gcc быстрее, но clang надежнее? бросаем-подбираем?

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

    Поэтому поддержка несколькими компиляторами сборки ядра Linux только поможет избавлению от ошибок и отладке ядра.

     
     
  • 3.12, Геста (?), 13:48, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, учитывая что сообщения об ошибках в gcc по сравнению с clang полное уг, это можно только приветствовать. По-хорошему, в ОС вообще не должно быть специфичных для конкретного компилятора конструкций, не дело среды исполнения влиять на стандарты языка.
     
     
  • 4.15, Аноним (-), 14:46, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    учитывая, что си создавался для написания юникса, то ваше заявление слегка наивно
     
  • 4.22, Аноним (-), 16:14, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >сообщения об ошибках в gcc по сравнению с clang полное уг

    обманывать нехорошо.

    http://gcc.gnu.org/wiki/ClangDiagnosticsComparison

     
     
  • 5.26, an. (?), 16:23, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за ссылку - круто, что ребята из gcc не отстают. Однако, gcc 4.8 еще не релиз, а 4.7 такой красоты еще не печатает, в то время как clang 3.1 - это релиз и ведет себя как написано. Так что указанное выше не обман, а текущее состояние дел, которое впрочем вскоре вполне может измениться.
     
     
  • 6.34, ананим (?), 16:46, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    релиз, не релиз, а сабж он пока не компилирует.
    и код у него плохо оптимизированный на выходе.

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

     
     
  • 7.44, Аноним (-), 19:14, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > релиз, не релиз, а сабж он пока не компилирует.

    так же как и текущий гцц не показывает таких сведений об ошибке.

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

    Профи, можно ваши проекты увидеть?

     
     
  • 8.48, ананим (?), 20:25, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    можно а ваши очень хочется на ошибки посмотреть, которые важнее производительн... текст свёрнут, показать
     
     
  • 9.62, Аноним (-), 12:17, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    мисье видимо не читал Кнута и Вирта ну да это не модно сейчас читать в Ылытно... текст свёрнут, показать
     
     
  • 10.66, ананим (?), 13:54, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    в психбольнице день открытых дверей ... текст свёрнут, показать
     
  • 5.29, Алексей (??), 16:33, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Спасибо clang, что ребята из gcc начали наконец заботится о нуждах пользователей.
     
  • 5.36, Геста (?), 17:01, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не-не-не, это 4.8, а в продакшене пока что этой красоты нет.
     
  • 5.70, arisu (ok), 00:59, 14/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > http://gcc.gnu.org/wiki/ClangDiagnosticsComparison

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

     
  • 4.41, Писёв (?), 17:24, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ошибки компиляции - не самые страшные ошибки.
     
     
  • 5.60, Vkni (ok), 11:00, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ошибки компиляции - не самые страшные ошибки.

    Да. Более того, для них есть статические анализаторы. Но, блин, встречаются и ошибки, которые не ловятся ни чем. :-(

     
     
  • 6.67, ананим (?), 13:57, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    да тут всё больше про оформление этих ошибок.
    а если она не поймана, то и не оформлена :D
     
     
  • 7.69, Vkni (ok), 22:30, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > да тут всё больше про оформление этих ошибок.
    > а если она не поймана, то и не оформлена :D

    Мы не про ошибки синтаксиса, которые ловятся компилятором. А про сложные ошибки выполнения, которые очень редко ловятся отладчиком.

     

  • 1.4, IMHO (?), 12:15, 12/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    некоторым важно качество, некоторым скорость, а некоторые сравнивают только лицензию clang vs gcc
    ))))
     
  • 1.13, JL2001 (ok), 13:57, 12/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    и самое главное - все багфиксы и оптимизации в оптимизаторах и "линковщиках" (которые байткод llvm в машинный код) сделанных для clang (компилятора с сей) будут работать для компиляторов со всех жав, D, сишарпов, фортранов и прочего
    за счёт этого llvm будет бибикать gcc

    а лицензию таки жалко что не та :(

     
     
  • 2.17, Аноним (-), 14:58, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    пффф, эпл как раз и создает этот компилятор, потому что им нужен компилятор именно с "не той" лицензией
     
     
  • 3.20, IMHO (?), 15:33, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • –11 +/
    цытирую Проблема, как ни удивительно, не в GPL, а в одном копирасте по фамили... текст свёрнут, показать
     
     
  • 4.23, ананим (?), 16:19, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    полная брехня. http://en.wikipedia.org/wiki/LLVM
    >In 2005, Apple Inc. hired Lattner and formed a team to work on the LLVM system for various uses within Apple's development systems

    http://lists.trolltech.com/qt4-preview-feedback/2005-02/msg00691.html
    >Date: Sat, 19 Feb 2005 14:57:49 -0500
    >The creator and lead author, Chris Lattner, has just been hired by Apple to  work on LLVM.  Apple is making a major investment in this compilation  strategy.

    http://en.wikipedia.org/wiki/GNU_General_Public_License#Version_3
    >In late 2005, the Free Software Foundation (FSF) announced work on version 3 of the GPL (GPLv3). On 16 January 2006, the first "discussion draft" of GPLv3
    >....
    >The final version of the license text was published on 29 June 2007

    первое(!!!) обсуждение GPLv3 появилась с отставанием более чем в 1 год говорит, что анонимус с ЛОР"а либо вообще не дружат с логикой, либо наглоё враньё уже часть его натуры.
    типа не соврал, день прошёл зря

     
     
  • 5.39, IMHO (?), 17:05, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • –5 +/

    > первое(!!!) обсуждение GPLv3 появилась с отставанием более чем в 1 год говорит,

    для особо религиозных, сменил != вышла, читать научитесь
    по вашему все пошло так  мигом, что можно все скинуть в одну кучу и сказать, это было так

     
     
  • 6.42, ананим (?), 18:27, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а "сменил" - это ещё позже, чем вышла.
    как бы очевидно, что вначале вышла GPLv3 и уже потом gcc под этой лицензией.
    соответсвенно выод прост - яблоко занялось разработкой llvm/clang задолго того момента, когда РМС о ней думать стал и тем более задолго, когда стал думать о смене лицензии на gcc.

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

     
  • 4.25, Аноним (-), 16:22, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Теперь мы имеем clang, который архитектурно превосходит гцц, но сливает в размере
    > кодовой базы и числу оптимизаций

    Есть интересные особенности, но говорить про "архитектурное превосходство" это очень наивно. Сколько лет он уже "архитектурно превосходит", а код на выходе унылый. Через склько лет начнете подозревать что не все так просто? Еще месяц и он порвет GCC? Не, после Нового года? Ладно, вот весной уже точняк!

     
     
  • 5.30, IMHO (?), 16:37, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    если честно то мне пофиг чем собран дистрибутив или ОС, главное что бы работало, если у кого то к этому религиозные взгляды то я не виноват.
    Что мы имеем, clang APPLE использовала для iOS - средствами obj-c, потом случилось что писал выше анонимус с лора, ка известно кроме iOS, ... еще есть МасOS X, и МАС на линукс ядре в котором и применялся GCC.
     
     
  • 6.33, IMHO (?), 16:43, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/

    >  Что мы имеем, clang APPLE

    опячатался LLVM

     
     
  • 7.46, ананим (?), 19:23, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а это тогда что?
    >и МАС на линукс ядре в котором и применялся GCC.

    тоже очепятка?

     
     
  • 8.50, res2500 (?), 20:32, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    есть версия мас с линукс ядром ... текст свёрнут, показать
     
     
  • 9.51, ананим (?), 20:48, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не слышал такого пруф можно ... текст свёрнут, показать
     
  • 6.43, Аноним (-), 19:06, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    иди к ембедшикам и расскажи про шланг.
     
  • 5.31, Алексей (??), 16:37, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Реально clang относительно молод, но при этом прогресс и скорость его разработки впечатляют. Смотря на то, как разработчики gcc активизировались на разработке давно обещаемых полезных фич можно сказать, что clang для gcc безусловное благо.
     
     
  • 6.35, ананим (?), 16:55, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    что за глупости...
    так и мс видимо благо для андроида, а огрызок для самсунга.
    черное - это такой оттенок белого и не более, следовательно чёрное - это белое.

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

     
     
  • 7.63, Аноним (-), 12:24, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/

    > gcc разрабатывался постоянно с такой скоростью и возможностями.
    > хоть 20 шлангов выйдет - это никак не увеличит рабочий день сотрудникам.

    Сознательно врешь или просто не знаешь?
    egcc видио появлялся просто так...


     
     
  • 8.68, ананим (?), 13:59, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вы и логика - это видимо вещи совсем ортогональные ... текст свёрнут, показать
     
  • 6.38, Аноним (-), 17:03, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Именно про это я и написал. Давно уже так говорят, а код все такой же неоптимальный.
     
  • 6.71, arisu (ok), 01:02, 14/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > на разработке давно обещаемых полезных фич

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

     
  • 2.19, inferrna (ok), 15:20, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Форкай, делов.
     
     
  • 3.24, ананим (?), 16:21, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    форкнуть под другую, не совместимую лицензию нельзя.
     
     
  • 4.32, Алексей (??), 16:38, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > форкнуть под другую, не совместимую лицензию нельзя.

    Под gpl можно. Только кто его будет разрабатывать?

     
     
  • 5.45, ананим (?), 19:21, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    без понятия.
    лично мне не нужна.

    хотя попытки компилировать ядро приветствую. но толку тут будет больше шлангу, чем ядру, т.к. ядро ещё и пилится интелом (вспоминаем LTO - http://www.opennet.ru/opennews/art.shtml?num=34619 ), также их компилятором icc, таже работа идёт в амд (Open64 http://www.opennet.ru/opennews/art.shtml?num=32275 ) и ещё рядом заинтересованных компаний.
    так что у ядра линукс более чем достаточно и интсрументов для всестороннего тестирования, и желающих это тестирование проводить.
    но если и из сабжа придёт хоть крупица улучшений для ядра, то это будет не плохо.

    так что сабж - это опыт и технологии полезные именно ему (научить компилить ядро, посмотреть результаты, устранить недочёты и тд)

    зыж
    а вот llvm очень интересен сам по себе.
    но это не имеет отношение ни к сабжу, ни к ядрам.

     
  • 2.27, ананим (?), 16:23, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >сделанных для clang (компилятора с сей) будут работать для компиляторов со всех жав, D, сишарпов, фортранов и прочего

    пусть это прочее вначале появится :D
    а то там токо обджси и шланг более менее стандратам соответсвуют

     
     
  • 3.47, JL2001 (ok), 19:26, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>сделанных для clang (компилятора с сей) будут работать для компиляторов со всех жав, D, сишарпов, фортранов и прочего
    >пусть это прочее вначале появится :D
    >а то там токо обджси и шланг более менее стандратам соответсвуют

    компилеры жавы и D на основе gcc тоже никаким стандартам не соответствуют, так что....
    зы: и не верится что в них будет ещё и оптимизация кроме сооответствия

     
     
  • 4.49, ананим (?), 20:30, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    следовательно

    > llvm будет бибикать gcc

    вот и выяснили, что не кому и не зачем бибикать. :D

     
     
  • 5.55, JL2001 (ok), 00:07, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > вот и выяснили, что не кому и не зачем бибикать. :D

    выяснили что написать компилер целиком слишком сложно, а один фронтенд с языка в байткод сильно проще написать

     
     
  • 6.56, ананим (?), 01:20, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ха! пруфы привести с подавляющим большинством поддерживаемых языков и архитектур по сравнению с gcc можете?
    нет? я так и думал.
    зыж
    и да!
    >выяснили что написать компилер целиком слишком сложно, а один фронтенд с языка в байткод сильно проще написать

    gcc так всегда и делал! :D
    http://gcc.gnu.org/wiki/StructureOfGCC
    и кстати, за последние годы отрыв по поддерживаемым языкам и платформам у gcc только увеличился.

     
     
  • 7.59, JL2001 (ok), 10:57, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > http://gcc.gnu.org/wiki/StructureOfGCC

    спасибо за ссылку, этого я не знал

     
  • 2.53, Anus Anus Ananimus (?), 22:48, 12/09/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Бибикалка у шланга не доросла, чтобы на ГЦЦ бибикать...
    Шланг пока для некоторых архитектур генерит код кривой как винт моторной лодки ( я занимаюсь разработкой под ARM/MIPS). Для ARM код кривой, для MIPS, AVR, PowerPC он вообще не умеед код генерить. Давайте уж о эфемерном бибиканье будем говорить, когда оно по числу поддерживаемых архитектур хотя-бы на 70% догонит ГЦЦ.
     
     
  • 3.54, JL2001 (ok), 00:06, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Шланг пока для некоторых архитектур генерит код кривой как винт моторной лодки
    > ( я занимаюсь разработкой под ARM/MIPS). Для ARM код кривой, для
    > MIPS, AVR, PowerPC он вообще не умеед код генерить. Давайте уж
    > о эфемерном бибиканье будем говорить, когда оно по числу поддерживаемых архитектур
    > хотя-бы на 70% догонит ГЦЦ.

    "Отправной точкой LLVMLinux послужила работа по задействованию Clang для сборки ядра Linux для платформы ARM, выполненная консорциумом Linaro в рамках инициативы по улучшению поддержки архитектуры ARM в Linux. На основе порта для ARM были подготовлены аналогичные порты для архитектур i586 и x86_64." - значит пилят на арм вот прям щас
    ну и "В дальнейшем спектр поддерживаемых архитектур планируется расширить (например, добавить поддержку MIPS, PowerPC), если найдутся заинтересованные в подобной работе лица."

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

     
     
  • 4.57, ананим (?), 01:30, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    столько бреда и в одном комментарии. даже и не знаю как это прокомментировать то.
    это АНОНС только начала работ.

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

    это новое слово в науке и технике. :D
    для тех кто не знает архитектуры gcc.
    в общем просвещайтесь - http://gcc.gnu.org/wiki/StructureOfGCC

     
     
  • 5.64, Аноним (-), 12:26, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/

    > это новое слово в науке и технике. :D
    > для тех кто не знает архитектуры gcc.
    > в общем просвещайтесь - http://gcc.gnu.org/wiki/StructureOfGCC

    одно слово. Дурак - даже читать не умеешь что там пишут - там указаны функциональные части - но на самом деле gcc монолит.

     
     
  • 6.65, ананим (?), 13:51, 13/09/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    о-о-о!... безнадёжный случай.
    мои соболезнования вашим родителям.
     
  • 6.72, Тупой молодец (ok), 18:23, 07/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >одно слово. Дурак - даже читать не умеешь что там пишут - там указаны функциональные части - но на самом деле gcc монолит.

    О_о

     

  • 1.58, Аноним (-), 02:31, 13/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > позволяет задействовать дополнительные техники оптимизации

    В каждой новости это пишут. И в каждом бенче видно что с хваленой оптимизацией как-то хреновато :)

     

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



    Спонсоры:
    MIRhosting
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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