dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
<Entei[m]> Just checking out the gcc rebuild the next day, I seriously doubt allocating 20 cores increased the performance....Any way to heck measure the impact? It seems to be using not more than 2-4 cores at a time, all other cores are almost idle most of the time
<Entei[m]> s/heck//
<Entei[m]> I was expecting a package like gcc would saturate all cores to max utilisation, instead I see qemu having not more than 200% cpu load
<Entei[m]> Oh very quick update. All 20 cores just lit up.
<davidlt[m]> It's probably configure stuff, which is basically a single thread.
<davidlt[m]> During those times, QEMU is slow compared to the boards.
<Entei[m]> davidlt[m]: Yeah it's snail pace. Would really like to see better boards(with more cores) soon for building purposes and setting up Koji.
<davidlt[m]> 64 core should be available soon.
<davidlt[m]> TBD if that is actually faster.
<davidlt[m]> Oh, there will be a new GCC 13 build in the F38.
<Entei[m]> What's the xgcc thing in the build process? My senior said gcc compiles in 3 stages. But I made sure all bootstrapping was disabled...
<davidlt[m]> That's a gcc already built IIRC.
<Entei[m]> davidlt[m]: So `xgcc` is my system's preinstalled gcc?
<davidlt[m]> No, it's built part of the build process IIRC.
<dtometzki> Hello what i see xgccc will build in the first stage
<davidlt[m]> > @itemize @bullet
<davidlt[m]> > @item @code{./xgcc -B.}
<davidlt[m]> > is the usual way to invoke a self-built GCC from within the @file{BUILDDIR/gcc}
<davidlt[m]> > subdirectory.
<Entei[m]> So the preinstalled gcc builds `xgcc`, which in turn builds the proper gcc (with specified language support). Is that correct?
<Entei[m]> How exactly is this different from bootstrapping then?
<davidlt[m]> I am not a GCC developer, but IIRC xgcc is a symlink to allow using GCC built it the last stage.
<davidlt[m]> So you have 1 stage, you build a GCC, you use it (xgcc) and build all the libraries, etc.
<davidlt[m]> At the install time it will be installed as gcc in the final location.
<davidlt[m]> it's just that during the build process you need to refer to the last built GCC. You cannot use system GCC to build, e.g. standard C++ library.
<Entei[m]> <davidlt[m]> "it's just that during the..." <- Ahh! That makes sense, then it would be no different otherwise. I am building for `rv64g`, and simply building the libraries with system compiler would result in libraries with `rv6gc`.
<Entei[m]> In other cases this would result in complete ABI changes for libraries.
jednorozec has quit [Server closed connection]
jednorozec has joined #fedora-riscv
jcajka has joined #fedora-riscv
<davidlt[m]> A new stable 6.3 kernel landed. Incl. a couple of RISCV patches.
diagprov has joined #fedora-riscv
unlord has quit [Ping timeout: 240 seconds]
unlord has joined #fedora-riscv
masami has joined #fedora-riscv
sajcho has joined #fedora-riscv
<sajcho> I'm sorry to bother you. Is there something wrong with this gcc build configuration? https://github.com/sajcho/core-riscv64/blob/main/gcc/Pkgfile. Thank you for the critical comment.
<davidlt[m]> <sajcho> "I'm sorry to bother you. Is..." <- Let me try to check.
<davidlt[m]> It seems okay, but without testing it would be hard to be 100% sure.
droidrage has quit [Ping timeout: 246 seconds]
<sajcho> Thank you.
sajcho has quit [Quit: Client closed]
masami has quit [Quit: Leaving]
zsun has joined #fedora-riscv
<davidlt[m]> MilkV Pioneer is at V1.1 right now IIUC.
<thefossguy> I assume if that's a standard extension, toolchain support isn't the headache/responsibility of the hardware vendor (for the very initial stages).
<davidlt[m]> M?
<thefossguy> what's that?
<davidlt[m]> Didn't understand the "standard extension" part. Maybe I missed something.
<thefossguy> I mean an extension that is ratified by the RISC-V foundation
<davidlt[m]> Which one?
<thefossguy> Not a vendor (read: proprietary) extension nor an extension that hasn't been ratified
<thefossguy> I meant to ask that for RVV 1.1 :D
<davidlt[m]> No, it's Version 1.1 :)
<davidlt[m]> Not vector stuff :)
<thefossguy> So, since it's an "open standard extension", I assume the vendor doesn't need to send patches upstream before the hardware reaches the hands of their customers but the stuff still works?
<thefossguy> davidlt[m]: Oh, my bad XD
<davidlt[m]> Well it's IP/SoC/CPU vendors that work on open source implementation.
<davidlt[m]> RVI doesn't do that.
<thefossguy> Ah, gotcha
<thefossguy> Well not exactly a gotcha but now I know which rabbit hole to go down into :D
<davidlt[m]> This is one of the reasons why we have https://riseproject.dev/
jcajka has quit [Ping timeout: 246 seconds]
jcajka has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
fuwei has quit [Read error: Connection reset by peer]
fuwei has joined #fedora-riscv
guerby__ is now known as guerby
<davidlt[m]> nirik: rwmjones: do we have ABI reports in Fedora running?
<davidlt[m]> IIRC fedabipkgdiff, libabigail, etc.
<nirik> CI runs those on bodhi updates, yeah...
<davidlt[m]> nirik: where could I see some reports?
<nirik> to pick some random update, go to https://bodhi.fedoraproject.org/updates/FEDORA-2023-48847ce601 and click on 'automated tests'
<nirik> well, I guess I could pick a critpath one, they get more...
<davidlt[m]> but I don't see any ABI reports
<davidlt[m]> Don't we run ABI check vs. the current tagged build in the repo?
<nirik> it's under rpminspect?
<davidlt[m]> Yeah, now I see it.
<davidlt[m]> It's just boring that "OK" means produce no reports :)
<davidlt[m]> Does this list also applies to COPR repos?
<nirik> nope, I don't know of any testing on copr repos... there might be some, but I am not aware of it.
<nirik> The #buildsys:fedoraproject.org room would know (thats where copr folks hang out)
jcajka has quit [Quit: Leaving]
<davidlt[m]> Not that important right now, but I joined the channel :)
<nirik> BTW, should I look at upgrading my builder to f38? or is that still waiting on images/some packages/more time?
<davidlt[m]> Wait
<davidlt[m]> The next disk image.
<nirik> ok, no worries, just wondering. ;)
aurel32 has quit [Quit: leaving]
aurel32 has joined #fedora-riscv