Czy optymalizacja kompilatora może wprowadzać błędy?

Tak, oczywiście.
Zobacz Tutaj, tutaj (który nadal istnieje - "z założenia"!?!), Tutaj, Proszę., Proszę., tutaj ...

Gdy błąd zniknie po wyłączeniu optymalizacji, przez większość czasu jest to nadal twoja wina

Odpowiadam za komercyjną aplikację, napisaną głównie w C++ - zaczynałem od VC5, wcześniej przeportowałem do VC6, teraz z powodzeniem przeportowałem do VC2008. W ciągu ostatnich 10 lat liczba linii wzrosła do ponad 1 miliona.

W tym czasie mogłem potwierdzić pojedynczy błąd generowania kodu, który wystąpił podczas agresywnych optymalizacji, gdzie włączone.

Więc dlaczego narzekam? Ponieważ w tym samym czasie, były dziesiątki błędów, które sprawiły, że zwątpiłem w kompilator - ale okazało się, że to moje niewystarczające zrozumienie standardu C++. Standard daje miejsce na optymalizacje, które kompilator może lub nie może wykorzystać.

Przez lata na różnych forach widziałem wiele postów obwiniających kompilator, ostatecznie okazujących się błędami w oryginalnym kodzie. Bez wątpienia wiele z nich niejasne błędy, które wymagają szczegółowego zrozumienia pojęć używanych w standardzie, ale błędy w kodzie źródłowym niemniej jednak.

Dlaczego odpowiadam tak późno: przestań obwiniać kompilator zanim potwierdzisz, że to wina kompilatora.

Optymalizacja kompilatora (i środowiska uruchomieniowego) z pewnością może wprowadzić niepożądane zachowanie - ale przynajmniej powinno się zdarzyć tylko wtedy, gdy polegasz na nieokreślonym zachowaniu (lub rzeczywiście dokonujesz błędnych założeń dotyczących dobrze określonego zachowania).

Poza tym, oczywiście Kompilatory mogą mieć w sobie błędy. Niektóre z nich mogą dotyczyć optymalizacji, a konsekwencje mogą być bardzo subtelne - rzeczywiście są one prawdopodobnie, ponieważ oczywiste błędy są bardziej prawdopodobne naprawione.

Zakładając, że dołączasz JIT jako Kompilatory, widziałem błędy w wydanych wersjach zarówno JIT. NET, jak i Hotspot JVM (niestety nie mam szczegółów w tej chwili), które były odtwarzalne w szczególnie dziwnych sytuacjach. Czy wynikały one z konkretnych optymalizacji, czy Nie, Nie wiem.

Aby połączyć pozostałe posty:

1. Kompilatory czasami mają błędy w kodzie, jak większość programów. Argument "inteligentnych ludzi" jest całkowicie nieistotny, ponieważ satelity NASA i inne aplikacje zbudowane przez inteligentnych ludzi również mają błędy. Kodowanie, które optymalizuje, różni się od tego, które nie, więc jeśli błąd pojawi się w optymalizatorze, to rzeczywiście zoptymalizowany kod może zawierać błędy, podczas gdy nie zoptymalizowany kod będzie nie.

2. Jak zauważył Pan Shiny and New, możliwe jest, aby kod, który jest naiwny w odniesieniu do współbieżności i / lub problemów z czasem działał zadowalająco bez optymalizacji, ale nie powiódł się z optymalizacją, ponieważ może to zmienić czas wykonania. Możesz winić taki problem na kodzie źródłowym, ale jeśli pojawi się on tylko wtedy, gdy zostanie zoptymalizowany, niektórzy ludzie mogą winić optymalizację.

Tylko jeden przykład: kilka dni temu ktośodkrył , że gcc 4.5 z opcją -foptimize-sibling-calls (co jest sugerowane przez -O2) produkuje plik wykonywalny Emacs, który segfaultuje się przy starcie.

To zostało najwyraźniej naprawione od tego czasu.

