Prerelease de GCC 3.3 pour TIGCC - Page 7

Sally Brown
: Kevin : ce n'est pas tout à fait dans le sujet, mais est-ce que ça t'intéresserait que je corrige le tigcc frontend pour linux (notamment la ligne de commande de gcc copiée dans un buffer de taille 256 sans aucune vérification ?)

Oui. (Je voulais le faire moi-même, mais j'ai été occupé avec pas mal d'autres trucs, surtout pour TIGCC 0.95. Donc je n'ai encore rien changé par rapport à la release 0.94 SP4 r1, et j'accepte les patches.)
Attention, si c'est pour remplacer le buffer de taille 256 par un buffer de taille 1024 ou 2048, ce n'est pas la peine. Il faudra allouer des buffers de la bonne taille.

Je pose la question parce que si tu refais entièrement le frontend pour tigcc 0.95 ça ne vaut peut-être pas la peine de corriger la version précédente...

Je vais devoir réécrire certains trucs (la phase de linking en particulier), mais je ne compte pas tout réécrire.

si c'est pour remplacer le buffer de taille 256 par un buffer de taille 1024 ou 2048, ce n'est pas la peine.

Et si je mets 65536 ? non je blague
Ben ça ne sera pas la semaine prochaine (je suis en vacances) mais je vais tâcher de faire ça dans le courant de la suivante, je t'enverrai le patch.

La suivante, c'est moi qui serai en vacances... Et les 2 semaines d'après aussi.

Bon ben ce sera pour la rentrée alors.

au fait, j'ai du louper une étape parce que je vois pas trop à quoi il sert le patch si il patch pas les sources au configure (j'ai regarder la commande patch, mais je ne sais pas à quel fichier l'appliquer)

Nouveau prerelease (pre19), qui réduit la taille des switch en mode -Os. Disponible à l'endroit habituel.
Prière de le tester. Ce sera probablement le prerelease qui sera inclus dans TIGCC 0.95 bêta 1.

