clang build : weird output

[TheFausap]

Hello, I built k using the standard clang compiler available under MacOS Ventura.

Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: x86_64-apple-darwin22.4.0

and I got no errors during the build phase. But, in some case, I get some weird ascii chars output on the screen and not the proper output.

For example, running: ./k q.k t2.k (where q.k is available -not the latest version at the moment, but it's not relevant for this error- at https://gist.github.com/TheFausap/1e16bee4b1f2e5224a408e87b1014083)

and t2.k is basically:

K00:ts[K0;K0]
A:ts[K00;K00]
B:ts[K00;K00] 

if I want to print the state K00: and it should be |00> in standard notation, I have instead on the screen:

ktye/k
 K00
`ket|1 0 0 0
 pst K00
(1;"|�>")

if I am using the same files, but the binary is compiled using GCC under Linux (RockyLinux 9.1) I have the correct result.

ktye/k
 K00
`ket|1 0 0 0
 pst K00
(1;"|00>")

Is this expected with clang?

regards, Fausto

[ktye]

no that is not expected.

you can convert the string to integers to see what character that is:

r:pst K00
0+r[0;1]     /should be: 124 48 48 62

pst prints as a list (1;"..") but it is actually enlisted:

,(1;"|00>")

you can prepand a space in the repl to force the k-string single-line output.

[TheFausap]

thanks... the prepended space is very nice idea :)

anyway, the string conversion is quite interesting

 pst K00
(1;"|�>")
 r:pst K00
 0+r[0;1]
124 -96 62

maybe something related to the size of the types?

[ktye]

you can also try to run the unit tests and see if/where they fail:

k k.t

k.t is in the main repository if everything is ok, the last lines are:

"256 256\\\\3 /0 3"
"3 4\\\\128 /2 0"
"24 60 60\\\\3723 /1 2 3"
ktye/k

[TheFausap]

good point, I didn't try them It seems there is a more general problem

