Compiler systematiquement en optimisant ?

Le
candide
Bonjour

J'ai écris la facétie suivante :

/* erreurOpt.c */
#include <stdio.h>

int main(void)
{
/* inclusion interdite dans le corps d'une fonction externe */
#include <string.h>

printf("%u", strlen("toto"));

return 0;
}


Compilé de la manière suivante

$ gcc -Wall -Wextra -stdÉ9 -pedantic erreurO2.c

aucun avertissement ni erreur n'est affiché par le compilateur et l'exécution se
déroule sans erreur visible.

Compilé avec une simple option d'optimisation :

$ gcc -O2 erreurOpt.c

cela permet de détecter une succession d'erreurs dont voici le début de la liste :

In file included from /usr/include/string.h:423,
from erreurO2.c:6:
/usr/include/bits/string2.h: Dans la fonction «main» :
/usr/include/bits/string2.h:972: erreur: nested function «__strcspn_c1» declared
«extern»
/usr/include/bits/string2.h:983: erreur: nested function «__strcspn_c2» declared
«extern»

Je ne sais pas si mon exemple est reproductible sous d'autres compilateur et/ou
d'autres plateformes.

Mais, existe-t-il une "recommandation" qui suggèrerait de compiler
systématiquement ses sources avec une option assez élevée d'optimisation afin de
diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but
d'améliorer le temps d'exécution) ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
espie
Le #18681151
In article candide

Mais, existe-t-il une "recommandation" qui suggèrerait de compiler
systématiquement ses sources avec une option assez élevée d'optimisation afin de
diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but
d'améliorer le temps d'exécution) ?




Oui, c'est un comportement connu de gcc: il fait plus d'analyse quand on
compile en -O quelque chose.

En des temps recules, la recommendation etait meme de compiler systematiquement
avec -O2, parce que c'etait la seule option de generation de code qui etait
vraiment bien testee...

Lorsque j'enseigne le C, je recommande systematiquement
-O2 -g -W -Wall

(pas fan de -stdÉ9 -pedantic), et j'explique le pourquoi du -O2.
candide
Le #18682471
Marc Espie a écrit :

Lorsque j'enseigne le C, je recommande systematiquement
-O2 -g -W -Wall



OK, j'en prends note (au passage : -g et -O2 ensemble ?)


Sinon, je signale que quel que soit le niveau d'avertissement, Visual C++ voit
tout de suite l'erreur d'inclusion.
espie
Le #18683701
In article candide
Marc Espie a écrit :

Lorsque j'enseigne le C, je recommande systematiquement
-O2 -g -W -Wall



OK, j'en prends note (au passage : -g et -O2 ensemble ?)



Ben oui, evidemment. Si tu veux debugguer ton code, tu es bien oblige d'avoir
le -g, et je ne vois pas l'interet de debugguer autre chose que le code qui
va te servir. Il y a tout un ensemble de problemes debiles qui ne vont pas
se poser avec -O0 (typiquement, gcc a une facheuse tendance a initialiser
les variables locales a 0. ;( ). Quelques petites choses a savoir:
- la presence ou l'absence de -g n'est pas censee modifier le code genere.
S'il y a une difference, c'est un gros bug (c'etait ecrit noir sur blanc
dans le cahier des charges de gcc...)
- gdb se depetre raisonnablement bien de code compile avec -O2. Il faut juste
parfois se rendre compte qu'on n'avance plus forcement ligne a ligne, et que
les valeurs de variable sont parfois modifiees "apres coup".
- sur tout systeme moderne, on peut virer les infos de debug si elles prennent
trop de place sur disque, et ca donne la meme chose que si on avait compile
avec -O2 seul (la-encore, si ca n'est pas le cas, c'est un gros bug).
- sur tout systeme moderne, les infos de debut ne sont chargees QUE dans le
debuggueur, et donc ne changent rien a l'efficacite du code lors d'une
execution normale...
Xavier Roche
Le #18684321
Marc Espie a écrit :
- sur tout systeme moderne, on peut virer les infos de debug si elles prennent
trop de place sur disque, et ca donne la meme chose que si on avait compile
avec -O2 seul



[gcc] On peut également les séparer en deux morceaux en jouant avec
objcopy (objcopy --only-keep-debug et ses amis) et ainsi, dans un gros
projet, livrer les fichiers de debuggage "à côté".

Et sous Visual c++, on a les .pdb, de manière analogue.
jacob navia
Le #18724071
candide wrote:
Bonjour

J'ai écris la facétie suivante :

/* erreurOpt.c */
#include
int main(void)
{
/* inclusion interdite dans le corps d'une fonction externe */
#include
printf("%un", strlen("toto"));

return 0;
}


Compilé de la manière suivante

$ gcc -Wall -Wextra -stdÉ9 -pedantic erreurO2.c

aucun avertissement ni erreur n'est affiché par le compilateur et l'exécution se
déroule sans erreur visible.

Compilé avec une simple option d'optimisation :

$ gcc -O2 erreurOpt.c

cela permet de détecter une succession d'erreurs dont voici le début de la liste :

In file included from /usr/include/string.h:423,
from erreurO2.c:6:
/usr/include/bits/string2.h: Dans la fonction «main» :
/usr/include/bits/string2.h:972: erreur: nested function «__strcspn_c1» declared
«extern»
/usr/include/bits/string2.h:983: erreur: nested function «__strcspn_c2» declared
«extern»

Je ne sais pas si mon exemple est reproductible sous d'autres compilateur et/ou
d'autres plateformes.

Mais, existe-t-il une "recommandation" qui suggèrerait de compiler
systématiquement ses sources avec une option assez élevée d'optimisation afin de
diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but
d'améliorer le temps d'exécution) ?




strcspn est inline,

Si l'optimisation est ON alors t'as une fonction dans une autre (nested
function).

Sans optimisation l'inline est ignoré, et tout marche bien.
Publicité
Poster une réponse
Anonyme