Discussion :

[Hinault Romaric]

LLVM 3.2 disponible avec Clang
la suite d�outils de compilation pour C, C++ et Objective C am�liore l�optimisation du code et le support de C11 et C++11

Les d�veloppeurs de LLVM viennent d�annoncer la sortie de la version 3.2 de la machine virtuelle � destination des langages de programmation, qui apporte un nombre important de nouvelles fonctionnalit�s et des am�liorations de l�optimisation du code et des performances.

LLVM 3.2 int�gre le compilateur Clang 3.2 pour les langages C, C++ et Objective C, la librairie compiler-rt, le � low-level debugger LLDB �, la librairie C++ libc++ et la JVM VMKit qui utilise LLVM pour la compilation statique et JIT (Just In Time).

Cette mouture apporte une nouvelle vectorisation des boucles, qui utilise des instructions avanc�es qui agissent sur des ensembles de valeurs plut�t qu�une seule valeur � la fois.

Un nouveau backend NVPTX vient remplacer le backend PTX (Parallel Thread eXecution) existant. D�velopp� par Nvidia, NVPTX est bas� sur CUDA et sur le compilateur OpenCL. Il sert d�interm�diaire entre le programme CUDA et le code binaire utilis� par la carte graphique.

Le compilateur Clang b�n�ficie d�une meilleure prise en charge de la norme C11 et C++11, des am�liorations des fonctions de diagnostics, de gestion des commentaires et de la s�curit� des types sous forme d�un attribut. Il introduit �galement le support de l�attribut tls_model, qui permet de sp�cifier le mod�le m�moire utilis� pour les variables locales � un thread (_Thread-Local Storage_).

LLVM 3.2 dispose �galement du plugin DragonEgg GCC qui permet de charger des plugins et de prendre en charge les mod�les de stockage en local. DragonEgg n�a d�sormais plus besoin de GCC pour �tre compil� avec le support LTO.

Le code source de LLVM 3.2 est t�l�chargeable sous une licence open source sur le site du projet.

T�l�charger LLVM 3.2


Source : Notes de version


Et vous ?

Que pensez-vous de ces am�liorations ?

[Freem]

Si � low-level debugger LLDB � est int�gr�, cela veut dire qu'on pourra utiliser autre chose que GDB pour d�boguer dans quelques temps?

Ce serait pas mal, parce que je dois reconna�tre avoir plus d'un probl�me avec GDB, et quand on voit la diff�rence entre clang et g++, je suis assez impatient de voir ce que donnerait un d�bogueur fait par les m�mes que clang: je suis pass� � clang r�cemment, et je ne pense m�me plus � pousser la ram de mon netbook au del� de 1Go, avant, je devais compiler mon projet avec 2 processus pour �viter de ramer comme un porc pendant 5 � 10 minutes, maintenant, 4 processus passent, et je peux utiliser les 4 threads de mon processeur ! J'aime beaucoup.

D'ailleurs, quelqu'un conna�t un frontend style cgdb, ddd ou autre pour ce fameux d�bogueur?

Vivement que �a sorte dans Debian (unstable, bien s�r, pour la stable, faut attendre 2 ans minimum ^^ ), cette version 3.2 ...

[PsychoH13]

Si � low-level debugger LLDB � est int�gr�, cela veut dire qu'on pourra utiliser autre chose que GDB pour d�boguer dans quelques temps?

Ce serait pas mal, parce que je dois reconna�tre avoir plus d'un probl�me avec GDB, et quand on voit la diff�rence entre clang et g++, je suis assez impatient de voir ce que donnerait un d�bogueur fait par les m�mes que clang: je suis pass� � clang r�cemment, et je ne pense m�me plus � pousser la ram de mon netbook au del� de 1Go, avant, je devais compiler mon projet avec 2 processus pour �viter de ramer comme un porc pendant 5 � 10 minutes, maintenant, 4 processus passent, et je peux utiliser les 4 threads de mon processeur ! J'aime beaucoup.

D'ailleurs, quelqu'un conna�t un frontend style cgdb, ddd ou autre pour ce fameux d�bogueur?

Vivement que �a sorte dans Debian (unstable, bien s�r, pour la stable, faut attendre 2 ans minimum ^^ ), cette version 3.2 ...

Sur Mac, on utilise d�j� exclusivement LLDB au lieu de GDB, donc je pense pas que tu aies besoin d'attendre longtemps.

[Klaim]

Sur Mac, on utilise d�j� exclusivement LLDB au lieu de GDB, donc je pense pas que tu aies besoin d'attendre longtemps.

Attention, les numeros de version de la version fournie par Apple ne correponds pas du tout aux releases officielles de LLVM. Ils ont leur propre version modifiee et avec leur propre numero de version.

[Freem]

Sur Mac, on utilise d�j� exclusivement LLDB au lieu de GDB, donc je pense pas que tu aies besoin d'attendre longtemps.

Effectivement. Aurais-tu quelques retours dessus, ou mieux, des outils l'utilisant?

Parce que, tr�s sinc�rement, GDB est une plaie pour moi. A moins que ce ne soient les interfaces qui j'y ai trouv� (code::blocks et cgdb) qui en soient la cause, mais il est juste incapable de d�boguer le projet sur lequel je travaille actuellement.
Au point que je suis contraint d'utiliser des horreurs type printf("%s\t%d\n",__FILE__, __LINE__); pour savoir ou �a plante...

Je soup�onne le multi-thread interne � wxwidgets d'�tre la cause de mes probl�mes, mais peu importe, quand le d�bogueur n'est pas capable d'arr�ter le programme quand on lui demande avec un breakpoint, ce n'est pas la faute de la biblioth�que!

Donc, si quelqu'un � des pistes...

[Klaim]

Sur mac jusqu'a present je crois que c'est GDB par defaut...


Sinon, il me semble avoir lu soit sur la mailing list, soit sur le site de LLVM que le nouveau debugger est maintenant corrige et donc carement superieur a GDB, mais quand j'ai lu ce poste j'ai cherche ou j'ai lu ca et je ne retrouve plus ma source.

Tu ferais mieu de demander sur la mailing list a mon avis.