Re: [Tinycc-devel] Do not load all referenced libraries, when linking a library

[Michael Matz]

Hello,

On Tue, 10 Oct 2023, Herman ten Brugge via Tinycc-devel wrote:


On 10/5/23 22:55, Detlef Riekenberg wrote:

 After the comments from grischka and Michael,
 i prepared a different patch to fix the build break of netbsd-curses
 and also updated the patch to current mob.


 `make test` works
 A testapp with netbsd-curses works,
 but i am away for the next 2 weeks.


 Since we have a release canditate, i decided to not push my patch to mob.

I think this is not correct.
If I read the elf documentation correctly a shared lib does not have to 
follow DT_NEEDED.

See attached patch.


Only runtime loaders are required to follow DT_NEEDED.  link editors 
aren't.  There's no distinction between emitting a shared lib or an 
executable.  (And for OUTPUT_MEMORY, which might be said to make tcc 
behave like a runtime loader, it's actually dlopen which does the 
necessary DT_NEEDED following).



Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] "error: invalid displacement" i386 1f 'L..1' does not get resolved

[Michael Matz]

Hello,

On Sun, 17 Apr 2022, Volodymyr Boyko wrote:


Hi
I'm trying to assemble the following snippet of code:

.global sigsetjmp
.global __sigsetjmp
.type sigsetjmp,@function
.type __sigsetjmp,@function
sigsetjmp:
__sigsetjmp:
        mov 8(%esp),%ecx
        jecxz 1f

        mov 4(%esp),%eax
        popl 24(%eax)
        mov %ebx,28+8(%eax)
        mov %eax,%ebx

.hidden ___setjmp
        call ___setjmp

        pushl 24(%ebx)
        mov %ebx,4(%esp)
        mov %eax,8(%esp)
        mov 28+8(%ebx),%ebx

.hidden __sigsetjmp_tail
        jmp __sigsetjmp_tail

1:      jmp ___setjmp
but getting this error:
src/signal/i386/sigsetjmp.s:8: error: invalid displacement
After renaming/moving the label around I assume the issue is that local
labels cannot be forward;1b and my_label moved to the top do work fine.


Yeah, it's related to that, but specific to the 'jexcz' opcode: the 
special thing about it is that it only comes in an 8-bit displacement form 
_and_ doesn't have an inverse form.  TCC, being single-pass, has to assume 
that forward labels could be anywhere, and hence potentially need a 32bit 
form (no matter that _in this case_ it would turn out to not be 
necessary), so jumps are rewritten into their disp32 forms for such 
labels.  For jecxz that can't be done.  And as the inverse form doesn't 
exist we can't even work around this by emitting something like a 
hypothetical:


  jecxnz +5   ; doesn't exist!
  jmp 1f

The GNU assembler uses multiple passes to figure out that the displacement 
in the testcase turns out to fit into a disp8 field and hence all is well. 
Add a couple more opcodes between the jecxz and the 1: label to make the 
distance larger than 128 and see it erroring out as well.


Supporting this requires some surgery (e.g. to support the _PC8 relocation 
and emitting them for this case only), so is of low priority.



Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Disabling memmove optimization

[Michael Matz]

Hi,

On Tue, 26 Apr 2022, Raul Hernandez wrote:


I guess TCC does this as either an optimization (to take advantage of
vectorization in the implementation of memmove), or as a way of simplifying
the generated code.


The latter, plus simplifying the generat_ing_ code (i.e. TCC itself).


My question is: is there any way of disabling this behavior?


Nope.  An alternative way of moving arbitrary memory (which a struct copy 
is) simply isn't implemented in TCC.  To solve the problem that would need 
to happen, i.e. open-coding the memmove/memcpy, with the appropriate care 
for alignment and target specifics.


Ideally I’d wish to be able to disable it for a single function, but I’d 
be happy with a compiler flag when invoking TCC or a compile-time define 
when building it.


***

