cross-build: Define __GNUC_PREREQ__ in cdefs.h

[markj]

Summary

This is required when including stdckdint.h and doesn't seem to be
provided by older clang.

[jlduran]

Thank you, these two commits fix GitHub's cross-builds on Linux.

[emaste]

Seems OK, although I wonder if __has_builtin(__builtin_add_overflow) will be true on GCC versions that are still relevant (and we could remove the __GNUC_PREREQ__ from stdckdint.h

[markj]

In D52933#1209484, @emaste wrote:

Seems OK, although I wonder if __has_builtin(__builtin_add_overflow) will be true on GCC versions that are still relevant (and we could remove the __GNUC_PREREQ__ from stdckdint.h

Apparently __has_builtin() itself only came in gcc 10, which is not that old really. Maybe not very relevant to us, but the header is likely used outside of FreeBSD. So I'd slightly prefer to fix this on the cross-build side.

[imp]

I know it's just for cross compiling, but maybe we can use the version we have in cdefs.h to avoid other foot-cannons in the future? The only reason this works is the || <something that works> in the instant use case.

/*
 * Macro to test if we're using a specific version of gcc or later.
 */
#if defined(__GNUC__)
#define __GNUC_PREREQ__(ma, mi) \
        (__GNUC__ > (ma) || __GNUC__ == (ma) && __GNUC_MINOR__ >= (mi))
#else
#define __GNUC_PREREQ__(ma, mi) 0
#endif

clang defines GNUC these days too...

[markj]

Apply Warner's suggestion.

[brooks]

Could we not just swap the order of the checks in stdckdint.h so clang never evaluates __GNUC_PREREQ__? We're already requiring at least an always-false __has_builtin in the next section in cdefs.h.

That being said I don't think we care about except in the most abstract sense about gcc 9 support for a C23 header.

[markj]

In D52933#1210459, @brooks wrote:

Could we not just swap the order of the checks in stdckdint.h so clang never evaluates __GNUC_PREREQ__? We're already requiring at least an always-false __has_builtin in the next section in cdefs.h.

That being said I don't think we care about except in the most abstract sense about gcc 9 support for a C23 header.

That would probably work too, assuming that all the versions of clang we care about have __has_builtin as well. At a glance that seems to be the case.

What's wrong with simply redefining __GNUC_PREREQ__ here though?

[brooks]

In D52933#1210494, @markj wrote:

That would probably work too, assuming that all the versions of clang we care about have __has_builtin as well. At a glance that seems to be the case.

Certainly. I don't think we care about things before 15, probably closer to 17. I wasn't able to determine when __has_builtin was added, but there was an issue with non-function-like builtins fixed in 10 and these are function-like so were fine even then.

What's wrong with simply redefining __GNUC_PREREQ__ here though?

It's a GNUism and pretty meaningless on with clang (which pretends to be GCC 4.2.1).

I'm also a little confused as to where __GNUC_PREREQ__ came from when all the references I can find online are to __GNUC_PREREQ (no trailing __).

[markj]

In D52933#1210529, @brooks wrote:

In D52933#1210494, @markj wrote:

That would probably work too, assuming that all the versions of clang we care about have __has_builtin as well. At a glance that seems to be the case.

Certainly. I don't think we care about things before 15, probably closer to 17. I wasn't able to determine when __has_builtin was added, but there was an issue with non-function-like builtins fixed in 10 and these are function-like so were fine even then.

What's wrong with simply redefining __GNUC_PREREQ__ here though?

It's a GNUism and pretty meaningless on with clang (which pretends to be GCC 4.2.1).

I'm also a little confused as to where __GNUC_PREREQ__ came from when all the references I can find online are to __GNUC_PREREQ (no trailing __).

Are you sure that's not __GNU_PREREQ?

[brooks]

In D52933#1210535, @markj wrote:

In D52933#1210529, @brooks wrote:

I'm also a little confused as to where __GNUC_PREREQ__ came from when all the references I can find online are to __GNUC_PREREQ (no trailing __).

Are you sure that's not __GNU_PREREQ?

I'm seeing https://github.com/lattera/glibc/blob/master/include/features.h#L158 (also true in upstream glibc, but the sourceware server seems to be getting killed by bots). I'm not objecting to the macro when used for GCC, but I am failing to find documentation so am confused.