Update POPCOUNT macro to be type-flexible

[Nuthouse01]

Is your enhancement proposal related to a problem? Please describe.

The current definition of the POPCOUNT macro in gcc.h is simply #define POPCOUNT(x) __builtin_popcount(x). This only supports uint32 or smaller datatypes. When operating on a uint64 or type, the upper half of the number is truncated/ignored, leading to potential bugs.

Describe the solution you'd like

The compiler should examine the data type of x and use either __builtin_popcountll() or __builtin_popcount() as is appropriate. I envision a system very similar to the current implementation of LOG2 macro in util.h. Specifically,

#define POPCOUNT(x) (sizeof(__typeof__(x)) > 4 ? __builtin_popcountll(x) : __builtin_popcount(x))

Describe alternatives you've considered

Adding a second macro #define POPCOUNT_64(x) __builtin_popcountll(x) would also be acceptable, as way of making user code more readable and easier to remember.

Additional context

None

[github-actions]

Hi @Nuthouse01! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[pdgendt]

CC @Thalley

[Thalley]

I recently attempted to add a generic function for this: #84022

It had to be reverted due to naming, and I guess postponed until #64627 reaches a conclusion.

[Nuthouse01]

I'm not familiar with the Zephyr github process. Can I just make a merge request (pull request?) that is the change I want to see, and associate it with this issue? I really think that this would be a one-line change that is an inarguable improvement; perhaps things could still be further better (standardization of names, or a universal replacement for POPCOUNT, as mentioned in those issues you link) but that shouldn't stop us from making things a little bit better.

[Thalley]

I'm not familiar with the Zephyr github process. Can I just make a merge request (pull request?) that is the change I want to see, and associate it with this issue? I really think that this would be a one-line change that is an inarguable improvement; perhaps things could still be further better (standardization of names, or a universal replacement for POPCOUNT, as mentioned in those issues you link) but that shouldn't stop us from making things a little bit better.

Yeah! https://docs.zephyrproject.org/latest/contribute/index.html should contain all the information you need in order to prepare a PR for Zephyr. Please let me know here or on Discord if you need any help doing this.

Please also check out my attempt at a generic solution to this from #84022 and understand why that was reverted.

[RobinKastberg]

@Thalley the collision was unfortunate. But I wouldn't let that discourage you from making another attempt. The namespace discussions could go for ages and shouldn't block the feature itself.

[Thalley]

@Thalley the collision was unfortunate. But I wouldn't let that discourage you from making another attempt. The namespace discussions could go for ages and shouldn't block the feature itself.

Yeah, I was hoping that we would reach a consensus in #64627 before adding a new public generic API function. Maybe I should just go ahead and make it zephyr_count_bits and then see what reviewers say :D