Eksperymentuję z gcov przy użyciu mingw gcc 4.4.0. Dostawałem interesujące, ale dziwne wyniki. Wspólny wzór jest coś takiego ...Jak mogę uzyskać dokładniejsze wyniki z gcov?
5162: 66: std::string::iterator i = l_Temp.begin();
5162: 67: std::string::iterator j = l_Temp.end() - 1;
-: 68: char ch;
-: 69:
20564: 70: while (i < j)
-: 71: {
10240: 72: ch = *i; *i = *j; *j = ch; i++; j--;
-: 73: }
-: 74:
#####: 75: return l_Temp;
-: 76:}
Jak może nie być exected że return w ogóle, zważywszy, że tuż przed pętlą wyraźnie jest zarówno wykonanie i wyjściu? Myślę, że jestem ofiarą optymalizacji wartości zwracanych tutaj, ponieważ ta zmienna tymczasowa ma typ std::string.
Problem polega na tym, że już określam -O0 w opcjach kompilatora. Są to dokładne flagi kompilatora używam ...
-Wno-invalid-offsetof -g -O0 -fprofile-arcs -ftest-coverage
Mój najlepszy przypuszczenie to, że nie wszystkie optymalizacje są wyłączone -O0 po wszystkim. Mogę zacząć wyszukiwać określone flagi optymalizacyjne jeden po drugim, ponieważ zauważam problemy, ale wydaje mi się to dziwne.
A więc - jakie flagi powinny być Podaj szczegółowe informacje, aby uzyskać prawidłowe wyniki zasięgu z gcov?
EDIT
Dotychczas Chyba muszę następujące dodatkowe flagi ...
- -fno-default-inline
- -fno-inline
Nie jestem pewien, czy oba są potrzebne, choć myślę, że każdy z nich wyłącza inny określony typ linii.
Nie znalazłem żadnej metody wyłączenia optymalizacji wartości zwracanej. To nie jest duży problem, ale to trochę irytuje. W przypadku 100% pokrycia niektóre pliki, które naprawdę osiągają 100%, będą zgłaszane jako mniej z powodu tego problemu. Grep może znaleźć znaczniki ##### i pokazać, czy są one dla deklaracji return, ale nadal musisz przeprowadzić inspekcję wizualną, aby sprawdzić, czy problem dotyczy wyłącznie RVO.
Czy dodawanie konstruktorów -fno-elide może pomóc? – Mat
@Mat - Sprawdzę, ale jestem dzisiaj zajęty – Steve314
Może twoja funkcja jest włączona. Spróbuj skompilować za pomocą -O0. – whoplisp