Nigdy nie słyszałem ani nie używałem kompilatora, którego dyrektywy nie mogłyby zmienić zachowania programu. Ogólnie jest to dobra rzecz , ale wymaga to przeczytania instrukcji.

A miaĹ 'em ostatnio sytuacjÄ™, w ktĂłrej dyrektywa kompilatora "usunÄ ™ Ĺ' a " bĹ ' Ä ™ d. Oczywiście błąd nadal istnieje, ale mam tymczasowe obejście, dopóki nie naprawię poprawnie programu.

Tak. Dobrym przykładem jest podwójnie sprawdzony wzór blokowania. W C++ nie ma sposobu na bezpieczne zaimplementowanie funkcji double-checked locking, ponieważ kompilator może ponownie zamówić instrukcje w sposób, który ma sens w systemie jednowątkowym, ale nie w systemie wielowątkowym. Pełna dyskusja znajduje się na stronie http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

Czy to możliwe? Nie w głównym produkcie, ale to jest z pewnością możliwe. Optymalizacje kompilatorów to generowany kod; bez względu na to, skąd pochodzi kod (piszesz go lub coś go generuje), może zawierać błędy.

SpotkaĹ ' em siÄ ™ z tym kilka razy z nowszym kompilatorem budujÄ ... cym stary kod. Stary kod działał, ale w niektórych przypadkach opierał się na niezdefiniowanym zachowaniu, np. nieprawidłowo zdefiniowanym przeciążeniu operatora / cast. Działałoby to w vs2003 lub VS2005 debug build, ale w wydaniu uległoby awarii.

Otwarcie wygenerowanego zestawu było jasne, że kompilator właśnie usunął 80% funkcjonalności danej funkcji. Przepisanie kodu tak, aby nie używał niezdefiniowanego zachowania wyczyściło go w górę.

Bardziej oczywisty przykład: VS2008 vs GCC

Zadeklarowane:

Function foo( const type & tp ); 

Wywołane:

foo( foo2() );

Gdzie foo2() zwraca obiekt klasy type;

Ma tendencję do awarii w GCC, ponieważ obiekt nie jest w tym przypadku przypisany do stosu, ale VS robi pewną optymalizację, aby to obejść i prawdopodobnie zadziała.

Aliasing może powodować problemy z niektórymi optymalizacjami, dlatego Kompilatory mają opcję wyłączenia tych optymalizacji. Z Wikipedii :

Aby umożliwić takie optymalizacje w przewidywalny sposób, norma ISO dla języka programowania C (w tym jego nowszej edycji C99) określa, że jest nielegalne (z pewnymi wyjątkami), aby wskaźniki różnych typów odwoływały się do tej samej lokalizacji pamięci. Zasada ta, znana jako "strict aliasing", pozwala na imponujące zwiększa wydajność [potrzebne cytowanie], ale wiadomo, że łamie jakiś inny poprawny kod. Kilka projektów oprogramowania celowo narusza tę część standardu C99. Na przykład Python 2.x zrobił to, aby zaimplementować zliczanie referencji [1] i wymagał zmian w podstawowych strukturach obiektów w Pythonie 3, aby umożliwić tę optymalizację. Jądro Linuksa robi to, ponieważ ścisłe aliasowanie powoduje problemy z optymalizacją kodu inlined.[2] w takich przypadkach, po skompilowaniu z gcc, opcja -FNO-strict-aliasing jest wywoływany, aby zapobiec niechcianym lub nieprawidłowym optymalizacjom, które mogłyby wytworzyć nieprawidłowy kod.

Tak, optymalizacje kompilatorów mogą być niebezpieczne. Zazwyczaj trudne Projekty oprogramowania w czasie rzeczywistym zabraniają optymalizacji z tego właśnie powodu. W każdym razie, czy znasz jakieś oprogramowanie bez błędów?

Agresywne optymalizacje mogą buforować lub nawet robić dziwne założenia ze zmiennymi. Problem polega nie tylko na stabilności kodu, ale także może oszukać debuggera. Widziałem kilka razy debugger nie reprezentować zawartości pamięci, ponieważ niektóre optymalizacje zachowały wartość zmiennej w rejestrach mikro

