GTC : un TIGCC sur votre calculatrice ? - Page 80

de toute façon, une entrée non initialisée, c'est une entrée comme une autre (elle est juste un peu plus dure à passer en argument).

et une entrée non initialisé peut etre totalement voulu

enfin, c'est surtout qu'il répond à côté, comme d'habitude. Je ne comprend pas comment il peut dire que c'est normal qu'un compilateur peut générer un binaire faux d'après un code juste, surtout qu'il ose dire

avec une fonction moins complexe

... dont tu n'as toujours pas démontré la correction.

comme argument conter unhook

Ce que je veux dire, c'est qu'un code faux peut paraître juste avec certains switches et pas d'autres. -fstrict-aliasing par exemple.

c'est kevin

Ce que je veux dire, c'est que c'est pas normal qu'un code juste puisse eêtre juste avec certains switches et pas d'autres. -d par exemple.

Et ben si, c'est tout à fait normal! L'essence-même des optimisations fait que si ton programme est incorrect, même s'il a l'air de marcher (à 100%!) sans optimisations, les transformations effectuées par les optimisations peuvent le casser. Exemple-type: -fstrict-aliasing.

Mais l'histoire du -d n'est pas vraiment liée à cette problématique. Dans ce cas, c'est l'optimisation qui est incorrecte sans ce switch et pas avec (pour des raisons évidentes et documentées, même si tu refuses toujours de les comprendre apparemment). Ce n'est pas un problème de "code juste" ou pas.

Dans la mesure ou un switch permet d'optimiser un programme donné (dans une direction ou une autre), en théorie, le programme doit être le même à la base, sinon, ça n'est pas uniquement le switch qui optimise, vu que l'automate de [compilation|linking...] ne compile pas le même programme d'entrée (enfin, du peu que j'ai appris en automates lexicaux & co., le signal d'entrée doit toujours être le même pour qu'on puisse considérer l'action de l'automate comme étant comparable à une autre action, sinon, on ne peut plus établir de comparatifs, et donc on n'a pas à faire à une optimisation).
D'autant plus si cette optimisation avec modifications obligatoires est activée par défaut dans l'IDE, ne permettant pas une compatibilité ascendante.

en résumé, pour pouvoir apprécier les différences, il faut jauger, paramètre par paramètre, si on fait tout changer d'un coup, le risque de confusion d'interprétation d'un effet grandira.

Et ben si, c'est tout à fait normal! L'essence-même des optimisations fait que si ton programme est incorrect, même s'il a l'air de marcher (à 100%!) sans optimisations, les transformations effectuées par les optimisations peuvent le casser. Exemple-type: -fstrict-aliasing.

je te parle de programmes qui sont corrects à l'entrée et incorrects à la sortie, pas de programmes qui sont incorrects à l'entrée et corrects à la sortie !!!

Mais l'histoire du -d n'est pas vraiment liée à cette problématique. Dans ce cas, c'est l'optimisation qui est incorrecte sans ce switch et pas avec (pour des raisons évidentes et documentées, même si tu refuses toujours de les comprendre apparemment). Ce n'est pas un problème de "code juste" ou pas.

Si c'est un problème de code juste. Un compilateur ne doit pas renvoyer un programme buggué alors qu'il a reçu un code juste en entrée

Nil: je suis tout a fait d'accord avec toi (flanker et vince aussi au passage)

Un montage (ou tout autre systeme prenant une entrée et une sortie) doit, quelque soit, et surtout si il veux etre compatible, donc quelque soit sont fonctionnement interne donner le meme resultat a la sortie (optimisation ou pas) avec la meme entrée.

A moins que bugger une entré soit une optimisation

]

Arg

dit donc t rapide

J'ai marre de discuter avec vous!
1. Vous vous plaignez d'un problème qui est déjà corrigé (switch -d passé automatiquement maintenant)!
2. Le problème dont vous vous plaignez est une erreur d'utilisateur. (La documentation disait clairement qu'il fallait passer le switch -d. Flanker ne l'a pas lue, tant pis pour lui. RTFM connard, sinon c'est DTC si ton programme n'est pas compilé correctement. )
3. Toutes vos théories avec les automates n'ont aucun intérêt en pratique. Je n'ai pas besoin de vos explications, je sais ce qu'est un automate. Mais en pratique, un programme C n'est pas un automate, il y a plein de situations où ce que fait le programme est totalement indéterminé (par exemple i=i++, ou justement les violations des règles d'aliasing). Un programme assembleur n'est pas un automate non plus. En pratique, une optimisation peut facilement détruire un programme incorrect, ou un résultat intermédiaire incorrect. Dans le cas du problème (passé!) dont vous vous plaignez, c'est un résultat intermédiaire incorrect: le switch nécessaire pour que le linker peut faire son optimisation de manière correcte n'a pas été passé à l'assembleur. Le code source n'a strictement rien à voir là-dedans.

Voilà, j'ai déjà répondu plus en détail que je le voulais à l'origine, je ne dirai pas plus.

4. J'oubliais: Ce n'est pas un vote ici, c'est une discussion fondée sur des faits, donc ce n'est pas parce que 4 personnes disent la même connerie qu'elle devient vraie...

RTFM connard, sinon c'est DTC si ton programme n'est pas compilé correctement. )

t'évites de m'insulter stp

4. J'oubliais: Ce n'est pas un vote ici, c'est une discussion fondée sur des faits, donc ce n'est pas parce que 4 personnes disent la même connerie qu'elle devient vraie...

