[illumos-gate] 16935 Use gcc 14 as shadow compiler -- Robert Mustacchi <rm⊙fo>

Hi all, with this, the expected gcc shadow is going to be gcc14 per prior mail on this. Please reach out with any questions.

nice, thanks!

Thanks to all (especially tsoome) for grinding through all the necessary changes to make this possible!

awesome, thanks toomas and everyone

yes, thank you!

cool

Thanks tsoome_ and everyone!

fwiw, just tried gcc14 as primary, it built and even booted :D

ofc it does boot:P

I have been running 14 built system as the last cleanups were done;)

I think it's pretty rare that it won't boot if it works as a shadow, FWIW

The sadness tends to be more around new miscompilation or weird new anti-debugging features :P

in which case it is fortunate I and yuripv used it as primary;)

Yes, thank you!

Have you noticed any performance differences?

Double-check your outside-gate software... gcc14 breaks more than a few older-software's `configure` feature checks.

not obviously noticeable ones, but I really havent done serious performance related tests.

right now the effort has been to make those builds possible and so people can start to work on testing and improving....

tsoome_: Yes, definitely makes sense!

tsoome_: i just remember the switch to gcc10 in our fork, where some code would build by gcc10 shadow, but fail to link or load (kernel modules) when built by gcc10 primary

yep, I think we had something with 14 too

I guess 10 did that COMDAT change

maybe?

i think it was the multiply-defined symbols, among other issues

16867 gcc 14 needs to use -gstrict-dwarf afterall -- this was one

yuripv: Yeah I think that was the COMDAT thing where they stopped deduping stuff

jclulow: ah okay, wasn't sure if it's the same issue

I remember it being obscure haha

but honestly who can even remember breakfast

but otherwise yes, we do depend on compiler and not all what we do get is pure gold:)

but then again, there is also unbelievable amount of bad code around too.

tsoome_: have you seen gcc 14 be more agressive about dead code elimination?

I'm not sure about that. hm, I guess some wsdiffs on proto trees would be in order:D

but otherwise.. I still have about 90 commits in my smatch cleanup branch and still have to find why my zfs patch branch does get one multilist empty while it should not be... ;)

wsdiff of a compiler change is usually unreadable

but I noticed that some code of mine got more thoroughily eliminated, and made me fix (now) unused libs

yea, would need "approximate" diff for wsdiff...

where is that AI when one needs it...

It's off in the back woods, hallucinating.

probably checking function sizes may give some hints.

in this case, I could check for entire symbols disappearing for the thing that actually tripped me

but I'm not sure there's an easy automatic way to find things that don't remove whole symbols, beyond what you suggest :\

lost public symbols should be discovered via linker maps, but local ones...

but as you said, there's lots of bad code

I'm just wondering if I should get a head start on finding it :)