This probably sounds like the XY problem; the reason why I need to 
change that behavior is that I’m trying to write a closure 
implementation for the V programming language. It works similarly to the 
approach described in https://nullprogram.com/blog/2017/01/08/, but I’m 
trying to write it in pure C for portability (so that it works with any 
calling convention and number of parameters). The implementation works 
correctly when compiled with GCC and clang, but sometimes fails under 
TCC because of the optimization I described. Any function calls within 
the closure wrapper will become invalid after the wrapper is copied 
somewhere else in memory, since the relative offset to that function 
will be different and the CPU will jump to a garbage location instead.


If you have control over the closure wrapper you could perhaps avoid the 
memmove by open-coding any struct copy yourself (with a char-by-char copy 
loop).  If the memcpy/memmove is part of the call sequence (i.e. for 
struct params or returns) and you control even more of your closure 
implementation then you can arrange for the problematic types (e.g. all 
structs) to be passed and returned by reference/pointer and so avoid the 
problem.  If you can't do that, then you'd need to implement the open-code 
sequence emission in TCC.



Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [patch] adding path resolution to #line directives

[Michael Matz]

Hey,

On Fri, 6 May 2022, Raul Hernandez wrote:

It would seem better to canonicalize during generating this, because 
the above and this don't look equivalent anyway (they are equivalent 
only when the above relative path is less that seven levels deep from 
/).


In our case this isn’t an issue, since the .c file is always compiled 
under /tmp/v_*/, so two levels would actually be enough here.


Sure, but TCC also has to work on input not coming from V.

The problem is that we cannot use an absolute path either (/home/…), 
because tcc will always prepend the file’s directory, even if the #line 
directive contains an absolute path. I guess a different fix could be to 
check for absolute paths, and prevent tcc from prepending the file 
surname if that’s the case,


That seems like a fix for what clearly is a bug in TCC, yes.  TCC 
shouldn't prepend something that is already an absolute path.


but I still think resolving relative paths 
is useful (one could generate #line directives like 
/my/lang/stdlib/../thirdparty/foo.c), and tcc would resolve them down to 
/my/lang/thirdparty/foo.c for cleaner backtraces, for example.


Well, IMHO TCC should do as little processing on what the producer put 
into the '#line' directives, simply because one has to assume that the 
producer did whatever it did for good reasons.  Prepending the compile 
directory to relative paths is borderline acceptably IMHO, but more than 
that: I don't think so.


So you simply remove '../' components without a matching directory 
part. That isn't correct in all circumstances.


This is only ever hit when enough ../’s have been parsed so that the 
beginning of the path (inserted by tcc or otherwise) has been completely 
removed, and we’re left at the root of the filesystem. In that case, 
/../ can be collapsed down to / . Could you give me an example of where 
this would be incorrect?


Hmm, you're right, it should be okay.  (It still feels strange, as it 
relies on the fact that '/..' is equal to '/').  But that still leaves the 
issue of symlinked directories, removing "dir/../" components from paths 
simply isn't preserving the path when 'dir' is a symlink to another 
directory:


% mkdir -p sub/sub2; touch sub/sub2/foo
% ln -sf sub/sub2 symlink
% ls symlink/../sub2/foo
symlink/../sub2/foo
% ls sub2/foo
ls: cannot access 'sub2/foo': No such file or directory

So, no, I don't think the patch is okay, it can transform correct input 
into incorrect output, even if it sometimes also transforms into nicer 
output.


You might consider using realpath(3) (which is in POSIX) to do all of 
this for you.


I tried that, but realpath() checks if the path actually exists on the 
filesystem, and returns an error if it does not, unfortunately.


Well, yeah, it has to, due to the above symlink problem.

This might be generally usefull to libtcc users, and the variant 
printing it out can be written in terms of the char** variant; so that 
seems sensible to have.


I can include that function then; the main__foo -> main.foo change is 
indeed very V-specific.


Related: libbacktrace has an API where it accepts a callback, which is 
then called with a backtrace frame's information 
(https://github.com/ianlancetaylor/libbacktrace/blob/master/backtrace.h#L91-L102 
), 
so that might be a useful alternative too.


Maybe, yeah.  I don't have a strong opinion there.


Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [patch] adding path resolution to #line directives

[Michael Matz]

Hey,

On Thu, 5 May 2022, Raul Hernandez wrote:


The code we generate looks something like this:

    #line 29
