Starting early April, a number of commits were pushed to the mob branch
that did not reflect the interest, wishes, or code quality of the tcc
community. This commit reverts those commits, while cherry-picking
grishka's commit for win64 linkage issues.
- revert to R_X86_64_PC32 for near calls on PE
- revert to s1->section_align set to zero by default
Untested. Compared to release_0_9_26 the pe-image looks back to
normal. There are some differences in dissassembly (r10/r11 usage)
but maybe that's ok.
example: "-lshell32" will try "shell32.def + shell32.c"
Add lib type "%s/%s.c" for tcc_add_library() ('-l' option parse)
So tcc can use all files as scripts.
And the modified tcctest.c test
2, pack: in the compiler under the mode of s1->ppfp, I have no clear ideas1->ppfp
Some advice thank you Roy to me.This patch, I hope I can pass the Roy test
- revert to R_X86_64_PC32 for near calls on PE
- revert to s1->section_align set to zero by default
Untested. Compared to release_0_9_26 the pe-image looks back to
normal. There are some differences in dissassembly (r10/r11 usage)
but maybe that's ok.
because:
- Constructing fp numbers isn't quite trivial
- 3 additional calls to strchr per number is noticeable slow
Also: exclude abitest.c:ret_longdouble_test2 on _WIN32
for mixed gcc/tcc scenario
test case:
- make -k test (on win32):
-2.120000 0.500000 23000000000.000000
+2.120000 0.500000 22999999999.999996
...
ret_longdouble_test2... failure
This reverts 857f7dbfa6
and deaee6c249
1: The new patch for the other machines still have the problem.
2: libcrt Rename (what if gcc had libcrt as well)
3: parse_number exact problem
4: VT_VLS is to allow tcc
Compile the following
int b = 9;
struct st {
int a;
int b [b]
};
struct st st1;
st1.b [8] = 9;
printf ("% d \ n", st1.b [8]);
tcc a problem. Due to problems in front, and now can not be improved
5: they commit much, bug difficult to lock, you can not let other people help develop.
6: ('\ t') too
Thanks to Michael and Ray
Their criticism I have benefited!
For example, it should look like this
High stack
-------------
----- Func_ret_sub
------------
---- Vla stack
-------------
---- Known loc
--------------
Low
Increased loc_stack () function is used for temporary stack management, call save_reg (), released by load ()
Like this
Before use
High
----- Known loc
----
---
----
---- Pop_stack
Low
loc_stack (size, 1)
After use
High
----- Known loc
---- Pop_stack
---
----
----
Low
The attached fix (libcrt.c) is just one example. There seem
many more such introduced from latest commits that look badly
formatted in anyone else's editors and should be fixed.
General recommended policy:
- if possible, do not add new hard tabs ('\t') at all.
Use spaces (soft tabs) instead
- in any case, configure your editor to read/write hard tabs
with width of 8 (eight)
Also:
- Avoid merge commits (unless for very good reason). Instead
use "git cherry-pick" or "git rebase" to put your commits on
top of the public branch. ref: 2a8905c93b
Also:
- jiang: please explain what you are doing, in the commit message
and on the list. Subscribe to the mailing list to receive feedback
from people for your work.
For example, what was wrong with 'parse_number'? Show a test
case and how your version fixes it (it is slower btw).
Carlos Montiers