Deux possibilités... - Page 1

Ou bien je deviens fou, ou bien y'a un truc qui cloche.
Voici une superbe boucle extremement complexe :

		for (i = anmIndex; i--; )
		{
			printf("Anm=%d",anmIndex);
		}

anmIndex vaut 0 avant la boucle, et heu... Ben ça m'affiche 0
Et évidement, si je la retourne (for (i = 0; i < anmIndex; i++)), ça marche sans problème. J'aurais bien voulu essayer avec GTC, mais il refuse de compiler à cause de certaines fonctions.
Donc soit y'a une erreur toute conne et que qqun va voir au 1er coup d'oeil, mais vu la taille de la partie qui pose pb, j'ai des doutes, soit y'a un truc qui m'échappe là...

for (i = anmIndex; i--;)
{
printf("Anm=%d",anmIndex); }

Que viens faire un i-- dans une condition? Essaye dans ce cas --i!

geogeo... J'attendais des réponses serieuses
Si anmIndex vaut 0 initialement, i-- est évalué, vaut 0, donc la boucle n'est pas executée. Maintenant merci de ne plus répondre dans ce topic si t'es pas certain d'avoir une explication.

[edit] Ah oui le détail amusant, c'est que j'ai la boucle à plusieurs endroits de la source, et qu'ailleurs elle marche.

Bon... Alors après tests, c'est marrant ça dépend des sources. Un coup ça marche, un coup ça marche pas #youpi#


[edit 1] Bon, autre chose

#include <tigcclib.h>

void _main(void)
 {
 unsigned short i;
 
 for (i = 0; i--; ) printf("1");
 ngetchx();
 }

Compilé avec TIGCC, ça m'affiche 1. Compilé avec GTC, ça n'affiche rien


[edit 2] Allez encore un plus flagrant :

void _main(void)
 {
 unsigned char i, str[6];
 unsigned short c = 0;
 
 for (i = 0; i--; ) c++;
 sprintf(str,"%u",c);
 ST_helpMsg(str);
 }

TIGCC affiche 1
GTC affiche 0

Voilà le code generé par TIGCC :

__main:
	lea (-12,%sp),%sp
	move.l %d3,-(%sp)
	move.l 200.w,%a0
	move.l 332(%a0),%a0
	move.w #1,-(%sp)
	pea .LC0
	moveq.l #12,%d3
	add.l %sp,%d3
	move.l %d3,-(%sp)
	jbsr (%a0)
	move.l 200.w,%a0
	move.l %d3,-(%sp)
	move.l 920(%a0),%a0
	jbsr (%a0)
	lea (14,%sp),%sp
	move.l (%sp)+,%d3
	lea (12,%sp),%sp
	rts

-

Normalement j'ai le GCC qui est livré avec TIGCC 0.95b4.

-

C'est une optimisation (qui déconne apparemment): une boucle exécutée exactement 1 fois est déroulée, qu'on optimise en taille ou non. Apparemment, il la déroule mal. Je vais analyser le problème.

Bogue confirmé en -Os avec tous les 2 test cases. -O0 et -O2 fonctionnent.

Et il s'agit dans les 2 cas de boucles exécutées 0 fois, donc qui devraient être supprimées complètement, pas déroulées 1 fois, mais qui sont déroulées 1 fois par erreur.

Hmm ok... En fait GCC a du voir que "anmIndex" était initalisée à 0 et jamais modifiée, donc il a foiré son optimisation. Y'a une nouvelle version de prévue qui corrige le bug ?

