Gcc fait des optimisations auxquelles on ne s'attend pas forcément. Quelques cas auxquels je pense:
Il optimise printf("chaine\n") en puts("chaine")
Dans Haiku, dans notre libc on teste dans nos fonctions de manipulations de chaîne (strcpy, strlen, ...) si un pointeur null est passé en paramètre. Dans le standard C, l'appel de ces fonctions avec un paramètre null est un comportement indéfini. Gcc optimise notre implémentation en enlevant le test qu'on avait ajouté. Il peut aussi décider de ne pas du tout appeler la fonction et d'utiliser sa propre implémentation.
Les compilateurs font usage de tout ce qui est dit dans la spécification, et la spécification est architecturée pour ça. Par exemple la spécification du C décrit un mode "hosted" et un mode "freestanding", dans le deuxième, la plupart des fonctions de la librairie standard ne sont plus définies. Ce qui permet au compilateur de savoir qu'il doit désactiver les optimisations correspondantes.
L'idée qu'on se fait d'une architecture bien découpée en couches indépendantes ne tient en fait pas la route quand on regarde les détails d'implémentation.
[^] # Re: Vectorisation illégale
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Recherche de valeur dans un tableau et l'écosystème des compilateurs C++. Évalué à 7.
Gcc fait des optimisations auxquelles on ne s'attend pas forcément. Quelques cas auxquels je pense:
Les compilateurs font usage de tout ce qui est dit dans la spécification, et la spécification est architecturée pour ça. Par exemple la spécification du C décrit un mode "hosted" et un mode "freestanding", dans le deuxième, la plupart des fonctions de la librairie standard ne sont plus définies. Ce qui permet au compilateur de savoir qu'il doit désactiver les optimisations correspondantes.
L'idée qu'on se fait d'une architecture bien découpée en couches indépendantes ne tient en fait pas la route quand on regarde les détails d'implémentation.