Lab 4 - GCC Build Lab (Part 1)

Introduction

This lab focuses on learning how to build the GCC (GNU Compiler Collection) from source code. GCC is a widely used compiler that supports multiple programming languages, including C and C++. Since GCC is a large and complex software project, understanding its build process is essential.


By completing this lab, we will:

• Learn how to obtain, configure, and compile GCC.

• Use common build tools like make, autotools, and configure.

• Gain experience working with large open-source projects.

• Compare build performance on different architectures (x86_64 and AArch64).


For this lab, we will perform the experiment on two SPO600 servers:

1. x86-001 (x86_64 architecture)

2. aarch64-002 (AArch64 architecture)


For now, I will begin with x86-001 and document the process. 








Step 1: Downloading the GCC Source Code

The first step is to obtain the latest GCC development version. The recommended way is to clone the official GCC repository using Git.

mkdir -p ~/git && cd ~/git
git clone https://gcc.gnu.org/git/gcc.git

• mkdir -p ~/git && cd ~/git → Creates a directory named git and moves into it.

• git clone https://gcc.gnu.org/git/gcc.git → Clones the entire GCC repository.

• The cloning process takes time because GCC has a long history and a large number of commits.






Step 2: Checking the Latest Commit

Once cloning is complete, we check the latest commit information. This helps verify that we have successfully obtained the latest development version.

cd ~/git/gcc
git log -1

• git log -1 → Shows details of the most recent commit like this.

commit 67e824c2497176980cb0c5d14bc730fa4ce2e1ad (HEAD -> master, origin/trunk, origin/master, origin/HEAD)

Author: Jeff Law <jlaw@ventanamicro.com>

Date:   Sun Mar 2 12:08:34 2025 -0700


    [RISC-V][PR target/118934] Fix ICE in RISC-V long branch support

    

    I'm not sure if I goof'd this or if I merely upstreamed someone else's goof.

    Either way the long branch code isn't working correctly.

    

    We were using 'n' as the output modifier to negate the condition.  But 'n' has

    a special meaning elsewhere, so when presented with a condition rather than

    what was expected, boom, the compiler ICE'd.

    

    Thankfully there's only a few places where we were using %n which I turned into

    %r.

    

    The BZ entry includes a good testcase, it just takes a long time to compile as

    it's trying to create the out-of-range scenario.  I'm not including the

    testcase due to how long it takes, but I did test it locally to ensure it's

    working properly now.

    

    I'm sure that with a little bit of work I could create at testcase that worked

    before and fails with the trunk (by taking advantage of the fuzzyness in length

    computations).  So I'm going to consider this a regression.

    

    Will push to the trunk after pre-commit testing does its thing.

    

            PR target/118934

    gcc/

            * config/riscv/corev.md (cv_branch): Adjust output template.

            (branch): Likewise.

            * config/riscv/riscv.md (branch): Likewise.

            * config/riscv/riscv.cc (riscv_asm_output_opcode): Handle 'r' rather

            than 'n'.

~


(END)



Step 3: Creating a Build Directory

To avoid modifying the original source code, it is recommended to create a separate build directory.

mkdir ~/gcc-build-001
cd ~/gcc-build-001

• mkdir ~/gcc-build-001 → Creates a new directory where we will compile GCC.

• cd ~/gcc-build-001 → Moves into the build directory.



Step 4: Configuring the GCC Build

Before building GCC, we need to set up the environment by running the configure script.

~/git/gcc/configure --prefix=$HOME/gcc-test-001

• ~/git/gcc/configure → Runs the configuration script from the GCC source directory.

• --prefix=$HOME/gcc-test-001 → Specifies where GCC should be installed after compilation.

• If any missing dependencies are reported, they need to be installed before proceeding.

• Running ls -l ~/gcc-build-001/Makefile should confirm that a Makefile was generated.




Step 5: Building GCC

Now that everything is set up, we can start the build process using make.

cd ~/gcc-build-001
time make -j 24 |& tee build.log

• make -j 24 → Starts the build process with 24 parallel jobs (for faster compilation).

• time → Measures how long the build takes.

• tee build.log → Saves both the output and errors to build.log.

• The build can take a long time (possibly over an hour).

• Using screen or tmux allows disconnecting and reconnecting while the build runs.

• If any errors occur, checking build.log will help with debugging.



To be continued in next posting!



Comments

Post a Comment

Popular posts from this blog

SPO600 2025 Winter Project - Stage 1: Create a Basic GCC Pass (part1)

Image
 Project Overview The goal of this project is to extend the GCC compiler by adding a custom pass that can analyze the functions being compiled. A GCC pass is a stage in the compilation process that processes intermediate representations (IR) of the source code. These passes perform various optimizations and analyses before generating the final machine code. 📌 What Will This Custom Pass Do? In Stage 1 , I am implementing a GCC pass that: • Iterates through each function in the compiled code. • Prints the function name being analyzed. • Counts the number of basic blocks in the function. • Counts the number of GIMPLE statements inside each function. • Outputs this information to the console. By completing this stage, I will gain hands-on experience with GCC’s internal structures, intermediate representations like GIMPLE , and how to modify GCC’s compilation pipeline. Step 1: Setting Up the Environment 🔹 Note: I have already completed GCC setup ...
Read more

SPO600 2025 Winter Project - Stage 2: GIMPLE Level Clone Analysis and Pruning (part4)

Image
 Progress Summary In this post, I worked on developing a custom GIMPLE-level GCC pass named skim to analyze function clone groups produced by Function Multi-Versioning (FMV). The goal was to determine whether the clones are functionally equivalent at the GIMPLE IR level and output either PRUNE or NOPRUNE . So far, I’ve successfully implemented the initial infrastructure and logic: - Iterated through all functions using `FOR_EACH_FUNCTION` - Classified functions into clone groups using regex to detect `.default`, `.resolver`, and `.variant.*` suffixes - Successfully grouped clones and output the groups to `dump_file` - Verified `.skim` file generation using the `-fdump-tree-skim` compiler flag - Confirmed correct execution of the `pass_skim::execute()` function Now, I aim to extend the functionality to compare GIMPLE IR within clone groups to verify if clones are truly functionally equivalent. Goal Determine at GIMPLE level if functions within each clone group are equivalent, an...
Read more

Lab 1 - 6502 Assembly Language

Image
Introduction In this post, I'll share my experience working on a fun and challenging lab about 6502 assembly language. Assembly language is a low-level programming language, and in this lab, I explored how it works by writing code to manipulate a simple pixel display. My goal was to learn how to calculate performance, optimize code, and modify it to create interesting visual effects on the display. Bitmap Code This code:     - Starts at memory address $0200 (the beginning of the display)     - Loops through all 1536 pixels (6 pages of 256 pixels each)     - Sets each pixel to yellow ($07) lda #$00 ; set a pointer in memory location $40 to point to $0200 sta $40 ; ... low byte ($00) goes in address $40 lda #$02 sta $41 ; ... high byte ($02) goes into address $41 lda #$07 ; colour number ldy #$00 ; set index to 0 loop: sta ($40),y ; set pixel colour at the address (pointer)+Y iny ; increment index bne loop ; continue until done the page...
Read more