IRC channel logs

<deesix>janneke, please consider https://paste.debian.net/plainh/af99917e/ for mes, to fix `lib/tests/dirent/90-readdir.c` on x86_64.

<deesix>As you can see in `gcc-lib/lib/tests/io/90-stat.2` there're some bogus values, including `st_blksize`. That was causing a big allocation in opendir (it goes unnoticed if enough memory but it's making the test fail here). I took the struct from upstream and adjusted types ('s/__kernel_ulong_t/unsigned long/' and 's/__kernel_long_t/long') and format (to follow the actual one in the file, with tabs,

<deesix>etc) so the diff is as clean as possible.

<deesix>While debugging that, I noticed that `build-aux/test-c.sh` has bashisms or something, but its shebang is /bin/sh so it was not working as expected.

<janneke>deesix: thanks

<deesix>janneke, sure! I'm also seeing 30+ fails when using the cross-compiler that guix shell setups (for x86)... I'm working around them with a flag, because they are all about the same thing. What's your take on that?

<deesix>This seems about gcc 14 being more picky because older (from the host) versions (I tried 12) does not produce the warning->error.

<deesix>-Wnoincompatible-pointer-types does the trick, but it would hide real problems, of course.

<janneke>deesix: i don't see the bashisms though, afaics dash handles test-c.sh OK?

<janneke>deesix: nope, i don't believe that's a problem; gcc-14 is overly strict

<deesix>janneke, I was doing something like the proposed in some doc file... (cd gcc-lib/ && V=2 ../pre-inst-env test-c.sh ../lib/tests/dirent/90-readdir.c)

<deesix>And it fails with ...test-c.sh: 57: Bad substitution

<deesix>But calling bash explicitly fixes it:

<deesix>(cd gcc-lib/ && V=2 ../pre-inst-env bash -x test-c.sh ../lib/tests/dirent/90-readdir.c)

<janneke>deesix: whac kind of shell are you using?

<janneke>*what

<deesix>janneke, dash I guess; /bin/sh it does not respond to --version or the like and man sh gives me dash.

<janneke>deesix: hmm, i'm pretty sure i tested with dash

<janneke>weird

<deesix>Does a like like that fail for you too?

<deesix>*line like

<janneke>hmm, line 57 seems to fail now for me

<janneke>yep, breaks for me too; so thanks again

<deesix>My pleasure.

<janneke>esp. the kernel-stat bug is weird

<janneke>i'm wondering what that might fix, ekaitz?

<janneke>and maybe my dismissal of gcc14 warnings was a bit too unthoughtful

<janneke>we'll at least want to take a look at them

<deesix>git grep "This breaks" is interesting, maybe the patch helps there?

<janneke>that's certainly interesting given that the 6bit kernel-stat.h was somehow wrong

<janneke>...which still puzzles me

<janneke>although, finding the right files in the kernel tree can be a real pain

<deesix>Yeah, I failed a couple of times :D

<janneke>so yeah, chances are hte other 64bit structs are also wrong and fixing them would fix "This breaks"

<deesix>The riscv one got some love in 7262ef89f136ece8b66116e8abbf080914920dc3

<janneke>deesix: interesting, let's see if we can have this ekaitz person to look into this some time

<janneke>and let's see if this janneke person can find more time to hack on nice things some time soon

<deesix>Thanks! One last question for now if I may... I was head scratching for a while until we realized the upstream wip branch was behind your wip branch (which I was not aware of, as it's not in the docs)... is that common, to be desync?

<deesix>In this case, upstream was lacking some fixes and failing, but ekaitz could not reproduce xD

<deesix>*reproduce the fail I was seeing

<deesix>Maybe a better question is... is there some policy about what goes where, repo-wise?

<janneke>i'm afraid i don't know

<deesix>OK, I'll keep an eye on both of them, just in case.

<ekaitz>janneke: copy from musl

<ekaitz>the best we can do is that

<ekaitz>that's how we fixed the riscv case

IRC channel logs

2025-04-21.log