is it legal "__assume_aligned((NULL),MY_ALIGNED_MEMORY_ALIGN)"

[Marian_M_]

Is it legal "__assume_aligned((NULL),MY_ALIGNED_MEMORY_ALIGN)" when "MY_ALIGNED_MEMORY_ALIGN" is "sizeof(__m256)"?

I have various configurations on program startup, when user can choose using FLOAT(23bit), FLOAT(64bit), or FLOAT(128bit on x64).

Therefore some of variables, e.g. when user chooses FLOAT(64), therefore FLOAT(32) (and FLOAT128) will be NULL, and my question is what ICC will do when "__assume_aligned((" will be NULL. i.e. crash or ignored NULL value?

[Shenghong_G_Intel · Accepted solution]

Just have a try with a simple code, it will be ignored.

$ cat xx.cpp
#include <stddef.h>

int main() {
        __assume_aligned((void*)(NULL), 32);
        return 0;
}
$ icc xx.cpp && ./a.out
$

But looks like it cannot be built if you use "NULL" (which is defined a zero), I guess it is not a big problem...

$ icc xx.cpp && ./a.out
xx.cpp(4): error: expression must have pointer type
        __assume_aligned((NULL), 32);
                         ^

compilation aborted for xx.cpp (code 2)
$

Thanks,

Shenghong

[Marian_M_]

Of course I actually not meant "NULL" literally, but e.g. "float* x" holding the value of NULL, therefore convertible implicitly to "void*".

Thank you for test, I should have been smarter and do this simple test myself. Though, I can't predict behaviour for future compiler compatibility, like "what 'standard' says" in meaning internal compiler's standard, since this is unique for ICC.

[jimdempseyatthecove]

As long as NULL is a void* pointing to location 0, then it will meet any and all alignment asserts (other than a potential undefined issue of when the alignment requirement is stated as .le. 0).

Historically I do not know why they did not #define NULL ((void*)0)

As this would have avoided issues like yours above.

Jim Dempsey