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.2
2) 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?)
L'optimisation du compilateur passe en effet par ces deux phases. Je ne
suis pas s�r que le jeu en vaille la chandelle. ....
Je ne comprends pas, un compilateur fabrique un binaire � partir d'un
source. Bon.
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
