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. À remarquer également que des modifications ont été faites sur la grammaire des langages C, C++, Objective C pour refléter au mieux les standards.
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.
Aller plus loin
- GCC (2 clics)
- Changements (1 clic)
- Liste des miroirs (2 clics)
- Obsolète (2 clics)
- Liste des corrections (1 clic)
# Une release importante
Posté par lucio . Évalué à 6.
* 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 !
[^] # Re: Une release importante
Posté par Pierre . Évalué à 3.
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..
[^] # Re: Une release importante
Posté par dcp . Évalué à 0.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . Évalué à 3.
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 Pierre . Évalué à 2.
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)
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . Évalué à 6.
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 PachaFonk . Évalué à 3.
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 . Évalué à -1.
[^] # Re: Une release importante
Posté par Cédric Chevalier (site web personnel) . Évalué à 3.
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 F (site web personnel) . Évalué à 3.
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
Posté par renoo . Évalué à 1.
[^] # Portée des boucles for
Posté par frecillia6 . Évalué à 1.
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 Pierre . Évalué à 2.
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..
[^] # Re: Une release importante
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: Une release importante
Posté par Pierre . Évalué à 1.
J'ai bien peur que ce projet ce soit transformé en "precompiled header support"
[^] # Re: Une release importante
Posté par linuxidable . Évalué à 1.
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 . Évalué à 4.
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 . Évalué à 0.
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 . Évalué à 2.
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 F (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 2.
> 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 F (site web personnel) . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Une release importante
Posté par Éric (site web personnel) . Évalué à 1.
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 . Évalué à 4.
> 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 F (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 0.
DDD tu connais?
[^] # Re: Une release importante
Posté par linuxidable . Évalué à 2.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . Évalué à 1.
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 . Évalué à 2.
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
Posté par Ayrton . Évalué à 1.
[^] # Re: Une release importante
Posté par renoo . Évalué à 2.
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 F (site web personnel) . Évalué à 1.
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
Posté par Ayrton . Évalué à 3.
Faut virer "()"
[^] # Re: Une release importante
Posté par Pooly (site web personnel) . Évalué à 2.
[^] # Re: Une release importante
Posté par LeMagicien Garcimore . Évalué à 2.
[^] # Re: Une release importante
Posté par Ayrton . Évalué à 3.
[^] # Re: Une release importante
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
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 . Évalué à 1.
« 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 (site web personnel) . Évalué à 1.
[^] # Re: Une release importante
Posté par TazForEver . Évalué à 0.
y a une différence entre -g et -ggdb ?
[^] # Re: Une release importante
Posté par Xavier Jacquelin (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 1.
[^] # Re: Une release importante
Posté par linuxidable . Évalué à 1.
[^] # Re: Une release importante
Posté par Epsos . Évalué à 5.
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 F (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 0.
[^] # Re: Une release importante
Posté par Epsos . Évalué à 1.
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 . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Une release importante
Posté par pasBill pasGates . Évalué à 2.
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 . Évalué à 1.
D'ailleurs, sous Windows aussi tu peux utiliser des makefiles avec NMAKE.
[^] # Re: Une release importante
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à -1.
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 (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à 1.
#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 M . Évalué à 2.
/tmp/to.cpp:2: erreur: « string » ne nomme pas un type
c'est donc bien mieux :)
# Re: Sortie de GCC 3.4.0
Posté par RB . Évalué à 7.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à 4.
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
Posté par Daneel . Évalué à 4.
[^] # Re: Sortie de GCC 3.4.0
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
[^] # Re: Sortie de GCC 3.4.0
Posté par ufoot (site web personnel) . Évalué à 2.
[^] # Re: Sortie de GCC 3.4.0
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Sortie de GCC 3.4.0
Posté par gS . Évalué à 5.
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 . Évalué à 4.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 7.
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 . É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?
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 . Évalué à 1.
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 . É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.
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 . Évalué à 4.
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 . Évalué à 2.
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 . Évalué à 0.
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 (site web personnel) . Évalué à 1.
Pour g++, je ne sais pas.
[^] # Re: Sortie de GCC 3.4.0
Posté par peau chat . Évalué à 2.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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
Posté par mickabouille . Évalué à 2.
C'est rigolo ça. en traduisant de travers ça fait "machine en panne".
[^] # Re: Sortie de GCC 3.4.0
Posté par Troy McClure (site web personnel) . Évalué à 3.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 0.
Les utilisateurs de Gentoo apprécirons ta remarque.
[^] # Re: Sortie de GCC 3.4.0
Posté par Philippe F (site web personnel) . É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 . 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 . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 0.
[^] # Re: Sortie de GCC 3.4.0
Posté par MiniMoi . Évalué à 1.
[^] # Re: Sortie de GCC 3.4.0
Posté par Troy McClure (site web personnel) . Évalué à 4.
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 . Évalué à -1.
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 . É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
Posté par Ayrton . Évalué à 0.
Merci d'aller dans mon sens.
[^] # Re: Sortie de GCC 3.4.0
Posté par Troy McClure (site web personnel) . Évalué à 1.
> 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 . Évalué à 1.
[^] # Re: Sortie de GCC 3.4.0
Posté par Ayrton . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: Sortie de GCC 3.4.0
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 4.
J'ai bon espoir que cette release apporte une solution.
[^] # Re: Sortie de GCC 3.4.0
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
[^] # Re: Sortie de GCC 3.4.0
Posté par Vincent Richard (site web personnel) . Évalué à 1.
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 Julien Wajsberg . Évalué à 1.
Les problèmes évoqués dans d'autres posts (lenteurs de la compilation, du code généré) proviennent aussi du fait que GCC ne peut pas utiliser certains algorithmes protégés par brevet, par ... IBM notamment :/
# Re: Sortie de GCC 3.4.0
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
GCC 2.95.x <-> libstdc++-3
Après la libstdc++-v3
GCC 3.0.x <-> libstdc++.so.3
GCC 3.1.x <-> libstdc++.so.4
GCC 3.2.x et 3.3.x <-> libstdc++.so.5
GCC 3.4.x <-> libstdc++.so.6
Les changements d'ABI nécessitent de recompiler toutes les parties C++ avec un même compilo.
[^] # Re: Sortie de GCC 3.4.0
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Est-ce que ça veut dire que finalement, la 3.4 a encore cassé la compatibilité ?
[^] # Re: Sortie de GCC 3.4.0
Posté par Bouiaw . Évalué à 4.
[^] # Re: Sortie de GCC 3.4.0
Posté par Dais Starry . Évalué à 0.
J'T'AI CASSÉ !!!!!!!!
</mode Brice de Nice>
[^] # Re: Sortie de GCC 3.4.0
Posté par N-Mi . Évalué à 2.
Ton commentaire est comme le H de Hawaï...
... il sert à rien!
Ah j't'ai cassé là!
</mode Brice de Nice>
[^] # Re: Sortie de GCC 3.4.0
Posté par MiniMoi . Évalué à 0.
< mode id="Brice de Nice" > c est mieux...
je sais, je sais... -----> [ ]
[^] # Re: Sortie de GCC 3.4.0
Posté par Moby-Dik . Évalué à 0.
Vector MMX and SSE operands are now passed in registers to improve performance and match the argument passing convention used by the Intel C++ Compiler. As a result it is not possible to call functions accepting vector arguments compiled by older GCC version.
http://gcc.gnu.org/gcc-3.4/changes.html(...)
à la rubrique "IA-32/AMD64 (x86-64)"
# Utilité des "Precompiled Headers" peu convaincante...
Posté par jerome_davanne . Évalué à 3.
Bref, les "precompiled headers" ne sont utilisables que très rarement, dommage!
En outre, il faudrait rassembler de nombreux de header en un seul all.h pour que cela soit intéressant et l'inclure au début de chaque .c ou .cpp...
Est ce que quelqu'un voit l'utilité ?
[^] # Re: Utilité des "Precompiled Headers" peu convaincante...
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
#define printf autrechose
#include <stdio.h>
la sémantique du #include est completement modifiée par le #define au dessus.
Donc, tu te fais un all.h avec tout les trucs que tu utilises souvent, et tu le précompile.
[^] # Re: Utilité des "Precompiled Headers" peu convaincante...
Posté par Pierre . Évalué à 1.
Dans codewarrior, le precompiled header etait carrement dans la configuration de compil (genre une option de gcc --precompiled=all.pch )
L'avantage de ce truc c'est que tu fait un gros all.h, que tu precompile, et ensuite, ya rien a changer dans le code source, le principe des guardiens (#ifdef _STDIO_H_ ) joue, et les header qui sont dans all.h sont sautes. De memoire, ca, optimisait vraiment les temps de compil pour les projets avec beaucoup de headers (typiquement le C++)
Par contre, evidement, la consomation memoire n'est pas vraiment optimisee.
Je n'y connais pas vraiment en compilateur, mais je vois pas pourquoi ca a mis si longtemps a arriver.
Heureusement que Apple est la pour implementer ce genre de features.. Car rappelons que c'est Apple qui a remonte ce developpement.
[^] # Re: Utilité des "Precompiled Headers" peu convaincante...
Posté par xavier . Évalué à 1.
que d'apres ce qui est dit les directives preproc sont utilisables avant
l'include de l'header precompilé... cette reponse simple l'est un peu trop :-)
# Re: Sortie de GCC 3.4.0
Posté par seminoob . Évalué à 1.
# Re: Sortie de GCC 3.4.0
Posté par Laurent GUERBY (site web personnel) . Évalué à 3.
[^] # Re: Sortie de GCC 3.4.0
Posté par Cédric Chevalier (site web personnel) . Évalué à 0.
ça existe ?
Bon je vais rejoindre Brice (Vive le grand air à Lacanau Beach)!
[^] # Re: Sortie de GCC 3.4.0
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Donc bon, effectivement Ada c'est suant à mettre en oeuvre, mais une fois que ça compile, aye aye aye !!! :-)
[^] # Re: Sortie de GCC 3.4.0
Posté par Monsieur Flynn . Évalué à -1.
moi aussi j'ai plein de bons souvenirs d'ADA mais moi ca fait que 5 ans et pas 8 :)
( et aussi grâce à ce fabuleux professeur :) qui savait comme personne poussait
d'énorme gueulante en nous rappelant que sa petite fille qui était à la maternelle
comprenait mieux que nous :) ).
Dommage qu'il parte à la retraite d'ailleurs :) ..
allez IUT info d'aix en force :)..
JM
# Re: Sortie de GCC 3.4.0
Posté par kruskal . Évalué à -2.
Un header, c'est normalement cencé etre de la déclaration, pas de l'implémentation, ca n'a pas a etre compilé.
Mais voila, avec c++, on a les fonctions inline dans les classes (bon, c'est pas gravissime quand c'est juste un accesseur qui fait un simple return) mais surtout, on a toutes les fonctions et classes templates, et ca c'est tres gros (std::list soit bien faire son millier de lignes)
C++ est vraiment mal foutu de ce point de vue la. Quitte a foutre du code dans les headers, autant ne plus faire de headers du tout et mélanger ca allegrement, comme en Java par exemple.
[^] # Re: Sortie de GCC 3.4.0
Posté par TazForEver . Évalué à 1.
ce n'est pas parce que ni toi, ni ton compilateur et ni ton Java (SAPUSPALIBRE) n'ont de notion d'inlining et que Java rajoute une sauce template qui n'en a que le nom (macro pour pas avoir à caster) qu'il faut critiquer un langage et ses techniques de compilations qui fournissent des programmes binaires très efficaces.
Beaucoup évoquent des problèmes de dépendances de compilation infernales : souvent c'est dû à des include mal placés et/ou à une mauvaise utilisation des template.
[^] # Re: Sortie de GCC 3.4.0
Posté par kruskal . Évalué à 0.
Pour ce qui est de _mon_ java, sache que je n'utilise pas ce langage, mais ca m'empeche pas de voir ce qu'il a de bien ou pas a coté.
C++ est peut etre efficace et tres puissant, OK, mais je constate juste que coté sémantique des headers, c'est mal foutu, ca n'a plus la fonction d'interface.
Il me semble par exemple qu'eiffel supporte la généricité de maniere plus propre par exemple.
[^] # Re: Sortie de GCC 3.4.0
Posté par Epsos . Évalué à 0.
Certes, elles ont l'immense avantages (par rapport au macro) d'etre type checkee, mais au niveau de la compilation elle meme, le resultat est strictement identique : duplication partout.
Les template java ont l'avantage (et le desavantge) d'etre partagee.
Si on est adepte c++ on dira qu'elles ne peuvent etre optimisees independamment les unes des autres. Si on est adepte Java, on dira que ca fait un gain de place.
Bon il y a pleins d'autres limitations aux template Java, mais ce n'est pas le sujet.
Sinon pour le gros jaloux du poste en dessous, sache petit scarabee que depuis la norme C ISO 89 et ANSI 90, le mot clef "inline" fait partie du langage C : alors garde tes trolls pour toi ! :-)
[^] # Re: Sortie de GCC 3.4.0
Posté par dilbert78900 . Évalué à 1.
Ca n'est donc pas une limitation du langage, mais bien du compilo.
# Pardon pour mon ignorance
Posté par mosfet . Évalué à 1.
Je sais ca perd tout l'interer du language mais c'est juste par curiosité.
[^] # Re: Pardon pour mon ignorance
Posté par mosfet . Évalué à 1.
GCJ is a portable, optimizing, ahead-of-time compiler for the Java Programming Language. It can compile:
* Java source code directly to native machine code,
* Java source code to Java bytecode (class files),
* and Java bytecode to native machine code.
[^] # Re: Pardon pour mon ignorance
Posté par peau chat . Évalué à 1.
Si tu prends un soft java, et que tu essayes de le compiler en natif avec GCJ, ça ne marchera pas dans 99% des cas.
[^] # Re: Pardon pour mon ignorance
Posté par Epsos . Évalué à 1.
# Compiler pour AMD64 ?
Posté par Yann Forget . Évalué à 1.
J'essaie de recompiler sur mon Opteron et j'obtiens:
/tmp/ccUYGAci.s: Assembler messages:
/tmp/ccUYGAci.s:33: Error: `completed.1(%rip)' is not a valid 32 bit base/index expression
/tmp/ccUYGAci.s:34: Error: suffix or operands invalid for `push'
/tmp/ccUYGAci.s:35: Error: suffix or operands invalid for `movq'
/tmp/ccUYGAci.s:41: Error: `p.0(%rip)' is not a valid 32 bit base/index expression
/tmp/ccUYGAci.s:44: Error: `p.0(%rip)' is not a valid 32 bit base/index expression
/tmp/ccUYGAci.s:45: Error: `(%rax)' is not a valid 32 bit base/index expression
/tmp/ccUYGAci.s:48: Error: `completed.1(%rip)' is not a valid 32 bit base/index expression
/tmp/ccUYGAci.s:60: Error: suffix or operands invalid for `push'
/tmp/ccUYGAci.s:61: Error: `__JCR_LIST__(%rip)' is not a valid 32 bit base/index expression
/tmp/ccUYGAci.s:62: Error: suffix or operands invalid for `movq'
make[1]: *** [crtbegin.o] Error 1
make[1]: Leaving directory `/usr/local/src/gcc/gcc-3.4.0/gcc'
make: *** [all-gcc] Error 2
Une idée ?
Par avance, merci.
[^] # Re: Compiler pour AMD64 ?
Posté par kruskal . Évalué à 2.
Apparement, ton as ne reconnait pas le jeu d'instruction k8, essaye voir de le mettre a jour en activant le support de l'opteron.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.