Sortie de GCC 4.0

Posté par  (site web personnel) . Modéré par Amaury.
Étiquettes :
0
22
avr.
2005
Technologie
La nouvelle version majeure du compilateur GCC du projet GNU (GNU Compiler Collection) vient de sortir.

Le grand changement est l'intégration de la technologie SSA (Static Single Assignement). Cela permet de faire une analyse abstraite du code source afin d'obtenir des optimisations générales et non plus de se limiter aux boucles précises et autres parties du code. C'est une amélioration majeure de l'architecture de GCC qui est ainsi mise en place pour le bénéfice de tous les utilisateurs du compilateur libre.

Il est à noter que cette version 4.0 ne sera que marginalement plus performante que le GCC actuel car le travail a porté surtout sur l'intégration propre et correcte de l'infrastructure tree-SSA. Les améliorations seront bien plus visibles avec la sortie de la 4.1 qui verra l'arrivée de l'autovectorisation et d'autres nouvelles techniques uniquement permises par tree-SSA.

Par contre il semble bien que la vitesse de compilation ait grandement été améliorée dès cette version 4.0 (plus de 20% avec le C++ dans certains cas).

Aller plus loin

  • # À quand son utilisation partout ?

    Posté par  . Évalué à 4.

    Actuellement, debian stable utilise gcc 2.95
    La plupart des distributions utilisent gcc 3.2 ou 3.3...
    Quand est-ce-que toutes les distributions utiliseront gcc 4.0 par défaut ? D'ici 3 ans, histoire que gcc 5.0 soit là avec d'autres "strictitudes" en plus ?
    Parce que trop d'applications ne compilent pas avec gcc4, et certaines ne passent même pas sur gcc3.4 ! Quand toutes les distribs utiliseront gcc4, toutes les applis seront "obligées" de compiler dessus...
    Mais d'ici là, comment feront ceux qui font une LFS et qui veulent compiler plus vite (et profiter de -fvisibility) ? Patcher tous les programmes pour ça est tout sauf marrant !

    • [^] # Re: À quand son utilisation partout ?

      Posté par  (site web personnel) . Évalué à 6.

      Bah Fedora et Ubuntu utilisent déjà et Mandriva ca va se faire dans les jours qui viennent...

    • [^] # Re: À quand son utilisation partout ?

      Posté par  (site web personnel) . Évalué à -8.

      Actuellement, debian stable utilise gcc 2.95

      Lol \O/

      • [^] # Re: À quand son utilisation partout ?

        Posté par  . Évalué à 1.

        Actuellement, debian stable utilise gcc 2.95

        Lol \O/

        Dans les cas d'utilisations courants, GCC 2.95 n'a pas à rougir de GCC 3.x. Il est bien plus rapide que la série 3.x, pour des performances proches.

        • [^] # Re: À quand son utilisation partout ?

          Posté par  . Évalué à 5.

          Pour compiler du C ou du C++ c'est vrai ca suffit ! Pour le reste ADA, java les versions 3 sont indispensables.
          Cela dit gcc 2.95 est resté dans les annales comme le premier gcc qui compilaient les templates sans fautes....

        • [^] # Re: À quand son utilisation partout ?

          Posté par  . Évalué à 6.

          > Dans les cas d'utilisations courants, GCC 2.95 n'a pas à rougir de GCC 3.x. Il est
          > bien plus rapide que la série 3.x, pour des performances proches.

          Bien plus rapide oui, je veux bien te l'accorder. Pour compiler du C, gcc 2.95 convient parfaitement. Mais pour du C++ c'est autre chose : non seulement gcc 2.95 est relativement éloigné de la norme c++ (notamment au niveau de la bibliothèque standard), mais cette norme a aussi évolué entre temps. Pour développer en C++ propre, utiliser gcc 2.95 serait une erreur.

          C'est vrai que gcc 3.x est très lent en c++, mais depuis gcc 3.4 on peut utiliser les en-têtes précompilés, et côté vitesse de compilation, ça change la vie ! \o/

          • [^] # Re: À quand son utilisation partout ?

            Posté par  (site web personnel) . Évalué à 6.

            > Pour développer en C++ propre, utiliser gcc 2.95 serait une erreur.

            Je dirai meme, pour developpe en C++ standard, utiliser n'importe quel compilateur est une erreur. En effet, il n'existe a ce jour aucun compilateur qui supporte completement et correctement l'integratlite de la norme C++.

            Du coup, on se demande a quoi sert cette norme.

    • [^] # Re: À quand son utilisation partout ?

      Posté par  (site web personnel) . Évalué à 10.

      >> Parce que trop d'applications ne compilent pas avec gcc4, et certaines ne passent même pas sur gcc3.4 !

      est-ce la faute de GCC ou de ces applis ? GCC respecte la norme ISO pour le C et donc les applis (si elles se conforment à la norme internationale) devraient compiler.
      En plus ce que tu nomme "strictitude" moi je le nomme "moyen-d'encourager-la-propreté-des-codes" ;-)

      c'est en étant plus strict qu'on detecte des erreurs et des saletés cachées dans les sources.

      • [^] # Re: À quand son utilisation partout ?

        Posté par  . Évalué à 5.

        Oui tout à fait.
        Pour moi, strict n'est pas vraiment négatif, surtout dans le cas d'un langage de programmation

      • [^] # Re: À quand son utilisation partout ?

        Posté par  . Évalué à 6.

        > est-ce la faute de GCC ou de ces applis ? GCC respecte la norme ISO
        > pour le C et donc les applis (si elles se conforment à la norme
        > internationale) devraient compiler.

        En pratique, j'ai pas l'impression que ce soit le C qui pose le plus de problèmes (là je pense que l'ISO est à peu près connu... encore que, tu prends le noyau, les patchs pour gcc4 étaient nombreux ces derniers mois, comme l'ont été il y a un moment ceux pour gcc3.4 un temps, et les autres avant), mais plus le C++. J'ai l'impression que là, pour pas mal de programmeurs, le standard en vigueur c'est vraiment ce qui compile avec leur g++ du moment.

    • [^] # Re: À quand son utilisation partout ?

      Posté par  . Évalué à 4.

      "Debian stable utilise 2.95. "

      A l'époque, où Woody est sorti (c'est vrai c'était il y a 3 ans !!) gcc 3 avait encore quelques casseroles.

    • [^] # Re: À quand son utilisation partout ?

      Posté par  . Évalué à 6.

      > Quand toutes les distribs utiliseront gcc4, toutes les applis seront "obligées" de compiler dessus..

      J'aurais tendance à dire « vivement qu'*une* distrib utilise gcc 4, comme ça la plupart des applis compileront avec »

      > comment feront ceux qui font une LFS et qui veulent compiler plus vite ? Patcher tous les programmes pour ça est tout sauf marrant !

      Il suffit qu'il y ait une personne utilisant une LFS qui envoie un patch aux mainteneurs, comme ça tout le monde en bénéficie...

      > (et profiter de -fvisibility)

      Yay, -O3 -march=xxx -mcpu=xxx est mort, long vie à -fvisibility, lanouvelle option de la mort qui tue qui fait aller un 486 à la vitesse d'un p4!!

      • [^] # Re: À quand son utilisation partout ?

        Posté par  . Évalué à 2.

        > J'aurais tendance à dire « vivement qu'*une* distrib utilise gcc 4, comme ça la plupart des applis compileront avec »

        FC4 (sortie pour début juin) utilise gcc 4 par défaut. Je n'ai pas connaissance de paquet qui ne soit pas compilé avec gcc 4.0. Ça ne va pas sans effort, il y a quelques patchs pour corriger quelques applis.

    • [^] # Re: À quand son utilisation partout ?

      Posté par  . Évalué à 10.

      Actuellement, debian stable utilise gcc 2.95
      comme dirait Keith Packard on dit pas "Debian Stable" mais "Debian Stale"

    • [^] # Re: À quand son utilisation partout ?

      Posté par  . Évalué à 3.

      > Mais d'ici là, comment feront ceux qui font une LFS et qui veulent
      > compiler plus vite (et profiter de -fvisibility) ? Patcher tous les
      > programmes pour ça est tout sauf marrant !

      Quel est l'intérêt de recompiler son système parce qu'un nouveau gcc est sorti, déjà...

      Mais quitte à gâcher du temps et de l'énergie, autant contribuer au libre et envoyer les corrections à ces gorets.

      C'est ce que je fais pour Ubuntu. Les logs de compilation de dia me donnent encore froid dans le dos...

    • [^] # Re: À quand son utilisation partout ?

      Posté par  . Évalué à 4.

      "Parce que trop d'applications ne compilent pas avec gcc4, et certaines ne passent même pas sur gcc3.4 ! "
      Ah... alors je dois rever car mon system tourne tres bien... j'ai une gentoo mon compilo est un gcc3.4... et mon system fonctionne... de plus (mais la je ne parles pas en connaissance de cause) certaines personnes sont passé en GCC 4 et arrive à tout compiler (bon c'est vrai qui y'en a qui n'y arrivent pas ;)
      Tu as une LFS et tu connais des deboir avec GCC3.4 pour dire ca ? (ton non agressif hein !)

      • [^] # Re: À quand son utilisation partout ?

        Posté par  . Évalué à 2.

        Alors, je ne fais que lister (sans retester) : la glib (version 1.2.10), monkey-bubble et SDL
        Je sais c'est peu... Mais j'ai pas testé sur tous les paquets du monde !

        • [^] # Re: À quand son utilisation partout ?

          Posté par  . Évalué à 3.

          Oula, la glib 1.2.10 c'est pas gagné pour qu'elle soit corrigée... :-/

        • [^] # Re: À quand son utilisation partout ?

          Posté par  (site web personnel) . Évalué à 4.

          Il fait quoi comme erreur avec Monkey Bubble ?

          Etant le developpeur de monkey bubble, je peux peut etre fixer ça facilement.

        • [^] # Re: À quand son utilisation partout ?

          Posté par  . Évalué à 2.

          Mon système est basé sur une LFS, et tout ce petit monde est patché pour au moin gcc 3.4.3.
          Il suffit de regarder sur BLFS (pour glib par exemple) ou chercher "ebuild package" sur Google (pour SDL par exemple), et d'aller dans le répertoire contenant les patches (files en général).

          Les seuls packs que j'ai pas pu recompiler avec gcc 3.4.3, ce sont ceux de Gnomemm, surtout libglademm (le dernier 2.6.0). Je ne sais pas où est la régression, mais comme j'ai pas le temps pour ça ...

          En revanche, avec GCC 4.0, c'est pire.
          glib-1.2.10 compile sans souci, mais c'est pas le plus important.
          Le pire, c'est que la glibc 2.3.5 vient de sortir, mais elle ne compile pas avec GCC 4.0. Les patches sont sortis (cf le site DIY Linux pour les hardcores comme moi pour qui LFS c'est un jeu pour enfants ;) ), mais je préfère attendre la sortie de glibc 2.3.6, qui va sortir, à ce que j'ai compris, rapidement, et exprès pour compiler avec gcc 4.0 !! Si c'est vrai, ça fera trois sorties de glibc très rapprochée, du jamais vu (surtout qu'avant, la 2.3.3 avait été sautée).

          A mon avis, le -fvisibility ne sert que pour certaines biblio pour le desktop, pas besoin de tout recompiler !!
          J'ai recompilé tout Gnome 2 avec. Pas trop difficile, le bug le plus courant est une déclaration en non statique, suivi d'une définition statique.
          QT et KDE j'ai même pas essayé, car c'est vivement découragé partout (je vais essayer quand même tiens !).
          Ce qui m'a fait le plus suer, c'est SDL, où il faut faire de sacrés modifs (parce que je ne maîtrise pas les alias de fonctions, celles-ci étant en assembleur ...).

          J'ai fait tout ça car je voulais me préparer un bootcd pour mon Linux à moi, en gcc4, mais c'est pas pour demain, je vais rester en gcc 3.4.3 pour le bootcd pour l'instant.

      • [^] # Re: À quand son utilisation partout ?

        Posté par  (site web personnel) . Évalué à 2.

        Je suis un fervent utilisateur de LFS/BLFS et je recompile (trop) souvent les OS de mes machines, surtout depuis que j'ai automatisé la chose. A ma connaissance, la seule application qui ne compile pas avec gcc 3.4 et qui n'a pas été patchée c'est openoffice.org 1.1.x, mais ça n'est pas bloquant puisqu'il suffit d'installer gcc 3.3 à coté du compilo principal pour avoir un OOo parfaitement fonctionnel.

  • # brevet...

    Posté par  . Évalué à 10.

    "Unfortunately we cannot implement Steensgaard [pointer] analysis due to patent issues."

    Remerciez nos amis MS pour avoir deposé un brevet ( http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HIT(...) )

    • [^] # Re: brevet...

      Posté par  . Évalué à 10.

      j'ai regardé ce brevet, et me suis dit "argggghhhhhhhhhhhhh c'est ca un brevet logiciel ??? c'est totalement incomprehensible, illisible, rempli d'infos totalement débile et structuré / présenté d'une manière certainement dicté par la conformité avec la législation (la formule magique pour qu'il soit accepté ?)"

      Je ne saurais meme pas déterminer en moins d'une semaine si un code correspond au brevet ou non ...

      En tout cas le prochain crétin qui me dit que les brevets log pourrait favoriser l'innovation, je l'envois en lire des comme ca, il comprendra ca douleur.

      Faut vraiment pas que de telles horreurs soient légales en Europe.

    • [^] # Re: brevet...

      Posté par  . Évalué à 4.

      Ils ne pourraient pas faire une version pour les pays qui de reconnaissent pas [encore] les brevets logiciels ?
      Ca fait quand même une grosse base d'utilisateurs...

      • [^] # Re: brevet...

        Posté par  . Évalué à 3.

        « Ils ne pourraient pas faire une version pour les pays qui de reconnaissent pas [encore] les brevets logiciels ? »

        Ca ne devrait pas être reformulé en « une version pour les pays où cette techno n'est pas brevetée » ? J'imagine qu'il peut y avoir des pays reconnaissant les brevets logiciels mais où Ms n'a pas déposé un tel brevet.

        • [^] # Re: brevet...

          Posté par  . Évalué à 7.

          Le pire, c'est que le contraire existe certainement aussi: des pays où les brevets logiciels ne sont pas reconnus mais où des entreprises en obtiennent quand même... des pays d'Europe par exemple :-/

    • [^] # Re: brevet...

      Posté par  . Évalué à 6.

      Et ... c'est quoi le « Steensgaard [pointer] » ?

  • # explication sur le ssa

    Posté par  . Évalué à 5.

    Sur slashdot, y a une personne qui a poste des transparents que j'ai trouve pas mal : http://copland.udel.edu/~jan/ssa-presentation.pdf(...)

    • [^] # Re: explication sur le ssa

      Posté par  . Évalué à 3.

      En plus c'est fait avec des chose Quellessontbien TM !

      /Creator(LaTeX with beamer class version 3.01)/Producer(pdfeTeX-1.21a)

      /PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)

      • [^] # Re: explication sur le ssa

        Posté par  . Évalué à 2.

        En tout cas ils sont beaux ;)
        T'as les noms exacts des softs qu'ont été utilisés pour ça ? J'imagine que ça peut être extrait des divers noms que t'as copié, mais je sais pas exactement lesquels sont significatifs ;) (j'imagine latex + la classe beamer, mais quid de pfdetex par ex ?)

        • [^] # Re: explication sur le ssa

          Posté par  . Évalué à 2.

          Non, désolé, je connais pas trop latex & co...
          J'ai juste regardé par curiosité, pour voir si j'allais trouvé un quelconque Powerpoint + Adbobe qqchose, ou encore des softs Mac (vu dans un pdf émis par Microsoft qui "comparait" son Office avec OOo...)
          Je pense que Google avec quelques mots clés savamment choisis parmis les tags ci-dessus devraient t'aider...
          pdfetex renvoie plein de choses en tout cas...

        • [^] # Re: explication sur le ssa

          Posté par  (site web personnel) . Évalué à 4.

          C'est du beamer tout ce qu'il y a de plus classique : http://latex-beamer.sourceforge.net/(...)

          Le style correspond presque à l'exemple. (j'ai pas encore utilisé beamer)

          pdfetex, c'est le moteur normal de pdflatex, donc rien de bien surprenant (etex etant une extention de tex, pdfetex etant la version pdf de etex, avec la couche latex, ca donne pdfelatex, en mode comptatibilité, ca donne pdflatex). Pareil pour kpathsea.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # gcc = g++ gcc et gjc et libgcj ?

    Posté par  (site web personnel) . Évalué à 3.

    Je soupsonne aussi bcp d'innovation coté java, le projet gcj classpath ...

    Une fonctionalité qui me manque c'est de pouvoir produire des lib dynamiques C++ linkable avec d'autre compilo (au hazard msvc?) ...

    gpg:0x467094BC

    • [^] # Re: gcc = g++ gcc et gjc et libgcj ?

      Posté par  . Évalué à 5.

      Pour les lib dynamiques C++ linkables avec celles produites par d'autres compilo, c'est sans doute une très mauvaise idée.

      1. L'utilisation des classes templates changent d'un compilo à l'autre puisque ce n'est pas la même STL. Le link peut donc éventuellement bien se passer, mais la manipulation des objets (std::string par exemple) peut être catastrophique pour l'intégrité des données.

      2. A moins d'une ABI C++ normalisée par un comité ANSI ou autre, comment être sûr d'une interopérabilité stable *et* durable ?

      3. Plus encore que l'ABI, il faudrait que la représentation intrinsèque de l'objet (ie sa représentation en mémoire) soit la même. Donc même format de vtable, même codage des infos de typage dynamique, etc.

      Bref, compliqué ! Notes d'ailleurs que même un compilateur comme MSVC est incompatible entre ses différentes versions, comme par exemple entre la version 6 et la version 7 (.NET). J'en garde d'assez mauvais souvenirs ! Alors l'interop entre des compilos différents, oublies !

      • [^] # Re: gcc = g++ gcc et gjc et libgcj ?

        Posté par  . Évalué à 4.

        C'est quoi l'ABI pour toi si ce que tu décris en 3 ça fait pas partie de l'ABI ?
        Pour info, depuis gcc 3.qqchose, l'ABI c++ est censée être stable et à peu près normalisée car basée sur une ABI définie par Intel (je crois) entre autres. Ca n'empêche pas qu'ils trouvent toujours le moyen de faire des petits changements (dûs à des bugs) d'une version à l'autre de gcc :(
        Mais tout espoir n'est pas perdue pour une interoperabilité! :)
        Le C c'est quand même bien pour ça, y a pas tous ces pbs...

        • [^] # Re: gcc = g++ gcc et gjc et libgcj ?

          Posté par  . Évalué à 1.

          Au temps pour moi ; les points 2 et 3 concernent tous les 2 l'ABI. Je ne pensais pas que l'ABI englobait la représentation interne des donées.

    • [^] # Re: gcc = g++ gcc et gjc et libgcj ?

      Posté par  (site web personnel) . Évalué à 3.

      Bah alors je pense que la lecture de : http://lwn.net/Articles/129914/(...) et surtout GCJ 4 enhancements est fortement conseillé. Tu soupconnes bien :)

      • [^] # Re: gcc = g++ gcc et gjc et libgcj ?

        Posté par  . Évalué à 7.

        si je reprends ce qui est dit sur lwn :

        Probably the most visible enhancement of GCJ 4 comes from merging the libgcj runtime with the GNU Classpath core class library project. By collaborating with other free runtimes like the traditional kaffe environment and around 20 other projects, GCJ 4 is able to offer a core class library comparable to JDK 1.3 or 1.4. The collaboration of all these projects on a common core library implementation means that a lot of the libraries needed by applications, except for advanced Swing, Corba and sound usage, are available out of the box.

        Ouais \o/ on se rapproche de Sun !
        Swing c'est vraiment un gros morceau, je sais pas exactement où ils se sont arretés.

        The other big change is the addition of the -findirect-dispatch switch to the compiler. Using that option causes GCJ to generate native code for classes and methods that follow the precise same binary compatibility rules as described in the Java Language Specification
        Le PDF ftp://gcc.gnu.org/pub/gcc/summit/2004/GCJ%20New%20ABI.pdf(...) est _très_ intéressant sur le sujet.

        Les points à venir dans GCJ :
        - le début de l'équivalence JDK 1.5 (generics par exemple)
        - le support accru des distribs (Fedora et Debian) pour un environnement Java libre et de qualité, par ex via http://www.jpackage.org/(...)
        - le fait que de plus en plus de projets Java Open Source supportent l'initiative GCJ en utilisant le plus possible de libs documentées dans l'API standard (cela vient aussi du transfert de packages en "com.sun" vers "java.*", par ex les proxy auth ou jmx)

        • [^] # Re: gcc = g++ gcc et gjc et libgcj ?

          Posté par  . Évalué à 3.

          Swing c'est vraiment un gros morceau, je sais pas exactement où ils se sont arretés.

          Il suffit d'aller voir sur le site de classpath http://www.gnu.org/software/classpath/classpath.html(...) , plus particulièrement les status par comparaison aux différentes versions du jdk, par exemple pour le 1.4 on a http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html(...) et on voit qu'il y a déjà un bon morceau de swing qui est implémenté. PAr contre rien n'est encore commencé pour javax.sound et les packages en org.omg sont à peine entamés.

          Au total il en sont (au moment où j'écrit, c'est mis à jour toutes les nuits) ils estiment avoir implémenté 90% du jdk 1.4 (mais ça fait également 82% du 1.3 et 85% du 1.2). Le jdk 1.1 est complètement implémenté (à 0.2% près et en négligeant les incompatibilités vis-à-vis des versions récentes).
          Il est amusant de voir par contre que le jdk 1.0 n'est implémenté qu'à 91% à cause du manque du package java.awt.peer qui a disparu des versions suivantes.

          Je garde un oeil dessus depuis un an (je travaille justement en java) et classpath à considérablement évolué ces derniers mois! (probablement grâce à l'implication de Redhat)

    • [^] # Re: gcc = g++ gcc et gjc et libgcj ?

      Posté par  . Évalué à 4.

      G++ utilise la 'common vendor ABI' ( http://www.codesourcery.com/cxx-abi/(...) ) qui a pour but de permettre ce genre de chose. Malheureusement pour toi MS n'a semble t-il pas l'intention d'adhérer à cette ABI (peut-être que ce n'est techniquement pas possible, je ne dis pas qu'ils y mettent de la mauvaise volontée).
      Pour le boulot j'avais essayé de faire cohabiter des libs C++ mingwin et msvc sans succès ; par contre ca marche bien avec du code C (ming|cyg)win et une DLL C++ msvc.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.