mercredi 27 août

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Développeur

Liens connexes

La liste des nouveautés de GCC 4.1 : (1658 hits)
SSA sur Wikipedia : (842 hits)
Protection contre les écrasements de la pile : (516 hits)
Le sommet GCC de 2005 : (307 hits)
GCC sur Wikipédia (1448 hits)

Dépêche modérée par

rootix

Dépêche éditée par

Développeur : Sortie de la version 4.1 du compilateur GCC

Posté par patrick_g (page perso, ). Modéré le 01 mars 2006.

Écrit à l'origine par Richard Stallman le logiciel GCC (GNU Compiler Collection) est devenu le compilateur de référence du monde du logiciel libre.

Après le tant attendu GCC 4.0 qui a vu la refonte complète son architecture interne voici maintenant la version 4.1 qui arrive.
Comme prévu la technologie SSA (Static Single Assignement) qui est au c½ur du nouveau GCC permet maintenant d'optimiser plus facilement le code source afin d'obtenir des améliorations générales. Le SSA est (en très gros) une forme intermédiaire entre le code source et le binaire dans laquelle chacune des variables du code source n'est assignée qu'une seule fois. Cette assignation unique a de nombreux avantages :

Les définitions et les utilisations de chacune des variables deviennent claires et explicites.
La majorité des analyses statiques du code source ne propagent les informations qu'à l'endroit strictement nécessaire.
Un grand nombre d'optimisations sur la forme intermédiaire SSA deviennent linéaire en temps.
De nombreux algorithmes deviennent plus concis et plus simples dans le cadre du SSA.

Après la grande bascule vers cette toute nouvelle technologie lors de la version précédente, l'équipe de développement de GCC s'est maintenant consacrée à l'amélioration poussée du code binaire produit par le compilateur. C'est donc le début des vrais bénéfices pour les utilisateurs !

La liste des nouveautés de GCC 4.1 : (1658 hits)
SSA sur Wikipedia : (842 hits)
Protection contre les écrasements de la pile : (516 hits)
Le sommet GCC de 2005 : (307 hits)
GCC sur Wikipédia (1448 hits)

> Lire la dépêche (75 commentaires, moyenne: 4,5).

On trouve ainsi dans cette nouvelle version 4.1 toute une série d'améliorations portant sur l'auto-vectorisation du code, notamment pour mieux profiter des unités multimédias des processeurs modernes (SSE ou Altivec). Cela ne remplacera pas des routines vectorisées "à la main" mais dans bien des cas c'est suffisant pour constater une amélioration significative de la vitesse d'exécution de certaines portions du code.
L'infrastructure pour faire des optimisations inter-procédures est maintenant en place. Il s'agit en fait de propager l'information d'analyse du source tout au long du graphe représentant le programme afin d'en tirer le meilleur parti possible et de générer une vue plus globale. Le profilage du source est ainsi rendu plus "intelligent" et il va plus en profondeur afin d'améliorer l'efficacité du binaire en sortie des différentes passes d'optimisation.
On trouve également une fonction pour marquer des portions de code en hot ou cold ce qui permet d'utiliser la mémoire cache des processeurs de façon plus rationnelle en ne chargeant que les instructions immédiatement utiles au programme en train de fonctionner (better instruction cache locality).
Du coté sécurité GCC est maintenant capable de générer automatiquement du code rendant plus difficile les attaques de type écrasement de pile (stack-smashing attacks). A noter qu'il s'agit d'une réimplémentation plus propre et moins intrusive du patch ProPolice d'IBM. Celui-ci était disponible en tant que patch externe pour les versions 3.x de GCC et il était activé notamment sous OpenBSD, DragonFlyBSD et dans la distribution IPCop. On trouvait également ce patch sous Gentoo mais il n'était pas activé par défaut.
Maintenant que cette fonctionnalité de protection de la pile fait partie intégrante de GCC (ce qui était réclamée à corps et à cris depuis des années ) on peut penser que toutes les distributions vont faire profiter leurs utilisateurs de ce surcroît appréciable de sécurité.
Dans le domaine Java le compilateur spécialisé GCJ (qui peut générer du code natif ou du bytecode) a été grandement amélioré sur le plan de la stabilité et de la couverture des spécifications Java 1.4 (il se base maintenant sur GNU Classpath 0.19 avec un backport des corrections de bugs de Classpath 0.20). GCJ peut maintenant supporter beaucoup plus d'applications que précédemment : Le client bitorrent Azureus, le lecteur de fil RSSOwl ou le serveur applicatif JonAS en sont des exemples.
Un article détaillé sur les nouveautés spécifiques du compilateur Java GCJ 4.1 et sur la future version 4.2 est disponible sur l'excellent site Linux Weekly News. On apprend ainsi que le support de Java 1.5 pourrait utiliser le compilateur ECJ du projet Eclipse au lieu de GCJX (et ceci une fois que la GPL v3 sera adopté car c'est cette dernière qui permet de renforcer la compatibilité entre les licences libres et de reprendre le code Eclipse dans le projet GCC).
Enfin coté support matériel on remarque l'intégration d'une nouvelle architecture. Il s'agit de MorphoSys qui est une architecture hybride composée d'un module programmable (TinyRISC) et d'un module hardware reconfigurable (RC Array).

Pour ce qui est des évolutions futures du compilateur on peut se pencher sur les articles (très) techniques issus de la publication du sommet GCC de 2005 à Ottawa.
On découvre que, expansion rapide de GNU/Linux aidant, beaucoup de grandes entreprises de logiciel et de hardware soutiennent le développement de GCC en payant des développeurs à plein temps : Intel consacre beaucoup d'effort au support de l'Itanium avec le projet Gelato et IBM fait de même avec le support de sa nouvelle architecture Cell. Ces deux types de processeurs étant très particuliers, ils nécessitent un compilateur extrêmement performant et moderne pour optimiser correctement le code généré.
Apple pour sa part finance l'amélioration du support du langage Objective-C alors que les deux poids lourd du monde Linux commercial, Novell/Suse et Red Hat, participent également activement aux améliorations du compilateur libre.
Bien entendu tout cela ne peut que renforcer le caractère incontournable de GCC dans le monde du logiciel libre et même au-delà.

PS1 : Pour faciliter son travail de développement l'équipe GCC a abandonné en fin d'année le logiciel de gestion des versions CVS et a migré vers Subversion (dont la version 1.3 est disponible). Après KDE c'est encore un poids lourd du monde du libre qui a basculé vers Subversion.
PS2 : Merci à alenvers pour ce post explicatif que j'ai repris sans aucune vergogne.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Ca c'est de la bonne dépêche !

Posté par Cali_Mero () le 01/03/2006 à 10:55. (lien). Évalué à 10.

Merci à l'auteur et tous ceux qui ont contribué à nous apporter une information si claire et détaillée !

Une petite question tout de même : les améliorations apportées dans cette nouvelle mouture produisent donc des binaires plus performants au final pour le même code source, si j'ai bien compris. Mais qu'en est il du temps de compilation lui-même ? Y-a t'il un surcout à ce niveau ?

Sinon, pour quel type de code/projets bénéficiera t-on le plus des améliorations de gcc 4.1 ? Et peut-on redouter des incompatibilités de certains codes sources comme ce fut le cas lors du passage à gcc 4.0 ?

--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */

Esperons que la qualité suivra

Posté par Ontologia (page perso, ) le 01/03/2006 à 11:07. (lien). Évalué à 10.

J'ai eu quelques problèmes avec GCC 4.1 qui est plus restrictif au niveau du code.

MPlayer ne veux pas compiler avec, il impose gcc-3. Je me suis amusé à le forcer à utiliser gcc 4, ça ne compile effectivement, et il génère une erreur interne.