❯ ./k k.t
"1 /1"
"1.1 -0w /1.1 -0w"
"1. 0n 0w -1.1 /1. 0n 0w -1.1"
"1. 0n 0w -1.1 -0w -0n 2p .5p /1. 0n 0w -1.1 -0w 0n 6.283185 1.570796"
"1. /1."
".1 /0.1"
"1.1 /1.1"
"1a /1a"
"1a 2a20 0a 1.0a 1.a 0na 0wa 1a90 2a180 3a270 /1a 2a20 0a 1a 1a 0na 0wa 1a90 2a180 3a270"
"1a90 /1a90"
"1e2 1e+2 1e-2 1.23e3 -12.e2 /100. 100. 0.01 1230. -1200."
"1.3e3a20 /1300a20"
"1000000. 1.234e-8 -1e50 /1.e6 1.234e-8 -1.e50"
"1.+2. /3."
"1 2+3 /4 5"
"1+2 3 /3 4"
"1 2+3 4 /4 6"
"(1;2;3) /1 2 3"
"(+/!20)~+/.\"(\",(\";\"/:$!20),\")\" /1"
"(+/!3000)~+/.\"(\",(\";\"/:$!3000),\")\" /1"
"(`a`b!1 2;`a`b!3 4) /+`a`b!(1 3;2 4)"
"(`a`b!1 2;`a`c!3 4) /(`a`b!1 2;`a`c!3 4)"
"-(1 2 3) /-1 -2 -3"
"-(1;2 3) /(-1;-2 -3)"
"0x /\"\""
"0x6162 /\"ab\""
"0x6162,\"ab\" /\"abab\""
"@0x61 /`c"
"0x0a /\"\\n\""
"x:1;0x6162x /\"b\""
"#\"abc\\n\\r\\t\\\\\\\"9\" /9"
"\"abc\\n\\r\\t\\\\\\\"9\" /\"abc\\n\\r\\t\\\\\\\"9\""
"0+\"\\t\\n\\r\\\"\\\\\" /9 10 13 34 92"
"\"a\"+_!3 /\"abc\""
"0+\"⍴\" /-30 -115 -76"
"0+*\"⍴\" /-30"
"- 0 1 0 1 /0 -1 0 -1"
"0+-_-1 2 3 /1 -2 -3"
"0+abs@_-3 2 0 3 /3 2 0 3"
"abs -3 0 2 /3 0 2"
"abs'-3 0 2 /3 0 2"
"\"efg\"+_1 2 3 /\"fhj\""
"\"efg\"-_1 2 3 /\"ddd\""
"1 2 3.+4 5 6 /5. 7. 9."
"1a45 5a60 3a45+3a45 5a300 6a45 /4a45 5a 9a45"
"\"a\"-_32 /\"A\""
"0+\"a\"-\"ABC\" /32 31 30"
"1 2-8 7 /-7 -5"
"3.0-2. /1."
"3.0-2 3. /1. 0."
"3-3a60 3a /3a300 0a"
"6a300-6a /6a240"
"(_2)*\" !\\\"\" /\"@BD\""
"(_2 3)*\" !\" /\"@c\""
"2*(1 2.;1a45 2a45;0#0.;!0) /(2. 4.;2a45 4a45;0#0.;!0)"
"(0#0.)%3. /0#0."
"(!0)*!0 /!0"
"1a45 2a45*2 /2a45 4a45"
"4%1 2 3 4 5 /4 2 1 1 0"
"4/1 2 3 4 5 /1 2 3 0 1"
"(3+!6)%1+!6 /3 2 1 1 1 1"
"3%4 5 6. /0.75 0.6 0.5"
"3 4%5 8. /0.6 0.5"
"2 3.%2 /1. 1.5"
"3 4%1a20 /3a340 4a340"
"2%1a45 1a315 /2a315 2a45"
"1a45 2%1a45 1a315 /1a 2a45"
"abs[3a45;4.] /5."
"abs[(3.;3a45);4.] /5. 5."
"1a /1a"
".\"1+2\" /3"
"+/1_.\"(!0;\",(\";\"/:$!20),\")\" /190"
".() /"
"`2 /+"
"`1+(+) /-"
"(+)+1 /3"
"(+)+\"a\" /\"c\""
"`211 /@"
"`(+)+448 /+"
"`(+)+128 /+"
"`257 /`257"
"`t\"1+2\" /(1;+;2)"
"0+`t\"1+ \\\\2\" /1 2 29 2"
"`p\"1+2\" /(2;1;+)"
"`p `t\"1+2\" /(2;1;+)"
"+[2;] /2+"
"+[;2] /+[;2]"
"+/[1 2;] /1 2+/"
"{x+y*z}[;1 2;] /{x+y*z}[;1 2;]"
"{(x;y;z)}/[1;2 3 4;5 6 7] /((1 2 5;3;6);4;7)"
"({(x;y;z)}/[1;;])[2 3 4;5 6 7] /((1 2 5;3;6);4;7)"
"{[x;y;z]x}/[(0#`)!0#`;!4;10*!4] /(0#`)!0#`"
"{x+y+z}'[1 2 3;4 5 6;7 8 9] /12 15 18"
"{x+y+z}'[1 2 3;4 5 6;][7 8 9] /12 15 18"
"(1+)3 /4"
"(1 2+)3 /4 5"
"f:-;(f@)3 /-3"
"f:{x+y};f 3 /{x+y}[3;]"
"({x+y}3)4 /7"
"(({x+y+z}3)4)5 /12"
"({x+y+z}3)4 /{x+y+z}[3;4;]"
"({x+y+z}[;1;])[;2] /{x+y+z}[;1;2]"
"{[a;b]a+b}[1;2] /3"
"{[alongname;z]alongname+2*z}[3;4] /11"
"{[a]a} /{[a]a}"
"(.{[]x+y})3 /0"
"(.{a+b})3 /0"
".(1;2;`66) /3"
"(.{[]s:1+s:1})1 /,`s"
"*.{`x`y:1} /(1;`x`y;`64)"
"{x+y*z}/[1;2 3;4 5] /24"
"{(x+y*z)}/[1;2 3 4;5] /46"
"{(x+y*z)}/[1;2 3;4] /21"
"({x+y*z}/[1;2 3;])4 5 /24"
"{x+y*z}\\[1;2 3;4 5] /9 24"
"({x+y*z}\\[1;2 3;])4 5 /9 24"
"@,{1+x} /`L"
",{1+x} /,{1+x}"
"1 /1"
"`x /`x"
"``x /``x"
"`\"a\" /`a"
"\"\" /\"\""
"\"3\" /\"3\""
"1+2 /3"
"1-2 /-1"
"3.1-2.2 /0.9"
"1 2 3+4 /5 6 7"
"1 2 3+4a /5a 6a 7a"
"1-2 3 /-1 -2"
"1 2+(3;4 5) /(4;6 7)"
"0+0 0 1 /0 0 1"
"3+`a`b!1 2 /`a`b!4 5"
"(`a`b!7 8)+`a`b!1 2 /`a`b!8 10"
"(+)+(-) /5"
"\"cd\"+3.14 /102.14 103.14"
",1 /,1"
",`a`b!1 2 /+`a`b!(,1;,2)"
",`a`b!(1;2 3) /+`a`b!(,1;,2 3)"
",(+) /,+"
,(+)
^
[1]    45236 segmentation fault  ./k k.t

[ktye]

yes this does not look good. maybe you can enable some warnings in the compiler to see if there are problems.

critical positions are usually evaluation order or type conversion / signed/unsigned.

otherwise the go version is probably more reliable accross platforms.

[ktye]

e.g. i used this to test with zig cc: zig cc -Wall -Wno-parentheses-equality -fwrapv -ffast-math k.c -o kc.exe -lm

see file x/mk

