GCC 4.6

Po téměř roce vývoje (GCC 4.5 vyšlo v dubnu 2010) bylo vydáno GCC 4.6. Nová verze přináší celou řadu nových vlastností a vylepšení. Novinkou je například podpora programovacího jazyka Go (gccgo). Kompletní seznam změn.

26.3.2011 15:07 | Ladislav Hagara | Nová verze

Komentáře

[stativ]

Teď ještě CLang 2.9…

[mirec]

Iba ja mám taký pocit, že gcc chýba podpora pre beh ako server (parsovanie headerov je pomalé, pch nepresné, pomalé) a hlavne podpora dopĺňania ako má clang?

[__dark__]

V době 4jádrových CPU na běžném desktopu mi nepřijde pomalé ani kompilování rozsáhlých C++ projektů.

[mirec]

Načo mi je štvorjadro keď je kompilátor schopný použiť jedno jadro?

[__dark__]

make -j5 :)

[mirec]

Ale ja potrebujem parsovať 1 súbor na ktorom práve pracujem. Nič viac nič menej, načo mi je -j5 keď je to jediný zdroják a gcc nevie využiť viacej jadier.

[__dark__]

Každý nástroj je možné znásilnit k jiným účelům, ale gcc je hlavně překladač. Pokud nejsi spokojený s doplňováním v IDE, tak si stěžuj na podporu C++ v daném IDE. Podle mě třeba nový KDevelop má to doplňování fakt ryché (jak parsování, tak doplňování)

[mirec]

A prečo by to malo robiť nejaké IDE keď to môže robiť kompilátor? Visual studio používa priamo parser kompilátora, XCode využíva priamo parser kompilátora (clang), a aj vo vime používam priamo parser kompilátora (gccsense) ktorý je ale príliš pomalý na reálne využitie takže ako záchranu používam ctags, čo ale nedoplní šablóny ani náhodou.

Okrem toho skúste sa zamyslieť ako môže IDE korektne dopĺňať kód. Má vari informáciu s akými voľbami preprocesora kompilujem? Nie, to má len kompilátor (ktorý si v prípade kompilačného serveru môže voľby zaznamenať, v súčasnosti riešim malým háčikom, ktorý ukladá do sqlite voľby pre každý súbor). Má vari plnú podporu jazyka, ktorý používam? Nie, bol by to predsa kompilátor! Vie rozpoznať či píšem C++ zdroják, alebo C++0x zdroják? Ako by mohol, toto vie len kompilátor, ktorý volám. Namiesto toho mi každé IDE, ktoré sa snaží tváriť inteligentne podčiarkuje rôzny kód pretože ho považuje za nesprávny len preto, lebo parser nie je úplne dokonalý. A zase na druhej strane ma neupozorní na skutočné chyby. Tak to ďakujem pekne za implementáciu toho istého do všetkých IDE podobne mizerným spôsobom. To radšej budem fandiť CLang-u aby dotiahli podporu pre mňa kľúčových vecí.

[__dark__]

Já osobně budu radši za mnohem kvalitnější vygenerovaný kód než rychlost parsování/kompilace, která v dnešní době už nehraje roli. Mi osobně Visual Studio funguje stejně blbě, jak popisuješ - hlásí chyby tam, kde nejsou, takže o tom propojení s překladače a IDE bych silně pochyboval

[mirec]

Vistual studio som len strelil, neviem ako je na tom v súčasnosti. Ale clang funguje celkom super (ukážka). Ale samozrejme CLang nestačí na boost, takže i keď dokáže dopĺňať kód rýchlo a kvalitne je mi nanič pretože boost nepohryzie. GCC síce schrúme ale gccsense je zúfalo pomalé (keďže na rozdiel od CLang-u nefunguje ako server).

[l4m4]

A prečo by to malo robiť nejaké IDE keď to môže robiť kompilátor?

