Prerelease de GCC 3.3 pour TIGCC - Page 6

EvaSDK
: euh j'ai pas trouvé de version linux sur la page, faut la faire soi-même ?

Oui, désolé, je n'ai pas vraiment le temps de compiler les 2 versions ni l'espace web pour les mettre. Donc vu que:
* les utilisateurs de Windows sont majoritaires
* la compilaton à partir des sources est plus simple sous Linux que sous Windows
je mets les binaires Windows.

Je devrais quand-même donner les instructions pour compiler:
* Configuration: Voilà ce que j'utilise pour Windows:
../gcc-3.3.1-20030623-src/configure --host=mingw32 --target=m68k-coff --with-gnu-as --with-gnu-ld --disable-nls --disable-multilib --disable-shared --enable-static --disable-threads --disable-win32-registry
(rajoute --prefix=/usr/local/tigcc et supprime --host=mingw32 pour la version Linux)
* Si tu utilises mes sources réduites au minimum, remplace tous les makefiles de 0 octets (il devrait y en avoir un dans libiberty/testsuite et un autre dans gcc/fixinc) par un makefile avec comme seule ligne:
all:
* Compilation:
make CFLAGS='-Os -s -fno-exceptions'
(mets les flags que tu veux, ce ne sont que ceux que j'utilise; -fno-exceptions ne devrait pas être nécessaire sous Linux, ce n'est que MinGW qui met du code pour gérer les exceptions C++ même dans les programmes C si on ne met pas ce flag)
* Tu copies cc1 vers /usr/local/tigcc/bin/cc1 et xgcc vers /usr/local/tigcc/bin/gcc, et tu peux supprimer /usr/local/tigcc/bin/cpp0 qui n'est plus utilisé.

ok merci.
euh pour information, tu met combien de temps à compiler la version linux ?
parce que ça me dérange pas de le faire, mais avec un K6II 233 faut que je vois combien de temps ça va mettre
(déjà qu'il met un jour pour mozilla...)

Vu ton processeur, j'estime que ça va te prendre 1 ou 2 heures probablement. Moi, ça me prend (à peu près - je n'ai jamais chronométré de manière exacte) 15-30 minutes sous Linux (30-60 sous Windows parce que MSYS est lent ) avec mon PIII 733.

ah ben ça va, je m'attendais à pire.
merci

Kevin Kofler> ce n'est pas vraiment une solution, mais si ça peut te dépanner, j'ai pas mal d'espace libre sur mon compte wanadoo.
Je peux héberger la version linux, si tu veux.

Nouveau prerelease (pre18):
* Multiplications and divisions are now done using smaller sequences (using the dedicated multiplication/division instructions) when -Os is given.

jackiechan :
Kevin Kofler> ce n'est pas vraiment une solution, mais si ça peut te dépanner, j'ai pas mal d'espace libre sur mon compte wanadoo. Je peux héberger la version linux, si tu veux.

Mais il faudrait déjà que je la compile. Comme déjà dit, je n'ai pas vraiment le temps de tout compiler 2 fois.

Kevin Kofler :
Nouveau prerelease (pre18):
* Multiplications and divisions are now done using smaller sequences (using the dedicated multiplication/division instructions) when -Os is given.

PS: Au cas où ça pourrait déranger certains, lisez ça s'il vous plaît: http://pub26.ezboard.com/ftichessteamhqfrm10.showMessageRange?topicID=86.topic&start=106&stop=107.

T'as pas le temps de compiler 2 fois ?

Tout le temps que tu passes à rédiger des posts de 65536 lignes pour faire chier PpHd à propos de PedROM... j'imagine que tu peux lancer une compilation pendant que tu lis ses posts et que tu tapes tes réponses...

Non, la compilation prend un grand pourcentage CPU.

heureusement que ça l'empêche pas de faire tourner X xmms anjuta Tilp et opera, parce que sinon, je me ferais chier

