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

284

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 ↗

(On Diff #171040)

I kept these as comments.

[bz]

cddl/lib/libzpool/Makefile

284

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

sys/crypto/ccp/ccp_hardware.h

410 ↗

(On Diff #171040)

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.

[bz]

In D55072#1270466, @bz wrote:

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.

I believe I solved the gcc mystery.
I'll finish discussion this by email with jhb before adding the conclusion etc here.
@jhb understands this way better than I do :)

[bz]

Hi everyone,

so here's the new proposed commit message; please feel free to correct/improve.
I'll go and rebase the change for cpp_hardware.h in the mean time and then hope this can go, so in a next step I can see about LinuxKPI USB.

@jhb, how should I mention all the email and digging back and forth with you given that was extremely helpful?

------------------------------------------------------------------------

Remove -fms-extensions throughout the tree

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
my use case (needing another option).

The original cause for enabling them for our tree back then was that
we needed to support C11 anonymous struct/unions.
Our in-tree gcc 4.2.1, despite later patches, needed the
-fms-extensions to support these even though this was not the expected
use case for that option ( cc4a90c445aa0 enabled it globally for the
kernel).
clang at that time (or at least when it became default for 10.0)
already was fine (with C11).

Any later gcc (4.6.0 onwards) did not need that option anymore, even
when compiled for -std=iso9899:1990 (which does not support anonymous
structs/unions) unless one would add -pedantic (see gcc git 4bdd0a60b27a).
This is also the reason why userland cddl sources now compile with the
option removed despite CSTD= c99.

The only driver which needed the option recently was ccp, but that was
fixed in 8d3f41dbcb2a by jhb.

So cleanup all uses cases of -fms-extensions for the moment as they are
no longer needed given all compilers currently supported seem to be
fine without them and gcc-4.2.1 was removed from the tree in stable/13
in 2020 (a9854bc3812b).

Reported by: jhb (all this but possibly the world CDDL parts)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days

------------------------------------------------------------------------

[bz]

Updating for ccp.

[imp]

Change is good, and I like the commit message.