Articles précédents : Logiciel
- [74] Yzis, un nouveau clone de vi
- [36] Sortie de gnuplot 4.0
- [34] Bookcase Bookcase 0.9 - un gestionnaire de collections KDE 3.x
- [40] Sortie de ImageMagick 6.0.0
- [44] PhpCompta 1.0.0 pre Comptabilité GPL
- [21] Gimp 2.0.1 dans les bacs
- [17] Le noyau 2.4.26 est disponible
- [27] Inkscape : nouveau leader open source du dessin vectoriel ?
- [46] Docker 0.14, un gestionnaire de paquets pour Windows
- [3] Release Candidate de Lodel version 0.7
Liens connexes
- GCC (1642 hits)
- Changements (1308 hits)
- Liste des miroirs (485 hits)
- Obsolète (541 hits)
- Liste des corrections (522 hits)
Dépêche modérée par
La liste des changements signale également la suppression des options qui avaient été marquées obsolètes dans la version 3.3.x ou encore des problèmes de compatibilité binaire pour les plateformes SPARC ou MIPS.
![[en]](../../../images/en.png)
GCC (1642 hits)-
Changements (1308 hits)
-
Liste des miroirs (485 hits)
-
Obsolète (541 hits)
-
Liste des corrections (522 hits)
> Lire la suite (136 commentaires, moyenne: 1,8). [dépêche : 351 caractères]
GCJ est également livré avec une version plus récente de GNU Classpath.
La bibliothèque libstdc++ a bénéficié d'améliorations avec notamment la gestion des fichiers de plus de 2 GiB sur système 32 bits.
Une release importante
Pour ceux qui utilisent le C++, ils y a deux points qui me semblent importants:
* La mise en oeuvre des "precompiled headers"
* Une réécriture complète du moteur de parsing du C++
Et bien entendu, une quantité impressionnante de corrections de bugs.
Bravo !
Lucio
-
[^]Re: Une release importante
Posté par lordcow () le 21/04/2004 à 14:11. (lien). Évalué à 3.precompiled headers ou comment diviser par 20 les temps de compilation!
AMHA, c'est une des plus grosses avancees de gcc. Si ca marche comme je l'espere. Tu compile un fois un gros header avec la stl qt et tout le bordel de ton projet, et hop, tes fichiers de 300 lignes se compilent instanements..--
Je est un autre.-
[^]Re: Une release importante
Posté par dcp (page perso, ) le 21/04/2004 à 14:17. (lien). Évalué à 0.Pour l'instant c'est plus une "preview feature".
-
[^]Re: Une release importante
Posté par Philippe Fremy (page perso, ) le 21/04/2004 à 17:28. (lien). Évalué à 3.A noter que sous windows, _sans_ les precompiled header, visual compile deja entre 3 et 10 fois plus vite que gcc sous linux. Ca se sent des qu'on tape sur un gros projet.
Sinon, le but d'etre compatible standard pour etre compatible standard, c'est bof. Comme gcc est le seul compilateur aussi respectueux des standards, si tu ecris du code au poil pour gcc, j'ai peur que ce soit une garantie de peter sur d'autres compilateurs.
Pis le standard C++, c'est quand meme une horreur.-
[^]Re: Une release importante
Posté par lordcow () le 21/04/2004 à 21:14. (lien). Évalué à 2.A noter que sous windows, _sans_ les precompiled header, visual compile deja entre 3 et 10 fois plus vite que gcc sous linux. Ca se sent des qu'on tape sur un gros projet.
VC++ compile tout en meme temps, ca laisse forcement la voie libre a pleins d'optimisations assez simples. genre, si tu as deja vu ce header avec le fichier precedent, hop, tu recupere le code qui est reste en memoire. ( bon, c pas aussi simple, ya des differences de contextes)
Mais bon, avec le systeme de makefile de unix, c'est plus complique a mettre en oeuvre avec gcc)--
Je est un autre.-
[^]Re: Une release importante
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 08:11. (lien). Évalué à 6.Donc en fait, il faudrait passer a un truc plus moderne que les makefile ? Pourquoi pas. Je payerai cher pour me debarasser des autotools et ca ne me generait pas tant que ca d'y inclure les makefile, si on propose un bon systeme equivalent.
Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire. Je m'interroge si c'est le fait que j'ai ose dire que un programme sous windows est mieux qu'un programme sous linux ou simplement que les gens moinssent des qu'ils voient le mot windows.
Dans les autres points ou on est a la rue sous linux, c'est les debuggeurs. On a que gdb et force est d'admettre qu'apres avoir utilise un debuggeur sous d'autre environnements (Visual pour ne pas le citer), on se rend compte que gdb est une bouse. En ce moment, je galere sous un projet parce que gdb refuse de suivre le chemin d'execution. Il me fait du step-by-step dans toutes les fonctions Qt mais zappe allegrement toutes mes fonctions a moi. Une vraie horreur.-
[^]Re: Une release importante
Posté par J A-G () le 22/04/2004 à 08:16. (lien). Évalué à 3....moinssent des qu'ils voient le mot windows.
Tu as raison... et ce n'est certainement pas à cause de ta justification rigolote de ne pas utiliser les standards !-
[+] [^]Re: Une release importante
Posté par Moby-Dik () le 22/04/2004 à 12:41. (lien). Évalué à -1.Si ton programme doit être portable, et que tu colles à mort à un standard qui n'est respecté que par un compilateur, t'as pas l'air con... Faut savoir être pragmatique dans la vie.
-
[^]Re: Une release importante
Posté par Cédric Chevalier (page perso, ) le 22/04/2004 à 14:36. (lien). Évalué à 3.En général les compilateurs sont plus permissifs que le standard.
C'est bien la première fois que j'entends que coder selon les standards (du langage j'entends) rend le code moins portable.
Tu fais comment pour faire du code portable si tu ne suis pas le standard ?
PS : Bon je sais que quand les standards sont trop jeunes, les implémentations sont pas faites etc ... C'est par exemple (rien à voir avec les compilateurs, quoi que) ce qui se passe avec la dernière version du protocole MPI.-
[^]Re: Une release importante
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 15:34. (lien). Évalué à 3.Parfois tu as des compilateurs vraiment pourri. Prenons au hasard Visual C++ (le meme qui est super rapide):
for( int i=0; i<1; i++) do_something();
for( int i=0; i<1; i++) do_something();
Le deuxieme ne va pas compiler ("variable i already declared") car Visual, dans sa magnitude, declare les variables de boucle a l'exterieur de l'espace de la boucle.
Ce cas est un peu extreme mais je suis sur que si tu chatouilles les template, tu es oblige d'ajouter des bugfix un peu partout pour chaque compilateur.-
[^]Re: Une release importante
-
[^]Portée des boucles for
Posté par frecillia6 () le 25/04/2004 à 17:07. (lien). Évalué à 1.En fait dans les première versions de la norme C++, la règle était que la portée d'une variable était le bloc d'accolade englobant, ce qui implique qu'un compilateur conforme au standard devait refuser de compiler ton code ci-dessus.
Comme c'était pas très intuitif,au début des années 90, la norme a été changée pour que les variables déclarées dans un for soient locales à la boucle.
Comme les gens qui ont conçu Visual voulaient garder un maximum de compatibilité avec le vieux code, ils ont fait en sorte que par défaut celui-ci applique l'ancienne règle de portée.
La nouvelle règle est en fait bien présente dans le compilateur mais n'est utilisée que si tu compile avec le flag --ansi.
-
-
-
-
-
[^]Re: Une release importante
Posté par lordcow () le 22/04/2004 à 08:29. (lien). Évalué à 2.Donc en fait, il faudrait passer a un truc plus moderne que les makefile ? Pourquoi pas. Je payerai cher pour me debarasser des autotools et ca ne me generait pas tant que ca d'y inclure les makefile, si on propose un bon systeme equivalent.
Non, je pensait plus a une sorte de gccd qui gèrerait cette cache.
il est lancé en début de makefile avec les options qui vont bien et on remplace $CC par un truc genre gcc-client, qui se connecte au serveur et qui donne le fichier a compiler. Comme ca on garde la gestion des dépendances de makefile tout en pouvant faire des optimisations de caches.
Cela dis, je délire surement totalement..--
Je est un autre.-
[^]Re: Une release importante
Posté par Troy McClure (page perso, ) le 22/04/2004 à 08:35. (lien). Évalué à 1.c'est prévu ! http://gcc.gnu.org/ml/gcc/2003-02/msg01911.html(...)
-
[^]Re: Une release importante
Posté par lordcow () le 22/04/2004 à 11:46. (lien). Évalué à 1.Le mail dont tu parle date d'un an. Des infos sur l'avancement du projet?
J'ai bien peur que ce projet ce soit transformé en "precompiled header support"--
Je est un autre.-
[^]Re: Une release importante
Posté par linuxidable () le 22/04/2004 à 12:18. (lien). Évalué à 1.>J'ai bien peur que ce projet ce soit transformé en "precompiled header support
Je ne pense pas mais chaque chose en son temps, il y a une foule d'évolution qui sont prévues pour gcc. Ce document en est un excellent aperçu :
http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf(...)
Ils y parlent entre-autre du "GCC compile server". L'idée est d'avoir un serveur de compilation (attention, il ne s'agit pas de compilation distribuée) qui compile l'ensemble des modules en gardant en mémoire ce qui a déjà été compilé. Non seulement ça permet d'obtenir des temps de compilation plus court (ils pensent obtenir de meilleurs résultats qu'avec les fichiers d'entête pré-compilé) mais ça permet d'effectuer davantage d'optimisations (comme les fonctions inline inter module). Ils tiennent à ce que la modification du makefile requise pour utiliser cette fonctionnalité soit minime (juste ajouter un paramètre à l'appel de gcc du style --server).
-
-
-
-
[^]Re: Une release importante
Posté par Ayrton () le 22/04/2004 à 09:05. (lien). Évalué à 4.> Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire.
Rappel de ton post :
>> Sinon, le but d'etre compatible standard pour etre compatible standard, c'est bof.
>> Pis le standard C++, c'est quand meme une horreur.
Et
>> Comme gcc est le seul compilateur aussi respectueux des standards, si tu ecris du code au poil pour gcc, j'ai peur que ce soit une garantie de peter sur d'autres compilateurs.
Remplaçons gcc par mozilla et compilateur par navigateur pour voir ce que ça donne :
Comme mozilla est le seul navigateur aussi respectueux des standards, si tu ecris du code au poil pour mozilla, j'ai peur que ce soit une garantie de peter sur d'autres navigateurs.
Le moinsage ne me surprend pas.
> gdb est une bouse.
Utilise les debuggeurs des unix commerciaux (quand il n'utilise pas déjà gdb). La bousse aura soudain un parfum de rose.
Pour moi gdb est la rolls des debuggeurs et ddd est une bonne interface graphique.
Si gdb déconne sur ta distribution, fait un rapport de bug.-
[^]Re: Une release importante
Posté par Moby-Dik () le 22/04/2004 à 12:43. (lien). Évalué à 0.Remplaçons gcc par mozilla et compilateur par navigateur pour voir ce que ça donne :
Une page fonctionnera toujours plus ou moins, en mode dégradé, sur IE ou Opera.
Un source qui ne compile pas, ne compile pas. Il n'y a pas de demie-mesure.-
[^]Re: Une release importante
Posté par Ayrton () le 22/04/2004 à 13:06. (lien). Évalué à 2.Ça n'enlève rien au principe de respecter les standards.
Si tu fais du spécifique icc ou gcc, tu auras encore plus de problème.
Il faut que les compilateur s'alignent. Je préfère qu'il s'alignent sur des standards que le :
- "nivellement pas le bas pour que ça passe partout"
- ou "je code gcc comme un porc car je veux qu'il supporte les saloperies de Visual C".
-
-
[^]Re: Une release importante
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 12:51. (lien). Évalué à 3.Le probleme des standards ne se limite pas a l'axiome "tu dois respecter les standards". Je bosse par exemple dans un milieu (la carte a puce sans-contact) ou les mecs qui ecrivent les standards sont malheureusement un peu trop chercheurs. Ils ont plein de bonnes idees qui sont irrealisables techniquement, mais qui passent dans les standards. Resultat, le standard est impossible a implementer avec la techno d'aujourd'hui.
Par le passe, certains standards ont ete rendus completement obsoletes parce que impossible a implementer. Chacun est partie sur sa solution proprio et il faudra encore quelques annees pour refaire la convergence.
On a aussi eu des standards completement merdique au niveau du protocole.
Bref, implementer le standard est a priori une bonne idee sauf quand ce n'est pas le cas. Quel est l'interet d'un standard si difficile a implementer que personne ne peut le faire avant 10 ans ? Nul. La consequence, c'est qu'on va avoir 10 ans de soi-disant transition pour que les compilateurs rattrappent leur retard sur le standard pas pique des vers. Sauf que les messieurs du standards, parce qu'ils s'ennuient et pour justifier leur salaire, ils continuent a faire evoluer le standard. Donc au lieu de garantir l'interoperabilite comme il devrait le faire, le standard ne fait que mettre un poid sur les developpeurs.
Le probleme est particulierement apparent avec le C++ qui est un langage vraiment trop complexe quand on le creuse bien. Il apparait aussi un peu avec le w3c. Le xhtml c'est bien. Le SVG, c'est une super idee, mais quand on voit la difficulte d'implementation, on peut se questionner aussi. A quoi ca sert de definir une norme aussi difficile a implementer ? Si elle est tres difficile a implementer, elle ne va pas assurer l'interperabilite.
Je prefere de loin l'approche des RFC qui pour obtenir un statut final doivent montrer deux implementations reussies pendant plusieurs mois (c'est l'idee, je ne me souviens plus des details).-
[^]Re: Une release importante
Posté par Éric (Jabber id, page perso, ) le 22/04/2004 à 13:03. (lien). Évalué à 2.> Je prefere de loin l'approche des RFC qui pour obtenir un statut final doivent
> montrer deux implementations reussies pendant plusieurs mois (c'est l'idee, je
> ne me souviens plus des details).
Le coup des deux implémentations est maintenant vrai pour le W3C aussi.-
[^]Re: Une release importante
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 15:46. (lien). Évalué à 1.Bonne nouvelle. Et c'est retro-actif ? J'aimerai bien voir les deux browsers qui supportent parfaitement le SVG.
-
[^]Re: Une release importante
-
[^]Re: Une release importante
Posté par Éric (Jabber id, page perso, ) le 23/04/2004 à 13:27. (lien). Évalué à 1.Il y a largement plus de deux implémentations de SVG correctes. Par contre, effectivement je ne parle pas forcément des browsers.
Coté implémentation il y a un plugin Adobe, il me semble que macromédia (ou une autre boite du même milieu/niveau) a lancé un truc concurent, (le tout est pour MSIE/win, le plugin Adobe est de nouveau compatible mozo win/linux mais sans le support des scripts et des animations, ce qui limite pas mal). Mozilla et Amaya ont un support partiel SVG (qui a été refait récement pour Mozo, mais qui n'est toujours pas activé par défaut). X-SMILE sait faire du SVG à peu près correct.
> Et c'est retro-actif ?
Comment tu veux faire du rétro-actif la dessus ? les normes qui existent existent, je ne vois pas ce qu'ils peuvent en faire d'autre même si les implémentations actuelles ne sont pas complètes/parfaites.
-
-
-
[^]Re: Une release importante
Posté par Ayrton () le 22/04/2004 à 13:26. (lien). Évalué à 4.Je suis d'accord avec toi. C'est le *principe* de respecter les standards qu'il faut retenir. Après, au cas par cas, on respecte ou non les standards. Mais ne pas respecter les standards gratuitement, sans bonnes raisons, est nul.
> Quel est l'interet d'un standard si difficile a implementer que personne ne peut le faire avant 10 ans ?
Ça fait une roadmap pour les 10 ans à venir :-)
Mozilla a mis combien de temps pour respecter les standards ?
Mozilla serait aussi bon si le projet devait aussi faire le travail réalisé par le w3c ?
De plus, qui participe pour faire les standards ? Pour w3c c'est mozilla, etc. Bref ceux qui réalisent des navigateurs et/ou utilisent le web.
> Sauf que les messieurs du standards, parce qu'ils s'ennuient et pour justifier leur salaire, ils continuent a faire evoluer le standard.
Là tu abuses. Il faut toujours un standard d'avance si le standard actuellement utilisé n'est pas satisfesant. Regarde le "merdier" des débuts d'html car il n'y avait pas de standard en avance. Des navigateurs incompatibles, des normes qui sortent à l'arrache pour remettre de l'ordre (html 3.2 et 4).
Maintenant que le w3c a repris de l'avance, tout le monde bossent dans la même direction.
De plus des nouveaux standards qui remplacent l'ancien il n'y en a pas tous les jours (regardes pour le C/C++ et SQL et compte le nombre de standard ANSI par exemple et divise par le nombre d'année).
Enfin, les nouveaux standards font toujours très attentions à la compatibilité. C'est plus rarement le cas des initiatives isolées.
Freedesktop travail pour faire des standards et éviter le bordel et la guerre entre Gnome et KDE.
Les standards c'est bien.-
[^]Re: Une release importante
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 15:39. (lien). Évalué à 1.> Maintenant que le w3c a repris de l'avance, tout le monde bossent dans la même direction.
La, tu as raison, je me suis un peu egare.
Tout ca pour dire que les standards, je suis a fond pour mais quand meme avec quelques reserves d'ordre pragmatiques. La, j'en chie avec un protocole de merde developpe il y a 10 ans et encore utilise partout dans la carte a puce: T=0. Priez pour ne pas avoir a l'utiliser un jour.
-
-
-
-
[^]Re: Une release importante
Posté par legranblon (page perso, ) le 22/04/2004 à 09:11. (lien). Évalué à 0.Dans les autres points ou on est a la rue sous linux, c'est les debuggeurs. On a que gdb
DDD tu connais?-
[^]Re: Une release importante
Posté par linuxidable () le 22/04/2004 à 11:47. (lien). Évalué à 2.Oui, il connait, il sait que c'est un front-end à gdb.
-
[^]Re: Une release importante
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 12:36. (lien). Évalué à 1.Tout a fait. C'est d'ailleurs celui que j'utilise. J'ai bien essaye kdbg mais il est vraiment trop limite a l'utilisation.
ddd a des trucs un peu chiant (l'idee de sauver toutes les sessions avec un no a 25 chiffres) mais est quand meme bien pratique.
Sinon, quelqu'un sait ou trouver le plugin python pour ddd ? J'ai trouve des liens qui en parlent sur internet mais impossible de trouver ou il est.
-
-
-
[^]Re: Une release importante
Posté par Christophe Fergeau () le 22/04/2004 à 09:32. (lien). Évalué à 2.> Il me fait du step-by-step dans toutes les fonctions Qt mais zappe allegrement toutes mes fonctions a moi. Une vraie horreur.
Ton programme est compilé sans aucune optim (ie aucun flag -O) ? Depuis gcc 3.qqchose, gdb a souvent du mal quand tu compiles en -O2, en le virant tout redevient normal en général.-
[^]Re: Une release importante
-
-
[^]Re: Une release importante
Posté par renoo () le 22/04/2004 à 14:38. (lien). Évalué à 2.gdb est largement superieur au debugeur de visual studio, au moins en temps que debugeur symoblique.
ex: tu as surchargé l'operateur[] dans une classe (au hasard la classe std::vector), et tu lui demandes d'afficher la 3eme valeur. Il suffit de faire un simple print a[3], sous VC++ c'est impossible on ne peut pas appeler une fonction operateur !
Pour ton probleme, tu dois avoir des problemes de flags de compil.-
[^]Re: Une release importante
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 15:42. (lien). Évalué à 1.j'ai verifie, mes flags de compile sont ok, mes sources sont en phase avec mes binaires, je vois pas d'ou ca vient.
en fait, les limitations des logiciels dependant vachement de la facon dont tu les utilises. La facon dont j'utilise le debugger de visual ne m'a pas montre de limitations, alors que la facon dont j'utilise gdb oui.
Sous gdb, break my_class::my_method() ne marche toujours pas pour moi. J'en suis encore a mettre des no de lignes.-
[^]Re: Une release importante
-
-
-
[^]Re: Une release importante
Posté par Pooly (page perso, ) le 22/04/2004 à 15:47. (lien). Évalué à 2.Je peux t'assurer qu'une fois que tu maitrise gdb, le debugueur de VC++ est a la rue pour les trucs compliquer...
-
[^]Re: Une release importante
Posté par LeMagicien Garcimore () le 22/04/2004 à 16:46. (lien). Évalué à 2.Bon ba puisqu'on parle de gdb : j'ai jamais réussi à debugger un programme avec des méthodes "inlinées". Il se plante toujours dans les numero de lignes. Si vous avez une solution, ça me ferait vraiment plaisir :)
-
[^]Re: Une release importante
-
-
[^]Re: Une release importante
Posté par Matthieu Moy (page perso, ) le 22/04/2004 à 17:02. (lien). Évalué à 2.J'ai prèsque jamais utilisé d'autres debuggeurs, mais j'utilise gdb de façon intensive, et je peux t'assurer que quand ça marche, c'est super, mais pour le C++, ça ne marche pas souvent.
J'ai régulièrement des segfaults de gdb, des fois, il passe sans s'arrêter sur un breakpoint (OUI, mon code est compilé avec -g), ... Mais la situation a tendance à s'améliorer avec le temps, alors ... wait&see !-
[^]Re: Une release importante
Posté par Christophe Fergeau () le 22/04/2004 à 17:45. (lien). Évalué à 1.Et avec ou sans -Ox ?
« Unlike most other C compilers, GCC allows you to use -g with -O.
The shortcuts taken by optimized code may occasionally produce sur-
prising results: some variables you declared may not exist at all;
flow of control may briefly move where you did not expect it; some
statements may not be executed because they compute constant
results or their values were already at hand; some statements may
execute in different places because they were moved out of loops.
»
(du man de gcc)-
[^]Re: Une release importante
Posté par Matthieu Moy (page perso, ) le 22/04/2004 à 18:07. (lien). Évalué à 1.sans -O. Pas fou l'autre, le débug de code optimisé, je laisse ça a d'autres ;-)
-
[^]Re: Une release importante
Posté par TazForEver () le 22/04/2004 à 18:12. (lien). Évalué à 0.va dire ça aux autres ... la majorités des trucs que tu récupères sous forme de source sont compilés en -g -02 ...
y a une différence entre -g et -ggdb ?
-
-
-
-
-
[^]Re: Une release importante
Posté par Xavier Jacquelin (Jabber id, page perso, ) le 13/05/2004 à 22:27. (lien). Évalué à 1.Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire. Je m'interroge si c'est le fait que j'ai ose dire que un programme sous windows est mieux qu'un programme sous linux ou simplement que les gens moinssent des qu'ils voient le mot windows.
Tu vas 1 peu vite à dire qu'un programme sous windows (Visual), est mieux qu'un programme linux. Pour 1 projet scolaire en C++ j'avais une appli à développer, qui devait compiler aussi sous Win pour pouvoir bosser avec mon binôme et sur une partie de code largement tiré du Stroustrup et standard après m'être renseigné, ben VC++ m'a tranquillement jeté. Pour 1 prog qui est mieux, bof bof...
Sinon, comme l'a dit 1 autre contributeur c'est sûrement ton argument "massue" sur le respect des standards qui t'as value le moinssage.
-
-
[^]Re: Une release importante
Posté par Jiba (page perso, ) le 22/04/2004 à 09:01. (lien). Évalué à 2.Et dans ce cas que se passe-t-il si "tout en meme temps" ça ne tient pas en mémoire (dans le cas d'un très gros programme) ?
C'est une question parce que du temps ou je codais en VB, j'ai l'impression d'avoir eu ce problème... du coup l'approche "compilation fichier par fichier de façon indépendante" de python (ou dans une moindre mesure java) me paraît meilleure.-
[^]Re: Une release importante
Posté par Fanf () le 22/04/2004 à 11:56. (lien). Évalué à 1.Tiens, je crois (je suis même presque sûr) que OCaml permet cela. D'ailleur, il me semble que s'est en partie pour permettre la compilation indépendante de modules que Xavier Leroys y a inclue la notion de "spécification de type manifeste". Il faudrait que je regarde d'un peu plus près (en tout cas, les module en OCaml, c'est un vrai bonheur).
-
-
[^]Re: Une release importante
Posté par linuxidable () le 22/04/2004 à 12:22. (lien). Évalué à 1.Je ne savais pas que VC++ fonctionnait comme ça mais du coup, quelle est l'intéret des fichiers d'entête pré-compilé ?
-
[^]Re: Une release importante
Posté par Epsos (page perso, ) le 22/04/2004 à 12:35. (lien). Évalué à 5.N'importe quoi !
Visual c++ utilise devenv.exe qui a son tour utilise cl.exe qui est le compilo standalone de MS.
Visual C++, comme gcc, compile les fichiers un par un.
Visual C++ est plus rapide a compiler que gcc. C'est un fait. Mais Visual C++ avale des trucs 100 fois moins complique que gcc aussi. Des qu'on essaye de faire des trucs un peu sioux avec des templates, Visual C++ a besoin d'etre tenu par la main pour inferer les types. Pas gcc. Bon il y a quand meme eu de sacre ameliorations sur la Version 7 (.NET) depuis la version 6. Mais AMHA, Visual est encore loin de gcc en ce qui concerne le respect du standard.
Visual C++ ne compile que pour une architecture. Combien d'archi de supportee par gcc ?-
[^]Re: Une release importante
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 12:52. (lien). Évalué à 1.Tout ca est vrai. Notamment avec boost, visual souffre pas mal.
Mais ca me fait mal quand je compile mon projet en 1 minute sous windows et 5 minutes sous Linux. Va t'en defendre l'excellence technique de linux et la nullite de microsoft apres ca.
En plus linux, le truc dont il regorge, c'est vraiment des developpeurs. On pourrait s'attendre a ce que les outils soient nickels et faciles a utiliser mais c'est loin d'etre le cas.-
[^]Re: Une release importante
Posté par Epsos (page perso, ) le 22/04/2004 à 13:00. (lien). Évalué à 1.Je suis d'accord avec toi : ca fait mal de compiler plus vite sous windows que linux.
Je ne repondais que sur la partie fausse "windows compile tous les fichiers d'un projet en une seule passe et garde un buffer en memoire de sa precedente compilation". ouf !
Personnellement, je trouve que les outils sont nickels : ils marchent et permettent de faire des trucs que l'on ne peut pas faire facilement sous windows.
C'est vrai qu'au niveau rapidite ce n'est pas la panacee. La cause est connue : les multiples architectures et les multiples langages supportes par gcc.
-
-
[^]Re: Une release importante
Posté par pasBill pasGates () le 23/04/2004 à 09:32. (lien). Évalué à 0.Si tu compares la derniere version de VC++ (.NET 2003), tu verras que celui qui est a la rue niveau standards n'est pas forcement celui qu'on croit
-
[^]Re: Une release importante
Posté par Epsos (page perso, ) le 23/04/2004 à 11:44. (lien). Évalué à 1.Ben justement, je bosse tous les jours sur Visual C++ 7.1.3088 (.NET framework 1.1.4322) ...
Le pire a la limite, c'est pas tant sur le respect des standards (ils ont fait de gros efforts de ce cote la), mais c'est le reporting d'erreur.
Regulierement, vc++ sort une internal error parce qu'en signalant une erreur dans ton code il se plante sur sa reprise sur erreur...
Ce qui est marrant aussi c'est que de temps en temps un gars de l'equipe fait un portage sur Linux/gcc. Ca lui permet de trouver des bogues que gcc nous remonte via des erreurs/warnings que vc++ ne voit pas ...-
[^]Re: Une release importante
Posté par Frédéric RISS () le 23/04/2004 à 12:20. (lien). Évalué à 2.Je suis un grand fan du couple GCC/GDB pour le développement, je développe toute la journée avec GCC et je fais de temps en temps un port VC.NET et il est évident pour moi que ta dernière phrase marche très bien dans l'autre sens.
En règle générale, le fait d'utiliser plusieurs compilateurs/platformes sur un projet apporte un énorme gain en robustesse.
-
[^]Re: Une release importante
Posté par renoo () le 23/04/2004 à 15:13. (lien). Évalué à 1.Oui, j'ai le meme probleme de reporting d'erreurs dans VS7.1. A tel point que j'utilise g++ pour compiler et verifier les erreurs. Mais il est vrai que VS7.1 a fait d'enormes progres du coté du respect des standard et notamment du coté des templates, deja avec VS7.0 il y avait eu des progres importants mais maintenant on peut dire que VS7.1 est au niveau de gcc du coté du respect des standard.
-
[^]Re: Une release importante
Posté par pasBill pasGates () le 23/04/2004 à 17:59. (lien). Évalué à 2.cf. http://www.cs.clemson.edu/~malloy/papers/ddj2/paper.pdf(...) pour une comparaison du respect des standards par les differents compilos.
Quand aux internals errors, ca je veux bien le croire, j'en ai rencontre 2 dernierement, mais ca tous les compilos en ont, j'en ai rencontre sur gcc/g++ aussi.
-
-
-
-
[^]Re: Une release importante
Posté par frecillia6 () le 25/04/2004 à 17:23. (lien). Évalué à 1.ça m'etonnerai que le gain de vitesse vienne de là, vu que sous VC++ aussi il y a un compilateur en ligne de commande comme sous UNIX. Il est juste appelé en tâche de fond par l'IDE, mais c'est un processus à part.
D'ailleurs, sous Windows aussi tu peux utiliser des makefiles avec NMAKE.
-
-
-
-
[^]Re: Une release importante
Posté par Matthieu Moy (page perso, ) le 21/04/2004 à 14:40. (lien). Évalué à 1.> * Une réécriture complète du moteur de parsing du C++
Est-ce que ça veut dire que c'est la fin des "Parse error before '('" et qu'on aura enfin des vrais messages d'erreur ?-
[+] [^]Re: Une release importante
Posté par Cédric Chevalier (page perso, ) le 21/04/2004 à 15:06. (lien). Évalué à -1.Je vois pas ce que tu leurs trouves aux messages d'erreur actuels.
Tu préférerais un message du type "il manque surement un point-virgule ou une accolade avant '('. Il faudrait que tu sois plus concentré pendant que tu codes, codeur de m...".-
[^]Re: Une release importante
Posté par Matthieu Moy (page perso, ) le 21/04/2004 à 15:39. (lien). Évalué à 6.Code 5 minutes en Ada avec GNAT, et tu comprendras ce que c'est qu'un message d'erreur explicite.
Sur
#include
string ma_fonction(int x);
g++ 3.2 donne
errmsg.cpp:2: parse error before `)' token
Bon, il était pas obligé de me dire
"string should be std::string"
mais si il me disais
"string: identifier not declared"
Je serais déjà content.-
[^]Re: Une release importante
Posté par Matthieu Moy (page perso, ) le 21/04/2004 à 17:28. (lien). Évalué à 1.Bien évidemment, il fallait lire
#include < string >
string ma_fonction(int x);
C'est encore templeet le méchant qui m'a bouffé une balise ...
-
[^]Re: Une release importante
Posté par Matthieu C () le 23/04/2004 à 16:53. (lien). Évalué à 2.g++-3.4 /tmp/to.cpp
/tmp/to.cpp:2: erreur: « string » ne nomme pas un type
c'est donc bien mieux :)
-
-
-
Re: Sortie de GCC 3.4.0
Experiments made on i386 hardware showed an 11% speedup on -O0 and a 7.5% speedup on -O2 compilation of a large C++ testcase.
Je crois pas que ça veut dire que les performances augmentent, mais seulement que la compilation va plus vite.
-
[^]Re: Sortie de GCC 3.4.0
Posté par MiniMoi () le 21/04/2004 à 13:30. (lien). Évalué à 2.Et oui ca aurait ete trop beau... C est bien le temps de comilation dont il est question... :'-(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361(...)
[3.3/3.4/3.5 regression] C++ compile-time performance regression-
[^]Re: Sortie de GCC 3.4.0
Posté par ufoot (page perso, ) le 21/04/2004 à 13:45. (lien). Évalué à 4.Ouais enfin moi j'ai un projet en C++ sur le feu et autant il n'a pas trop de problèmes de perf à l'exécution (ça tourne bien sur un P200 si mes souvenirs sont bons) autant à la compilation c'est la cata même avec mon bel Athlon je dépasse allègremment la minute à chaque compil, donc 11% de mieux à la compil: j'achète!
PS: fût un temps où je développais ce projet sur le fameux P200 et là la compil c'était carrément 10minutes à 1/2 heure, houla...-
[^]Re: Sortie de GCC 3.4.0
Posté par Cédric Chevalier (page perso, ) le 21/04/2004 à 14:33. (lien). Évalué à 4.Personnellement, je préfererrais gagner plus sur l'éxécution, même si la compilation est plus longue (du moins lorsqu'on met les optimisations).
Et puis, si ça compile trop vite on aura plus le temps d'aller se détendre sur DLFP ;-)-
[^]Re: Sortie de GCC 3.4.0
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Guillaume Laurent (page perso, ) le 21/04/2004 à 14:41. (lien). Évalué à 3.Ah ouais, plus d'1mn de temps de compil, c'est vraiment enorme. :-)
-
[^]Re: Sortie de GCC 3.4.0
Posté par ufoot (page perso, ) le 22/04/2004 à 06:17. (lien). Évalué à 2.Oui non mais 1min à chaque fois que je modifie un ".h". Le rebuild complet lui est plutôt dans les 5 ou 10 min (donc 1h ou 2h sur l'ancienne machine...). Honnêtement 1 min pour savoir si ta petite modif d'une ligne compile ou pas, c'est lourd. Evidemment on peut après coder "par paquets" en limitant le nombre de compils et en ne se servant pas du compilo pour chopper les erreurs de syntaxe mais en anticipant. M'enfin c'est méga chiant. Du coup maintenant je préfère me tourner vers les langages de script.
-
[^]Re: Sortie de GCC 3.4.0
Posté par Guillaume Laurent (page perso, ) le 22/04/2004 à 14:08. (lien). Évalué à 1.Ah, pareil chez moi, 2-3mn de temps de compil en moyenne, presque 20 pour le total, et c'est vrai, ca gave. Malheureusement les langages de scripts ne sont pas une option pour ce que je fais, en attendant je garde un bouquin a cote du clavier pour lire pendant les compils :-).
-
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par gS () le 21/04/2004 à 15:07. (lien). Évalué à 5.Pour accelerer les compilation essayez ccache (ou distcc, si vous avez plusieurs machines dispo).
Comme son nom l'indique presque ccache stocke les resultats de compilation précédents et les ressorts si les sources sont identiques.
Sur notre projet, nous sommes passes de 12 minutes a 1 minute trente (et comme on utilise qmake/Qt et qu'il gere pas super bien les dépendences, on etait obligé de tout recompiler tres frequemment).
Bref, ca marche pas mal et on a pas encore eu de problemes avec.
a++
Guillaume.-
[^]Re: Sortie de GCC 3.4.0
Posté par harbort1 () le 22/04/2004 à 07:02. (lien). Évalué à 4.Dans mon labo on est passé SCons et il gère bien les dépendances (et Qt avec les moc,ui, ...) et considère un fichier modifié non pas uniquement sur la base de la date (même s'il l'utilise) mais sur la base d'un checksum. AMA, mieux vaut un bon système de compilation que de rajouter les couches avec ccache ou autre ...
Mais pour tout dire, c'est loin de suffire ! Pour interfacer mon programme avec Python j'utilise Boost (pour ceux qui ne connaissent pas Boost est un ensemble de bibliothèques qui pour la plupart sont super bien mais qui ont le gros défaut d'utiliser les templates à outrance) et ce seul petit ajout à fait passé mon programme de 30sec. de compil. à près de 20 min !!!!!! Et les systèmes de caches n'y font rien (puisque SCons gère ça correctement).
Donc j'attendais avec impatience cette nouvelle version de g++ pour les precompiled headers et pour le nouveau parseur !
Ce matin se sera : G++ LE GRAND TEST ! En direct live sur ma machine :)-
[^]Re: Sortie de GCC 3.4.0
Posté par gS () le 22/04/2004 à 09:04. (lien). Évalué à 2.Ouaip, c'est vrais que Scons a l'air pas mal.
Je l'ai essayé pour un tout petit projet fait a la maison parce que j'avais la flemme de me refaire toute la choucroute automake/autoconf pour gérer les dépendences proprement et ca marche super bien.
Il faut quelques minutes pour comprendre comment ecrire l'équivalent du makefile et hop ca roule!
Je suis en train de réflechir a la façon dont je pourrais migrer le projet de l'équipe au boulot (pas une mince affaire).
En tout cas, meme pour un tout petit projet d'une dizaine de fichiers, le bénéfice est immédiat!
-
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Troy McClure (page perso, ) le 21/04/2004 à 16:11. (lien). Évalué à 7.La lenteur de g++ est effectivement un gros problème. D'après les benchs publiés sur la ml de gcc ( http://gcc.gnu.org/ml/gcc/2004-04/msg00913.html(...) par ex) il y a eu de gros progrès avec la 3.4, en particulier pour l'edition de lien en '-g' (faut dire que la 3.3 partait de loin..)
Par contre icpc (le compilo c++ d'intel) reste encore 2 fois plus rapide à compiler, genere un code 15% plus performant en moyenne, et des executables sensiblement plus petits. La future version de gcc (3.5 ou 4.0 c'est pas encore décidé) changera peut-etre la donne..-
[^]Re: Sortie de GCC 3.4.0
Posté par MiniMoi () le 21/04/2004 à 19:37. (lien). Évalué à 1.Aïe je ne savais pas que g++ etait si lent a compiler et qu il se faisait battre par les autres compilateurs pour la rapidite du code?
Quelqu un sait il pourquoi? Pour la rapidite de compilation c est peut etre le respect de la norme ANSI, mais pour l efficacite du code?
Moi qui pensais que comme gcc est le meilleur compilateur C, g++ est le meilleur compilateur C++...-
[^]Re: Sortie de GCC 3.4.0
Posté par peau chat () le 21/04/2004 à 20:00. (lien). Évalué à 1.Moi qui pensais que comme gcc est le meilleur compilateur C, g++ est le meilleur compilateur C++
Houla... non pas du tout. GCC et G++ sont même des grosses bouses au niveau performances et code généré. Par contre ils ont le gros avantage d'être libre et multi-plateformes.
GCC est complètement hors-jeu pour ceux qui cherchent à faire des clusters haute performance par exemple :
http://www.hs.uni-hamburg.de/EN/For/ThA/phoenix/index.html(...)
Mais lui, au moins, il est multiplateformes :-)-
[^]Re: Sortie de GCC 3.4.0
Posté par Guillaume POIRIER (page perso, ) le 21/04/2004 à 20:36. (lien). Évalué à 2.non pas du tout. GCC et G++ sont même des grosses bouses au niveau performances et code généré.
Alors là, je ne peux pas te laisser dire ça! Dire que c'est une grosse bouse, c'est vraiment manquer de respect à l'équipe de dev de gcc.
Il ne faut pas perdre de vue qu'il est tout à fait impossible de faire aussi bien qu'un compilateur spécifique à une architecture et à quelques processeurs, pour des questions que seules plusieurs heures de cours de compilation permettent de comprendre vraiment.
Cela dit, quand on regarde les benchs:
http://people.redhat.com/dnovillo/spec2000/gcc/global-run-ratio.htm(...)
On voit que gcc n'est vraiment pas si mal étant donné toutes les contraintes de base dût à sa nature multiplateforme...-
[^]Re: Sortie de GCC 3.4.0
Posté par peau chat () le 21/04/2004 à 22:41. (lien). Évalué à 4.Il ne faut pas perdre de vue qu'il est tout à fait impossible de faire aussi bien qu'un compilateur spécifique à une architecture et à quelques processeurs
Bien sûr, c'est ce que je dis : il a l'avantage d'être multi plateformes !
J'ai en mémoire des articles/interviews d'ingénieurs d'IBM qui travaillent sur les compilos IBM mais également sur l'optimisation de GCC pour le PowerPC. Ils le disent clairement : le fait que GCC soit multiplateformes ne permet pas de faire les mêmes optimisations.
Il n'empêche, que le code final est moins performant.
Les gars de Phoenix ont même parlé de différences de l'ordre de 60%
Il n'y a aucune honte à cela, mais il ne faut surtout pas laisser croire béatement que GCC a les meilleures perfs sous le simple prétexte qu'il commence par un « G ».
En puis, pour le C++, le problème de G++ est connu et décortiqué depuis longtemps...
-
[^]Re: Sortie de GCC 3.4.0
Posté par Moby-Dik () le 22/04/2004 à 12:46. (lien). Évalué à 2.Alors là, je ne peux pas te laisser dire ça! Dire que c'est une grosse bouse, c'est vraiment manquer de respect à l'équipe de dev de gcc.
Allons voyons. On n'a pas le droit de critiquer un logiciel libre car ce serait manquer de respect. Bienvenue au pays de la pensée unique.-
[^]Re: Sortie de GCC 3.4.0
Posté par Castor666 () le 22/04/2004 à 13:13. (lien). Évalué à 0.Il y a un différence entre insulte et critique quand même. Il ne faut pas crier au loup dés que quelqu'un ose faire remarquer que grosse bouse est insultant.
Ha mais non j'oubliais, les Linuxiens sont tous des intaigristes bornés qui défendent leur système favori coûte que coûte...
-
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Cédric Chevalier (page perso, ) le 21/04/2004 à 20:46. (lien). Évalué à 1.Le code généré à partir du C est quand même dans l'ensemble assez correct. J'ai déjà comparé (sur Intel et Sparc) de l'assembleur généré par gcc avec de l'assembleur généré par d'autres compilateurs et gcc fournit un code de bonne qualité quand même.
Pour g++, je ne sais pas.-
[^]Re: Sortie de GCC 3.4.0
Posté par peau chat () le 21/04/2004 à 22:46. (lien). Évalué à 2.Même en ce qui concerne le C, le résultat est très variable en ce qui concerne les plateformes (CPU), et GCC est largué dès qu'on commence à parler de calculs en virgules flottantes, jeux d'instructions SIMD (MMX, SSEx, Altivec etc.)
Fondamentalement, ce n'est pas un problème. On voit mal comment GCC qui est multi-processesseurs pourrait faire mieux qu'un compilateur dédié à un seul modèle de CPU, conçu par le concepteur du CPU, et vendu plusieurs milliers d'euros la licence.
-
[^]Re: Sortie de GCC 3.4.0
Posté par peau chat () le 21/04/2004 à 22:57. (lien). Évalué à 3.J'ajoute qu'on peut avoir un code assembleur de très bonne qualité, mais quand même pas optimisé.
Je m'explique :
Les microprocesseurs disposent en général de plusieurs pipelines s'exécutant en parallèle. Une première unité du CPU a pour tâche de prendre les instructions à exécuter, et à les répartir entre les différents pipelines.
Seulement voila, le CPU va prendre N instructions à répartir entre P pipelines, et chaque pipeline est dédié à un seul type d'opération.
Typiquement 2 pipelines pour exécuter des opérations sur les entiers, 1 pipeline pour exécuter les accès mémoire, 1 pipeline pour les calculs en virgul flottante, 1 pour les saut conditionnels etc.
Un compilateur dédié à un microprocesseur se débrouillera pour que dans un « paquet » de N instructions consécutives il n'y ait pas plus de 2 opérations sur les entiers pour alimenter un maximum de pipelines en parallèle en un seul cycle d'horloge.
Évidemment, comme pour chaque modèle de CPU le nombre et le type de pipelines est différent, il est extrêmement difficile d'effectuer ce genre d'optimisation.-
[^]Re: Sortie de GCC 3.4.0
Posté par Cédric Chevalier (page perso, ) le 21/04/2004 à 23:16. (lien). Évalué à 3.Quand je parlais de bonne qualité, c'était notamment par rapport à ces problème de reordonnancement.
Et juste pour info (mais je suis sûr que vous le savez déjà tous mais c'est pas grave ça me rode un peu mon clavier) un processeur type P4 (par exemple) réordonne les instructions avant de les éxécuter (out-of-order engine), à un niveau plus fin que le compilateur (niveau instructions internes au core, donc en RISC). Donc je pense que sur les processeurs actuels de PC c'est pas le réordonnancement du compilateur qui va être capital.
Sur une architecture type Itanium (VLIW) par contre c'est vital.
Voilà, c'était juste pour parler un peu. De toute façon, les différences de performances les plus visibles sont dûes au programmeur, pas au compilateur (et là on peut atteindre bien plus de 60% d'écart).-
[^]Re: Sortie de GCC 3.4.0
-
-
-
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Troy McClure (page perso, ) le 21/04/2004 à 20:59. (lien). Évalué à 3.mais il a aussi des avantages, bien sur la portabilité, le fait que ce soit une suite de compilateurs (c,c++,ada,fortran,objC,..). C'est aussi un des rares compilos c++ à fournir des messages d'erreurs complets (i.e. qui permettent après 10 minutes de reflexion et de recherche dans un message de 500 lignes de trouver à quel endroit se situe le probleme), icpc par exemple est bien moins loquace. Pareil pour les warnings, ceux de g++ sont judicieux alors que ceux de icpc (ou cxx, ou le mipspro..) sont soit trop nombreux et inutiles, soit trop peu nombreux. Il est aussi (pour ce que j'en ai vu) moins buggué que icpc. ET il est internationalisé ! (ok ça c'est plus une connerie qu'autre chose)
Et la prochaine version apportera le tree-SSA, j'aurais bien du mal à expliquer le pourquoi du comment, mais visiblement les dev de gcc ont beaucoup d'espoir dans ce truc qui devrait permettre plein de choses, entre autres de faire des optimisations impossibles à l'heure actuelle-
[^]Re: Sortie de GCC 3.4.0
Posté par Croweye () le 22/04/2004 à 04:48. (lien). Évalué à 1.un des avantages de gcc, c est qu'il est stable!!!
On a été obligé d'utiliser a la job icc pour faire bouffer les tonnes d assembleur écrit a la mode MS (portage) et je en compte pas le nombre de fois que le compilateur a planté
pas qui retourne une erreur, non, icc : segfault!
apres, amusons-nous a trouver dans le fichier de 4000 lignes c quoi qui aime pas
(faut par contre avouer que la v8 est bcp stable que la 7)-
[^]Re: Sortie de GCC 3.4.0
Posté par Matthieu Moy (page perso, ) le 22/04/2004 à 06:27. (lien). Évalué à 2.T'inquiètes, un segfault de g++, j'en ai déjà vu.
Ce monsieur n'avait pas apprécié qu'on mette un unsigned int à la place d'un int.
J'ai déjà réussi à faire générer du code incorrect a gcc avec un code parfaitement banal de C pur, de moins de 20 lignes.-
[^]Re: Sortie de GCC 3.4.0
Posté par Ayrton () le 22/04/2004 à 09:19. (lien). Évalué à 0.Si 20 lignes de "code parfaitement banal de C" suffissent pour générer du code incorrect, que GNU/Linux marche alors qu'il faut compiler des dizaines de millions de lignes de code est un véritable exploit.
Les utilisateurs de Gentoo apprécirons ta remarque.-
[^]Re: Sortie de GCC 3.4.0
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 12:58. (lien). Évalué à 1.Mais oui. Et chaque changement de compilateur est un nouvel exploit pour chaque distrib, surtout quand ces messieurs de gcc s'amusent (si on peut dire) a retirer des trucs qui marchaient avant.
Le resultat, c'est que des tas de projet vont passer du temps a corriger les problemes de compilation lie a gcc 3.4 . Voila comment l'exploit se realise. Mais c'est pour la bonne cause, c'est pour le standard.
Je ne suis pas alle voir mais je suis sur que sur kde-core-devel, ils discutent deja des nouvelles perfs et du code qu'il faut corriger pour passer sur gcc 3.4 . Ce temps aurait pu etre investi a corriger des bugs mais rien n'est plus important que de respecter le standard du C++.
J'espere pour Soustroup qu'il verra avant sa mort un compilateur qui respecte le standard qu'il a ecrit. Sinon, ca serait triste pour lui quand meme.-
[^]Re: Sortie de GCC 3.4.0
Posté par Ayrton () le 22/04/2004 à 13:40. (lien). Évalué à 1.> Le resultat, c'est que des tas de projet vont passer du temps a corriger les problemes de compilation lie a gcc 3.4
Et généralement il vont aussi découvrir des conneries dans leur code.
J'était sur http://lwn.net/Articles/79560/(...) et j'ai trouvé ça dans gcc 3.4 :
gcc 3.4 supports a "warn_unused_result" attribute on functions; the compiler will complain when code calls a function marked with this attribute and fails to check the return value. The Red Hat kernel applies that attribute to a few functions (copy_from_user(), pci_enable_device(), etc.) to trap places where the proper checks are not made. Various functions which use too much kernel stack space have been fixed up.
Une très très grosse partie de FC2 compile avec gcc 3.4 (ce n'est pas le compilateur par défaut). A chaque foi qu'il y a un nouveau compilateur il faut 6 mois pour que l'essentiel soit porté (il reste toujours deux ou trois mal maintenu...).
Tu veux quoi ? Plus d'évolution ?
GNU/Linux a la chance d'être orienté source. Ça permet d'évoluer vite.
Profitons-en.
Si on était empétré dans les problèmes de compatibilité comme les OS proprio, GNU/Linux serait probablement un échec.
De plus tu peux toujours installer plusieurs version de gcc en parallèle. Donc je ne comprend pas ta remarque.
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Matthieu Moy (page perso, ) le 22/04/2004 à 13:56. (lien). Évalué à 2.Tu veux aller voir le rapport de bug ?
http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00449.html(...)
J'arrive plus à décoder l'attachement en base64, mais il y avait 17 lignes si mes souvenirs sont bons. Le truc qui n'avait pas plu à gcc, c'est la présence d'un "unsigned char" dans une boucle for ou un truc du genre.
J'ai aussi déjà vu GCC partir en vrille (100% de CPU, 500Mo de RAM) sur un programme C++ de moins de 20 lignes. Mais là, c'est de la triche, il y avait des templates.
Maintenant, devines quoi : Quand un programmeur tombe sur un cas comme ça, devines ce qu'il fait ... Il change son code, et il met un truc qui compile. Du coup, oh, miracle, à la fin, il a un programme qui compile. C'est dingue, non ?-
[^]Re: Sortie de GCC 3.4.0
Posté par renoo () le 23/04/2004 à 16:22. (lien). Évalué à 2.C'est pas lié à la machine AIX on bull ? Sinon le binaire faux c'est quand meme terrible.
Pour les templates c'est normal, pour calculer la factorielle à la compil combien faut-il de temps et d'espace mémoire ? Mais c'est quand meme une force terrible de pouvoir faire des trucs aussi puissant à la compilation.
template<int N> inline Facto() {return N*Facto<N-1>();}
template<> inline int Facto<0>() {return 1;}-
[^]Re: Sortie de GCC 3.4.0
Posté par Matthieu Moy (page perso, ) le 26/04/2004 à 12:29. (lien). Évalué à 1.> C'est pas lié à la machine AIX on bull ?
Si mes souvenirs sont bons, je n'avais pas réussi à reproduire le bug sur Linux i386, donc, c'était lié à l'architecture.
> Sinon le binaire faux c'est quand meme terrible.
Tu l'as dit, surtout quand il faut trouver l'endroit qui fait planter GCC au milieu de 3000 lignes de code :-(
> Pour les templates c'est normal,
Je n'ai pas le programme sous la main, mais je t'assure que dans ce cas particulier, ce n'était pas du tout normal ;-) (En fait, GCC aurait du sortir une erreur immédiatement)
-
-
-
-
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par patrick_g (page perso, ) le 22/04/2004 à 13:11. (lien). Évalué à 2.Et la prochaine version apportera le tree-SSA, j'aurais bien du mal à expliquer le pourquoi du comment, mais visiblement les dev de gcc ont beaucoup d'espoir dans ce truc qui devrait permettre plein de choses, entre autres de faire des optimisations impossibles à l'heure actuelle
j'avais posté une news y'a qq mois qui évoquait le futur de GCC (avec le tree-SSA) :
http://linuxfr.org/2003/10/29/14428.html(...)
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Croconux () le 22/04/2004 à 14:43. (lien). Évalué à 1.Quelqu un sait il pourquoi? Pour la rapidite de compilation c est peut etre le respect de la norme ANSI, mais pour l efficacite du code?
J'avais lu il y a quelques temps que la structure sur laquelle gcc travaille en interne (le RTL) était de trop bas niveau pour permettre certaines optimisations. D'ailleurs dans la prochaine grosse version (4.0?) cette structure sera remplacée par une nouvelle forme (Gimple).
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Ayrton () le 22/04/2004 à 09:14. (lien). Évalué à 1.> genere un code 15% plus performant en moyenne
Tu veux dire que si je compile mon GNU avec icpc mon système va tourner 15 % vite en moyenne ?
Fichtre !
J'y crois pas.-
[^]Re: Sortie de GCC 3.4.0
Posté par Troy McClure (page perso, ) le 22/04/2004 à 10:08. (lien). Évalué à 0.c'est pas ce que j'ai dit !
-
[^]Re: Sortie de GCC 3.4.0
Posté par MiniMoi () le 22/04/2004 à 10:08. (lien). Évalué à 1.Ca me parait aussi tres bizarre... Dans ce cas pourquoi Linux a-t-il de bonnes performances si il est handicape par un compilateur C tout juste correct (gcc) et par un compilateur C++ tout juste correct aussi (g++)?
-
[^]Re: Sortie de GCC 3.4.0
Posté par Troy McClure (page perso, ) le 22/04/2004 à 10:33. (lien). Évalué à 4.parce qu'il ne fait pas ou peu de taches cpu-intensives ! ce genre de difference n'est sensible que sur des softs qui utilisent beaucoup de temps processeur, par ex. oggenc, mencoder, gcc, etc.., pas sur ceux qui passent 99% de leur temps à attendre l'arrivée d'un evenement.
et gcc est plus que correct, mais il n'est pas le meilleur à tous points de vue.-
[+] [^]Re: Sortie de GCC 3.4.0
Posté par Ayrton () le 22/04/2004 à 11:37. (lien). Évalué à -1.> gcc est plus que correct, mais il n'est pas le meilleur à tous points de vue.
C'est peut-être pas le meilleur pour les performances mais globalement c'est le meilleur (avis personnel)
Puis ces trucs d'optimisations c'est "fatiguant". On promet le pérou et quand on voit la différence entre une Gentoo et une autre distribution, on constate que le pérou est encore très loin... Et aussi lorsque le cpu est utilisé intensivement (sauf pour des cas particuliers qui ne consernent que 0.01 % des utilisateurs).
Il y a plein de cluster Linux vendu avec gcc. Ce n'est pas un hazard.
Si icc écrasait gcc en performance, Intel aurait fait un bench avec une distribution complètement compilée avec icc pour montrer comme icc rox à mort. Peut-être qu'Intel aurait aussi forké une distribution avec la seule particularité d'utiliser icc.
> beaucoup de temps processeur, par ex. oggenc, mencoder
J'aimerais bien voir un bench de mencoder, qui est optimisé aux petits oignons, compilé avec gcc et icc.
Déjà il faut que ça compile avec icc, ce qui n'est pas sûre.
Puis l'écart en faveur d'icc (si cet écart existe) sera très faible. Pas de quoi lacher un amour de logiciel libre comme gcc.-
[^]Re: Sortie de GCC 3.4.0
Posté par Moby-Dik () le 22/04/2004 à 12:52. (lien). Évalué à 0.
C'est peut-être pas le meilleur pour les performances mais globalement c'est le meilleur (avis personnel)
Moi j'ai mangé de la banane flambée ce midi.
On promet le pérou et quand on voit la différence entre une Gentoo et une autre distribution, on constate que le pérou est encore très loin...
Ouais, alors qu'on pourrait se contenter de la Belgique.
Il y a plein de cluster Linux vendu avec gcc. Ce n'est pas un hazard.
Oui, Linux et gcc sont gratuits.
Si icc écrasait gcc en performance, Intel aurait fait un bench avec une distribution complètement compilée avec icc pour montrer comme icc rox à mort.
Intel est un marchand de processeurs, le marché du soft ne l'intéresse pas. Ecrire un compilateur ne lui sert qu'à montrer ses CPUs sous un meilleur jour (notamment tests SPEC CPU).-
[^]Re: Sortie de GCC 3.4.0
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Troy McClure (page perso, ) le 22/04/2004 à 14:22. (lien). Évalué à 1.> J'aimerais bien voir un bench de mencoder, qui est optimisé aux petits oignons, compilé avec gcc et icc.
> Déjà il faut que ça compile avec icc, ce qui n'est pas sûre.
> Puis l'écart en faveur d'icc (si cet écart existe) sera très faible. Pas de quoi lacher un amour de logiciel libre comme gcc.
Pour mencoder il n'y aura sans doute aucune difference vu que le truc est blindé d'optimisations en assembleur etc.
Prends n'importe quel code de calcul un peu bourrin, compile-le avec icc et gcc, et les 15% tu les auras. En tout cas moi je les ai constaté à chaque fois. Maintenant 15% c'est pas grand chose, personnellement ça m'importe beaucoup moins que la difference de vitesse de compilation de g++ par rapport icc.-
[^]Re: Sortie de GCC 3.4.0
Posté par Christophe Fergeau () le 22/04/2004 à 15:34. (lien). Évalué à 1.Recompile g++ avec icc, tu gagneras déjà 15% de perfs, donc de temps de compil ;)
-
[^]Re: Sortie de GCC 3.4.0
Posté par Ayrton () le 22/04/2004 à 16:06. (lien). Évalué à 1.Difficile. gcc boostrap.
Ce qui va arriver, c'est que icc va compiler gcc-stage1 puis gcc-stage1 va compiler tout gcc. Puis les 15 % de mieux, tu peux rêver.-
[^]Re: Sortie de GCC 3.4.0
Posté par Matthieu Moy (page perso, ) le 22/04/2004 à 17:07. (lien). Évalué à 1.Oui, enfin, tu peux aussi récupérer le binaire du gcc-stage1.
Les Makefiles ne sont pas trop fait pour, mais mais le compilateur que tu cherche (gcc compilé avec icc) est bien celui qui est utilisé pour compiler stage2.
Par contre, il y a de fortes chances pour que ca ne compile pas du tout (cf. p tramo ci-dessous)
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Troy McClure (page perso, ) le 22/04/2004 à 16:19. (lien). Évalué à 1.aarg je viens d'essayer et ... la compilation foire au bout de quelques fichiers :'( dommage j'aimais bien l'idée
-
-
-
-
-
-
-
-
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Nicolas ANTONIAZZI (page perso, ) le 21/04/2004 à 13:30. (lien). Évalué à 4.Pour le moment, que le C++ compile plus vite c'est vraiment apprecié... Les programmes en C++ sont vraiment lent à compiler comparé à d'autres compilateur proprio.
J'ai bon espoir que cette release apporte une solution.
-
[^]Re: Sortie de GCC 3.4.0
Posté par Cédric Chevalier (page perso, ) le 21/04/2004 à 13:32. (lien). Évalué à 2.Par contre il ya peut-être bien des améliorations dans l'analyse du code qui permettront de gagner un peu de performances à l'éxécution.
-
[^]Re: Sortie de GCC 3.4.0
Posté par Vincent Richard (page perso, ) le 21/04/2004 à 14:16. (lien). Évalué à 1.En tout cas, il y a eu des optimisations dans la STL, et c'est une bonne chose à mon avis. Elle n'est encore pas parfaite (pas qu'en terme d'optimisations), mais elle ne fait que s'améliorer.
Voir la rubrique "Runtime Library (libstdc++) -> Optimization work" des changements.
En tout cas, je tiens à adresser mon respect aux développeurs de GCC, car faire un compilateur c'est quand même un sacré boulot...
-
-
[^]Re: Sortie de GCC 3.4.0
Posté par Wajsberg Julien (
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.