URL: https://linuxfr.org/news/llvm-3-3-et-clang-3-3 Title: LLVM 3.3 et Clang 3.3 Authors: rewind Davy Defaud, teoB, Jiehong, Sylvestre Ledru, claudex, patrick_g, Florent Zara, EdB, Nicolas Casanova et kadalka Date: 2013年05月11日T17:03:00+02:00 License: CC By-SA Tags: debian, interview, llvm, clang, objective-c, fortran et ubuntu Score: 73 Le projet LLVM est un ensemble de technologies modulaires et réutilisables destinées à construire des chaînes de compilation et des compilateurs. Ce projet a grandi depuis ses débuts en tant que [projet de recherche](http://llvm.org/pubs/2004-01-30-CGO-LLVM.html) à l’[Université de l’Illinois](http://cs.illinois.edu/) pour maintenant rivaliser avec l’[autre grand compilateur du monde libre](http://gcc.gnu.org/). À l’aube de ses 10 ans, le projet est on ne peut plus actif, attirant aussi bien des industriels (ARM, IBM, Qualcomm, Google, Intel, etc.) que des chercheurs. ![logo LLVM](http://upload.wikimedia.org/wikipedia/fr/c/c8/LLVM-Logo.png) Le projet LLVM, ainsi que Clang, le compilateur C/C++/ObjectiveC officiel du projet, [sont sortis dans leur version 3.3 le 17 juin 2013](http://lists.cs.uiuc.edu/pipermail/llvm-announce/2013-June/000046.html). LLVM apporte la prise en charge de nouvelles architectures. Clang implémente désormais la totalité du standard C++11. Ces nouveautés sont détaillées dans la seconde partie de la dépêche. La conférence européenne LLVM 2013 qui s’est déroulée les 29 et 30 avril derniers à Paris, a permis de voir certaines améliorations possibles qui seront peut‐être un jour intégrées dans LLVM/Clang. Enfin, il est important de noter que LLVM a reçu le [_2012 System Software Award_](http://awards.acm.org/software_system/year.cfm), rejoignant ainsi Eclipse (2011), Java (2002), TCP/IP (1991) et tant d’autres. ---- [The LLVM Compiler Infrastructure](http://llvm.org/) [2013 European LLVM Conference](http://llvm.org/devmtg/2013-04/) [Sources et binaires de la version 3.3](http://llvm.org/releases/3.3/) [Notes de version de LLVM 3.3](http://llvm.org/releases/3.3/docs/ReleaseNotes.html) [Notes de version de Clang 3.3](http://llvm.org/releases/3.3/tools/clang/docs/ReleaseNotes.html) [Annonce de LLVM 3.3](http://lists.cs.uiuc.edu/pipermail/llvm-announce/2013-June/000046.html) ---- # LLVM ## Architectures De nouvelles architectures sont désormais prises en charge par LLVM 3.3 : AArch64, z/Architecture et R600. D’autres architectures ont été améliorées : x86, ARM, MIPS et PowerPC. ### AArch64 L’architecture [AArch64](http://www.realworldtech.com/arm64/) est la nouvelle architecture 64 bits des processeurs ARM. La particularité de cette architecture est qu’il n’existe à l’heure actuelle aucun matériel avec cette architecture. Mais sa prise en charge [dans les compilateurs](http://linuxfr.org/news/la-version-4-8-du-compilateur-gcc-est-disponible#toc_4) et [dans les systèmes d’exploitation](http://linuxfr.org/news/sortie-du-noyau-linux-3-7#toc_11) suit son cours. En ce qui concerne LLVM, il est déjà possible de compiler du C99 ou du C++03 sur Linux, si le code et les données statiques ne dépassent pas 4 Gio. Il est aussi possible de générer des informations de débogage au format DWARF. ### z/Architecture La [z/Architecture](http://en.wikipedia.org/wiki/Z/Architecture) est l’architecture des ordinateurs centraux — [_mainframes_](http://fr.wikipedia.org/wiki/Ordinateur_central) — _zSeries_ d’IBM. Ulrich Weigand qui travaille pour IBM a [fait état de l’avancement de la prise en charge de cette architecture](http://llvm.org/devmtg/2013-04/weigand-slides.pdf) en précisant que LLVM était maintenant considéré comme un composant critique pour IBM. Il cite notamment l’utilisation de LLVM en tant que compilateur à la volée dans le pilote Mesa/Gallium3D [llvmpipe](http://www.mesa3d.org/llvmpipe.html) et dans certaines applications de base de données propriétaires. Preuve que LLVM dépasse largement le petit monde de la compilation C/C++. ### R600 On a plutôt l’habitude de lire des nouvelles de l’[architecture R600](http://fr.wikipedia.org/wiki/Radeon_R600) dans les nouvelles du noyau au chapitre des améliorations des cartes graphiques. Eh bien, LLVM n’est pas en reste, puisque la prise en charge de cette architecture a été ajoutée à LLVM dans le cadre du développement des pilotes libres Mesa3D. LLVM est dans ce cas utilisé en conjonction avec [Gallium3D](http://fr.wikipedia.org/wiki/Pile_graphique_Linux) pour la prise en charge d’[OpenCL](http://fr.wikipedia.org/wiki/OpenCL), et optionnellement pour la compilation des [_shaders_](http://fr.wikipedia.org/wiki/Shader) OpenGL. ### x86 et ARM La nouvelle interface [_TargetTransformInfo_](http://llvm.org/doxygen/classllvm_1_1TargetTransformInfo.html) permet dorénavant aux outils travaillant au niveau de la représentation intermédiaire d’avoir des informations sur le coût des instructions, de manière à pouvoir faire de meilleurs choix. Cette interface a permis de définir un modèle de coût pour les architectures x86 et ARM, et donc de potentiellement améliorer le code obtenu. Cette fonctionnalité est utilisée pour la [vectorisation des boucles](http://blog.llvm.org/2013/05/llvm-33-vectorization-improvements.html) qui est maintenant activée au niveau d’optimisation `-O3`. ### MIPS Clang prend désormais en charge des options concernant l’[ABI](http://fr.wikipedia.org/wiki/Application_binary_interface) (32 ou 64 bits, [gros‐boutisme](http://fr.wikipedia.org/wiki/wikt:gros-boutisme "Définition Wikipédia") ou [petit‐boutisme](http://fr.wikipedia.org/wiki/wikt:petit-boutisme "Définition Wikipédia"), simple précision ou double précision). De plus, l’ensemble d’instructions DSP-ASE (Application-Specific Extension) peut maintenant être généré directement sans avoir besoin d’une [fonction intrinsèque](http://fr.wikipedia.org/wiki/fonction intrinsèque "Définition Wikipédia") _(builtin)_. Ces instructions servent essentiellement pour les applications multimédia. ### PowerPC La prise en charge de PowerPC a été grandement améliorée sur de nombreux points : meilleure [allocation de registres](http://fr.wikipedia.org/wiki/allocation de registres "Définition Wikipédia"), lecture et écriture 64 bits atomiques, amélioration de la génération de code pour les comparaisons et les accès mémoire non alignés, prise en charge de `setjmp`/`longjmp` en ligne, ainsi que d’instructions de [PowerISA](http://en.wikipedia.org/wiki/IBM_POWER_Instruction_Set_Architecture) 2.04, 2.05 et 2.06. LLVM peut maintenant lire de l’assembleur PowerPC. ## Divers La documentation de LLVM et de Clang est désormais générée à l’aide de [Sphinx](http://sphinx-doc.org/). Ce passage par Sphinx a permis de mettre de l’ordre dans toute la documentation, et le [résultat](http://llvm.org/docs/index.html) est bien plus lisible et compréhensible qu’auparavant. # Clang ## Prise en charge complète de C++11 Clang prend désormais en charge l’[intégralité de C++11](http://blog.llvm.org/2013/04/clang-support-for-c11-and-beyond.html). Les derniers éléments apparus dans Clang 3.3 sont les suivants. ### Prise en charge des attributs Clang prend en charge la syntaxe générique pour les attributs, ainsi que les deux attributs `[[noreturn]]` (qui permet de spécifier qu’une fonction ne reviendra jamais) et `[[carries_dependency]]` (qui permet de prévenir le compilateur de ne pas émettre de barrière mémoire inutile). ### Héritage de constructeur Clang gère maintenant l’héritage de constructeur, qui permet d’utiliser un constructeur de la classe mère sans avoir à le réimplémenter dans la classe fille. La nouvelle [GCC 4.8](http://linuxfr.org/news/la-version-4-8-du-compilateur-gcc-est-disponible#toc_3) donne plusieurs exemples pour comprendre le principe. ### Variables `thread_local` Clang permet de définir des [variables locales aux fils d’exécution](http://fr.wikipedia.org/wiki/Thread_Local_Storage) via le mot‐clef `thread_local`. La principale difficulté est la construction et la destruction d’objets qui sont placés dans la mémoire locale de la tâche. Il est nécessaire d’avoir une gestion au moment de l’exécution _— runtime —_ à travers l’appel à la bibliothèque `__cxa_thread_atexit`, qui n’est pour l’instant disponible que dans celle fournie avec G++ 4.8. ### C++1y On vient à peine de s’habituer à C++11 que la prochaine version est déjà sur les rails. Pour l’instant, C++1y apporte principalement des améliorations et des corrections par rapport à toutes les nouveautés introduites dans C++11. Ce nouveau standard devrait apparaître en 2014. LLVM implémente déjà [certaines de ces corrections](http://clang.llvm.org/cxx_status.html) qui peuvent être activées via l’option `-std=c++1y`. ## Divers Clang permet désormais d’utiliser des identifiants étendus pour C99 et C++, c’est‐à‐dire des identifiants qui utilisent certains caractères [[Unicode]] en plus des caractères ASCII traditionnels. Il est possible d’écrire ces identifiants en UTF-8 ou avec les notations `\uXXXX` ou `\UXXXXXXXX`. ## Analyseur statique L’[analyseur statique de Clang](http://clang-analyzer.llvm.org/) a gagné quelques fonctionnalités. L’analyse inter‐procédurale a été améliorée sur de nombreux points : les constructeurs et destructeurs sont mieux traités, les faux positifs concernant le déréférencement de pointeurs nuls ont été diminués et l’analyse est globalement plus rapide. Les nouvelles erreurs suivantes sont détectées : * utilisation d’un pointeur après sa désallocation dans le cas d’un `delete` du C++ ; * détection d’un allocateur et d’un désallocateur non concordant (`malloc`/`delete` ou `new`/`free`). ## Un outil de migration vers C++11 : `cpp11-migrate` L’arrivée de C++11 permet d’adopter des syntaxes qui sont parfois plus concises et moins génératrices d’erreurs. On pense notamment à la définition des itérateurs qui peut maintenant être évitée de deux façons, soit par le mot‐clef `auto` qui permet d’inférer le type localement, soit via la nouvelle forme du `for` qui itère directement sur les éléments sans passer par un itérateur. Seulement, de grosses bases de code utilisent la vieille syntaxe et il est impensable de devoir tout changer à la main. C’est là qu’intervient [l’outil `cpp11-migrate`](http://blog.llvm.org/2013/04/status-of-c11-migrator.html). Cet outil basé sur les bibliothèques [LibTooling](http://clang.llvm.org/docs/LibTooling.html) et [LibASTMatchers](http://clang.llvm.org/docs/LibASTMatchers.html) permet d’automatiser ces tâches et d’appliquer des transformations au code. À l’heure actuelle, les transformations suivantes sont prises en charge : - le `for` basé sur les intervalles. Que ce soit via des itérateurs ou en parcourant un tableau, ou même un conteneur qui implémente l’opérateur d’indexation (`operator[]`), la transformation se fait automatiquement ; - l’introduction de `nullptr` partout où est utilisé `NULL` ou 0 (qui était conseillé par rapport à `NULL` en C++ jusque là) ; - le remplacement du type dans une déclaration par `auto`. Il se fait dans les cas suivants : quand le type est un itérateur d’un conteneur de la STL ou quand l’initiateur est un appel à `new` ; - l’ajout d’`override`. Quand une méthode virtuelle est ré‐implémentée dans une classe fille, il est maintenant conseillé d’ajouter l’attribut `override`. L’outil peut s’en charger automatiquement. Les [options de cet outil](http://clang.llvm.org/extra/cpp11-migrate.html) permettent de calibrer le degré de modification pour être sûr de ne pas détruire tout un projet. Cet outil a été appliqué en test sur des projets de taille assez conséquentes, LLVM et [ITK](http://www.itk.org/), ce qui a permis de détecter de nombreux bogues, et d’améliorer son efficacité et sa robustesse. Il est prévu de l’appliquer sur [LLDB](http://lldb.llvm.org/), [OpenCV](http://opencv.org/) et [Poco](http://pocoproject.org/). ![Logo LLVM 2](http://upload.wikimedia.org/wikipedia/en/thumb/4/4c/LLVM_Logo.svg/500px-LLVM_Logo.svg.png) # LLVM et Clang dans Debian Dès que l’on parle de LLVM/Clang et Debian, il faut bien évidemment évoquer l’énorme travail de [Sylvestre Ledru](http://linuxfr.org/users/grayswandir). En plus de son travail d’intégration de LLVM/Clang dans Debian, vous trouverez une entrevue de ce développeur très actif. ## Versions journalières _— nightly builds —_ LLVM et Clang pour Debian Des [versions journalières de LLVM et Clang pour Debian et Ubuntu](http://blog.llvm.org/2013/04/llvm-debianubuntu-nightly-packages.html) sont désormais construites et accessibles sur un dépôt particulier, uniquement pour les architectures i386 et amd64. ## Entrevue avec Sylvestre Ledru **Bonjour Sylvestre, avant toute chose, est‐ce que tu peux te présenter brièvement pour ceux qui ne te connaissent pas ?** Bonjour, j’ai différentes casquettes au quotidien. Mon employeur est [Scilab Enterprises](http://www.scilab-enterprises.com/fr). J’y fais aussi de la gestion de projets (pour des clients ou de [Recherche et Développement](http://fr.wikipedia.org/wiki/Recherche et Développement "Définition Wikipédia")). Je participe aussi au développement sur [Scilab](https://www.scilab.org/) (logiciel libre de calcul numérique). Je travaille en parallèle pour [IRILL](http://www.irill.org/) en tant que _community manager_ (grosso modo, je fais de la communication et je participe à l’organisation d’évènements). Par exemple, j’ai la chance d’y travailler avec [Roberto Di Cosmo](http://fr.wikipedia.org/wiki/Roberto Di Cosmo "Définition Wikipédia"), [Julia Lawall](http://pagesperso-systeme.lip6.fr/Julia.Lawall/) ou [Stefano Zacchiroli](http://fr.wikipedia.org/wiki/Stefano Zacchiroli "Définition Wikipédia"). Enfin, je suis impliqué dans Debian et Ubuntu. Je maintiens plus d’une [soixantaine de paquets](http://qa.debian.org/developer.php?login=sylvestre@debian.org), tout en étant trésorier de [Debian France](http://france.debian.net/). **Quand as‐tu été amené à t’intéresser à LLVM et pourquoi ? Est‐ce que tu utilises LLVM quotidiennement et dans quel cadre ?** Initialement, je suis venu à LLVM plutôt via Clang. J’avais vu une dépêche passer sur _LinuxFr_ sur l’amélioration de la prise en charge de C et C++. Étant convaincu que compiler un logiciel avec différents compilateurs améliore la qualité du code et des applications, j’ai commencé à l’utiliser pour développer sur Scilab. Ensuite, j’ai commencé à m’y intéresser dans le cadre de Debian. Un peu à la manière dont on a réussi à proposer plusieurs noyaux (Linux, HURD et KFreeBSD), je cherche à rendre Debian agnostique en termes de compilateur. Enfin, synergie entre mes intérêts et les besoins de Scilab, dans le cadre du GTLL (Groupe thématique logiciel libre) de Systematic, nous avons monté un projet intitulé [_Richelieu_](http://www.richelieu.pro) qui vise à apporter de la [compilation à la volée](http://fr.wikipedia.org/wiki/compilation à la volée "Définition Wikipédia") _— just‐in‐time —_ dans Scilab, via LLVM/VMKit. Démarré en novembre dernier, j’en assure la coordination. **Qu’est‐ce que tu trouves intéressant dans LLVM/Clang d’un point de vue technique et d’un point de vue utilisateur, en particulier en comparaison du vénérable GCC ?** D’un point de vue utilisateur, avant tout, la qualité des avertissements et erreurs. J’ai toujours un peu de mal avec les pages d’erreurs de g++ lorsque l’on traite avec les _templates_, alors que Clang produit des messages plus clairs et plus concis. Cependant, pour être _fairplay_, poussé par la compétition, GCC, en particulier dans sa version 4.8, améliore aussi fortement ces points (comme, par exemple, le travail de Dodji Seketeli sur l’expansion des macros lors de l’affichage d’erreurs). D’ailleurs, Il ne faut pas voir GCC et Clang comme des adversaires : il ne faut pas oublier qu’il avait été [envisagé que LLVM soit la base d’une future version de GCC](http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html). En parallèle, LLVM et Clang proposent de nombreux greffons et extensions très intéressants comme : * `scan-build`, un analyseur statique de code C/C++/Objective-C pour trouver des bogues « complexes » ; * l’ensemble `{Address,Thread,Memory}Sanitizer`, qui propose d’instrumenter du code binaire pour [trouver des erreurs lors de l’exécution](http://sylvestre.ledru.info/blog/2013/01/12/some_more_cool_stuff_with_llvm_clang) ; * `libclang` pour travailler sur l’[arbre de syntaxe abstrait](http://fr.wikipedia.org/wiki/arbre de syntaxe abstrait "Définition Wikipédia") (AST) C/C++ pour écrire des greffons ou extensions (compilation source à source, par exemple). Enfin, d’un point de vue technique, c’est du code C++ bien architecturé, très bien commenté avec une grosse base de tests. Ainsi, LLVM/Clang permet à des académiques de proposer des implémentations de leurs travaux de recherche d’une manière plus simple et plus rapide qu’avec GCC. Ça peut paraître surprenant mais la communauté LLVM est très forte et amicale. Pas mal de développeurs expérimentés (comme Duncan Sands, Rafael Espindola, etc.) encouragent et aident les débutants à contribuer. Par exemple, lorsque j’ai contribué à quelques _patches_ pour le support de HURD et KFreeBSD dans LLVM, j’ai été surpris de recevoir un courriel d’encouragement d’un développeur employé d’Apple se félicitant de voir le logiciel porté sur ces plates‐formes. **Tu as récemment co‐organisé la conférence européenne des développeurs LLVM. Quel bilan technique et humain tires‐tu de cette conférence ?** Cette conférence a été organisée par les mêmes personnes (Duncan Sands, Tobias Grosser, Arnaud de Grandmaison et moi‐même) qui proposent depuis presque deux ans les _Meetup LLVM_. L’organisation a été facilitée par la participation active d’ARM et par les sponsors. En soit, la conférence fut très intéressante. Parfois un peu trop technique pour des gens pas assez dans le projet (ou pas directement intéressés par un sujet), mais, dans l’ensemble, elle démontre la vigueur de la communauté (on a dû refuser beaucoup de monde à la conférence). De plus, comme la plupart des projets FLOSS, beaucoup de participants ne se voient que lors de ce genre de conférence. C’est vraiment important pour renforcer la communauté, faire progresser les projets et en lancer des nouveaux. Les [vidéos sont disponibles sur le site IRILL](http://www.irill.org/videos/euro-llvm-2013) et [Renato Golin, de Linaro, a publié un compte rendu sur le blog LLVM](http://blog.llvm.org/2013/05/eurollvm-2013-paris-france.html). **Tu es également développeur Debian et tu empaquètes LLVM et Clang pour Debian. Peux‐tu nous parler du travail que tu mènes pour pouvoir rendre Debian indépendante du compilateur ?** Mon objectif final est simple : avoir une version de Debian compilé avec Clang. Le cheminement pour atteindre cet objectif est plus complexe. Évidement, dans un premier temps, le premier travail est d’avoir un [paquet Clang](http://packages.debian.org/fr/sid/clang) qui fonctionne bien. Tâche pas toujours facile, car Clang se base sur les en‐têtes de gcc/g++ et le _runtime_ C++ de g++, et qu’ils ont récemment pas mal changé avec la [multi‐architecture dans Debian](http://wiki.debian.org/Multiarch). Ensuite, avec l’aide de Lucas Nussbaum, j’ai tiré parti du _cloud_ Amazon AWS pour effectuer des reconstructions massives de l’archive Debian avec Clang. La version 3.2 a permis de valider la qualité du compilateur en termes de prise en charge du C et C++. Maintenant, l’essentiel des erreurs de compilation se trouvent dans des erreurs de programmation dans les paquets amonts. Quelques exemples : * [une fonction qui attend un argument mais qui ne retourne rien (`return;`)](http://clang.debian.net/status.php?version=3.2&key=FUNCTION_RETURNS_VALUE) ; * [des arguments invalides acceptés par gcc comme `-O6` ou `-O20`](http://clang.debian.net/status.php?version=3.2&key=WRONG_OPTIM_VAL). Cependant, il est important de préciser que ni les performances du binaire, ni la qualité de celui‐ci ne sont testés. Pour cela, depuis quelques semaines, nous avons une infrastructure autonome de construction de paquets basée sur Clang au lieu de GCC. Ce travail a été réalisé dans le cadre du [_Google Summer of Code 2012_ par Alexander Pashaliyski, qui a pour mentors l’hyperactif Paul Tagliamonte et moi‐même](http://wiki.debian.org/SummerOfCode2012/Projects#clang_support_for_build_services). La méthode est assez bête : vu que `clang` accepte les mêmes arguments que `gcc`, on remplace le binaire `gcc` par `clang` et on lance la compilation du paquet de la même manière que d’habitude. Cette plate‐forme permet aux empaqueteurs Debian et Ubuntu de vérifier que leurs paquets se compilent correctement avec Clang, et les corriger si besoin. J’espère qu’elle sera aussi utile aux développeurs de logiciels intégrés dans Debian, pour les encourager à corriger les problèmes soulevés par ce nouveau compilateur (et ainsi leur prouver que Clang est mature). En parallèle, nous avons publié un dépôt Debian avec bon nombre de paquets compilés avec Clang : ``` deb http://clang.debian.net/repository-2013年04月07日/ unstable-clang main ``` Ce dépôt devrait permettre de tester la qualité des binaires produits. Enfin, j’ai mis en place une [instance Jenkins pour construire automatiquement des _nightly builds_ de la chaîne de compilation LLVM pour Debian et Ubuntu](http://llvm-jenkins.debian.net/). Ces dépôts sont [publiés sur le site officiel de LLVM](http://www.llvm.org/apt/). À plus long terme, j’aimerais pousser l’usage de `/usr/bin/cc` et `/usr/bin/c++`, au lieu de `gcc` et `g++`. Dans de nombreux paquets, l’usage de `gcc` est codé en dur. Malheureusement, même si les retours de la communauté Debian sont dans l’ensemble positifs sur cette initiative, je pense que cet objectif prendra quelques années. Enfin, malgré tout, il restera un gros travail pour certaines architectures prises en charge par Debian mais pas par LLVM. **Que penses‐tu de l’évolution très rapide de LLVM/Clang ? Quels sont les principaux défis pour LLVM/Clang que tu vois pour le futur ?** Je trouve l’évolution de LLVM et Clang assez extraordinaire. Il y a un engouement fort à la fois autour de ce « nouveau » compilateur, mais aussi autour de la plate‐forme qu’est LLVM en tant que tel. Les contributions se font simplement : listes de diffusion très (trop ?) actives et permissions au SVN facilement données. Un des exemples de réussite de la chaîne de compilation LLVM est [_emscripten_](http://fr.wikipedia.org/wiki/emscripten "Définition Wikipédia"). Projet de la fondation Mozilla, il permet de compiler des codes C/C++ en JavaScript. Il utilise [LLVM et Clang pour générer une représentation intermédiaire (IR) qui sera lue en JavaScript](https://linuxfr.org/users/bjacob/journaux/la-strategie-de-mozilla-pour-les-jeux-video-sur-le-web-ouvert). Il y a de nombreux projets autour LLVM qui sont prometteurs, comme [_libc++_](http://libcxx.llvm.org/) (une nouvelle implémentation de la bibliotèque d’exécution C++), [_lldb_](http://lldb.llvm.org/) (un débogueur tirant parti de _libclang_ pour l’analyse de C++), ou encore [_lld_](http://lld.llvm.org/) (éditeur de liens). Quant aux défis, ça n’est un secret pour personne, mais LLVM et Clang sont fortement poussés par des grosses boîtes comme Apple, Google, Intel ou Samsung. Pour leurs produits ou leur utilisation interne, ils utilisent bien souvent des révisions du dépôt _Subversion_. Or, en particulier d’un point de vue distributions, je pense que l’on aura besoin d’aller vers des révisions mineures de la chaîne de compilation LLVM. En effet, pour le moment, seules des versions majeures ([3.1](http://llvm.org/releases/3.1/docs/ReleaseNotes.html), [3.2](http://llvm.org/releases/3.2/docs/ReleaseNotes.html) et maintenant 3.3) sont publiées. Les modifs devant être rétroportées à la main par les empaqueteurs (par exemple, le [paquet `llvm-3.2` de la dernière Ubuntu](https://launchpad.net/ubuntu/+source/llvm-3.2) contient un rétroportage de la prise en charge du R600). J’espère aussi que les contributions resteront fortes. Sans partir dans un débat GPL _vs_ BSD, certains acteurs pourraient être tentés de garder pour eux des évolutions fortes et d’autres de « forker » le logiciel à la manière de WebKit/Blink. Techniquement, j’aimerais voir LLVM/Clang améliorer les performances des binaires produits, pour, dans un premier temps, dépasser GCC, puis se rapprocher des compilateurs Intel, ainsi que [la prise en charge de OpenMP (en cours de développement)](http://www.llvm.org/devmtg/2013-04/bokhanko-bataev-slides.pdf) et de Fortran.

AltStyle によって変換されたページ (->オリジナル) /