Journal Fin de gcc dans les *BSD ?

Posté par (page perso) .
Tags : aucun
1
16
sept.
2007
PCC est un compilateur C licencié sous BSD écris pendant les années 70.
Il serait 5 à 10 fois plus rapide que gcc et produirait des binaires suffisament optimisé.

Il a été importé [ http://undeadly.org/cgi?action=article&sid=2007091519520(...) ] dans OpenBSD [ http://marc.info/?l=openbsd-cvs&m=118988004013923&w=(...) ] et NetBSD [ http://mail-index.netbsd.org/pkgsrc-changes/2007/09/15/0009.(...) ].

Otto Moerbeek ayant nottament écris sur la mailling list de pcc
Of course the road is still long, but things really look promising

Serais-ce la fin du dernier gros morceau de code GPL chez les *BSD ?
  • # llvm

    Posté par . Évalué à 9.

    A mon avis quand ils arriveront au niveau d'optim de gcc, les devs gcc auront eu le temps de réécrire les optimisations pour qu'elles soient plus rapides.
    (Il n'y a même pas encore de SSA dans pcc...)
    Sinon a leur place j'aurais utilisé clang (front end C d'apple, licence BSD) +llvm (backend BSD, maintenu entre autre par apple). clang demande encore du travail avant d'etre utilisable (mais en attendant on peut utiliser gcc en back end), par contre llvm est bien plus avancé et il produit des optimisations très efficaces.
    • [^] # Re: llvm

      Posté par . Évalué à 7.

      Ca ne sera peut-être pas si long que ça pour le SSA: "Conversion to SSA format is also implemented, but not yet the phi function. Not too difficult though, after that strength reduction is high on the list." (1er lien). Cela dit, je suis d'accord pour LLVM, les optimisations ont l'air extrêmement poussées et ça a l'air conçu de manière très évolutive.
      • [^] # Re: llvm

        Posté par . Évalué à 5.

        Hum, SSA sans phi c'est pas très utile :) (en puis c'est beaucoup plus facile).

        Sinon c'est pas comme si un compilateur c'était un des logiciels les plus compliqués à écrire, en tout cas visiblement y'a plein de gens qui aiment tout refaire :)
        • [^] # Re: llvm

          Posté par . Évalué à 2.

          Oui enfin, poser des phi fonctions c'est pas dur non plus hein. Et si la représentation intermédiaire est bien faite, remonter les arcs c'est pas spécialement compliqué. Ce qui est difficile dans SSA, c'est le calcul des frontières de domination, etc. Donc tout dépend si l'algo est implémenté ou pas.
          • [^] # Re: llvm

            Posté par . Évalué à 1.

            Construire SSA sans l'utiliser après ca sert juste à rien. Et SSA sans phi j'appelle pas ça du SSA.
            Ensuite le phi c'est toujours le truc qui fait chier quand on fait un algo sur SSA (la copie est parallèle, le use est dans le bloc précedent, etc).
            Sinon construire SSA c'est vraiment trivial, si il arrive pas à le faire c'est que sa representation intermédiaire est à chier, le plus dur c'est de minimiser le nombre de phi sans que la construction prenne trop de temps.
            • [^] # Re: llvm

              Posté par . Évalué à 2.

              Construire SSA sans l'utiliser après ca sert juste à rien. Et SSA sans phi j'appelle pas ça du SSA.


              Moi j'appelle ça du "travail en cours".
              • [^] # Re: llvm

                Posté par . Évalué à 5.

                Raaah bon désolé de m'enerver mais faudrait arrêter... toute la communauté des compilos est morte de rire, pcc est présenté partout comme une innovation technologique qui va sauver *BSD du marasme, et on me répond que c'est du "travail en cours".

                Sérieux quand on voit le buzz que peut avoir ce truc qui est a mille lieux de la plupart des compilos académiques (qui sont encore loin des compilos de productions), c'est à se demander si les experts d'un domaine peuvent encore encore contre balancer la "foule" du web.

                Encore désolé, mais je viens de telecharger les sources et la c'est juste risible. J'ai rien contre pcc, c'est un bon projet de licence ou de master pour apprendre comment est fait un compilo mais c'est tout sauf une avancée technologique.

                (En plus si j'ai bien compris ce que vienne de faire NetBSD et OpenBSD, ils viennent de forker le projet en l'important chacun dans leur cvs, donc ca risque d'avancer encore moins)
                • [^] # Re: llvm

                  Posté par . Évalué à 4.

                  Intrigué par ton message, j'ai téléchargé les sources (sur http://www.ludd.ltu.se/~ragge/pcc/ ) et c'est vrai que ça a l'air plutôt basique pour un compilo C. Je vais essayer de le compiler pour voir la qualité du code x86 que ça génère. Sinon, comme son archi a l'air effectivement très simple, ça doit être excellent à étudier.
                  • [^] # Re: llvm

                    Posté par . Évalué à 3.

                    Jusqu'a il n'y a pas longtemps la seule archi supportée était PDP-11. Peut etre que c'est aussi pour ca qu'il developpe son compilo (est ce que gcc supporte encore PDP-11 ?)

                    Sinon je trouve llvm très facile d'accès pour comprendre comment marche un backend optimisant. (et clang étant en developpement si des gens veulent faire joujou avec un parser tout neuf, ils peuvent se faire plaisir)
                • [^] # Re: llvm

                  Posté par . Évalué à 5.

                  > mais c'est tout sauf une avancée technologique

                  D'un autre coté, si j'ai bien compris, le fait qu'il soit très simple et propre est précisément la raison de l'intérêt qu'il suscite. D'une façon générale, il est courant de voir des développeurs BSD réaffirmer leur attachement à la simplicité et la petite taille du code. Nonobstant cette simplicité, il semble que pcc sache déjà compiler (presque) tout le userland de NetBSD/i386 (et produise des binaires à peine 6 à 8% plus gros que ceux produits par gcc, ce qui n'est pas si mal à ce stade infantile de non-optimisations).

                  Et cet aspect est bel et bien un but du compilateur, tel qu'indiqué sur le site de PCC section « Goal » : « the intention is to write a C99 compiler while still keeping it small, simple, fast and understandable ». Preuve que la sophistication n'est pas toujours (ou pas pour tous) le critère d'ingénierie déterminant, s'agissant d'évaluer l'intérêt d'un logiciel.

                  > (En plus si j'ai bien compris ce que vienne de faire NetBSD et OpenBSD, ils viennent de forker le projet en l'important chacun dans leur cvs, donc ca risque d'avancer encore moins)

                  Tu a mal compris, donc.
                  NetBSD l'a simplement inclus dans pkgsrc (approximativement, pour rapprocher ça de quelque chose que connaissent les linuxien, ils en ont fait un package pour NetBSD).

                  Et OpenBSD l'a importé dans son cvs comme ils font avec tout les logiciels qu'ils veulent inclure dans le système de base (où re-travailler à partir de là). C'est leur façon de faire, je pense qu'ils trouvent cette méthode plus pratique, mais ce ne sont pas des forks : même les projets qui acceptent toutes les modifs d'OpenBSD upstream (par ex. Sendmail ou Sudo) sont inclus de la sorte dans leur cvs. Il faut garder en tête, lorsqu'on vient du monde Linux, que les *BSD ont une approche plus centrée sur le code source / le cvs (par opposition aux distributions Linux courantes, souvent plus orientées packages / bugzilla).

                  Bref, ça ne les empêche pas de re-synchroniser régulièrement leur copie des sources, et d'envoyer leurs modifications upstream.

                  En l'occurence, vous pouvez aisément voir qu'ils travaillent collaborativement, en lisant ce qui se passe sur la mailing-list de pcc. ML dont les archives viennent d'êtres incluses dans MARC, pour info : http://marc.info/?l=pcc-list&r=1&b=200709&w=2

                  Archive et collaboration qui me rappelle que, si on peut fortement s'inquiéter des problèmes sociaux causés par un compilo qui compilerai trop vite ( http://xkcd.com/303/ ), il ne faut pas bouder le plaisir de trouver un nouveau terrain où de nombreux devs NetBSD et OpenBSD peuvent se foutre sur la gueule collaborer publiquement. Ce qui nous offrira sans doute de superbes coups de hache dans les gencives débats pour les soirées d'un hiver qui vient à grands pas ! :)
                  • [^] # Re: llvm

                    Posté par . Évalué à 5.

                    > Nonobstant cette simplicité, il semble que pcc sache déjà compiler
                    > (presque) tout le userland de NetBSD/i386 (et produise des binaires
                    > à peine 6 à 8% plus gros que ceux produits par gcc, ce qui n'est pas
                    > si mal à ce stade infantile de non-optimisations).

                    compiler l'userland est un objectif, ils en sont loin...

                    > Et cet aspect est bel et bien un but du compilateur, tel qu'indiqué sur
                    > le site de PCC section « Goal » : « the intention is to write a C99
                    > compiler while still keeping it small, simple, fast and understandable
                    > ». Preuve que la sophistication n'est pas toujours (ou pas pour tous)
                    > le critère d'ingénierie déterminant, s'agissant d'évaluer l'intérêt d'un
                    > logiciel.

                    gcc est particulier à cause de Stallman qui ne veut surtout pas que le compilo ait 2 passes bien séparées. Il reste moultes compilos qui sont propres et bien plus avancés. Le buzz qui l'accompagne est ridicule (et je ne pense pas que c'était l'effet voulu par les gens qui l'ont importé dans *BSD et par upstream).
    • [^] # Re: llvm

      Posté par . Évalué à 3.

      N'était-il pas question de TenDRA à une époque? Pourquoi ce revirement?
    • [^] # Re: llvm

      Posté par . Évalué à 2.

      Le fait qu'LLVM et CFE soient écrits en C++ ça ne pose pas de problème pour le bootstrap ? Vu que CFE ne gère pas (encore ?) le C++...
      • [^] # Re: llvm

        Posté par . Évalué à 4.

        En même temps clang n'est pas encore utilisable pour le C. Par contre il commence à gérer pas mal pour l'analyse syntaxique, y'a pas des volontaires pour plugger ca dans vim et avoir une analyse temps réel des erreurs de syntaxe ?
        C'etait un des buts de clang de pouvoir analyser très rapidement le code pour les IDE.
  • # Fastoche

    Posté par . Évalué à 10.

    Dit comme ça, on dirait qu'écrire un compilateur est supair fastoche … on comprend même pas pourquoi on se pose tant de question pour la migration de gcc 4.1 à 4.2 …
  • # La rapidité ne suffit pas

    Posté par (page perso) . Évalué à 8.

    Certes, il peut etre rapide, mais pour les BSD il faut certainement aussi se poser d'autres questions :
    est il multi archi ?
    le code généré assure t il un niveau de sécurité suffisant ? (piles etc ...)
    et surement d'autres auxquelles je pense pas, je suis pas expert.
  • # Re: Fin de gcc dans les *BSD

    Posté par . Évalué à 10.

    Tout d'abord, BSD/PCC ne génère pas du code "suffisamment optimisé" mais du code "raisonnable" selon les termes utilisé par l'auteur. Ensuite, leur compilateur n'est pour l'instant qu'un compilateur de bootstrap pour compiler la base de *BSD sans utiliser GNU/GCC : il ne supporte à l'heure actuelle que le C99 et d'ailleurs il n'est même pas réellement capable de compiler toute la base des *BSD (openbsd/src.lib ne compile pas). Enfin, comparer ce embryon de compilateur à usage très spécifique avec un framework multi-plateforme et multi-langage comme GCC, je dis qu'il faut sévèrement être burné. Surtout pour ajouter qu'il est 5 à 10 fois plus rapide que GNU/GCC alors que BSD/PCC a été développé juste pour un usage spécifique : compiler la base des *BSD sans utiliser d'outils GNU.

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Fin de gcc dans les *BSD

      Posté par . Évalué à 7.

      Et personne chez les BSD ne dit que c'est un GCC killer d'ailleurs.
      • [^] # Re: Fin de gcc dans les *BSD

        Posté par . Évalué à -3.

        un GPL killer ou un RMS killer alors ?
      • [^] # Re: Fin de gcc dans les *BSD

        Posté par . Évalué à 7.

        « Et personne chez les BSD ne dit que c'est un GCC killer d'ailleurs. »

        Exact, on peut surtout lire un excès d'enthousiasme et un manque de réalisme dans les commentaires sur deadly.o et dans le corps de ce journal.

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Fin de gcc dans les *BSD

      Posté par . Évalué à 0.

      En gros on peut dire que ça ne sert à rien. Il faut aussi bootstrapper le compilateur. Ça ne sert à rien sauf :
      - à faire plaisir à des développeurs. Si c'est leur truc, il n'y a rien à redire.
      - permettre aux fanatiques BSD de dire "HAHA ! on s'en torche de GNU et de sa (L)GPL tyranique, on a un compilateur ultra-plus-mieux-bien que ce tout pourri et archi-lent de gcc.

      En passant, gcc se bootstrappe. Pour compiler gcc, on commence par compiler un mini-gcc (qui ne fait que compilateur C, n'est pas cross-plateforme, n'est pas optimisé, etc) et ce dernier est utilisé pour compiler gcc. Ça doit être un poil plus compliqué car je crois qu'il y a stage1 stage2 et final.

      J'ai rien contre pcc, mais j'ai rien pour.
      • [^] # Re: Fin de gcc dans les *BSD

        Posté par . Évalué à 3.

        En gros on peut dire que ça ne sert à rien. Il faut aussi bootstrapper le compilateur. Ça ne sert à rien sauf :
        [ ZAP ]

        - a pouvoir distribuer un ensemble avec licence cohérente ?
        Personnellement ça me gène pas de devoir utiliser un compilo spécifique pour le sys tème de base. D'ailleurs c'est aujourd'hui le cas: le système de base se compile avec une version précise de GCC ... donc que ce soit GCC ou un autre, peu importe.
    • [^] # Re: Fin de gcc dans les *BSD

      Posté par . Évalué à 4.

      il ne supporte à l'heure actuelle que le C99
      Ha pourtant je croyais que c'était un compilo des années 70. Les develo avaient utilisé IPOT ?

      Au fait pcc se compare comment par rapport à tcc ?
      • [^] # Re: Fin de gcc dans les *BSD

        Posté par . Évalué à 1.

        Je ne sais pas ce que vaut pcc, mais tcc fait tout en une passe, et n'optimise pas grand chose (càd : rien). Ce n'est pas son but. Donc si pcc optimise des trucs, alors il est sans doute plus performant que tcc :-)
      • [^] # Re: Fin de gcc dans les *BSD

        Posté par . Évalué à 1.

        tcc est sous licence GPL ce qui arrache des hurlements de douleur aux BSDistes.
        Juré, c'est une horreur. Certains se tapent la tête contre les murs, d'autres se font des saignées, etc...
        • [^] # Re: Fin de gcc dans les *BSD

          Posté par (page perso) . Évalué à 5.

          Passer d'un compilateur sous GPL portable mais laid à un compilateur en GPL pas portable, pas maintenu et surement pas plus beau (Fabrice Bellard est un génie mais la qualité du code est parfois plus que douteuse, et le code est quand meme basé sur un code IOCC ...), ca serait en effet une grande avancée :).

          tcc n'est tellement pas maintenu qu'il existe un "bug de securité" connu depuis Février 2006 et toujours pas corrigé dans une release ...(http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-0635).

          Sinon la GPL c'est du tout bon .... pour les avocats :). Pour le reste, cela reste à prouver ...
          • [^] # Re: Fin de gcc dans les *BSD

            Posté par . Évalué à -1.

            > Sinon la GPL c'est du tout bon .... pour les avocats :). Pour le reste, cela reste à prouver ...

            La BSD c'est bon pour les brevets et les brevet c'est tout bon pour les avocats.
        • [^] # Re: Fin de gcc dans les *BSD

          Posté par . Évalué à 4.

          C'est lourd et pas très drôle en plus d'être une généralisation abusive (surtout de la part de quelqu'un qui persiste au moins 3 fois dans la même erreur après avoir été corrigé) ton running gag sur les BSDistes.
  • # Re:

    Posté par . Évalué à 3.

    > Il serait 5 à 10 fois plus rapide que gcc et produirait des binaires suffisament optimisé

    Visual C++ est aussi très rapide pour compiler (probablement 4 à 6 fois plus rapide que gcc).
    Pour le reste il n'est pas du niveau de gcc. Je boose actuellement avec Visual C++ (consigne du boss), ben c'est presque une daube à côté de gcc.
    Que Visual C++ soit plus rapide que gcc, ne lui donne aucun charme de plus. Si à l'avenir je peux éviter Visual C++, je l'éviterai.
    • [^] # Re: Re:

      Posté par . Évalué à 6.

      Que Visual C++ soit plus rapide que gcc, ne lui donne aucun charme de plus.

      Un compilo qui va "seulement" 2 fois plus vite que gcc a au moins le charme de compiler un OS complet en 2 fois moins de temps. Surtout quand il faut tester plus d'une dizaine d'archis.
      C'est aussi pour ca qu'il est important pour un projet consequent de compiler rapidement, meme si le binaire final n'est pas super optimise, au moins le code a passe le test du "make word".
      • [^] # Re: Re:

        Posté par . Évalué à 3.

        Mouaif....

        Quand tu es développeur (et pas seulement un gentoo lover), tu ne passes pas ton temps à compiler des OS. Tu compiles ton code et il y a make pour compiler que ce qui est nécessaire. Make peut aussi compiler en parallèle (option -j) pour profiter d'un dual/quad core/cpu. Dans ce contexte, la vitesse de gcc est largement bonne.

        Je suivais la mailing devel Fedora. Les rebuilds de tout l'OS (dit mass rebuild chez Fedora) sont très rares (un par an à cause d'un changement de version majeur de gcc). Pour F8 ça a été exceptionnel, il y a eu 2 mass rebuild (le premier a utilisé un gcc buggé). Les mass rebuild sont fait en une voire deux journées et pour 4 architectures. Il me faut préciser que Fedora utilise un cluster pour les compilations. Les développeurs Fedora ne font pas des "make world" histoire pour pourrir la planète, il récupère les binaires fait par Fedora.

        > C'est aussi pour ca qu'il est important pour un projet consequent de compiler rapidement

        Tu veux dire que les *BSD sont des OS gras ?

        > au moins le code a passe le test du "make word".

        J'en ai des frissons dans le dos.
        • [^] # Re: Re:

          Posté par . Évalué à 4.

          Quand tu changes une structure "sensible" ou que tu ajoutes du code intrusif, il faut _toujours_ tout recompiler.
          C'est sur lorsque tu modifies netcat c'est pas la meme chose que modifier le code du routing, UFS ou autres changements intrusifs.

          C'est fallacieux de comparer un BSD a fedora. C'est pas du tout la meme contrainte.
          • [^] # Re: Re:

            Posté par . Évalué à -2.

            > Quand tu changes une structure "sensible" ou que tu ajoutes du code intrusif,

            Ben tu le fais rarement. Sinon il y a un bug de conception. De plus il y a la libc entre le noyau et les applis et la libc supporte les versions (on peut donc avoir plusieurs versions d'une API).
            Un OS qui demande de tout recompiler toutes les semaines est un OS qui sucks grave de chez grave.

            > il faut _toujours_ tout recompiler.

            Non.

            > que modifier le code du routing, UFS

            Dans ce cas tu recompiles le noyau et c'est l'affaire de 10 ou 20 minutes.

            > C'est fallacieux de comparer un BSD a fedora.

            Ouais, BSD c'est naze, il faut tout recompiler toutes les semaines.
            • [^] # Re: Re:

              Posté par . Évalué à 1.

              Tu es bien remonté contre Gentoo dis donc. Si tu utilisais une Gentoo tu te rendrais compte que changer de version du compilateur peut tout casser, même sans changer au code. J'ai un ami qui a compilé certaines libs centrales avec un nouveau gcc, tout ce qui en dépendant ne marchait plus. Il fut obligé de tout recompiler avec le même compilateur. C'est ce qui s'appelle la compatibilité binaire . Et ce n'est pas un problème de Gentoo, c'est jusque que dans les distributions binaire les mainteneurs des paquets y font le bouleau pour toi.

              Quant à comparer Fedora et BSD, j'suis pas un expert dans les deux mais c'est clairement pas les mêmes buts. Pour le citer qu'OpenBSD et NetBSD, l'un se voulant une forteresse imprenable et l'autre voulant tourner même sur les grilles pains, et Fédora qui se veut le plus user friendly (ce qui ne veut pas dire que les BSD ne se veulent pas userfriendly !) il y a tout un monde.
              • [^] # Re: Re:

                Posté par . Évalué à 2.

                Tu es sur que l'incompatibilité n'est pas due à un changement de version des librairies plutot qu'a une version de gcc differente ?
                • [^] # Re: Re:

                  Posté par . Évalué à 2.

                  En fait, je pense que le changement mentionné est un changement de version de GCC qui a entraîné un changement de la version de la libstdc++.

                  Il y a donc eu 2 possibilités : continuer d'utiliser l'ancienne version de la libstdc++ ou utiliser la nouvelle. Sachant que dans le cas d'un soft utilisant plusieurs librairies, il est impératif que ce soft et ces librairies utilisent la même version de la libstdc++.

                  Bref, tôt ou tard, il a fallu recompiler toutes les applis/libs utilisant le C++ (ce qui est loin d'être la totalité de la distribution...).
                • [^] # Re: Re:

                  Posté par (page perso) . Évalué à 1.

                  Ça dépends du langage. En C, l'ABI est relativement stable, pas de problème au changement de compilo. En C++, l'ABI change assez régulièrement, une applie compilée avec une version de g++ de pourra pas forcément linker avec une bibliothèque compilée avec une version plus ancienne (de mémoire, il y a eu cassage d'ABI C++ avec gcc 4.0, 3.2, 3.1 et 3.0 au moins).
                  • [^] # Re: Re:

                    Posté par . Évalué à 1.

                    En C++, l'ABI change assez régulièrement
                    Enfin bon là c'est sensé être fini avec gcc 4.
                    • [^] # Re: Re:

                      Posté par . Évalué à 1.

                      > Enfin bon là c'est sensé être fini avec gcc 4.

                      Où tu as lu ça ?
                      Je ne crois pas les développeurs assez cons pour dire "jamais".
                      • [^] # Re: Re:

                        Posté par (page perso) . Évalué à 2.

                        Bah ils sortiront gcc 5 quand ils voudront tout peter, c'est pas un jamais, où est le probleme ? :)
                        • [^] # Re: Re:

                          Posté par . Évalué à 2.

                          Aucun.
                          Notons que la compatibilité sur tous les gcc 4 n'est pas assurée. Par exemple ce qui est compilé avec Fedora 5 ne peut tourner sur Fedora 4. Ce n'est pas un problème de version de librairie mais de compilateur/édition de lien. Mais ce n'est pas un problème car pratiquement personne ne l'a remarqué :-)
                    • [^] # Re: Re:

                      Posté par (page perso) . Évalué à 4.

                      Je ne sais pas ce qu'il en est avec GCC 4, mais en tous cas, GCC 3.2 devait avoir une ABI stable, et tout et tout, et ça n'a pas duré bien longtemps.
          • [^] # Re: Re:

            Posté par . Évalué à -2.

            > c'est pas la meme chose que modifier le code du routing, UFS ou autres changements intrusifs.

            En passant, Linus Torvalds (himself) utiliser une Fedora. Les changements intrusifs il connait et il ne recompile pas tout tout les matins (Fedora n'est pas Gentoo).
            Linus Torvalds est un "plouc" car il ne fait pas de "make word" ?
            • [^] # Re: Re:

              Posté par . Évalué à 3.

              Linus Torvalds est un "plouc" car il ne fait pas de "make word" ?

              Je n'ai jamais dit ca. Mais la aussi ce n'est pas la meme contrainte kernel != OS
              Mais on va prendre des exemples concrets.
              geom_journal sous FreeBSD:
              En plus du module geom pour la journalisation, il a fallu modifier pas mal d'outils userland (newfs, tunefs, mount, fsck etc...) a cause du changement de structures, ajouter BIO_FLUSH dans le VFS et d'autre. Pour cela il faut s'assurer que ca compile partout et correctement. Certes, on ne compile pas tout a chaque fois, mais a chaque changement important, il faut s'assurer que ca fonctionne.
              Sans compter que dans ce cas la, l'endianness entre en jeu.

              Idem pour le routing. Il faut modifier le code kernel + route + la libc + pf + ce qui en depend (opsfd et openbgpd par ex).
              • [^] # Re: Re:

                Posté par . Évalué à -1.

                > Mais on va prendre des exemples concrets.
                > geom_journal sous FreeBSD:

                Certe, mais c'est changé tout les combiens ?
                Tous les 3 mois ou tous les ans ?
                Es-ce intéressant d'utliser et de développer un compilo "bas de gamme" qui va vite uniquement pour ça ?
                De plus ses programmes se compilent vite. Ils sont très petits et même si tu en as une dixaine, c'est l'affaire de 10 minutes (c'est le temps pour la bécane, pour toi ça risque d'être plus long (récupérer les sources, ./configure, installation, etc...)).

                C'est quasi sans intérêt. De plus il faut voir la contre partie. Un compilo qui fait moins de vérification que gcc, qui n'est pas cross-plateform, qui n'est pas "renforcé" (controle de débordement), etc, etc...

                C'est très bien de faire un "make word" pour voir si tout est cohérent. On peut trouver des bugs etc...
                Mais les développeurs qui font ça sont rares. En tout cas, il a autre chose à foutre que ça.

                Je dis ça sans le moindre mépris, mais ce n'est pas un boulot de développeur, c'est un boulot de testeur (et j'ai beaucoup fait de tests et j'ai beaucoup de respect pour les testeurs, il faut du talent pour être un bon testeur). Dans le cas de Fedora, il y a des bécanes qui sont affectées à ça avec des procédures automatiques, un scheduler pour plannifier les tests, etc...
                Au "petit matin" un mail est envoyé sur la mailing devel et les développeurs regardent ce qui les concernes.

                En passant, Fedora utilise moch ce qui permet avec une bécane de compiler un programme pour FC4, FC5, FC6, F7, pour i386 pour amd64, etc.
                Tu ne lance pas à moch à chaque fois que tu change une ligne de ton code, mais lorsque tu veux diffuser et t'assurer de la qualité du code (es-ce qu'il compile partout ? sur toute les architectures ? il y a-t-il des fichiers en conflit avec d'autres paquets, etc).
                • [^] # Re: Re:

                  Posté par . Évalué à 2.

                  Comme c'est expliqué dans le commentaire cité dans le commentaire plus bas (par moi-même),
                  le but de l'inclusion d'un nouveau compilateur dans openbsd n'est pas ce que tu décris et même le contraire sur certains points
                  (et j'ai la flemme de les recopier ici :)
        • [^] # Re: Re:

          Posté par (page perso) . Évalué à 3.

          Quand tu es développeur (et pas seulement un gentoo lover), tu ne passes pas ton temps à compiler des OS. Tu compiles ton code et il y a make pour compiler que ce qui est nécessaire. Make peut aussi compiler en parallèle (option -j) pour profiter d'un dual/quad core/cpu. Dans ce contexte, la vitesse de gcc est largement bonne.

          Ben, quand tu compiles du code genere' par du code, tu peux te retrouver avec un gros bouzin. J'ai du code qui met plus de 30 minutes a compiler *un seul fichier* (et d'ailleurs, GCC plante souvent sur ce genre de donnees). Et la, vu le code genere, ben, j'ai beau avoir un 16 coeurs, ca m'aide pas... (Et non, on peut pas trivialement generer le code dans plusieurs fichiers)
          • [^] # Re: Re:

            Posté par . Évalué à 3.

            Le code qui met 30 minutes à être compilé, c'est la plupart du temps du code qui à un problème. J'ai déjà rencontré ça avec plusieurs compilo (Sun, Windows), et à chaque fois tu peux comprendre pourquoi la compilation est lente.

            Par exemple, une méthode avec de nombreux objets, créés sur la stack, visible dans l'intégralité de la méthode, et de nombreux return. Le compilateur doit générer du code pour détruire les objets avant chaque return, ce qui génère un executable énorme et long à compiler.
            • [^] # Re: Re:

              Posté par . Évalué à 3.

              Ah.

              Je connais au moins un domaine où la compilation peut prendre un temps pas possible : le calcul haute performance.

              Un code scientifique, comportant de nombreuses indirections de tableaux (inévitables, car usant de maillages adaptatifs et de matrices creuses, qui intrinsèquement nécessitent ce genre de structures de données), avec pourtant le maximum de code dont le comportement est statiquement connu à la compilation (parce que programmé en FORTRAN 77 et donc pas de risque d'aliasing, etc), ça peut mettre dans les 45-60 minutes à compiler. Bon ok, le fait que le compilateur voie plein d'opportunités d'optimisation peut clairement jouer, mais la complexité du code est la principale raison de la lenteur de compilation.

              Ici donc, pas d'objet, du bête code, à peine mieux que de l'assembleur (bon ok, j'exagère un chouilla).

              Par contre, si on parle « presqu'objet », parlons des templates, qui de par leur côté totalement statique fait que les temps de compilation s'allongent, s'allongent ...

              Enfin, là on parle de code C, et effectivement, gcc est clairement beaucoup plus lent qu'avant, alors qu'il a relativement peu de choses à analyser (comparé à du code C++).
    • [^] # Re: Re:

      Posté par (page perso) . Évalué à 4.

      Enfin, sous Windows, cela compile vite lorsque tes fichiers sont en local sur ta machine car dès que tu es sur un partage réseau, cela n'avance plus au niveau compilation.

      Avec gcc, un Makefile correct et des fichiers sur nfs, cela va à une vitesse raisonable.

      Bref, la vitesse est toute relative et peut fortement dépendre de ton environnement.
      • [^] # Re: Re:

        Posté par . Évalué à 5.

        Je me suis mis à Visual C++ depuis quelques mois (faut bien manger :-)), et quand je vois des critiques sur gcc, je ne comprend pas. Gcc est de la balle. Qu'il compile 10 fois plus lentement que Visual C++, je m'en fous.
        • [^] # Re: Re:

          Posté par (page perso) . Évalué à 2.

          Enfin, ma remarque sous Windows concernait VisualC++ même si avec gcc, c'est du pareil au même. Je pense que le problème est intrinsèque au protocole CIF qui ne permet pas de réellement travailler sur l'espace partagé en tant que développeur.

          Alors que sous UNIX, j'ai toujours travaillé sur des partages NFS sans jamais avoir eu l'impression que gcc ou nag ou icc était lent. Comme je développe à 99% sous linux, pour moi gcc, c'est que du bonheur ;-)
        • [^] # Re: Re:

          Posté par . Évalué à 1.

          J'ai l'impression qu'on compare des pommes à des oranges. La version stable de mingw actuellement disponible est un port de la branche 3.4.x de GCC, le port de la branche 4.2.x est disponible en "preview" et depuis peu, il me semble.
          Après, je plussois isNotGood, je préfére un compilo aussi strict, respectueux des normes et ubiquitaire que l'est GCC, à un compilo plus rapide bogué et avec un support des normes incomplet. Quitte à comparer GCC à un autre compilateur, autant le comparer à ICC.
          • [^] # Re: Re:

            Posté par . Évalué à 1.

            je préfére un compilo aussi strict, respectueux des normes et ubiquitaire que l'est GCC,
            Enfin niveau warning, gcc est loins derrière icc quand meme.
            (Comment ca je parle pas de vc++ ? et alors ?)
            • [^] # Re: Re:

              Posté par (page perso) . Évalué à 1.

              ah ? mon sentiment est que contrairement à icc, gcc ne sort quasiment que des warnings "utiles" . Icc genere beaucoup de bruit sans interet
              • [^] # Re: Re:

                Posté par . Évalué à 1.

                mate les warning de icc, sans parler de leur récurrence ou autre. J'ai trouvé qu'il était mieux explicité que ceux de gcc (ca remonte a loin toutefois, je peux me tromper)


                En outre
                Il y a peut etre plus de bruit, mais gcc ne sort pas tout , loin de la. Et quant tu fait du multi archi, tu est content de faire au moins une passe avec le plus de recommandation possible.
                Ensuite bien entendu, à toi de vérifier si ca correspond à quelque chose.

                En somme je prefere, pour un avertissement, un truc qui fait que des faux positifs, plutot qu'un truc qui fait des faux négatifs et des faux positifs.

                Bien entendu le mode warning de icc c'est simplement pour faire des tests, pas pour dvp tous les jours (alors que les warnings de gcc si).

                enfin c'est juste ma préférence perso aussi.
          • [^] # Re: Re:

            Posté par . Évalué à 2.

            Pardon, je n'ai jamais utilisé mingw. J'ai utilisé gcc sous HPUX, DEC et Linux mais jamais sous Windows.
            J'ai du code qui compile sous Windows et Linux, et sous Linux (gcc) la compilation est beaucoup plus lente. Mais je m'en fous.

            > je préfére un compilo aussi strict, respectueux des normes et ubiquitaire que l'est GCC, à un compilo plus rapide bogué et avec un support des normes incomplet.

            VC++ c'est "pire". Il y a des cas (certe complexes) où VC++ perd le type d'un pointeur.

            Par exemple :
            class CToto : public virtual CTiti, public virtual CTutu {}
            CToto * ptoto = new CToto ;
            CTiti * ptiti = ptoto ; // plantage avec VC++ alors que ça roule avec gcc. Un dynamic_cast n'arrange rien (il est d'ailleur sans intérêt ici normalement).

            VC++ m'a donné des cauchemards. J'avais finit de coder (3 mois de développement), j'étais content de ma hiérarchie d'object "et tout". Je compile: OK. J'exécute : explosion dans tous les coins. Je "porte" sous Linux/gcc, ça marche comme un charme. Ça m'a pris presque deux semaines pour voir que c'était un bug de VC++. Ça m'a pris une semaines pour réorganiser mon code afin qu'il tourne avec VC++. Donc : 3 semaines de perdu. Et vraiment perdu. Si le compilateur est lent, je peux boire un café, discuter, bosser sur autre chose, etc...
            • [^] # Re: Re:

              Posté par . Évalué à 3.

              VStudio 2005 SP1 :

              class Bob
              {
              public:
              Bob() {c=0;}
              virtual int Get() {return c;}
              private:
              int c;
              };

              class Foo
              {
              public:
              Foo() {d=1;}
              virtual int GetFoo() {return d;}
              private:
              int d;
              };

              class Bar : public virtual Bob, public virtual Foo
              {
              public:
              Bar() {};
              virtual int GetValue() {return GetFoo();}
              };


              int __cdecl wmain(int argc, WCHAR *argv[])
              {

              Bar* NewVal=new Bar;
              Bob* Cast=NewVal;
              printf("%d\n",Cast->Get());
              return 0;
              }

              Affichage : 0

              Bref, ton exemple marche tres bien sous VC++
              • [^] # Re: Re:

                Posté par . Évalué à 1.

                Mon "vrai" exemple qui ne marche pas fait plusieurs milliers de ligne. Désolé de ne pas avoir fait un copié/collé ici. Enfin, il faut aussi utiliser les fonctions virtuelles pures pour avoir ce problème.

                > class Bar : public virtual Bob, public virtual Foo

                Tes virtual ne servent à rien dans ton exemple.
                • [^] # Re: Re:

                  Posté par . Évalué à 3.

                  T'es sur que le probleme vient du compilo et que tu n'as pas fait une bourde qui par chance passe dans gcc ? C'est le genre de truc qui m'est arrive quelque fois.

                  Sinon, ca m'interesserait d'avoir une reproduction du probleme.

                  (pour les public virtual, le but etait simplement de recopier ton code)
                  • [^] # Re: Re:

                    Posté par . Évalué à 1.

                    > T'es sur que le probleme vient du compilo et que tu n'as pas fait une bourde qui par chance passe dans gcc ?

                    Voilà ce qui ne marchait pas (une petite partie des entêtes) :
                    class CMixerBmpD3D : public virtual CBmpD3DDesc {
                    virtual ... = 0 ;
                    }
                    class CMixerBmpD3DSurf : public virtual CMixerBmpD3D {
                    }
                    class CMixerBmpD3DTex : public virtual CMixerBmpD3D {
                    }
                    class CMixerShot : public virtual CShotDesc, public virtual CMixerBmpD3D {
                    int entier_CMxierShot ;
                    virtual ... = 0 ;
                    void fonction_CMixerShot() {
                    entier_CMixerShot++ ;
                    }
                    class CMixerShotSurf : public virtual CMixerShot, public virtual CMixerBmpD3DSurf {
                    }
                    class CMixerShotTex : public virtual CMixerShot, public virtual CMixerBmpD3DTex {
                    }


                    Ce qui ne marchait était par exemple :
                    CMixerShotTex * pTex = new CMixerShotTex ;
                    CMixerShot * pShot = pTex ;
                    pShot->fonction_CMixerShot() ; // plantage.

                    Il n'y a pas forcément plantage à l'appel de la fonction mais plantage lors de "entier_CMixerShot++". Un affichage de "*this" dans le débuggeur donne du n'importe quoi alors que je suis dans une fonction membre ! C'est définitivement une erreur du compilateur.

                    Autre problème :
                    CMixerShotTex * pTex = new CMixerShotTex ;
                    CMixerShot * pShot = dynamic_cast<CMixerShot *>(pTex) ;

                    Le dynamic_cast n'est pas nécessaire. Mais si je l'utilise, pShot est égal à NULL. C'est encore définitivement une erreur du compilateur.

                    Autre problème :
                    CMixerShotTex * pTex = new CMixerShotTex ;
                    f(pTex) ;
                    f(CMixerShot * pShot) {
                    CMixerShotTex * pTex = dynamic_cast<CMixerShotTex *>(pShot) ; // retourne NULL alors que c'est un CMixerShotTex *
                    }

                    Pour régler le problème, j'ai viré CMixerShot (j'ai déplacé des données/fonctions) et tout regroupé dans CMixerBmpD3D.

                    > T'es sur que le probleme vient du compilo

                    Oui, j'ai vu une page web qui en parle mais je ne l'ai plus. Parfois VC++ n'arrive pas à déterminer le type d'un object.

                    Les "public virtual" sont nécessaires car il y a des données en commun entre CShotDesc et CMixerBmpD3D entre autre.
                    • [^] # Re: Re:

                      Posté par . Évalué à 1.

                      En passant, j'ai aucun warning sous gcc et aucun warning sous VC++.
                      Le dynamic_cast déclenche une exception __non_rtti_object (ou un truc dans ce goût) alors que c'est compilé avec /GR (stupidement non par défaut dans le compilateur VC++, ce qui ne respecte pas le standard ISO...).
                    • [^] # Re: Re:

                      Posté par . Évalué à 1.

                      Pour info et expliquer en parti les "public virtual", CShotDesc est dérivé de CBmpD3DDesc et CMixerBmpD3DDesc est aussi dérivé de CBmpD3DDesc.
                    • [^] # Re: Re:

                      Posté par . Évalué à 2.

                      Ce qui ne marchait était par exemple :
                      CMixerShotTex * pTex = new CMixerShotTex ;
                      CMixerShot * pShot = pTex ;
                      pShot->fonction_CMixerShot() ; // plantage.


                      Il me faudrait voir le code pour confirmer, mais je suis 99.999% sur que le probleme est dans ton code ou du a qqe chose de bien complique.

                      Ce dont tu parles ici c'est de l'heritage de base, appeler une fonction de la classe parente, j'ai pondu assez de cas identiques depuis des annees (ainsi que des milliers d'autres softs compiles en C++ dans VC++) pour savoir qu'un cas banal comme cela fonctionne sans aucun probleme.
                      • [^] # Re: Re:

                        Posté par (page perso) . Évalué à 1.

                        J'avais récemment le cas d'une classe contenant plein de CString, que j'ajoutait dans un CArray. Dans une boucle, je faisais régulièrement un new de cette classe que j'ajoutait ensuite au CArray. je me retrouvais ensuite avec une collection du même pointeur (le dernier ajouté).
                        Les spécialistes du C++ dans la boite ont conclu à un bug du compilateur (VC98).

                        A la décharge de krosoft (dont le dernier logiciel dépourvu de bug que j'ai connu était le BASIC 128 sur TO9), C++ est un langage horrible(ment complexe) et ça doit pas être facile.

                        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                        • [^] # Re: Re:

                          Posté par (page perso) . Évalué à 6.

                          En même temps tu parles d'un bug dans un compilateur qui a 9 ans d'âge ! Est-ce vraiment sérieux de continuer à utiliser cette bouse de VC6 ?
                          • [^] # Re: Re:

                            Posté par (page perso) . Évalué à 5.

                            Pose la question à mon chef...

                            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                  • [^] # Re: Re:

                    Posté par . Évalué à 2.

                    Grand pasBill pasGates, grand spécialiste de Windows, dans le débuggeur lorsque je suis sur "delete quelquechosequejaidéfini" et que je fais un "pas à pas détaillé" , pourquoi parfois il me fait un "pas à pas principal" ?
                    C'est vraiment casse couille.
                    • [^] # Re: Re:

                      Posté par . Évalué à 3.

                      C'est qqe chose qui m'est arrive qqe fois, et bien que n'etant pas expert de VStudio, ce que j'ai realise c'est que cela arrive souvent lorsque le debugger n'a pas la version a jour des symboles pour le code en question, ou que le code a ete optimise et que le destructeur a ete vire car non necessaire pour raison x ou y.
                  • [^] # Re: Re:

                    Posté par . Évalué à 1.

                    > Sinon, ca m'interesserait d'avoir une reproduction du probleme.

                    Désolé, mais le code est propriétaire :-(
                    J'avais fait un fichier .cpp minimum pour reproduire le bug (savoir spécifiquement ce qui ne marchait pas) mais j'ai foutu ce fichier à la poubelle. C'est ce fichier qui marchait nickel avec gcc et qui plantait toujours VC++. La vrai appli n'a pas été porté sous Linux (c'est quasi impossible).
                    Si tu vires tous les "public virtual", ça semble marcher sous VC++. Mais je n'ai plus ce que je veux et plein de duplication de donné très difficile à gérer. Donc ça semble marcher par j'ai fait peu de tests pour ce cas.

                    Autre problème avec VC++, je voulais un "constructeur virtuel". Un truc dans ce goût :
                    CMixerBmpD3D::Clone() = 0;
                    CMixerBmpD3DTex::Clone() ;
                    CMixerShot::Clone() = 0;
                    CMixerShotTex::Clone() ;

                    CMixerShotTex * pTex = ... ; // <= C'est un CMixerShotTex
                    f(pTex) ;
                    f(CMixerBmpD3D * pBmpD3D) {
                    CMixerBmpD3D * p = pBmpD3D->Clone() ; // Ici avec VC++ appel de CMixerBmpD3DTex::Clone() et non CMixerShotTex::Clone().
                    }


                    Marche nickel avec gcc, sucks avec VC++.
                    • [^] # Re: Re:

                      Posté par . Évalué à 1.

                      Euh, tes classes CMixerBmpD3D et CMixerShot elles sont derivees d'un parent commun qui definit Clone ?

                      Si non, alors il est tout a fait normal que ca ne marche pas. Que la fonction ait le meme nom ne signifie pas que ces methodes sont identiques et heritent entre elles.

                      Si oui, alors je suis 100% sur que ton truc marche sous VStudio, c'est le b-a-b-a de l'heritage ca et je l'ai assez fait (sans parler du fait que Firefox, OO, ... qui compilent sous VC++ sous Windows le font surement aussi) pour savoir que ca marche parfaitement.
                    • [^] # Re: Re:

                      Posté par . Évalué à 4.

                      Oublie je viens de voir plus haut que CMixerShot derive de CMixerBmpD3D.

                      Ton probleme il me semble c'est que ton CMixerShotText derive de CMixerShot directement ET de CMixerBmpD3D (heritage multiple). Hors ces 2 classes derivent d'un ancetre commun.

                      Resultat il y a ambiguite entre les methodes vu que ces 2 classes ont des methodes identiques.

                      C'est un probleme classique de design et connu : http://www.parashift.com/c++-faq-lite/multiple-inheritance.h(...)

                      Le fait que ca marche sous gcc et pas VC++ est de la pure chance, car la spec ne dit pas quoi faire.
    • [^] # Besoin de vitesse de compilation (au moins pendant les cycles de dev)

      Posté par . Évalué à 10.

      OpenBSD supporte officiellement des archis très vieilles et lentes comme Vax. Et ils ont pour habitude de compiler tout le cvs en boucle (pour intercepter les problèmes de portabilité - tout les devs n'ont pas un Vax ou un mac68k à la maison - et en même temps pour stresser la VM sur ces diverses archs normalement peu utilisées (donc moins testées)).

      Ils n'ont pas les moyens financiers de Linux (nombreuses sociétés et particuliers impliqués dans le dev/testing kernel et la libc + distros pour réparer en aval), pour s'offrir de gros clusters de Vax, Zaurus, hppa et de mac68k (et payer la note d'éléctricité !) à chaque fois qu'un header d'X.org ou de la libc change.

      On peut donc aisément comprendre leur besoins de compilations rapides.

      D'autre part, et au moins pour le moment, il ne s'agit pas de *remplacer* gcc par pcc (ni même de produire les binaires finaux de certaines archs avec pcc). Je crois que pour le moment l'intéret immédiat est simplement de disposer d'un compilo très rapide, pour accélérer le développement et la remontée de bugs, mais gcc reste là. D'après les explications que j'ai pu lire, c'est la motivation déterminante (et non une guerre de religion sur la licence).

      (ps: accessoirement, recompiler tout le système avec un nouveau compilateur permet aussi de trouver de nouveaux bugs dans le système : Anders Magnusson dit avoir trouvé plein de bugs en compilant le userland NetBSD avec pcc).
      • [^] # Re: Besoin de vitesse de compilation (au moins pendant les cycles de dev

        Posté par (page perso) . Évalué à 6.

        > recompiler tout le système avec un nouveau compilateur permet
        > aussi de trouver de nouveaux bugs dans le système

        Parfaitement d'accord la dessus. Je me souviens avoir trouvé plein de bogue dans un programme qui marchait pourtant particulièrement bien lors du passage à Linux alors que le code compilait à l'époque sur SGI et SUN. Le jour ou on a eu un accès à un CRAY, on a encore retrouvé des bogues incroyable !

        Bref, parfois, on se demande comment cela peut marcher aussi bien.
  • # Pourquoi changer ?

    Posté par . Évalué à 10.

    Ce commentaire sur undeadly montre pleins de raisons intéressantes qui expliquent l'abandon de gcc : http://undeadly.org/cgi?action=article&sid=2007091519520(...)
  • # Re ; Fin de gcc dans les *BSD ?

    Posté par (page perso) . Évalué à 8.

    pcc n'a pas été importé dans NetBSD mais dans pkgsrc aka il est plus facile d'installer et de suivre les modifications de ce logiciel (et pkgsrc supporte bien plus que NetBSD comme Os cible).

    Pcc permet de compiler les sources de NetBSD/i386. Cela permet surtout de vérifier que le code est portable , et de détecter un certain nombre de gnuisme. Pour l'instant l'impact de pcc s'arrête la pour NetBSD.

    Apres espie@OpenBSD.org a très bien expliqué les nombreuses raisons pour lesquelles ils seraient souhaitable d'avoir un autre compilateur de gcc. Rappellons par exemple qu'on a jamais reussi a booter un kernel VaX avec gcc3 ...

    C'est à mon avis bien trop tôt pour intégrer pcc au cvs d'OpenBSD mais rien ne m'etonnent de leur part (ils feraient mieux de contribuer directement à pcc m'enfin je suis sur qu'ils vont préférer écrire OpenCC dans leur coin).
    • [^] # Re: Re ; Fin de gcc dans les *BSD ?

      Posté par . Évalué à 6.

      ton commentaire aurait pu être excellent sans ton troll de fin.
      • [^] # Re: Re ; Fin de gcc dans les *BSD ?

        Posté par (page perso) . Évalué à 2.

        J'admets, j'admets, je n'ai pu m'empecher de résister au troll.

        Toutefois, je suis convaincu de l'ininteret de rentrer pcc dans le cvs de OpenBSD.

        Tout d'abord, parce que ca ne sert à rien pour 99,99 % des utilisateurs d'OpenBSD.

        Deuxièment, parce que ce ne va pas accélérer le developpement de pcc en tant que projet externe. Ils vont devoir synchroniser regulièrement leur arbre de source avec celui de pcc (actuellement ils le font à la main ...) et ensuite ils vont faire une modification dans leur arbre puis au mieux remonter dans pcc la modification (et ils verront un bon conflit apparaitre lorsqu'ils synchroniseront les arbres de source).

        Je ne vois donc pas l'interet d'avoir intégrer pcc à l'arbre de source, sauf evidemment si ils comptent "forker". M'enfin nous verrons bien.
        • [^] # Re: Re ; Fin de gcc dans les *BSD ?

          Posté par . Évalué à 1.

          C'est bien simple, d'après ce que je lisais, il n'y a tout simplement pas de main d'oeuvre dans OpenBSD (parce que pas de temps libre, trop de trucs plus urgents à faire) à consacrer à un compilateur quelconque. Donc non, pas de OpenCC ou autre.
          • [^] # Re: Re ; Fin de gcc dans les *BSD ?

            Posté par . Évalué à 5.

            > C'est bien simple, d'après ce que je lisais, il n'y a tout simplement pas
            > de main d'oeuvre dans OpenBSD (parce que pas de temps libre, trop
            > de trucs plus urgents à faire) à consacrer à un compilateur quelconque.

            Pas beaucoup - pas assez - mais un petit peu quand même (de la main d'oeuvre). Par ex. :

            - Un ou deux employés de Coverity (boite qui maintient un fork de gcc dédié à l'analyse statique de code) sont des développeurs d'OpenBSD (au moins Ted Unangst)
            - Marc Espie, qui maintient depuis longtemps les semi forks de gcc (2.95 et 3.3.5 + patchs propolice) dans le système de base et dans les ports (4.0, 4.1, 4.2), et qui a les droits en écriture/commit dans le vrai depot svn de gcc
            - Un certain nombre de développeurs ont cultivé des compétences liées, en ré-écrivant récemment le lint d'OpenBSD pour en faire un outil puissant et moderne (à la place de l'ancien lint, peu utilisable car floodeur de false positives)
            - Maintenance, depuis longtemps,d'une paire de versions de gcc très adaptées à leurs besoins
            - Et un paquet de spécialistes sur les « architectures minoritaires » (hppa, arm, mvme88k, ppc, sparc, ...).

            Ce n'est certainement pas assez pour développer seuls un nouveau compilateur C complet, mais tout de même bien utile pour collaborer, avec d'autres, sur un compilateur déjà existant et bien architecturé. Au final ça ne fera sûrement pas un compilateur aussi complet (nombres de langages supportés) ou optimisé que gcc, mais fera probablement un bel outil complémentaire de gcc, pratique pour ceux qui ont les mêmes besoins qu'eux. Pas de raisons de s'en plaindre : ça n'enlève rien à personne, et ça profitera à certains.

            Pour faire un peu d'informatique prédictive/fumeuse/astrologique ;), mon paris, c'est que ça donnera d'ici quelque temps un petit compilateur :

            - C only (car ils n'ont pas besoins de C++ ou autre dans le système de base (sauf pour grof, mais il sera sûrement remplacé...))
            - très rapide (car c'est un problème immédiat de gcc dont ils souffrent depuis longtemps, et qui leur coûte du temps)
            - ayant une relative compatibilité avec les extensions gcc (ils en utilisent, et en auront besoin pour les ports)
            - intégrant des fonctionnalités utiles pour la sécurité (puisqu'ils maintiennent déjà de nombreuses extensions de ce type dans leur fork "in house" de gcc)
            - supportant un nombre décent d'architectures (puisque c'est capital pour eux et pour NetBSD)
            - produisant du code peu optimisé (parce que ça demande beaucoup de travail et n'est pas une priorité immédiate pour eux, en tout cas moins importante que la rapidité de compilation)
    • [^] # Re: Re ; Fin de gcc dans les *BSD ?

      Posté par . Évalué à 2.

      > Rappellons par exemple qu'on a jamais reussi a booter un kernel VaX avec gcc3 ...

      Je vais faire une remarque naïve pour les z'élites d'OpenBSD, mais il me semble plus facile de corriger un bug de gcc que d'écrire un compilateur...
      Je me trompe ?

      Si à chaque bug/limitation de gcc il faut un compilateur, on n'est pas sorti de la merde...
      • [^] # Re: Re ; Fin de gcc dans les *BSD ?

        Posté par . Évalué à 8.

        je te renvoies à nouveau vers la réponse de Marc Espie sur undeadly, notamment la partie sur le dev de gcc :

        GCC is developed by people who have vastly different goals from us. If you go back and read the GCC lists, you'll notice several messages by me where I violently disagree with the direction it's following. Here is some *more* flame material.

        - GCC is mostly a commercial compiler, these days. Cygnus software has been bought by redhat. Most GCC development is done by commercial linux distributors, and also Apple. They mostly target *fast* i386 architectures and PowerPC. A lot of work has been done on specmarks, *but* the compiler is getting bigger and bigger, and slower and slower (very much so).

        - GCC warnings are not *really* useful. The -Wall flag shows many right things, and quite a few wrong issues.

        - There is a lot of churn in GCC which ends up with it no longer supporting some architectures that are still relevant to us.

        - The whole design of GCC is perverted so that someone cannot easily extract a front-end or back-end. This is broken by design, as the GPL people do believe this would make it easier for commercial entities to `steal' a front-end or back-end and attach it to a proprietary code-generator (or language). This is probably true. This also makes it impossible to write interesting tools, such as intermediate analyzers. This also makes it impossible to plug old legacy back-ends for old architectures into newer compilers.

        - As a result, you cannot have the new interesting stuff from newer GCC without also losing stuff... every GCC update is an engineering nightmare, because there is NO simple choice. You gain some capabilities, and you also lose some important stuff.

        - it's also very hard to do GCC development. Their branching system makes it very likely that some important work is falling between the cracks (and this happens all the time). If you develop code for GCC, you must do it on the most recent branch, which is kind of hard to do if your platform is currently broken (happens *all the time* if you're not running linux/i386). Even when you conform, it's hard to write code to the GNU coding standards, which are probably the most illegible coding guidelines for C. It's so obvious it was written by a lisp programmer. As a result, I've even lost interest into rewriting and getting in the GCC repository a few pieces.

        - some of their most recent advances do not have a chance to work on OpenBSD, like preparsed includes, which depend on mmap() at a fixed location.

        - there are quite a few places in GCC and G++ where you cannot have full functionality without having a glibc-equivalent around.

        - some of the optimisation choices are downright dangerous, and wrong for us (like optimizing memory fills away, even if they deal with crypto keys).

        - don't forget the total nightmare of autoconf/libtool/automake. Heck, even the GCC people have taken years to update their infrastructure to a recent autoconf. And GCC is *the only program in the ports tree* that actually uses its own libtool. Its configuration and reconfiguration fails abysmally when you try to use a system-wide libtool.

        I could actually go on for pages...

        I've actually been de facto maintainer of GCC on OpenBSD for a few years by now, and I will happily switch to another compiler, so frustrating has been the road with GCC.
        • [^] # Re: Re ; Fin de gcc dans les *BSD ?

          Posté par . Évalué à -7.

          Ben on va voir ce que va faire pcc.
          Vu comme ils prennent de haut gcc, ils ont intérêt à faire un truc qui arrache sa mère.

          Je te paris que pcc restera un petit truc. Même les Gentoo lovers qui sont accros à la compilation ne vont pas l'utiliser...
          J'en prend le pari.

          Et si pcc c'est seulement faire un compilateur qui n'est pas cross-plateform, qui est peu optimisé, qui supporte peu de cpu, qui ne fait C et pas C++, etc, et bien il est mal venu de cracher sur gcc. Surtout qu'openBSD va rester dépendant de gcc pour encore très longtemps.

          Mais ça c'est classique de openBSD boys. Ça ne manque pas une ocasion de cracher sur les outils GPL alors qu'ils les utilisent. Ce que j'utilise sous licence BSD, je ne crache pas dessus.
          • [^] # Re: Re ; Fin de gcc dans les *BSD ?

            Posté par . Évalué à 9.

            tu veux des recommandations pour un psy ? Parce que la dans le genre "je crache ma haine et ma frustration sur tout ce qui bouge", tu nous sors le grand jeu depuis un petit moment...

            Ce n'est pas parce qu'un projet est actuellement dépendant de gcc qu'il n'a pas le droit de critiquer certaines lacunes ou choix. Maintenant, si tu prends toute remarque négative comme une insulte envers ce projet, on ne peut plus rien dire dans ce cas la et rien n'avancera.
            • [^] # OpenBSD utilise gcc 3.3. Les nazes.

              Posté par . Évalué à -3.

              > Maintenant, si tu prends toute remarque négative comme une insulte envers ce projet,

              Dans le cas que tu donnes, oui.

              Tu peux faire une critique de gcc, il y a toujours des choses à améliorer.
              Mais dire que gcc est tellement pourrave qu'il faut passer à un "sous-compilateur", c'est une insulte.
              Et quel est l'argumentaire pour "descendre" gcc ?

              > GCC is developed by people who have vastly different goals from us.

              Un compilateur, c'est un compilateur. Ce n'est pas une machine à café. Donc le "vastly different goals from us", je ne le comprend pas.

              > Here is some *more* flame material.

              C'est un compliment pour toi ?

              > GCC is mostly a commercial compiler, these days.

              Et ? Il l'a acheté combien ?
              Il y a peu Theo se félicitait d'avoir des contributions de société et il trouvait ça bien. Mais si c'est GCC, "bing", ça devient mal.
              Marrant.
              Et pourquoi le "these days". Si ma mémoire ne me trahie pas, OpenBSD n'est même pas à la version 4 de gcc qui est sortie depuis des années. OpenBSD est à la version 3.3 (tout une époque...).

              > They mostly target *fast* i386 architectures and PowerPC.

              Et ?
              C'est là où il y a le plus d'utilisateur, c'est là où il y a le plus de contribution.
              Qu'il fasse pcc ou n'importe quoi, ça sera la même chose (pour peu que pcc soit vaguement populaire).
              En passant, OpenBSD utilisant gcc 3.3, il ne doivent rien remarquer de ces modifications.

              > *but* the compiler is getting bigger and bigger, and slower and slower (very much so).

              Comment il le sait, OpenBSD est à la version 3.3 de gcc...

              C'est con, mais gcc a gagné en rapidité ces derniers temps. Il en a perdu à l'introduction de SSA et maintenant il en gagne. De plus, ça ne veut rien dire. Un compilateur ce n'est pas un truc pour l'utilisateur final, ce n'est pas un jeux ou les fps compte, ça n'a pas des critères d'ergonomies, etc... Avant tout, il rend un service (compiler, générer du code machine). Le service est-il bon ? La majorité pense que oui.

              > GCC warnings are not *really* useful. The -Wall flag shows many right things, and quite a few wrong issues.

              Ben qu'il nous casse pas les couilles avec ça et qu'il désactive les warnings s'il veut coder comme porc. C'est ses oignons. NB : c'est l'option "-w" pour désactiver les warnings. C'est aussi configurable au niveau système.

              > - There is a lot of churn in GCC which ends up with it no longer supporting some architectures that are still relevant to us.

              Et ?
              C'est ses oignons. Si personne ne veut d'une architecture mais seulement lui, ben qu'il retrousse ses manches. Passer à pcc ne change rien à ce problème.
              pcc supporte des architectures "exotiques" ? Je ne crois pas.
              Pcc est-il cross-plateform ? C'est important pour tester les architecture exotique sans avoir des tonnes de matériel.

              > - The whole design of GCC is perverted

              Encore un compliment ou une affirmation gratuite ?

              > This is broken by design

              Encore un compliment ? Une critique argumenté ?

              > as the GPL people

              La conspiration des adorateurs de la GPL. Mais oui...

              > This also makes it impossible to write interesting tools, such as intermediate analyzers

              C'est carrément impossible !

              > This also makes it impossible to plug old legacy back-ends for old architectures into newer compilers.

              ?!?!
              Si tu veux un vieux compilateur, utilise un vieux compilateur ! C'est exactement ce que fait OpenBSD. Il utilise gcc 2.95 et 3.3. Des vieux compilateurs.
              Sûr que pcc n'aura jamais cette "feature" (utiliser des vieux backend avec un nouveau frontend). On en fait le pari ?

              > every GCC update is an engineering nightmare,

              Comment il sait ça?
              OpenBsd n'est même pas à la version 4 de gcc...

              > because there is NO simple choice. You gain some capabilities, and you also lose some important stuff.

              S'il le dit...
              En tout cas pour OpenBSD on n'en sait rien car OpenBSD a arrêté le temps depuis gcc 3.3.

              > Even when you conform, it's hard to write code to the GNU coding standards, which are probably the most illegible coding guidelines for C. It's so obvious it was written by a lisp programmer. As a result, I've even lost interest into rewriting and getting in the GCC repository a few pieces.

              La belle excuse....

              > - some of their most recent advances do not have a chance to work on OpenBSD, like preparsed includes,

              Ben il faut faire le portage. C'est un "peu" le boulot d'OpenBSD.

              > which depend on mmap() at a fixed location.

              Ben dans ce cas ça ne marche pas sous Linux non plus.
              Le "méchant" Red Hat (et pas seulement Red Hat) utilise des adresses alléatoires pour RHEL et Fedora.
              Bref, du gros pipo.

              > - there are quite a few places in GCC and G++ where you cannot have full functionality without having a glibc-equivalent around.

              C'est un problème de portage, c'est à OpenBSD de faire le boulot (du moins de ne pas se plaindre si ce n'est pas fait).

              > - some of the optimisation choices are downright dangerous

              Puisque tu le dis. Depuis quelques jours c'est un feux d'artifice d'exposion de bécane qui compile avec gcc.

              > and wrong for us (like optimizing memory fills away, even if they deal with crypto keys).

              C'est un problème de portage.

              > - don't forget the total nightmare of autoconf/libtool/automake.

              Toujours le même troll...
              Ben qu'OpenBSD fasse l'équivalent d'autoconf/libtool/automake et qui marche partout. Après on en recause.

              > And GCC is *the only program in the ports tree* that actually uses its own libtool. Its configuration and reconfiguration fails abysmally when you try to use a system-wide libtool.

              Enfin une bonne critique....
              Ce bug ne demande qu'à être corrigé.
              Mais je m'interroge. Ça ne serait pas un bug de gcc 3.3 qui a été corrigé depuis des lustres ? Mais OpenBSD ne serait pas au courrant car il reste sckotché à gcc 3.3.

              > I could actually go on for pages...

              Compliment ou critique constructive ?
              Et de quoi ?
              De gcc 3.3 ?

              > I will happily switch to another compiler, so frustrating has been the road with GCC.

              Bon débarras. Qu'OpenBSD n'utilise plus GCC.

              > I've actually been de facto maintainer of GCC on OpenBSD for a few years by now

              Ça n'a pas été trop dure puisque que gcc est en version 3.3 dans OpenBSD.
              Il y a peut-être encore gcc 2.95 dans la dernière OpenBSD que ça ne m'étonnerait pas.




              Si tu veux des critiques constructives sur gcc, t'en trouvera ici par exemple :
              http://www.gccsummit.org/2007/
              • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                Posté par . Évalué à 3.

                olalala que c'est beau et facile de faire des remarques sur des sections de 5 mots qui ne sont même pas des phrases entières...ça évite de réfléchir.

                Tu ne t'es pas posé la question du pourquoi justement gcc est en 3.3 dans openbsd ?

                Je te laisse te masturber sur la superiorité de redhat qui se bat sans relâche contre le monde entier qui ne désire que sa perte.
                • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                  Posté par . Évalué à 0.

                  > Tu ne t'es pas posé la question du pourquoi justement gcc est en 3.3 dans openbsd ?

                  Peut-être car openbsd n'a quasiment rien fait depuis au moins 3 ans dans gcc ?
                  Ce n'est pas peut-être, c'est sûrement.

                  > Je te laisse te masturber sur la superiorité de redhat qui se bat sans relâche contre le monde entier qui ne désire que sa perte.

                  Quand as-tu lu ou entendu que j'avais peur pour l'avenir de Red Hat ?
                  Jamais.

                  Toi tu retournes te masturber sur ce que j'aurais dit sur Red Hat et sur les trolls d'OpenBSD sur gcc.
                • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                  Posté par . Évalué à -3.

                  ohlala que c'est beau de faire des attaques ad homniem quand quelqu'un ose faire une contre argumentation qui tient la route et que tu n'offre strictement aucun argument.
                  • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                    Posté par . Évalué à 6.

                    je n'ai pas vu une argumentation qui tient la route, juste un passage à la machette du post précédent suivi d'accusations ou remarques évasives. Sa seule argumentation c'est "openbsd n'utilise que gcc3.3" sans qu'il ne se pose la question du pourquoi et du comment. Le-dit pourquoi étant très bien expliqué dans la citation de espie@.
                    • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                      Posté par . Évalué à -3.

                      si tu ne veux pas lire, je ne peux pas te forcer.

                      Le-dit pourquoi étant très bien expliqué dans la citation de espie@.
                      Marrant que tu estime que c'est très bien expliqué alors que quelqu'un estime le contraire.
                      Quand il t'en fait la remarque , avec un poste reprenant POINT PAR POINT les remarques, tout ce que tu trouve a dire c'est 'mais non cette citation est super top génial. C'est toi qui a pas d'argumentation. Je démontre pas en quoi elle est cool malgré le fait que tu l'a repris point par point. Elle est bien et c'est toi qui fait des remarques évasives et ne se pose aucune question comme pourquoi ni comment.'

                      De mon point de vue ca fait pas très sérieux ce genre de comportement (je ne tomberais pas dans la bassesse des attaques ad hominem, que certains dans ce threads affectionne).
              • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                Posté par (page perso) . Évalué à 7.

                Arrête de raconter n'importe quoi :
                OpenBSD dispose toutes les versions *récente* de GCC au travers des ports : http://ports.openbsd.nu/lang/gcc jette un oeil et tu verras, il y a même des ports pour les version 4.X et même celle en dev (4.3), donc tu as bien des mecs qui se prennent la tête a intégrer gcc dans OpenBSD y compris dans les versions récentes. En plus c'est la même personne qui les maintient, mais comme tu le dis, le mec ne doit pas savoir il en son resté à la version 3.3...

                De plus si OpenBSD en est resté à la version 3.3 pour la compilation des sources officielles, et 2.95 pour certaines archi, c'est peut être bien parce que gcc n'est peut être pas si facile que ça a intégrés : comme dit dans ce que tu quotes : certaines architectures non supportés, du GNUisme, des buts différents de ceux des devs d'OpenBSD. Bah dans ces cas là tu changes dès que tu le peux pour un produit qui leur correspond mieux.
                Ensuite pour les postes de baves sur GCC, si tu lis les premiers posts (je ne parles de trollfr, mais bel et bien des annonces officielles) qui parlent de l'import de pcc dans gcc ça ne bave pas sur GCC, mais ça dit juste que PCC pourrait mieux correspondre à leur besoin, par la suite ça bave car rien que le fait de penser proposer un compilateur alternatif pour leurs sources en C, entrainent une levé de bouclier de gens comme toi, et comme des gens prêt à troller et à baver il y en a *plein* dans tous les camps, (Théo est très souvent en première ligne pour ça, mais Linus n'est jamais bien loin non plus.) ça crache dans tous les sens.

                Toi par exemple dès ton premier post du bave sérieusement sur les BSD : http://linuxfr.org/~inico/25304.html#867189
                • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                  Posté par . Évalué à 2.

                  > par la suite ça bave car rien que le fait de penser proposer un compilateur alternatif pour leurs sources en C, entrainent une levé de bouclier de gens comme toi

                  J'en ai rien à foutre qu'OpenBSD utilise autre chose que gcc. Vu comme OpenBSD est prêt systématiquement à gerber sur Linux et la GPL, j'en serai heureux même. Il donne systématique des leçons, critiques les outils GNU, etc...
                  Très bien, qu'ils ne les utilisent pas. S'ils ne les utilisent pas et font du troll/fud, ça m'énerverait beaucoup moins.

                  Ce qui m'insupporte c'est de voir des gens qui profitent de gcc et vomissent sur gcc.
                  De combien à contribué OpenBSD à gcc ?
                  0,01 % ou 0, 02 % ?
                  Pourtant OpenBSD utilise 100 % de gcc.

                  On va dire encore qu'il n'ont pas les moyens de développer un compilateur. Très bien encore. Avec gcc, ils ont quelques qu'il n'ont pas les moyens de développer. Ça fait encore une raison de moins de critiquer gratuitement gcc.

                  > du GNUisme

                  C'est une seconde nature...
                  Vois ta contradiction :
                  - "car rien que le fait de penser proposer un compilateur alternatif pour leurs sources en C, entrainent une levé de bouclier de gens comme toi,"

                  Si je suis "GNUiste" alors je ne ferai pas une levée de bouclier.

                  Alors, je suis "GNUiste" ou non ?

                  C'est de la critique gratuite/facile tout ça. Si gcc est comme ci alors c'est mal et s'il est comme ça alors ... c'est mal aussi. Tout ce qui n'est pas gcc est bien. Dans ce cas, il faut assumer et ne pas utiliser gcc.
                  J'utilise openssh, je ne vomis pas sur openssh. Pourtant il y a une alternative GPL.
                  • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                    Posté par . Évalué à 4.

                    J'en ai rien à foutre qu'OpenBSD utilise autre chose que gcc


                    euh...qu'est-ce que tu fais dans ce journal alors ?

                    Vu comme OpenBSD est prêt systématiquement à gerber sur Linux et la GPL, j'en serai heureux même. Il donne systématique des leçons, critiques les outils GNU, etc...


                    C'est qui OpenBSD ? personne. Si tu parle de Théo de Raadt, ben il ne s'est même pas exprimé publiquement au sujet de pcc. La seule chose que Theo et Miod ont fait, c'est accepter l'inclusion de pcc dans le cvs de openbsd pour pouvoir bosser dessus.

                    Maintenant faut pas mélanger les propos personnels d'un leader de projet, les choix techniques de plusieurs autres et les avis de ses utilisateurs...

                    Du reste personne n'a vomi sur gcc. Le titre de undeadly, c'est "BSD Licensed PCC Compiler Imported" et le log de l'ajout dans le cvs est "Import ragge's version of PCC into our tree, so we can hack on it more easy. ok deraadt@ miod@" et pour netbsd c'est "Initial import of ragge's version of pcc, version 0.9.8. This is the latest version of the portable C compiler" suivi d'une description et un historique de pcc. Rien dans tout cela n'attaque le projet gcc.
                    • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                      Posté par . Évalué à -1.

                      euh...qu'est-ce que tu fais dans ce journal alors ?
                      Ben si tu apprenais a lire plutot qu'a attaquer, tu remarquera qu'il dit ce qu'il pense : a savoir 'que critiquer un outil quand on l'utilise, surtout avec des critiques fausses et non argumenté m'insupporte'.
                      Et je tend a etre plutot de son avis.

                      Mais comme on est des GPLeux on pas le droit de parler , c'est ca?

                      Si tu parle de Théo de Raadt, ben il ne s'est même pas exprimé publiquement au sujet de pcc.
                      Et tu quote un truc qui ne parle pas de pcc, ca tombe bien.

                      Du reste personne n'a vomi sur gcc
                      Non dire que c'est 'defective by design' ou alors que le "design is perverted", c'est des compliments hein
                      • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                        Posté par . Évalué à 3.

                        Ben si tu apprenais a lire plutot qu'a attaquer, tu remarquera qu'il dit ce qu'il pense : a savoir 'que critiquer un outil quand on l'utilise, surtout avec des critiques fausses et non argumenté m'insupporte'.
                        Et je tend a etre plutot de son avis.


                        Raisonnement tordu. C'est quand on utilise un outil qu'on est capable d'y formuler les critiques les plus pertinentes.

                        'fin sauf si tu considère que quelqu'un a plus de légitimité à critiquer le Guitarangi da Gamba s'il ne sais pas jouer de la musique...

                        Si tu parle de Théo de Raadt, ben il ne s'est même pas exprimé publiquement au sujet de pcc.
                        Et tu quote un truc qui ne parle pas de pcc, ca tombe bien.


                        note qu'il y'a un "si" dans ma phrase, parce que l'idiot n'est pas capable de se rendre compte qu'OpenBSD n'est pas un être humain mais un OS. Et je contredis un post lançant des accusations vagues et sans sources, c'est donc difficile d'être plus précis...

                        Du reste personne n'a vomi sur gcc
                        Non dire que c'est 'defective by design' ou alors que le "design is perverted", c'est des compliments hein


                        euh...as tu une idée de la notion de contraste et de nuance. Entre ne pas être d'accord avec un choix de design (comme l'est Marc Espie) et "vomir" dessus, il y'a une nuance. Si espie@ "vomissait" sur gcc, il ne se serait jamais cassé le cul à y contribuer...
                        • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                          Posté par . Évalué à 1.

                          Raisonnement tordu. C'est quand on utilise un outil qu'on est capable d'y formuler les critiques les plus pertinentes.
                          Ca confirme donc ce que je disais :
                          (passage en gras ce sur quoi tu confirme mes dires)

                          Ben si tu apprenais a lire plutot qu'a attaquer, tu remarquera qu'il dit ce qu'il pense : a savoir 'que critiquer un outil quand on l'utilise, surtout avec des critiques fausses et non argumenté m'insupporte'.


                          Entre ne pas être d'accord avec un choix de design (comme l'est Marc Espie) et "vomir" dessus, il y'a une nuance. Si espie@ "vomissait" sur gcc, il ne se serait jamais cassé le cul à y contribuer...
                          Ca dépend quel nuance tu accorde à 'vomir'.
                          Dire 'c'est pourri jusqu'a la moelle' (traduction de defective by design : on pourra jamais en faire qqch de bien sans tout recasser), ben désolé pour moi c'est pas une 'petite critique sans importance'.

                          Enfin des fois tu contribue a un truc 'tres moche' pour le rendre 'un peu moins moche'.

                          Maintenant si tu fait/vend/... un logiciel et que quelqu'un en dis qu'il est pourri jusqu'a la moelle. Tu considérera qu'il en fait une critique argumenté, tout juste ce qu'il faut pour faire avancer dans le bon sens, ou plutot qu'il vomi sur ce soft ?
                          Moi j'ai tendance a penser la seconde version, et je pense que je ne suis pas le seul.
                          • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                            Posté par . Évalué à 4.

                            Raisonnement tordu. C'est quand on utilise un outil qu'on est capable d'y formuler les critiques les plus pertinentes.
                            Ca confirme donc ce que je disais :
                            (passage en gras ce sur quoi tu confirme mes dires)

                            Ben si tu apprenais a lire plutot qu'a attaquer, tu remarquera qu'il dit ce qu'il pense : a savoir 'que critiquer un outil quand on l'utilise, surtout avec des critiques fausses et non argumenté m'insupporte'.


                            ça ne confirme rien, c'est hors sujet...

                            Dire 'c'est pourri jusqu'a la moelle' (traduction de defective by design : on pourra jamais en faire qqch de bien sans tout recasser), ben désolé pour moi c'est pas une 'petite critique sans importance'.


                            Sauf que citer "defective by design" comme fait plus haut sans lui ajouté l'explication qui suit, c'est juste passer un post à la machette pour lui faire dire ce qu'on veut.

                            D'ailleurs pourri jusqu'à la moelle n'est pas du tout une bonne traduction de defective by design. pourri implique une décomposition, dégradation. defective by design au contraire implique que le choix du design est mauvais à la base. Bref comme tu sais très bien pervertir les phrases des autres pour y donner le sens que tu veux, c'est pas vraiment la peine que je continue la discussion.
                            • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                              Posté par . Évalué à 2.

                              ça ne confirme rien, c'est hors sujet...
                              Quel argumentation.
                              Plutot qu'argumenté ce en quoi les arguments en question sont ou non pertinent.
                              Plutot que d'explicité où tu montre justement qu'ils sont pertinent, tout ce que tu dis c'est
                              'Non , j'ai décidé que c'était HS' , alors que je reprend juste deux de nos réponses. Donc soit c'était HS avant, et dans ce cas tu aurais du le dire, soit c'est pas HS et dans ce cas ce n'est TOUJOURS pas HS.

                              Ah j'oubliais (vu les notes), sur ce thread faut pas oser contredire un bsdiens, apres tout je suis qu'un gpleux, n'est ce pas ?


                              Sauf que citer "defective by design" comme fait plus haut sans lui ajouté l'explication qui suit, c'est juste passer un post à la machette pour lui faire dire ce qu'on veut.
                              Et pourquoi tu n'as pas citer cet argument plutot que dire 'muwahhh vous dites que des conneries, d'abord c'est meme pas vrai' ?


                              D'ailleurs pourri jusqu'à la moelle n'est pas du tout une bonne traduction de defective by design. pourri implique une décomposition, dégradation. defective by design au contraire implique que le choix du design est mauvais à la base.

                              Je t'embaucherais pas comme traducteur.
                              Quand on dis que quelqu'un est pourri jusqu'a la moelle, ca veut dire quoi ? Qu'il se dégrade de l'intérieur ?
                              Avant de partir sur du littéral, il faut d'abord voir le sens de l'expression (qui n'est PAS se dégrader de l'intérieur, mais bien qu'on ne peux rien en tirer, bon à jeter.)

                              Puis comme cette expression est une 'mauvaise traduction', quel expression nous proposes tu alors ?

                              Bref comme tu sais très bien pervertir les phrases des autres pour y donner le sens que tu veux, c'est pas vraiment la peine que je continue la discussion.
                              Perverir les phrases ? Ou ca ?
                              Oser une traduction, qui peut etre polémique mais que je peux argumenter ?
                              Oser argumenter mes posts ? (je crois que la longueur de nos posts respectifs le montre un peu, qui même si elle n'est pas en corrélation directe avec l'argumentation, elle y contribue : un post de trois ligne sera rarement bien argumenté)
                              C'est ca pervertir les phrases des autres.
                              Ps tu m'a fait une reflexion sur 'tu sais pas traduire'. Je te conseillerais donc de te renseigner sur le sens du verbe 'pervertir'.
                  • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                    Posté par . Évalué à 10.

                    J'ai un peu de temps, je vais donc enfoncer quelques portes ouvertes.

                    ***

                    Tout d'abord, rappelons que gcc a été l'un des premiers compilateurs C sous licence libre. Et quand je dis "l'un des premiers", soyons sérieux un instant, il n'existait que _deux_ compilateurs libres : pcc, qui était quasiment abandonné sans que personne ne reprenne le navire, et gcc.

                    Les autres compilateurs étaient non libres (comme lcc) ou n'ont pas réussi à se faire connaître aussi bien que gcc (souvent parce que leur cible n'étaient pas les systèmes de type Unix).

                    Gcc 1 a donc eu un boulevard pour se développer, et a tout naturellement capté les meilleures compétences. Le vide s'est fait petit à petit, avec les compilateurs propriétaires (mipspro, Sunpro, XLC, etc) d'un côté et gcc de l'autre.

                    À cette époque, on est encore à la fin des années 1980, les systèmes libres ne pèsent rien du tout.

                    Un certain Michael Tiemann adapte gcc pour le support du C++ lors de sa thèse à l'INRIA, ce qui provoque l'éclatement de gcc 1 en une conception plus modulaire permettant de gérer plusieurs languages : gcc 2 est né. Tiemann fonde Cygnus dans la foulée.

                    Vous suivez toujours ? Gcc 2 sort au début de l'année 1992. À cette époque, on commence seulement à avoir des compilateurs C++ solides, qui ne sont plus des compilateurs C avec une surcouche comme l'était CFront, et qui peuvent enfin gérer les constructions les plus complexes que permet le language.

                    Afin d'aider à asseoir la notoriété et l'utilisation de gcc (et surtout de g++), Richard Stallman impose que les deux parties de gcc (celle qui traduit un des langages supportés en la représentation interne RTL, et celle qui traduit le RTL en du code assembleur) ne puissent pas être disjointes, de façon à ce qu'un vendeur de compilateur propriétaire ne puisse pas utiliser par exemple l'analyseur syntaxique C++ de gcc 2, et mettre son propre générateur de code assembleur derrière.

                    C'est un choix qui va à l'encontre de la philosophie Unix (qui favoriserait ``gcc-highlevel monfichier.c | gcc-lowlevel | as -o monfichier'' avec un gcc en deux composants distincts), mais qui est compréhensible dans l'optique "pénaliser le code propriétaire à tout prix" du projet GNU.

                    Par contre, d'un point de vue d'ingénieur, c'est une décision regrettable, ne serait-ce que pour déboguer : tu peux demander à gcc de te "cracher" 30 fichiers de représentation intermédiaire correspondant à 30 étapes d'optimisation, mais tu n'as aucun moyen, lorsque tu crois avoir détecté une erreur à la passe N, de modifier manuellement ce fichier et de le réinjecter à la passe N+1, afin de vérifier ton hypothèse dans le code final.

                    C'est sur ce point que râle perpétuellement Marc Espie (la partie "perverted design").

                    ***

                    Un autre reproche, peut-être plus spécifique à OpenBSD, est le choix des plate-formes supportées par gcc. Gcc évolue de plus en plus vite, c'est bien (et ça change du cycle de release entre 2.5.8 et 2.8...), mais du coup il est difficile de suivre quand tu as d'autres choses à faire à côté. Les développeurs de gcc ne testent pas tous toutes les plate-formes pour lesquelles gcc est capable de produire du code (que ce soit en natif ou en compilation croisée), et le résultat est que sur les N plate-formes supportées par gcc, seule une bonne moitié est vraiment fiable, les autres souffrant de bugs par ci par là, qui peuvent très bien être indétectés avant belle lurette, ou produire des erreurs subtiles dans le comportement d'un programme difficile à analyser.

                    Il y a plusieurs plate-formes où, par manque d'intérêt ou de gens payés pour, le "backend" de gcc est fiable en version N, mais plus en version N+1, soit à cause de bugs bêtes, soit parce que les optimisations plus fines de cette nouvelle version de gcc cassent certaines choses "considérées comme acquises" (comment traduire ``assumptions'' ?) par le code du backend. Pire encore, le backend peut être mal écrit initialement et mal décrire la réalité du processeur.

                    Dans ce cas, il y a un travail important à accomplir, et de nos jours, à la vitesse où sont introduits dans gcc des changements (nouvelle représentation intermédiaire, nouvelles optimisations, nouveau modèle de gestion du parallélisme) nécessitant des modifications substancielles du backend, il n'est pas possible de suivre si l'on ne dispose pas de beaucoup de temps à consacrer à gcc.

                    On le voit très bien dans les changelog de gcc ou les backend sont de facto en deux classes : ceux qui sont maintenus, souvent par des personnes payées à plein temps pour le faire par IBM, Apple, Sony ou autres, et ceux pour lesquels les seuls changement visibles sont des changement systématiques (remplacement de VIEIILLE_MACRO() par NOUVELLE_MACRO(), correction de fautes d'orthographe dans les commentaires, extension du copyright à la nouvelle année tous les ans) dont il a simplement été vérifié de temps en temps qu'ils compilent, et aucune autre activité.

                    C'est une source de mécontentement croissante, parce que justement cela montre que gcc (et plus particulièrement gcc 4) peut de moins en moins être présenté comme supportant autant de plate-formes que par le passé.

                    ***

                    Le troisième reproche fait à gcc est la lenteur croissante des temps de compilation.

                    Autant les migrations successives de 2.1 à 2.95 ont conservé des temps de compilation proches, autant chaque version intermédiaire de gcc 3 a impacté les temps de compilation de façon significative (30 à 70% selon les plate-formes, pour un passage de 2.95 à 3.3, les plate-formes le plus affectées étant celles disposant de beaucoup de registres : alpha, hppa, mips, sparc).

                    Heureusement, 4.1 puis 4.2 commencent à bien digérer le passage à la représentation ssa, et regagnent du temps sur 3.4 (on constate généralement des temps intermédiaires entre ceux de 3.3 et ceux de 3.4, lorsque l'on compile avec 4.2).

                    Mais, comme je le disais un peu plus haut, il arrive que le support d'une architecture donnée soit absent ou non fiable en 4.x. Voire en 3.x. Donc, faute de moyens (essentiellement en temps), on en reste à gcc 2.95.

                    Le fait que les développeurs de gcc ne soient pas intéressés pour aider à migrer un backend 2.95 au niveau 3.4 ou 4.x, n'aide pas non plus à la motivation.

                    ***

                    On en vient alors à "mais s'ils sont aussi mécontents de gcc, qu'ils utilisent donc autre chose !".

                    Oui, on aimerait bien. D'ailleurs on y pense depuis longtemps, et plusieurs développeurs OpenBSD s'étaient intéressés à TenDRA il y a moult années déjà.

                    Mais comme je l'ai rappelé plus haut, gcc a fait le vide autour de lui. TenDRA, par exemple, n'était plus maintenu depuis la fin des années 1990, et le groupe qui s'est monté pour le reprendre a surtout réussi à se tirer dans les pattes et à se scinder en deux groupes encore moins actifs.

                    Ce qui fait la différence dans pcc, c'est qu'il est plus facile de "rentrer" dans le code que dans celui de TenDRA, et que les projets BSD ont de très bonnes relations avec Ragge (Anders Magnusson) à l'origine du renouveau de pcc.

                    La situation est donc différente : ce n'est plus reprendre un projet dont l'équipe a mis la clef sous la porte, mais c'est s'injecter dans un projet bouillonnant, et qui n'intéresse d'ailleurs pas qu'OpenBSD : sur la liste de développement de pcc, on trouve aussi des gens de DragonflyBSD et NetBSD.

                    ***

                    Je terminerai en rappelant qu'il est évident qu'il reste beaucoup de travail à accomplir. Pcc n'est pas près de remplacer gcc dans OpenBSD, mais on va essayer de le faire mûrir pendant quelques mois, afin de voir quel effort est réellement nécessaire pour obtenir une alternative viable à gcc.

                    Ceux qui s'imaginent que c'est pour demain sont de doux rêveurs... tout comme ceux qui s'imaginent que c'est une tâche impossible.
                    • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                      Posté par . Évalué à 1.

                      > l'optique "pénaliser le code propriétaire à tout prix" du projet GNU.

                      Ce n'est pas pénaliser, c'est ne pas voir son code "perverti" en un truc proprio.
                      Si gcc pouvait avoir des greffon proprio, il y a des risques.
                      Linux a aussi le même problème (avec les modules).

                      GCC peut produire des binaires proprio car ça ne change pas le caractère libre de gcc. Comme Linux peut exécuter des logiciels proprio car ça ne change rien au caractère libre de Linux. Bien que gcc peut produire du code proprio, gcc reste totalement libre. gcc n'est pas un moyen pour empêche le développement de proprio (ou des trucs sous BSD).

                      > C'est une source de mécontentement croissante, parce que justement cela montre que gcc (et plus particulièrement gcc 4) peut de moins en moins être présenté comme supportant autant de plate-formes que par le passé.

                      Et ce qui arrivera, c'est mon avis, c'est que gcc ne supporte officiellement qu'un petit nombre d'architecture. Pour les architectures particulières, ça sera des forks.

                      Le problème de nombre d'architecture supporté se retrouves partout et n'a rien de spécifique à gcc. Linux (le noyau) a le même problème. Bien des choses ne marchent pas quand tu sors des architectures "classiques".

                      Mais que faire ? Demander aux développeurs de bosser spécifiquement pour 1 % des utilisateurs au détriment de 99 % des utilisateurs ?
                      Je suis contre.
                      Demander aux développeurs de bosser spécifiquement pour 1 % des utilisateurs au détriment de 99 % des utilisateurs ?
                      C'est du logiciel libre, ils bossent sur ce qu'ils veulent. S'ils ne veulent pas bosser sur l'architecture bidule, il faut faire avec.

                      > Mais comme je l'ai rappelé plus haut, gcc a fait le vide autour de lui.

                      Gcc n'est pas un aspirateur. Il y avait déjà le vide.
                      • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                        Posté par (page perso) . Évalué à 6.

                        > Ce n'est pas pénaliser, c'est ne pas voir son code "perverti" en un truc proprio. Si gcc pouvait avoir des greffon proprio, il y a des risques.

                        Des risques de ? Qu'une société écrive un backend propriétaire ? Et donc ? Cela réduirait la liberté de qui ? Personne ne t'interdirait d'écrire un backend libre, personne même ne t'oblige à utiliser ce backend proprio. Tout comme perso t'oblige à utiliser un module propriétaire sous Linux. La liberté est avant tout un choix ...

                        > C'est du logiciel libre, ils bossent sur ce qu'ils veulent. S'ils ne veulent pas bosser sur l'architecture bidule, il faut faire avec.

                        gcc est un logiciel libre certes, mais reveille toi. La majorité des contributeurs de gcc et de linux sont des grosses boîtes qui voient leurs intérets avant tout.

                        Respecte alors le choix de ceux qui critiquent gcc (en connaissant bien mieux gcc que toi à priori) et qui veulent une alternative plus en adequation avec leurs attentes.

                        Au passage, merci Miod pour ce petit historique.
                        • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                          Posté par . Évalué à 1.

                          Cela réduirait la liberté de qui ?
                          Meme question avec des firmwares proprio dans le noyau.

                          Le plus drole c'est que quand la bsd est utilisé par des entreprises, meme pas pour faire du proprio, une partie de ses défenseurs (comme théo par exemple) vient raler parce qu'il ne recoit pas de thune.

                          Ne pas voir son code repris dans un logiciel proprio est une volontée que je comprend très bien.


                          gcc est un logiciel libre certes, mais reveille toi. La majorité des contributeurs de gcc et de linux sont des grosses boîtes qui voient leurs intérets avant tout.
                          Et ?
                          C'est quoi ton point la ?
                          Que des boites contribuent au libre ?
                          Cool.
                          Que parce que c'est des boites faut refuser leurs patchs ?
                          Voit pas pourquoi.
                          Qu'un contributeur contribue suivant ce qui l'intéresse et pas ce qu'intéresse tartenpion ?
                          Franchement impressionnant la !

                          Bref le coup du 'réveille toi' me laisse perplexe.


                          Respecte alors le choix de ceux qui critiquent gcc (en connaissant bien mieux gcc que toi à priori)
                          En l'exprimant bien moins bien alors (ie commentaire d'espi).

                          Par contre tu vois le commentaire de miod a été plutot assez clair.

                          et a bien expliqué les différents points (enfin ce n'est que mon point de vue).
                          Est ce pour autant qu'on est forcé d'être d'accord avec les arguments engagé ? non.

                          IsNotGood a une position différente de la GPL de miod.
                          C'est donc qu'il a forcément tort ?

                          Ou sont donc les arguments ou contre argument ?
                          Miod en a, isnotgood en a.
                          Je vois donc pas de mal a ce qu'ils en discutent.
                        • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                          Posté par . Évalué à 6.

                          Des risques de ? Qu'une société écrive un backend propriétaire ? Et donc ? Cela réduirait la liberté de qui ? Personne ne t'interdirait d'écrire un backend libre, personne même ne t'oblige à utiliser ce backend proprio. Tout comme perso t'oblige à utiliser un module propriétaire sous Linux. La liberté est avant tout un choix ...

                          Le pragmatisme de GCC a fait ses preuves. Apple ne serait pas en train de maintenir la partie Objective C de gcc à l'heure actuelle si GCC était sous une licence BSD-like. NeXT a essayé il y a bien longtemps de créer leur compilateur Objective C par dessus gcc tout en le faisant propriétaire. La FSF est allé leur dire deux mots et ils ont été obligé de libérer le code.

                          La GPL est bien plus pragmatique qu'idéologique, dans le monde réel. Elle a permis à des softs comme GCC de recevoir des contributions de la part de personnes qui n'avaient pas envie d'en donner, mais qui ont préféré utiliser un logiciel GPL comme GCC plutôt que de devoir recréer tout un compilateur from scratch, le cas de NeXT.

                          La BSD contrairement aux idées reçues n'est pas la licence idéale pour les entreprises qui font du proprio, si l'entreprise en question mets beaucoup d'argent derrière le logiciel en bsd. Faut voir Trolltech et MySQL par exemple, qui font du business à base de double licence GPL/proprio. Ca ferait pas bander Trolltech si tout le monde pouvait propriétariser QT. La GPL leur permets de faire du libre tout en ayant un business model avec les marchands propriétaires. La BSD est anti-business. Pour une entreprise qui produit du software, mettre un logiciel sous double licence est bien plus rentable que se de faire piller son code par tout le monde, puis ça va revenir cher la facture en vaseline..
                          • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                            Posté par (page perso) . Évalué à 3.

                            > Le pragmatisme de GCC a fait ses preuves. Apple ne serait pas en train de maintenir la partie Objective C de gcc à l'heure actuelle si GCC était sous une licence BSD-like

                            Cela reste bien evidemment à prouver. On peut se souvenir de khtml et apple. Certes, le code était sous GPL m'enfin on sait ce que ca a longtemps donné ... Il faut aussi voir que le seul utilisateur de Obj C c'est apple et sa communauté. Et même sous une licence BSD-like, je vois pas la plus value qu'ils auraient à garder le code propriétaire.

                            La question de plus n'est pas là (GPL vs BSD) pour gcc. Le problème vient du design qui a été bousillé pour éviter qu'un module propriétaire ne s'immisse dans la châine de compilation. Ce n'est pas une décision pragmatique, du point de vue ingéniérie....

                            Quand on commence à me parler de rentabilité financière sur linuxfr, je me dis que le monde va bien mal :) Moi qui était persuadé que le logiciel libre, c'était d'abord une question d'éthique et de partage. Je suis vraiment un gros con ... :D
                            • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                              Posté par . Évalué à 5.

                              Et même sous une licence BSD-like, je vois pas la plus value qu'ils auraient à garder le code propriétaire.

                              On s'en fout que tu ne vois pas la plus value, moi non plus comme toi je ne vois pas la plus value mais on s'en fout de nos pensées parce que là on parle de *faits*. Les faits sont là : NeXT a essayé de faire du proprio avec l'Objective C, la FSF leur a donné un coup de bâton, fin de l'histoire. Je parle d'Apple parce qu'objectivement c'est le NeXT d'aujourd'hui, son Steve Jobs, son objective C, ses APIs cocoa et les mêmes ingénieurs de l'époque..

                              Consider GNU Objective C. NeXT initially wanted to make this front end proprietary; they proposed to release it as .o files, and let users link them with the rest of GCC, thinking this might be a way around the GPL's requirements. But our lawyer said that this would not evade the requirements, that it was not allowed. And so they made the Objective C front end free software.

                              C'est un évènement qui s'est déjà produit et dont la finalité est celle qu'elle est parce que la licence de GCC les a forcé à libérer le code.
                              Et non Apple n'est pas le seul utilisateur d'objective C, même s'ils sont la seule plateforme où on fait du fric avec, dans le monde du libre tu as GNUStep et le projet de bureau Etoilé qui font usage de ce langage.

                              Quant à KHTML, Apple avait déjà eu une expérience avec le libre et ils ont compris qu'ils étaient obligés de suivre les licences des logiciels qu'ils emploient, c'est pour ça que le code de KHTML modifié par Apple a été libéré. C'est du LGPL, donc ils ont libéré que ce qu'ils étaient obligés de libérer, ainsi qu'une portion de leur API de haut niveau (webkit) mais ils n'ont pas libéré Safari évidemment.
              • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                Posté par . Évalué à 8.

                > Ben qu'il nous casse pas les couilles avec ça et qu'il désactive les
                > warnings s'il veut coder comme porc.

                Visiblement, tu te méprend sur le sens de sa remarque.
                À titre indicatif, le noyau d'OpenBSD est compilé, en boucle, sur toutes les archs, avec par défaut (en dur dans les Makefile) :
                cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wstack-larger-than-2047

                Et leur version de gcc dipose d'un certain nombre de warnings suppélementaires, en rapport avec leurs priorités (dont le -Wstack-larger-than-x plus haut, et -Wbounded (pour faire des verifs contre les débordements), -Wformat (pour faire des verifs contre les possibilites de format string vulnerabilities).

                Bref on ne peut vraiment pas dire qu'ils soient contre l'idée générale des Warnings du compilo, mais plutôt qu'ils voudraient plus de warnings sur les choses ayant un impact sur la sécurité, et un meilleur rapport signal/bruit.

                >> every GCC update is an engineering nightmare,
                > Comment il sait ça?
                > OpenBsd n'est même pas à la version 4 de gcc...

                Mar Espie est un développeur de gcc depuis longtemps (il a accès en écriture au depot svn de gcc et a pas mal contribué...). Ce qui lui donne à la fois plus de crédibilité et de légitimité que toi, trolleur de linuxfr (as-tu contribué au projet gcc ?). Je pense qu'il sait mieux que toi ce qu'apporte (ou pas) la version 4 de gcc...

                Et cela lui donne, peut-être aussi, le droit d'indiquer ses souhaits et deceptions au sujet de certaines orientations *politiques* du projet (par exemple à l'époque où il avait soutenu la proposition d'intégrer propolice dans gcc).

                Accessoirement, son reproche central, le fait que, pour des raisons purement politiques (et en conflit avec l'interet technique) le frontend et le backend soient mélangés est un reproche fortement partagé par Linus Torvalds, et a motivé l'écriture et le choix de la licence de sparse.
                FAQ de sparse, par Linus Torvalds :


                Q. Why not just use gcc?

                A. Gcc is big, complex, and the gcc maintainers are not interested in
                other uses of the gcc front-end. In fact, gcc has explicitly
                resisted splitting up the front and back ends and having some common
                intermediate language because or religious license issues - you can
                have multiple front ends and back ends, but they all have to be part
                of gcc and licensed under the GPL.

                This all (in my opinion) makes gcc development harder than it should
                be, and makes the end result very ungainly. With "sparse", the
                front-end is very explicitly separated into its own independent
                project, and is totally independent from the users. I don't want to
                know what you do in the back-end, because I don't think I _should_
                know or care.

                Q. Why not GPL?

                A. See the previous question: I personally think that the front end
                must be a totally separate project from the back end: any other
                approach just leads to insanity. However, at the same time clearly
                we cannot write intermediate files etc crud (since then the back end
                would have to re-parse the whole thing and would have to have its
                own front end and just do a lot of things that do not make any sense
                from a technical standpoint).

                I like the GPL, but as rms says, "Linus is just an engineer". I
                refuse to use a license if that license causes bad engineering
                decisions.


                Sparse étant, disons, un demi-compilateur, tu vois qu'il y a d'autres gens très respectable qui font la même chose que les devs OpenBSD, à savoir maintenir un outil, en parallèle à gcc, pour pallier aux mêmes limitations artificielles (car politiques) de gcc.
              • [^] # Re: OpenBSD utilise gcc 3.3. Les nazes.

                Posté par (page perso) . Évalué à 2.

                Il y'a un truc de sur. C'est une horreur de changer de version de gcc (en particulier de 3 vers 4). L'intégration dans le système de base est difficile, de nouvelles dépendances arrivent, souvent sous GPL, et il faut réfléchir comment les intégrer à l'arbre de source. Toutefois, ce n'est pas impossible. NetBSD l'a fait (en tout cas, pour la 4.1). Mais cela a été long et pénible.

                OpenBSD doit possèder gcc 2.95 pour la même raison pour laquelle NetBSD le gardait, à savoir le port VaX.

                Le passage en version 4.x leur permettrait
                1/ de pas avoir à avoir deux gcc dans leur base systeme
                2/ les empecherait de faire du buzz (vu que SSP est de base dans gcc 4.x, OpenBSD n'apporterait plus beaucoup de plus value).

                Le passage à gcc4 permet a aussi de corriger divers "bugs" dans NetBSD (d'incorrections en tout cas).

                La série 4.x a quand même introduit un warning très chiant, celui qui dit que les variables peuvent être non initialisés, et 90% du temps il se plante. Comme les BSD utilisent -Werror, ca bloque la compilation pour un faux motif et ca oblige à faire une "fausse initialisation" pour calmer gcc.

                Sinon, je suis relativement content de gcc4. J'attend l'intégration de gcc 4.2 dans NetBSD.

                Ca n'empeche pas qu'il est intéressant de pouvoir compiler les sources avec un autre compilateur. C'est ca aussi la correction et la portabilité du code.

                M'enfin, oui la majorité des OpenBSDistes sont des gros trolleurs :) Certains de leurs objectifs sont intéressants mais ils jouent souvent plus sur le buzz et le bruit que sur ce qu'ils font vraiment. (commentaire du vendredi en avance).
      • [^] # Re: Re ; Fin de gcc dans les *BSD ?

        Posté par (page perso) . Évalué à 2.

        Yaka :)

        Je te conseille d'ouvrir les sources de gcc. Tu comprendras tout de suite pourquoi il est difficile de corriger un bug, quand tu n'es pas un gourou gcc.

        Tu as l'air très doué. Je pense que tu va pouvoir aider la communauté BSD... Yapluka
        • [^] # Re: Re ; Fin de gcc dans les *BSD ?

          Posté par . Évalué à -2.

          > Je te conseille d'ouvrir les sources de gcc.

          Ben pareil avec mes sources.

          Tous truc "technique" est compliqué. On ne devient pas codeur gcc ou Linux du jour au lendemain.
        • [^] # Re: Re ; Fin de gcc dans les *BSD ?

          Posté par . Évalué à 2.

          Tu as l'air très doué. Je pense que tu va pouvoir aider la communauté BSD... Yapluka
          Ben non, c'est un sale gpleux qui pux. il se fera jeter des cailloux si il apporte du code.
          • [^] # Re: Re ; Fin de gcc dans les *BSD ?

            Posté par . Évalué à -3.

            Si les sources de gcc sont si "compliquées", c'est aussi une question historique.
            gcc (et d'autres logiciels GNU), ont été commencés il y a longtemps.
            D'où par exemple tous les #ifdef BSD, #if HAVE_STDIO_H, placés par soucis de compatibilité.
            Il est toujours plus facile de refaire quelque chose proprement, en ayant connaissance des erreurs à ne pas faire et des nouvelles techniques, que d'améliorer l'existant.
          • [^] # Re: Re ; Fin de gcc dans les *BSD ?

            Posté par . Évalué à 2.

            faut arrêter avec le délire de persécution.

Suivre le flux des commentaires

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