Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Linus Torvalds trouve un bug dans GCC 4.9 et qualifie celui-ci de « merde »
Le compilateur reçoit un prix de l'ACM

Le , par Hinault Romaric

0PARTAGES

8  0 
Le compilateur GCC a fait récemment l’objet de deux événements inattendus : d’un côté la colère de Linus Torvalds, et de l’autre côté un prix de l’ACM (Association for Computing Machinery).

Le compilateur GCC (GNU Compiler Collection), très célèbre dans l’écosystème du libre et de l’open source, est utilisé pour le développement de grands projets comme le noyau Linux, dont plusieurs fonctionnalités dépendent de GCC. GCC propose une série de compilateurs pouvant prendre en charge les langages C, C++, Objective-C ou encore Java.

Lors du développement de la version 3.16 du noyau Linux, un bug a été constaté dans une fonction d’équilibrage de charge. Après plusieurs évaluations du code de Linux pour identifier le problème, Linus Torvalds s’est rendu compte que c’était le compilateur GCC 4.9 qui était la source du problème.

Dans un ton qui lui est caractéristique, Torvalds n’a pas ménagé sa colère et s’est emporté contre les développeurs de GCC. Il était dégoûté par le code généré par GCC 4.9, qu’il n’a pas manqué de qualifier de « merde ».

« Ok, je suis en train de regarder le code généré et votre compilateur est purement et absolument une *merde* », a écrit Linus Torvalds dans la liste de diffusion du projet.

Le problème indexé par Torvalds est le fait que le compilateur aurait apparemment renversé une constante lors de la génération du code sur architecture x86-64. « Le compilateur fait des choses absolument folles avec le renversement, y compris le renversement d’une constante », a critiqué Linus Torvals, avant d’enfoncer le clou. « Ce compilateur n’aurait pas dû être autorisé à sortir de la maternelle. »

La suite du message de Linus Torvalds présente de façon détaillée le bogue et les potentielles causes, ainsi que le rapprochement avec un autre bogue, avant de conclure que quoi qu’il en soit, il ne s’agit pas d’un bogue du noyau Linux. « C’est votre compilateur qui crée du code complètement cassé. », conclut Torvals, qui met ensuite en garde les développeurs de GCC. « Nous pourrions ajouter un avertissement pour nous assurer que personne ne compile avec GCC 4.9.0 et les gens de Debian devraient probablement downgrader leur brillant nouveau compilateur. »

GCC 4.9.0 est disponible depuis avril dernier. Une mise à jour (GCC 4.9.1) a été publiée récemment. Il n’est pas certain que le bug soit résolu dans cette version. Linus Torvalds a signalé le problème sur le bug tracker du projet. Pour l’instant, il est préférable d’utiliser GCC 4.8 qui est encore la version par défaut pour plusieurs distributions Linux.

Parallèlement, GCC a reçu pour la première fois un prix de l’ACM, après pratiquement 30 ans d’existence. Pour l’ACM, GCC « offre un compilateur portable, productif, conforme aux normes et optimisé, qui soutient plusieurs architectures et plusieurs langages de programmation ».

Pour rappel, le compilateur LLVM, qui existe depuis environ 10 ans, a reçu il y a 2 ans le même prix de l’ACM. Des travaux ont déjà été effectués par des développeurs pour compiler le noyau Linux avec LLVM/Clang. Dans Linux 3.15, il est pratiquement possible de compiler le Kernel avec LLVM.

Sources : message de Linus Torvalds sur LKML, ACM

Et vous ?

Que pensez-vous de la réaction de Linus Torvalds ? Justifiée ou disproportionnée ?

Utilisez-vous GCC ou LLVM ? Pourquoi ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de transgohan
Expert éminent https://www.developpez.com
Le 30/07/2014 à 8:27
Disproportionnée comme toujours. Ce bonhomme ne sait pas s'exprimer sans gueuler.
Des raisons de médiatiser autant un simple ticket de report ?
Ah mais oui... C'est parce que ce monsieur est connu qu'on médiatise le moindre de ses mots...
Allez, ouvrons un sujet de news à chaque bug trouvé sur GCC !
4  0 
Avatar de digitkiller
Membre du Club https://www.developpez.com
Le 30/07/2014 à 9:29
Toujours disproportionné, c'est sa marque de fabrique, le gars est doué, mais a aussi une très haute estime de lui. GCC est utilisé depuis probablement la première version du noyau, le noyau 3.16 est-il exempt de bugs (sauf celui provoqué par le compilo) ? Est-ce pour autant une "merde", je ne crois pas.
4  0 
Avatar de Kropernic
Expert confirmé https://www.developpez.com
Le 30/07/2014 à 9:42
Bah... C'est sa marque de fabrique... On le sait qu'il démarre au quart de tour. Donc tout va bien :-)
4  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 30/07/2014 à 11:05
A force de pousser des gueulantes et d'insulter tout le monde, il va finir par entamer sa propre crédibilité...
4  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 30/07/2014 à 12:54
"Tout ce qui est excessif est insignifiant" (ça a été attribué à différentes personne : Beaumarchais, Talleyrand...)
4  0 
Avatar de niarkyzator
Membre confirmé https://www.developpez.com
Le 30/07/2014 à 17:00
J'ai lu la suite de la conversation, et j'ai pas l'impression que Linus soit dans un accès de rage folle et incontrôlable.

