Fix it to actually be able to parse 64bit immediates (enlarge
operand value type). Then, generally there's no need for accepting
IM64 anywhere, except in the 0xba+r mov opcodes, so OP_IM is
unnecessary, as is OPT_IMNO64. Improve the generated code a bit
by preferring the 0xc7 opcode for im32->reg64, instead of the
im64->reg64 form (which we therefore hardcode).
Traditional behaviour on x86-64 is to encode the relocation
addend in r_addend, not in the relocated field (after all,
that's the reason to use RELA relocs to begin with). Our
linker can deal with both, other linkers as well. But using
e.g. the GNU assembler one can detect differences (equivalent
code in the end, but still a difference).
Now there's only a trivial difference in tests/asmtest.S
(having to do with ordering of prefixes).
A bag of assembler fixes, to be either compatible with GAS
(e.g. order of 'test' operands), accept more instructions,
count correct foo{bwlq} variants on x86_64, fix modrm/sib bytes
on x86_64 to not use %rip relative addressing mode, to not use
invalid insns in tests/asmtest.S for x86_64.
Result is that now output of GAS and of tcc on tests/asmtest.S
is mostly the same.
Insert a space when it is required to prevent mistokenisation of
the output, and also in a few cases where it is not strictly
required, imitating GCC's behaviour.
... for fast redeclaration checks
Also, check function parameters too:
void foo(int a) { int a; ... }
Also, try to fix struct/union/enum's on different scopes:
{ struct xxx { int x; };
{ struct xxx { int y; }; ... }}
and some (probably not all) combination with incomplete
declarations "struct xxx;"
Replaces 2bfedb1867
and 07d896c8e5
Fixes cf95ac399c
A constant expression removed from the loop.
If subroutine have 50000+ local variables, then currently
compilation of such code takes obly 15 sec. Was 2 min.
gcc-4.1.2 compiles such code in 7 sec. pcc -- 3.44 min.
A test generator:
#include <stdio.h>
int main() {
puts("#include <stdio.h>"); puts("int main()"); puts("{");
for (int i = 0; i < 50000; ++i) printf("int X%d = 1;\n", i);
for (int i = 0; i < 50000; ++i) puts("scanf(\"%d\", &X0);");
puts("}");
return 0;
}
don't catch redefinition for local vars. With this option on
tcc accepts the following code:
int main()
{
int a = 0;
long a = 0;
}
But if you shure there is no problem with your local variables,
then a compilation speed can be improved if you have a lots of
the local variables (50000+)
Various x86 asm fixes: 64bit lcall/ljmp like 32bit a commit before,
xchgw accepted wrong operands on 32 and 64bit, and 64bit used
0x40/0x48+reg for incw/decw, but those are REX prefixes, not
instructions.
* correct -E output for the case ++ + ++ concatenation
do this only for expanded from macro string
and only when tcc_state->output_type == TCC_OUTPUT_PREPROCESS
- uses new `TinyAlloc`-ators for small `TokenSym`, `CString` and
`TokenString` instances
- conditional `TAL_DEBUG` for mem leaks and double frees detection
- on `TAL_DEBUG` collects allocation origin (file + line)
- conditional `TAL_INFO` for allocators stats (in release mode too)
- chain a new allocator twice current capacity on buffer exhaustion
parse_print_line_comment() and parse_print_comment() are
combined and made more simply:
* don't worry about speed with -E option
* don't handle straya in comments
Do we need to handle strays in regular
parse_line_comment() and
parse_comment() ?