Bon, il est vrai que sous Linux, ça marche mieux, et la consommation CPU est beaucoup plus acceptable sous Linux. (MSYS m'énerve de plus en plus. ) Si seulement je n'avais pas la flemme de rebooter tout le temps.

ben pourquoi tu reste pas sous linux ?

Parce qu'il faut bien que je compile des binaires Win32, sinon pratiquement personne ne va tester mes prereleases.
Et je n'ai pas vraiment envie d'essayer de compiler en "canadian cross" (compiler un compilateur MinGW->m68k sous Linux) parce que c'est là où il y a le plus de bogues d'habitude. Et aussi parce que ça empêche de tester correctement.

ah oui, vu comme ça...

Bon, je vais sortir une version je pense définitive de mes programmes, et j'avais envie de les compiler avec ce qu'il y a de mieux...
Et effectivement, ces dernières images de GCC font vraiment bien au niveau de la taille !
Je n'ai eu aucune erreur à la compilation, et aucun problème après quelques tests rapides, cool

EvaSDK > Moi je l'ai compilé sur mon P100 et ça n'a pris qu'une heure à peine si je me souviens bien (enfin, peut-être que je me souviens mal, mais en tout cas j'avais trouvé ça impressionnamment rapide)

avec linux ?

oui

Ça va nettement plus vite quand on a le shell en natif. MSYS ou Cygwin rament énormément. Et en plus Windows 9x/Me est excessivement lent pour créer de nouveaux processus, et les shell-scripts font ça sans arrêt. (Je pense qu'un shell avec les commandes *nix les plus importantes en interne pourrait accélérer ça de beaucoup.) Bref, la compilation sous Linux est de loin plus rapide que sous Windows.

Kevin Kofler
: Je pense qu'un shell avec les commandes *nix les plus importantes en interne pourrait accélérer ça de beaucoup.

BusyBox ?

Je connais, mais est-ce que ça lance aussi les trucs comme cp, ls etc. directement ou est-ce que ça forke un autre processus? Et puis, je pense que ça ne va pas marcher sans modifications avec MSYS.

A mon avis il va quand même forker pour lancer ses processus (à vérifier), mais ça reste quand même facilement modifiable.

Tiens, salut FL !
En effet, si tu veux faire des releases définitives, il faut qu'elles soient bien faites...

Kevin> je viens de tester la pre18 sur la nouvelle version de KII (arf, j'ai un peu trainé entre le moment où je l'ai dl et le moment où je l'ai essayée)
j'ai un warning que je n'avais pas avec la 0.94 sp 3 ou 4 je sais pas trop :

SetIntVec(AUTO_INT_1, DUMMY_HANDLER); // Sous TIGCC pre18, ceci génére un warning "Deferencing type-punned pointer will break strict-aliasing rules" (warning qui disparait si on utilise -fno-strict-aliasing... mais utiliser cette option augmente la taille du programme (dans les 400 octets en plus, sur en gros 31ko de programme, du moins en -O2))

(en esperant que je n'ai pas une paire de versions de retard )

visiblement je crois que la réponse à déjà été donné plus haut. il faut modifier 2 fichiers (j'ai la flemme de chercher)

./176> arf, ok.
(j'ai pas lu au dessus du post 155, qui annonce la sortie de la pre18, ou alors, ça date de longtemps... toujours est-il que je ne m'en souvenais pas)

enfin, pour les versions de développement, perdre 400 octets n'est pas bien génant...
et pour la version finale, au pire, je laisserai le warning sans y préter attention

squale92 :
Kevin> je viens de tester la pre18 sur la nouvelle version de KII (arf, j'ai un peu trainé entre le moment où je l'ai dl et le moment où je l'ai essayée)
j'ai un warning que je n'avais pas avec la 0.94 sp 3 ou 4 je sais pas trop :

SetIntVec(AUTO_INT_1, DUMMY_HANDLER); // Sous TIGCC pre18, ceci génére un warning "Deferencing type-punned pointer will break strict-aliasing rules" (warning qui disparait si on utilise -fno-strict-aliasing... mais utiliser cette option augmente la taille du programme (dans les 400 octets en plus, sur en gros 31ko de programme, du moins en -O2))

(en esperant que je n'ai pas une paire de versions de retard )

Non, on en est bien à la pre18.

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

Pour le warning, ça a été dit et redit, ici comme sur le forum de la TICT

oops

merci pr la solution de correction

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 ?)
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...