"../../../../../../home/spaceface/git/v/v/vlib/builtin/builtin.c.v"


It would seem better to canonicalize during generating this, because the 
above ...



   /tmp/v_1000/../../../../../../home/spaceface/git/v/v/vlib/builtin/builtin.c
.v:53: at panic_debug: Backtrace


... and this don't look equivalent anyway (they are equivalent only when 
the above relative path is less that seven levels deep from /).



    @@ -2042,6 +2042,22 @@ include_done:
                    pstrcpy(buf, sizeof buf, file->true_filename);
                    *tcc_basename(buf) = 0;
                    pstrcat(buf, sizeof buf, (char *)tokc.str.data);
    +                // collapse relative `../`s
    +                while ((q = strstr(buf, "../")) != NULL) {
    +                    (q == buf) ? (*q = '\0') : (*(q-1) = '\0');
    +                    last_slash = strrchr(buf, '/');
    +                    if (last_slash == NULL) {
    +                        memmove(buf, q + 2, strlen(q + 2) + 1);


So you simply remove '../' components without a matching directory part. 
That isn't correct in all circumstances.  You might consider using 
realpath(3) (which is in POSIX) to do all of this for you.  But as said, 
you might also be better off to just do that during generating the #line 
directives, so as to be independend of compiler behaviour.



Would you be willing to merge something this?

We’ve also added a function that returns the backtrace as a char** rather
than printing it out,


This might be generally usefull to libtcc users, and the variant printing 
it out can be written in terms of the char** variant; so that seems 
sensible to have.



and modified the backtrace functions to replace
e.g. main__foo with main.foo in symbol names,


But this is quite specific to V, so not too applicable without making it 
more general, at which point it doesn't look too attractive anymore.



Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] test failures on win32 x86-64

[Michael Matz]

Hello,


On Fri, 14 Oct 2022, avih via Tinycc-devel wrote:


0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al
0x7ff72b42b268 <+52>: dec %edi


This is the problem.  "dec %edi" truncates the %rdi register to 32bit by 
zero-extension, so that ...



0x7ff72b42b26a <+54>: mov 0x30(%rbp),%ecx
0x7ff72b42b26d <+57>: dec %ecx
0x7ff72b42b26f <+59>: js 0x7ff72b42b277 
0x7ff72b42b271 <+61>: lods %ds:(%rsi),%al
=> 0x7ff72b42b272 <+62>: stos %al,%es:(%rdi)


... this insn now segfault.  That only matters if the stack (which %rdi 
points into) is setup such that it's beyond 32bit, which ...



rdi 0xcb9ff955 3416258901
rbp 0x4ecb9ff8f0 0x4ecb9ff8f0
rsp 0x4ecb9ff8e0 0x4ecb9ff8e0


... is indeed the case on win10 for you.  So, it's not malloc() result, 
but it does have to do with address space layout.


The problem is that win64 is an IL32 platform, so that 'long' is not the 
same size as a pointer, but the strncat1 implementation, coming from the 
linux kernel, expects that to be the case.  The below patch should fix it, 
but I can't test on win64, so please check yourself and commit if it does.



Ciao,
Michael.

--

diff --git a/tests/tcctest.c b/tests/tcctest.c
index f5bd9aab..1d625b0c 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -3254,7 +3254,7 @@ void local_label_test(void)
 /* from linux kernel */
 static char * strncat1(char * dest,const char * src,size_t count)
 {
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
 __asm__ __volatile__(
"repne\n\t"
"scasb\n\t"
@@ -3276,7 +3276,7 @@ return dest;

 static char * strncat2(char * dest,const char * src,size_t count)
 {
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
 __asm__ __volatile__(
"repne scasb\n\t" /* one-line repne prefix + string op */
"dec %1\n\t"

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] test failures on win32 x86-64

[Michael Matz]

tomic(long) atomic_long;  [position 44:17]
typedef _Atomic(long) atomic_long;  [position 44:30]
typedef _Atomic(unsigned long) atomic_ulong;  [position 45:26]
typedef _Atomic(unsigned long) atomic_ulong;  [position 45:40]
typedef _Atomic(long long) atomic_llong;  [position 46:17]
typedef _Atomic(long long) atomic_llong;  [position 46:22]
typedef _Atomic(long long) atomic_llong;  [position 46:36]
stddef.h
    __FILE__, __FUNCTION__, p, (unsigned long)offset);  [position 
514:50]
    __FILE__, __FUNCTION__, p, (unsigned 
long)offset); \  [position 562:50]
    (void *) (addr + fp), (unsigned long) p[1]);  
[position 642:53]
    (void *) (addr + fp), (unsigned long) p[1]);  
