IRC channel logs

2023-02-11.log

back to list of logs

<fossy>doras: #242
<fossy>note that the checksums are not correct, so don't worry about that
<stikonas>clang can finish infinite loops in a few miliseconds :D https://paste.debian.net/1270331/
<fossy>.....
<fossy>uhhh
<stikonas>ok, I guess I can start reviewing
<fossy>stikonas: how did you come across that? i assume its a compiler bug
<stikonas>fossy: saw it on mastodon...
<stikonas> https://github.com/llvm/llvm-project/issues/60622
<fossy>haha, thats really cursed
<stikonas>apparently C++ spec says you can assume that loop that does not call library i/o or accesses variables terminates
<fossy>and no return, so it falls through to next symbol?
<stikonas>no, that's probably special casing
<stikonas>that "unreachable" is probably the only name that works
<stikonas>possibly internally there is unreachable: label added to function
<stikonas>and then jump to it? (but I'm guessing here, I didn't check)
<stikonas>fossy: can we move python-3.11 after GCC?
<stikonas>I guess file needs python, but should run fine with older pythons
<stikonas>looks good in general
<stikonas>I guess we need to backport your crc32 table rebuild to gcc 4.7.4
<stikonas>oh file is needed for that stripping...
<sam_>the issue is C++ requires forward-progress
<sam_>I don't really get the complaint in that bug tbh
<oriansj>stikonas: it doesn't just complete an infinite loop but also calls an uncalled function.
<doras>Thanks!
<mihi>sam_, stikonas: A C++ compiler is free to (1) remove unreachable statements (like the RET after an infinite loop), (2) remove any (possibly infinite) loops that show no observable behaviour. The (for me) surprising/unintuitive result is that Clang performs (1) before (2) although (2) falsifies the prerequisites of (1)
<mihi>But you can see similar behaviour with some gcc versions in -O2 too. Consider a struct s { int a[10]; int b[10] }. Now when running »for(int i=0; i<20; i++) { sum += s.a[i] }«, the compiler reasons that since i is used to access an array of size 10, it can never be 20 or higher, therefore the loop never terminates and it removes all statements after the loop (including the RET)
<mihi>yes, the snippet shows undefined behaviour, but in most cases the array access will not yet segfault (as there is another array in the struct), but the program will probably afterwards if it falls through to the next function without having cleaned up the stack.
<mihi>still, these are not compiler bugs (they are better than nasal deamons), yet a warning would be nice in cases like this.
<muurkha>these are awfully close to nasal demons
<stikonas>fossy: ready to merge? or is there still anything left (your PR is still in draft mode)
<fossy>stikonas: i think we're good now, i'll merge
<stikonas>ok
<stikonas>let's merge
<stikonas>I'm now testing readline, but it's not ready for PR yet...
<fossy>neat
<stikonas>I think I'll go for 8.0 (and not 8.2) as that can be built earlier
<stikonas>so we can build bash with it
<fossy>yeah, good idea
<stikonas>8.2 needs newer autoconf
<fossy>i was pleasantly surprised i could use the newest 'file'
<stikonas>fossy: could you also update GCC 4.7 to regen crc?
<fossy>stikonas: yep
<stikonas>I think 4.0.4 does not have it
<stikonas>or at least I didn't notice it with 30s check
<stikonas>I guess anything we add at the end of sysc can be basically the latest now
<fossy>yeah, it should be, which is very nice :D
<stikonas>(at least normal stuff that doesn't need extra bootstrapping)
<stikonas>though I guess we won't actually need to add much more stuff to the end of live-bootstrap...