To samo może się zdarzyć z Twoim kodem. Optymalizacja umieszcza zmienną w rejestrze i nie zapisuje jej do czasu jej zakończenia. Teraz wyobraź sobie, jak różne mogą być rzeczy, jeśli twój kod ma wskaźniki do zmiennych w stosie i ma kilka wątków

To teoretycznie możliwe, jasne. Ale jeśli nie ufasz narzędziom do robienia tego, co powinny, po co z nich korzystać? Ale od razu każdy argumentujący z pozycji

"Kompilatory budują mądrzy ludzie i robić mądre rzeczy " i w ten sposób można nigdy się nie mylisz.

To głupi argument.

Więc, dopóki nie masz powodów, aby sądzić, że kompilator tak robi, dlaczego o tym mówisz?

Z całą pewnością zgadzam się, że głupio jest mówić, że Kompilatory są pisane przez "mądrych ludzi", dlatego są nieomylne. Inteligentni ludzie zaprojektowali także Hindenberg i Tacoma Narrows Bridge. Nawet jeśli prawdą jest, że twórcy kompilatorów należą do najmądrzejszych programistów, prawdą jest również, że Kompilatory należą do najbardziej złożonych programów. Oczywiście, że mają robaki.

Z drugiej strony doświadczenie mówi nam, że niezawodność komercyjnych kompilatorów jest bardzo wysoko. Miałem wiele razy, że ktoś mi powiedział, że powodem, dla którego program nie działa, musi być błąd w kompilatorze, ponieważ sprawdził go bardzo dokładnie i jest pewien, że jest w 100% poprawny ... i wtedy okaże się, że w rzeczywistości program ma błąd, a nie kompilator. Staram się myśleć o czasach, że osobiście natknąłem się na coś, co byłem naprawdę pewien, że było błędem w kompilatorze, i mogę sobie przypomnieć tylko jeden przykład.

Tak ogólnie: zaufaj swojemu kompilator. Ale czy kiedykolwiek się mylą? Jasne.

To się może zdarzyć. Dotyczy to nawet Linuksa.

O ile dobrze pamiętam, wczesny Delphi 1 miał błąd, w którym wyniki Min i Max zostały odwrócone. Wystąpił również niejasny błąd z niektórymi wartościami zmiennoprzecinkowymi tylko wtedy, gdy wartość zmiennoprzecinkowa była używana w bibliotece dll. Co prawda minęło już ponad dekadę, więc moja pamięć może być nieco zamazana.

Miałem problem w. NET 3.5 jeśli budujesz z optymalizacją, dodaj kolejną zmienną do metody, która jest nazwana podobnie do istniejącej zmiennej tego samego typu w tym samym zakresie, to jedna z dwóch (Nowa lub stara zmienna)nie będzie ważna w czasie wykonywania i wszystkie odwołania do nieprawidłowej zmiennej zostaną zastąpione odwołaniami do drugiej.

Więc, na przykład, jeśli mam abcd typu MyCustomClass i mam abdc typu MyCustomClass i ustawiam abcd.a = 5 i abdc.a = 7 wtedy oba zmienne będą miały właściwość a=7. Aby rozwiązać problem, obie zmienne powinny zostać usunięte, program skompilowany (miejmy nadzieję, że bez błędów), a następnie powinny zostać ponownie dodane.

Myślę, że napotkałem ten problem kilka razy z. NET 4.0 i C# również podczas wykonywania aplikacji Silverlight. W mojej ostatniej pracy dość często spotykaliśmy się z tym problemem w C++. Być może dlatego, że Kompilacje trwały 15 minut, więc budowaliśmy tylko potrzebne biblioteki, ale czasami zoptymalizowany kod był dokładnie tak samo jak w poprzedniej kompilacji, mimo że dodano nowy kod i nie zgłoszono żadnych błędów kompilacji.

