TIGCC 0.95 Beta 6 - Page 11

Poste le code exact, sinon il pourra pas repondre.

Et ça sent le cast vers float/double qui manque...

Pollux
: Et ça sent le cast vers float/double qui manque...

non, même en mettant un double derrière...

une erreur :

return negative ? (double)-HUGE_VAL : (double)HUGE_VAL;

sachant que HUGE_VAL est POSITIVE_INF qui est défini par :
#define POSITIVE_INF (*(float*)&(bcd){0x7FFF,0xAA00BB0000000000})

Même erreur avec NAN.

Sinon, j'ai des erreurs de links : Symbol 'xxx\tigcc\Lib\tigcc.a_stl3' too far for size 2 reloc at 0x3A

C'est pas normal, au hasard ?

Non. Essaye
#define HUGE_VAL (1.0/0.0).

Sinon GCC dispose aussi de __builtin_HUGE_VAL__ je crois.

PpHd> ton HUGE_VAL doit valoir UNSIGNED_INF... p-ê que #define HUGE_VAL 1.0e+12345 marcherait mieux ?

PpHd :
Non. Essaye
#define HUGE_VAL (1.0/0.0).
Sinon GCC dispose aussi de __builtin_HUGE_VAL__ je crois.

Bon, j'ai changé ça et... ça marche. Ne reste que NAN...

Quant à l'erreur de link, c'est peut-être dû à la taille que ça prend ? - 340 ko !!! -

Nan est aussi 0.0/0.0

Ca marche efectivement. Ne reste plus qu'à réussir à tout linker - les changements de dossier sont pour l'instant impossible, mais c'est pour voir simplement -

Miles :
sachant que HUGE_VAL est POSITIVE_INF qui est défini par :
#define POSITIVE_INF (*(float*)&(bcd){0x7FFF,0xAA00BB0000000000})
Même erreur avec NAN.

Mets à jour TIGCC, tu as une vieille bêta.
Maintenant, il y a:
#define POSITIVE_INF (1/POSITIVE_ZERO)
#define POSITIVE_ZERO (1.e-8192*1.e-8192)
et le compilateur calcule le tout en temps de compilation (ne change pas juste le header, il te faut aussi le GCC de la bêta la plus récente):
1.e-8192*1.e-8192 -> underflow -> +0
1/(+0)=+∞

Sinon, j'ai des erreurs de links : Symbol 'xxx\tigcc\Lib\tigcc.a_stl3' too far for size 2 reloc at 0x3A

C'est pas normal, au hasard ?

Ce n'est certainement pas normal. Essaye avec la bêta la plus récente (bêta 6).

PpHd :
Non. Essaye #define HUGE_VAL (1.0/0.0).

C'est faux. Tu calcules UNSIGNED_INF là, pas POSITIVE_INF.

Sinon GCC dispose aussi de __builtin_HUGE_VAL__ je crois.

Mais pas TIGCC. Les builtins float ne sont pas implémentés pour notre format.

Kevin Kofler
:

Miles :
sachant que HUGE_VAL est POSITIVE_INF qui est défini par :
#define POSITIVE_INF (*(float*)&(bcd){0x7FFF,0xAA00BB0000000000})
Même erreur avec NAN.

Mets à jour TIGCC, tu as une vieille bêta.
Maintenant, il y a:
#define POSITIVE_INF (1/POSITIVE_ZERO)
#define POSITIVE_ZERO (1.e-8192*1.e-8192)
et le compilateur calcule le tout en temps de compilation (ne change pas juste le header, il te faut aussi le GCC de la bêta la plus récente):
1.e-8192*1.e-8192 -> underflow -> +0
1/(+0)=+∞

Sinon, j'ai des erreurs de links : Symbol 'xxx\tigcc\Lib\tigcc.a_stl3' too far for size 2 reloc at 0x3A

C'est pas normal, au hasard ?

Ce n'est certainement pas normal. Essaye avec la bêta la plus récente (bêta 6).

Comme tu as pu voir dans le forum de la T3, ce sont les headers de DeDroM, et non de TIGCC que j'utilise.
Par ailleurs, il s'agit biende la dernière version, mais tu as souligné le fait que le fichier est vraissemblablement beucoup trop gros
Faudra que je le coupe avec des libs dynamiques...

Miles
: Comme tu as pu voir dans le forum de la T3, ce sont les headers de DeDroM, et non de TIGCC que j'utilise.

