LLVM 3.2 et Clang 3.2 publiés

Posté par yogitetradim (site web personnel) le 28 décembre 2012 à 09:19. Édité par Sylvestre Ledru, rewind, Nÿco, tuiu pol, claudex, Bruno Michel, Pierre Jarillon et NeoX. Modéré par tuiu pol. Licence CC By‑SA.

Étiquettes :

déc.

2012

LLVM (à l'origine Low Level Virtual Machine) est une machine virtuelle principalement destinée à la mise au point des langages informatiques.
Clang est un compilateur basé sur LLVM. Il vise à compiler à la fois le C, C++ et Objective-C. Signe de son actuelle maturité, il devrait être le compilateur C par défaut de FreeBSD 10

Sept mois après la dernière mouture, la suite LLVM sort dans sa version 3.2.

Au programme de nombreuses corrections de bugs et améliorations dans l'optimisation du code, notamment avec une meilleure prise en charge des nouveaux jeux d'instructions , une meilleure vectorisation et enfin, une modification du back-end avec le compilateur Nvidia.

NdM : Merci à Nÿco, Pierre Jarillon, Sylvestre Ledru, Bruno Michel et rewind pour leur participation à la rédaction de cette dépêche.

LLVM

Vectorisation

Une nouvelle vectorisation des boucles a été mise en place. La vectorisation consiste à utiliser des instructions avancées, type MMX ou SSE, qui agissent sur des ensembles de valeurs plutôt qu'une seule valeur à la fois. LLVM disposait déjà d'une vectorisation au niveau des blocs de base, c'est-à-dire que des instructions vectorielles viennent remplacer des ensembles d'instructions localement.

Avec la vectorisation des boucles, il s'agit d'identifier des boucles dont les opérations peuvent être faites en parallèle grâce à des instructions vectorielles. Les premiers benchmarks montrent une accélération entre 2 et 3 fois par rapport à un code normal.

Nouveau backend PTX

Parallel Thread eXecution (PTX) est un langage assembleur créé par NVidia pour CUDA. Il sert d'intermédiaire entre le programme CUDA (un dérivé de C) et le code binaire qui est utilisé par la carte graphique. Le programme nvcc transforme le code CUDA en assembleur PTX puis le pilote de la carte compile l'assembleur PTX en code binaire.

LLVM permet de générer de l'assembleur PTX. C'est NVidia qui a développé cette partie après avoir fait le choix de LLVM pour leur chaîne de compilation. Ce nouveau backend vient remplacer l'ancien qui était expérimental.

Amélioration de la génération de code

L'ensemble d'instructions vectorielles AVX2 a été amélioré pour les architectures x86 et amd64.
Un assembleur complet pour ARM est maintenant complètement intégré à LLVM.
La génération de code pour les architectures MIPS et PowerPC a été grandement améliorée.

En vrac

La documentation de LLVM est maintenant gérée à l'aide de Sphinx.

Clang

Amélioration des diagnostics

-Wuninitialized

Avec la fonction suivante,

int f(int b) {
  int n;
  if (b)
    n = 1;
  return n;
}

L'utilisation de Clang avec l'argument -Wuninitialized produira les messages d'erreur suivants :

$ clang -c -Wuninitialized foo.c
foo.c:3:7: warning: variable 'n' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (b)
    ^
foo.c:5:10: note: uninitialized use occurs here
return n;
     ^
foo.c:3:3: note: remove the 'if' if its condition is always true
if (b)
^~~~~~
foo.c:2:8: note: initialize the variable 'n' to silence this warning
int n;
     ^
= 0
1 warning generated.

Attribut `tls_model`

Le nouvel attribut tls_model permet de spécifier le modèle mémoire utilisé pour les variables locales à un thread (_Thread-Local Storage_). Cet attribut est spécifique à Clang mais peut être utile pour ceux qui ont des besoins très précis.

Attribut pour la sûreté des types

Certaines API permettent de passer des données à l'aide d'un pointeur générique void*, tout en précisant le type de données à l'aide d'un paramètre. C'est par exemple le cas pour l'API MPI qui dispose d'un type MPI_Datatype pour spécifier le type au bout du pointeur.

LLVM permet désormais de pouvoir vérifier si le pointeur passé en paramètre est du bon type par rapport au paramètre de typage. Pour cela, un ensemble d'attributs permet d'identifier quel paramètre est le pointeur et quel paramètre est le type.

Les paramètres des fonctions fcntl() et ioctl() sont également gérés de la même manière.

Gestion des commentaires de documentation

Clang permet maintenant, grâce à l'option -Wdocumentation, de gérer les commentaires de documentation (au format Doxygen) et de s'assurer de leur cohérence avec le code. Voir le compte-rendu de la présentation faite à la Rencontre des développeurs LLVM 2012 à ce sujet.

Prise en charge de C11 et C++11

Clang gère maintenant le mot-clef _Alignof introduit dans C11. La prise en charge de C++11 est, quant à elle, presque complète, elle s'est vue ajouter la déclaration avancée (_forward declaration_) des enum.

Debian

LLVM et Clang 3.2 sont aussi déjà disponibles dans Debian.

Aller plus loin

Note de publication de LLVM 3.2 (137 clics)
Les présentations de la LLVM compilers meeting (57 clics)
Note de publication de Clang 3.2 (89 clics)

# cohérence commentaire/code

Posté par Oliver (site web personnel) le 28 décembre 2012 à 20:13. Évalué à 3.

Rien que pour vérifier la cohérence entre les commentaires doxygene et le code source, je ferai bien une passe de compilation avec LLVM/Clang.

Est-ce quelqu'un a déjà testé cette fonctionnalité ? des retours d'expériences ?
Sinon, il y aurait il un autre moyen pour réaliser cette vérification ?

Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
- [^] # Re: cohérence commentaire/code
  
  Posté par rewind (Mastodon) le 28 décembre 2012 à 22:49. Évalué à 3.
  
  Tu peux regarder les slides (mis en lien dans la nouvelle) qui donne une bonne idée des fonctionnalités. Mais sinon, doxygen peut émettre des warning, je crois, s'il n'y a pas de cohérence entre le code et les commentaires.
# Clang vs GCC

Posté par ariasuni le 29 décembre 2012 à 00:30. Évalué à 3.

Je vois que clang a l'air très bien, et même génial pour détecter certaines erreurs. En plus son développement a l'air très actif. Que vaut-il par rapport à GCC? Parce les erreurs incompréhensibles ça lui connaît.

Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Clang vs GCC
  
  Posté par rewind (Mastodon) le 29 décembre 2012 à 12:44. Évalué à 4.
  
  Je pense que GCC est encore devant au niveau de la qualité du code produit, grâce à de meilleurs optimisations. Mais Clang progresse très vite, parce qu'il a une architecture qui lui permet d'évoluer bien mieux que GCC. Sans même parler de Polly qui est encore expérimental mais qui permettra d'avoir du meilleur code.
  
  Maintenant, dans une utilisation quotidienne, je pense que Clang est bien meilleur que GCC. Le pouième gagné sur le code produit ne vaut pas la qualité des messages d'erreur de Clang (notamment pour les templates).
  - [^] # Re: Clang vs GCC
    
    Posté par Zenitram (site web personnel) le 29 décembre 2012 à 16:32. Évalué à 8. Dernière modification le 29 décembre 2012 à 16:33.
    
    Donc, si je comprend bien, on débuggue avec Clang (messages, vitesse de compilation) et on release avec GCC (qualité globale du code produit en taille/perfs)?
    - [^] # Re: Clang vs GCC
      
      Posté par rewind (Mastodon) le 29 décembre 2012 à 16:55. Évalué à 6.
      
      Tu peux releaser avec Clang aussi, il apporte pas mal de souplesse, notamment pour la cross-compilation. Et la perte en vitesse est tellement négligeable que ça ne change pas grand chose (sauf pour des besoins très particuliers).
      
      De toute façon, compiler avec les deux, si on peut, est toujours une bonne chose, simplement parce qu'ils ont des extensions qui peuvent être différentes et qu'il faut y prendre garde si on veut avoir un code le plus portable possible.
      - [^] # Re: Clang vs GCC
        
        Posté par freem le 29 décembre 2012 à 18:21. Évalué à 4. Dernière modification le 29 décembre 2012 à 18:23.
        
        si on veut avoir un code le plus portable possible.
        
        Pourquoi, il n'y a pas de flag pour virer les extensions avec clang? Gcc en a, et je m'en sers systématiquement, personnellement.
        
        Un autre avantage de clang sur GCC, c'est la consommation de ressources drastiquement inférieure lors de la compilation.
        C'est bien simple, sur mon 1015 pem, dual core, 2 thread par coeur, 1Go de ram, compiler avec Code::Blocks (enfin, c'est l'IDE qui lance la compilation, mais je précise, peut-être que ça peut avoir un impact) l'un des projets libres sur lesquels je travaille, qui galère dur sur le fichier "principal" qui implémente la fenêtre de l'application:
        
        avec GCC si je me limite pas à 2 processus pour compiler, je sature la mémoire, donc ça swap dur, pendant de longues minutes. Avec 2 processus seulement, le processeur n'est exploité qu'a moitié.
        
        avec clang, 4 processus, ça passe, sans swapper.
        
        Génération des binaires, avec les mêmes options de compilations (débug, pas d'optimisation):
        
        g++ 2 processus : 3 minutes, 35 secondes (tiens, je perdais 5 secondes, bon à savoir… ou pas)
        
        g++ 3 processus : 3 minutes, 30 secondes
        
        g++ 4 processus : 4 minutes, 48 secondes
        
        clang++ 3 processus : 2 minutes, 40 secondes
        
        clang++ 4 processus : 2 minutes, 35 secondes
        
        La différence n'est pas énorme: clang prends juste 73,8% du temps de compilation de g++, différence sûrement due à la saturation de la ram. J'ai la flemme de faire les mêmes mesures sur ma tour qui a plus de mémoire, d'autant que le processeur n'a que 2 coeurs et 1 thread par coeur, donc la comparaison me semble un peu ridicule.
        
        Notes:
        
        le PC est nettement plus lent après compilation avec G++, chose qui n'est pas prise en compte par les temps annoncés, parce que pas mesurable précisément. L'explication: faut tout sortir de la swap, même avec 2 processus !
        
        j'ai, avec clang, l'avertissement suivant supplémentaire: "argument inutilisé -pg" (bon, ok, j'ai traduit) mais je doute qu'il justifie la différence de temps totale.
        
        Après, pour le binaire final, vu que je suis en pleine phase de développement, je n'ai jamais testé. De toute façon, j'ai comme un doute que ça joue énormément sur un programme classique.
        
        Je suis passé à clang il y a 1-2 semaines, avant, je pensais à booster ma ram à 2Go, depuis j'ai oublié pourquoi je voulais le faire :D
        C'est simple, en fait, avec clang, on peut travailler confortablement sans avoir de machine surpuissante. C'est important, pour qui ait adopté le développement comme occupation principale plus que l'électronique parce que ça coûte nettement moins cher.
        
        Clang, c'est le compilateur C* qui sera majoritairement utilisé sur les systèmes non microsoft (parce que les utilisateurs de MS, j'ai l'impression (erronée ?) qu'ils ne cherchent pas plus loin que le bout de leur nez quand ils veulent dev: MS VS only, malgré la lourdeur du bouzin) dans un future proche, pour moi, grâce à ses performances impressionnantes et ses fonctionnalités. Les messages d'erreur sont aussi nettement moins illisibles, depuis.
        
        [^] # Re: Clang vs GCC
        
        Posté par rewind (Mastodon) le 29 décembre 2012 à 20:48. Évalué à 5.
        
        Pourquoi, il n'y a pas de flag pour virer les extensions avec clang? Gcc en a, et je m'en sers systématiquement, personnellement.
        
        Si, ce sont les mêmes flags pour gcc et Clang (-std=c++11 et hop !). Clang essaie d'avoir les mêmes options que gcc quand c'est possible, pour faciliter la compatibilité des builds.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 11 janvier 2013 à 23:00. Évalué à 0.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Clang vs GCC
        
        Posté par ariasuni le 12 janvier 2013 à 10:38. Évalué à 3.
        
        x *= 0,75;
        
        Pourquoi c'est faux? Ça devrait être un point à la place de la virgule? Ça cause quoi comme problème(s)?
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 13 janvier 2013 à 01:34. Évalué à 1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Clang vs GCC
        
        Posté par Benoît Sibaud (site web personnel) le 12 janvier 2013 à 12:33. Évalué à 2.
        
        Test avec g++ 4.6.3
        
        #include <iostream> int main() { float x = 1.0; x *= 0,75; std::cout << x << std::endl; }
        $ g++ -o virgule virgule.cpp && ./virgule 0 $ g++ -Wall -o virgule virgule.cpp && ./virgule virgule.cpp: In function ‘int main()’: virgule.cpp:4:12: attention : right operand of comma operator has no effect [-Wunused-value] 0 $ g++ -Wunused-value -o virgule virgule.cpp && ./virgule virgule.cpp: In function ‘int main()’: virgule.cpp:4:12: attention : right operand of comma operator has no effect [-Wunused-value] 0
        
        Remplaçons la ligne par :
        
        x *= 0,x=75;
        $ g++ -Wall -o virgule virgule.cpp && ./virgule 75
        
        Et c'est aussi valable en C :
        
        #include "stdio.h" int main() { float x = 1.0; x *= 0,x=75; printf("%f\n",x); }
        $ gcc -Wall -o virgule virgule.cpp && ./virgule 75.000000
        
        [^] # Re: Clang vs GCC
        
        Posté par ariasuni le 12 janvier 2013 à 23:07. Évalué à 1.
        
        Euh c'est pas débile de faire
        
        x *= 0,x=75;
        
        ?
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Clang vs GCC
        
        Posté par Benoît Sibaud (site web personnel) le 13 janvier 2013 à 15:35. Évalué à 2.
        
        Je ne dirais pas débile ici : je voulais juste rappeler que la virgule peut être utilisée en C/C++ pour séparer des opérations. J'aurais pu mettre y= à la place du second x=, mais là on voit en plus l'ordre d'affection (d'abord x à 0, puis x à 75). Après, dans la vraie vie, ça ne servirait à rien d'affecter deux fois de suite.
        
        [^] # Re: Clang vs GCC
        
        Posté par ariasuni le 13 janvier 2013 à 16:19. Évalué à 1.
        
        Ok, c'était pour être sûr d'avoir bien compris le propos (en effet quand on voit quelque chose qui a l'air stupide, on se dit qu'on a mal compris l'intérêt de la chose).
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 13 janvier 2013 à 01:38. Évalué à 0.
        
        Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Clang vs GCC
  
  Posté par groumly le 29 décembre 2012 à 21:34. Évalué à 8.
  
  Gcc est parti aux abimes pour moi le jour ou apple l'a deprecie et mit clang par defaut ya a peu pres 18 mois.
  
  Comme ont dit les autres, et pour rajouter:
  - vitesse de compilation (sur des gros projets, ca aide, surtout avec cocoapods qui force un peu a rebuilder les dependences en permanence)
  - precision des messages d'erreur
  - analyse statique. Xcode/Instruments en sont a un point ou ils peuvent trouver les cycles de retain count et suggerer ou les casser, et il me semble que ARC est tres dependant de l'analyzeur pour savoir ou mettre les retain/release/autorelease
  - sur le support objc, gcc est tellement loin derriere que c'est meme plus drole
  - De meme, xcode suggere maintenant des solutions aux erreurs de compilations, il me semble que c'est grace a clang.
  
  Du cote du mauvais:
  - le code genere est certes plus lent, pas sur que ca se ressente a l'utilisation
  - leur generateur de code arm6 etait bugge jusqu'a la moelle, j'ai eu le droit a des binaires malforme (donc qui ne peuvent meme pas se lancer), un mauvais acces a des membres de structs en -O2 (i.e. var.width accedait en fait a var.height. Je deconne pas, bon courage pour debugger ca, et le corriger) et un dernier du meme tonneau, mais ma memoire me fait defaut.
  A noter que ces bugs etaient tous pour l'armv6, armv7 n'etait pas affecte et cette plateforme etait mourrante a cette epoque (mais toujours vivotante, ce qui ne rend pas les bugs acceptables).
  - lldb a suivi le chemin de flash: prochaine release, promit, ca marchera bien! Au final, ca marchotte mais xcode est toujours pas foutu de lister le contenu d'un tableau dans l'inspector alors qu'il le fait avec gdb, et on s'est tape un an de xcode avec un lldb inutilisable par defaut.
  
  Apres, le monde objective-c est un peu different, gcc n'en a vait rien a faire de ce langage et donc il a toujours ete a la ramasse, loin derriere, mais quand meme, je retourne pas en arriere, meme pour deux barils de gcc.
  
  Linuxfr, le portail francais du logiciel libre et du neo nazisme.
  - [^] # Re: Clang vs GCC
    
    Posté par ariasuni le 29 décembre 2012 à 23:57. Évalué à 1.
    
    Ah ça a l'air cool, j'essaierais dès que possible… Et pour ce qui est du support de C++11 par exemple, ils en a un qui est plus en avance que l'autre? Sinon pour la qualité du binaire produit j'imagine que ça va s'améliorer avec le temps!
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Clang vs GCC
      
      Posté par groumly le 30 décembre 2012 à 22:31. Évalué à 1.
      
      Aucune idee pour le c++, je reste aussi loin que possible de ce langage :)
      Apple se vantait d'un bon support c++ a wwdc 2011, donc j'ai envie de dire que c'est supporte, au moins partiellement, mais ca reste une conf apple (ils pretendaient aussi que lldb roxait des mamans ours a la meme conf, donc bon…), je verifierais sur le site de llvm.
      A noter que xcode vient avec clang 4, pas 3, donc voire si tu peux chopper leur version de clang qui est visiblement plus recente. Ou potentiellement, apple change la version de clang juste pour coller a celle de xcode aussi, et c'est juste clang 3.2.
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Clang vs GCC
        
        Posté par rewind (Mastodon) le 31 décembre 2012 à 11:26. Évalué à 3.
        
        La version Apple de Clang est exactement la même que la version publique, modulo l'intégration dans XCode.
        
        [^] # Re: Clang vs GCC
        
        Posté par Sylvestre Ledru (site web personnel) le 05 janvier 2013 à 07:40. Évalué à 1.
        
        Peux tu préciser tes sources ? C'est pas les infos que j'avais entendu… (révision SVN de la version Apple non existante dans le SVN publique).
        
        [^] # Re: Clang vs GCC
        
        Posté par rewind (Mastodon) le 05 janvier 2013 à 10:18. Évalué à 2.
        
        Je ne la retrouve pas :(
        
        Je ne sais plus exactement où je l'avais lu, mais je me souviens de l'avoir lu. J'ai fait quelques recherches mais impossible de remettre la main dessus. D'un autre côté, étant donné le nombre de contributeurs externes, ça serait con d'avoir des fonctionnalités spécifiques à Apple.
        
        [^] # Re: Clang vs GCC
        
        Posté par Sylvestre Ledru (site web personnel) le 06 janvier 2013 à 07:56. Évalué à 1.
        
        Je vois pas trop en quoi ça serait "con" de la part de Apple ?!
        Patcher LLVM/Clang pour améliorer les performances ou l'intégration dans Mac OS X ou IOS, ça pourrait avoir du sens.
        
        [^] # Re: Clang vs GCC
        
        Posté par rewind (Mastodon) le 06 janvier 2013 à 14:11. Évalué à 7.
        
        Je n'y crois pas pour plusieurs raisons : à la base, Clang n'est pas un projet Apple, et il fonctionne encore beaucoup en dehors d'Apple (les listes par exemple sont encore hébergé à l'université d'origine de l'auteur de Clang), Apple n'a aucun intérêt à cacher des fonctionnalités au risque de perdre la confiance des contributeurs externes dont certains ont énormément d'intérêts dans Clang (ARM notamment, Google aussi) et pour un projet sous une licence permissive, cette confiance est d'autant plus difficile à obtenir qu'il ne faut aucun écart de conduite.
        
        De toute façon, de fait, le support pour Mac OS X ou iOS est souvent meilleur que pour les autres systèmes. Mais ce n'est absolument pas caché.
        
        [^] # Re: Clang vs GCC
        
        Posté par ariasuni le 06 janvier 2013 à 20:51. Évalué à 1.
        
        De toute façon, de fait, le support pour Mac OS X ou iOS est souvent meilleur que pour les autres systèmes. Mais ce n'est absolument pas caché.
        
        En quoi? (vraie question)
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Clang vs GCC
        
        Posté par rewind (Mastodon) le 07 janvier 2013 à 19:18. Évalué à 2.
        
        Généralement, les fonctionnalités un peu poussées sont d'abord prêtes pour Mac OS X avant Linux ou pire, Windows. Je n'ai pas d'exemple en tête mais je pourrais t'en retrouver. La différence n'est pas très sensible dans une utilisation quotidienne, voire pas sensible du tout.
        
        [^] # Re: Clang vs GCC
        
        Posté par lasher le 06 janvier 2013 à 21:26. Évalué à 5.
        
        J'ai pertinenté, mais il ne faut pas oublier que le projet LLVM refuse les contributions brevetées. Si pour une raison ou une autre Apple a des modifs à faire qu'ils estiment dignes d'être brevetées, alors ils auront des modules non-inclus dans la distribution officielle de LLVM.
    - [^] # Re: Clang vs GCC
      
      Posté par G.bleu (site web personnel) le 03 janvier 2013 à 19:32. Évalué à 1.
      
      Pour le C++11… ben j'ai pas réussit à compiler !
      
      En gros clang 3.1 tente de compiler avec la libc++ de gcc 4.5 mais la compatibilité ne se fait pas et je me retrouve avec une pelleté d'erreurs dans la stl !
      
      J'ai trouvé quelques rapports de bug à ce propos, va falloir attendre la prochaine version…
  - [^] # Re: Clang vs GCC
    
    Posté par Sytoka Modon (site web personnel) le 07 janvier 2013 à 10:51. Évalué à 3.
    
    Apres, le monde objective-c est un peu different, gcc n'en a vait rien a faire de ce langage
    
    Enfin, le support de Fortran et d'Ada dans Clang est proche de zéro. Vive la diversité ;-)
    - [^] # Re: Clang vs GCC
      
      Posté par Gof (site web personnel) le 08 janvier 2013 à 00:59. Évalué à 6.
      
      Clang est un frontend a LLVM pour compiler la famille des langages dérivés du C.
      
      Si tu veux compiler du fortran ou du ADA avec LLVM, il faut utiliser un autre frontend, comme par exemple dragonegg (qui utilise GCC comme frontend)
      
      Faire un frontend fortran utilisant uniquement l'architecture de LLVM ne doit pas être si difficile à faire. Mais il n'y aurais sans doute pas beaucoup de partage de code entre Clang et un frontend ADA ou Fortran car ses langages sont différents.
      
      Bref, ce que je veux dire est que ce n'est pas la vocation de clang de comprendre des langage non dérivés de C.
# Je vais tester Clang

Posté par woprandi le 30 décembre 2012 à 01:06. Évalué à -4. Dernière modification le 30 décembre 2012 à 01:08.

J'avoue détester le c++ notamment à cause des messages complètement incompréhensible de gcc qui faisait que je mettais 10 ans à corriger l'erreur, parfois presque au hasard, ce qui m'a rendu allergique à ce langage. Peut-être qu'avec clang ça sera mieux…
Ou alors c'est juste le langage qui pue….
==> []
- [^] # Re: Je vais tester Clang
  
  Posté par SauronDeMordor (site web personnel) le 30 décembre 2012 à 22:15. Évalué à 4.
  
  les 2 :p
  - [^] # Re: Je vais tester Clang
    
    Posté par ariasuni le 30 décembre 2012 à 23:39. Évalué à 2.
    
    Bah en Java™ j'arrive à avoir le même genre d'erreurs débiles qu'en C++ (instruction de récupération de saisie au clavier ignorée pour une raison obscure).
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Je vais tester Clang
      
      Posté par tyoup le 07 janvier 2013 à 12:37. Évalué à 3.
      
      Le truc c'est pas d'arriver à les avoir, mais d'arriver à ne pas les avoir :-)
      - [^] # Re: Je vais tester Clang
        
        Posté par ariasuni le 07 janvier 2013 à 13:47. Évalué à 3.
        
        Oui, après 2 longues heures et un bon mal de tête.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Je vais tester Clang
        
        Posté par tyoup le 07 janvier 2013 à 15:51. Évalué à 1.
        
        Tout à fait ! C'est une sorte d'exploit…