Personne le prend mal, ça semble admis que le code pointé du doigt était mauvais et personne ne se sent offusqué blessé ou agressé.

C'est franchement tout un fromage pour pas grand chose, si le code est pourrit le code est pourrit, et si les gens (Linus et les gens de chez GCC, et de linux) sont suffisamment proche pour pouvoir utiliser ce niveau de langage je vois pas ce que ça peut nous faire.
4  0 
Avatar de SKZ81
Membre habitué https://www.developpez.com
Le 14/08/2014 à 10:03
Moi perso j'aimerai avoir des rapport de bug aussi détaillé, analysés en amont, etc...

Un rapport de bug mal analysé, avec peu de détails ne me dérange pas, si la personne n'est pas spécialiste et qu'elle reste aimable.
Un rapport de bug incendiaire mais avec toutes les infos utiles, où on sent que le mec a bien pris le temps de chercher, ne me dérange pas vraiment non plus (bon à condition que les "attaques" concernent le code, pas les personnes. Linus n'a pas explicitement insulté les personnes, mais l'outil. Ok, comme ce sont les personnes en question qui font l'outil... Ok, ok, mais la nuance existe).

Bien évidemment, tout le monde préfèrerait des rapport de bug courtois par des gens compétents qui ont pris le temps d'analyser le problème, mais on ne vit pas au pays des bisounours.

Je ne parle pas des tickets tous pourris écrits sur un ton aggressif, on sait où ils finissent
4  0 
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 30/07/2014 à 15:22
Réaction normale. Il m'est arrivé de tomber sur un bug dont l'origine ne venait pas du code source mais du compilateur. Sur le moment, ça énerve énormément, d'une part pour le temps perdu à essayer de comprendre d'où vient l'erreur, d'autre part parce que l'on se retrouve avec un code source parfaitement correct que l'on ne peut pas compiler à cause ... D'un programme de merde. Niveau frustration, c'est le top.
3  0 
Avatar de Jacen Solo
Membre à l'essai https://www.developpez.com
Le 08/08/2014 à 17:56
Ca amuse Linus.

Si vous trainez sur la LKML, vous devez avoir vu la conversation entre Linus et Sarah Sharp, une employée de Intel qui critiquait son franc parler :
https://lkml.org/lkml/2013/7/15/374

Par contre, l'article n'est pas très clair sur le bug. Je ne suis pas sur qu'on utilise le terme renversement en Français pour le spilling. Le Spilling, c'est quand on commence à avoir trop de variables à manipuler, et qu'on vient en sauvegarder quelques une sur la pile pour libérer des registres. Le problème c'est que les accès mémoire, c'est très lent, donc moins on en fait, mieux c'est. Là, GCC 4.9 (et les précédents aussi) sauvegarde ainsi sur la pile un registre qui a une valeur constante, et le restaure après quand il en a besoin. Il est bien plus efficace d'écraser la valeur, et de la remettre plus tard avec de l'adressage immédiat (une instruction avec une valeur codée en dur dedans). Le comportement est le même, mais il n'y a pas d'accès à la pile, et c'est plus rapide.

Mais le bug n'est pas là. Ce mauvais comportement aide le bug à être révélé (le bug est présent depuis 4 ou 5 ans), mais n'est pas le vrai bug. En fait, gcc stocke les variables sur la pile, et ensuite seulement étend la taille de la pile. Si une interruption survient entre les deux, la routine d'interruption ignore qu'il y a des données à ne pas écraser au delà du pointeur de pile actuel. Pourquoi n'a-t-on pas vu le bug avant ? Parce que x86-64 prévoit une "zone rouge" de 128 octets que les routines d'interruption ne touchent pas, ce qui évite normalement de corrompre la pile dans le cas ci-dessus. Malheureusement, ici, il y a eu 136 octets de données "spilled", et donc une interruption au mauvais moment peut corrompre la stack du noyau.
Linus explique ça très bien :
https://lkml.org/lkml/2014/7/24/584

edit : en fait, ça aurait posé problème même avec le système de zone rouge, mais la zone rouge est prévue par l'ABI, pas par le processeur lui-même. En espace noyau, il ne peut donc pas y avoir de zone rouge, parce que les IT tombent dans le contexte du noyau, donc c'est encore pire.
3  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 19/08/2014 à 19:27


Il est marrant lui, Linus... ben si t'es pas content, fait le toi même le compilo !
C'est le genre de message qu'il a eu de Tanenbaum, le créateur de Minix. Du coup il a fait Linux.
3  0