I've seen a segfault under some other circumstances on linux 64.
Using "lea str(%rip),%rdi" instead of "mov $str,%rdi" in asm-c-connect-1.c
did fix it. (I can't tell right now whether that is expected behavior or
points to a bug though.)
Also I noticed that apparently 'U' is a string prefix in newer gcc versions.
(Don't know, maybe for unicode?).
Btw, what about the "vide" hack on tccasm.c:1020 from commit 6afe668ec
Can we delete it?
Ciao,
--- grischka
avih wrote:
>> 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