Forum > General
Strict Aliasing Rule
nixbody:
I would like to ask if it is legal to access a block of memory via pointers of different types. It seems to be pretty common practice in FreePascal code I've seen so far, including FCL, to have a storage declared as one type and then intentionally use a pointer of a different type to access it. E. g.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---TFPMemoryImage.FData: PFPIntegerArray which is treated as
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---PFPColorArray for non-paletted images. That would be an undefined behaviour in C (at least since C99). I would be happy should such casts were legal in FreePascal but, since it's illegal in C, I would like to hear from the developers of FPC whether or not it's legal. Thank you.
marcov:
It's simply accepted that such usage is implementation defined/architecture dependent. Which is probably the idea behind the C defined/undefined status also.
nixbody:
The idea behind the strict aliasing rule in C is that it allows for aggressive optimisations when an optimisaing compiler can safely assume that two pointers of different types can never alias each other. Because GCC and other big compilers really use this rule to eliminate some loads/stores, it is very dangerous to break this rule with high level optimisation settings. So what's the situation with FPC?
Khrys:
I don't think that the ISO Pascal Standard mentions aliasing at all (unlike the ISO C Standard), so I'd agree with @marcov that it's implementation-defined.
Regarding FPC's implementation, it seems that currently no such aggressive optimizations are performed:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---function Foo(F: PSingle; I: PInteger): Integer;begin I^ := 1; F^ := 0.0; Result := I^;end;
With -O4 and constprop, deadstore, deadvalues, dfa, regvar explicitly turned on via {$optimization}, the above code compiles to this:
--- Code: ASM [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---mov dword ptr [rsi], 1xorps xmm0, xmm0movss dword ptr [rdi], xmm0mov eax, dword ptr [rsi]ret
For comparison, the equivalent C function is optimized by GCC to eliminate the reload of I via [rsi] under the assumption that F and I may never refer to the same object:
--- Code: ASM [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---mov dword ptr [rsi], 1mov eax, 1mov dword ptr [rdi], 0ret
With the amount of code in the FCL (and elsewhere) that relies on the absence of strict aliasing rules, I don't expect this to change soon (or at all).
Apart from that, personally I don't think that the existence of the absolute variable modifier is compatible with the notion of strict aliasing being present in FPC's memory model.
MarkMLl:
In any event untagged variant records are a legal part of the language, they may be passed by reference and pointers to them may be declared.
It's difficult to imagine a language which could be used to write system-level modules (i.e. including its own RTL etc.) which did not have this capability. Whether it is something which should be made available at the application level is a different matter.
MarkMLl
Navigation
[0] Message Index
[#] Next page