21:49:09 <gitomat> [illumos-gate] 16935 Use gcc 14 as shadow compiler -- Robert Mustacchi <rm⊙fo>
21:50:14 <rmustacc> Hi all, with this, the expected gcc shadow is going to be gcc14 per prior mail on this. Please reach out with any questions.
21:50:45 <tsoome_> nice, thanks!
21:51:24 <sommerfeld> Thanks to all (especially tsoome) for grinding through all the necessary changes to make this possible!
21:53:24 <richlowe> awesome, thanks toomas and everyone
22:02:27 <jclulow> yes, thank you!
22:02:29 <yuripv> cool
22:21:16 <danmcd_> Thanks tsoome_ and everyone!
22:25:25 <yuripv> fwiw, just tried gcc14 as primary, it built and even booted :D
22:29:43 <tsoome_> ofc it does boot:P  
22:30:17 <tsoome_> I have been running 14 built system as the last cleanups were done;)
22:36:14 <jclulow> I think it's pretty rare that it won't boot if it works as a shadow, FWIW
22:36:52 <jclulow> The sadness tends to be more around new miscompilation or weird new anti-debugging features :P
22:37:04 <tsoome_> in which case it is fortunate I and yuripv used it as primary;)
22:37:17 <jclulow> Yes, thank you!
22:37:30 <jclulow> Have you noticed any performance differences?
22:37:35 <kebe> Double-check your outside-gate software... gcc14 breaks more than a few older-software's `configure` feature checks.
22:38:51 <tsoome_> not obviously noticeable ones, but I really havent done serious performance related tests.
22:41:16 <tsoome_> right now the effort has been to make those builds possible and so people can start to work on testing and improving....
22:46:32 <jclulow> tsoome_: Yes, definitely makes sense!
22:59:42 <yuripv> 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
23:00:26 <tsoome_> yep, I think we had something with 14 too
23:00:35 <jclulow> I guess 10 did that COMDAT change
23:00:43 <jclulow> maybe?
23:01:07 <yuripv> i think it was the multiply-defined symbols, among other issues
23:01:26 <tsoome_> 16867 gcc 14 needs to use -gstrict-dwarf afterall -- this was one 
23:02:56 <jclulow> yuripv: Yeah I think that was the COMDAT thing where they stopped deduping stuff
23:03:31 <yuripv> jclulow: ah okay, wasn't sure if it's the same issue
23:03:40 <jclulow> I remember it being obscure haha
23:03:54 <jclulow> but honestly who can even remember breakfast
23:04:54 <tsoome_> but otherwise yes, we do depend on compiler and not all what we do get is pure gold:)
23:05:57 <tsoome_> but then again, there is also unbelievable amount of bad code around too.
23:07:48 <richlowe> tsoome_: have you seen gcc 14 be more agressive about dead code elimination?
23:10:02 <tsoome_> I'm not sure about that. hm, I guess some wsdiffs on proto trees would be in order:D
23:11:52 <tsoome_> 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...  ;)
23:12:19 <richlowe> wsdiff of a compiler change is usually unreadable
23:12:44 <richlowe> but I noticed that some code of mine got more thoroughily eliminated, and made me fix (now) unused libs
23:14:13 <tsoome_> yea, would need "approximate" diff for wsdiff...
23:14:34 <tsoome_> where is that AI when one needs it...
23:15:38 <nomad> It's off in the back woods, hallucinating.
23:15:40 <tsoome_> probably checking function sizes may give some hints.
23:16:24 <richlowe> in this case, I could check for entire symbols disappearing for the thing that actually tripped me
23:16:42 <richlowe> but I'm not sure there's an easy automatic way to find things that don't remove whole symbols, beyond what you suggest :\
23:17:31 <tsoome_> lost public symbols should be discovered via linker maps, but local ones... 
23:18:49 <richlowe> but as you said, there's lots of bad code
23:19:41 <richlowe> I'm just wondering if I should get a head start on finding it :)