De même, le code généré par le compilateur Lisaac, qui a la particularité de gérer lui-même sa mémoire (ie. un gros malloc au début, et une gestion "à la main" des zones mémoires dans le code), ne compile généralement pas le code généré par le compilateur. Ce code est pourtant conforme à C99 (au minimum tout le corps du code).
Remarque GCC 3 déconne aussi parfois. Avec le même code craché par le compilateur, on remarque, si l'on compile en -O {2,3,s}, que le compilateur invente des registres (!!!). C'est vraiment assez marrant à regarder.

Il serait donc peut être intéressant qu'un jour, une équipe, comme celle de Xavier Leroy à l'INRIA s'amuse à prouver quelques morceaux du compilateur.
Ce qui a été fait pour un compîlateur mini C.

http://pauillac.inria.fr/~xleroy/compcert-backend/

GCC reste néanmoins un excellent logiciel, sans lequel le libre ne serait à mon avis pas ce qu'il est.

Félicitation à l'équipe.

[^]Re: Esperons que la qualité suivra

Posté par Jacquot Raphael () le 01/03/2006 à 11:40. (lien). Évalué à 1.
pour mplayer, c'est de la faute des developpeurs qui travaillent comme des cochons.
- [^]Re: Esperons que la qualité suivra
  
  Posté par Guillaume POIRIER (page perso, ) le 01/03/2006 à 18:22. (lien). Évalué à 10.
  J'arrive pas à croire que ce genre de réflexion ait été marqué comme pertinente par les lecteurs de linuxfr.
  
  Autant tu as raison qu'une partie du code C qui ne compilait pas avec GCC-4.x était moche, et le fait de l'adapter pour qu'il soit compatible avec GCC4 a été une bonne chose, autant les modifications qu'il y a eu à faire pour adapter l'assembleur inline a été un vrai cauchemar. La faute à certaines version de GCC qui ne respectent même pas les spécifs de leur propre docs. La faute aussi à l'équipe de GCC qui considère que c'est normal qu'un code ne puisse compiler que quand on active les optimisations: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203#c14 , la faute à l'équipe de GCC de considérer que c'est une situation normale que GCC ne puise pas réaliser son allocation de registre avec certains codes asm inline valides.
  Oui, le code de MPlayer n'est pas ce qu'on puisse rêver de mieux en matière de qualité de code, mais ton aide est la bienvenue si tu veux remédier à ce problème.
  - [^]Re: Esperons que la qualité suivra
    
    Posté par Xavier Bestel (Jabber id, page perso, ) le 01/03/2006 à 19:22. (lien). Évalué à 10.
    C'etait pertinent. Dans le bug que tu cites, justement, il y a de l'assembleur inline a la tonne qui devrait compiler sur une architecture notoirement pauvre en registres (i386). Le compilateur ne peut pas trouver de registres libres pour toutes les instructions sans passes d'optimisation. Ce n'est pas comme si GCC n'arrivait pas a compiler du C sans optimisation.
    - [^]Re: Esperons que la qualité suivra
      
      Posté par Chaddaï Fouché () le 01/03/2006 à 19:42. (lien). Évalué à 5.
      Il devrait tout de même réussir à le compiler (tant que ce n'est pas impossible)... Même si on ne lui demande pas d'optimiser il devrait essayer de compiler parce que c'est le but, qu'on lui ait demandé d'optimiser est juste une indication sur la façon d'aboutir au résultat final.
      Par ailleurs la suite de la discussion est assez surréaliste avec un gros mensonge où quelqu'un confond NP-complet et "impossible", ce qui, même pour un étudiant en informatique comme moi est vraiment gros...
      
      Il faut aussi tenir compte du fait que mplayer a une très grosse base de code assez ancien, ce qui ne peut pas aider, et que mplayer a également "besoin" d'utiliser du asm inline s'il veut garder la légèreté qui fait sa qualité en tant que lecteur vidéo. Franchement mplayer est l'aïeul du multimédia (vidéo) Linux et avec ffmpeg continue à être l'un des acteurs les plus important du multimédia libre. Alors insulter mplayer pour la qualité de son code c'est vraiment une réaction détestable ! Rien ne t'empêche d'aider au développement.
      
      --
      Jedaï
      - [^]Re: Esperons que la qualité suivra
        
        Posté par Ontologia (page perso, ) le 02/03/2006 à 01:22. (lien). Évalué à 4.
        Par ailleurs la suite de la discussion est assez surréaliste avec un gros mensonge où quelqu'un confond NP-complet et "impossible", ce qui, même pour un étudiant en informatique comme moi est vraiment gros...
        
        Oulala, je me sens visé...
        
        Je n'ai pas dit que NP impliquait impossible. J'ai laissé entendre qu'on ne sait pas (et son auteur ne le sait pas non plus, je suis bien placé pour le savoir) comment le compilateur Lisaac réagira si on lui demande de compiler 1 000 000 de lignes.
        Il consomme 512 Mo pour compiler 50 000 lignes (lib incluse) en 15 secondes (sur un athlon 2Ghz). Combien lui faudra t-il de mémoire et de temps pour compiler 1 000 000 de lignes ? On ne sait pas, on a jamais essayé.
        
        L'analyse de flot (ie. l'algorithme testant toutes les branches de programme pour par exemple détecté qu'une variable est défini par n:=2*n+1 et 10 km virer un test de parité car il ne sert à rien) est un algorithme extrêmement consommateur de ressources, car exponentiel.
        
        Pas impossible en théorie, mais potentiellement impossible sur le PC que j'achète chez l'assembleur du coin.
        
        [^]Re: Esperons que la qualité suivra
        
        Posté par Matthieu C () le 02/03/2006 à 18:11. (lien). Évalué à 1.
        Je n'ai pas dit que NP impliquait impossible. J'ai laissé entendre qu'on ne sait pas
        
        C'est pas la question.
        Au pire tu peux utiliser la pile pour avoir tous les registres dispo (minus ceux en parametre) quand tu rentre dans un bloc asm inline.
      - [^]Re: Esperons que la qualité suivra
        
        Posté par Guillaume Knispel () le 02/03/2006 à 20:35. (lien). Évalué à 6.
        Ben ouai mais en même temps c'est dur d'intervenir sur un projet ou la fonction main fait 4000 lignes ;) (enfin elle faisait environ ça la dernière fois que j'ai regardé :p)
        
        [^]Re: Esperons que la qualité suivra
        
        Posté par Étienne Bersac (Jabber id, page perso, ) le 02/03/2006 à 21:01. (lien). Évalué à 5.
        Salut,
        
        wc a compté 3225 ligne pour le main, faut exgérer non plus :P
        
        Espérons que c'est le resultat d'un ménage progressif :)
        
        --
        E Ultreïa !
      - [^]Re: Esperons que la qualité suivra
        
        Posté par lasher () le 03/03/2006 à 01:48. (lien). Évalué à 10.
        « Alors insulter mplayer pour la qualité de son code c'est vraiment une réaction détestable ! Rien ne t'empêche d'aider au développement. »
        
        Tu veux dire, mis à part les fonctions de 4000 lignes et les hacks qu'on retrouve dans tous les sens ?
  - [^]Re: Esperons que la qualité suivra
    
    Posté par Corsaire () le 01/03/2006 à 22:25. (lien). Évalué à 6.
    A ce propos, j'ai proposé aux dev de MPlayer de quoi corriger la tonne de warning portant sur les "differ in signedness" afin déjà de corriger les plus simples qui sont dans les arguments de fonctions...
    
    Il semble cependant en effet que ce ne soit pas leur priorité et même trouvent les changement alourdissant le code.
    
    Maintenant la question est vaut il mieux un code peut-etre un peu lourd mais qui compile sans erreurs, ou garder le code "leger" mais vomissant des pages d'injures à la compile ?
    - [^]Re: Esperons que la qualité suivra
      
      Posté par Colin Leroy (page perso, ) le 02/03/2006 à 07:45. (lien). Évalué à 4.
      Ben c'est vrai que differ in signedness c'est un warning chiant. Si tu veux les enlever il faut spécifier le signe sur chaque char *: unsigned char * ou signed char *. Sinon tu vas corriger les warnings sur x86 et en ajouter sur ppc, ou vice-versa. C'est débile d'avoir ajouté ce warning dans -Wall. -- A mon humble avis.
      
      --
      Claws Mail - it bites!
      - [^]Re: Esperons que la qualité suivra
        
        Posté par Krunch (Jabber id, page perso, ) le 02/03/2006 à 12:07. (lien). Évalué à 9.
        Personnellement ça m'a déjà sauvé la vie (une sombre histoire de "c == EOF" qui n'était jamais vrai sur PPC). Mais si t'aimes pas t'es toujours libre de rajouter -Wno-sign-compare.
        
        Par ailleurs -Wsign-compare n'est pas activé par -Wall mais par -Wextra (anciennement -W).
        
        --
        Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
        pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
