[illumos-gate] 16768 kernel printf should know about %j and %z size specifiers -- Toomas Soome <tsoome⊙mc>

now we can update gcc:)

I'll be happy to review that and get a release / tag cut.

[illumos-gate] 16821 loader: dosfs fails to access directory data with large cluster number -- Toomas Soome <tsoome⊙mc>

rmustacc, tsoome: I'd be interested to know which gcc to look at, for bringing the aarch64 stuff forward

currently gate compilers are 10 and 7

for next, I have been building with 14, they are almost the same in context of warnings

at the end we need the decision which one to pick because there is one fix which needs compiler parameter to be set and that parameter is available since gcc 12, so we do need to use _gccVERSION option to set it.

So I think my main question is what's the relative warning churn we need to deal with between 13 and 14 right now.

As I know 14 changed a number of defaults and K&R related bits.

I'd like to get to 14 and later, just want to be cogniscent and see if we can get rid of 7 shadow sooner.

I have a couple(?) unrelated points

.) I'd prefer a newer compiler sooner, chasing version numbers you never win

.) removing gcc 7 you can just do now

.) I'd love it if you when you upgraded, you sort of "contracted private" she shadow to me until I get arm fixed

s/she/the/

I guess all have stopped using 7 as primary?

Well, the reason I wanted to get to 14 was C23. So feature chasing versus version, but I agree getting to something sooner is better.

We require 10 as the primary.

if so, there is no need to use 7 for shadow

yeah, there's no use for 7 as shadow

It mostly has been kept as a courtesy to folks for a bit.

I think we left it as a courtesy, and then an extended courtesy

So right now we have an existing 13.x branch. I'm not sure of what our relative warning clean up is to get it to shadow status and what that versus 14 looks like.

just a moment, I'll push my 13 and 14 branches

github.com/tsoome/illumos-gate/tree/gcc13 github.com/tsoome/illumos-gate/tree/gcc14 and github.com/tsoome/illumos-gate/tree/gcc14-assfail last one is with assfail fix and dropped updates for vmm and smbsrv as assfail change fixes those.

So 13 and 14 are mostly similar if I'm reading that right (modulo assfail issues)?

yep

Given that, seems probably better to go shadow 14?

And Rich, I'm fine with the shadow request for ARM and holding that.

whichever works best as a shadow and encouraging testing as a primary seems best

also 14 does not seem to need -gstrict-dwarf

We can work through some of the dwarf / ctf bits once it's there in a shadow too.

So maybe andyf, you can work with tsoome to get a bring up branch for 14.2? I'll get a base bit pushed there in a bit.

with last reviews I should get those queues really short too

I seem to remember from when I was working on a prototype "new-style" saveargs, that strict-dwarf seemed preferable regardless

I don't remember why though :(

possibly just that it firmly matched what I was looking at with a standard I could read

and as I told Dan - I probably leave assfail as is [at leas for now] as Gordon is strongly opposing it. if it means few code changes, so be it.

tsoome: I don't think that's a good idea. I'm working on an IPD to cover some details on assertions.

well, it is blocking compiler update and we can easily revert the related changes once assfail is fixed.

Anyhow, I'm doing other remaining bits first;)

[illumos-gate] 16807 pcfs: writes to pcfs do not update fat on 4kn disks -- Toomas Soome <tsoome⊙mc>

Yes, I can help with getting the omnios 14.2 patches (or some other set) into an illumos branch.

andyf: don't suppose the arm branch merges that easy too?

not sure what omnios has done with that gcc, if anything.

14? Just carried forward the patches from 13 as far as I remember. The last illumos specific bit was "cmn_err() supports 'h' and 'hh'" which ended up in illumos/gcc 10 IIRC

With the arm branch, I don't think we've done anything apart from contribute the odd patch to your repo

ok