Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de inico :
- [04/04@16:24] Freenet 0.7 alpha is out !
- [16/01@17:46] Microsoft Propose Mozilla 1.6
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 ?
> Lire le journal (116 commentaires, moyenne: 3).
llvm
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 galactikboulay () le 16/09/2007 à 12:36. (lien). É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 ribwund () le 16/09/2007 à 13:28. (lien). É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 lasher () le 17/09/2007 à 23:10. (lien). É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 ribwund () le 18/09/2007 à 07:52. (lien). É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 Gabriel Linder () le 18/09/2007 à 10:19. (lien). É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 ribwund () le 19/09/2007 à 11:54. (lien). É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 galactikboulay () le 19/09/2007 à 12:06. (lien). É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 ribwund () le 19/09/2007 à 12:11. (lien). É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 herodiade () le 19/09/2007 à 13:11. (lien). É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 ribwund () le 19/09/2007 à 14:17. (lien). É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
-
[^]Re: llvm
Posté par A0cC0Fk () le 16/09/2007 à 18:26. (lien). É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 ribwund () le 16/09/2007 à 21:23. (lien). É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
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 …
E Ultreïa !
La rapidité ne suffit pas
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.
Ma signature ici
-
[^]Re: La rapidité ne suffit pas
Re: Fin de gcc dans les *BSD
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.
-
[^]Re: Fin de gcc dans les *BSD
Posté par kowalsky () le 16/09/2007 à 17:28. (lien). Évalué à 7.Et personne chez les BSD ne dit que c'est un GCC killer d'ailleurs.
--
You got the money, I got the soul.-
[^]Re: Fin de gcc dans les *BSD
-
-
[^]Re: Fin de gcc dans les *BSD
Posté par IsNotGood () le 16/09/2007 à 18:41. (lien). É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 totof2000 () le 17/09/2007 à 14:33. (lien). É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 Matthieu C () le 16/09/2007 à 22:01. (lien). É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
-
[^]Re: Fin de gcc dans les *BSD
Posté par IsNotGood () le 18/09/2007 à 02:41. (lien). É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 zul (Jabber id, page perso, ) le 18/09/2007 à 08:27. (lien). É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
-
-
Re:
> 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 nullisimo () le 16/09/2007 à 19:22. (lien). É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 IsNotGood () le 16/09/2007 à 20:26. (lien). É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 nullisimo () le 16/09/2007 à 20:36. (lien). É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 IsNotGood () le 16/09/2007 à 22:00. (lien). É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 GTof (Jabber id, ) le 17/09/2007 à 06:58. (lien). É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 boklm (page perso, ) le 17/09/2007 à 08:57. (lien). É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 Frédéric COIFFIER () le 17/09/2007 à 09:51. (lien). É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 Matthieu Moy (page perso, ) le 17/09/2007 à 14:21. (lien). É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 benja () le 17/09/2007 à 18:37. (lien). É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 IsNotGood () le 17/09/2007 à 19:17. (lien). É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 Ph Husson (page perso, ) le 17/09/2007 à 20:30. (lien). É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 IsNotGood () le 17/09/2007 à 22:57. (lien). É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 Matthieu Moy (page perso, ) le 18/09/2007 à 13:08. (lien). É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 IsNotGood () le 18/09/2007 à 22:41. (lien). Évalué à 0.Qui a dit ça ?
Des trolleurs dlfp ou les développeurs gcc ?-
[^]Re: Re:
Posté par Matthieu Moy (page perso, ) le 19/09/2007 à 08:22. (lien). Évalué à 8.http://gcc.gnu.org/gcc-3.2/c++-abi.html
The main point of the GCC 3.2 release is to have a relatively stable and common C++ ABI for GNU/Linux and BSD usage, following the documentation at http://www.codesourcery.com/cxx-abi/
-
-
-
-
-
-
-
-
[+] [^]Re: Re:
Posté par IsNotGood () le 16/09/2007 à 22:22. (lien). É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 nullisimo () le 17/09/2007 à 06:45. (lien). É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 IsNotGood () le 17/09/2007 à 07:55. (lien). É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 kaouete (page perso, ) le 17/09/2007 à 08:24. (lien). É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 Axioplase Ashi (page perso, ) le 19/09/2007 à 11:26. (lien). É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 thedidouille () le 19/09/2007 à 19:35. (lien). É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 lasher () le 20/09/2007 à 10:53. (lien). É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 Sytoka Modon (page perso, ) le 17/09/2007 à 06:52. (lien). É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 IsNotGood () le 17/09/2007 à 08:00. (lien). É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 Sytoka Modon (page perso, ) le 17/09/2007 à 09:31. (lien). É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 GeneralZod () le 17/09/2007 à 09:33. (lien). É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 briaeros007 () le 17/09/2007 à 10:08. (lien). É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 ?)--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Re:
Posté par Troy McClure (page perso, ) le 17/09/2007 à 14:21. (lien). É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 briaeros007 () le 17/09/2007 à 19:29. (lien). É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.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
[^]Re: Re:
Posté par IsNotGood () le 17/09/2007 à 19:35. (lien). É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 pasBill pasGates () le 17/09/2007 à 22:11. (lien). É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 IsNotGood () le 17/09/2007 à 23:03. (lien). É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 pasBill pasGates () le 17/09/2007 à 23:38. (lien). É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 IsNotGood () le 18/09/2007 à 03:14. (lien). É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 IsNotGood () le 18/09/2007 à 03:19. (lien). É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:
-
[^]Re: Re:
Posté par pasBill pasGates () le 19/09/2007 à 00:35. (lien). É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 Ontologia (page perso, ) le 20/09/2007 à 10:44. (lien). É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.-
[^]Re: Re:
Posté par Troy McClure (page perso, ) le 20/09/2007 à 11:14. (lien). É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 Ontologia (page perso, ) le 21/09/2007 à 09:08. (lien). Évalué à 5.Pose la question à mon chef...
-
-
-
-
-
[^]Re: Re:
Posté par IsNotGood () le 18/09/2007 à 03:29. (lien). É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 pasBill pasGates () le 19/09/2007 à 00:37. (lien). É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 IsNotGood () le 18/09/2007 à 03:45. (lien). É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 pasBill pasGates () le 19/09/2007 à 00:18. (lien). É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 pasBill pasGates () le 19/09/2007 à 00:32. (lien). É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 herodiade () le 17/09/2007 à 10:04. (lien). É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 Sytoka Modon (page perso, ) le 17/09/2007 à 11:56. (lien). É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 ?
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 ?
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 PsychoFox () le 17/09/2007 à 12:32. (lien). Évalué à 6.ton commentaire aurait pu être excellent sans ton troll de fin.
-
[^]Re: Re ; Fin de gcc dans les *BSD ?
Posté par zul (Jabber id, page perso, ) le 17/09/2007 à 13:06. (lien). É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 lasher () le 17/09/2007 à 23:26. (lien). É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 herodiade () le 18/09/2007 à 11:23. (lien). É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 IsNotGood () le 17/09/2007 à 20:04. (lien). É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 PsychoFox () le 18/09/2007 à 06:34. (lien). É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 IsNotGood () le 18/09/2007 à 07:01. (lien). É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 PsychoFox () le 18/09/2007 à 07:59. (lien). É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 IsNotGood () le 18/09/2007 à 09:01. (lien). É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 PsychoFox () le 18/09/2007 à 09:35. (lien). É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 IsNotGood () le 18/09/2007 à 10:13. (lien). É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 briaeros007 () le 18/09/2007 à 12:12. (lien). É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.
--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par PsychoFox () le 18/09/2007 à 13:11. (lien). É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 briaeros007 () le 18/09/2007 à 14:10. (lien). É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).--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
[^]Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par Bapt (page perso, ) le 18/09/2007 à 09:36. (lien). É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 IsNotGood () le 18/09/2007 à 10:30. (lien). É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 PsychoFox () le 18/09/2007 à 11:18. (lien). É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 briaeros007 () le 18/09/2007 à 12:21. (lien). É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 critiqu
-
-
-
-
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.