Après la nouvelle version de llvm, je me suis dit que ça pourrait être sympa de la tester.
Comme au moment du test, la 2.5 n'était pas dispo sur ma distrib et que clang n'est pas disponible, je passe par l'étape de compilation.
Je tente d'utiliser la 2.5, mais il n'y a pas de version stable de clang, et il faut forcement utiliser la version de dev (subversion).
La compilation se passe bien, je décide de faire un test sur ffmepg.
Et la les problèmes commencent :
le script de build arrive bien a utiliser ccc le frontend clang, il y a juste un mineur soucis avec la génération des dépendances qui n'est pas supporté par clang.
La compilation se passe bien, jusqu'à tomber sur un assert de llvm [1]. Le bug est signalé et corrigé assez vite.
La compilation se poursuit jusqu'à tomber sur un problème de compilation avec l'asm-inline [2]. Le problème est signalé et en attendant sa résolution, je modifie les sources pour le contourner.
Ça y est, j'ai réussi a compiler ffmpeg avec llvm/clang. Je lance les tests de régression. Et un test échoue lamentablement. Après analyse le code est mal compilé [3].
Je me dis que j'ai peut être été trop ambitieux de vouloir tester clang, donc je teste llvm-gcc. Je le compile pour être sur la même base que clang.
Et a la compilation de ffmpeg, llvm-gcc crash [4].
Je reviens à [3] et je constate que le bug n'apparait pas en -O0, je décide de compiler ffmpeg en -O0 (en plus ça me permettra d'avoir les symboles de debug, chose que llvm ne sait pas faire en -Ox [5]).
Mais en -O0 tout le code ne compile pas [6].
En désactivant les optimisations assembleur j'arrive enfin à compiler un ffmpeg (lent) qui passe les tests de régression...
Le tout, plus le fait que llvm ne suit pas forcement l'ABI linux [7], m'a vraiment déçu.
Je pensais que llvm était dans une version bien plus avancée et stable.
[1] http://llvm.org/bugs/show_bug.cgi?id=3759
[2] http://llvm.org/bugs/show_bug.cgi?id=3788
[3] http://llvm.org/bugs/show_bug.cgi?id=3789
[4] http://llvm.org/bugs/show_bug.cgi?id=3787
[5] http://llvm.org/bugs/show_bug.cgi?id=1710
[6] http://llvm.org/bugs/show_bug.cgi?id=3800
[7] http://llvm.org/bugs/show_bug.cgi?id=3731
http://llvm.org/bugs/show_bug.cgi?id=783
http://llvm.org/bugs/show_bug.cgi?id=2823
http://llvm.org/bugs/show_bug.cgi?id=2390
# Options de compilation
Posté par Bactisme (site web personnel) . Évalué à -10.
Ne ratez pas le prochain numéro avec la page man de /etc/motd
[^] # Re: Options de compilation
Posté par sanao . Évalué à 10.
# ffmpeg
Posté par patrick_g (site web personnel) . Évalué à 10.
Tu a essayé de compiler un autre truc ?
En tout cas super journal, bien intéressant et bravo pour les rapports de bug.
[^] # Re: ffmpeg
Posté par thedidouille . Évalué à 2.
[^] # Re: ffmpeg
Posté par IsNotGood . Évalué à 0.
http://linuxfr.org/2009/03/04/25108.html
Du côté du projet Clang qui est destiné à remplacer GCC dans les futures versions
[^] # Re: ffmpeg
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
LLVM utilise actuellement GCC. Clang est destiné à remplacer GCC pour l'utilisation de LLVM
[^] # Re: ffmpeg
Posté par IsNotGood . Évalué à 1.
Certes, un comparatif *aujourd'hui* sera en faveur de gcc.
Pour en revenir à la dépêche, elle est clairement llvm vs gcc. Je t'invite à la relire. Les modérateurs auraient fait une boulette ?
> Clang est destiné à remplacer GCC pour l'utilisation de LLVM
Oui. Mais llvm+clang se veut un "remplaçant" de gcc. Plus précisément, une alternative. Matthieu C a tenté d'évaluer cette alternative.
[^] # Re: ffmpeg
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
Et plus loin dans les détails ca dit Du côté du projet Clang qui est destiné à remplacer GCC dans les futures versions, il y a aussi du nouveau, sous entendu remplacer GCC dans les futures versions de LLVM.
En ce qui concerne ce journal, oui c'est une alternative et c'est intéressant de savoir ce qu'il est possible de faire avec aujourd'hui, mais le but de LLVM n'est pas de reeccrire GCC pour avoir un remplaçant qui sache compiler ce que GCC sait actuellement compiler. Dans ce sens il n'est pas destiné à remplacer GCC. Je pense que le nouveau pcc par contre a plus cet objectif.
[^] # Re: ffmpeg
Posté par IsNotGood . Évalué à 3.
Je n'ai pas dit qu'il était destiné à remplacer GCC ou que c'était son objectif.
C'est un peu léger de réfuter toute critique de llvm+clang en disant que ce n'est pas un remplaçant de gcc ni que c'est son objectif. Ils proposent les mêmes fonctionnalités, donc on les compare.
> Je pense que le nouveau pcc par contre a plus cet objectif.
Pour BSD.
[^] # Re: ffmpeg
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
Heu je viens de relire, et c'est toujours ce que je lis pourtant...
[^] # Re: ffmpeg
Posté par Patrick Lamaizière (site web personnel) . Évalué à 1.
> Pour BSD.
FreeBSD semble s'orienter vers LLVM pour le système, il y a des travaux en cours (la raison c'est que la GPLv3 de gcc c'est *MAL*).
http://wiki.freebsd.org/BuildingFreeBSDWithClang
les pixels au peuple !
[^] # Re: ffmpeg
Posté par beagf (site web personnel) . Évalué à 5.
L'objectif de clang++llvm me semble quand même de faire un compilateur C et dérivés au moins aussi bon que gcc et même meilleur grâce à toutes les possibilités offertes par llvm.
Par contre, l'objectif, et c'est relativement clair dans les propos des dévellopeurs, n'est pas de faire un remplacant direct de gcc, dans le sens un compilateur qui accepte les mêmes sources et donne les même binnaires.
Un programme écrit en respectant les standards devrait être accepté par les deux sans problèmes, mais tout ce qui touche aux extentions des standards ne sera pas forcément géré de la même manière.
Les extentions spécifiques à gcc ne seront pas forcément gérées de la même manière.
L'objectif de clang est quand même de faire un compilateur propre en partant sur des bases saines. Dans ce cadre, il y a des choses relativement dégueulasse faites par gcc qui ne peuvent pas être supportées.
Donc ici, il faut clairement prendre "remplacant" comme "alternative", c'est-à-dire un compilateur aussi bon (voir meilleur) mais pas forcément compatible à 100% si tu utilise des trucs spécifiques à gcc. Tout comme gcc est une alternative à icc ou visual-c mais pas 100% compatible.
Pour ce qui est de la non-compatibilité avec l'ABI de linux, si j'ai bien compris elle n'est que temporaire. Une grosse partie du dévellopement ce fait sous darwin qui n'a pas la même ABI d'ou cette incompatibilité, mais à terme les deux devrait être supportées.
[^] # Re: ffmpeg
Posté par M . Évalué à 3.
C'etait le but : tester avec quelque chose de different que le hello word ou un mini bench
De plus si tu regarde le testcase du bug [3], tu veras que c'est du C99 parfaitement valide. Sans aucune extension gcc. D'ailleurs a ce niveau ffmpeg est assez portable dans le fait que le script de configure délecte se que supporte le compilo, et n'activera l'asm inline que si celui-ci est supporté.
Tu a essayé de compiler un autre truc ?
Le noyau Linux, mais je suis pas allé très loin.
Mais bon il faut croire que ca marche chez des gens : http://wiki.freebsd.org/BuildingFreeBSDWithClang
[3] http://llvm.org/bugs/show_bug.cgi?id=3789
# Pluribus pluralum est.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -3.
Ben, LLVM, ça doit tourer soit linux, *bsd, beos, windows, cygwin, et autres que j'oublie non ?
Si tel est le cas, alors "heureusement" que ça ne suit pas l'ABI linux, tu crois pas ?
En tout cas ça a l'air fun…
[^] # Re: Pluribus pluralum est.
Posté par beagf (site web personnel) . Évalué à 9.
La seule chose c'est que pour l'instant c'est l'ABI de darwin la mieux supportée car le dévellopement est fait principalement sur ce système.
[^] # Re: Pluribus pluralum est.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
J'avais mal compris, je pensais à API, donc oui, effectivement, c'est pas top si ça colle pas.
Forcément, si fallait une API différente par hôte, ça rendait le truc con, et je comprenais vraiment pas le problème.
Maintenant, l'ABI du noyau linux varie-t-elle beaucoup ?
J'imagine alors que chaque version de LLVM est compatible avec certains noyaux uniquement non ?
Enfin, le programmeur qui compile vers LLVM, il s'en fiche de l'ABI non ? Ou alors ça veut dire que si elle est pas complète pour tel ou tel hote, il va falloir compiler le code vers LLVM sans utiliser les parties "cassées" de la VM ? Par exemple (fictif), si l'additionneur ternaire est pas implanté, compiler en (+ a (+ b c)) au lieu de (+ a b c) ? Ou alors tout simplement ça sera émulé d'une manière ou d'une autre ?
(euh, je me suis pris gros en moinssage pour ma question du message précédent, je pige pas trop là.)
[^] # Re: Pluribus pluralum est.
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
# Petit commentaire
Posté par Olorim . Évalué à 1.
Sans rentrer dans les détail, juste une petite phrase pour dire aux incultes comme moi ce qu'est cet outil...
[^] # Re: Petit commentaire
Posté par JoeltheLion (site web personnel) . Évalué à 6.
[^] # Re: Petit commentaire
Posté par Xavier Teyssier (site web personnel) . Évalué à 3.
Alors en cliquant sur ce journal, je m'attendais à lire un journal parlant de LVM (Logical Volume Manager), et pas du tout à un compilo. Et pendant les premières lignes, j'avais vraiment du mal à faire le lien entre LVM et les tests de Matthieu C.
Donc oui, quand on parle d'une appli non triviale, trois/quatre mots de rappel serait un plus agréable.
[^] # Re: Petit commentaire
Posté par allcolor (site web personnel) . Évalué à 7.
Alors en cliquant sur ce journal, je m'attendais à lire un journal parlant de LVM
Donc tu reproches au rédacteur du journal ta myopies ? Il est écrit LLVM.
===>[-0]
# A tester aussi, l'interpreteur compilateur JIT lli
Posté par Olivier Grisel (site web personnel) . Évalué à 1.
% llvm-gcc --emit-llvm-bc -c -o mon_programme.bc mon_programme.c
% lli mon_programme.bc
ou si tu as des dépendances chargées dynamiquement :
% lli --load=/chemin/vers/mes/libs.so mon_programme.bc
En 2.4, j'ai observé des segmentation faults sur un programme compilé avec llvm-gcc en code natif que je ne reproduisais ni avec le vrai gcc, ni avec la version bitcode interpretée par lli (valgrind n'a pas vu l'erreur non plus). J'ai pas eu le courage de compiler la version 2.5 pour voir si c'etait toujours le cas.
# Un autre test : Blender
Posté par auve . Évalué à 3.
Le mail à l'origine : http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-March/004610(...)
Les résultats : http://t1.minormatter.com/~ddunbar/blender/times.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.