Bon, le header de PpHd n'est pas à jour, plains-toi chez lui. Les headers de PedroM ne sont pas supportés par l'équipe de TIGCC.
Et puis il faudrait aussi le préciser la prochaine fois.

Kevin Kofler
:

Miles
: Comme tu as pu voir dans le forum de la T3, ce sont les headers de DeDroM, et non de TIGCC que j'utilise.

Bon, le header de PpHd n'est pas à jour, plains-toi chez lui. Les headers de PedroM ne sont pas supportés par l'équipe de TIGCC.
Et puis il faudrait aussi le préciser la prochaine fois.

désolé

Mais théoriquement, une nouvelle version de PeDroM est en préparation...

www.timetoteam.fr.st

Martial >
Oui, plutôt oui. ^^

./311: Pkoi c'est unsigned inf ? Il y a une raison ?

Parce que 0.0 est UNSIGNED_ZERO.
Les floats IEEE ne connaissent que 2 zéros, donc ton code fonctionnerait en IEEE. Mais les floats AMS connaissent 3 zéros.
Idéalement, je trafiquerais le parseur GCC pour qu'il traîte les expressions +0.0 et -0.0 spécialement (actuellement, +0.0==0.0==UNSIGNED_ZERO et -0.0==-UNSIGNED_ZERO==UNSIGNED_ZERO). Mais pour l'instant, la méthode des underflows fonctionne pour avoir les zéros signés.

Je proteste : c'est un bug du parseur de GCC !

Ce n'est pas un bogue, c'est qu'il fait exactement ce que le standard C lui demande. Ce que je propose serait une extension. Le problème est que les 3 zéros différents ne sont pas vraiment prévus ni par le C, ni par GCC.

Le standard C ne demande rien a ce sujet.
Je tape tout le temps 1.0/0.0 pour +Inf et -1.0/0.0 pour -Inf et 0.0/0.0 pour NaN.
Et en pratique c'est bien portable qu'utiliser les constantes (bugguees) de math.h/float.h.

Kevin Kofler :
J'ai une idée: Je vais suggérer à Sebastian de passer automatiquement -d à A68k quand l'optimisation des bsr est activée, et ceci à la fois dans l'IDE et dans tigcc.exe. Ça devrait résoudre le problème une fois pour toutes.

C'est implémenté maintenant. (Le switch est également mis lors de la création d'une librairie statique.) La bêta 7 corrigera donc ce problème.

Moi j'ai droit a un "adding programm startup code to library" ou un truc du genre quand j'utilise ngetchx(); dans une lib, c'est nomal/grave? et comment l'eviter?

C'est le rajout automatique du in-use bit. Je vais corriger ça. (C'est au kernel de mettre le bit in-use d'une librairie kernel.)
Workaround:
#include <tigcclib.h>
#undef __need_in_use_bit
#define __need_in_use_bit ((void)0)

Ha c'est peut-être a cause de ca que j'avais des problème de lib qui restaient in-use alors qu'elle ne devaient pas normalement.

Patch envoyé à Sebastian:

--- _set_file_in_use_bit.s_	Thu Jul 10 23:51:24 2003
+++ _set_file_in_use_bit.s	Sat Apr 10 19:36:14 2004
@@ -1,4 +1,4 @@
-	.xdef __set_file_in_use_bit,__clear_file_in_use_bit,__set_clear_in_use_bit
+	.xdef __set_file_in_use_bit_AND_NOT___kernel_library_header,__set_file_in_use_bit__,__clear_file_in_use_bit,__set_clear_in_use_bit
 
 | This file requires cleanup code.
 	.xdef __ref_all___complex_main
@@ -8,7 +8,7 @@
 	.xdef __ref_all___save_d3d5
 
 .section _st87
-__set_file_in_use_bit:
+__set_file_in_use_bit__:
 | First, look for the current address.
 	lea.l (%pc),%a1
 	move.l %a1,%d4

Le problème sera corrigé dans la prochaine bêta.

Uther
: Ha c'est peut-être a cause de ca que j'avais des problème de lib qui restaient in-use alors qu'elle ne devaient pas normalement.

Normalement, ce code n'est pas appelé du tout pour une librairie, il gaspille juste de la place.

Normalement, ce code n'est pas appelé du tout pour une librairie.

Arf alors c'est de ma faute j'ai encore pas mal de boulot de debuggage