[position 717:57]
    __FILE__, __FUNCTION__, p, (unsigned long)size); [position 
737:50]

    unsigned long start;  [position 1007:18]
    unsigned long end;  [position 1008:18]
    unsigned long ad =  [position 1009:18]
    (unsigned long) __builtin_return_address(0); [position 
1010:23]

    (void *) p[0], (unsigned long) p[1]); [position 1082:46]
    argv[i], (unsigned long)(strlen (argv[i]) + 1));  
[position 1114:44]
    *p, (unsigned long)(strlen (*p) + 1));  [position 
1138:39]

 (unsigned long) tree->size); [position 1193:36]
 __FILE__, __FUNCTION__, ptr, (unsigned 
long)size);  [position 1442:61]
    __FILE__, __FUNCTION__, ptr, (unsigned long)size);  [position 
1452:52]
    __FILE__, __FUNCTION__, ptr, (unsigned long)size);  [position 
1491:52]
    __FILE__, __FUNCTION__, new_ptr, (unsigned long)size);  
[position 1569:56]
 __FILE__, __FUNCTION__, ptr, (unsigned long)size);  
[position 1606:61]
 __FILE__, __FUNCTION__, ptr, (unsigned long)size);  
[position 1614:53]
    __FILE__, __FUNCTION__, start, (unsigned long)size);  
[position 1637:54]
    __FILE__, __FUNCTION__, start, (unsigned long)size);  
[position 1653:54]

    p, (unsigned long)size, function);  [position 1672:30]
    p1, (unsigned long)n1, p2, (unsigned long)n2, 
function);  [position 1687:31]
    p1, (unsigned long)n1, p2, (unsigned long)n2, function);  
[position 1687:54]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1696:58]
    __FILE__, __FUNCTION__, s1, s2, (unsigned long)n);  [position 
1712:55]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1732:58]
    __FILE__, __FUNCTION__, s, c, (unsigned long)n); [position 
1742:53]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1752:58]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1764:58]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1774:58]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1784:58]
    __FILE__, __FUNCTION__, s, c, (unsigned long)n); [position 
1794:53]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1836:58]
    __FILE__, __FUNCTION__, s1, s2, (unsigned long)n);  [position 
1871:55]
    __FILE__, __FUNCTION__, new, (unsigned long)(p -s));  
[position 1931:52]

    (void *) t->start, (unsigned long) t->size, [position 2185:42]


On 19/10/22 14:36, Michael Matz wrote:

 Hello,


 On Fri, 14 Oct 2022, avih via Tinycc-devel wrote:


 0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al
 0x7ff72b42b268 <+52>: dec %edi


 This is the problem.  "dec %edi" truncates the %rdi register to 32bit by
 zero-extension, so that ...


 0x7ff72b42b26a <+54>: mov 0x30(%rbp),%ecx
 0x7ff72b42b26d <+57>: dec %ecx
 0x7ff72b42b26f <+59>: js 0x7ff72b42b277 
 0x7ff72b42b271 <+61>: lods %ds:(%rsi),%al
 => 0x7ff72b42b272 <+62>: stos %al,%es:(%rdi)


 ... this insn now segfault.  That only matters if the stack (which %rdi
 points into) is setup such that it's beyond 32bit, which ...


 rdi 0xcb9ff955 3416258901
 rbp 0x4ecb9ff8f0 0x4ecb9ff8f0
 rsp 0x4ecb9ff8e0 0x4ecb9ff8e0


 ... is indeed the case on win10 for you.  So, it's not malloc() result,
 but it does have to do with address space layout.

 The problem is that win64 is an IL32 platform, so that 'long' is not the
 same size as a pointer, but the strncat1 implementation, coming from the
 linux kernel, expects that to be the case.  The below patch should fix it,
 but I can't test on win64, so please check yourself and commit if it does.


 Ciao,
 Michael.

 --

 diff --git a/tests/tcctest.c b/tests/tcctest.c
 index f5bd9aab..1d

