Prerelease de GCC 3.3 pour TIGCC - Page 1

J'ai rendu disponible un prerelease de GCC 3.3 pour TIGCC, pour vous permettre de le tester. http://tigcc.ticalc.org/gcc33/.

Les avantages c'est quoi ?

Si tu lisais la page, tu le saurais:

For what's new, see http://gcc.gnu.org/gcc-3.3/changes.html. There were also some generic optimizer improvements, which are not listed, but which do affect compilation of TIGCC programs in a positive way.

Et avant que tu râles pour les extensions supprimées:

Note that the extension "typedef foo = bar" was already officially removed in GCC 3.2.1, and was technically removed since GCC 3.0 already (since each
use of that extension caused an internal compiler error), so it is not actually a problem in GCC 3.3. Also note that, as I said above [sur la page du lien du message d'origine], and as I already promised a long time ago, multi-line string literals are reenabled by the TIGCC patch.

Je ne comprend pas ton extension
typedef foo = bar
c'est pareil que
typedef bar foo
?

Non, dans GCC 2.95, on pouvait écrire:
int bar;
typedef foo=bar;
au lieu de:
int bar;
int foo;

GCC 3.x n'accepte plus cela. Ça donnait une erreur interne dans GCC 3.0-3.2, et ça donne une erreur normale dans GCC 3.2.1-3.3.

Mais de toute façon, le seul usage pratique de cette extension est dans des macros, et on peut utiliser ça à la place:
int bar;
typedef typeof(bar) foo;

Heu,
int bar; typedef foo=bar;
C'est bien équivalent à
int bar; typedef bar foo;
non

Ha non, j'ai compris !
Bon, pas grave qu'elle soit supprimée : c'était une extension ésotérique comme la majorité de celles que ne supporte pas GTC

Non, int bar; typedef bar foo; est une erreur de syntaxe avec tous les compilateurs que je connais. Tu ne peux mettre qu'un nom de type là où tu as mis bar, pas un nom de variable.

Post croisé.

Je viens de sortir un nouveau prerelease qui corrige un bogue grave avec SYMSTR: la conversion en SYMSTR_CONST ne marchait pas du tout. Non seulement elle ne fonctionnait pas, mais en plus elle donnait du code qui plantait. C'est corrigé. Je remercie TRgenius pour avoir testé le prerelease et signalé ce bogue.

Je viens de tester cette nouvelle release, et aucun problème détecté sur aucun de mes programmes ! Je gagne même de la place, 70 octets par librairie Flib par exemple, ce qui est loin d'être négligeable surtout que TIGCC 0.94 avait déjà permis des gains de place.
Quelques warnings pointilleux en plus quand même.

Pourrais-tu préciser les warnings exacts que tu as eu en plus s'il te plaît?

Nouveau prerelease, qui corrige un bogue qui "optimisait" SYMSTR en du code incorrect.

Déjà, il est plus pointilleux lors de comparaisons signed/unsigned.
Ensuite :
SetIntVec(AUTO_INT_1, DUMMY_HANDLER) ; -> dereferencing type-punned pointeur will break strict antialising rules

Peut-être d'autres, je suis pas sûr.

FL
a écrit : Déjà, il est plus pointilleux lors de comparaisons signed/unsigned.

Et il a raison de l'être, tu peux faire pas mal de bêtises avec ça.

Ensuite : SetIntVec(AUTO_INT_1, DUMMY_HANDLER) ; -> dereferencing type-punned pointeur will break strict antialising rules

C'est un problème des headers de TIGCCLIB. Le problème existe avec toutes les versions 3.x de GCC (même s'il n'y a pas de warning), mais il ne peut être corrigé facilement qu'avec GCC 3.3. (Les versions précédentes de GCC ne comprennent pas l'attribut may_alias.) Voici le patch à appliquer:

diff -Naur Include.old/C/gray.h Include/C/gray.h
--- Include.old/C/gray.h        Mon Dec 16 02:00:34 2002
+++ Include/C/gray.h        Thu Dec 26 21:38:02 2002
@@ -47,7 +47,7 @@
 enum GrayPlanes{LIGHT_PLANE=0,DARK_PLANE=1};
 #ifndef __HAVE_INT_HANDLER
 #define __HAVE_INT_HANDLER
-typedef struct{short foo;}_DEREF_INT_HANDLER,*INT_HANDLER;
+typedef struct{short foo;}__attribute__((__may_alias__))_DEREF_INT_HANDLER,*INT_HANDLER;
 #endif
 #define GrayAdjust(x) ((void)(*(volatile unsigned char*)0x600013=128-(signed char)(x)))
 #define GrayCheckRunning() (!!__gray_handle)
diff -Naur Include.old/C/intr.h Include/C/intr.h
--- Include.old/C/intr.h        Mon Dec 16 02:00:40 2002
+++ Include/C/intr.h        Thu Dec 26 21:38:16 2002
@@ -19,7 +19,7 @@
 #endif
 #ifndef __HAVE_INT_HANDLER
 #define __HAVE_INT_HANDLER
-typedef struct{short foo;}_DEREF_INT_HANDLER,*INT_HANDLER;
+typedef struct{short foo;}__attribute__((__may_alias__))_DEREF_INT_HANDLER,*INT_HANDLER;
 #endif
 enum IntVecs{AUTO_INT_1=0x64,AUTO_INT_2=0x68,AUTO_INT_3=0x6C,AUTO_INT_4=0x70,AUTO_INT_5=0x74,AUTO_INT_6=0x78,AUTO_INT_7=0x7C,TRAP_0=0x80,TRAP_1=0x84,TRAP_2=0x88,TRAP_3=0x8C,TRAP_4=0x90,TRAP_5=0x94,TRAP_6=0x98,TRAP_7=0x9C,TRAP_8=0xA0,TRAP_9=0xA4,TRAP_10=0xA8,TRAP_11=0xAC,TRAP_12=0xB0,TRAP_13=0xB4,TRAP_14=0xB8,TRAP_15=0xBC,INT_VEC_RESET=0x04,INT_VEC_BUS_ERROR=0x08,INT_VEC_ADDRESS_ERROR=0x0C,INT_VEC_ILLEGAL_INSTRUCTION=0x10,INT_VEC_ZERO_DIVIDE=0x14,INT_VEC_CHK_INS=0x18,INT_VEC_TRAPV_INS=0x1C,INT_VEC_PRIVILEGE_VIOLATION=0x20,INT_VEC_TRACE=0x24,INT_VEC_LINE_1010=0x28,INT_VEC_LINE_1111=0x2C,INT_VEC_UNINITIALIZED_INT=0x3C,INT_VEC_SPURIOUS_INT=0x60,INT_VEC_KEY_PRESS=0x68,INT_VEC_LINK=0x70,INT_VEC_ON_KEY_PRESS=0x78,INT_VEC_STACK_OVERFLOW=0x7C,INT_VEC_INT_MASK=0x84,INT_VEC_MANUAL_RESET=0x88,INT_VEC_OFF=0x90,INT_VEC_SELF_TEST=0xA8,INT_VEC_ARCHIVE=0xAC,INT_VEC_ER_THROW=0xBC};
 #define AUTO_INT(IntNo) ((long)(IntNo)*4+0x60)

??? comment ces lignes pourraient poser problème? (tant qu'on ne fait pas de #undef __HAVE_INT_HANDLER bien sûr )

Lis l'entrée -fstrict-aliasing de http://gcc.gnu.org/onlinedocs/gcc-3.2.1/gcc/Optimize-Options.html et compare avec la définition de GET_INT_VEC et de SET_INT_VEC pour voir ce qui cloche.

ah pardon je croyais que ct un pb de redéfinition de type... désolé

Nouveau prerelease, qui:
1. rajoute le support pour la prise d'adresse de fonctions imbriquées (c'est la première version de GCC pour TIGCC à réellement permettre cela - toutes les autres causaient un plantage certain sur HW2 AMS 2 sans HW2Patch). Pour que ça marche, il faut que le programme soit exécuté à partir de l'espace fantôme. Solutions possibles:
- EXECUTE_IN_GHOST_SPACE
- compression ExePack
- utilisation de ttstart par l'utilisateur (*)
- utilisation de h220xTSR par l'utilisateur (*)
(* Il est déconseillé de se fier de cela. Utilisez #define EXECUTE_IN_GHOST_SPACE si votre programme n'est pas compressé. Ça ne prend que 140 octets.)
Vous receverez un warning à ce sujet. Je compte rajouter une option pour pouvoir désactiver ce warning plus tard.
2. corrige des problèmes avec la vérification des chaînes de format de printf.

C'est disponible à l'endroit habituel.

Ça permet de faire quoi les fonctions imbriquées ?

pas grand chose (et en tout cas rien qui ne puisse se faire avec les structures)

jackiechan
a écrit : Ça permet de faire quoi les fonctions imbriquées ?

Ça permet d'utiliser les variables locales d'une fonction dans une autre (en la rendant une sous-fonction de la fonction dont on veut utiliser les variables locales).

il y avait un exemple de ça dans la faq, à l'entrée InputStr, non ?
(enfin, il me semblait)

sinon (je pose la question ici, histoire de pas creéer un topic pr juste une question ), tu (Kevin) avais parlé il y a quelques temps de C++ pr TI...
c'est un projet sérieux ?
il permettrait de faire quoi ? tout ce que le C++ permet ?
c'est pr qd ? (C++ interessant, tout ça )

Aucune idée, on n'y est pas encore. Pour l'instant, Stéphane Akhoun travaille sur l'Objective-C vu que c'est plus simple (il n'y a que très peu de patches à faire), mais son but ultime est le C++. Et il travaille en même temps sur l'IDE pour Linux, donc il en a du travail à faire.

squale92 a écrit :
il y avait un exemple de ça dans la faq, à l'entrée InputStr, non ? (enfin, il me semblait)

Oui. L'ancienne entrée de la FAQ (avant la version 0.94 finale) fonctionne maintenant correctement à condition de rajouter #define EXECUTE_IN_GHOST_SPACE. Et il y a un warning à ce sujet ("Execution from ghost space required when taking the address of a nested function.").

Et franchement, je n'en ai rien à battre de l'Objective-C et du C++. Je déteste ces langages lourds. Par exemple, selon Stéphane Akhoun, le runtime Objective-C fait 50 KO! Bonjour le "Hello, World!" de 64 KO...

OK, merci

ma foi, moi, le C++, j'aime bien...
je trouve bien pratique l'orientation objet

on verra ce que ca donnera comme taille de programme. Ca sert à rien si tu perd trop de place par rapport au C

oué, clair

Kevin> le "objective-C", c du C orienté Objet ?
(le language intermédiaire dans le temps entre le C et C++ ?)

squale92 a écrit :
Kevin> le "objective-C", c du C orienté Objet ?

Oui, c'est du C avec un peu de Smalltalk dedans.

(le language intermédiaire dans le temps entre le C et C++ ?)

Ce n'est pas vraiment un intermédiaire entre le C et le C++, la syntaxe est très différente de celle du C++. Personnellement, je n'ai pratiquement pas touché à l'Objective-C, mais en voyant des exemples, je trouve la syntaxe du C++ bien plus logique. Mais il y a des passionnés d'Objective-C qui trouvent que c'est nettement mieux que le C++.

OK...