Defekt optymalizacji kompilatora x64

Podczas dalszego kodowania mojego silnika natrafiłem na bardzo dziwny błąd kompilatora Visual Studio. Zaczynając od początku – mam oto taki kod:

enum
{
	// Rozmiary pól
	MAX_BITS_INDEX = sizeof(Size_t) * 4,
	MAX_BITS_MAGIC = sizeof(Size_t) * 4,
	// Maksymalne wartości pól (Przesunięcie 1 w dwóch operacjach, ponieważ inaczej kompilator nie daje rady)
	MAX_INDEX = ((1 << MAX_BITS_INDEX / 2) << MAX_BITS_INDEX / 2) - 1,
	MAX_MAGIC = ((1 << MAX_BITS_MAGIC / 2) << MAX_BITS_MAGIC / 2) - 1
};
/* ... */
 
// handle = 0x0000000400000006;   - przykladowo
// Size_t ma rozmiar wskaźnika (jest zależny od platformy)
Size_t value = handle & MAX_MAGIC;

Otóż problem z tym kodem jest taki, że gdy zostanie skompilowany na platformę x64, zostaje wygenerowany następujący kod w assemblerze:

    79:                 {
    80:                         Size_t value = handle & MAX_MAGIC;
 
000000013FC96F94  mov         rax,qword ptr [handle]
000000013FC96F9C  mov         qword ptr [value],rax
 
    81:                         if(value == *it) return true; // Dalszy kod

Jak widać problem polega na braku kluczowej instrukcji and, której zadaniem jest odcięcie najstarszych 32-bitów. Dla porównania kod assemblera wygenerowanego dla platformy x86 jest następujący:

    79:                 {
    80:                         Size_t value = handle & MAX_MAGIC;
00DC9DDC  mov         eax,dword ptr [handle]
00DC9DDF  and          eax,0FFFFh
00DC9DE4  mov         dword ptr [value],eax
    81:                         if(value == *it) return true; // Dalszy kod

Tutaj instrukcja ta występuje.

Błąd ten jednak nie występuje gdy samemu sprecyzuję stałą, tj.:

Size_t value = handle & 0xffffffff;

W tym przypadku zostanie wygenerowany poprawny kod.

Wniosek jest taki, że kompilator widząc operację and zmiennej ze stałą typu enum (który przechowuje wartości 32-bitowe), traktuje tą zmienną jako typ 32-bitowy. W tym przypadku stwierdza, że instrukcja and nie ma sensu, bo wartość MAX_MAGIC zawiera maksymalną wartość (0xffffffff). Według mnie jest to ewidentny błąd i nie powinno takie coś wystąpić.

// Edit :)
Problemem oczywiście jest to, że enum jest tak naprawdę typem int, więc się dokładnie tak zachowuje.

Problemów z x64 ciąg dalszy

Postanowiłem przekompilować aktualnie pisany framework pod platformę x64. Jest to już trochę napisanego kodu, więc objawiło się to trzema problemami, z których najważniejszym jest ten komunikat:

LNK1112: module machine type 'X86' conflicts with target machine type x64''

Zostaje on wyrzucony wtedy, gdy podczas składania programu x64 Linker napotka bibliotekę skompilowaną pod target x86.Poprawne ustawienie bibliotek

Przyczyną tego konfliktu są błędne wpisy ścieżek do bibliotek statycznych, które znajdują się w opcjach Visual Studio. Niestety wpisy dla platformy x64 są po prostu kopiowane z platformy Win32 (nie wszystkie, bo jest ich mniej). Należy je poprawić tak aby wskazywały na foldery z bibliotekami x64. Obok jest obrazek z poprawnymi ustawieniami mojego Visual Studio.

Drugim, ale już mniej znaczącym problemem jest ostrzeżenie

conversion from 'size_type' to 'int', possible loss of data

powodowane rozrzeszeniem rozmiaru typu ‘size_type’ z 4 do 8. Typ ten jest zwracany przez funkcje size() w kontenerach biblioteki standardowe. W tym przypadku rozwiązaniem jest po prostu zamiana powszechnie używanego (unsigned) int na size_type bądź własny odpowiednik zdefiniowany w klauzulach #ifdef/#endif :).

Ostatnim problemem jest brak inline’owych wstawek assemblerowych. W moim przypadku za ten błąd odpowiadało makro NAssert, w środku którego jest wykorzystana konstrukcja:

__asm 
{
   int 3 
}

Powoduje ona wywołanie Breakpointa w miejscu asercji. Okazuje się, że rozwiązanie tego jest bardzo proste, ponieważ Visual Studio posiada następującą funkcję typu intrinsic:

__debugbreak()

Powoduje ona dokładnie tę samą akcję co podana wyżej wstawka w assemblerze.

A poniżej wynik całego procesu przenoszenia :).
End

Problem z kompilacją x64 na Win7 RC

Dzisiaj postanowiłem spróbować skompilować coś pod platformę 64-bitową. Jako że dysponuję teraz już odpowiednim sprzętem, systemem, więc nic nie stało na przeszkodzie aby to uczynić. Ze znalezionych w internecie informacji dowiedziałem się tyle, że wystarczy przestawić docelową platformę z Win32 na x64 i już można przystąpić do próby kompilacji.Przed poprawką

Niestety tu pojawił się problem, ponieważ jedynymi dostępnym platformami oprócz Win32 są platformy ARM. Po kolejnym skorzystaniu z wyszukiwarki Google dowiedziałem się, że winę za to ponosi nieodpowiednia kolejność instalacji Windows SDK 7, Visual Studio oraz braku odpowiedniego dla niego Service Packa. Poprawna kolejność instalacji jest następująca:

  1. Visual Studio 2008
  2. Service Pack 1 dla Visual Studio 2008
  3. Windows SDK 7

Oczywiście nie miałem ochoty robić reinstalacji VS i WSDK, dlatego poszukałem innego rozwiązania. Oto ono:

  1. Deinstalacja “Microsoft Visual C++ Compilers 2008 Standard Edition – enu – x64” oraz “Microsoft Visual C++ Compilers 2008 Standard Edition – enu – x86”
  2. Naprawa instalacji Visual Studio (Przez funkcję Repair)
  3. Instalacja Service Packa

Należy zaznaczyć, że użycie funkcji Repair na instalacji WSDK7 usunie tę poprawkę.

Po poprawce

Tutaj znajduje się oryginalna stronka z opisem naprawy.

Błąd kompilatora

Udało mi się wreszcie opanować kawałek kodu, który męczył mnie od 2 dni. Okazało się, że umieściłem w strukturze, która była agregatem, referencję. Następnie zainicjalizowałem obiekt takiej struktury jako agregat. Wszystko było ładnie, dopóki nie postanowiłem przestawić kompilacji z Debug na Release. Aplikacja zaczęła się sypać. Dzisiaj udało mi się wreszcie znaleźć ten błąd, który tkwił w referencji umieszczonej w agregacie, po jej usunięciu wszystko było ok.

Myślę, że jest to błąd kompilatora, który powinien przynajmniej ostrzegać o próbie inicjalizacji referencji w agregacie. Wynik takiej operacji jest niestety niezdefiniowany.

Problemy z plikami afxres.h oraz winres.h w Visual C++ EE 2008

Mała porada dla tych, którzy chcą otworzyć stare projekty, które zawierają pliki *.rc.
Przy próbie kompilacji takich projektów, może wyskoczyć błąd, który oznajmia, że nie mamy plików podanych w tytule.

Rozwiązanie jest proste, wystarczy nazwę tego pliku podmienić na windows.h. Dzięki temu można korzystać z zasobów ładowanych do pliku *.exe. (Sprawdzałem tylko na prostym projekcie z książki Programowanie w DirectX Masona McCuskey’a).

W Visualu C++ EE, zablokowana jest możliwość otwierania plików *.rc, jednak nie tak do końca, albowiem wystarczy kliknąć na takim pliku prawym przyciskiem myszy, a następnie wybrać Open with… i w oknie wybrać Source Code (Text) Editor. Według mnie zawsze jest to jakieś rozwiązanie.
EDIT: wystarczy kliknąć na takim pliku prawym przyciskiem myszy i opcję View Code. Thx Tarains.

Spotkałem się również z takim problemem, jak brak zdefiniowanej stałej IDC_STATIC (używanej do tworzenia szablonów okien dialogowych).
Kod błędu:
error RC2104 : undefined keyword or key name: IDC_STATIC

W takim przypadku należy do pliku resources.h dodać następujący kod:

#ifdef IDC_STATIC
#undef IDC_STATIC
#endif
#define IDC_STATIC (-1)