Re: [Tinycc-devel] test failures on win32 x86-64

[Michael Matz]

Hello,

On Thu, 20 Oct 2022, avih wrote:


> "dec %edi" truncates the %rdi register to 32bit by zero-extension,
> so that ... this is now segfault. That only matters if the stack
> (which %rdi points into) is setup such that it's beyond 32bit,
> which ... is indeed the case on win10 for you. So, it's not
> malloc() result, but it does have to do with address space layout.

Thanks for pointing out the relation between my (somewhat off)
addresses observation and the test failures.

Are you able to shed some light on how some binaries (those compiled
with msvc or new mingw gcc) exhibit ~44 bit addresses on Windows 10,
but ~24 bits addresses on Windows 7?


That's simply how the win10 runtime behaves a little different.  stack and 
malloc memory ultimately all rely on memory pages gives out by the kernel 
to userspace (on unix that's mmap and on windows that's CreateFileMapping 
and friends), and the win10 kernel happens to give out pages 
residing beyond 4GB by default, while the win7 kernel does not (at least 
for you, in your cases; but I'm guessing that Microsoft is slowly but 
surely eliminating artifacts that still stem from compatibility 
considerations between win32 and win64: giving out pages below 4GB by 
default, even for 64bit processes, would be such compatibility hack)



> The problem is that win64 is an IL32 platform, so that 'long' is not the
> same size as a pointer, but the strncat1 implementation, coming from the
> linux kernel, expects that to be the case. The below patch should fix it,
> but I can't test on win64, so please check yourself and commit if it does.

I think your patch will conflict with the fix on mob from few days ago:
https://repo.or.cz/tinycc.git/commitdiff/bb80cbe0


Ah, I haven't checked mob before fiddling with this.

However, do note that your patch replaces two instances of long with 
size_t, while bb80cbe0 replaces few more instances, so I'd imagine 
that's why the test was still failing with your patch (didn't check).


Yup, as I said, I wasn't able to test for real ;-)


Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] VLA support is not detected with autoconf

[Michael Matz]

Hey,

On Sun, 18 Sep 2022, Detlef Riekenberg wrote:



tcc can't compile the attached VLA check (gcc works)
and configure adds "#define __STDC_NO_VLA__ 1" to config.h

The code was generated using the autoconf macro "AC_C_VARARRAYS".

console output:
tcc -std=c11  vla_conftest.c -c
vla_conftest.c:30: error: constant expression expected


Any ideas, how to fix that?


Fixed in mob.


Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] __attribute__((constructor)) not getting called

[Michael Matz]

Hello,

On Sat, 1 Oct 2022, Liam Wilson wrote:


Note __attribute__((constructor)) has been stripped off bar and not foo.


Yep, that's the glibc headers defining __attribute__ away ...


Digging a bit further, it seems to be due to sys/cdefs.h (which is
included by string.h and many other standard headers). In sys/cdefs.h
I found this:


... as you found out.

Is there a work around for this issue? I can define __GNUC__ but 
presumably that may cause other issues?


The work-around is to use the other form of attribute: __attribute(foo)
(note the missing suffix of '__').  That's still in the implementation 
namespace and not defined away by glibc.


The other work-around would be to '#undef __attribute__' after all glibc 
headers are included.  As  (on glibc!) also has header guards 
you might also get away with this, as first directives in the .c files:


  #include 
  #undef __attribute__

as the following includes, even if they include  again, won't 
parse its content again.  As TCC ignores unknown attributes that should 
work fine for the decls in the glibc headers as well.



Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] miscompilation for code snippet

[Michael Matz]

Hey,

On Tue, 16 Aug 2022, ntysdd via Tinycc-devel wrote:


Sorry, bad format.


 #define G(x) _Generic((x),int*:"int*",void*:"void*")

 int printf(const char*, ...);

 int main()
 {
         int y = 0;
         const char *s = G(1?(void*)(y*0LL):);
         printf("%s\n", s);
 }


