gcc not warning against the Strict Aliasing Rules

Question

I've been reading some articles about the Strict Aliasing Rules for a couple of days. Here are my understandings:

1. An object's effective type is the type of its declaration. If the object is an allocated memory, it does not have one until accessed by an lvalue with an effective type, which becomes the object's effective type.

2. An access to the value of an object must be through a compatible type with its effective type.

After I thought I got this, I wanted to do a simple experiment to see if my compiler really warns about this when I deliberately break the rule. Here's my code:

int main(void) {
    unsigned char c[5] = {0x1, 0x2, 0x3, 0x4, 0x5};
    int i = *(int*)c;
    printf("%x\n", i);
    
    return 0;
}

To me this seems to be against the rule because c has an effective type of char and we are trying to access it with an int pointer.

But my gcc compiles just fine! Even with the highest constraining level (-Wstrict-aliasing) it does not give a single warning. But strangely, replacing the int with a float gives the expected response:

int main(void) {
    unsigned char c[5] = {0x1, 0x2, 0x3, 0x4, 0x5};
    float i = *(float*)c;
    printf("%f\n", i);
    
    return 0;
}

The compiler gives a warning for this code. (dereferencing type-punned pointer will breakk strict-aliasing rules [Wstrict-aliasing])

Does the first code really break the rules? I know casting any pointer into a char* type is fine, but is it true the other way around? Or is it just something gcc does not care so much for?

Answer 1

According to the published Rationale for the C Standard, the purpose of the constraint referred to as the "strict aliasing rule" was to avoid requiring that a compiler given something like:

int x;
int test(double *p)
{
  x = 1;
  *p = 2.0;
  return x;
}

allow for the possibility that the store to *p might affect the value of x, even though there is nothing in the code that would suggest that such a thing could happen. Because the Standard explicitly specifies that implementations may process constructs where it imposes no requirements "in a documented manner characteristic of the environment", the authors saw no need to fully enumerate all of the constructs they expected implementations to handle consistently. Consequently, in order to avoid rendering the language useless, every compiler must process meaningfully some constructs that violate the "aliasing" constraints as written.

From what I can tell, one of the ways that gcc does that is by applying the rules bidirectionally in some cases beyond those provided for by the constraint. The rules as written wouldn't require that an implementation allow for the possibility that an object of character-array type might be accessed using an lvalue of type int, but they also wouldn't require that implementations allow for the possibility that a structure object containing an array of integers might be accessed by dereferencing an int* such as that formed by the decay of the array in an expression like myStruct.intArray[2]. In cases where the authors of gcc recognize that treating a construct as a violation of the "aliasing" constraints would be silly, they will treat the construct as though it were not a constraint violation, and thus will not warn about it.