bah évidémment, du moment que tu dis le contraire, nous ne pouvons pas avoir raison.

Flanker
:

RTFM connard, sinon c'est DTC si ton programme n'est pas compilé correctement. )

t'évites de m'insulter stp

Si tu évites de me la gonfler en te plaignant sans arrêt d'un "bogue" qui non seulement n'en est pas un mais de plus n'existe plus, ça pourra peut-être se faire.

ce "bogue" n'existe ptet plus avec l'IDE mais sera tjours présente pour ceux qui utilise de batchs lors de la compilation et il sont nombreux sa j'en suis certain

Godzil :
ce "bogue" n'existe ptet plus avec l'IDE mais sera tjours présente pour ceux qui utilise de batchs lors de la compilation et il sont nombreux sa j'en suis certain

Faux!
1. tigcc.exe passe lui aussi automatiquement -d à A68k si tu compiles avec --optimize-branches ou --optimize-code. (Ça a été corrigé dans la bêta 8: "* Bugfix: In the Win32 tigcc.exe, --optimize-code now also implie[s] --keep-locals or -d (not just explicit --optimize-returns), and tigcc -ar now correctly implies both --all-relocs and --keep-locals (-a and -d for A68k). (The *nix version already got this right in Beta 7 r1.)").
2. L'optimisation du linker est désactivée par défaut dans tigcc.exe, tu ne l'auras que si tu passes explicitement --optimize-code, et dans ce cas tu as intérêt à savoir ce que tu fais.
3. Le seul cas de figure où tu peux avoir un problème est si tu fais tigcc -c et tigcc --optimize-code séparément (ou si tu appelles a68k.exe directement, mais cette configuration n'est pas supportée). Dans ce cas, tu dois passer soit --optimize-code, soit --optimize-branches, soit -WA,-d aussi à ton tigcc -c.
Bref, réfléchis avant et parle après.

Kevin Kofler :
Mais en pratique, un programme C n'est pas un automate, il y a plein de situations où ce que fait le programme est totalement indéterminé (par exemple i=i++, ou justement les violations des règles d'aliasing). Un programme assembleur n'est pas un automate non plus.

Tu te rends compte de l'énormité que tu viens de dire ? Depuis qd l'assembleur a des "undefined behaviour" ? Tu lui donnes ton code, il l'assemble, point. Il n'y a aucun comportement indéfini, justement (enfin, plus précisément, il n'y avait...)

Regarde le manuel du 68k ou de n'importe quel autre processeur, il y a pas mal de trucs laissés non définis. Par exemple le résultat de abcd, sbcd et nbcd sur des nombres qui ne sont pas du BCD valide.

C'est au moment de l'exécution, pas de l'assemblage (pareil pour ce qu'on envoie sur le bus).


Et puis bsr+rts, c'est loin d'être marqué indéfini ou transformable en bra par le 68k

Pollux :
C'est au moment de l'exécution, pas de l'assemblage (pareil pour ce qu'on envoie sur le bus).

Soit, mais ça a quand-même exactement le même effet qu'en C. Un comportement indéfini se manifeste par définition au moment de l'exécution seulement.

Et puis bsr+rts, c'est loin d'être marqué indéfini ou transformable en bra par le 68k

Si tu ne veux pas cette optimisation, tu ne l'actives pas. C'est comme pour toutes les autres optimisations.

ba aucune instruction du 68k n'est marqué indéfinie

Kevin Kofler
:

Pollux :
C'est au moment de l'exécution, pas de l'assemblage (pareil pour ce qu'on envoie sur le bus).

Soit, mais ça a quand-même exactement le même effet qu'en C. Un comportement indéfini se manifeste par définition au moment de l'exécution seulement.

La différence, c'est que le C a la sémantique "j'ai le droit de faire une transformation quelconque du moment que ça ne change pas l'effet d'une exécution normale". En ASM, ce n'est pas du tout comme ça : par exemple, je n'ai aucune envie que l'assembleur me déplace mon code, même s'il suit un "bra" ou un "rts" et que le flux normal ne poserait pas de pb : je peux avoir envie que tout le code lié à une certaine fonction soit entre deux labels donnés. Donc les comportements indéfinis à l'exécution et indéfinis à l'interprétation ne sont plus du tout les mêmes en ASM...

Et puis bsr+rts, c'est loin d'être marqué indéfini ou transformable en bra par le 68k

Si tu ne veux pas cette optimisation, tu ne l'actives pas. C'est comme pour toutes les autres optimisations.

Et c'est désactivé par défaut, donc ? (y compris dans l'IDE)

Godzil :
ba aucune instruction du 68k n'est marqué indéfinie

yop, juste qu'on ne sait pas ce que peuvent donner certaines instructions une fois exécutées, mais on ne peut pas dire gd-chose de plus : rien ne dit qu'elles sont là pour être exécutées, par exemple.

Pollux
:

Et puis bsr+rts, c'est loin d'être marqué indéfini ou transformable en bra par le 68k

Si tu ne veux pas cette optimisation, tu ne l'actives pas. C'est comme pour toutes les autres optimisations.

Et c'est désactivé par défaut, donc ? (y compris dans l'IDE)

Ben non, l'IDE met les optimisations par défaut. Il y a aussi -Os qui est mis pour le C. C'est à toi de les désactiver.

Et sache aussi que A68k optimise même par défaut (par exemple pour les addq, il y a même certain de ce code qui est de toi!), tu dois passer le switch -n explicitement si tu ne veux pas de ça.