Fixed in mob.


Ciao,
Michael.





 


-- Original --
From: "ntysdd" ;
Date: Tue, Aug 16, 2022 08:32 PM
To: "tinycc-devel";
Subject: miscompilation for code snippet

TCC gets different result than gcc or clang for code below

 #define G(x) _Generic((x),int*:"int*",void*:"void*")

 int printf(const char*, ...);

 int main()
 {
 int y = 0;
 const char *s = G(1?(void*)(y*0LL):y);
 printf("%s\n", s);
 }

expected
void*

actual
int*

Similar constructs are used in Linux kernel.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] clang 15.0 issue with tcctest.c

[Michael Matz]

Hello,


On Thu, 17 Nov 2022, Christian Jullien wrote:


Test later fails with

tcctest.c:2903:17: error: incompatible pointer to integer conversion passing
'void *' to parameter of type 'int' [-Wint-conversion]

    old_style_f((void *)1, 2, 3.0);

    ^


So, this is a warning promoted to an error with recent clang.  We try to 
avoid such compatibility warnings explicitely (by compiling with -w), but 
clang doesn't heed this request anymore.


The warning here is a bit on the border because this is an old style 
function definition, and parameter types are not compared for calls to 
such functions (though the call will be undefined behaviour if the types 
aren't compatible, which is indeed the case here, so a warning is somewhat 
justified).


Can clang15 at least be convinced to not warn (and hence error out) here 
with -Wno-int-conversion?  If so that would be the solution.  If not, we 
have a problem, because tcc _wants_ to support exactly this situation 
(until we decide that we don't, then we need to adjust the testcase).



Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TCC produced wrong code (yarpgen v1)

[Michael Matz]

Hey,

On Sat, 18 Feb 2023, wine@web.de wrote:


While trying yarpgen (v1 branch of github.com/intel/yarpgen ),
various test files compiled with tcc (x86_64@linux) produce a wrong result.

I compared the first failed program with gcc
and found an "if" section in the example code,
where the compiled programs from both compiler
(tcc and gcc-12) enter the "true" section,
but in the middle of the "if" sections,
the tcc compiled code breaks out of the "true" part of the "if" section
and execution continiues at the start of the "false" section.

Very strange


The problem (at least for the 'yarpgen -s 5' generated program) is fixed 
in mob now.  I haven't tried yarpgen on more than your reported example, 
so you might want to check yourself.


FWIW, the problem was that too complicated expressions involving 
short-circuiting || and && with constant operands sometimes left code 
generation deactivated to further statements outside the expression (which 
is why it seemed to jump from inside the true if block to some random 
other place).



Ciao,
Michael.



Any idea, how to nail down the issue?

I already increased some internal stacks:
#define INCLUDE_STACK_SIZE  932
#define IFDEF_STACK_SIZE964
#define VSTACK_SIZE 9256
#define STRING_MAX_SIZE 91024
#define TOKSTR_MAX_SIZE 9256
#define PACK_STACK_SIZE 98


The example source works with clang (v15) and gcc (v12)
and is attached to a bug report:
https://savannah.nongnu.org/bugs/?63816




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Bug 63816 fixed (yarpgen_v1). Thanks Michael

[Michael Matz]

Hey,

On Wed, 8 Mar 2023, Detlef Riekenberg wrote:

> Your commit c771cb52 fixes a lot of bugs in the yarpgen v1 generated tests.
> 
> For seed values from 1 to 99, only 4 result failures left: 26, 56, 64 and
> 84.
> For 100 to 200, there are some more result failures (102, 117 and 173)
> and some compile aborts: 123, 143, 197.

Thanks for checking.  Most of them were struct with anon bitfield members.  
When their sizes were full types (i.e. 32bit int fields) they weren't 
ignored in initializers like they should.  Fixed in mob by Herman.

seed 64 was different and a problem with ternary expressions whose 
condition was a ternay-op itself.  Also fixed in mob.  seeds from 1 to 200 
are working fine for me now.  (I haven't checked others)


Ciao,
Michael

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel