GCC 3.1.1

Posté par  . Modéré par Manuel Menal.
Étiquettes :
0
2
août
2002
GNU
GCC 3.1.1 est passé en release le 26 juillet 2002. Ce sera la dernière version de la série des 3.1 et la branche de dévelopement sera renommée 3.2

Il s'agit d'une version de bugfix uniquement. Au programme, donc, un grand nombre de corrections de bugs, évidemment en majorité au niveau des deux compilateurs les plus utilisés de la GNU Compiler Collection (la nouvelle signification de l'acronyme GCC, nécessitée par son évolution en bien plus qu'un compilateur C), les compilateur C (gcc) et C++ (g++), mais aussi sur les compilateurs Objective C (gobjc) et Java (même si en moindre nombres), montrant que ces projets aussi ne sont pas morts.

Il est aussi intéressant de voir qu'il existe des ports *maintenus* pour des architectures "exotiques", comme CRIS (un processeur embarqué). Cela montre à quel point GCC est répandu dans tous les milieux, et comment un logiciel libre a réussi à devenir *la* référence dans un monde pas forcément ouvert.

NdM: comme signalé dans les commentaires, je me suis laissé tromper par l'auteur de la news présentant les changements de la série 3.1 comme ceux de la version 3.1.1. Mea culpa, j'espère que cet oubli est maintenant réparé. Sinon, l'ABI C++ devrait quand même se stabiliser pour le 3.2 :-)

