Stupid compiler signs my fast uint's

Hello /prog/riders.
I've stumbled upon a problem when I tried to OPTIMIZE a topologic sort function for a geometry package. Here's the gist of it:
extern "C"
{
#include <stdint.h>
}

enum {LEFT = 1u, RIGHT = 2u, BOTH = 3u};

int main()
{
    bool side  = true;
    const bool side_const = true;

    uint_fast8_t n;

    const uint_fast8_t a = side  ? LEFT : RIGHT,
                       b = LEFT;
    const uint_fast8_t A = side_const ? LEFT : RIGHT,
                       B = LEFT;

    uint_fast8_t c = side ? LEFT : RIGHT,
                 d = LEFT;
    uint_fast8_t C = side_const  ? LEFT : RIGHT,
                 D = LEFT;

    n |= a; // warning: conversion to ‘uint_fast8_t’ from ‘int’ may alter its value
    n |= b;
    n |= A;
    n |= B;

    n |= c; // warning: conversion to ‘uint_fast8_t’ from ‘int’ may alter its value
    n |= d; // warning: conversion to ‘uint_fast8_t’ from ‘int’ may alter its value
    n |= C; // warning: conversion to ‘uint_fast8_t’ from ‘int’ may alter its value
    n |= D; // warning: conversion to ‘uint_fast8_t’ from ‘int’ may alter its value

}
As you can see the compiler evaluated the expressions for b,A and B and didn't complain about type conversion. Why then, does it need to convert my fast uints to slow ints in the case of a,c,d,C and D?
I compiled with
$ gcc -std=c++98 -Wconversion bittwiddling.cpp.
My compiler version is
$ gcc -V
gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)

>>15
I must be doing something wrong, then.
I'll need to check if packing the masks into the fast integer type is worthwhile. If the fast type is going to get promoted to a higher rank int on every bitwise op then I might as well use that rank in the first place.
>>17
I know. I was fighting caffeine deprivation at the time.