Au cas où ce n'était pas évident: les dumps RTL confirment que c'est la passe 12.loop qui fait n'importe quoi.
La structure de la boucle est différente en mode -O2 (c'est notre patch pour économiser de la taille dans les boucles en -Os qui fait ça), ce qui fait que la boucle est déjà éliminée en la phase 09.cse, donc que le problème ne se pose pas.
Bref, une de ces 2 passes a besoin d'être corrigée.

Vertyos
: Hmm ok... En fait GCC a du voir que "anmIndex" était initalisée à 0 et jamais modifiée, donc il a foiré son optimisation. Y'a une nouvelle version de prévue qui corrige le bug ?

C'est un bogue spécifique à TIGCC. Je vais m'occuper de ce problème.

Bon ben en attendant, -> GTC

Il y a plus simple comme workaround: déclare i en volatile, ça empêche l'optimisation qui déconne.

Et le problème est que le nombre d'itérations est calculé de manière incorrecte:
Loop unrolling: 1 iterations.
C'est faux, il y a 0 itération.
Reste à savoir où est fait le calcul et pourquoi GCC se trompe.

C'est la fonction loop_iterations de unroll.c qui fait le calcul incorrect. Je suis en train de déboguer la fonction.

Corrigé par:

--- unroll.c_   Fri Jun 27 19:33:38 2003
+++ unroll.c    Sun Dec 28 22:34:10 2003
@@ -3921,6 +3921,18 @@
      (abs_diff + abs_inc - 1) / abs_inc, provided care was taken to
      handle potential overflow of the summation.  */
   loop_info->n_iterations = abs_diff / abs_inc + ((abs_diff % abs_inc) != 0);
+
+  /* (TIGCC 20031228) If the first instruction in the loop is a jump to cont,
+                      then we actually have 1 iteration less. -- Kevin Kofler */
+  if (loop->cont) {
+    rtx first_loop_insn = NEXT_INSN (loop->start);
+    if (GET_CODE (first_loop_insn) == JUMP_INSN
+        && INSN_LUID (JUMP_LABEL (first_loop_insn))
+           == INSN_LUID (NEXT_INSN (loop->cont))) {
+      loop_info->n_iterations--;
+    }    
+  }
+
   return loop_info->n_iterations;
 }
 

Reste à corriger le problème de l'optimisation (suppression totale de la boucle) ratée, mais c'est un problème d'optimisation, pas un bogue évident comme celui que je viens de corriger.

Mise à jour du patch qui corrige aussi le problème d'optimisation. Maintenant, la boucle est supprimée s'il n'y a aucune itération.

--- unroll.c_   Fri Jun 27 19:33:38 2003
+++ unroll.c    Sun Dec 28 22:53:08 2003
@@ -3921,6 +3921,23 @@
      (abs_diff + abs_inc - 1) / abs_inc, provided care was taken to
      handle potential overflow of the summation.  */
   loop_info->n_iterations = abs_diff / abs_inc + ((abs_diff % abs_inc) != 0);
+
+  /* (TIGCC 20031228) If the first instruction in the loop is a jump to cont,
+                      then we actually have 1 iteration less.
+                      And if we end up with no iteration at all, delete the jump
+                      at the end of the loop so the dead code elimination passes
+                      will eliminate the useless loop. -- Kevin Kofler */
+  if (loop->cont) {
+    rtx first_loop_insn = NEXT_INSN (loop->start);
+    if (GET_CODE (first_loop_insn) == JUMP_INSN
+        && INSN_LUID (JUMP_LABEL (first_loop_insn))
+           == INSN_LUID (NEXT_INSN (loop->cont))) {
+      loop_info->n_iterations--;
+      if (!loop_info->n_iterations)
+        delete_related_insns (last_loop_insn);
+    }    
+  }
+
   return loop_info->n_iterations;
 }
 

Temps écroulé entre le report et la correction du bogue: moins de 5 heures.
Vertyos, si tu veux une mise à jour de GCC expédiée par mail, c'est possible dès maintenant. (Et en tout cas, ça sera pour la prochaîne bêta, évidemment.)
Ne vous attendez pas à un tel temps de réponse pour GTools Compiler.

Heu oui je veux bien, merci

-> vertyos [at] fr.st

C'est envoyé.

Reçu, merci

Vertyos> Pourquoi tu n'as pas écrit vertyos [at] fr.st ? (voire même vertyos [at] fr.st)

[Vertyos] Edité, cf. post en dessous

Dans le doute, tu peux au moins ne pas le faire toi ?
Si par hazard y'a des bots qui trainent sur yAronet, j'ai pas envie de me faire ramasser mon mail et de recevoir de la pub...

Ah ok.
Merci
Désolé

Pas grave
Bon, le topic ne sert plus (on notera la réponse bien à coté de la plaque de geogeo, comme d'habitude )


napu