Design Stops Working When Modifying Unrelated Code

Ok, I will post the code, but it won't make any sense by itself.

    when SBC_OP =>
                flagVal(C_FLAG) := not I_PSR_ALU(C_FLAG);
                resultOutSigned := dataNumeric - dataAccumulatorNumeric - flagVal;
                resultOut <= std_logic_vector(resultOutSigned);
                
                updateCarryFlag(currFlags, resultOutSigned);
                updateZeroFlag(currFlags, resultOutSigned);
                updateNegativeFlag(currFlags, resultOutSigned);
                updateOverflowFlag(currFlags, resultOutSigned);        

Commenting out the line

 flagVal(C_FLAG) := not I_PSR_ALU(C_FLAG); 

stops my CPU from incrementing the program counter. Notice I said commenting out. Wouldn't you expect something to break when you add a line of code, not when you remove it?

That code section is contained within a large case statement. I will post the code in context.

entity alu is
    port (
        I_DATA_ALU        : in bit8; --data in from bus
        I_DATA_ACC_ALU    : in bit8; --data in from accumulator
        I_PSR_ALU        : in bit8; --data flags from status register
        I_SEL_ALU        : in aluOp; --select lines
        I_ADDRL_ALU        : in bit8; --data in from address bus low
        RD_ALU            : in std_logic; --read from alu (write to internal data bus)
        RD_ADDRL_ALU    : in std_logic; --read from alu (write to internal address bus low)
        RD_ADDRH_ALU    : in std_logic; --read from alu (write to internal address bus high)
        ENA_ALU            : in std_logic; --enable alu (read new value)
        
        Q_DATA_ALU        : out bit8; --data out to bus
        Q_DATA_ACC_ALU    : out bit8; --data out to accumulator
        Q_PSR_ALU        : out bit8; --data flags to status register
        Q_ADDRL_ALU        : out bit8; --data to address bus low
        Q_ADDRH_ALU        : out bit8H --data to address bus high
    );
end alu;
architecture aluLogic of alu is
    signal resultOut: bit8; --std_logic_vector value of result
    signal dataNumeric: bit8S; --numeric equivalent of I_DATA_ALU
    signal dataAccumulatorNumeric: bit8S; --numeric equivalent of I_DATA_ACC_ALU
    signal currFlags: bit8; --current PSR flags
    constant C_FLAG: integer := 0; --bit 0 for carry flag
    constant Z_FLAG: integer := 1; --bit 1 for zero flag
    constant V_FLAG: integer := 6; --bit 6 for overflow flag
    constant N_FLAG: integer := 7; --bit 7 for negative flag
......
begin
    dataNumeric <= signed(I_DATA_ALU) when ENA_ALU = '1'; 
    dataAccumulatorNumeric <= signed(I_DATA_ACC_ALU) when ENA_ALU = '1'; 
    process (I_SEL_ALU, I_PSR_ALU, dataNumeric, dataAccumulatorNumeric, resultOut)
        variable resultOutSigned: bit8S; --numerical (signed) result of operations
        variable flagVal: bit8S;
    begin
        currFlags <= I_PSR_ALU; --current flags default to same as input
        currFlags(5) <= '1';
        currFlags(4) <= '0';
        currFlags(3) <= '0';
        flagVal := x"00";
    
        case I_SEL_ALU is
                     when ADC_OP =>
                    .........
                    --more when statements
                    .........
                     when SBC_OP =>
                flagVal(C_FLAG) := not I_PSR_ALU(C_FLAG);
                resultOutSigned := dataNumeric - dataAccumulatorNumeric - flagVal;
                resultOut <= std_logic_vector(resultOutSigned);
                
                updateCarryFlag(currFlags, resultOutSigned);
                updateZeroFlag(currFlags, resultOutSigned);
                updateNegativeFlag(currFlags, resultOutSigned);
                updateOverflowFlag(currFlags, resultOutSigned);
            
            when others =>
                resultOut <= std_logic_vector(dataNumeric);
        end case;
    end process;
        
    Q_PSR_ALU <= currFlags; --update flags for PSR
    Q_DATA_ACC_ALU <= resultOut;
        ....................
        --some more code
end aluLogic;

--- Quote Start ---

I would suggest you start using SignalTap II integrated logic analyzer instead of running your design on extreme slow clock speed. Then check your counters in action and get some real information.

--- Quote End ---

I have already tested with SignalTap II and I get the same results. The reason why I'm running the design at such a slow clock rate is because I have to demonstrate this project such that people can actually see the instructions being executed on the real device. If it's running at 27MHz (or even 1MHz), no one can see what's happening.