kbkpbot

The generated C code as follow: ```c // assert1: assert u64(-1) == 18446744073709551615 // this one passes if (!(((u64)(-1)) == 18446744073709551615U)) {} // assert2: assert f64(u64(-1)) == u64(-1) // this...

This bug is related to how V(c gen) operate on string. For example: ```v VV_LOCAL_SYMBOL void main__leak_test(main__MyLeak* leak) { string _t1 = str_intp(1, _MOV((StrIntpData[]){{_SLIT("&"), 0xfe10 ,{.d_s = isnil(leak) ? _SLIT("nil")...

change ```v net.listen_tcp(.ip6, ':8081') ``` to ```v net.listen_tcp(.ip, ':8081') ``` The same panic.

If comment out `s.set_dualstack(options.dualstack) or {}` in vlib/net/tcp.c.v `pub fn listen_tcp`, then has no this bug.

`v test.v -cc clang -prod` this is ok (Ubuntu clang version 14.0.0-1ubuntu1.1) `v test.v -cc gcc -prod` this will panic(gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)) .

```sh gcc -fwrapv -O2 -flto -DNDEBUG "/home/mars/.vmodules/cache/76/769009b5e03b3475e2b1f9c2b837a8b2.module.builtin.o" -o "/home/mars/v/wrk/test" -D GC_BUILTIN_ATOMIC=1 -D GC_THREADS=1 -I "/HD/github/kbkpbot/v/thirdparty/libgc/include" "/tmp/v_1000/test.tmp.c" -std=gnu99 -D_DEFAULT_SOURCE -ldl -lpthread ``` compile will show warning, and the test is OK...

After some tests, I found that in `-prod` mode, after `s := new_tcp_socket()` in `fn listen_tcp()`, `s.handle` will become ZERO. This will cause following operations on socket `s` fail. Not...

By disassemble the `./test` file, it shows that `gcc -O3 -flto` generate wrong instruction sequence. At 0000564A60BA76FC , it read `handle` into ebx (which is ZERO), then use `rep movsd`...

Something interesting, after apply this PR, v self compile time become 8x slower..... (just overwrite the `v/thirdparty/stdatomic/nix/atomic.h`) Before apply PR: ```sh ~/github/kbkpbot/v/thirdparty/stdatomic/nix$ time v self V self compiling ... V...

> @kbkpbot thanks for the work you put into this! Quite a bit of changes, that's for sure. > > When you were compiling, did you have to specify the...