In reply to the second half of: https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00021.html
> As to spurious problems with MSYS2 I can only say that in my experience > it is not a completely reliable build system. > > As a derivative from cygwin it shares the same fork() emulation hack, > and I've seen it sub-processes just silently terminating (or maybe not > even start them) with no failure code whatsoever. > > That would not affect the built tcc itself however it could affect the > 'diff' used by the tests for example. I think I removed the cygwin/fork/diff variables as follows: I'm using this, which is a reproducible mingw env without cygwin: https://github.com/skeeto/w64devkit/releases/tag/v1.16.1 building tcc (simply configure && make) within this environment is producing identical tcc.exe, libtcc.dll, libtcc1.a on both my Windows 10 system (32G ram) and my Windows 7 system (16G ram). "make test" succeeds on win7 but fails on win10. _Before_ commit d76e0323 (win64: hi-mem adjustments) test 104 failed also when invoked manually as: cd tests/tests2 && path/to/inttalled/tcc 104+_inline.c -run 104_inline.c where on win7 it printed things and exited successfully, while on win10 it printed "tcc: error: internal error: relocation failed". So it's also not an issue of diff not running correctly. I took the liberty to print the value which fails ("diff") and its origin (s->sh_addr at relocate_section), and noticed that on win10 it's 41-44 bits values, while on win7 it's 22-24 bits values. I guessed that this might be an address from malloc, and checked which values malloc returns using this program (source link below): int msb(unsigned long long v) { for (int i = 0;; ++i, v /= 2) if (!v) return i; } int main(int argc, char **argv) { unsigned long long a = (uintptr_t)malloc(1024); printf("%s %d [%d]: malloc: %llu (%d/%d bits)\n", cc, ccver, ccbits, a, msb(a), 8 * (int)sizeof(void*)); return 0; } I compiled this program using tcc (64) itself, as well as using mingw gcc 5.5 (64), mingw gcc 12.2 (64), and msvc 2015 (64). Source + binaries are available here https://0x0.st/ov4N.zip On win7 these programs print results like this: gcc 12 [64]: malloc: 1464336 (21/64 bits) gcc 5 [64]: malloc: 8476688 (24/64 bits) msvc 1900 [64]: malloc: 2635264 (22/64 bits) tcc 927 [64]: malloc: 2185120 (22/64 bits) While on win10 the same binaries print resuts like this: gcc 12 [64]: malloc: 2620625130432 (42/64 bits) gcc 5 [64]: malloc: 12260288 (24/64 bits) msvc 1900 [64]: malloc: 1504834189600 (41/64 bits) tcc 927 [64]: malloc: 8590208 (24/64 bits) So somehow, on win7 the address from malloc is always ~22 bits, while on win10 msvc and new mingw gcc procude ~43 bits address, while with tcc and old gcc malloc returns ~22 bits addresses. and indeed, when tcc64 is compiled using tcc64 then on win10 s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323. ---------- On Thursday, October 13, 2022, 10:16:45 PM GMT+3, grischka <gris...@gmx.de> wrote: >> from tests/tests2/: >> - 104_inline.test > > This might be fixed on mob. Confirmed, 104 now passes on win10 with gcc 12.2 (at d76e032). > You can see the command when you call the test directly: > > make -C tests clean > make -C tests test1 On win10 with gcc 12.2, the output ends with this: ./tcctest.gcc > test.ref make: *** [Makefile:110: test.ref] Error -1073741819 make: Leaving directory 'D:/tmp/tcc2/tests' and the last line at test.ref is "---- asm_test -" Then, at tcctest.c, I commented out /* RUN(asm_test); */ and the test passes. I tried to find which line crashes at asm_test, and it's: strncat1(buf, " worldXXXXX", 3); (adding exit(42) just before it exits with code 42, but exit(42) after it is not reached). I then tried also make -C tests clean make -C tests test3 and it's the same end of output as with test1, and same diagnostics (pass if commenting out RUN(asm_test), else crash at strncat1(buf, " worldXXXXX", 3)). - avih
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
