IRC channel logs

<aleksih>Hi! In mescc 0.27.1, is it expected that scaffold/16-cast.c from the test suite fails on riscv64?

<aleksih>To me, the output asm seems to be doing a 64-bit comparison of a signext'd -1 (in .c, integer literal) and zeroext'd -1 (in .c, a local var of type "unsigned")

<stikonas>ekaitz: do yo remember?

<stikonas>aleksih: I wouldn't be surprised if it does fail. I seem to remember some issues with it

<stikonas>but not 100% sure now

<ekaitz>I don't remember that either

<ekaitz>let me take a look aleksih

<stikonas>I think we were mostly focusing on building tinycc with it

<stikonas>and didn't look too much at tests

<ekaitz>well I wrote that file actually

<ekaitz>aleksih: it might be that one commit is missing

<stikonas>and if you want to build tcc, I think you need ot revert one commit in tcc

<ekaitz>52dcdc77b1dcf488f1fe76ff88961ce81ceb52ea was added later

<stikonas>need to revert this revert: https://gitlab.com/janneke/tinycc/-/commit/ea3900f6d5e71776c5cfabcabee317652e3a19ee

<ekaitz>but this test issue we should check janneke and I

<aleksih>Thanks :)

<ekaitz>aleksih: you can also fix it yourself if you want. Feel free to send us patches!

<aleksih>Sure! I have been looking at the mescc codebase for a while and I'm a little lost on how mescc could tell (once it starts to compile the "ne" expression) what type of integer is stored in a temporary register

<aleksih>As far as I can tell, integer literals are parsed and go into r0, but any U/UL/L/LL/etc is erased, which would limit the ability to correctly compile e.g. `(unsigned int)-1 != -1LL` as opposed `(int)-1 != -1LL`

<aleksih>(or as opposed to `(unsigned int)-1 != -1`)

<aleksih>These are all edge cases of course, but I think if I can understand how this type logic could be handled in mescc in general, then I might be able to work toward a patch

<ekaitz>hmm... i am working more on mes than in mescc so I don't remember how that works :)

<ekaitz>i made the test case you mentioned, so... maybe there are few extra commits that affect it

<aleksih>Thanks, I will be checking the history as well

<aleksih>Oh and btw, is Codeberg the preferred place to send patches?

<ekaitz>aleksih: in fact you should use the mailing list as described in GNU's website. The gnu mes codeberg is my personal clone

<ekaitz>aleksih: if you do it in codeberg i'll deal with the patch, no problem

<janneke>aleksih: have you looked at my gitlab's wip-bootstrap-x86_64 branch?

<janneke>it's not ready for release, but if you're looking/working at x86_64, you'll probably want to take a look at it

<stikonas>what's the state of that branch these days?

<stikonas>I guess the goal is to build upstream tcc directly?

<stikonas>skipping that older pre 0.9.27 fork?

<janneke>stikonas, thats'th goal and is has already many x86_64 fixes

<stikonas>I should try it at some point though recently didn't have much spare time for bootstrapping work...

<janneke>me neither, i'm planning this work for some time in spring

<janneke>but i don't want aleksih to be stalled for that or re-figure things out that might be fixed

IRC channel logs

2026-01-21.log