Je ne comprends pas, un compilateur fabrique un binaire à partir d'un source. Bon.L'optimisation du compilateur passe en effet par ces deux phases. Je ne suis pas sûr que le jeu en vaille la chandelle. ....il me semble en effet avoir lu dans le dernier Linux mag qqchose disant qu'en fait, si on veut bénéficier pleinement d'un gcc 3.4 (par exemple) et qu'on a une version 3.2 (toujours par exemple, mais une version inf à 3.4 quoi), il faut :1) compiler les sources du 3.4 avec le 3.22) recompiler un nouveau 3.4 avec le 3.4 qu'on vient de compiler (pour bénéficier ds la version 3.4 compilée des améliorations de la 3.4 en gros?)
On a un compilateur C1 (le 3.2) et C2 (le 3.4). C2 est réputé plus efficace que C1 bien, d'accord. Ce la veut dire que si B1 et B2 sont les binaires produits par C1 et C2 pour un code T donné, B2 est mieux optimisé. Par contre je ne vois pas en quoi le fait que le code de C2 soit optimisé où non change B2 (amélioration ou non), en clair il est quand même souhaitable que le fonctionnement d'un programme (je ne parle pas de la rapidité mais des résultats exacts (fichiers produits, résultats numériques aux erreurs de calcul en flottant près,...)) soit indépendant du compilateur utilisé. Donc si on compile C2 avec une brouette et C1 avec un megacompilateur, C2 mettra deux siècles là où C1 mettra deux secondes mais le code produit par C2 (B2 donc) restera le même donc sera plus efficace que celui produit par C1 (soit B1). C'est je pense ce que voulait dire Patrice et ça me parait exact. En clair recompiler gcc me parait inutile car optimisant un programme utilisé occasionnellement. Par contre utiliser une version plus récente de gcc peut effectivement être utile pour optimiser un programme utilisé chaque jour.
François Boisson