Weird behavior of right shift in C (sometimes arithmetic, sometimes logical)

GCC version 5.4.0 Ubuntu 16.04

I have noticed some weird behavior with the right shift in C when I store a value in variable or not.

This code snippet is printing 0xf0000000, the expected behavior

int main() {
    int x = 0x80000000
    printf("%x", x >> 3);
}

These following two code snippets are printing 0x10000000, which is very weird in my opinion, it is performing logical shifts on a negative number

1.

int main() {
    int x = 0x80000000 >> 3
    printf("%x", x);
}

2.

int main() {
    printf("%x", (0x80000000 >> 3));
}

Any insight would be really appreciated. I do not know if it a specific issue with my personal computer, in which case it can't be replicated, or if it is just a behavior in C.

Quoting from https://en.cppreference.com/w/c/language/integer_constant, for an hexadecimal integer constant without any suffix

The type of the integer constant is the first type in which the value can fit, from the list of types which depends on which numeric base and which integer-suffix was used.

int
unsigned int
long int
unsigned long int
long long int(since C99)
unsigned long long int(since C99)

Also, later

There are no negative integer constants. Expressions such as -1 apply the unary minus operator to the value represented by the constant, which may involve implicit type conversions.

So, if an int has 32 bit in your machine, 0x80000000 has the type unsigned int as it can't fit an int and can't be negative.

The statement

int x = 0x80000000;

Converts the unsigned int to an int in an implementation defined way, but the statement

int x = 0x80000000 >> 3;

Performs a right shift to the unsigned int before converting it to an int, so the results you see are different.

EDIT

Also, as M.M noted, the format specifier %x requires an unsigned integer argument and passing an int instead causes undefined behavior.