Celkem zajimavy souhrn. Ale par veci jsem nepochopil:
- z jakeho duvodu "freebsd-gcc != gcc"? Copak podpora FreeBSD neni v mainline GCC? (nevim, zdrojaky ted nemam po ruce). V cem se tedy freebsd-gcc lisi?
- proc autor nedoporucuje pouzivat gcc -O2? Pokud vim, tak optimalizace maji dost malo spolecneho s operacnim systemem a naopak dost hodne spolecneho s cilovym procesorem. Takze pokud si FreeBSD lidi upravili GCC tak, aby jim z neho padajici assembler lip vyhovoval (ale furt by me zajimalo proc :-), dost pravdepodobne se to netyka optimalizaci a tudiz nevidim duvod proc je nepouzivat.
- doufam ze se FreeBSD poucilo z Linuxu a DevFS trefili na poprve "spravne" aby si nezadelali na stejne problemy ktere resil Linux se svym devfs ve 2.4...
- proc autor misto "tedy" pouziva "ie."? Johanka ma asi dovolenou... :-)
Hlavny dovod je asi to ze je to implementacia v jadre, v k2.6 pouzivaju spojenie hotplug+udev - takze sa pouzivaju standartne event (generovane vzdy) v spojeni s userspace toolom.
Podla mna je to cistejsie riesenie, oproti inkernel implementacii
ad gcc: gcc co je v base fbsd ma par veci upravenych + par veci pridanych atd. proto napr. neni doporuceno (a tusim to ani nefunguje) kompilovat world/kernel pomoci gcc z portu
ad -O2: gcc je zname tim ze produkuje spatny kod. napr. dost dlouho strasil problem kdy nejela knihovna libalias pri -O2 (pomahal jsem to opravovat) a byla to fakt kravina proc to nejelo (gcc spatne pochopilo nektere vazby)
ad devfs: mne funguje dobre.. je ale fakt ze nepouzivam zadne hotswap veci atd.
ad ie: no, psal jsem to tam protoze se mi to libi. navic. ie = id est coz je latinsky, ma snad nekdo neco proti latine?
Ja jsem nekde vykuchal a pouzil funkci strtod z FreeBSD libc, a nefungovala mi s optimalizacema, a pak jsem zjistil, ze to neni buga gcc, ale te funkce. Musi se to prelozit s -fno-strict-aliasing
no... ona je otazka ci je to chyba kdyz je potreba psat "urcitym zpusobem". ie. ze validni kod (ktery lze skoro vzdy napsat nekolika zpusoby) je validni jen "nekdy".... ja to nazyvam chybou prekladace
Nemas pravdu. "Strict aliasing" pravidla jsou v C imho minimalne od C90. Akorat drive jich kompilatory nevyzivali k uplateni optimalizaci, takze jejich porusovani nebylo poznat. Tohle je jasna chyba kodu a ne kompilatoru.
Chyba prekladace to neni. Najdete si v man gcc popis volby -fstrict-aliasing. ISO C99 predepisuje prisna pravidla pro aliasing. Pokud ceckovy program tato pravidla nedodrzuje, je to chyba v nem, ne v gcc. Protoze tato pravidla mohou byt nepohodlna, existuje popularni volba -fno-strict-aliasing (se kterou se preklada i Linux, pokud vim).
