<v​yom00907:matrix.org> monero.stackexchange.com/questions/…en-some-keywords-and-thier-function

<v​yom00907:matrix.org> need help with this i already posted question on stack

<0​xfffc:matrix.org> How we can assign label to issues and PRs?

we used to have a label bot that a bunch of contributors had access to, not sure if that still exists

doesn't look like it's been used since 2018, but pigeons would know if it's easy to resuscitate it

<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.

<0​xfffc:matrix.org> (Those I have commented, few of them are not reproducable.)

<v​yom00907:matrix.org> i am unable to understand what is

<v​yom00907:matrix.org> the refrence cpu and SuperScaler hash program and the vm of RandomX

<v​yom00907:matrix.org> HOW THE PROGRAMMS ARE RUN ON RXVM

<v​yom00907:matrix.org> WHAT IS ROLE OF SUPERSCALAR

maybe search github.com/tevador/RandomX/blob/master/doc/design.md for "SuperscalarHash" and read what's written there.

0xfffc: we have a couple people added on github to the org that can close issues and add labels

so basically the bot was replaced by github having this function natively

I can add labels if you point out where

<0​xfffc:matrix.org> selsta: great. thanks. I will mention you in few. Of the top of my head there was this one: monero-project/monero #8912

<0​xfffc:matrix.org> There were 5,6 more that I personally tested. Will send you the list. Hopefully that is okay.

8912 appears to be a compiler bug

<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.

not much we can do from our side apart from reporting it upstream if it is reproducible

which label should I add?

<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.

<0​xfffc:matrix.org> Or wontfix (since we are not able to reproduce)

<0​xfffc:matrix.org> There is this one too:

<0​xfffc:matrix.org> monero-project/monero #8973

<0​xfffc:matrix.org> I would suggest "pending review" or "low priority"

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

<0​xfffc:matrix.org> I would label this one : monero-project/monero #8732 as "improvement" or "enhancement" . I have fix for this will send the PR soon.

<0​xfffc:matrix.org> Great. Very good approach. But for "improvement" s or others would not work I believe.

<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 :))

I reproduced 8912 with 0.13.0 fwiw.

<0​xfffc:matrix.org> selsta: This one needs investigation monero-project/monero #8725 "help wanted" do you think is appropriate?

<0​xfffc:matrix.org> moneromoooo: Oh great. Can you run it with this flag? monero-project/monero #8912#issuecomment-1714353812

<0​xfffc:matrix.org> I can take a look at the GCC codebase. It happens at parser level it seems.

<0​xfffc:matrix.org> selsta: This one needs more info monero-project/monero #8680

<0​xfffc:matrix.org> selsta: this one needs investigation. monero-project/monero #8742 user was able to find a scenario that would prevent memory leak

townforge.net/epee_boosted_tcp_server.cpp.i.bz2 (will be deleted next time I update the website).

<0​xfffc:matrix.org> moneromoooo: Thanks a lot. I will take a look at right now.

<0​xfffc:matrix.org> selsta and for PR's "pending review" is most helpful label.

Compiler bugs are not rare, especially if you experiment with new compiler releases and have some big codebase to play with

fresh example: 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

<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)

Why do you think this one is hit easily ? I assume you do not mean "reprodicibly" here.

Anyway, it's clearly an ICE, it reports so.

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: SChernykh/p2pool #274#issuecomment-1704334180

<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.

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

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).

This one still ICEs with -O0 fwiw.

<0​xfffc:matrix.org> Familiar with mid level optimization. Not much with frontends though. But I will give it a shot to debug.

Thanks.

I can test a patch since you can't repro. I built it.

<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

<0​xfffc:matrix.org> Thanks. Will DM you

<0​xfffc:matrix.org> (moneromoooo: matrix bridge has problem opening DM to IRC users, will contact you soon)

yes, no DM's are possible Matrix <-> IRC , must be IRC <-> IRC

oops, ignore my echo^

jeffro256: the recent `store_to()` PR seems to cause an issue with the GUI, here are steps to reproduce: paste.debian.net/1292732

you have to update the monero submodule to `release-v0.18` when testing

I'm not sure if it's a bug in the `store_to()` PR or the GUI itself

Wallet initialization failed: file /home/test/Monero/wallets/test/test_viewonly does not correspond to /home/test/Monero/wallets/test/test_viewonly.keys

<j​effro256:monero.social> Okay I’ll take a look at it! Thanks selsta

Myself, yes. I built it from the 13.1.0 tarball.

linux x86_64

Bog standard config IIRC.

Found it: ../configure --prefix=/home/user/gcc13.1/ --program-prefix gcc13- --disable-gcov --disable-multilib --enable-languages=c,c++ --disable-libada

<0​xfffc:matrix.org> Awesome. Will try it in few hours once I get back to home