Tak, optymalizatory kodu są budowane przez inteligentnych ludzi. Są one również bardzo skomplikowane, więc posiadanie błędów jest powszechne. Proponuję w pełni przetestować każdą zoptymalizowaną wersję dużego produktu. Zazwyczaj produkty o ograniczonym zastosowaniu nie są warte pełnego wydania, ale nadal powinny być ogólnie testowane, aby upewnić się, że prawidłowo wykonują swoje typowe zadania.

Optymalizacja kompilatora może ujawnić (lub aktywować) uśpione (lub ukryte) błędy w kodzie. Może być błąd w kodzie C++, O którym nie wiesz, że po prostu go nie widzisz. W takim przypadku jest to błąd ukryty lub uśpiony, ponieważ ta gałąź kodu nie jest wykonywana [wystarczająco dużo razy].

Prawdopodobieństwo wystąpienia błędu w kodzie jest znacznie większe (tysiące razy większe) niż błąd w kodzie kompilatora: ponieważ Kompilatory są intensywnie testowane. Przez TDD plus praktycznie przez wszyscy ludzie, którzy używają ich od czasu ich wydania!). Jest więc praktycznie mało prawdopodobne, aby błąd został odkryty przez Ciebie i nie został odkryty dosłownie setki tysięcy razy, kiedy jest używany przez innych ludzi.

A uśpiony błąd lub ukryty błąd jest tylko błędem, który nie jest jeszcze ujawniony programiście. Osoby, które mogą twierdzić, że ich kod C++ nie ma (ukrytych) błędów są bardzo rzadkie. Wymaga znajomości C++ (bardzo niewielu może się o to ubiegać) i obszernego testowania kodu. On nie tylko o programistę, ale o sam kod (styl tworzenia). Bycie podatnym na błędy jest w charakterze kodu (jak rygorystycznie jest testowany) lub / i programisty (jak zdyscyplinowany jest w teście i jak dobrze zna C++ i programowanie).

Bezpieczeństwo + błędy współbieżności: jest to jeszcze gorsze, jeśli uwzględnimy współbieżność i bezpieczeństwo jako błędy. Ale przecież to " są " robaki. Pisanie kodu, który jest w pierwszej kolejności wolny od błędów pod względem współbieżności i bezpieczeństwa jest prawie niemożliwe. Dlatego w kodzie zawsze pojawia się błąd, który można ujawnić (lub zapomnieć) w optymalizacji kompilatora.

Wszystko, co możesz sobie wyobrazić robiąc z lub do programu, wprowadzi błędy.

Więcej i bardziej agresywne optymalizacje mogą być włączone, jeśli skompilowany program ma dobry pakiet testowy. Następnie można uruchomić ten pakiet i być nieco bardziej pewnym, że program działa poprawnie. Możesz również przygotować własne testy, które ściśle pasują do tych, które planujesz wykonać w produkcji.

Prawdą jest również, że każdy duży program może mieć (i prawdopodobnie ma) pewne błędy niezależnie od przełączników, których używasz do kompilacji.

Ze względu na wyczerpujące testy i względną prostotę rzeczywistego kodu C++ (C++ ma poniżej 100 słów kluczowych / operatorów) błędy kompilatora są stosunkowo rzadkie. Zły styl programowania często jest jedyną rzeczą, która je spotyka. I zwykle kompilator się zawiesi lub wytworzy wewnętrzny błąd kompilatora. Jedynym wyjątkiem od tej reguły jest GCC. GCC, szczególnie starsze wersje, miały wiele eksperymentalnych optymalizacji włączonych w O3, a czasami nawet na innych poziomach O. GCC również celuje w tak wiele backendów, że pozostawia to więcej miejsca na błędy w ich pośredniej reprezentacji.

Wczoraj miałem problem z. Net 4 z czymś, co wygląda...

double x=0.4;
if(x<0.5) { below5(); } else { above5(); }

I wywoła above5(); ale jeśli faktycznie użyję x gdzieś, wywoła below5();

double x=0.4;
if(x<0.5) { below5(); } else { System.Console.Write(x); above5(); }

Nie ten sam kod, ale podobny.