> 0x1234-123 parsed by tcc as float number
May be 0x0fe-123 (as macro expansion, I can't remember now)
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> That's a good bit of sleuthing. A couple of questions immediately come to
> mind:
>Why does gcc and pcc take 4 as their alignment? Why do we take 32?
I'm not a guru. But tcc behaviour cost me a day of the problem discovering
>Does this have any performance impact?
I don't think so.
Hello Sergey,
That's a good bit of sleuthing. A couple of questions immediately come to
mind:
- Why does gcc and pcc take 4 as their alignment? Why do we take 32?
- Does this have any performance impact?
- Is there a reason you are implementing this with #ifdef? Might we use
a
Hi!
I have 3 patches to submit. But now I can't, nothing happens.
commit a07946980624b1cfe4955a329c49bfe704a2cfb7
Author: seyko
Date: Thu Apr 21 01:32:22 2016 +0300
.rept asm directive
and '.' alone is a token now in *.S (not an identifier)
representing
> A problem may be in the section aligment: gcc sets this to 4 and tcc to 32.
Just checked. I used a hex editor to replace a 0x20 bytes in mem-2.o with 0x04.
This helped.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
A problem may be in the section aligment: gcc sets this to 4 and tcc to 32.
Where in the source this is fixed?
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Hi!
I'm trying to use tcc as CC compiler for usual kernel compilation (2.4.37) i.e.
cd linux
make bzImage CC=tcc
Kernel compiles fine, but hangs some time after start. After
Investigating a problem, I got the following difference: a file
mem-2.s (a part of the file drivers/char/mem.c)