The test is always compiled by tcc.
Of course.
So if you say "initial compiler", do you mean the compiler by which tcc itself
is compiled?
Yes
I.e. there is a difference if tcc is compiled by gcc (tcc produces segfaulting>
code then), vs. with tcc (the resulting tcc produces good code)?
That's what I said indeed, but apparently there's more to it.
First, attached are the .o files from the two c files, each compiled with three
different versions of tcc, two of those were compiled themselves using tcc
(tcc32-tcc32 and tcc64-tcc64), and one version of tcc compiled using gcc
(gcc64-tcc64).
There's no difference at the .o files between the tcc64-tcc64 versions to the
gcc64-tcc64 versions. I don't have gcc32 installed to create gcc32-tcc32 .o
file and compare to the tcc32-tcc32 .o version, but I've attached the
tcc32-tcc32 version anyway.
So it must be at the build/test procedure.
If I use the standard (out of tree) build with ../configure && make && make
test then indeed it fails the same way (segfault) regardless if I'm building tcc with gcc or
with tcc (i.e. ../configure --cc=/abs/path/to/tcc.exe ...).
But when I reported my results earlier I used a different build+test procedure
for tcc-tcc which succeeded - at least apparently, with the output I reported
at the previous mail.
The one which succeeded was using my reproducible build script which runs the
tests makefile with custom arguments, but I'm currently having some issues
which I want to explore further before I post further info.
If anyone else could try building tcc using mingw gcc (32 and/or 64) using the
normal procedure and running the tests, it could help.
On Thursday, November 23, 2017 3:58 PM, Michael Matz <address@hidden> wrote:
Hi,
On Thu, 23 Nov 2017, avih wrote:
I hope it also works on win32 and win64, which I haven't tested
asm-c-connect-test pass if the initial compiler is tcc 32 or 64 (and building
tcc 32/64 respectively).
It segfaults if the initial compiler is gcc 64 (mingw gcc 7.2.0, in msys2
setup).
I didn't test with gcc 32 mingw.
The test is always compiled by tcc. So if you say "initial compiler", do
you mean the compiler by which tcc itself is compiled? I.e. there is a
difference if tcc is compiled by gcc (tcc produces segfaulting code then),
vs. with tcc (the resulting tcc produces good code)?
Hmpf.
Can you compile the two files separately into .o files and attach them
here? (With the failing compiler I mean). Perhaps it's something
obvious, but I can't test win32/64.
Ciao,
Michael.
When it passes, this is what it prints:------------ asm-c-connect-test
------------
./asm-c-connect
x1
x2
x3
And when it fails:../tcc.exe -B../../win32 -I../../include -I../.. -I.. -L.. -o
asm-c-connect.exe ../../tests/asm-c-connect-1.c ../../tests/asm-c-connect-2.c
------------ asm-c-connect-test ------------
./asm-c-connect.exe
make[1]: *** [Makefile:240: asm-c-connect-test] Segmentation fault
make[1]: Leaving directory '<tcc-root>/bld/tests'
make: *** [Makefile:346: test] Error 2
On Wednesday, November 22, 2017 7:11 PM, Michael Matz <address@hidden>
wrote:
Hi,
On Mon, 20 Nov 2017, Michael Matz wrote:
naively I'd think that it probably should more closely emulate the gcc
situation where inline asm ends up just as embedded snippets in its C ->
asm output. Which could mean for example that "free_asm_labels" should
be called only once at the end of each "translation unit" (file).
Yes, that would be the ultimate goal. As said, this would elevate the
problem of sharing C-label and asm-label namespace, which already is a
problem right now, even more. So that needs solving, preferably without
needing too much additional memory, then the move to a single end-of-file
free_asm_labels, and then all is sunny :)
Below is some test that I just have tried.
Yep, a conscise example of all asm- symbol table problems we have right
now :)
I've fixed the problems I know about, including this two-file testcase
(I've added it to the testsuite, I hope it also works on win32 and win64,
which I haven't tested).
After release I'm probably going to change how the asm symtable is
implemented, which then does away with the new slot in TokenSym. My idea
is to have just a single sym table for global decls, the C one, which can
be used for the asm one as well, with some slight adjustments.
But as is, it at least fixes the testcase, the linux-2.4.x 32bit kernel,
and 64bit linux 4.6, so I'm happy enough for now :)
Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
------------------------------------------------------------------------
_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel