Strict Aliasing Rule

[nixbody]

Well, they say that they follow the C standard which means, unless they're lying, that it's in the C standard too. Clang does that too and also has this enabled by default according to their maunual.

https://clang.llvm.org/docs/UsersManual.html#strict-aliasing

The following is from the ISO/IEC 9899:2023 document:

• The effective type of an object for an access to its stored value is the declared type of the object, if
  any. If a value is stored into an object having no declared type through an lvalue having a type
  that is not a non-atomic character type, then the type of the lvalue becomes the effective type of the
  object for that access and for subsequent accesses that do not modify the stored value. If a value
  is copied into an object having no declared type using memcpy or memmove, or is copied as an array
  of character type, then the effective type of the modified object for that access and for subsequent
  accesses that do not modify the value is the effective type of the object from which the value is
  copied, if it has one. For all other accesses to an object having no declared type, the effective type of
  the object is simply the type of the lvalue used for the access.
• An object shall have its stored value accessed only by an lvalue expression that has one of the
  following types:
• • type compatible with the effective type of the object,
  • qualified version of a type compatible with the effective type of the object,
  • type that is the signed or unsigned type corresponding to the effective type of the object
  • a type that is the signed or unsigned type corresponding to a qualified version of the effective
    type of the object,
  • an aggregate or union type that includes one of the aforementioned types among its members
    (including, recursively, a member of a subaggregate or contained union), or
  • a character type.

Section 6.2.7 defines "compatible types" and starts with:

Two types are compatible types if they are the same.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf

We can discuss the standard and have our opinions on what is the intetion behind all those rules but the fact is that the two (of three?) major compilers GCC and Clang apply this rule by default when optimisations are enabled because their authors believe that the C standard allows it. It exists because some people believe that performance is more important than soudnes.

[tetrastes]

Your "The following" remains unchanged since the C99 standard. Moreover, there it has the following remark:

The intent of this list is to specify those circumstances in which an object may or may not be aliased.

And what? Reread my previous post and explain me, bazed on these rules, why the code from it is optimized, if "they follow the C standard"?
Nevertheless I don't argue, that "their authors believe that the C standard allows it", especially as quoted text was added to allow it. But it does not mean that every compiler maker ought or even is recommended to realize it. I doubt that it has noticeable effect on performance (again, reread my previous post and think why there is -fno-strict-aliasing). If it was so, I think Microsoft added it to their compiler.
I would be grateful if you show me the code which indeed needs aliasing, and this optimization enhance its performance, leaving it works as intended at the same time.

[nixbody]

I'm sorry but I don't understand why you are arguing with me. I just quoted (or interpreted) the C standard document and compiler manuals, I also provided links to the said document and manuals. You say that the section about aliasing in the C standard hasn't been changed since C99, but that's kind of the point. Since the beginning I'm saying that those aliasing rules have existed at least since C99. If an optimising compiler utilising these rules see two pointers of different types it can assume that they cannot alias, never ever, and therefore writes through these pointers don't affect the object pointed-to by the other pointer. In this very thread @Khrys showed an assembly code generated by GCC under this assumption. You can see that GCC removed some instructions and replaced some loads with constants, unlike FPC. A compiler certainly isn't required to follow the strict aliasing rules but a valid standard C programme is, otherwise it isn't a valid standard C programme.

[tetrastes]

To be honest, I don't want to argue. I want to understand how compilers can follow these rules and follow f.e. (from "6.3.2.3 Pointers" of C99 standard)

A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type.

at the same time.
And I asked you to explain the results of compiling one example... I'm afraid that the only explanation is that it is not "valid standard C program"...

As for @Khrys example. He shows that GCC's optimizer is better than FPC's one considering floats. But what is the impact of strict aliasing optimization? The code

Code: C  [Select][+][-]

1. int foo(float *f, int *i)
2. {
3.         *i = 1;
4.         *f = 0.0;
5.         return *i;
6. }

compiled with gcc 14.2.0 -O2 or -O3 produces

Code: ASM  [Select][+][-]

1.         movl    $1, %eax
2.         movl    $1, (%rdx)
3.         movl    $0x00000000, (%rcx)
4.         ret

what we see in his post.

Compiled with (-O2 or -O3) and -fno-strict-aliasing:

Code: ASM  [Select][+][-]

1.         movl    $1, (%rdx)
2.         movl    $0x00000000, (%rcx)
3.         movl    (%rdx), %eax
4.         ret

Is there much difference in performance of movl $1, %eax and movl (%rdx), %eax?
At last, -fstrict-aliasing option alone has no impact on results of compilation without optimization.

And now I feel that I have to stop this discussion.

[nixbody]

I didn't want for my answers to annoy you and I apologise if they did. I was mainly discussing what the C standard mandates and that such rules exist and can be used for performance optimisations but I can't really tell if in practice such optimisations can be very meaningful, the people behind them probably thought that they could. GCC and Clang change their behaviour because of these rules and that's why I was worried if FPC does the same. It seems that FPC doesn't even have any notion of aliasing rules which I appreciate because it makes certain operations easier and safer.

To be honest, I don't want to argue. I want to understand how compilers can follow these rules and follow f.e. (from "6.3.2.3 Pointers" of C99 standard)

A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type.

at the same time.

This seems similar to the situation with void *, you can convert the pointers but it doesn't say anything about actually dereferencing them which could only be done with a pointer that is of a type compatible with the effective type of the pointed-to object. I agree with you and anyone else who has their doubts if the strict aliasing rules are worth it.

I'm grateful to you and everyone else who participated in this discussion, it gave me some answers and useful insights. Thank you for your time.

Have a great weekend.