je suis en train de le télécharger.
je testerai KII et BrEgg1st (enfin, vu le peu que ce truc est commencé, ça va pas être long ) soit qd ça aura fini de dl, soit demain aprem (je commence à fatiguer... et je profite de la semaine qu'il me reste de vacances pr continuer mes grasses matinées )

J'ai compilé Seven Tiles avec gcc 3.3 et je gagne environ 200 octets sur 7300 à l'origine. Par contre ça me rajoutait un warning "dereferencing type-pointer will break strict-aliasing rules" au moment du détournement des vecteurs d'AInts que GCC 3.1 ne me mettait pas, m'enfin c'est pas la mort .

Compilé Vertel 3 en -Os, la taille passe de 7873 à 7645 octets, je vais voir ce qu'il en est pour la vitesse.

[Edit] La vitesse a un tout petit peu diminué, pour ce projet c'est pas grave la taille est prioritaire, mais pour des jeux ça peut être genant.

./188> c'est expliqué plus haut, pour ce probleme ; il faut changer des trucs dans deux headers de tigcc, il me semble
(enfin, il me semble que c qd j'avais ce pb là qu'on m'a fait faire ces correcttions)

en passant de la pre18 à la pre19, aucun changement, que ce soit pour KII ou pour BrEgg1st.
(mais je n'ai qu'une petite partie de chaque projet qui soit en Os)

Ximoon :
J'ai compilé Seven Tiles avec gcc 3.3 et je gagne environ 200 octets sur 7300 à l'origine. Par contre ça me rajoutait un warning "dereferencing type-pointer will break strict-aliasing rules" au moment du détournement des vecteurs d'AInts que GCC 3.1 ne me mettait pas, m'enfin c'est pas la mort .

Argh, je vais piquer une crise...

Kevin Kofler
(./178):
Pour le warning, ça a été dit et redit, ici comme sur le forum de la TICT: C'est un problème des headers de TIGCC 0.94. Le problème existe avec tout GCC 3.x (même si GCC 3.3 est le premier à le reconnaître et t'en avertir), mais la seule correction à la fois simple et propre nécessite GCC 3.3.

Pour une explication détaillée du problème, les méthodes de correction possibles, et le patch à appliquer pour la meilleure méthode de correction, cf.:
http://pub26.ezboard.com/ftichessteamhqfrm10.showMessageRange?topicID=86.topic&start=2&stop=3

J'attends vivement TIGCC 0.95 bêta 1 qui viendra avec des headers à jour!

Vertyos :
Compilé Vertel 3 en -Os, la taille passe de 7873 à 7645 octets, je vais voir ce qu'il en est pour la vitesse.
[Edit] La vitesse a un tout petit peu diminué, pour ce projet c'est pas grave la taille est prioritaire, mais pour des jeux ça peut être genant.

C'est normal. -Os optimise en taille, pas en vitesse, donc c'est un progrès, pas une régression.

Et ceux qui donnent des tailles "avant", si vous pouviez préciser ce qu'est "avant" (GCC 3.2.1-tigcc-2 livré avec TIGCC 0.94 SP4? GCC 3.3.1-tigcc-pre18? Autre 3.3.x?), ça serait bien.

En tout cas c'est vraiment du bon boulot.

Kevin Kofler :
C'est normal. -Os optimise en taille, pas en vitesse, donc c'est un progrès, pas une régression.

Et on fait comment quand on veut un programme rapide sans qu'il devienne monstrueusement gros ?

tigcc masource.c -O3 -Os

avant : 7229 octets / avant: GCC 3.1 avec la 0.94
après : 7037 octets / après: GCC 3.3 dernier cri

(sauf si je me suis emmellé les pinceaux)

Et on fait comment quand on veut un programme rapide sans qu'il devienne monstrueusement gros ?

On ne peut pas tout avoir.

On prend une ancienne version de TIGCC

... ou bien on prend GTC avec le switch -Om J'avais d'ailleurs déjà fait la remarque à Kevin il y a qq jours.

Je pense que en 2042 TIGCC fonctionnera en -Os avec une compression automatique qui va à 100 octets/s en décompression parce que c'est plus efficace comme ça, et en -O2 avec toutes les boucles déroulées jusqu'à ce que le prog atteigne la limite des 64k (un tout petit peu moins qu'en -O3 [qui lui fera automatiquement une DLL pour atteindre la limite des 128k] mais bon ).

[Edit] Arg post croisé, et d'après la 1ere phrase de Pollux, je suis devin ^^

Rah c'est carrément lourd ça. Et paf un argument pour GTC.
(sauf que je pourrais pas compiler mon prog avec, bicause plusieurs .c...)

Bon je garde une vieille version de GCC au chaud sur mon disque dans ce cas

> (sauf que je pourrais pas compiler mon prog avec, bicause plusieurs .c...)
C'est pas parce que GTC ne passe pas par des .o comme fichiers intermédiaires qu'il ne supporte pas d'avoir plusieurs .c

gtc [options] fichier_principal.c moteur.c dessin.c

Hmm hmm ok ok. Reste à voir si il acceptera de compiler, ça non plus c'est pas gagné, surtout si il a fait le difficile avec Einstein

Il doit bien y avoir eu 4 bugs, grand maximum, alors que c'était un des premiers gros progs que je compilais. Mais c'est vrai que la lib n'était pas encore finie (il y a une gestion bcp plus efficace des headers maintenant).

Depuis, j'ai compilé AS et TI-Chess sans aucun pb, et Side en modifiant un petit truc (quand on faisait une déclaration du type char sprite[7]={}, il n'y avait pas de padding, contrairement à ce que fait TIGCC [quelle idée ], donc les caractères apparaissaient mal).

Evidemment, il faut convertir quelques trucs (asm(), long long, nested functions), mais sinon il ne doit pas y avoir d'autre pb.

Pollux
: Depuis, j'ai compilé AS [...] et Side

Cool ça donne quoi niveau taille ?

Pollux #201 : ca permet vraiment une compilation séparée ? C'est à dire que les variables globales / fonctions en static d'un .c sont inaccessibles pour les autres .c ?

Vertyos :
Hmm hmm ok ok. Reste à voir si il acceptera de compiler, ça non plus c'est pas gagné, surtout si il a fait le difficile avec Einstein

GTC avait quand même compilé pas mal de trucs avant Einstein. Einstein est très tordu
Mon shell n'a pas mis à jour beaucoup de vrais bugs dans GTC. La plupart des problèmes venaient de fonctionnalités encore absentes.
Tout est désormais corrigé.

Vertyos
:

Kevin Kofler :
C'est normal. -Os optimise en taille, pas en vitesse, donc c'est un progrès, pas une régression.

Et on fait comment quand on veut un programme rapide sans qu'il devienne monstrueusement gros ?

On ne peut pas. Ce sont des demandes contradictoires.

Et Pollux, tu attends quoi pour implémenter les long long (fonctionnalité du standard ISO C99, je te rappelle)?

Il attend d'avoir le temps. Ok ?

Kevin Kofler
: On ne peut pas. Ce sont des demandes contradictoires.

Paf GCC sux. Non serieusement y'a plein de projets ou je vais devoir garder une ancienne version, c'est lourd...

Je rajouterai que si tu veux du rapide sans consommer trop de place, c'est -O2 normalement. Problème, c'est "rapide sans consommer trop de place", pas "petit sans être trop lent". La nuance est importante. C'est nettement plus gros que -Os en tout cas.

Tu peux aussi essayer des trucs de style -O2 -fno-unroll-loops.