GCC už není součástí FreeBSD (diskuse)

[bugme]

+milijon

[Ivorne]

Hmm, a to je opravdu Clang tolik lepší než gcc, jak se všichni poslední dobou tváří? Mě gcc přiijde svobodnější, ale moc do toho nevidím.

[Saljack]

To by mě taky zajímalo. Může někdo napsat proč je Clang lepší než gcc?

[Luboš Doležel (Doli)]

Interně je lepší podstatně - od základu je stavěn jako API a kompilátor je jen frontend k tomuto API. To dělá z (lib)Clangu výborný nástroj pro integraci do dalších aplikací, např. do IDE pro kontrolování zdrojáku před kompilací. To je taky důvod, proč se noví vývojáři hrnou do Clangu a ne to GCC, do kterého je obtížnější proniknout.

Další důvody: Clang je rychlejší. Clang dává lepší popisy chyb. Clang umí podporovat více cílových platforem (zatímco u GCC si musíte vytvořit oddělený toolchain). Atd. Atd.

Píšu o tom (a o LLDB) článek, snad ho do příštího týdne dopíšu.

[chrono]

Najnovšie verzie GCC v niektorých prípadoch zobrazujú chyby ešte prehľadnejšie, ako Clang (v niektorých prípadoch stále ešte nie, ale tejto oblasti sa pravdepodobne venuje oveľa viac úsilia, ako to bolo v minulosti). Comparison of Diagnostics between GCC and Clang

Pred nejakým časom som čítal článok o porovnávaní optimalizácií v GCC a Clang. Výsledok bol ten, že keď GCC použije len podobné optimalizácie ako Clang, rýchlosť kompilácie je viac-menej rovnaká (a vygenerovaný kód je v podstate rovnaký). Problém ale je, že rôznych optimalizácií je v GCC oveľa viac, takže štandardne je kompilácia pomalšia.

[Ivan]

To musim potvrdit. Ted nedavno jsem cumel co vsechno novy GCC umi. Napriklad jsem specializoval sablonu dal ji jako parametr jmeno tridy a gcc tu tridu nedokazalo najit, a SAMO mi nabidlo, ze trida se stejnym jmenem se nachazi v jinem namespace. Dost jsem cumel o kolik jsou prehlednejsi chybovy hlasky g++ kdyz pouzivate sablony.

Na druhou stranu je potreba rict, ze GNU na potreby programatory roky zvysoka kaslalo. Tipnul bych si ze nejstarsi pozadavek na source-code browsing pochazi z roku 2000. Dokonce vznikl fork gcc-xml, ktery behem prekladu generuje xml metadata ze zdrojaku. Nejcastesi duvod, proc gcc neco takovyho nema, byl: "Mame jiny priority a kdo neco takovyho potrebuje je kreten, neumi programovet, a nema na Linuxu co delat".

[Ivan]

Anebo predkompilovany headery. Ty uz gcc taky ma, ale taky to trvalo dlouho.

[Ivan]

Anebo linker. ld.gold od Google je radove rychlejsi.

[pavlix]

Zdá se tedy, že z existence Clang těží i GCC :).

[pc2005]

Konkurence se hodí vždy, ale doufám, že konkurence zůstane (tj. všichni se najednou nepřesunou k llvm).

[little.owl]

To dělá z (lib)Clangu výborný nástroj pro integraci do dalších aplikací, např. do IDE pro kontrolování zdrojáku před kompilací.

Ano, da se treba relativne snadno implementovat staticka analyza kodu.

GCC, do kterého je obtížnější proniknout.

Je to peklo ....

[pc2005]

Jo GCC křížová kompilace nebo ještě vtipnější kanadská kompilace je děs-běs.

[Peter Fodrek]

>Interně je lepší podstatně - od základu je stavěn jako API a kompilátor je jen frontend k tomuto API.

> Clang umí podporovat více cílových platforem (zatímco u GCC si musíte vytvořit oddělený toolchain).

Kedze mam rozrobeny, ale pozastaveny, port CBackendu pre LLVM 3.3 tak si dovolim tvrdit, ze toto su vlastnopsti LLVM ako celku neie Clangu..

[Luboš Doležel (Doli)]

Ano.

[Algi]

Odborně bohužel nemůžu, ale obecně je to prý kvůli tomu, že GCC je moloch a špatně se v něm dělají rozšiřující úpravy. Určitě budou nějaké informace na stránkách Clangu nebo obecně LLVM. Ohledně toho jak moc svobodný nebo nesvobodný projekt je bych fakt obavy neměl - obojí je opensource a to, že nevznikl z GNU nic moc neznamená (IMHO)...

[Ivorne]

Jak jsem pochopil, tak do vývoje Clangu dost kecá Apple. A GNU má mojí důvěru mnohem více než Apple.

Ono neplatí že je open-source jako open-source, některé projekty jsou mnohem otevřenější komunitě a vstřícnější k ostatním open-source projektům než jiné. Příkladem budiž open-source projekty Googlu, nebo poslední dobou Cannonicalu. Tak nevím, jestli u Clangu nemůže v budoucnu něco takového vzniknout.

[Luboš Doležel (Doli)]

Jak jsem pochopil, tak do vývoje Clangu dost kecá Apple.

Nemyslím si, že by to bylo až tak na škodu. V zájmu Apple je, aby Clang dobře fungoval a rozvíjel se.

[j]

A taky je mozna v jejich zajmu tam integrovat nejaky vypecenosti na zadost NSA ... takze uz nebude treba, to davat do zdrojaku aplikace, zakompiluje to tam primo kompilator.

[jadd]

A proto ho Freebsd uprodnostňuje. Zdrojáky nečte, posoudilo jen rychlost vygenerovaného kódu.

[Ivorne]

Obávám se, že se najdou otázky z oblasti vývoje, ve kterých se s Applem neshodnu. Prostě je mnohem lepší, když je vývoj otevřenější názorům všem přispěvatelů.

[bugme]

Nejaka _konkretni_ pripominka z vyvoje clang/llvm?

[Ivorne]

Ne. Ovšem obávám se, že o tom tu nemluvím. Až tu připomínku budu mít, tak může být pozdě.

[bugme]

Promin, ale mam pocit ze sis neco usmyslel a ted "mas pravdu za kazdou cenu"...

[Ivorne]

Já hlavně nic netvrdím, jen jsem položil dotaz a od té doby se snažím ho vysvětlit.

Vždyť jsi ani neřekl, v čem nemám pravdu, tak těžko mohu prosazovat svou pravdu za každou cenu. Prostě jsem svou pravdu řekl, k žádnému prosazování jsem nedostal ani příležitost.

Tak mi prosímtě aspoň naznač, v čem se mýlím a můžeme se někam pohnout.

[bugme]

Jenom rikam, ze usuzujes z nejakyho fiktivniho predpokladu.

[Ivorne]

Ale CO usuzuji ze špatného předpokladu? Já toho kolikrát usoudím, že se v tom ani pořádně nevyznám.

[bugme]

Usuzujes, ze se neshodnes s Applem na tom, ze by mel byt vyvoj otevrenejsi nazorum vsech prispevatelu. Ja sem si nevsimnul toho, ze by u clang/llvm byl nejaky problem s neotevrenosti nazorum prispevatelu.

[Ivorne]

Ten problém (s neotevřeností názorům přispěvatelů) je ale u jiných produktů Applu. Kdežto GNU se v tomto ohledu vždy choval příkladně. Takže ohledně otevřenosti více důvěřuji GNU než Apple.

Tudíž pokud má Apple na Clang nepřiměřeně větší vliv než ostatní, pak z hlediska otevřenosti je GCC lepší než Clang.

[pavlix]

Kdežto GNU se v tomto ohledu vždy choval příkladně.

Platí o i pro maintainery GNU projektů?

[bugme]

Ne vzdycky je to tak uzasny jak to popisujes ("vzdy choval prikladne"). Je spousta projektu, ktery z ruznych duvodu opustily gnu. Reakce gnu-fasisty stallmana byly obcas dost drsny. Jeden priklad za vsechny - gnutls.

[darth]

A to že do toho kecá Google Vám nevadí? Možno práve vďaka tomu kecaniu Apple a Google je clang tam kde je (Apple používa clang ako systémový kompilátor už nejaký čas)

[nyan]

BTW, Google pouziva(l) pro sve projekty obe najednou - clang i gcc. Clang kvuli debugovacim hlaskam, gcc kvuli tomu ze vysledny kod je porad lepsi (rychlejsi). Navic clang/llvm krome rychlosti zaostava v jistych oblastech (treba OpenMP, ale mozna uz se to trochu zlepsilo).

[vencas]

Pro mě vítězí clang tím, že kompiluje zhruba 5x rychleji než gcc (je to případ mého kódu, který hodně používá šablony, boost atd) a spotřebuje 2-3x méně paměti (gcc 4GB, clang 1.5-2GB).

Mínusy: Generovaný kód z clangu je o něco málo pomalejší než z gcc (10-20%) a clang neumí OpenMP.

Takže pro debugging clang (má často i hezčí diagnostiku chyb, i když gcc se taky hodně zlepšilo), release buildy s gcc.

[bugme]

Clang je svobodnejsi, protoze pouziva BSD-style licenci. Takze vedle technickych veci (jak uz tady nekdo zminoval) jsou to i duvody svobody.

[xkucf03]

Ano, např. mají přispěvatelé svobodu tě vydírat s tím, že údajně porušuješ jejich patenty – BSD licence tuto jejich svobodu nijak neomezuje.

[bugme]

Nejsme v USA, takze sw patenty me fakt nezajimaji... Zato me zajima svoboda, kterou mi BSD-style licence davaji vetsi nez "bezne open source licence".

[Sešívaný]

Nejsme v USA, takze sw patenty me fakt nezajimaji...

Kéž by to bylo tak jednoduché...

[pavlix]

+1

[Sten]

Což je ale problém celého FreeBSD

[chrono]

Pre používateľa je to úplne jedno a určite nie všetci vývojári môžu to, že niekto použije ich kód bez toho, aby ďalšie vylepšenia smel využiť aj ten vývojár, brať ako väčšiu slobodu.

[nyan]

Jestli pod "svobodnejsi" myslis "svobodu korporaci pouzit nekoho praci k vydelavani a ukazat mu prostrednik", pak ano.

[Šangala]

Ano to je svoboda, protože taková svoboda byla udělena. A ten kdo ji udělil s tím počítá a nevadí mu to, jinak by tu svobodu neudělil.

Ten komu se to nelíbí (někdo třetí), že to někdo dovolil a/nebo někdo to udělal, tak buď tu svobodu upírá těm dvěma a chce jim diktovat svůj světonázor, nebo jen závidí, že ti dva jsou spokojení.

Mimo jiné: prostředníčky tady ukazuje spíš ta druhá strana

[martin-ux]

Uplne vystizne napisane.

[Jerry12]

Puvodni spoustec rozmachu Clangu byla shoda v BSD komunite a Applu, ze by to chtelo poradny nastroje, co by nahradily GCC pod pro ne rozumnejsi licenci. Clang nemusi byt nutne lepsi nez GCC, ale donutil vyvojare GCC k rade vylepseni a je o hodne modernejsi. Vubec jen jeho existence a rozsireni pomohly, protoze vedly k uklidu obrovske spousty GCC specialit ze vsech mozny projektu vcetne tech pod GPL.

[chsajarsa]

U FreeBSD je problem nekompatibilita GCC licence. Do ted museli pouzivat nejakou starou verzi GCC(myslim 4.2.1), ktera byla pod GPLv2. Pak presli na GPLv3, coz zabranilo pouziti gcc ve freebsd.

[panCHrz]

+1

Hlavní důvod je právě v licenci.

[xkucf03]

Co jim brání vydat FreeBSD pod GNU GPL licencí?

(a je ta vazba na kompilátor vůbec tak těsná, aby bylo nutné některé části FreeBSD licencovat pod GPL?)

[chsajarsa]

Brani jim to, ze spousta velkym uzivatelu, kteri pouzivaji FreeBSD nechce pouzivat GPLv3 software, protoze maji strach, ze je nekdo donuti verejnit kod. Navic proc by to i bez toho delali? FreeBSD je zalozene na BSD licenci a pojeti svobody se chape jinak nez v GPL(schvalne se vyhybam otazkam co je svobodnejsi, protoze nechci rozohnit flame, kam tato otazka vzdy spadne).

A ano, kompilator se dodava spolu s operacnim systemem a je to v podstate zakladni vec. Samozdrejme, ze je nadale GCC ve spouste verzi pristupne v portech a vzdy bylo, ale uz neni soucasti core systemu, ale je to jen aplikace.

[bugme]

nechcou totalitu...

[stativ]

Třeba to, že je to FreeBSD a ne FreeGNU?

[Darth]

GCC už standardně není součástí systému. To samé se týká libstdc++.

vs

The GNU Compiler Collection and C++ standard library (libstdc++) are no longer built by default on platforms where clang is the system compiler.

[Darth]

A tak isto by sa asi patrilo povedať, že sa to týka FreeBSD "10" (head). FreeBSD 9.1 je buildované s gcc (by default) ... ak sa dobre pamätám

[Luboš Doležel (Doli)]

Clang je defaultní kompilátor už skoro rok, GCC se ale ještě do systému přidávalo. Teď už se tam ani nepřidává.

Verzi jsem do zprávičky doplnil.

[Darth]

20130906: The GNU Compiler Collection and C++ standard library (libstdc++) are no longer built by default on platforms where clang is the system compiler. You can enable them with the WITH_GCC and WITH_GNUCXX options in src.conf.

Ja to chápem tak, že sa len pri "buildworld" nebuilduje (by default). V strome ale stále je. Chápem zle?

[petr_p]

Vzhledem k tomu, že clang umí jen Intel a ARM, tak jinak to ani nejde.

[petr_p]

Podoba s portfoliem Applu je čistě náhodná.

[darth]

Ale no tak. Apple jediný potrebuje kompilátor a jediný používa ARM alebo Intel?

[petr_p]

Ne, ale vypovídá to o tom, kdo táhne vývoj. A jak si Apple představuje open source, známe třeba z KHTML.

[darth]

Ok ...

[Boris Dušek]

Od doby KHTML ovšem uplynulo již hodně času takže soudit podle toho dnešek není možné

[potato]

Apple je dnes mnohem horší, Tehdy byl rád, že byl rád, dnes může postupovat z posice síly -- a taky to dělá.

[darth]

Ale veď iste. Ja som narážal na ten tak trochu bulvárny nadpis správičky a podľa mňa nepresný preklad ....

[roman]

LLVM umi generovat kod pro daleko vic architektur nez je Intel a ARM. Napriklad vyse zminovane FreeBSD bootuje i na PowePC64 a na MIPSu.

[petr_p]

Clang CPU Architectures Features and Limitations, clang llvm on IPS??

[roman]

Outdated dokumentace, vecer commitnu fix. Diky za upozorneni.

[:::]

Vzpominam si ze jsem nekde slysel ze kod gcc je schvalne zatemnenej z politickych duvodu - aby nebylo snadny ho vykrast... Ted to ale nemuzu najit.

Vi o tom nekdo neco? Uz si nevzpominam jestli ten zdroj od kteryho to mam byl duveryhodnej...

Jestli je to nahodou pravda, tak i kdybych chapal ty politicky duvody, tak by me takova vec dost vadila.

[little.owl]

Ano, jeden cas se to tvrdilo ....

[Pavel Píša]

FSF nechtělo do GCC přidat podporu pluginů, protože by umožnily získat levně kvalitní parser C/C++, pak používat další uzavřené optimalizátory bez přispění do otevřených projektů a nakonec použít levně získaný optimalizátor na úrovni RTL a generátor assembleru. Celkem oprávněná obava a ochrana investic. Když zvážíme dále zmíněný Apple a množství dalších firem. Např. Microchip a i přímo "výrobci" kompilátorů často přechod na ARM a MIPS zvládli tak, že zabalili opatchované GCC s uzavřenými knihovnami a tvrdili, že optimalizují mnohem lépe než GCC. Přitom značnou část kódu kódu schovávají a snaží se zamlžit postup kompilace kompilátoru.

Takže z přílišné kontroly LLVM od Apple mám nepříjemný pocit. Vždyť Apple uměl vždy "dokonale" využívat otevřené licence. Celý jeho vzestup je svázaný s Objective-C. Slušný kompilátor sami neudělali a roky používali patchované GCC. Vlastní úpravy kompilátoru sice (nakonec) poskytli, ale i pro obecné Objective-C nutné runtime knihovny drželi tvrdě pod zámkem a zajistili, že vše bylo pro komunitu mimo uzavřené systémy Apple nepoužitelné.

Jinak souhlasím s tím, že postupné přetěžování položek struktur v GCC vedlo k totálnímu zmatení čtenáře a nejspíš i častým chybám zasvěcených. Z postupného přechodu implementace GCC na C++ mám také dost hrůzu, nějak mi ten jazyk úplně nesedí u low level věcí a na boostrap kompilátoru, ale na druhou stranu věřím, že to přinese výrazné zpřehlednění. Takže jsem na budoucnost i celkem zvědavý a věřím, že jak LLVM tak GCC se budou zlepšovat. Zánik/výrazný propad vývoje GCC by ale podle mě byl vážnější problém než případné zadrhnutí LLVM.

[pavlix]

FSF nechtělo do GCC přidat podporu pluginů, protože by umožnily získat levně kvalitní parser C/C++, pak používat další uzavřené optimalizátory bez přispění do otevřených projektů a nakonec použít levně získaný optimalizátor na úrovni RTL a generátor assembleru. Celkem oprávněná obava a ochrana investic. Když zvážíme dále zmíněný Apple a množství dalších firem. Např. Microchip a i přímo "výrobci" kompilátorů často přechod na ARM a MIPS zvládli tak, že zabalili opatchované GCC s uzavřenými knihovnami a tvrdili, že optimalizují mnohem lépe než GCC. Přitom značnou část kódu kódu schovávají a snaží se zamlžit postup kompilace kompilátoru.

Ve světě open source je na toto logickou odpovědí fork či nová implementace ze strany těch, kteří takovou poptávku mají. Za předpokladu, že tito nejsou schopni smysluplně přispívat do open source projektu, takový nemůže uspět. LLVM budiž důkazem, že toho schopni jsou.

[Ivan]

Viz treba http://gccxml.github.io/HTML/Index.html

[Pavel Píša]

Jenže fork znamená značné investice a pochybné forky většinou (naštěstí) odpadnou, často i s existencí dané firmy. Protože mít přidanou hodnotu a ještě ji stíhat integrovat se zdravě se vyvíjejícím mainline je náročnější, než spolupracovat s mainline a mít maximální snahu o integraci většiny/všeho užitečného do něho.

[pavlix]

Protože mít přidanou hodnotu a ještě ji stíhat integrovat se zdravě se vyvíjejícím mainline je náročnější, než spolupracovat s mainline a mít maximální snahu o integraci většiny/všeho užitečného do něho.

Myslím, že většina diskuze je právě o případech, kdy existuje důvod dát přednost nové implementaci či forku před původním projektem. Co je náročnější nebo méně náročné není vždy směrodatné. To dokazuje i fakt, že nejméně náročné je nedělat nic.

[pc2005]

Tak to API pro moduly by mohlo mít GPL only export symboly ne? Něco jako je teď v kernelu, jenom už od začátku navrženo se zkušenostmi, že se to občas někdo pokusí ochcat.

BTW když si vzpomenu na syntézu a implementaci FPGA, tak nevím zda je lepší mít hypotetický pochybný proprietární modul v GCC nebo pochybný proprietární toolchain.

[pavlix]

Tak to API pro moduly by mohlo mít GPL only export symboly ne? Něco jako je teď v kernelu, jenom už od začátku navrženo se zkušenostmi, že se to občas někdo pokusí ochcat.

Se zkušenostmi, že to může kdokoli triviálně ochcat to nemá cenu snad ani zkoušet, ne?

[Pavel Píša]

Jen upozorňuji, že v současné době již API pro pluginy součástí mainline GCC je.

[little.owl]

gcc python plugin jsem se snazil pouzit, ale prislo mi to tezkopadne a hlavne spatne dokumentovane.

[pc2005]

I pro sestavení: Defaultní kompilátor v distribuci, binárka na x86-64, cílová architektura x86-64. S potřebou přidat cílovou architekturu Microblaze?

[Pavel Píša]

GCC takto runtime konfigurovatelné/rozšiřitelné není. Teoreticky by ho šlo použít jako parser do syntax tree, možná i obecného RTL kódu, ale backend by pak musel být celý mimo binárku. Další problém je, že GCC i v compile time vlstního driveru jazyka (C, C++) používá definy z configure time, které osahávají cílovou architekturu (hlavičkové soubory C runtime a případně jádra) a zároveň mnoho věcí je definované ve fragmentech kódu, makefile a headerů v gcc-verze/gcc/config/cpu. To umožňuje provádět i optimalizace přizpůsobené dané architektuře již i v době budování syntax tree. Takže výsledné "obecné" syntax tree a mnoho dalšího ve skutečnosti není erchitekturně nezávislé. Takže GCC k uvedenému příkladu není použitelné. Stejně tak popis instrukcí cílového procesoru v architekturně nezávislých operacích (machine definition file) je pro každou architekturu přímo zpracovaný při kompilaci GCC a zakompilovaný do binárky. Těžko říct, jestli programátorsky čisté řešení s třídami a popisem machine pomocí objektů, může být stejně rychlé a schopné optimalizace. Na druhou stranu bude nejspíš snadněji spravovatelné a třeba i "run-time" rozšiřitelné. Na druhou stranu popis architektury pomocí jazyka podobného lispu (jak to řeší GCC) a hledání vhodné kombinace instrukcí cílové architektury, která bude mít shodný efekt v obecných operacích jako popis algoritmu z RTL (tedy něco jako prolog), je architektura zajímavá a má také své výhody. Přitom to, že není/nebyla snaha vše podřídit tomu, co je možné vyjádřit nějakým silnějším jazykem (C++), vede ke vniku vlastní specializované implementace vyjádření algoritmu a jeho zpracování na míru a může to mít výhody, které minimálně myšlenková limitace daná uvažováním v určitém omezeném prostoru daném jiným i přehlednějším systémem nedokáže objevit.

Ale celkově opravdu nevím co je lepší a bude zajímavé vývoj LLVM a GCC sledovat a určitě mají čím se vzájemně obohatit.