Développeur : Sortie de la version 4.1 du compilateur GCC
Posté par patrick_g (page perso, ). Modéré le 01 mars 2006.
Après le tant attendu GCC 4.0 qui a vu la refonte complète son architecture interne voici maintenant la version 4.1 qui arrive.
Comme prévu la technologie SSA (Static Single Assignement) qui est au c½ur du nouveau GCC permet maintenant d'optimiser plus facilement le code source afin d'obtenir des améliorations générales. Le SSA est (en très gros) une forme intermédiaire entre le code source et le binaire dans laquelle chacune des variables du code source n'est assignée qu'une seule fois. Cette assignation unique a de nombreux avantages :
- Les définitions et les utilisations de chacune des variables deviennent claires et explicites.
- La majorité des analyses statiques du code source ne propagent les informations qu'à l'endroit strictement nécessaire.
- Un grand nombre d'optimisations sur la forme intermédiaire SSA deviennent linéaire en temps.
- De nombreux algorithmes deviennent plus concis et plus simples dans le cadre du SSA.
![[en]](../images/en.png)
La liste des nouveautés de GCC 4.1 : (1655 hits)-
SSA sur Wikipedia : (842 hits)
-
Protection contre les écrasements de la pile : (515 hits)
-
Le sommet GCC de 2005 : (307 hits)
![[fr]](../images/fr.png)
GCC sur Wikipédia (1448 hits)
> Lire la dépêche (75 commentaires, moyenne: 4,5).
Vous avez demandé le commentaire #687011.
Run by 
Cette page a été générée par Templeet en 0.1012s (dont 0.008 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Esperons que la qualité suivra
J'ai eu quelques problèmes avec GCC 4.1 qui est plus restrictif au niveau du code.
MPlayer ne veux pas compiler avec, il impose gcc-3. Je me suis amusé à le forcer à utiliser gcc 4, ça ne compile effectivement, et il génère une erreur interne.
De même, le code généré par le compilateur Lisaac, qui a la particularité de gérer lui-même sa mémoire (ie. un gros malloc au début, et une gestion "à la main" des zones mémoires dans le code), ne compile généralement pas le code généré par le compilateur. Ce code est pourtant conforme à C99 (au minimum tout le corps du code).
Remarque GCC 3 déconne aussi parfois. Avec le même code craché par le compilateur, on remarque, si l'on compile en -O {2,3,s}, que le compilateur invente des registres (!!!). C'est vraiment assez marrant à regarder.
Il serait donc peut être intéressant qu'un jour, une équipe, comme celle de Xavier Leroy à l'INRIA s'amuse à prouver quelques morceaux du compilateur.
Ce qui a été fait pour un compîlateur mini C.
http://pauillac.inria.fr/~xleroy/compcert-backend/
GCC reste néanmoins un excellent logiciel, sans lequel le libre ne serait à mon avis pas ce qu'il est.
Félicitation à l'équipe.
[^]Re: Esperons que la qualité suivra
pour mplayer, c'est de la faute des developpeurs qui travaillent comme des cochons.
[^]Re: Esperons que la qualité suivra
J'arrive pas à croire que ce genre de réflexion ait été marqué comme pertinente par les lecteurs de linuxfr.
Autant tu as raison qu'une partie du code C qui ne compilait pas avec GCC-4.x était moche, et le fait de l'adapter pour qu'il soit compatible avec GCC4 a été une bonne chose, autant les modifications qu'il y a eu à faire pour adapter l'assembleur inline a été un vrai cauchemar. La faute à certaines version de GCC qui ne respectent même pas les spécifs de leur propre docs. La faute aussi à l'équipe de GCC qui considère que c'est normal qu'un code ne puisse compiler que quand on active les optimisations: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203#c14 , la faute à l'équipe de GCC de considérer que c'est une situation normale que GCC ne puise pas réaliser son allocation de registre avec certains codes asm inline valides.
Oui, le code de MPlayer n'est pas ce qu'on puisse rêver de mieux en matière de qualité de code, mais ton aide est la bienvenue si tu veux remédier à ce problème.
[^]Re: Esperons que la qualité suivra
C'etait pertinent. Dans le bug que tu cites, justement, il y a de l'assembleur inline a la tonne qui devrait compiler sur une architecture notoirement pauvre en registres (i386). Le compilateur ne peut pas trouver de registres libres pour toutes les instructions sans passes d'optimisation. Ce n'est pas comme si GCC n'arrivait pas a compiler du C sans optimisation.
[^]Re: Esperons que la qualité suivra
Il devrait tout de même réussir à le compiler (tant que ce n'est pas impossible)... Même si on ne lui demande pas d'optimiser il devrait essayer de compiler parce que c'est le but, qu'on lui ait demandé d'optimiser est juste une indication sur la façon d'aboutir au résultat final.
Par ailleurs la suite de la discussion est assez surréaliste avec un gros mensonge où quelqu'un confond NP-complet et "impossible", ce qui, même pour un étudiant en informatique comme moi est vraiment gros...
Il faut aussi tenir compte du fait que mplayer a une très grosse base de code assez ancien, ce qui ne peut pas aider, et que mplayer a également "besoin" d'utiliser du asm inline s'il veut garder la légèreté qui fait sa qualité en tant que lecteur vidéo. Franchement mplayer est l'aïeul du multimédia (vidéo) Linux et avec ffmpeg continue à être l'un des acteurs les plus important du multimédia libre. Alors insulter mplayer pour la qualité de son code c'est vraiment une réaction détestable ! Rien ne t'empêche d'aider au développement.
--
Jedaï
[^]Re: Esperons que la qualité suivra
Par ailleurs la suite de la discussion est assez surréaliste avec un gros mensonge où quelqu'un confond NP-complet et "impossible", ce qui, même pour un étudiant en informatique comme moi est vraiment gros...
Oulala, je me sens visé...
Je n'ai pas dit que NP impliquait impossible. J'ai laissé entendre qu'on ne sait pas (et son auteur ne le sait pas non plus, je suis bien placé pour le savoir) comment le compilateur Lisaac réagira si on lui demande de compiler 1 000 000 de lignes.
Il consomme 512 Mo pour compiler 50 000 lignes (lib incluse) en 15 secondes (sur un athlon 2Ghz). Combien lui faudra t-il de mémoire et de temps pour compiler 1 000 000 de lignes ? On ne sait pas, on a jamais essayé.
L'analyse de flot (ie. l'algorithme testant toutes les branches de programme pour par exemple détecté qu'une variable est défini par n:=2*n+1 et 10 km virer un test de parité car il ne sert à rien) est un algorithme extrêmement consommateur de ressources, car exponentiel.
Pas impossible en théorie, mais potentiellement impossible sur le PC que j'achète chez l'assembleur du coin.
[^]Re: Esperons que la qualité suivra
Je n'ai pas dit que NP impliquait impossible. J'ai laissé entendre qu'on ne sait pas
C'est pas la question.
Au pire tu peux utiliser la pile pour avoir tous les registres dispo (minus ceux en parametre) quand tu rentre dans un bloc asm inline.
[^]Re: Esperons que la qualité suivra
Ben ouai mais en même temps c'est dur d'intervenir sur un projet ou la fonction main fait 4000 lignes ;) (enfin elle faisait environ ça la dernière fois que j'ai regardé :p)
[^]Re: Esperons que la qualité suivra
Salut,
wc a compté 3225 ligne pour le main, faut exgérer non plus :P
Espérons que c'est le resultat d'un ménage progressif :)
E Ultreïa !
[^]Re: Esperons que la qualité suivra
« Alors insulter mplayer pour la qualité de son code c'est vraiment une réaction détestable ! Rien ne t'empêche d'aider au développement. »
Tu veux dire, mis à part les fonctions de 4000 lignes et les hacks qu'on retrouve dans tous les sens ?
[^]Re: Esperons que la qualité suivra
A ce propos, j'ai proposé aux dev de MPlayer de quoi corriger la tonne de warning portant sur les "differ in signedness" afin déjà de corriger les plus simples qui sont dans les arguments de fonctions...
Il semble cependant en effet que ce ne soit pas leur priorité et même trouvent les changement alourdissant le code.
Maintenant la question est vaut il mieux un code peut-etre un peu lourd mais qui compile sans erreurs, ou garder le code "leger" mais vomissant des pages d'injures à la compile ?
[^]Re: Esperons que la qualité suivra
Ben c'est vrai que differ in signedness c'est un warning chiant. Si tu veux les enlever il faut spécifier le signe sur chaque char *: unsigned char * ou signed char *. Sinon tu vas corriger les warnings sur x86 et en ajouter sur ppc, ou vice-versa. C'est débile d'avoir ajouté ce warning dans -Wall. -- A mon humble avis.
Claws Mail - it bites!
[^]Re: Esperons que la qualité suivra
Personnellement ça m'a déjà sauvé la vie (une sombre histoire de "c == EOF" qui n'était jamais vrai sur PPC). Mais si t'aimes pas t'es toujours libre de rajouter -Wno-sign-compare.
Par ailleurs -Wsign-compare n'est pas activé par -Wall mais par -Wextra (anciennement -W).
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[+] [^]Re: Esperons que la qualité suivra
lol effectivement...
par contre xine a l'air bien ecris
[^]Re: Esperons que la qualité suivra
C'est corrigé depuis longtemps...
Prend le CVS ca marche sans probleme
(Pas testé avec le 4.1 pour le moment mais nickel pour le 4.0 je l'utilise plusieurs heures par jour sans probleme (vive le multiposte free))
[^]Re: Esperons que la qualité suivra
Bah pas chez moi :(
[^]Re: Esperons que la qualité suivra
Moi ca marche nickel....
Avec gcc 4.1, testé avec 1h de multiposte free
[^]Re: Esperons que la qualité suivra
J'ai eu quelques problèmes avec GCC 4.1 qui est plus restrictif au niveau du code.
On dit pas "plus restrictif", mais "plus respectueux des standards" :-) Avec l'option -Wall, gcc sort des avertissements souvent pertinant ou pouvant détecter des bugs. Les corriger prend du temps (si on n'avait jamais utilisé -Wall), mais ça ne peut qu'être bénéfique !
Bon, après il existe peut-être des faux-positifs ... mais j'en ai jamais rencontré.
Pour les extrémistes : options -ansi voir ... (aïe) -pedantic :-P
Haypo
[^]Re: Esperons que la qualité suivra
« Pour les extrémistes : options -ansi voir ... (aïe) -pedantic :-P »
Euh, je n'utilise jamais -ansi, parce que de toute manière je serais obligé de définir certaines macros spécifiques à GCC, alors autant garder l'environnement de base. Mais je ne vois pas en quoi --pedantic est une option d'extrêmiste.
-Wall -W -pedantic
me semblent les options minimales pour qui veut faire un code un minimum correct (éventuellement avec l'option -std=c99 histoire de se mettre au goût du jour - mais bon, comme GCC n'implémente pas toutes les options de C99, ce sera du C99--).
[^]C'est très bien -pedantic mais avec -std=c99 quand même
Et pour les masochistes, il y a splint(1).
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]D'autres outils
Et flawfinder (écrit en Python :o)) et rats pour la sécurité.
http://www.dwheeler.com/flawfinder/
https://securesoftware.custhelp.com/cgi-bin/securesoftware.c(...)
J'ai jamais compris si rats était libre ou nan !? Attendez je lis la licence ... GNU GPL2, ah nan c'est bon :-) C'est le formulaire qui me trouble.
J'ai l'impression que Flawfinder trouve plein de trucs, mais les rapports générés sont bordeliques. rats fait de jolis rapport en regroupant les fichiers (avec numéro de ligne) par erreur.
Puis y'a Valgrind pour traquer les erreurs d'accès mémoire et fuite de mémoire. La conférence à FOSDEM m'a vraiment convaincu que c'est un outil génial :
http://valgrind.org/
Pour un atelier sur la sensibilisation à la sécurité, j'avais entamé un article où vous y trouverez plein de liens :
http://www.haypocalc.com/wiki/Analyse_statique_de_code
Haypo
[^]Re: D'autres outils
Si on sort de l'analyse statique, il y a Electric Fence qui est bien plus limité que Valgrind mais très pratique et facile à utiliser. Sinon on m'a fait découvrir les "Google Performance Tools" sur IRC hier.
http://goog-perftools.sf.net/
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: Esperons que la qualité suivra
De même, le code généré par le compilateur Lisaac [...] ne compile généralement pas le code généré par le compilateur.
Pourrais-tu expliquer/expliciter à un béotien ? J'avoue que j'ai rien compris du tout...
[...] qui a la particularité de gérer lui-même sa mémoire (ie. un gros malloc au début, et une gestion "à la main" des zones mémoires dans le code)
"Le code", celui de l'appli ? ou celui du compilo ? Tu parles d'une forme de GC ?
Le fonctionnement de Lisaac a l'air assez intéressant, mais relativement obscur. Merci d'avance.
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
[^]Re: Esperons que la qualité suivra
sur le 1 :
AMHA (Ontologia pourra me contredire) on a
code Lisaac --(compilo Lisaac)--> code C --( gcc )--> executable
Et ça coince à l'étape gcc, alors que normalement le code C généré est complètement correct.
Sinon, pour le 2, toujours AMHA, ca doit être le code C généré qui a des fonctions de gestions de mémoire maison, et qui gère l'allocation à l'intérieur du gros "malloc", sans doute une forme de gc, oui, mais là, je suis moins sûr ;)
[^]Re: Esperons que la qualité suivra
Je répond au post grand-père en ajoutant quelques commentaires à ta réponse utile.
Effectivement, Thomas a bien décrit le fonctionnement du compilateur.
La gestionnaire mémoire est tout simplement défini dans le fichier memory.li qui se trouve dans la lib du compilateur.
Rappelons que Lisaac est un compilateur ultra minimaliste : il ne connait même pas la conditionnelle, elle est défini dans la lib.
Un gros malloc est effectivement effectué au début, et un GC gère toute la mémoire.
Comme tout est intégralement compilé, le GC est défini dans la libairie en fait (le fameu memory.li)
Ça coince effectivement au niveau de la compilation avec gcc.
Je compare ce qui n'est pas comparable, mais comparer du C est beaucoup plus difficile que compiler du Lisaac (quoique, compiler l'héritage dynamique est extrêmement difficile, nécessite une analyse de flot sur touts le code et constitue de toutes façon un algo de complexité exponentielle), du moins compiler proprement : la grammaire de Lisaac tiens en 20 lignes, celle du C en 4 pages...
[+] [^]Re: Esperons que la qualité suivra
Et la marmotte qui met le chocolat dans le papier d'alu, tu la prouves aussi en Coq ?
Sérieusement, on est très très très très loin de pouvoir prouver du code C un tant soit peu non trivial, alors des bouts de gcc...
Vous devriez vraiment visiter Aperture First !
[^]Re: Esperons que la qualité suivra
C'est pas une question de trivialité, c'est une question de grammaire.
Ce qu'à fait X. Leroy, c'est de prouver le parser, la transformation du code source en code intermédiaire , l'allocation de registres et la traduction du code intermédiaire en code objet.
Prouver du code C, c'est plutôt l'oeuvre de Jean-Christophe Filliatre http://why.lri.fr
C'est vrai, que vu la taille de la grammaire, prouver du C non trivial est pas chose facile.
[^]Re: Esperons que la qualité suivra
Il me semble qu'il existe ce genre de compilos partiellement prouvés dans le domaine de de l'embarqué, peut être pas avec le C en entier, mais au moins avec des sous ensembles, ultras-chers par ailleurs.
(La flemme de fouiller dans mes notes pour voir si j'ai noté des trucs là dessus)
[^]Re: Esperons que la qualité suivra
T'es sûr que tu confonds pas avec un compilateur Ada ?
http://www.cs.ucla.edu/~palsberg/paper/iccl92.pdf
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: Esperons que la qualité suivra
Effectivement, le premier compilo prouvé, et longtemps le seul, ça a été un compilo ADA (c'est plus simple, le langage est concu pour être plus robuste, et ADA était un langage poussé entre autre par les armées).
Mais là, peut être que je me plante, mais il me semble qu'il y a des compilos C prouvés maintenant (Le papier date d'il y a 14 ans, ça me semble pas impossible ;) )
[^]Re: Esperons que la qualité suivra
[Mode chiant ON]
Ada :p
[Mode chiant OFF]