GCC 3.1.1

Posté par sébastien boyart le 02 août 2002 à 02:14. Modéré par Manuel Menal.

Étiquettes :

août

2002

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

Les Release Notes de GCC 3.1.1 (3 clics)
Les changements de la série 3.1 (dont 3.1.1) (4 clics)
Le site de GCC (2 clics)

# L'ABI Change encore ???

Posté par psc le 02 août 2002 à 03:33. É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 Gaël Le Mignot le 02 août 2002 à 08:41. É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 boris le 02 août 2002 à 19:49. É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 Pascal Terjan (site web personnel) le 04 août 2002 à 00:52. Évalué à 1.
      
      Un peu les deux
  - [^] # Re: L'ABI Change encore ???
    
    Posté par Ja le 04 août 2002 à 16:37. É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 Franck Guillaud le 02 août 2002 à 08:42. É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 Schwarzy le 02 août 2002 à 09:16. É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 Gwenole Beauchesne le 02 août 2002 à 19:53. É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 Olivier M. le 02 août 2002 à 05:08. É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 Dams Nadé (site web personnel) le 02 août 2002 à 07:07. É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 ʭ ☯ le 02 août 2002 à 08:06. É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 Gwenole Beauchesne le 02 août 2002 à 19:18. É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 Gaël Le Mignot le 02 août 2002 à 08:43. É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 Dams Nadé (site web personnel) le 02 août 2002 à 08:46. Évalué à -2.
      
      Toute mes confuses j'avais pu le sujet de ton commentaire..
      je vais me flageller et je reviens..
      - [^] # Re: GCJ
        
        Posté par Dams Nadé (site web personnel) le 02 août 2002 à 08:47. Évalué à -4.
        
        s/pu/pas lu/
        
        Vais ptete prendre un cafe' ce matin moi :)
  - [^] # Re: GCJ
    
    Posté par matiasf le 02 août 2002 à 14:23. É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 kael le 02 août 2002 à 09:30. Évalué à 10.
  
  Ca donne quoi?
  un executable?
  
  -1 pour pompage de fortune mais j'ai pas pus resister :)
  - [^] # Re: GCJ
    
    Posté par Infernal Quack (site web personnel) le 02 août 2002 à 10:13. É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 Pierre Tramo (site web personnel) le 02 août 2002 à 10:24. É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 Gwenole Beauchesne le 02 août 2002 à 19:12. É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 jojolapin le 02 août 2002 à 21:48. É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 tanguy_k (site web personnel) le 03 août 2002 à 13:49. É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 Dugland Bob le 05 août 2002 à 15:25. É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 DiZ le 02 août 2002 à 11:09. É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.