cdefs.h: Assume the compiler supports at least GNU C 3.0 extensions

[imp]

Summary

All compilers that can build FreeBSD binaries (as opposed to the entire
system) support at least gcc 9 (gcc, clang, tcc). Even pcc supports most
of the gcc 4.3 attributes. Make this file simpler by removing support
for pre-3.0 compilers.

[kib]

I do not like this/object against the appoach. What is the point of having all that re-defines in sys/cdefs.h? Why not use GNUCC-ism attribute((something)) directly? It would be less confusing and less convoluted to see actual code feed to the compiler, from our sources.

IMO the point of cdefs.h is to hide compiler-specific features behind FreeBSD-specific features. If compiler cannot provide the feature, sys/cdefs.h should clearly state that at compilation stage.
In other words, I think it is mostly fine to do something like

#if defined(__GNUC__)
#define __freebsd_feature __gcc_feature
#else
#error compiler does not implement freebsd_feature
#endif

but not just assume that everything is GCC.

[imp]

In D45653#1041463, @kib wrote:

I do not like this/object against the appoach. What is the point of having all that re-defines in sys/cdefs.h? Why not use GNUCC-ism attribute((something)) directly? It would be less confusing and less convoluted to see actual code feed to the compiler, from our sources.

IMO the point of cdefs.h is to hide compiler-specific features behind FreeBSD-specific features. If compiler cannot provide the feature, sys/cdefs.h should clearly state that at compilation stage.
In other words, I think it is mostly fine to do something like

#if defined(__GNUC__)
#define __freebsd_feature __gcc_feature
#else
#error compiler does not implement freebsd_feature
#endif

but not just assume that everything is GCC.

You miss a subtle point, I think. I assume everything implements the API that gnu c does. I do not assume, per se, gcc is the compiler.

Besides, these changes are just a code cleanup to bring us up to the believed least common denominator, but that may change and we can adapt to new things we learn about it.

And the main problem with doing the above, apart from taking the 50 lines of #defines and turning them into 200 is that compilers lie about GNUC and GNUC_MINOR so the above construct would really hold us back. clang lies and says it's 4.2.1, for some crazy reason. pcc says it's 4.3.3, but doesn't implement all the 4.3 attributes, and also implements a few more. tinyC claims to be 9.3, but doesn't implement symver.

And when most things are supported, it just adds a barrier to new compilers being able to be built with out headers. It's a big reason I've *NOT* added a #if !GNUC_PREREQ(9,0) #error #endif to cdefs.h. It's not an error at include time, but it's an error at use time. And with this scheme, if we have a new mumble that's broken for clang, gcc, etc, it will throw that error when it's used, which is what we want... We want it to be harmless to add new mumbles and we want it to only be a problem iff __mumble is used. I don't think the "nice" error message is worth the hassle or cost for all the things that just work.

This approach actually preserves the ability to pivot to other compilers in the future for the base, provides a lower barrier to entry for new compilers and retains control points to allow us to communicate a richer semantic meaning than the current gcc attribute grammar allows (see the __writeonly define). I'm not changing approach, and going to a tree-wide sweep to a use it directly approach would be a bit mistake.

tl;dr: this is just a code cleanup to make this code easier to understand and maybe fix a few historical mistakes along the way.

So, respectfully, this is a hard pass on that suggestion.

[brooks]

I think this is a nice cleanup acknowledging reality.

I think the question "should these remain when we can count on the __attribute__((attribute)) existing?" is a question worth asking, but removing them is going to be a long and bumpy road as we've had these for a long time. In the mean time I see no value in retaining support for compilers that can't realistically work. It's just clutter.

[imp]

In D45653#1041605, @brooks wrote:

I think the question "should these remain when we can count on the __attribute__((attribute)) existing?" is a question worth asking, but removing them is going to be a long and bumpy road as we've had these for a long time. In the mean time I see no value in retaining support for compilers that can't realistically work. It's just clutter.

I think that's a good conversation to have, not least because I'm not sure where it will wind up. I can make arguments for / against it in my head that are convincing. I'd like to see what the wider community says.
But I also agree that's not relevant for this code review.
There's a lot of clutter in this file, and this is just the start to cleaning it up.