08:04:10 <m-relay> <v​yom00907:matrix.org> https://monero.stackexchange.com/questions/14066/unable-to-understand-the-diffrance-between-some-keywords-and-thier-function
08:04:49 <m-relay> <v​yom00907:matrix.org> need help with this i already posted question on stack
08:54:47 <m-relay> <0​xfffc:matrix.org> How we can assign label to issues and PRs?
10:01:43 <fluffypony> we used to have a label bot that a bunch of contributors had access to, not sure if that still exists
10:03:15 <fluffypony> doesn't look like it's been used since 2018, but pigeons would know if it's easy to resuscitate it
10:12:03 <m-relay> <0​xfffc:matrix.org> I really believe we have to revive that IMHO. I personally know (and commented) on multiple issues that needs reproduction from user side. Few of them I have tried myself. I wish Monero community would revive that label.
10:12:36 <m-relay> <0​xfffc:matrix.org> (Those I have commented, few of them are not reproducable.)
12:00:11 -xmr-pr- edge7 opened issue #8997: monerod connection count vs RPC get_info call
12:00:11 -xmr-pr- > https://github.com/monero-project/monero/issues/8997
13:02:55 <m-relay> <v​yom00907:matrix.org> i am unable to understand what is
13:02:55 <m-relay> <v​yom00907:matrix.org> the refrence cpu and SuperScaler hash program and the vm of RandomX
13:02:55 <m-relay> <v​yom00907:matrix.org> HOW THE PROGRAMMS ARE RUN ON RXVM
13:02:56 <m-relay> <v​yom00907:matrix.org> WHAT IS ROLE OF SUPERSCALAR
13:05:41 <sech1> maybe search https://github.com/tevador/RandomX/blob/master/doc/design.md for "SuperscalarHash" and read what's written there.
17:01:26 <selsta> 0xfffc: we have a couple people added on github to the org that can close issues and add labels
17:02:10 <selsta> so basically the bot was replaced by github having this function natively
17:02:25 <selsta> I can add labels if you point out where
17:04:27 <m-relay> <0​xfffc:matrix.org> selsta: great. thanks. I will mention you in few. Of the top of my head there was this one: https://github.com/monero-project/monero/issues/8912
17:04:56 <m-relay> <0​xfffc:matrix.org> There were 5,6 more that I personally tested. Will send you the list. Hopefully that is okay.
17:05:22 <selsta> 8912 appears to be a compiler bug
17:08:19 <m-relay> <0​xfffc:matrix.org> Needs reproduction. It is very rare to hit compiler bug that easily. I have same configuration and I am able to compile without issue.
17:08:30 <selsta> not much we can do from our side apart from reporting it upstream if it is reproducible
17:09:22 <selsta> which label should I add?
17:10:51 <m-relay> <0​xfffc:matrix.org> I  totally agree. So closing it or labeling it would be a rational thing.  I would suggest something like pending review.
17:11:12 <m-relay> <0​xfffc:matrix.org> Or wontfix (since we are not able to reproduce)
17:11:16 <m-relay> <0​xfffc:matrix.org> There is this one too:
17:11:43 <m-relay> <0​xfffc:matrix.org> https://github.com/monero-project/monero/issues/8973
17:12:22 <m-relay> <0​xfffc:matrix.org> I would suggest "pending review" or "low priority"
17:13:03 <selsta> I usually just simply close the issue if the reporter does not reply, if they continue to have issues it can be reopened or they can create a new one
17:13:15 <m-relay> <0​xfffc:matrix.org> I would label this one : https://github.com/monero-project/monero/issues/8732  as "improvement" or "enhancement" . I have fix for this will send the PR soon.
17:13:56 <m-relay> <0​xfffc:matrix.org> Great. Very good approach. But for "improvement" s or others would not work I believe.
17:14:27 <m-relay> <0​xfffc:matrix.org> I usually go over issues over and over on my spare time. Helps me to get more familiar with codebase. That is why I am pushing this labeling approach :))
17:16:43 <moneromooo> I reproduced 8912 with 0.13.0 fwiw.
17:19:20 <m-relay> <0​xfffc:matrix.org> selsta: This one needs investigation https://github.com/monero-project/monero/issues/8725 "help wanted" do you think is appropriate?
17:19:48 <m-relay> <0​xfffc:matrix.org> moneromoooo: Oh great. Can you run it with this flag? https://github.com/monero-project/monero/issues/8912#issuecomment-1714353812
17:20:34 <m-relay> <0​xfffc:matrix.org> I can take a look at the GCC codebase. It happens at parser level it seems.
17:23:21 <m-relay> <0​xfffc:matrix.org> selsta: This one needs more info https://github.com/monero-project/monero/issues/8680
17:25:27 <m-relay> <0​xfffc:matrix.org> selsta: this one needs investigation.  https://github.com/monero-project/monero/issues/8742 user was able to find a scenario that would prevent memory leak
17:26:41 <moneromooo> https://townforge.net/epee_boosted_tcp_server.cpp.i.bz2  (will be deleted next time I update the website).
17:27:29 <m-relay> <0​xfffc:matrix.org> moneromoooo: Thanks a lot. I will take a look at right now.
17:32:13 <m-relay> <0​xfffc:matrix.org> selsta and for PR's "pending review" is most helpful label.
17:36:42 <sech1> Compiler bugs are not rare, especially if you experiment with new compiler releases and have some big codebase to play with
17:37:36 <sech1> fresh example: https://github.com/llvm/llvm-project/releases/tag/llvmorg-17.0.1 "Note that LLVM 17.0.0 was withdrawn due to an issue, please use 17.0.1 instead." :D
17:43:00 <m-relay> <0​xfffc:matrix.org> Yes, they are not rare. But it is rare to hit one that easily. Because compilers are usually extensively tested. (should be at least in theory)
17:44:10 <moneromooo> Why do you think this one is hit easily ? I assume you do not mean "reprodicibly" here.
17:44:52 <moneromooo> Anyway, it's clearly an ICE, it reports so.
17:46:15 <sech1> Extensively tested? I wouldn't say so. I had a lot of issues with p2pool binaries recently, because of a compiler bug with link-time optimization: https://github.com/SChernykh/p2pool/issues/274#issuecomment-1704334180
17:47:19 <m-relay> <0​xfffc:matrix.org> Sure. I have to debug to see where it happens. But it is subjective. I would say it happens very easily if your compiler is not able to compile a well known codebase (Monero) that has been compiling for years. Now suddenly it crashes.
17:48:08 <moneromooo> I don't know what your level of familiarity with the GCC code is, but it is a difficult beast to hack on. I personally would file a bug rather than debug it myself :D
17:48:44 <sech1> LTO and high optimization levels are a can of worms in GCC/clang. Most compiler bugs are found there (sometimes it's internal compiler error, sometimes it's incorrect code generated).
17:50:20 <moneromooo> This one still ICEs with -O0 fwiw.
17:51:16 <m-relay> <0​xfffc:matrix.org> Familiar with mid level optimization. Not much with frontends though. But I will give it a shot to debug.
17:51:35 <moneromooo> Thanks.
17:52:15 <moneromooo> I can test a patch since you can't repro. I built it.
17:57:27 <m-relay> <0​xfffc:matrix.org> Did you build the gcc yourself? I would appriciate if you give me the commit that you were building on it
17:57:32 <m-relay> <0​xfffc:matrix.org> Thanks. Will DM you
18:31:33 <m-relay> <0​xfffc:matrix.org> (moneromoooo:  matrix bridge has problem opening DM to IRC users, will contact you soon)
18:45:24 <plowsof> yes, no DM's are possible Matrix <-> IRC , must be IRC <-> IRC
18:46:00 <plowsof> oops, ignore my echo^
18:47:19 <selsta> jeffro256: the recent `store_to()` PR seems to cause an issue with the GUI, here are steps to reproduce: https://paste.debian.net/1292732/
18:47:39 <selsta> you have to update the monero submodule to `release-v0.18` when testing
18:47:53 <selsta> I'm not sure if it's a bug in the `store_to()` PR or the GUI itself
18:48:41 <selsta> Wallet initialization failed: file /home/test/Monero/wallets/test/test_viewonly does not correspond to /home/test/Monero/wallets/test/test_viewonly.keys
19:42:12 <m-relay> <j​effro256:monero.social> Okay I’ll take a look at it! Thanks selsta
19:50:28 <moneromooo> Myself, yes. I built it from the 13.1.0 tarball.
19:50:47 <moneromooo> linux x86_64
19:50:56 <moneromooo> Bog standard config IIRC.
19:54:00 <moneromooo> Found it: ../configure --prefix=/home/user/gcc13.1/ --program-prefix gcc13- --disable-gcov --disable-multilib --enable-languages=c,c++ --disable-libada
20:23:13 <m-relay> <0​xfffc:matrix.org> Awesome. Will try it in few hours once I get back to home