Mouais ça me parait douteux ça. A priori optimiser le code n'est pas une tâche facile, on est d'accord. Et ici l'optimisation est complètement pourrave (si tant est qu'il y ait de l'optimisation là dedans, ça ressemble plus à un code pas (encore) optimisé). Mais heu, désoptimiser du code pour le faire tenir dans plus d'espace, ça c'est peut être encore plus difficile, enfin si c'était le cas il aurait juste rajouté des nop comme tu le suggères, car ça ne coûte rien. (et sans doute que ça consomme moins d'énergie/produit moins de chaleur mais ça je sais pas trop)
Sinon j'ai jamais accordé aucune confiance à gcc donc je suis pas vraiment choqué (ouais j'aime pas les usines à gaz open source c pas un secret

) mais il me semble avoir lu il y a longtemps que ARM étant le mainteneur de la partie ARM de gcc, faisait exprès de garder gcc en retard sur son propre compilateur, je sais pas quel est l'état des choses actuellement, mais ça pourrait expliquer quelques trucs éventuellement.
Enfin pour un processeur si souvent utilisé dans l'embarqué c clairement mauvais (tout comme le compilateur de TI pour AMS cela dit

), ça ne fait que diminuer l'autonomie des appareils fonctionnant sur batterie :/
Et pour le saut moisi, il me semble que certaines fonctionnalités (je pense à la liaison incrémentale mais je sais pas si gcc/gcc-arm le fait) peuvent produire ce genre de code inutile. Mais après c'est clair que ce genre de choses ne devrait jamais apparaître ailleurs que dans un build debug, quelle qu'en soit la raison
