Zephyr misses strict aliasing disabling

[evgeniy-paltsev]

While debugging issue I've bumped when I was using new ARC GCC11 based toolchain I've surprisingly found that we don't disable strict aliasing (don't pass -fno-strict-aliasing option for gcc/llvm based toolchains).

I've seen the places where we violate strict aliasing rule in many places in Zephyr.

---

Here is an example:
In posix threads layer we do cast between k_tid_t (which is defined as typedef struct k_thread* k_tid_t)
and the pointer to posix_thread structure, which is defined as

struct posix_thread {
	struct k_thread thread;

    // *other fields* //
};

Here is an example of code where we do assignment which violates the strict aliasing rule (located in pthread.c)

int pthread_getschedparam(pthread_t pthread, int *policy,
			  struct sched_param *param)
{
	struct posix_thread *thread = (struct posix_thread *) pthread;
	uint32_t priority;

	if ((thread == NULL) || (thread->state == PTHREAD_TERMINATED)) {
		return ESRCH;
	}

	priority = k_thread_priority_get((k_tid_t) thread);       // <<<<---- incorrect!

	param->sched_priority = zephyr_to_posix_priority(priority, policy);
	return 0;
}

---

So, given that

• initial GCC11 issue goes away when disable strict aliasing
• we have places in code which violates strict aliasing rule
  I guess we need do disable strict aliasing.

I'm going to do that for ARC, however I guess it's worth to do it for all architectures.

Any ideas why it isn't disabled now?

[evgeniy-paltsev]

@abrodkin @ruuddw FYI

[ruuddw]

Any ideas why it isn't disabled now?

Performance I assume, with the strict aliasing assumption the compiler can optimize more. But most likely it wasn't a conscious decision.
Are there many violations? Could we do -Wno-strict-aliasing instead? I see '#pragma GCC diagnostic ignored "-Wstrict-aliasing"' in the syscall generation code...

[stephanosio]

cc @andyross @peter-mitsis

[evgeniy-paltsev]

Any thoughts about this?

As of today we have undefined behavior in Zephyr kernel code (so bumping priority)

To avoid that undefined behavior we either need to

• disable strict aliasing optimization (-fno-strict-aliasing option for GCC and LLVM)
  or
• fix all places in kernel code where we violate strict aliasing rule (IMO, it's hardly achievable)

[andyross]

Sorry, just seeing this. I'm not sure I buy that example. That's just typecasting, there's no aliasing because in the local function, the pointers have the same value and the compiler can prove that. And if k_thread_priority_get() is inlined, it gets the same treatment. If it's not inlined, then the pointer gets passed as an argument and aliasing optimization isn't possible anyway.

There's a lot of value in the gcc strict-aliasing optimization, and turning this off is going to have significant impact. Circumstances where a function actually gets two aliased variants of the same memory in a way that it can't prove are actually extremely rare. You need to work hard to trip over this. I guess my sense is that absent clear evidence of bugs we're permitting, we should leave this on. (And yes, I'm aware that Linux made the opposite choice. But that was back in the days before pervasive static analysis tools. And in any case Zephyr is less dynamic and does a lot less "copying memory around" than Linux.)