Et l'optimisation du linker dynamique (je m'attends à être crucifié par les défenseurs de la langue française), a-t-elle été intégrée dans ce mélange?
Si tu entends par objprelink, non cela ne l'est pas au niveau glibc, et je n'en sais pas plus à d'autres niveaux.
Si tu entends par les optimisations de ld.so naturellement intégrées à partir de la glibc 2.2.5, ben oui. Quand je disais glibc 2.2.5 CVS c'était en fait glibc 2.2.5 + CVS, une sorte de glibc 2.2.6. Mais comme y'a des bouts du 2.3 CVS aussi donc c'est parti pour une glibc-2.2.5-RH comme l'était gcc-2.96-RH. ;-)
Parce qu'il disent quand même sur leur communiqué que c'est la version 2.2.4
Tout comme annonçaient-ils Mozilla 0.9.2. C'est bien une glibc-"2.2.5" selon leur liste de packages: http://www.redhat.com/software/linux/pl_rhl.html
Je ne pense pas que tu puisses parler ici, si tu l'as vue, de la roadmap actuelle d'Intel concernant ses outils (compilateurs - ICC, et profilers). Il me semble improbable qu'Intel contribue tout de suite à GCC. Mais on peut toujours espérer et apprécier que des éditeurs de compilateurs commerciaux puissent contribuer au développement de GCC. ;-)
Intel contribue cependant au développement du projet conjoint Intel - Institute of Computing Technology (en Chine) concernant ORC: Open Research Compiler.
Par contre, il y est bien fait mention dans les slides du MICRO-34 que l'intégration avec gcc3 n'est pas prévue, entre autres (optimisations concernant les opérations FP, possibilité de bootstrap, etc.).
Note: ORC est dérivé d'Open64 lui-même issu de feu Pro64 de SGI qui est dérivé de GCC. En clair, on a un vrai front-end compatible GCC et toutes ses extensions.
au niveau de la gestion des exceptions (segfault à répétition)
Ah, je suis sûr que tu as un testcase à envoyer. Merci.
Je déconseille l'usage conjoint de -Ox et -fomit-frame-pointer pour du code C++ faisant intervenir des exceptions. C'est effectivement un problème connu qui est aussi présent dans gcc-3.0.4 et des fixes seraient trop complexes à mettre en oeuvre pour la série 3.0.X.
Workarounds:
-Ox -fno-omit-frame-pointer
-Ox -fomit-frame-pointer -maccumulate-outgoing-args
(avec x >= 1)
RedHat utilise bien prelink, et pas objprelink, ça je peux confirmer (discussion avec bero de rh-de à ce sujet), mais prelink n'est pas installé...
Il me semble qu'en l'essence, prelink n'a pas d'intérêt s'il est installé par défaut pour ne rien faire. Ça devient intéressant après plusieurs exécutions. Du profiling en somme sur les relocations. Faudrait retrouver le message de Jakub sur les listes idoines.
par ailleurs, la fonctionnalité que tu décris (-z combreloc), inclue dans les binutils (glibc a également dû etre patché) est en fait une partie du "projet" prelink (je simplifie),
-z combreloc est une optimisation "usuelle". D'ailleurs, c'est dispo dans le linker de Solaris si je ne m'abuse.
objprelink et prelink ne fonctionnent pas de la même manière. Mandrake utilise objprelink, tandis que RedHat utilise prelink.
Non, on n'utilise pas objprelink. L'équipe KDE a essayé, ont vu que ça ne marchait pas, ont viré la chose. J'en sais rien pour RedHat.
Par contre, les binutils récents > 2.11.90.0.5 (quelque part en août dernier) contiennent une fonctionnalité (-z combreloc) que l'on (RH, Debian aussi) a activé par défaut. Cela permet de combiner les multiples sections de relocations, les trier (donc enlever les doublons pour le même symbole au passage) et ainsi accélérer la recherche des symboles
gcc 2.96 fait du c++ qui est plus proche de l'ISO par ailleurs (plus proche que gcc 2.95, mais moins que gcc 3)
Et gcc-3.0.x moins que gcc-3.1 d'ailleurs. Il est normal de tendre vers une meilleur compliance ISO au fil des versions.
ont-ils fait profiter les gens du GNU des bugs trouvés - et corrigés ? si oui, finalement, gcc 2.96 a aidé au développement de gcc 3...
Oui, c'est normal, la base de code compilée et testée avec le "2.96" est non négligeable par rapport au 3.0. Durant le développement de ce dernier des patches/testcases/autres ont été commités upstream.
Mais bon, vaut mieux se focuser sur le 3.1 maintenant...
et j'espere qu'ils en ont bien chie a patcher les softs (surtout ceux ecrits en C++) pour pouvoir les compiler.
Oui, corriger les erreurs dans le code des développeurs desdits softs.
Cependant je pense qu'on devrait le voir disparaitre dans la future release majeure de MDK (la 9.0?), car changer de gcc, c'est riquer de perdre la compatibilite binaire.
Exactement. gcc-3.1.X est un choix intéressant pour la 9.0/ix86.
KDE 3 pas totalement 2.95 compliant si tu me le demandes ...
gcc 2.95 pas totalement ISO/C++ compliant si tu me le demandes... "2.96" était déjà une évolution à l'époque, le 3.0.4 l'est encore plus et le 3.1 est bigrement intéressant.
Les prix à 6 chiffres sont pour les serveurs. Les petites workstations de HP (i2000) font entre 7500 et 8000 USD, IIRC.
L'architecture Itanium a, à mon avis, un fort potentiel. Le problème est que les compilateurs EPIC réllement optimisants ne courent pas les rues. D'ailleurs Intel va lancer dans pas longtemps le projet ORC (Open Research Compiler) basé sur feu Pro64 (mais ressuscité en Open64), lui même basé sur gcc.
> Le C défini 'int' comme 'le plus grand entier manipulé rapidement par la machine'.
Une citation a certainement une source, je ne la vois pas dans ton message. La norme dit en fait en 6.2.5 [#5]:
"A ``plain'' int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>)."
La norme parle de l'architecture du runtime, pas de l'architecture matérielle du processeur. Plus précisément, elle ne parle pas de registre du processeur. Mon interprétation est que l'implémenteur de compilateur se réfère aux conventions logicielles idoines de l'architecture cible (dépendante de l'OS et du processeur, évidemment).
Et, ô miracle, vois-je dans "IA-64 Software Conventions and Runtime Architecture Guide" en 4.1 (Data Representation, Fundamental types) que sizeof(int) vaut bien 4.
Concernant le "long", il est effectivement au moins aussi grand qu'un "int". Par contre, cela ne veut pas dire que ça fasse forcément 64 bits sur une archi 64 bits. En effet, mais là c'est le cas extrême des bizarreries, Microsoft a établi que le "long" resterait en fait à 32 bits sur ia64 (Windows XP 64 & co). Voir par exemple le "Quick Start Guide for Porting Applications for Win64" d'Intel...
Enfin, pour revenir au trucs rapidement manipulés par la machine. La norme définit en effet en 7.18.1.3, des entiers d'une certaine taille minimale qui peuvent généralement être manipulés rapidement. (cf. uint_fast32_t par exemple). Il ne s'agit pas de "int".
Concernant GCC 3.0.2, il ne compile toujours pas certaines parties de KDE correctement (arts). Il y aura cependant un patch à gcc-3.0.3 qui traînera dans le répertoire contrib/ des sources. Il s'agit d'un backport "direct" (i.e. sans trop se poser de questions, et intrusif) pour fixer 1 des bugs connus. Il en reste un autre encore. D'un autre côté, gcc-3.1 semble "KDE-able".
Pour la JVM, il s'agit de Kaffe (GPL) qui tourne en natif ia64 mais en mode interpréteur uniquement. i.e. pas de JIT. IBM propose la Beta 2 de son JDK pour Linux/ia64 mais également sans JIT. (http://www.alphaworks.ibm.com/tech/linuxsdk(...)). Quant à l'ORP d'Intel, ils annoncent toujours le port ia64 dans une prochaine version.
[^] # Re: glibc 2.2.4 (redhat 7.3) vs glibc 2.2.5
Posté par Gwenole Beauchesne . En réponse à la dépêche Sortie de la Red Hat 7.3. Évalué à 10.
[^] # Re: glibc 2.2.4 (redhat 7.3) vs glibc 2.2.5
Posté par Gwenole Beauchesne . En réponse à la dépêche Sortie de la Red Hat 7.3. Évalué à 10.
[^] # Re: Compilateur?
Posté par Gwenole Beauchesne . En réponse à la dépêche HP: un super ordinateur sous Linux. Évalué à 2.
Intel contribue cependant au développement du projet conjoint Intel - Institute of Computing Technology (en Chine) concernant ORC: Open Research Compiler.
Par contre, il y est bien fait mention dans les slides du MICRO-34 que l'intégration avec gcc3 n'est pas prévue, entre autres (optimisations concernant les opérations FP, possibilité de bootstrap, etc.).
Note: ORC est dérivé d'Open64 lui-même issu de feu Pro64 de SGI qui est dérivé de GCC. En clair, on a un vrai front-end compatible GCC et toutes ses extensions.
* ORC: http://ipf-orc.sourceforge.net/(...)
[^] # Re: ## GCC 2.96 N'existe PAS ! ##
Posté par Gwenole Beauchesne . En réponse à la dépêche La Mandrake 8.2 est sortie. Évalué à 4.
Ah, je suis sûr que tu as un testcase à envoyer. Merci.
Je déconseille l'usage conjoint de -Ox et -fomit-frame-pointer pour du code C++ faisant intervenir des exceptions. C'est effectivement un problème connu qui est aussi présent dans gcc-3.0.4 et des fixes seraient trop complexes à mettre en oeuvre pour la série 3.0.X.
Workarounds:
-Ox -fno-omit-frame-pointer
-Ox -fomit-frame-pointer -maccumulate-outgoing-args
(avec x >= 1)
Ce sera corrigé pour gcc-3.1. Cf. GNATS PR c++/2447 pour plus de détails: http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&d(...) . Il semble même que gcc-2.95.2 soit affecté. Cf. GNATS PR c++/144.
BTW, de toutes façons ce problème n'existe pas sur de vraies architectures, aka non x86-based. Mais bon, je ne voudrais pas partir en troll. ;-)
[^] # Re: ## GCC 2.96 N'existe PAS ! ##
Posté par Gwenole Beauchesne . En réponse à la dépêche La Mandrake 8.2 est sortie. Évalué à 2.
Il me semble qu'en l'essence, prelink n'a pas d'intérêt s'il est installé par défaut pour ne rien faire. Ça devient intéressant après plusieurs exécutions. Du profiling en somme sur les relocations. Faudrait retrouver le message de Jakub sur les listes idoines.
Les derniers sources de prelink devraient se trouver ici: ftp://people.redhat.com/jakub/prelink/(...) .
par ailleurs, la fonctionnalité que tu décris (-z combreloc), inclue dans les binutils (glibc a également dû etre patché) est en fait une partie du "projet" prelink (je simplifie),
-z combreloc est une optimisation "usuelle". D'ailleurs, c'est dispo dans le linker de Solaris si je ne m'abuse.
[^] # Re: ## GCC 2.96 N'existe PAS ! ##
Posté par Gwenole Beauchesne . En réponse à la dépêche La Mandrake 8.2 est sortie. Évalué à 5.
Non, on n'utilise pas objprelink. L'équipe KDE a essayé, ont vu que ça ne marchait pas, ont viré la chose. J'en sais rien pour RedHat.
Par contre, les binutils récents > 2.11.90.0.5 (quelque part en août dernier) contiennent une fonctionnalité (-z combreloc) que l'on (RH, Debian aussi) a activé par défaut. Cela permet de combiner les multiples sections de relocations, les trier (donc enlever les doublons pour le même symbole au passage) et ainsi accélérer la recherche des symboles
gcc 2.96 fait du c++ qui est plus proche de l'ISO par ailleurs (plus proche que gcc 2.95, mais moins que gcc 3)
Et gcc-3.0.x moins que gcc-3.1 d'ailleurs. Il est normal de tendre vers une meilleur compliance ISO au fil des versions.
ont-ils fait profiter les gens du GNU des bugs trouvés - et corrigés ? si oui, finalement, gcc 2.96 a aidé au développement de gcc 3...
Oui, c'est normal, la base de code compilée et testée avec le "2.96" est non négligeable par rapport au 3.0. Durant le développement de ce dernier des patches/testcases/autres ont été commités upstream.
Mais bon, vaut mieux se focuser sur le 3.1 maintenant...
[^] # Re: ah quoi ca sert une release ? :-)
Posté par Gwenole Beauchesne . En réponse à la dépêche La Mandrake 8.2 est sortie. Évalué à 4.
À quel niveau? Où puis-je trouver ton rapport de bug à ce sujet et le testcase qui va avec?
et non supporté (dans le sens aide).
Et cela veut dire quoi?
[^] # Re: ## GCC 2.96 N'existe PAS ! ##
Posté par Gwenole Beauchesne . En réponse à la dépêche La Mandrake 8.2 est sortie. Évalué à 1.
Oui, corriger les erreurs dans le code des développeurs desdits softs.
Cependant je pense qu'on devrait le voir disparaitre dans la future release majeure de MDK (la 9.0?), car changer de gcc, c'est riquer de perdre la compatibilite binaire.
Exactement. gcc-3.1.X est un choix intéressant pour la 9.0/ix86.
[^] # Re: KDE 3 et gcc 2.95 de chez debian
Posté par Gwenole Beauchesne . En réponse à la dépêche La Mandrake 8.2 est sortie. Évalué à 9.
gcc 2.95 pas totalement ISO/C++ compliant si tu me le demandes... "2.96" était déjà une évolution à l'époque, le 3.0.4 l'est encore plus et le 3.1 est bigrement intéressant.
[^] # Re: ## GCC 2.96 N'existe PAS ! ##
Posté par Gwenole Beauchesne . En réponse à la dépêche La Mandrake 8.2 est sortie. Évalué à 1.
Ah. Où donc cela?
[^] # Re: prix ? ? ?
Posté par Gwenole Beauchesne . En réponse à la dépêche Mandrake 8.1 sur IA64. Évalué à 1.
L'architecture Itanium a, à mon avis, un fort potentiel. Le problème est que les compilateurs EPIC réllement optimisants ne courent pas les rues. D'ailleurs Intel va lancer dans pas longtemps le projet ORC (Open Research Compiler) basé sur feu Pro64 (mais ressuscité en Open64), lui même basé sur gcc.
[^] # Re: a propos de 64 bits
Posté par Gwenole Beauchesne . En réponse à la dépêche Mandrake 8.1 sur IA64. Évalué à 1.
Une citation a certainement une source, je ne la vois pas dans ton message. La norme dit en fait en 6.2.5 [#5]:
"A ``plain'' int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>)."
La norme parle de l'architecture du runtime, pas de l'architecture matérielle du processeur. Plus précisément, elle ne parle pas de registre du processeur. Mon interprétation est que l'implémenteur de compilateur se réfère aux conventions logicielles idoines de l'architecture cible (dépendante de l'OS et du processeur, évidemment).
Et, ô miracle, vois-je dans "IA-64 Software Conventions and Runtime Architecture Guide" en 4.1 (Data Representation, Fundamental types) que sizeof(int) vaut bien 4.
Concernant le "long", il est effectivement au moins aussi grand qu'un "int". Par contre, cela ne veut pas dire que ça fasse forcément 64 bits sur une archi 64 bits. En effet, mais là c'est le cas extrême des bizarreries, Microsoft a établi que le "long" resterait en fait à 32 bits sur ia64 (Windows XP 64 & co). Voir par exemple le "Quick Start Guide for Porting Applications for Win64" d'Intel...
Enfin, pour revenir au trucs rapidement manipulés par la machine. La norme définit en effet en 7.18.1.3, des entiers d'une certaine taille minimale qui peuvent généralement être manipulés rapidement. (cf. uint_fast32_t par exemple). Il ne s'agit pas de "int".
[^] # Re: Gcc 3.0 ? JVM 64 bits ?
Posté par Gwenole Beauchesne . En réponse à la dépêche Mandrake 8.1 sur IA64. Évalué à 1.
Pour la JVM, il s'agit de Kaffe (GPL) qui tourne en natif ia64 mais en mode interpréteur uniquement. i.e. pas de JIT. IBM propose la Beta 2 de son JDK pour Linux/ia64 mais également sans JIT. (http://www.alphaworks.ibm.com/tech/linuxsdk(...)). Quant à l'ORP d'Intel, ils annoncent toujours le port ia64 dans une prochaine version.