- [+] [^]Re: Esperons que la qualité suivra
  
  Posté par tuks () le 01/03/2006 à 19:15. (lien). Évalué à -9.
  lol effectivement...
  par contre xine a l'air bien ecris

[^]Re: Esperons que la qualité suivra

Posté par Ph Husson (page perso, ) le 01/03/2006 à 12:29. (lien). Évalué à 7.
C'est corrigé depuis longtemps...
Prend le CVS ca marche sans probleme
(Pas testé avec le 4.1 pour le moment mais nickel pour le 4.0 je l'utilise plusieurs heures par jour sans probleme (vive le multiposte free))
- [^]Re: Esperons que la qualité suivra
  
  Posté par Ontologia (page perso, ) le 01/03/2006 à 13:03. (lien). Évalué à 3.
  Bah pas chez moi :(
  
  [...]
  tvi_v4l2.c:1519: error: array type has incomplete element type
  tvi_v4l2.c:1519: error: invalid application of 'sizeof' to incomplete type 'struct v4l2_buffer'
  tvi_v4l2.c:1519: error: invalid application of 'sizeof' to incomplete type 'struct v4l2_buffer'
  make[1]: *** [tvi_v4l2.o] Erreur 1
  make[1]: Leaving directory `/home/montaigne/Logiciels-packagés/MPlayer/libmpdemux'
  make: *** [libmpdemux/libmpdemux.a] Erreur 2
  - [^]Re: Esperons que la qualité suivra
    
    Posté par Ph Husson (page perso, ) le 01/03/2006 à 15:31. (lien). Évalué à 4.
    Moi ca marche nickel....
    Avec gcc 4.1, testé avec 1h de multiposte free

[^]Re: Esperons que la qualité suivra

Posté par Victor STINNER (page perso, ) le 01/03/2006 à 12:41. (lien). Évalué à 10.
J'ai eu quelques problèmes avec GCC 4.1 qui est plus restrictif au niveau du code.

On dit pas "plus restrictif", mais "plus respectueux des standards" :-) Avec l'option -Wall, gcc sort des avertissements souvent pertinant ou pouvant détecter des bugs. Les corriger prend du temps (si on n'avait jamais utilisé -Wall), mais ça ne peut qu'être bénéfique !

Bon, après il existe peut-être des faux-positifs ... mais j'en ai jamais rencontré.

Pour les extrémistes : options -ansi voir ... (aïe) -pedantic :-P

Haypo
- [^]Re: Esperons que la qualité suivra
  
  Posté par lasher () le 01/03/2006 à 17:45. (lien). Évalué à 7.
  « Pour les extrémistes : options -ansi voir ... (aïe) -pedantic :-P »
  
  Euh, je n'utilise jamais -ansi, parce que de toute manière je serais obligé de définir certaines macros spécifiques à GCC, alors autant garder l'environnement de base. Mais je ne vois pas en quoi --pedantic est une option d'extrêmiste.
  
  -Wall -W -pedantic
  
  me semblent les options minimales pour qui veut faire un code un minimum correct (éventuellement avec l'option -std=c99 histoire de se mettre au goût du jour - mais bon, comme GCC n'implémente pas toutes les options de C99, ce sera du C99--).
- [^]C'est très bien -pedantic mais avec -std=c99 quand même
  
  Posté par Krunch (Jabber id, page perso, ) le 01/03/2006 à 17:53. (lien). Évalué à 3.
  Et pour les masochistes, il y a splint(1).
  
  --
  Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
  pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
  - [^]D'autres outils
    
    Posté par Victor STINNER (page perso, ) le 02/03/2006 à 09:21. (lien). Évalué à 3.
    Et flawfinder (écrit en Python :o)) et rats pour la sécurité.
    http://www.dwheeler.com/flawfinder/
    https://securesoftware.custhelp.com/cgi-bin/securesoftware.c(...)
    
    J'ai jamais compris si rats était libre ou nan !? Attendez je lis la licence ... GNU GPL2, ah nan c'est bon :-) C'est le formulaire qui me trouble.
    
    J'ai l'impression que Flawfinder trouve plein de trucs, mais les rapports générés sont bordeliques. rats fait de jolis rapport en regroupant les fichiers (avec numéro de ligne) par erreur.
    
    Puis y'a Valgrind pour traquer les erreurs d'accès mémoire et fuite de mémoire. La conférence à FOSDEM m'a vraiment convaincu que c'est un outil génial :
    http://valgrind.org/
    
    Pour un atelier sur la sensibilisation à la sécurité, j'avais entamé un article où vous y trouverez plein de liens :
    http://www.haypocalc.com/wiki/Analyse_statique_de_code
    
    Haypo
    - [^]Re: D'autres outils
      
      Posté par Krunch (Jabber id, page perso, ) le 02/03/2006 à 12:29. (lien). Évalué à 6.
      Si on sort de l'analyse statique, il y a Electric Fence qui est bien plus limité que Valgrind mais très pratique et facile à utiliser. Sinon on m'a fait découvrir les "Google Performance Tools" sur IRC hier.
      
      http://goog-perftools.sf.net/
      
      --
      Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
      pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

[^]Re: Esperons que la qualité suivra

Posté par agmk () le 01/03/2006 à 14:45. (lien). Évalué à 2.
De même, le code généré par le compilateur Lisaac [...] ne compile généralement pas le code généré par le compilateur.

Pourrais-tu expliquer/expliciter à un béotien ? J'avoue que j'ai rien compris du tout...

[...] qui a la particularité de gérer lui-même sa mémoire (ie. un gros malloc au début, et une gestion "à la main" des zones mémoires dans le code)

"Le code", celui de l'appli ? ou celui du compilo ? Tu parles d'une forme de GC ?

Le fonctionnement de Lisaac a l'air assez intéressant, mais relativement obscur. Merci d'avance.

--
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
- [^]Re: Esperons que la qualité suivra
  
  Posté par Thomas Douillard () le 01/03/2006 à 15:22. (lien). Évalué à 5.
  sur le 1 :
  AMHA (Ontologia pourra me contredire) on a
  
  code Lisaac --(compilo Lisaac)--> code C --( gcc )--> executable
  
  Et ça coince à l'étape gcc, alors que normalement le code C généré est complètement correct.
  
  Sinon, pour le 2, toujours AMHA, ca doit être le code C généré qui a des fonctions de gestions de mémoire maison, et qui gère l'allocation à l'intérieur du gros "malloc", sans doute une forme de gc, oui, mais là, je suis moins sûr ;)
  - [^]Re: Esperons que la qualité suivra
    
    Posté par Ontologia (page perso, ) le 01/03/2006 à 22:15. (lien). Évalué à 3.
    Je répond au post grand-père en ajoutant quelques commentaires à ta réponse utile.
    
    Effectivement, Thomas a bien décrit le fonctionnement du compilateur.
    
    La gestionnaire mémoire est tout simplement défini dans le fichier memory.li qui se trouve dans la lib du compilateur.
    Rappelons que Lisaac est un compilateur ultra minimaliste : il ne connait même pas la conditionnelle, elle est défini dans la lib.
    
    Un gros malloc est effectivement effectué au début, et un GC gère toute la mémoire.
    Comme tout est intégralement compilé, le GC est défini dans la libairie en fait (le fameu memory.li)
    
    Ça coince effectivement au niveau de la compilation avec gcc.
    
    Je compare ce qui n'est pas comparable, mais comparer du C est beaucoup plus difficile que compiler du Lisaac (quoique, compiler l'héritage dynamique est extrêmement difficile, nécessite une analyse de flot sur touts le code et constitue de toutes façon un algo de complexité exponentielle), du moins compiler proprement : la grammaire de Lisaac tiens en 20 lignes, celle du C en 4 pages...

[+] [^]Re: Esperons que la qualité suivra

Posté par Zakath (page perso, ) le 02/03/2006 à 14:03. (lien). Évalué à -1.

Il serait donc peut être intéressant qu'un jour, une équipe, comme celle de Xavier Leroy à l'INRIA s'amuse à prouver quelques morceaux du compilateur.
Ce qui a été fait pour un compîlateur mini C.

Et la marmotte qui met le chocolat dans le papier d'alu, tu la prouves aussi en Coq ?
Sérieusement, on est très très très très loin de pouvoir prouver du code C un tant soit peu non trivial, alors des bouts de gcc...

--
Vous devriez vraiment visiter Aperture First !
- [^]Re: Esperons que la qualité suivra
  
  Posté par Ontologia (page perso, ) le 02/03/2006 à 14:55. (lien). Évalué à 3.
  C'est pas une question de trivialité, c'est une question de grammaire.
  
  Ce qu'à fait X. Leroy, c'est de prouver le parser, la transformation du code source en code intermédiaire , l'allocation de registres et la traduction du code intermédiaire en code objet.
  
  Prouver du code C, c'est plutôt l'oeuvre de Jean-Christophe Filliatre http://why.lri.fr
  
  C'est vrai, que vu la taille de la grammaire, prouver du C non trivial est pas chose facile.
- [^]Re: Esperons que la qualité suivra
  
  Posté par Thomas Douillard () le 02/03/2006 à 18:04. (lien). Évalué à 5.
  Il me semble qu'il existe ce genre de compilos partiellement prouvés dans le domaine de de l'embarqué, peut être pas avec le C en entier, mais au moins avec des sous ensembles, ultras-chers par ailleurs.
  
  (La flemme de fouiller dans mes notes pour voir si j'ai noté des trucs là dessus)
  - [^]Re: Esperons que la qualité suivra
    
    Posté par Krunch (Jabber id, page perso, ) le 03/03/2006 à 09:34. (lien). Évalué à 1.
    T'es sûr que tu confonds pas avec un compilateur Ada ?
    http://www.cs.ucla.edu/~palsberg/paper/iccl92.pdf
    
    --
    Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
    pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
    - [^]Re: Esperons que la qualité suivra
      
      Posté par Thomas Douillard () le 04/03/2006 à 12:32. (lien). Évalué à 2.
      Effectivement, le premier compilo prouvé, et longtemps le seul, ça a été un compilo ADA (c'est plus simple, le langage est concu pour être plus robuste, et ADA était un langage poussé entre autre par les armées).
      
      Mais là, peut être que je me plante, mais il me semble qu'il y a des compilos C prouvés maintenant (Le papier date d'il y a 14 ans, ça me semble pas impossible ;) )
      - [^]Re: Esperons que la qualité suivra
        
        Posté par Gmooron (page perso, ) le 04/03/2006 à 14:33. (lien). Évalué à 0.
        [Mode chiant ON]
        Ada :p
        [Mode chiant OFF]

Gentoo

Posté par LastMan / Lastrainson (page perso, ) le 01/03/2006 à 11:28. (lien). Évalué à 2.

Vivement que Gentoo supporte officiellement la série 4 de GCC... Y'a pas à dire, elle commence à se faire attendre ;-)

Pour le moment on peut quand même l'utiliser à coup d'entrées dans les fichiers de configuration de portage (le système de gestion de paquets de Gentoo) mais ça reste officiellement non supporté, même en ~arch qui est l'équivalent d'un "unstable" debian (obligation de rajout d'une variable d'environnement / de configuration I_PROMISE_TO_SEND_PATCHES_WITH_BUGS par exemple, en stipulant bien que si ton système casse avec GCC 4.x, pour le moment c'est ton problème.)

M'enfin... Je garde espoir, sachant que c'est surtout le code de certaines appllis qui ne compilent pas avec GCC 4 qui fait que le support officiel tarde.

[^]Re: Gentoo

Posté par matt () le 01/03/2006 à 11:35. (lien). Évalué à 3.
En plus gcc 4.1 sous gentoo compile quasiment tout, j'ai juste des problemes avec vlc, sinon tout le reste de mes package marche nickel !
- [^]Re: Gentoo
  
  Posté par klessou (Jabber id, ) le 01/03/2006 à 15:15. (lien). Évalué à 1.
  Ouaww', je trouve ça plutôt impressionnant que GCC 4.1 fonctionne déjà si bien sous Gentoo.
  Enfin je suis peut être impressionné pour rien, mais c'est une application très "critique" en production dans une distribution comme Gentoo.
  C'est un réel progret pour les distribution dite "source", mais je pense tout de même que GCC 4, va mêtre encore beaucoup de temps pour arriver en production dans la branche stable. Mais tout est relatif.
  
  --
  Logiciel Libre à Telecom Lille 1

[^]Re: Gentoo

Posté par tgl () le 01/03/2006 à 20:32. (lien). Évalué à 7.
Pour suivre l'avancement de la chose, on peut se surveiller les dépendances de ce meta-bug :
http://bugs.gentoo.org/showdependencytree.cgi?id=117482
Ça fait finalement assez peu de problèmes pour les gcc-4.x je trouve (comparativement à tout ce qui marche déjà bien quoi).

M'enfin... Je garde espoir, sachant que c'est surtout le code de certaines appllis qui ne compilent pas avec GCC 4 qui fait que le support officiel tarde.

Tout à fait. Pour enfoncer encore un peu le clou, disons qu'il n'est pas vraiment question que gcc4 atteigne le ~arch tant qu'il restera des problèmes connus avec certains paquets qui sont fonctionnels par ailleurs. La branche ~arch n'est pas un terrain de jeu où l'on a le droit de sciemment provoquer des régressions, mais c'est une branche pour les paquets candidats à la stabilité. Aux imprévus près, elle est censée être complètement cohérente, enfin autant que possible.

Perso, je trouve ça plutôt rassurant que les devs Gentoo se tiennent à cette politique, y compris pour des paquets où la demande populaire peut devenir, comme ici, assez pressante. Et puis bon, c'est pas non plus comme si les ebuilds étaient absent de Portage et que ça prenait plus d'une dizaine de secondes pour y avoir accès...

ObjectiveC++

Posté par Larry Cow () le 01/03/2006 à 11:43. (lien). Évalué à 7.

Parmi les modifs attendues de cette nouvelle version, il y a si je ne m'abuse le support pour l'Objective-C++ (mélange d'Objective-C et de C++ dans un même code). Ceci devrait notamment permettre le portage d'un certain nombre d'applis libres du monde MacOS vers GNUstep.

[^]Re: ObjectiveC++

Posté par FReEDoM (page perso, ) le 02/03/2006 à 11:00. (lien). Évalué à 1.
Exactement !

Webcore par exemple devrait pouvoir être porté plus facilement.

apple et gcc

Posté par Troy McClure (page perso, ) le 01/03/2006 à 12:42. (lien). Évalué à 5.

Apple fait un peu plus que supporter l'obj-C, ça a été les premiers à adopter gcc 4.0 et maintenant ils envisagent des changements assez radicaux dans gcc:
http://www.kdedevelopers.org/node/1628
http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html
(le but étant de permettre des optimisations au moment du link)

Ubuntu Dapper

Posté par laurent carlier () le 01/03/2006 à 12:48. (lien). Évalué à 1.

Dispo sous Ubuntu Dapper :
https://lists.ubuntu.com/archives/dapper-changes/2006-March/(...)

A propos des optimisations de code

Posté par Fabrice Mousset (page perso, ) le 01/03/2006 à 14:29. (lien). Évalué à 10.

Je travail dans le domaine de l'électronique industrielle et de l'informatique embarquée. En gros ça veut dire que je joue avec des composants qui disposent d'un espace adressable relativement faible (de l'ordre de la centaine de ko).
Dans mon domaine on a l'habitude de travailler avec compilateurs relativement chers qui offrent des optimisations de codes très, très poussées (codewarrior, microtec, hi-tec, etc).

De puis quelques temps j'ai commencé à travailler avec le compilateur GCC et ses outils annexes, plus par curiosité et pour des développements personnels.
J'ai vu dans une doc de GCC version 3.xx, que celui-ci était incapable de faire une optimisation de code au niveau "module". En gros ça veut dire que si on utilise une fonction d'un module/fichier C d'une librairie, tout les fonctions du module sont importées dans le binaires.
Ce qui est relativement génant pour moi à moins de fractionner tous mes fichiers pour les exploser dans des fichiers séparés. Ce qui n'est pas forcément simple à faire ni agréable.

Je voulais simplement savoir si dans la version 4.0 ou 4.1 c'était encore le cas ? Quelqu'un sait où je pourrait trouver cette info ?

Et pour compléter encore un peu, est-ce qu'il y a quelque part des infos concernant la pertinance des optimisations et éventuellement un comparatif par rapport à d'autres compilateurs commerciaux ou libre ?

Sinon, super dépêche, très intéressante.

[^]Re: A propos des optimisations de code

Posté par tuan kuranes (page perso, ) le 01/03/2006 à 14:49. (lien). Évalué à 10.
Si c'etait une lib static c'etait déjà le cas.

Pour les lib dynamiques, depuis gcc4.0 en C++ au moins il y a -fvisibility qui révolutionne la vie des librairies dynamiques :
: http://gcc.gnu.org/wiki/Visibility

[^]Re: A propos des optimisations de code

Posté par gpe () le 01/03/2006 à 16:13. (lien). Évalué à 4.
Je n'ai plus vraiment les chiffres en tête mais au boulot on a fait des tests sur ARM7 entre gcc 3 et le compilo ARM ADS1.2 et il n'y a pas photo. ADS est plus performant en taille de code (20% je crois) et le code généré est plus rapide.
- [^]Re: A propos des optimisations de code
  
  Posté par Nicolas Boulay () le 01/03/2006 à 21:56. (lien). Évalué à 4.
  tu avais testé l'efficacité de l'option -Os ?
  - [^]Re: A propos des optimisations de code
    
    Posté par gpe () le 01/03/2006 à 22:38. (lien). Évalué à 3.
    Je ne me rappelle plus les conditions exactes du test (ce n'est pas moi qui les ait fait, le "on" désignait la boite où je bosse) mais il y a eu plusieurs configurations de testées et dans mon souvenir ADS était toujours meilleur sur les 2 domaines (taille code, vitesse d'exécution). Faudrait que je retrouve le rapport de test...
    - [^]Re: A propos des optimisations de code
      
      Posté par Philippe Fremy (page perso, ) le 03/03/2006 à 02:15. (lien). Évalué à 10.
      C'est un fait connu que gcc n'est pas un excellent compilateur dans tous les domaines. C'est pas facile de compiler tous les langages de la terre sur toutes les architectures de l'espace et d'etre meilleur que tout le monde. Ce qu'il faut juger, c'est la distance. 20%, ca me parait acceptable tout en restant a ameliorer. Au dela, c'est qu'il y un truc qui ne va pas.
      
      En general, gcc se fait battre par des compilos optimises pour des architectures specifiques, qui ont beaucoup moins de contraintes globales que gcc.
      
      En vitesse de compilation, il se fait battre a plat de couture par Visual C++ vieille version.
      
      Des projets comme KDE galerent parce que la gestion du code virtuel dans les classes n'est pas optimal. De ce que j'en comprends, le support C++ evolue tres lentement ce qui ralentit parfois de facon notable des gros projets C++. KDE etant probablement le plus gros projet Open Sourc en C++ qui utilise gcc.
      
      Sur des archis embarques petite, je doute que gcc soit vraiment super efficace. Pour ce type d'architecture, ecrire un compilateur qui ne fait que du C et tient compte de certains caracteristiques des petits micros permet de meilleurs resultats que l'artillerie gcc.
      
      Tu peux regarder sdcc (http://sdcc.sf.net) qui parait plus adapte. Sur certains projets, il arrivait au niveau de Keil.
      
      Sinon, je travaille aussi dans l'embarque sur des micro 8bits et la facon dont tu ecris ton code a une influence certaine sur la taille du code genere par certains compilateurs. Certains vont mieux optimiser les acces aux variables globales, d'autres les acces aux variables locales. Certains n'aiment pas du tout les pointeurs (genre Keil, il aime pas du tout du tout les pointeurs au dela de 64K sur une archi 8 bits), d'autres les digerent facilement. Et chacun ont leur bugs : Codewarrior qui addresse les membres d'une structure sur un registre == pas possible d'avoir une strucutre plus grosse que 255 octets.
      
      --
      phil.freehackers.org
      - [^]Re: A propos des optimisations de code
        
        Posté par Tennis Prono (page perso, ) le 03/03/2006 à 08:51. (lien). Évalué à 6.
        
        En vitesse de compilation, il se fait battre a plat de couture par Visual C++ vieille version
        
        D'un certain coté, écrire des programmes avec Visual C++ vieille version, ça me gave vu qu'il est limité point de vue support des templates (et c'est normal, il est vraiment vieux). La nouvelle version n'a rien à envier à gcc point de vue lenteur :-) (faudrait que je mesure la vitesse de compil sur gcc et vc7 sur notre gros projet).
        
        --
        Pas de bureau 3d libre sans drivers libres!
      - [^]Re: A propos des optimisations de code
        
        Posté par gpe () le 03/03/2006 à 10:03. (lien). Évalué à 6.
        
        C'est un fait connu que gcc n'est pas un excellent compilateur dans tous les domaines. C'est pas facile de compiler tous les langages de la terre sur toutes les architectures de l'espace et d'etre meilleur que tout le monde. Ce qu'il faut juger, c'est la distance. 20%, ca me parait acceptable tout en restant a ameliorer. Au dela, c'est qu'il y un truc qui ne va pas.
        
        Je n'ai pas critiqué gcc. La question était de savoir si des comparatifs existaient entre gcc et des compilos commerciaux. J'ai apporté ma très modeste pierre avec une réponse basée sur des souvenirs...
        
        Certe 20% ce n'est pas énorme et pas génant sur un PC mais dans l'embarqué c'est très pénalisant et pourtant je travaille sur une archi 32 bits (ARM7 et ARM9) avec des binaires de 2Mo. Mais 20% de plus c'est inacceptable chez nous... surtout si en plus le code est moins efficace. Mais il faudrait peut-être refaire le test avec cette version 4.1 de gcc pour voir l'évolution.
        
        Tu peux regarder sdcc (http://sdcc.sf.net) qui parait plus adapte. Sur certains projets, il arrivait au niveau de Keil.
        
        Je ne connaissais pas mais c'est inadapté à mon cas (32 bits, arm7 et arm9).

Toujours pas l'intégration de GOMP...

Posté par tuan kuranes (page perso, ) le 01/03/2006 à 15:11. (lien). Évalué à 10.

Le futur des PC c'est le multi-core, vu que la course au Ghz est enfin finie.

En gros, bientot le seul moyen d'augementer les perfs pour une appli, utiliser les threads....puisqu'on pourra bientot plus acheter de plus gros proc...

Quelques docs pour ceux qui n'ont pas suivi :
- The Free Lunch Is Over de Herb Sutter (comité de normalisation du c++ : http://www.gotw.ca/publications/concurrency-ddj.htm )
- Managing Concurrency: Latent Futures, Parallel Lives ( http://www.gamearchitect.net/Articles/ManagingConcurrency1.h(...) )

Les optimisations de gcc 4 ne peseront pas lourds, face à des compilateurs qui savent gérer les multi-core (vc8, ic9, etc...), notemment par le support d'OPENMP ( http://www.openmp.org/drupal/ )

Vivement l'intégration d'OPENMP dans GCC plutot que de laisser ca en dans une branche inconnue ( http://gcc.gnu.org/projects/gomp/ ).

En tout cas, j'espere que les cours d'algo pour étudiant en ce moment mette plus l'accent qu'avant sur ce problème épineux... sinon "ca va pas etre facile".

[^]Re: Toujours pas l'intégration de GOMP...

Posté par tuan kuranes (page perso, ) le 01/03/2006 à 15:35. (lien). Évalué à 10.
C'est prévu pour 4.2 et certaines distribs l'ont mis quand même dans leur paquet gcc 4.1 version x64.

[^]Re: Toujours pas l'intégration de GOMP...

Posté par Orphis () le 01/03/2006 à 17:53. (lien). Évalué à 2.
Je sors justement d'un cours de programmation concurentielle où on a abordé la difficulté de créer des programmes efficaces avec des processus se déroulant en parallèle. On a aussi un peu parlé d'optimisations faites à la compilation mais c'est vrai que ce n'était pas très approfondi pour l'instant.

Mais bon, en même temps, pour le premier cours sur le sujet du semestre, fallait pas en demander trop !
- [^]Re: Toujours pas l'intégration de GOMP...
  
  Posté par Philippe Fremy (page perso, ) le 03/03/2006 à 02:24. (lien). Évalué à 4.
  > la difficulté de créer des programmes efficaces avec des processus se déroulant en parallèle.
  
  Sans meme aller jusqu'a l'efficacite, concevoir et debugger un programme dont les morceaux s'executent en parallele est enormement plus complexe que de concevoir et debugger un programme normal.
  
  Perso, je pense que les threads ne doivent etre utilises qu'en cas d'extreme necessite couplee avec une necessite extreme. Genre calculs mathematiques, programmes gerant n connexions, etc.
  
  Pour parallelise un programme plutot monotache dans son fonctionnement, c'est tout de suite beaucoup plus complique. Il faut isoler des portions du programme qui n'ont pas besoin d'ecrire des donnes communes, il faut regarder l'ordonancement de chaque tache pour voir si on peut pas en lancer qqs'une avant les autres, etc.
  
  Je prefere plutot que mon noyau et son scheduler qui s'occupe de paralleliser l'utilisation des ressources de ma machine, que le compilateur qui essaye de paralleliser un programme.
  
  Pour en revenir aux programmes pseudo-monotaches, je me demande a quel point ce n'est pas plus simple de faire un scheduler interne (ce qu'a fait mplayer) que de faire de la programmation par thread a tout va. Au moins, avec ton scheduler, tu sais ou tu vas.
  
  --
  phil.freehackers.org
  - [^]Re: Toujours pas l'intégration de GOMP...
    
    Posté par lasher () le 03/03/2006 à 15:31. (lien). Évalué à 4.
    « Je prefere plutot que mon noyau et son scheduler qui s'occupe de paralleliser l'utilisation des ressources de ma machine, que le compilateur qui essaye de paralleliser un programme. »
    
    C'est dommage. Si un compilateur est capable, moyennant un léger surcoût à la compilation, d'extraire les instructions indépendantes, je ne vois pas pourquoi on ne pourrait pas en profiter pour paralléliser automatiquement le programme (création de pipelines logiciels, déroulage de boucles, déroulage/fusion, etc)
    - [^]Re: Toujours pas l'intégration de GOMP...
      
      Posté par Lionel Draghi (page perso, ) le 03/03/2006 à 18:55. (lien). Évalué à 5.
      Je crois que l'on parle de deux choses différentes : l'optimisation du code et la conception d'un logiciel.
      Au niveau optimisation, le processeur fait tout son possible pour explorer en avance de phase plusieurs chemins d'exécution, le compilateur va faire de son mieux pour détecter dans le code source des choses vectorisables, etc. etc.
      Mais le parallélisme de l'application, par exemple les politiques d'ordonnancement ou d'accès aux donées partagées, si ce n'est pas décrit dans le code source, le compilateur ne peut pas l'inventer.
      - [^]Re: Toujours pas l'intégration de GOMP...
        
        Posté par lasher () le 04/03/2006 à 08:18. (lien). Évalué à 2.
        « Mais le parallélisme de l'application, par exemple les politiques d'ordonnancement ou d'accès aux donées partagées, si ce n'est pas décrit dans le code source, le compilateur ne peut pas l'inventer. »
        
        Ben euh... Au moins la « threadification », le compilateur peut faire quelque chose...

[^]Re: Toujours pas l'intégration de GOMP...

Posté par forc3 (page perso, ) le 01/03/2006 à 17:54. (lien). Évalué à 2.
En parlant de OpenMP, ou puis-je tester ce truc ?
Impossible de trouver du code ou quoi que ce d'autre que leur spec et presentation...

C'est que je veux le voir tourner ce truc !
- [^]Re: Toujours pas l'intégration de GOMP...
  
  Posté par gvallee () le 01/03/2006 à 18:16. (lien). Évalué à 4.
  Il y a des exemples sur le site http://www.openmp,org/ (exemples en Fortran).
  Quelques autres liens qui pourraient egalement t'interesser, notamment le compilateur Omni (que j'ai utilise il y a quelque temps et qui fournit des exemples) :
  - le compilateur Omni (LGPL) : http://phase.hpcc.jp/Omni/home.html
  - un benchmark OpenMP (NAS Parallel Benchmarks in OpenMP) : http://phase.hpcc.jp/Omni/benchmarks/NPB/index.html
  
  Mes 2 cents... :-)
- [^]Re: Toujours pas l'intégration de GOMP...
  
  Posté par tuan kuranes (page perso, ) le 17/03/2006 à 11:58. (lien). Évalué à 1.
  GCC a une branche qui support openmp, qui s'appelle GOMP :
  
  http://gcc.gnu.org/projects/gomp/

[^]Re: Toujours pas l'intégration de GOMP...

Posté par Ontologia (page perso, ) le 02/03/2006 à 12:45. (lien). Évalué à 3.
Mon avis sur la question s'exprime en une ligne : L'idéal serait de cacher au maximum cette complexité au programmeur, bref faire en sorte que le compilateur gère lui-même.

Bertrand Meyer, le concepteur d'Eiffel à conçu pour cela le modèle SCOOP : http://se.inf.ethz.ch/teaching/ss2004/0268/lectures/251-0268(...) pour Simple Concurrent Object-Oriented Computation

C'est un modèle qui propose une syntaxe pour Eiffel permettant de définir quand est-ce qu'un appel de message est asynchrone ou non.
Eiffel Software l'a implémenté en 1995.

Puisque la nature revient au galop ;-) je précise que le brouillon de publication que j'ai présenté sur ce site, n'est autre que l'adaptation du modèle SCOOP à un langage objet à prototype compilé.

https://linuxfr.org/~Montaigne/20582.html

L'idée de ce modèle est de permettre de la programmation parallèle, en pensant son code en tant que système multi agent.
Les problèmes de multithread ne se posent pas trop car les zones mémoires entre thread sont, dans ce modèle, étanches. C'est un peu l'idée de SCOOP.
- [^]Re: Toujours pas l'intégration de GOMP...
  
  Posté par Philip Marlowe (Jabber id, ) le 02/03/2006 à 17:43. (lien). Évalué à 3.
  Eiffel Software l'a implémenté en 1995
  
  Je suis content de l'apprendre. En fait, à ma connaissance, SCOOP avec son mot-clé separate et un fichier de ressources un peu semblable aux fichiers d'assemblage de classes (permettant de savoir si le nouveau "processeur" est un thread, un autre processeur, ou une machine distante, ou autre chose), ça n'a jamais été implémenté en 2006. Que la spécification date de 1995, je veux bien le croire.

[^]Re: Toujours pas l'intégration de GOMP...

Posté par Lionel Draghi (page perso, ) le 03/03/2006 à 22:55. (lien). Évalué à 8.

- The Free Lunch Is Over de Herb Sutter (comité de normalisation du c++ : http://www.gotw.ca/publications/concurrency-ddj.htm )

J'en prends un extrait :
The mainstream state of the art revolves around lock-based programming, which is subtle and hazardous. We desperately need a higher-level programming model for concurrency than languages offer today; I'll have more to say about that soon.

<mode cynisme>
Encore un qui semble vachement au fait de l'état de l'art (son papier ne cite que Java). Je suis impatient de voir ce qu'il va nous pondre.
</fin du cynisme>

Ca me parait être l'occasion de rappeler que dans gcc, il y a un compilateur Ada, et que Ada propose un modèle de programmation parallèle d'une puissance inégalée.
Ces concepts sont intégrés depuis toujours dans le langage, ils ne s'agit pas d'une bibliothèque externe ou d'un concept minimaliste ajouté avec difficultés dans un langage pas du tout pensé pour ça.

En Ada, les taches ou les objets protégés sont des citoyens de première classe. Ils peuvent être manipulés comme beaucoup d'autres types. On peut par exemple déclarer un tableau de tache.

Si vous souhaitez faire un logiciel de calcul, de jeux, ou de traitement d'image, intégrant un tasking performant, basé sur un standard ISO, portable entre compilateur, portable entre OS, alors pas la peine d'attendre, c'est déjà dans gcc.

J'espère que la banalisation des dual-core augmentera l'intéret des développeurs pour Ada, qui permet d'écrire un code unique pour Linux/Solaris/Windows/etc., exploitant les ressources disponibles sur la machine, quel que soit le nombre de processeurs.
- [^]Re: Toujours pas l'intégration de GOMP...
  
  Posté par Sylvain Sauvage () le 04/03/2006 à 18:52. (lien). Évalué à 4.
  
  J'espère que la banalisation des dual-core augmentera l'intéret des développeurs pour Ada
  
  J'ai de forts doutes : la mode est plus aux langages de scripts où on ne déclare pas grand'chose avant de s'en servir...
- [^]Re: Toujours pas l'intégration de GOMP...
  
  Posté par tuan kuranes (page perso, ) le 17/03/2006 à 12:08. (lien). Évalué à 1.
  Il fait partie du comité de normalisation du C++.
  
  "mainstream" veut dire utilisé et accepté par tout le monde, industrie et academie.
  C++, Java, C#, ruby, python => mainstream
  ada, lisp, ocaml => peu utilisé, donc pas mainstream
  
  Ada ne fait malheureusement pas parti du "mainstream".
  
  Qui sait, les "task, "entry", "accept", "requeue", et autres "delay" feraont peut-etre leur coming-back.

Protection de la pile par défaut sur les prochaines releases des distros

Posté par herodiade () le 03/03/2006 à 17:30. (lien). Évalué à 10.

Maintenant que cette fonctionnalité de protection de la pile fait partie intégrante de GCC (ce qui était réclamée à corps et à cris depuis des années ) on peut penser que toutes les distributions vont faire profiter leurs utilisateurs de ce surcroît appréciable de sécurité.

Ça serait formidable !
À ce jour, je n'ai pas eu d'autres echos que de la position de Fedora Core, dont un développeur expliquait sur une mailing-list que les packages sont désormais compilés avec cette option activée (la FC 5 sera donc releasée avec cette protection). Et évidement DragonflyBSD et OpenBSD qui utilisent son équivalent pour gcc3 depuis une paye.

Qu'en est-il des autres distributions ? quelles sont celles qui ont annoncé leur position par rapport à cette option (qu'ils aient décidé de la supporter ou non) ?
Qu'en pensent Debian, Ubuntu, OpenSuse et Mandriva ?

Je suis particulièrement inquiet pour Debian, qui a longtemps tenu le haut du pavé en matière de sécurité, du fait de la très haute exigeance qualité de son équipe de developpeurs. Mais qui semble ne plus tenir le rythme, par exemple par rapport à Fedora (qui intègre maintenant par défaut SELinux , Exec-Shield, fstack-protector , FORTIFY_SOURCE...).
Un grand nombre de ces protections (option /Gs de vc++, ACL ntfs, ...) sont même désormais intégrées dans les dernières releases de windows, cependant que (selon un sondage mené par debian-administration.org) les developpeurs Debian considèrent la sécurisation comme relativement secondaire (et je ne parle pas des couacs comme l'absence de maj sécu de juillet dernier, le temps de réponse aux problèmes de firefox en aout etc. !).
Quel dommage s'il fallait se priver de la qualité et stabilité légendaires de Debian (sur ce plan, Debian ne fléchit pas !) pour avoir un environement sécurisé par défaut, lors de la prochaine release (et non, recompiler toute l'archive avec -fstack-protector, créer les polices SELinux pour les daemons courants et le système de base etc. n'est pas une solution triviale. Et oui, ces protections sont devenues nécéssaire, parceque les pirates ont, eux aussi, progréssé. D'où le besoin du secure "by default").

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

Posté par olivn () le 03/03/2006 à 22:21. (lien). Évalué à 3.
Depuis la version Suse 10.0, les applications sont compilées avec l'option -D_FORTIFY_SOURCE=2

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

Posté par salvaire () le 04/03/2006 à 15:18. (lien). Évalué à 2.

Je suis particulièrement inquiet pour Debian, qui a longtemps tenu le haut du pavé en matière de sécurité, du fait de la très haute exigence qualité de son équipe de développeurs. Mais qui semble ne plus tenir le rythme
Les boîtes comme RedHat ont acquis avec le temps de solide base pour développer leurs distributions. Debian est trop dépendant du dévouement, et de la bonne collaboration de ses développeurs. Un orchestre symphonique sans chef d'orchestre produit une cacophonie. Mais des monstres comme M$, IBM ont aussi leurs couacs. Il faudrait un juste milieux.
- [^]Re: Protection de la pile par défaut sur les prochaines releases des dis
  
  Posté par Frédéric Lopez () le 04/03/2006 à 17:03. (lien). Évalué à 7.
  
  Un orchestre symphonique sans chef d'orchestre produit une cacophonie.
  
  C'est justement la saison de l'élection du chef d'orchestre chez Debian :
  http://www.us.debian.org/vote/2006/vote_002
- [^]Re: Protection de la pile par défaut sur les prochaines releases des dis
  
  Posté par herodiade () le 07/03/2006 à 10:05. (lien). Évalué à 2.
  Oui, c'est assez juste.
  Peut-être pas pour le besoin de dévouement: certaines de ces technologies ne demandent pas beaucoup d'efforts particuliers, le terrain a déjà été déffriché par les autres distros, et il y a aussi du suport commercial derrière Debian (Xandros, Ubuntu, Progeny, DCC, ...), mais je crois que tu a raison en pointant le besoin de collaboration et la difficulté de prendre des décisions collectives comme les causes principales de ce problème.
  
  Car même lorsque la mise en oeuvre de certaines de ces protections est assez simple, elle doit souvent être appliquée à toute l'archive ou aux composants centraux. Elle demande donc une décision collective (pour les mainteneurs gcc/glibc/kernel de Debian, ça représente peut-être plus de travail que la mise en oeuvre technique).
  Dommage, j'aurai préféré que, même sur ces questions, le modèle de fonctionnement démocratique soit le plus efficace :(
  
  Pour les chantiers plus lourds (comme l'intégration de politiques RSBAC ou SELinux), il aurait été juste que ceux qui tirent un profit commercial de Debian mettent leur responsabilité en oeuvre. Par exemple que DCC se montre enfin utile, plutot que de faire mal aux mouches !

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

Posté par Sytoka Modon (page perso, ) le 05/03/2006 à 21:09. (lien). Évalué à 4.
Je ne suis pas sur qu'il faille toujours suivre RedHat ;-)

Par exemple, sur SELinux, je prefererais que debian choissise par défaut RSBAC.

http://www.rsbac.org/

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

Posté par Mickaël L () le 07/03/2006 à 00:09. (lien). Évalué à 2.
En fait, au niveau sécurité, je me demande si SElinux n'est pas plutôt un TROU potentiel de sécurité.
Après tout, ceux qui l'ont conçu sont les même qui aiment bien écouter les gens.
- [^]Re: Protection de la pile par défaut sur les prochaines releases des dis
  
  Posté par herodiade () le 07/03/2006 à 09:47. (lien). Évalué à 3.
  Si j'ai bien compris, ils l'ont conçu pour que Linux puisse répondre à leurs propres critères d'utilisation de logiciels pour des opérations sensibles, en fonction de contraintes légales qui leurs sont imposées.
  Bref, ils sont problablement les utilisateurs qui ont le plus besoin de cette technologie ; il est donc improbable qu'ils aient pris le risque de laisser des trous connus - même cachés. De même qu'ils n'ont surement pas choisi Rijndael pour devenir AES en fonction d'une quelquonque fragilité de l'algorithme, vu qu'ils seront contraints de l'utiliser quotidiennement.
  
  Celà étant dit il faut reconnaitre que les contraintes de la NSA sont assez tortueuse, et (en conséquence ?) SELinux un poil byzantin.
  Je suis d'accord avec Sytoka Modon (commentaire ci-dessus) pour privilégier RSBAC lorsque l'administration étasunienne n'est pas votre cible: le code est moins volumineux (potentiellement moins de bugs), le système est beaucoup plus facile à mettre en oeuvre (potentiellement moins d'erreurs d'admin) et surtout, certains composants de SELinux sont affectés par de sombres histoires de brevets logiciels qui font froid dans le dos.
  Mais de là à dire que SELinux est une régression en termes de sécurité ....
  
  Quoiqu'il en soit, ces systèmes sont peut-être contraignants et difficiles à mettre en oeuvre dans une distro (mais certaines l'ont fait ...) mais ça n'est pas le cas des options de renforcement à la compilation, comme fstack-protector et fortify ainsi que de certains patches du noyau ! C'est maintenant une responsabilité des mainteneurs de distribution, de contraindre un minimum de protections en les activants pour les binaires qu'ils produisent.
  
  Quand on apprend qu'une majorité (je n'ai plus les chiffres en têtes, peut-être 70%) des failles critiques indéxées par le CERT sont des buffers overflow, précisément, ce que protègent ces outils simples et non intrusifs (dont la mise en oeuvre n'est pas lourde mais doit être faite par ceux qui packagent), on peut trouver irresponsable, pour des mainteneurs de distribution, de les ignorer.

C++0x

Posté par Sebastien Binet () le 03/03/2006 à 23:50. (lien). Évalué à 4.

C'est un peu off-topic (enfin pas temps que ca puisque ca sera surement interessant pour les futures-futures-... versions de GCC), mais je suis tombe par hasard sur un enieme article[1,2] de BS expliquant les nouveautes de la prochaine norme pour le C++.

J'ai trouve que ce concept de "concept" etait vraiment tres interessant et devrait permettre de plus facilement resoudre certains problemes du C++ (notamment les collections d'objets polymorphiques qui devraient pouvoir etre vues comme des collections d'objets a n'importe quel endroit de l'arbre d'heritage)

Par contre je n'ai pas trouve de mention concernant XTI (eXtended Type Information) [3] qui aurait du/pu resoudre les problemes de persistence des donnees (entre autre!).

Quelqu'un a de plus amples informations concernant XTI ?

[1] la version light
http://www.artima.com/cppsource/cpp0x.html

[2] la version poussee
http://www.research.att.com/~bs/popl06.pdf

[3] http://lcgapp.cern.ch/project/architecture/XTI_accu.pdf

[^]Re: C++0x

Posté par salvaire () le 04/03/2006 à 15:07. (lien). Évalué à 2.

Par contre je n'ai pas trouve de mention concernant XTI (eXtended Type Information) [3] qui aurait du/pu resoudre les problemes de persistence des donnees (entre autre!).
Il manque donc l'essentiel ... Les gens qui font les normes ne doivent pas être confronté aux même problèmes pratiques ...
- [^]Re: C++0x
  
  Posté par Sebastien Binet () le 05/03/2006 à 22:00. (lien). Évalué à 4.
  Mouais...
  Faut pas voir le mal partout, hein...
  Je crois surtout que c'est une histoire de manpower.
  
  Apparemment, Stroustrup est tout seul a implementer/developper cette librairie...
  Donc normal que cela prenne du temps.
  
  Moi, le seul reproche que je ferais ce serait: "mais pourquoi diantre ne pousse-t-il pas cette lib dans Boost comme ca pleins de gens (talentueux) s'y mettraient et contribueraient !?".
  
  Quand on voit le nombre d'applications dans la vraie vie (TM) qu'aurait XTI, je suis sur que ce n'est pas une question du probleme de la "tour d'ivoire".
  Juste un bete probleme de manpower (parce que BS, il a quand meme un vrai boulot aussi a cote).

Voleur !

Posté par alenvers () le 04/03/2006 à 23:52. (lien). Évalué à 6.

>PS2 : Merci à alenvers pour ce post explicatif que j'ai repris sans
>aucune vergogne.

Me semblait bien que j'avais reconnu la plume habile et précise.

Ok, je ->[]

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : Sortie de la version 4.1 du compilateur GCC

Ca c'est de la bonne dépêche !

Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[+] [^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]C'est très bien -pedantic mais avec -std=c99 quand même

[^]D'autres outils

[^]Re: D'autres outils

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[+] [^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

[^]Re: Esperons que la qualité suivra

Gentoo

[^]Re: Gentoo

[^]Re: Gentoo

[^]Re: Gentoo

ObjectiveC++

[^]Re: ObjectiveC++

apple et gcc

Ubuntu Dapper

A propos des optimisations de code

[^]Re: A propos des optimisations de code

[^]Re: A propos des optimisations de code

[^]Re: A propos des optimisations de code

[^]Re: A propos des optimisations de code

[^]Re: A propos des optimisations de code

[^]Re: A propos des optimisations de code

[^]Re: A propos des optimisations de code

Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

[^]Re: Toujours pas l'intégration de GOMP...

Protection de la pile par défaut sur les prochaines releases des distros

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

[^]Re: Protection de la pile par défaut sur les prochaines releases des dis

C++0x

[^]Re: C++0x

[^]Re: C++0x

Voleur !