[TheFausap]

Sure. I will post the results asap.

On Wed, 5 Apr 2023 at 16:48, ktye @.***> wrote:

e.g. i used this to test with zig cc: zig cc -Wall -Wno-parentheses-equality -fwrapv -ffast-math k.c -o kc.exe -lm

see file x/mk

— Reply to this email directly, view it on GitHub https://github.com/ktye/i/issues/36#issuecomment-1497620188, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOCZK6UDPYO4CH37RNH52TW7WA5TANCNFSM6AAAAAAWT46TBM . You are receiving this because you authored the thread.Message ID: @.***>

[TheFausap]

if I am using the parameters above, I have no warnings at all from clang. But if I use -Weverything (Clang stuff) I have more than 1000 warnings. I think this is expected, because of how the source code is written. Nevertheless, I will attach the output, maybe something useful is present in there. Also I enabled only the -Wsign-conversion and I got this:

❯ cc -o k -Wall -Wsign-conversion -Wno-parentheses-equality -fwrapv -ffast-math k.c
k.c:21:51: warning: implicit conversion changes signedness: 'int32_t' (aka 'int') to 'unsigned long' [-Wsign-conversion]
void Memory (int32_t x){_memorysize =x;_M =calloc(x,64*1024);}
                                           ~~~~~~ ^
k.c:22:51: warning: implicit conversion changes signedness: 'int32_t' (aka 'int') to 'unsigned long' [-Wsign-conversion]
void Memory2(int32_t x){_memorysize2=x;_M2=calloc(x,64*1024);}
                                           ~~~~~~ ^
k.c:28:32: warning: implicit conversion changes signedness: 'int' to 'unsigned long' [-Wsign-conversion]
 _M=(char *)realloc(_M, 64*1024*_memorysize);
            ~~~~~~~     ~~~~~~~^~~~~~~~~~~~
k.c:34:34: warning: implicit conversion changes signedness: 'int' to 'unsigned long' [-Wsign-conversion]
 _M2=(char *)realloc(_M2, 64*1024*_memorysize2);
             ~~~~~~~      ~~~~~~~^~~~~~~~~~~~~
k.c:72:6: warning: implicit conversion changes signedness: 'long' to 'size_t' (aka 'unsigned long') [-Wsign-conversion]
 n = ftell(fp);
   ~ ^~~~~~~~~
k.c:81:36: warning: implicit conversion changes signedness: 'int32_t' (aka 'int') to 'unsigned long' [-Wsign-conversion]
 if(nfile == 0){ fwrite(_M+src, 1, n, stdout); return 0; }
                 ~~~~~~            ^
k.c:87:20: warning: implicit conversion changes signedness: 'int32_t' (aka 'int') to 'unsigned long' [-Wsign-conversion]
 fwrite(_M+src, 1, n, fp);
 ~~~~~~            ^
k.c:95:39: warning: implicit conversion changes signedness: 'int32_t' (aka 'int') to 'size_t' (aka 'unsigned long') [-Wsign-conversion]
 }else return (int32_t)strnlen(_M+dst,n);
                       ~~~~~~~        ^
k.c:393:19: warning: implicit conversion changes signedness: 'unsigned int' to 'int32_t' (aka 'int') [-Wsign-conversion]
const int32_t nai=-0x80000000;
              ~~~ ^~~~~~~~~~~
9 warnings generated.

kwarns.txt

[ktye]

thank you. i have clang-11 on debian (k runs fine). but it can also do these warnings with -Weverything. Maybe i can get rid of them. alignment could be an issue. All memory is in one array, and I8, I32, F64 access it, SetI8, SetI32 write to it. part of the code is hand-written (the runtime) the rest is translated by a compiler written in k: x/cc.k if you haven't seen, there is a demo: ktye.github.io/kweb/compile

[ktye]

i removed many warnings (about 117 remaining) and rewrote heap access. there are no more alignment warnings, but i doubt it was not 8-byte aligned before

as before gcc and clang11 work on linux.

this also works (zig cc uses clang15): zig cc k.c -fwrapv -ffast-math -lm

without -ffast-math it fails on floating-point formatting and without -fwrapv it produces an illegal instruction for 0N-1

[TheFausap]

I built now with cc -o k -Wall -Wsign-conversion -Wno-parentheses-equality -fwrapv -ffast-math k.c and got no warnings. Also, the test passes, no more segmentation fault. Also, my program is working fine. Thanks a lot!

[ktye]

@TheFausap i noticed another bug with the c-version: SetI64 was a macro: #define SetI64(x,y) U_[(x)>>3]=(uint64_t)(y) I use e.g. SetI64(rp,(int64_t)(atv(rx(y),rx(x)))); The expression on the right may trigger a reallocation of U_, but c uses the old value on the assignment, which segfaults. it's fixed in the latest commit, replacing the macro with function calls. If you use the c version, it's a good idea to update.