Chociaż można użyć opcji -fdump-tree-all i -fdump-rtl-all w gcc, nie sądzę, że ich wyniki są bardzo przydatne dla ucznia kompilatora. FWIW, zacząłem pracować nad gcc w ramach moich studiów doktoranckich, mając już ukończone dwa studia licencjackie i znalazłem gcc, a jego pliki debugujące jako nieprzejrzyste i trudne do naśladowania.
Ponadto gcc tak naprawdę nie podąża za podręcznikiem projektowania kompilatorów. Nikt tak naprawdę nie robi, ponieważ nie działa tak dobrze. Jestem prawie pewien, że gcc nie generuje drzewa parsowania ani drzewa-składni abstrakcyjnej. Tworzy IR (zwany gimple), na którym wykonuje optymalizacje wysokiego poziomu.
Proponuję zamiast tego spróbować LLVM, który ma reputację dobrze zaprojektowanego i łatwego do naśladowania. Inną alternatywą jest pobranie kodu z podręcznika, zwłaszcza z książki Appel, zakładając, że jest ona dostępna.
Inną propozycją, jeśli mogę polecić własną na chwilę, jest użycie phc. Za pomocą phc można zobaczyć drzewo analizy jako obraz i wyświetlić AST i kod źródłowy po każdym pojedynczym przejściu w kompilatorze. Here is a comparison of parts of the AST and the parse tree. Są generowane trywialnie za pomocą phc. W gałęzi dataflow można zobaczyć kompilator IR, formularz CFG, SSA i dane wyjściowe debugowania z wnioskowania o typ i analizy aliasów. Możesz także włączać i wyłączać optymalizacje oraz przekazywać efekty, aby zobaczyć, jaki mają efekt.
Myślę, że to może być przydatne dla Ciebie.
Uwaga dla czytelników: z opcją kompilator zrzuca drzewo do pliku z nazwą kodu źródłowego i postfiksem takim jak ".optimized". Nie jest to wcale oczywiste, spędziłem ≈20 minut, przejrzałem dokumentację i przeszukano przypadki, w których gcc nie generuje zrzutu, gdy od czasu do czasu odnotowywano nowy plik * (co nie jest łatwe, ponieważ wykonałem test w '/ tmp /', który jest dość niezdarny) *. –