Aller plus loin

  • # L'ABI Change encore ???

    Posté par  . Évalué à 6.

    C'est du delire la, cela veut dire qu'il va y avoir encore des problems de libc compiler avec la version X de gcc ???

    c moyen quand meme, si qq1 a des infos la dessus ...
    • [^] # Re: L'ABI Change encore ???

      Posté par  . Évalué à 10.

      L'ABI _C++_ change, donc pas de problèmes pour la libc et tous les autres programmes écrits en C.

      Pour le C++ (qui suxor de toute façon ;) ) je ne connais pas l'ampleur des changements entre g++ 3.1.1 et les autres 3.x donc je ne sais pas si plus rien ne marchera (comme entre le 2.x et le 3.x) ou si juste dans certains cas bien précis il y aura qqes problèmes.
      • [^] # Re: L'ABI Change encore ???

        Posté par  . Évalué à -1.

        Pour le C++ (qui suxor de toute façon ;) )

        Le language ou l'implémentation par GCC ?
      • [^] # Re: L'ABI Change encore ???

        Posté par  . Évalué à 5.

        l'ABI c++ de gcc 3.2 sera encore incompatible avec celle du 3.1 (et celle des autres gcc) mais ce sera la derniere fois
        il est donc conseille de ne pas migrer en gcc 3.1.x (beaucoup de distributions vont passer directement de gcc 2.95 ou 2.96 a gcc 3.2)
    • [^] # Re: L'ABI Change encore ???

      Posté par  . Évalué à 10.

      Relis bien la news... L'ABI C++ concerne la compatibilité binaire entre les librairies standard C++, pas C. :-)
    • [^] # Re: L'ABI Change encore ???

      Posté par  . Évalué à 10.

      Premièrement c'est seulement l'ABI pour le C++ qui a changé avec la version 3.1
      Le posteur de la news est une taupe seulement le haut du changelog est pour gcc 3.1.1, le reste est pour 3.1. L'ABI C++ est resté (quasi) stable entre la version 3.1 et la révision 3.1.1 . Les seuls changement concernent des détails de l'ABI (ajustement sur les templates) mais les projets majeurs comme KDE ne sont pas concernés.

      Les modifs pour la 3.1.1:

      Additional changes in GCC 3.1.1

      * A bug related to how structures and unions are returned has been fixed for powerpc-*-netbsd*.
      * An important bug in the implementation of -fprefetch-loop-arrays has been fixed. Previously the optimization prefetched random blocks of memory for most targets except for i386.
      * The Java compiler now compiles Java programs much faster and also works with parallel make.
      * Nested functions have been fixed for mips*-*-netbsd*.
      * Some missing floating point support routines have beed added for mips*-*-netbsd*.
      * This message gives additional information about the bugs fixed in this release.

      Le message avec les détails des changements pour la 3.1.1:

      http://gcc.gnu.org/ml/gcc/2002-07/msg01208.html(...)

      dont la partie qui concerne les ajustements dans l'ABI C++ est décrite par les "(c++) ICE".

      Jolie tentative de troll mais on ne m'y prendra pas :)
      • [^] # Re: L'ABI Change encore ???

        Posté par  . Évalué à 5.

        dont la partie qui concerne les ajustements dans l'ABI C++ est décrite par les "(c++) ICE".

        Non, ICE = "Internal Compiler Error". Les fixes majeurs d'ABI C++ sont pour le 3.2
  • # GCJ

    Posté par  . Évalué à 10.

    Est-ce que quelqu'un l'a testé? (fut-ce sur un 3.1 tout court)...

    Ca donne quoi? Que peut-on faire avec? Que peut-on en éspérer pour l'avenir?
    • [^] # Re: GCJ

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

      > Que peut-on faire avec?

      --->> Sortir une distrib beta :)
      La 1ere des 2 limbo (c'est le nom des dernieres betas) de redhat tournait avec gcc-3.1. La seconde tourne avec une prerelease de gcc3.2. Gcc 3.2 dont la release est imminente (parait-il) sera le compilateur fourni avec la prochaine redhat (qui devrait etre une 8..)
      • [^] # Et Mandrake fait comme RedHat

        Posté par  . Évalué à -10.

        A croire qu'ils aiment toujours les copier.

        allez, -1

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Et Mandrake fait comme RedHat

          Posté par  . Évalué à 10.

          Ben non, tous les principaux distributeurs Linux (MDK, RedHat, SuSE, XXX?) avaient demandé à avoir une release de gcc3.2 qui contiendrait les fixes ABI du CVS courant. De fait, il y aurait cette fois-ci un espoir non nul d'avoir quelque chose de compatible quand gcc3.3 sortira. Cela motivé par le fait que ces distributions sortiront toutes vers septembre en gcc3.x based, d'où les délais courts.

          BTW, FreeBSD avait également demandé une telle release pour leur version 5.0.
      • [^] # Re: GCJ

        Posté par  . Évalué à 10.

        Euh, la question était sur _gcj_ (GNU Compiler for Java) et non _gcc_ (GNU Compiler Collection). A ma connaissance aucune distrib n'est basée sur un compilateur Java.

        Moi je n'ai testé gcj que rapidement il y a plus d'un an (les debian-prelease d'avant gcc 3.0), ça permettait de faire des choses, en particulier l'interaction C <=> Java marchait pas trop mal, mais ça ne supportait qu'une partie du Java et pas toujours très bien. Je ne sais pas ce que ça donne maintenant.
      • [^] # Re: GCJ

        Posté par  . Évalué à 4.

        Redhat indique que les différences en leur précédent gcc 3.1.1 et gcc 3.2 sont faible et qu'il aurai tort de ne pas prendre ce "risque", initialement non prévu pour Limbo.
    • [^] # Re: GCJ

      Posté par  . Évalué à 10.

      Ca donne quoi?
      un executable?

      -1 pour pompage de fortune mais j'ai pas pus resister :)
      • [^] # Re: GCJ

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

        ARRETES DE DIRE DES CONNERIES DANS LES NEWS ET MONTES DANS TA CHAMBRE !!!!!!!!!

        Sale gosse :)

        hop -1

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: GCJ

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

      Compiler mozilla corectement: http://bugzilla.mozilla.org/show_bug.cgi?id=145267(...)

      Ça provoquait par exemple que le curseur restait en début de ligne dans une case texte, c'est assez génant, fallait y aller a l'aveuglette
      • [^] # Re: GCJ

        Posté par  . Évalué à 5.

        Non, il parlait de Gcj. Le bug que tu décris était du à une mis-optimization de __builtin_memset apparue avec gcc3.1 et corrigée dans la branche pas longtemps après.

        Aucun distributeur sérieux n'a shippé de package gcc3.1 sans ce patch, de toutes façons. Donc c'est passé quasi inaperçu. ;-)
    • [^] # Re: GCJ

      Posté par  . Évalué à 10.

      Le problème, c'est que seule une (toute petite) partie des classes de sun est incluse dedans. L'autre problème, je crois, est un problème au niveau des performances, qui ne sont pas formidables (une appli compilée en executable natif tourne souvent moins vite que la même compilée par javac et tournant sur la jvm de sun).
      Mon rêve, ce serait de pouvoir utiliser les bindings java de kde avec gcj pour pouvoir dvper des applis kde natives en java.
      • [^] # Re: GCJ

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

        Mon rêve, ce serait de pouvoir utiliser les bindings java de kde avec gcj pour pouvoir dvper des applis kde natives en java.

        le même rêve que moi... :)
      • [^] # Re: GCJ

        Posté par  . Évalué à 2.

        Les problèmes de perfs sont connus, il vaut mieux une petite appli dont seule la partie active est déployée (cache de méthodes compilé natviement) que de tout avoir développé en mémoire en permanence.

        IBM a sorti un papier dessus (sur alphaworks ou sur developerworks, je sais plus).
        La compilation JIT est aussi un sujet controversé (voir la ML de O'Caml à ce sujet).
        Un bouquin à lire sur ce sujet : "Smalltalk On A Risc" (abrégé en SOAR) par David Ungar.
  • # ObjC++

    Posté par  . Évalué à -5.

    On veut chimera
    On veut chimera
    On veut chimera
    On veut chimera
    On veut chimera
    On veut chimera......

    http://chimera.mozdev.org/(...)

Suivre le flux des commentaires

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