Remove -fms-extensions throughout the tree

[bz]

Summary

During a discussion about using -fms-extensions jhb pointed out that
we have them enabled in the kernel for gcc by default (even multiple
times in one part). I had missed all that and clang still failed on
me.

The original cause for enabling them for gcc apparently was to support
anonymous struct/unions for C11. clang apparently was fine.

A decade forward, more of these -fms-extensions have crept up in modules
and there are also three in CDDL world.

the only driver needing it to actually compile is ccp but fixing a
struct/union definition to be really anonymous solves that problem too.

So cleanup all uses cases of -fms-extensions given all compilers
supported currently shoudl be fine without them.

Reported by: jhb (all this but possibly the world CDDL parts)

[bz]

This still needs to pass a few universe builds with various compilers as indicated in email so don't just accept it yet ;-)

[bz]

Ok, I completed:

• a full universe with default options (clang)
• a universe with gcc14 restricted to amd64 (tried drm-kmod but didn't compile but seems independent)
• a universe with gcc13 restircted to amd64
• a universe with gcc12 restircted to amd64

For all gcc the LINT kernels failed, and the *SAN* kernels fail. GENERIC, GENERIC-NODEBUG, GENERIC-MMCCAM, FIRECRACKER, MINIMAL seemed fine.
For gcc most of the other architectures seem to lead to a "not supported error".

I would not expect any ports (kmod) fallout given this was gcc-only enabled in sys/conf/kern*; anyone else opinions.

Are there other combinations/compilers/versions I should try from main?

[jhb]

cddl/lib/libzpool/Makefile

283

I expect this to fail still as ZFS is compiled as c99, so I didn't even try this. Also, I had a separate commit for ccp first before doing a tree-sweep of the kernel.

sys/crypto/ccp/ccp_hardware.h

410

I kept these as comments.

[bz]

cddl/lib/libzpool/Makefile

283

Well it passed a universe with clang and it built with gcc12/13/14 on amd64.

sys/crypto/ccp/ccp_hardware.h

410

Want to push your bits in?

[bz]

a universe with gcc15 restircted to amd64 behaves the same as the other gcc; LINT* and *SAN* kernels fail but GENERIC/MINIMAL/.. finished.

[bz]

@jhb Do you want to push your changes in? Or put your changes up for review? Or should I re-add the comments in ccp as you said, then and split the commit into two, and just get it in?

[bz]

@jhb how do you want me/us to proceed here?

[jhb]

I've merged the ccp(4) changes if you want to land the rest of this.

[jhb]

I would maybe tweak the commit log a bit though:

This was originally added to support anonymous unions and structs with GCC
when compiling with C versions older than C11.  However, this became moot
when the default C standard was bumped from C99 to C17 in 15.0.

Importantly, they haven't been stale for a decade, only for the past year, and clang never needed these.

You could maybe even add Fixes: tags for the commit that switched the kernel to C17: 3a98d5701c7f3b6e0933ddb0085ea8ec3fd30d25.

I still don't understand why the CDDL bits build though since they use C99 explicitly. :(

[bz]

In D55072#1269818, @jhb wrote:

I still don't understand why the CDDL bits build though since they use C99 explicitly. :(

I followed-up by email to you about this. I am hesitant to commit this while this statement stays.