Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
Hi, On Sat, 9 Jun 2012, g...@sdf.org wrote: d = malloc (s); If this returns a pointer with upper 32 bits set (which depends on malloc size, fragmentation and moon phase) ... d[0] = 10.0; i = d[0] f (); ... those are lost in the caller-save/restore code for the address of d[0] generated because of the call to f. This is because the reload was done in VT_INT mode, not VT_PTR as it should have been. I fixed it on the mob branch with a hopefully more reliable testcase using alloca (which on x86-64 will always return a pointer with high 32 bit set because the stack will be set up that way). Thomas: as you were last fiddling with arm, you might want to check if the test works on it. The other alloca testcase is #ifdef'ed on i386 and x86_64, but that only makes sense if alloca really isn't supported on arm, which I can't believe. If that really is the case callsave_test() needs to be conditional too. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
On Sun, Jun 10, 2012 at 09:15:52AM +0200, Michael Matz wrote: Thomas: as you were last fiddling with arm, you might want to check if the test works on it. The other alloca testcase is #ifdef'ed on i386 and x86_64, but that only makes sense if alloca really isn't supported on arm, which I can't believe. If that really is the case callsave_test() needs to be conditional too. Some time ago I posted an alloca version for ARM: http://lists.nongnu.org/archive/html/tinycc-devel/2011-02/msg00046.html but we don't build a libtcc1 for ARM and libgcc/libc don't provide alloca as it is a GCC builtin. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
Hi, On Sun, 10 Jun 2012, Daniel Glöckner wrote: On Sun, Jun 10, 2012 at 09:15:52AM +0200, Michael Matz wrote: Thomas: as you were last fiddling with arm, you might want to check if the test works on it. The other alloca testcase is #ifdef'ed on i386 and x86_64, but that only makes sense if alloca really isn't supported on arm, which I can't believe. If that really is the case callsave_test() needs to be conditional too. Some time ago I posted an alloca version for ARM: http://lists.nongnu.org/archive/html/tinycc-devel/2011-02/msg00046.html Ah, I see. Well, alloca is highly desirable to have IMHO, so ... but we don't build a libtcc1 for ARM ... I think we should do so then. As it seems the various arithmetic routines of libtcc1.c aren't needed on arm it would only contain alloca. I'd vote for the assembler implementation (don't know if it would have to differ between the eabi and oldabi variants). Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
Le dimanche 10 juin 2012 20:01:11, Michael Matz a écrit : Hi, On Sun, 10 Jun 2012, Daniel Glöckner wrote: On Sun, Jun 10, 2012 at 09:15:52AM +0200, Michael Matz wrote: Thomas: as you were last fiddling with arm, you might want to check if the test works on it. The other alloca testcase is #ifdef'ed on i386 and x86_64, but that only makes sense if alloca really isn't supported on arm, which I can't believe. If that really is the case callsave_test() needs to be conditional too. Some time ago I posted an alloca version for ARM: http://lists.nongnu.org/archive/html/tinycc-devel/2011-02/msg00046.html Ah, I see. Well, alloca is highly desirable to have IMHO, so ... but we don't build a libtcc1 for ARM ... I think we should do so then. As it seems the various arithmetic routines of libtcc1.c aren't needed on arm it would only contain alloca. I'd vote for the assembler implementation (don't know if it would have to differ between the eabi and oldabi variants). It doesn't use VFP so it will work for both ABI. It also work for the new eabihf which I introduced as there is no float parameter. Ciao, Michael. Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
On Sun, Jun 10, 2012 at 08:03:24PM +0200, Thomas Preud'homme wrote: Le dimanche 10 juin 2012 20:01:11, Michael Matz a écrit : but we don't build a libtcc1 for ARM ... I think we should do so then. As it seems the various arithmetic routines of libtcc1.c aren't needed on arm it would only contain alloca. I'd vote for the assembler implementation (don't know if it would have to differ between the eabi and oldabi variants). It doesn't use VFP so it will work for both ABI. It also work for the new eabihf which I introduced as there is no float parameter. Compiler generated calls have been chosen to allow the use of libgcc_s.so.1 on ARM EABI and OABI. It is needed for divisions, 64-bit shifts, and some floating point conversion. One day we might also support devices without floating point hardware/emulator, where we could use the EABI soft float functions already contained in libgcc. I also added a configure option --with-libgcc to make TinyCC automatically link to libgcc_s.so.1 instead of libtcc1.a. If we now start to supply a libtcc1.a that does not include the functions from libgcc_s.so.1, we need to link to two libraries. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
Hi, On Sun, 10 Jun 2012, Daniel Glöckner wrote: Compiler generated calls have been chosen to allow the use of libgcc_s.so.1 on ARM EABI and OABI. It is needed for divisions, 64-bit shifts, and some floating point conversion. One day we might also support devices without floating point hardware/emulator, where we could use the EABI soft float functions already contained in libgcc. I also added a configure option --with-libgcc to make TinyCC automatically link to libgcc_s.so.1 instead of libtcc1.a. If we now start to supply a libtcc1.a that does not include the functions from libgcc_s.so.1, we need to link to two libraries. But that's no problem, is it? Alternatively alloca could be expanded inline at a (small) code size cost, but I think a libtcc1.a makes sense even when using libgcc_s (the former being the tinycc internals libs, the latter being a conveniently supported 3rd party lib). Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
Hi list,
Here is another simple program demonstrating a bizarre bug in TCC (on
amd64, both with TCC 0.9.25 and with the latest sources; it works on
i386).
This program should loop forever (or at least until the memory is
exhausted), but it does not: starting at given size of the dynamically
allocated array 'd', it segfaults in the two comparisons. (On my
computer, that given size is 135136 bytes for tcc, and 134432 for tcc
-run).
#include stdlib.h
#include stdio.h
double f () { return 100.0; }
int main ()
{
int i, s; double *d; double t;
for (s = sizeof (double); 1; s += sizeof (double)) {
printf (%d\n, s);
d = malloc (s);
d[0] = 10.0;
i = d[0] f ();
free (d);
}
return 0;
}
This program would run fine:
- if the size of the array is declared instead of using malloc()
- if the d = malloc (s); is replaced by d = malloc (s); free (d); d = malloc
(s);
- if the i = d[0] f (); is replaced by i = f () d[0];
- if the i = d[0] f (); is replaced by t = d[0] + f();
- if the i = d[0] f (); is replaced by i = d[0] 100.0;
- if ints are used instead of doubles
Here is a GDB session log after the segfault:
Program received signal SIGSEGV, Segmentation fault.
0x080483e7 in main ()
(gdb) disassemble
Dump of assembler code for function main:
0x0804835d +0: push %rbp
0x0804835e +1: mov%rsp,%rbp
0x08048361 +4: sub$0x30,%rsp
0x08048368 +11: mov$0x8,%eax
0x0804836d +16: mov%eax,-0x8(%rbp)
0x08048370 +19: jmpq 0x8048380 main+35
0x08048375 +24: mov-0x8(%rbp),%eax
0x08048378 +27: add$0x8,%eax
0x0804837b +30: mov%eax,-0x8(%rbp)
0x0804837e +33: jmp0x8048370 main+19
0x08048380 +35: mov-0x8(%rbp),%eax
0x08048383 +38: mov%rax,%rsi
0x08048386 +41: lea0x1223(%rip),%rax# 0x80495b0
L.25
0x0804838d +48: mov%rax,%rdi
0x08048390 +51: mov$0x0,%eax
0x08048395 +56: callq 0x8048560 printf
0x0804839a +61: mov-0x8(%rbp),%eax
0x0804839d +64: mov%rax,%rdi
0x080483a0 +67: mov$0x0,%eax
0x080483a5 +72: callq 0x8048570 malloc
0x080483aa +77: mov%rax,-0x10(%rbp)
0x080483ae +81: mov-0x10(%rbp),%rax
0x080483b2 +85: movq 0x120e(%rip),%xmm0# 0x80495c8
L.26
0x080483ba +93: movq %xmm0,(%rax)
0x080483be +97: lea0x120b(%rip),%rax# 0x80495d0
L.27
0x080483c5 +104: mov%rax,%rdi
0x080483c8 +107: mov$0x0,%eax
0x080483cd +112: callq 0x8048560 printf
0x080483d2 +117: mov-0x10(%rbp),%rax
0x080483d6 +121: mov%rax,-0x28(%rbp)
0x080483da +125: mov$0x0,%eax
0x080483df +130: callq 0x8048343 f
0x080483e4 +135: mov-0x28(%rbp),%eax
= 0x080483e7 +138: movq (%rax),%xmm1
0x080483eb +142: ucomisd %xmm0,%xmm1
0x080483ef +146: mov$0x0,%eax
0x080483f4 +151: seta %al
0x080483f7 +154: mov%eax,-0x4(%rbp)
0x080483fa +157: lea0x11d2(%rip),%rax# 0x80495d3
L.28
0x08048401 +164: mov%rax,%rdi
0x08048404 +167: mov$0x0,%eax
0x08048409 +172: callq 0x8048560 printf
0x0804840e +177: mov-0x10(%rbp),%rax
0x08048412 +181: mov%rax,%rdi
0x08048415 +184: mov$0x0,%eax
0x0804841a +189: callq 0x8048580 free
0x0804841f +194: jmpq 0x8048375 main+24
0x08048424 +199: mov$0x0,%eax
0x08048429 +204: jmpq 0x804842e main+209
0x0804842e +209: leaveq
0x0804842f +210: retq
End of assembler dump.
(gdb) info registers
rax0xf7fb8010 4160454672
rbx0x0 0
rcx0x80495d2134518226
rdx0x77dd8e10 140737351880208
rsi0x77ff8000 140737354104832
rdi0x 4294967295
rbp0x7fffe210 0x7fffe210
rsp0x7fffe1e0 0x7fffe1e0
r8 0x77ff8002 140737354104834
r9 0x0 0
r100x22 34
r110x246582
r120x8048300134513408
r130x7fffe2f0 140737488347888
r140x0 0
r150x0 0
rip0x80483e70x80483e7 main+138
eflags 0x10202 [ IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb)
Thanks,
--ghe