Protože každý takový bordel a podpora nesmyslů komplikuje kód kompilátoru, čímž zvyšuje pravděpodobnost chyb. Já od kompilátoru především chci, aby dobře, tedy co nejvíce bez chyb, kompiloval. To je jeho účel.

[Boris Dušek]

Protože každý takový bordel a podpora nesmyslů komplikuje kód kompilátoru, čímž zvyšuje pravděpodobnost chyb. Já od kompilátoru především chci, aby dobře, tedy co nejvíce bez chyb, kompiloval. To je jeho účel.

Tak se zeptej autorů clangu, jak se jim to povedlo. Mě příjde normální, že se software (v tomto případě frontend překladače pro C-like jazyky) rozdělí na knihovny tak, aby se jednotlivé části daly použít a kombinovat různými způsoby, a dal se využít na víc věcí, než jedinou (i když tu hlavní). Proč by se syntaktický strom z frontendu nemohl použít i na statickou analýzu, doplňování kódu, generování XML popisujících API knihovny, atd.?

[l4m4]

Podařilo se jim to zřejmě proto, že už to takhle navrhovali. Program se navrhuje podle toho, k čemu má sloužit. Předpokládám, že cat bys nenavrhoval jako obecnou knihovnu + frontend... Tak 80% doby existence gcc s ním míkdo takové věci dělat nechtěl, takže takhle navržen není. A poslední, co by nám chybělo, je aby se do něj teď začaly bastlit nesmysly kvůli chytrákům, kterým pomalu doplňuje nějaké IDE.

[Ivan]

Popravde to chtela spousta uzivatelu, dokonce existovaly i 3rd party patche. Bohuzel to ale nebyla priorita vyvojaru.

[mirec]

Protože každý takový bordel a podpora nesmyslů komplikuje kód kompilátoru

Tak parser je nezmysel? Zaujímavé, že každý kompilátor ho má, len nie každý má prístupné API.

čímž zvyšuje pravděpodobnost chyb

Hmm, zaujímavé. Máme tu libclang, to si linkuje zopár IDE a aj vďaka tomu je to celkom slušne vychytané. Na druhej strane tu máme gcc, ktoré síce nie je experimentálne (vraj) ale občas padá ako zhnité hrušky.

Já od kompilátoru především chci, aby dobře, tedy co nejvíce bez chyb, kompiloval.

A ja chcem zase aby IDE nemuselo implementovať podstatnú časť kompilátora. Chcem aby slúžilo na úpravu kódu, nie na to aby samo kód kompilovalo.

[l4m4]

Tak parser je nezmysel? Zaujímavé, že každý kompilátor ho má, len nie každý má prístupné API.

Tak se rozhodni. Muselo by se gcc přepsat nebo do něj dobastlovat nesmysly, nebo nemuselo? Já tvrdím že ano a že by to vedlo k chybám. Co tvrdíš ty?

Máme tu libclang, to si linkuje zopár IDE a aj vďaka tomu je to celkom slušne vychytané.

Na to už jsem odpověděl výše.

A ja chcem zase aby IDE nemuselo implementovať podstatnú časť kompilátora.

A mě zase tvoje IDE vůbec nezajímá. IDE je milion, každé by něco chtělo a jejich uživatelé dvakrát tolik.

[miso]

Ak by tam dobastlili nezmysli, tak by to rozhodne viedlo k chybam. S parserom samozrejme suhlasim.

[miso]

nezmysly

[mirec]

Muselo by se gcc přepsat nebo do něj dobastlovat nesmysly, nebo nemuselo?

Vrstvorá štruktúra u kompilátoru ako gcc je dosť podstatná. Len tak pre zaujímavosť kompilátor nie je len priblblý kus softvéru, ktorý schrúme zdroják a vypľuje z neho binárku. Kompilátor má niekoľko vrstiev. Na začiatku je parser, ktorý spracuje kód do zdrojového stromu pričom kontroluje syntax, má dostupné zoznamy symbolov pre každý rozsah a jeho výstup je nezávislý na platforme a jazyku. Takže gcc má niekoľko parserov pre C++, D a podobné pričom z toho lezie stále rovnaký bordel. Patch na podporu dopĺňania syntaxe má asi 100 riadkov.

Takže zhrňme si to: gcc je členené do vrstiev (inak by bola podpora viacerých jazykov a platforiem takmer nemožná) a nič teda rozbíjať netreba. Stačí len sprístupniť verejné rozhranie a oddeliť to do samostatnej knižnice.

Namiesto toho si ale každý radšej na vlastnom piesočku bastlí to svoje IDE pričom ani jedno nezvládne C++0x. A pritom by stačilo tak málo.

[vodic]

Pokud je jeden zdrojovy soubor tak veliky, ze jeho preklad trva dele, nez zlomek vteriny, tak je v tvem projektu neco spatne. Zdrojove kody maji byt prehledne a ne to cpat vsechno na jedno misto.

[l4m4]

tak je v tvem projektu neco spatne

Ta věc, která je špatně, v tomto případě je, obávám se, jazyk. I programy typu hell-world v C++ se mohou kompilovat velmi dlouho, pokud využívají STL + boost + další monstrosity.

[Tomáš Bžatek]

OpenMP?

[martyone]

Server? Jako jeden? Lepší je zdrojáky distribuovat na více strojů

[mirec]

No jasné, čakať na CPU je dlhšie než čakať na sieť a CPU. Ľudia zobuďte sa, gcc potrebuje podporu behu ako server inak bude navždy pomalý. Spracovanie zdrojového kódu musí byť pekelne rýchle aby to bolo použiteľné, fakt nemám chuť v IDE stlačiť ctrl + space a teraz čakať kým sa niekam odošlú zdrojáky, schrumú a kompilátor mi ponúkne možnosti pre doplnenie. To je fakt choré!

[l4m4]

Fakt nevím, by měl kompilátor něco dělat s doplňováním v tvém IDE. Stěžuj si autorům toho IDE, pokud je pomalé. Když ti teče z kohoutku rezavá voda, tak to taky má řešit kompilátor?

[Petr Tomášek]

GCC now has stricter checks for invalid command-line options...

A kurva, to zas polovina projektů nepůjde zkompilovat

[__dark__]

GCC začíná být opravdu dobrý překladač. Co se týče generování MMX a SSE2 kódu (s použitím intrinsics) tak už předběhl MSVC, co se týče plain C/C++ kódu, tak je MSVC trochu lepší (hlavně produkuje kompaktní kód).

Do budoucna to vidím na konkurenční boj mezi gcc a clang :)

[tom]

A navic MSVC konci u C89, takze na vyvoj v cistem C docela solidni vopruz.

[Martin Mareš]

Pokud vím, tak ani C89 neumí. Pouze průnik C++ a C89. Takže typový systém se chová podle C++, nikoliv tak, jak se má chovat v Céčku.

[tom]

Je to mozne, ja spalil nekolik hodin portovanim jedne nasi knihovny na MSVC, ale kdyz se ukazalo, jak by nam to znepehlednilo kod, tak jsme od toho upustili.

[__dark__]

V tom případě je někde chyba. Je mi jasné, že žádný překladač není dokonalý, ale to samé bych mohl říct o kterékoliv knihovně napsané pro ten správný operačný systém, překladač, atd...

Ze zkušenosti vím, že stačí pár maker pro tzv "compiler specific" věci, a pokud je zdroják dobře napsaný, tak takový kód je pak možné přeložit téměř jakýmkoliv překladačem.

[tom]

Tak napriklad MS prekladac neumi literal typu pole (vec z C99), coz u knihovny, ktera pracuje s vektory, je sakra znat. Na operacnim systemu je ta knihovna nezavisla, nepouziva zadne systemove API.

[Tomáš Bžatek]

Jaj, to zas bude segfaultu pri kompilaci systemu. Naposledy s 4.5.0 jsem musel trochu doladit CFLAGy, nedalo se temer nic zkompilovat.