math: numbers: only define SOF gcd() if not already defined

[kv2019i]

Zephyr commit ("sys: util: Add gcd and lcm utilities") added a version of gcd() to sys/util.h that now can conflict with SOF numbers.h definition of gcd().

Make the SOF definition conditional. The Zephyr default gcd() version takes unsigned numbers while SOF version took signed, but it seems SOF existing usage is fine to make this change.

Link: #10428

[Copilot]

Pull request overview

This PR resolves a naming conflict between SOF's gcd() function and a newer Zephyr implementation by making the SOF definition conditional. The change ensures that if Zephyr's gcd() is available, it will be used instead of defining SOF's version.

Key changes:

• Made SOF's gcd() function definition conditional using preprocessor guards
• Added USE_SOF_GCD macro to control when SOF's implementation should be compiled

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/include/sof/math/numbers.h	Added conditional compilation guard to only declare gcd() if not already defined by Zephyr
src/math/numbers.c	Wrapped gcd() implementation in conditional compilation block matching the header

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[kv2019i]

FYI @singalsu . I'll proceed with merge given tests seem to pass and this fixes the PR CI. Please follow-up if you have/had something in plans where we need to bring signed gcd variant back.

[kv2019i]

Known issues seen https://github.com/thesofproject/sof/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Bugs%20seen%20in%20PR%20CI%22 -- otherwise looks good, proceeding with merge.

[singalsu]

Sounds honestly quite stupid to make a gcd function that takes only positive numbers, but since I don't think I've needed signed gcd() it's OK. Should scrutinize the Zephyr gcd() instead. Someone will fall into that trap for sure. It should be called gcd_unsigned() instead. Again an overly eager usage of unsigned when you can case. I don't get the C experts' preference for unsigned types. I've crashed and burned with those in my previous life with signal processing a mass market device so better to not be unsigned unless really needed (for that extra positive range and can't go int64_t or for bitfields).

[kv2019i]

@singalsu Looking at sys/util.h again, it seems it's doing some cleverness to handle both signed and unsigned use. The gcd() is a macro that is defined as:

#define gcd(a, b) ((((__typeof__(a))-1) < 0) ? gcd_s(a, b) : gcd_u(a, b))

So if 'a' is a signed type, the gdc_s() will be called (which takes signed arguments). So I think we are good, unless "gdc()" is called in some inner algo loop, which it probably isn't (and shouldn't be).