Frederic PETROT wrote: Saluti, #include <stdio.h #include <stdlib.h int main(void); int main(void) { int b,i; int x,y; x = 1/y; for( i = 0 ; i<4 ; i++ ) if( i == 2 ) b=2; return(b); } Provoque comme sortie de compilation : gregoire@valse:/tmp/greg gcc -O2 -Wall -c toto.c toto.c: In function `main': toto.c:8: warning: `b' might be used uninitialized in this function Alors que b est systématiquement initialisé, et que l'exéctution de 1/y peut très bien aboutir à un "floatting exception"... sauf si on utilise x par la suite (par exemple un printf), on obtient alors un message comme pour b. Normal. L'optimiseur se rend compte que x est écrit sans être jamais lu, donc il n'est pas calculé, et donc y n'a pas besoin d'exister non plus! Donc PAS de floating exception ici! Il est trop fort ce gcc finalement ! J'ai vérifié ce point en regardant le code généré : main: pushl %ebp movl %esp,%ebp xorl %edx,%edx .align 4 .L45: cmpl $2,%edx jne .L44 movl $2,%eax .L44: incl %edx cmpl $3,%edx jle .L45 movl %ebp,%esp popl %ebp ret .Lfe1: Effectivement, on ne trouve pas de traces de la division, mais on a le message d'erreur concerant b. Concernant b, essaye -funroll-loops ou qqchose de ce genre, le compilo devrait se taire alors. Note que la decidabilite d'un chemin est en general impossible a determiner (sauf ici ou les donnees sont statiques), donc gcc ne se prend pas le mou et utilise le conditionnel. main: pushl %ebp movl %esp,%ebp movl $2,%eax movl %ebp,%esp popl %ebp ret .Lfe1: Alors là, mais alors là, c'est carrement génial : non seulement je n'ai plus de message d'erreur, mais en plus je n'ai même plus ma boucle ! Et comment je fais mes temporisations dans mes programmes ? L'exécution de : gregoire@valse:/tmp/greg gcc -Wall -c toto.c ne détecte rien du tout (comme ça, on est pas embété !). Sauf que ca a toutes les chances de faire la fameuse floating exception, puisque pour le coup on ne modifie pas la structure du programme lorsque l'on n'optimise pas, ... Pas de chance! Les gouroux du C vont sans doute dire qu'il vaut mieux avoir des warnings faux que risquer de rater le "vrai" warning, mais il faut être réaliste : si je lance un Makefile en sachant que plein de messages parasites apparaissent, je ne vais jamais y préter attenttion, le mieux risque d'être pour moi et les autres l'ennemi du bien. Que nenni! Je ne me considère pas comme un guru du C, mais je n'utilise jamais -Wall. Ce qui importe vraiment, ce sont les problèmes de types et de nombre d'arguments de fonctions, Tout à fait d'accord, le reste (genre valeur de retour de printf est int par defaut) ne me sert a rien. Sauf que si tu omets le -Wall, tu n'auras aucun messages d'avetissement dans la situation suivante : char *pta = "Hello"; char *ptb = "World"; printf( "%s %d\n", pta, ptb ); C'est pourquoi je préfère avoir le maximum d'informations lors de la compilation en mettant le -Wall, mais sur ça, chacun à son point de vue. Le problème est que tout le monde se mette d'accord. En résumé, je pense qu'il est mieux de ne pas spécifier le O4 (qui d'ailleur n'existe pas, le gcc va jusqu'à O3), et de ne laisser que le -Wall par défaut, qui oblige à respecter pas mal de choses. N'importe qui pourra lors de ses compilations utiliser le -Oquelquechose localement. Je n'approuve pas, car entre asimut et asimut compile en O4 (gcc prend l'optimisation max qui existe sur la machine, donc il faut considere le n dans On comme une borne sup) Je ne vois pas ça dans le man, mais je te fais confiance. il y a un facteur 2 ou 3 en temps (il suffit de regarder le code généré pour s'en convaincre). La parole est alors aux utilisateurs (surtout ceux des librairies: namealloc compilé en -Wall, ça vous dit ?) J'utilise le -Wall tout le temps, et namealloc ne m'a jamais posé de problèmes. Y'a une astuce ? Maintenant que je saisis un peu mieux le -On, je rejoins ton point de vue : il vaut mieux l'utiliser. Donc pour résumer : Le CFLAGS par défaut est ( je l'ai remis ce matin ) : -Wall -O4 Hier, je voulais seulement -Wall, aujourd'hui, je rejoins le -Wall -O4, tant pis pour les faux warning. Tu voudrais : -O4 seulement. Voir ce détail avec Mr Alliance (Czo pour les intimes) et les personnes que ça interresse. Pour pouvoir m'en sortir ce week-end, j'ai donc (légèrement) abusé de mes droits de root et modifié le fichier Solaris.mk en ne laissant que le -Wall. Qu'en penses tu ? Que je suis pour l'abolition des priviléges! On le savait ! Sauf quand c'est moi qui en profite, bien sur. Ça aussi ! Dommage que tu n'ai pas fait CAO en DEA, tu aurais eu des cours de C. (J'admets que je suis particulierement de mauvaise foi sur celle la, aussi implore-je des a present ton pardon). C'est bien parce que je suis content d'avoir découvert les subtilités du -O4. Fred P.S: echangerait quelques pipes et terminaux virtuels contre un bon moyen de communication interprocess pouvant utiliser les entres sorties standard. Il te faut deux xterm et un étudiant de maîtrise en stage. Tu ouvres les deux xterm. L'étudiant lit les informations du premier process sur un xterm et les recopie au clavier sur le process tournant dans le deuxième xterm. Ecrire au journal qui fera suivre. @----------------------,-,-----,-------------------------------------@ |Ad augusta Frederic PETROT: MC d'ASIM/LIP6/UPMC (Paris VI) | |Per angusta 55-65/201 4 place Jussieu, 75252 Paris Cedex 05 | |Work - Tel:331 44275415 Fax:331 44276286 Frederic.Petrot@lip6.fr | |Home - Tel:331 47129513 http://asim.lip6.fr/~fred/ | |Pager - 336 56278636 | @--------------------------------------------------------------------@ -- Gregoire AVOT Universite Pierre & Marie Curie Laboratoire LIP6 - Dpt ASIM 4 Place Jussieu, Paris Cedex 05 Couloir 55-65, 2eme etage. Tel (portable) : 06.68.55.26.33 http://asim.lip6.fr/~gregoire/index.html