Re: [Tinycc-devel] tcc: error: unknown relocation type for got: 285
On 2023-12-09 02:40, vw via Tinycc-devel wrote: When I installed libtcc, I just used the command: sudo apt install libtcc-dev So, I am not sure how to find if it is ARM32 or AArch64? I assume everything must be AArch64? Do NOT install TinyCC from your package manager, it should be a quite old version of TinyCC. I didn't compile anything myself, all tcc, libtcc-dev where installed via the sudo apt install. My version of debian is 11 (bullseye). Build TinyCC from source should be the solution. I am really interested in the feature of dynamic compilation as in the libtcc_test.c example file. Thanks! Vinny -- Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc: error: unknown relocation type for got: 285
On 2023-12-08 07:48, Henri Carrie via Tinycc-devel wrote: But when i tried to get it to work on my raspberry pi 4, running debian 11, I got this error and I don’t know how to get around it: tcc: error: Unknown relocation type for got: 285 Are you running an AArch64 variant of Debian or an ARMv7 one? Relocation type 285 stands for R_AARCH64_LDST32_ABS_LO12_NC, which is handled in arm64-link.c. Are you using libtcc compiled for ARM32 instead of AArch64? Any suggestions on how to fix it? thanks! Vinny ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel -- Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'
On 2023-09-10 15:13, Страхиња Радић wrote: What is weird is that tcc requires a libc function, memset, when none is explicitly requested, when for example this code: It is not that weird I think. Early versions of GCC generates a call to memset() as well when zeroing a block of memory [1] btw, the call could be easily eliminated by add a function like gen_struct_copy() in x86_64-gen.c. And this call may lead to problems. For example, the dynamic linker of musl has code that zeros a structure, but at that time memset() has not been relocated, result in a segfault. -- Ziyao [1]: check for clear_storage() in gcc/expr.c of commit 3b6f75e2 of gcc ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Questions about commit 5b28165: Fix test 131 for 32 bits targets
On 2023-07-08 01:29, Herman ten Brugge via Tinycc-devel wrote: On 7/7/23 18:15, Ziyao wrote: Hi, I noticed that test 131 (authored by me) has been modified in commit 5b28165: Fix test 131 for 32 bits targets: struct with two long int members are replaced by long long int ones. Test 131 (return struct in registers) is intended to test whether functions return small structs (maybe passed in registers in some ABIs) are handled properly. long long int on 32bit targets seem to be 8 bytes, right? And AFAIK, many ABIs only pass structs with 2 * WORDLENGTH size in registers (for 32-bit architectures, it is 8-bytes and is equal to the size of a struct with two long int members.) Is this fix necessary? Your testcode only worked on 64 bits targets. I just fixed it to work on 32 bits targets. We can add extra tests for structures containing int/short/char. These are compatible on 64 and 32 bits. Type long is different on 32 and 64 bits targets so can not be used. See other test cases. Thanks. Herman ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel -- Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Questions about commit 5b28165: Fix test 131 for 32 bits targets
On 2023-07-08 01:25, grischka wrote:
Hi,
well, problem is simply that with 32-bit longs your data
0x1234567890abcd
would be truncated to
0x7890abcd
and the output from %lx would not match the .expect file.
Thanks for explanation. But replacing 0x1234567890abcd with
0x12345678 (32-bit length) may be better?
Btw is your fix incorrect. The code that you "fixed" is about
alignment but there was no alignment problem in your case.
The real problem is below at "vtop->c.i += regsize;" which can
advance the location to load the 2nd register only for local or
global/static memory.
If the struct is not aligned, it will be copied to an aligned
address on stack. With this fix, returned structs without
VT_LVAL | VT_LLOCAL will also be copied onto stack as the same way
in which unaligned ones are copied, thus code below could handle it.
For pointers it would need to emit an 'add r, regsize' instruction
You can see such code in gv():
gaddrof();
vpushs(PTR_SIZE);
gen_op('+');
vtop->r |= VT_LVAL;
-- gr
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
--
Ziyao
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Questions about commit 5b28165: Fix test 131 for 32 bits targets
Hi, I noticed that test 131 (authored by me) has been modified in commit 5b28165: Fix test 131 for 32 bits targets: struct with two long int members are replaced by long long int ones. Test 131 (return struct in registers) is intended to test whether functions return small structs (maybe passed in registers in some ABIs) are handled properly. long long int on 32bit targets seem to be 8 bytes, right? And AFAIK, many ABIs only pass structs with 2 * WORDLENGTH size in registers (for 32-bit architectures, it is 8-bytes and is equal to the size of a struct with two long int members.) Is this fix necessary? -- Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Fix invalid loads generated by gfunc_return()
Hi list,
On riscv64, code below could trigger a SIGSEGV:
struct s {
long int a;
long int b;
};
struct s
foo(void)
{
struct s d;
struct s *p =
long int x = 0;
return *p;
}
int
main(void)
{
foo();
}
Generated code:
1151c: fca43823sd a0,-48(s0)
11520: fd843503ld a0,-40(s0)
11524: fca43423sd a0,-56(s0)
11528: fc843503ld a0,-56(s0)
1152c: 00053503ld a0,0(a0)
11530: fd043583ld a1,-48(s0)
=> 11534: 0005b583ld a1,0(a1)
-48(s0) is x and -40(s0) is pointer *p, and the last line leads to a
fault.
When returning the struct to which *p points, generated code actually
loads address from the area contains x and try to dereference it,
which leads to a segfault. (The value x holds, 0x0, is obviously an
invalid memory address)
This could be fixed with a little patch to gfunc_return(). It has been
tested on aarch64 Debian, x86-64 Alpine and riscv64 Debian and
everything worked (but AFAIK TinyCC on aarch64 and x86-64 do not rely
gfunc_return() to handle small structures returned in paired registers)
Many thanks if you could help test this on other architectures/OS.
--
Ziyao
From a82aff333774f3bd38841d3c167f1add8c473c1c Mon Sep 17 00:00:00 2001
From: Yao Zi
Date: Sun, 2 Jul 2023 03:58:02 +0800
Subject: [PATCH] Fix invalid load generated by gfunc_return()
On backends that rely on gfunc_return() to handle structures
returned in registers (like RISC-V), gfunc_return() may generate
invalid loads for structures without VT_LOCAL and VT_LVAL. This
commit fixes it and adds a regression test
(131_return_struct_in_reg)
---
tccgen.c | 2 +-
tests/tests2/131_return_struct_in_reg.c | 49
tests/tests2/131_return_struct_in_reg.expect | 3 ++
3 files changed, 53 insertions(+), 1 deletion(-)
create mode 100644 tests/tests2/131_return_struct_in_reg.c
create mode 100644 tests/tests2/131_return_struct_in_reg.expect
diff --git a/tccgen.c b/tccgen.c
index c582c4a..f91a43d 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -6622,7 +6622,7 @@ static void gfunc_return(CType *func_type)
size = type_size(func_type,);
if ((vtop->r != (VT_LOCAL | VT_LVAL) ||
(vtop->c.i & (ret_align-1)))
-&& (align & (ret_align-1))) {
+|| (align & (ret_align-1))) {
loc = (loc - size) & -ret_align;
addr = loc;
type = *func_type;
diff --git a/tests/tests2/131_return_struct_in_reg.c
b/tests/tests2/131_return_struct_in_reg.c
new file mode 100644
index 000..911b660
--- /dev/null
+++ b/tests/tests2/131_return_struct_in_reg.c
@@ -0,0 +1,49 @@
+#include
+
+#define DATA 0x1234567890abcd, 0x5a5aa5a5f0f00f0f
+
+struct s {
+ long int a;
+ long int b;
+};
+
+struct {
+ struct s d;
+} g = { { DATA } }, *gp =
+
+struct s
+foo1(void)
+{
+ struct s d = { DATA };
+ struct s *p =
+ long int x = 0;
+ return *p;
+}
+
+struct s
+foo2(void)
+{
+ long int unused = 0;
+ return gp->d;
+}
+
+struct s
+foo3(void)
+{
+ struct s d = { DATA };
+ long int unused = 0;
+ return d;
+}
+
+int
+main(void)
+{
+ struct s d;
+ d = foo1();
+ printf("%lx %lx\n", d.a, d.b);
+ d = foo2();
+ printf("%lx %lx\n", d.a, d.b);
+ d = foo3();
+ printf("%lx %lx\n", d.a, d.b);
+ return 0;
+}
diff --git a/tests/tests2/131_return_struct_in_reg.expect
b/tests/tests2/131_return_struct_in_reg.expect
new file mode 100644
index 000..301e3b0
--- /dev/null
+++ b/tests/tests2/131_return_struct_in_reg.expect
@@ -0,0 +1,3 @@
+1234567890abcd 5a5aa5a5f0f00f0f
+1234567890abcd 5a5aa5a5f0f00f0f
+1234567890abcd 5a5aa5a5f0f00f0f
--
2.41.0
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] bcheck:1075-1077 on arm32
On 2023-06-28 21:36, Sagar Acharya via Tinycc-devel wrote: I'm facing this error while building latest master with gcc on armv7 alpine linux. ../tcc -c bcheck.c -o ../bcheck.o -B.. -I.. -g bcheck.c:1075: warning: implicit declaration of function '__ctype_b_loc' bcheck.c:1077: error: pointer expected make[1]: *** [Makefile:85: ../bcheck.o] Error 1 First of all, use mob branch instead of master. And you need to pass option -config-musl to configure script. -- Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] __has_include() ?
On 2023-04-20 03:41, Bernhard Reutner-Fischer wrote:
I don't think we have it yet, do we?
Thoughts? Any takers?
We do have it already.
#if __has_include("/dev/null") && !__has_include("StRanGeNamE")
#define a
#endif
int main()
{
a
return 0;
}
could be compiled and run without an error.
Grepping the commit log also proves that.
--
Ziyao
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] [PATCH] Fix passing of large function arguments on riscv64
Hi list,
I was working with riscv64-tcc and found that it failed to compile this
simple code.
struct foo {
int a[768];
};
void f(struct foo a)
{
(void)a.a[767];
}
int main(void)
{
struct foo a;
f(a);
return 0;
}
riscv64-tcc ended up with an assertion failure.
$ riscv64-tcc test.c -c
Assertion failed: ! ((imm + (1 << 11)) >> 12) (riscv64-gen.c: EI: 135)
Aborted
$ riscv64-tcc -v
tcc version 0.9.27 mob:e7262ac 2023-03-23T20:02:19+01:00 (riscv64
Linux)
It is caused by wrong adjustment of stack in gfunc_call() in
riscv64-gen.c. Instruction ADDIW on riscv64 could accept a 12-bit
immediate number only, which will be sign-extended. So only adjustments
up to 2048 bytes could be done in a single ADDIW instruction. For the
same reasons, more works need done when bit 11 (the 12th bit) of the
immediate number is set.
This patch fixes the problem and has been pushed to mob branch. A
regression test is also included.
---
Ziyao
---
diff --git a/riscv64-gen.c b/riscv64-gen.c
index 490eca7..8a17b70 100644
--- a/riscv64-gen.c
+++ b/riscv64-gen.c
@@ -627,10 +627,14 @@ ST_FUNC void gfunc_call(int nb_args)
if ((vtop->r & VT_VALMASK) == VT_CMP)
gv(RC_INT);
+
if (stack_add) {
-if (stack_add >= 0x1000) {
-o(0x37 | (5 << 7) | (-stack_add & 0xf000)); //lui t0,
upper(v)
-EI(0x13, 0, 5, 5, -stack_add << 20 >> 20); // addi t0, t0,
lo(v)
+if (stack_add >= 0x800) {
+unsigned int bit11 = (((unsigned int)-stack_add) >> 11) &
1;
+o(0x37 | (5 << 7) |
+ ((-stack_add + (bit11 << 12)) & 0xf000)); //lui t0,
upper(v)
+EI(0x13, 0, 5, 5, ((-stack_add & 0xfff) - bit11 * (1 <<
12)));
+ // addi t0,
t0, lo(v)
ER(0x33, 0, 2, 2, 5, 0); // add sp, sp, t0
}
else
@@ -757,9 +761,12 @@ done:
gcall_or_jmp(1);
vtop -= nb_args + 1;
if (stack_add) {
-if (stack_add >= 0x1000) {
-o(0x37 | (5 << 7) | (stack_add & 0xf000)); //lui t0,
upper(v)
-EI(0x13, 0, 5, 5, stack_add << 20 >> 20); // addi t0, t0,
lo(v)
+if (stack_add >= 0x800) {
+unsigned int bit11 = ((unsigned int)stack_add >> 11) & 1;
+o(0x37 | (5 << 7) |
+ ((stack_add + (bit11 << 12)) & 0xf000)); //lui t0,
upper(v)
+EI(0x13, 0, 5, 5, (stack_add & 0xfff) - bit11 * (1 << 12));
+ // addi t0,
t0, lo(v)
ER(0x33, 0, 2, 2, 5, 0); // add sp, sp, t0
}
else
diff --git a/tests/tests2/130_large_argument.c
b/tests/tests2/130_large_argument.c
new file mode 100644
index 000..8415c85
--- /dev/null
+++ b/tests/tests2/130_large_argument.c
@@ -0,0 +1,41 @@
+#include
+
+struct large1 {
+int a[768];
+};
+
+struct large2 {
+int a[1920];
+};
+
+void pass_large_struct1(struct large1 in)
+{
+printf("%d %d\n", in.a[200], in.a[767]);
+return;
+}
+
+void pass_large_struct2(struct large2 in)
+{
+printf("%d %d %d\n", in.a[200], in.a[1023], in.a[1919]);
+return;
+}
+
+void pass_many_args(int a, int b, int c, int d, int e, int f, int g,
int h, int i,
+int j, int k, int l, int m)
+{
+printf("%d %d %d %d %d %d %d %d %d %d %d %d %d\n", a, b, c, d, e,
f, g, h, i,
+ j, k, l, m);
+return;
+}
+
+struct large1 l1 = { .a = { [200] = 1, [767] = 2 } };
+struct large2 l2 = { .a = { [200] = 3, [1023] = 4, [1919] = 5} };
+
+int main(void)
+{
+pass_large_struct1(l1);
+pass_large_struct2(l2);
+pass_many_args(13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1);
+
+return 0;
+}
diff --git a/tests/tests2/130_large_argument.expect
b/tests/tests2/130_large_argument.expect
new file mode 100644
index 000..8c5d9cd
--- /dev/null
+++ b/tests/tests2/130_large_argument.expect
@@ -0,0 +1,3 @@
+1 2
+3 4 5
+13 12 11 10 9 8 7 6 5 4 3 2 1
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] AVR port
On 2023-04-06 21:05, certanan via Tinycc-devel wrote: Hello, everyone. I am thinking of having a shot at porting tcc to the AVR microcontroller family, as an alternative to a part of the bulky GNU toolchain. Since the last release was specified quite a while back, I am inclined to fork at HEAD. However when it comes to 'mob' branches, I am always a bit worried about potential insufficiencies in terms of security and stability. Are those fears justified in this case? mob is actually a development branch, to which new fixes and features are introduced. Sure new features lead to unstability, but there are also lots of fixes for bugs in 0.9.27. And also, release 0.9.27 seems to fail to build on newest glibc, according to historical emails in this list. imho, it should be deprecated now. -- Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Targeted Extensions on RISC-V64
Hi list,
I am trying to make RISC-V 64 support more complete and noted that
there seems to be no 'c' extension support ('c' stands for "compressed",
which is similar to Thumb on ARM). I compiled a simple function which
simply returns 0, and got a object file containing 4-byte
instructions only.
:
0: ff010113addisp,sp,-16
4: 00113423sd ra,8(sp)
8: 00813023sd s0,0(sp)
c: 01010413addis0,sp,16
10: 0013nop
14: 051bsext.w a0,zero
18: 00813083ld ra,8(sp)
1c: 00013403ld s0,0(sp)
20: 01010113addisp,sp,16
24: 8067ret
My question is: what combination of extensions does riscv64-tcc target?
For doubles, instruction fld is used, so I guess 'd' extension must be
included. A common used combination is rv64gc, is it what the original
author of RISC-V 64 backend has intended to support?
--
Ziyao
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Self hosting issues with tcc 0.9.27
On 2023-03-15 21:27, avih via Tinycc-devel wrote: 1. On Ubuntu 64 22.04 LTS (gcc 11.3), tcc 0.9.27 does not build. git clean -xfd git checkout release_0_9_27 ./configure --prefix=$PWD/../tcc0927 make # ends with this error: ../tcc -c bcheck.c -o bcheck.o -B.. bcheck.c:738: error: '__malloc_hook' undeclared make[1]: *** [Makefile:64: bcheck.o] Error 1 As described a few days ago, Glibc has deprecated __malloc_hook since 2.32. Conclusions: - This is not ideal. It's hard to build 0.9.27 these days, and even once built, it fails some tests, and ignoring that, it can build current mob but some tests fail. - Luckily, using this last "broken tests mob" build it is possible to build mob-proper with all tests passing. What might be be ideal, IMVHO, is: - A new release 0.9.27.1 with minimal diff from 0.9.27, which: - Could be built with modern compilers and pass (enabled) tests. - Preferably can be built and pass tests with tcc 0.9.26 too. - Or at least have a documented path to build from 0.9.26. - E.g. maybe just disable bcheck and asm-c-connect-test. - That mob is modified to allow to be built and pass (Enabled) tests using a newly built tcc 0.9.27[.1]. This could be tricky, as I think it would have to be detected in configure tests or options, because tcc version has not changed for years, so hard to test... - maybe add a configure option --with-tcc-0-9-27 or some such. - Finally, a new release (0.9.28 or 1.0, which can be built and pass tests using 0.9.27[.1]), because it's been years, and to serve as a new baseline to build future tcc versions. There used to be a plan for a new release, but it has NOT made any progress. It is true that 0.9.27 is too old, so always sticking to mob may be a wise option... -- Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc latest version and new glibc
I have really waited for a long time for the new release and will vote yes for any version new. -- Ziyao On 2023-02-19 14:47, Christian Jullien wrote: +1 for anything > 0.9.27, really! C. From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Detlef Riekenberg Sent: Saturday, February 18, 2023 22:02 To: tinycc-devel@nongnu.org Cc: gris...@gmx.de Subject: *** SPAM *** Re: [Tinycc-devel] tcc latest version and new glibc Importance: High Hi grischka. Another case, where the latest release makes problems, but current mob works. You said and did nothing about releasing a 0.9.28 from current mob and prepare for a 1.0 release. I already asked some month ago for a release. You also said and did nothing to fix the link issue for i386-tcc on a 64 bit linux machine, which you introduced by reverting my patches. (I did a fresh install of xubuntu 23.04, and the 32bit files are installed in /usr/i686-linux-gnu/include and /usr/i686-linux-gnu/lib, but i have no idea, if there are still systems, which use /usr/i386-linux-gnu/* ) When you need some help, please let us know. -- bye bye ... Detlef ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc latest version and new glibc
On 2023-02-07 07:37, Fausto Saporito wrote: Hello, I’m trying to build the latest version of TCC with glibc 2.34 and __malloc_hook is not present anymore. make[1]: Entering directory '/home/fausap/TC/tcc-0.9.27/lib' It seems that you are working on 0.9.27, which is a quite old version. You may try the latest commit on branch mob, which works fine for me. (I remember there used to be a plan for 1.0.0, btw) -- Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How do I build it?
On 2023-02-06 02:07, Sagar Acharya via Tinycc-devel wrote: Is there a way to fetch a certain version of musl and build it first and then use it for building? Thanking you Building musl needs extra patches both on the compiler itself and musl. Sagar Acharya https://designman.org 5 Feb 2023, 23:14 by tinycc-devel@nongnu.org: I do not want to tamper with system's gcc. I'm on voidlinux musl based on RPI3 aarch64. How do I solve building this? Also, isn't there an issue with having 2 signal.h files? It may not be solved, coz of the lack of (u)int128_t. There may be someone who is happy to add 128-bit integers to TinyCC, but as for now there is not -- Ziyao ___ 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
At 2022-10-14 15:53:56, "Domingo Alvarez Duarte" wrote: >I noticed that there is a github mirror of tinycc repository, maybe it's >a good idea to set a github action there that builds and test it on >windows, mac and linux on every commit. Maybe it is not a good idea. It seems to be synced manually, so the repository is not always up to date. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks
On Wed, Jul 13, 2022 at 12:01:57PM +0200, grischka wrote: > Is it necessary or a good idea to remove that behavior/feature now > from tcc? > I've seen no arguments. Sorry for my impulsive decision. It is a valuable feature to be honest but supposed to be described in document I think. As for me,I agree with Vincent and am wishing to make TinyCC throw a warning in this case at least,because it seems exactly to break the language rules. Maybe we could revert this commit,keep this feature but make TinyCC print a message when -Wall option is specified. Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks
On Tue, Jul 12, 2022 at 03:17:09PM +0200, Vincent Lefevre wrote:
> First, this breaks the ISO C syntax rules, thus a diagnostic is
> required by the standard. Moreover, a multiline #define like that
> (without backslash + newline) is unintuitive. So I would say that
> the code should be rejected.
I have made a simple patch and pushed it towards the git repository.
It will throw an error if there is no terminating character of a string at
the end of line.A part of tcctest3 related to this issue is deleted.
Ziyao
---
diff --git a/tccpp.c b/tccpp.c
index 25654b2..f070640 100644
--- a/tccpp.c
+++ b/tccpp.c
@@ -944,19 +944,16 @@ static uint8_t *parse_pp_string(uint8_t *p,
}
}
} else if (c == '\n') {
-file->line_num++;
-goto add_char;
+tcc_error("missing terminating %c character",sep);
} else if (c == '\r') {
PEEKC_EOB(c, p);
if (c != '\n') {
if (str)
cstr_ccat(str, '\r');
} else {
-file->line_num++;
-goto add_char;
+tcc_error("missing terminating %c character",sep);
}
} else {
-add_char:
if (str)
cstr_ccat(str, c);
p++;
diff --git a/tests/tcctest.c b/tests/tcctest.c
index e969c76..f7fbd65 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -4253,11 +4253,6 @@ void func_arg_test(void)
/* gcc 2.95.3 does not handle correctly CR in strings or after strays */
#define CORRECT_CR_HANDLING
-/* deprecated and no longer supported in gcc 3.3 */
-#ifdef __TINYC__
-# define ACCEPT_CR_IN_STRINGS
-#endif
-
/* keep this as the last test because GCC messes up line-numbers
with the ^L^K^M characters below */
void whitespace_test(void)
@@ -4279,20 +4274,6 @@ ntf("aaa=%d\n", 3);
\
ntf("min=%d\n", 4);
-#ifdef ACCEPT_CR_IN_STRINGS
-printf("len1=%d\n", strlen("
-"));
-#ifdef CORRECT_CR_HANDLING
-str = "
-";
-printf("len1=%d str[0]=%d\n", strlen(str), str[0]);
-#endif
-printf("len1=%d\n", strlen("
a
-"));
-#else
-printf("len1=1\nlen1=1 str[0]=10\nlen1=3\n");
-#endif /* ACCEPT_CR_IN_STRINGS */
-
#ifdef __LINE__
printf("__LINE__ defined\n");
#endif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks
- Original Message - From: "Vincent Lefevre" To: tinycc-devel@nongnu.org Sent: Tue, 12 Jul 2022 02:44:50 +0200 Subject: Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks > That's why I said that there should be > a diagnostic. So the missing diagnostic with tcc is a bug. > If the program is not rejected, the behavior is undefined. So is it better to throw an error and then stop compiling here like gcc?Or just print a warning? I am going to make a patch for this Ziyao___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks
On Mon, Jul 11, 2022 at 05:47:31PM +0200, Domingo Alvarez Duarte wrote: > Hello Ziyao ! > > Although gcc compiles a file containing your example with warnings, I'm not > sure it's worth try to do the same in TiinyCC the preprocessor probably uses > TOKENS from the lexer to decide to skip till the end of the initial "#if 0" > and '"' is not a valid token the error probably come from the lexer that > found a non terminated string. > For conditional inclusion,C99 document says: Only the first group whose control condition evaluates to true (nonzero) is processed. If none of the conditions evaluates to true, and there is a #else directive, the group controlled by the #else is processed; lacking a #else directive, all the groups until the #endif are skipped.1 In my understanding,the skipped part should NOT be processed. Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks
> while with tcc: > > zira:~> tcc -E err.c > # 1 "err.c" > # 1 "" 1 > # 2 "err.c" 2 > > > " > FOO > " > "FOO" > > which makes more sense as an extension, IMHO. But tcc doesn't give > any diagnostic there, and I think that this is incorrect. It seems that TinyCC parses the first three lines as a string literature,does't it? But according to C99 standard, string-literal: " s-char-sequenceopt " L" s-char-sequenceopt " s-char-sequence: s-char s-char-sequence s-char s-char: any member of the source character set except the double-quote ", backslash \, or new-line character escape-sequence New-line character cannot be included in a string literature. Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks
Hi list, When I was compiling Bash with TinyCC,an error occurred. The simpliest example is like below: #if 0 " #if 0 " #endif #endif Code within #if 0 ... end block should be ignored.But this code breaks TinyCC.TinyCC seems to analyse the string inside the useless code block. As many use #if 0 blocks as comments,maybe this is valuable to fix. Tons of thanks for your help Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Optimise Copying Small Structures
Hi list, I have recently pushed a commit(3715fd) which apply the optimisation I have mentioned earlier here. Everything works well except test 112_backtrace.Because my commit make the error messages of bound checks vary from platform to platform.For example,on x86_64 (the only platform effected by this commit) it would be at f1: BCHECK: invalid pointer , size 0x? in struct copy destination while on uneffected platforms, at f1: BCHECK: invalid pointer , size 0x? in memmove dest This is because on x86_64 the calls to memmove has been replaced by a series of instructions with an additional bound check function. To make the test process continue,another commit 2d210fe has been pushed to disable test 112_backtrace on x86_64.Then it is tested both on x86_64 Debian11 and x86_64 Alpine 3.16. If you think this is not the proper way to deal with the test,simply revert commit 2d210fe. Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Optimize Copying Small Structures
Hi list,
I am working on deal with the calls to memcpy() and memmove() in native
code generated by TinyCC.As of now,I have made this patch to optimize
the copying of small-sized structures.
But it seems to break a test (112_backtrace). I am not familiar with the
bound check part of TinyCC.Could anyone try this patch and give me some
help about bound check?
Tons of thanks for your help
Ziyao
---
diff --git a/tcc.h b/tcc.h
index 9bc12e3..34db372 100644
--- a/tcc.h
+++ b/tcc.h
@@ -1644,6 +1644,8 @@ ST_FUNC void gen_increment_tcov (SValue *sv);
/* x86_64-gen.c */
#ifdef TCC_TARGET_X86_64
+#define TCC_TARGET_NATIVE_STRUCT_COPY
+ST_FUNC void gen_struct_copy(int size);
ST_FUNC void gen_addr64(int r, Sym *sym, int64_t c);
ST_FUNC void gen_opl(int op);
#ifdef TCC_TARGET_PE
diff --git a/tccgen.c b/tccgen.c
index c170ff3..5e7e002 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -3474,9 +3474,37 @@ ST_FUNC void vstore(void)
if (sbt == VT_STRUCT) {
/* if structure, only generate pointer */
/* structure assignment : generate memcpy */
-/* XXX: optimize if small size */
size = type_size(>type, );
+#ifdef TCC_TARGET_NATIVE_STRUCT_COPY
+if (size <= (PTR_SIZE << 4)) {
+ vswap();
+#ifdef CONFIG_TCC_BCHECK
+if (vtop->r & VT_MUSTBOUND)
+gbound();
+#endif
+vtop->type.t = VT_PTR;
+gaddrof();
+#ifdef CONFIG_TCC_BCHECK
+if (vtop->r & VT_MUSTBOUND)
+gbound();
+#endif
+
+vpushv(vtop - 1);
+#ifdef CONFIG_TCC_BCHECK
+if (vtop->r & VT_MUSTBOUND)
+gbound();
+#endif
+vtop->type.t = VT_PTR;
+gaddrof(); /* src dest src */
+#ifdef CONFIG_TCC_BCHECK
+if (vtop->r & VT_MUSTBOUND)
+gbound();
+#endif
+
+gen_struct_copy(size);
+} else {
+#endif
/* destination */
vswap();
#ifdef CONFIG_TCC_BCHECK
@@ -3510,7 +3538,9 @@ ST_FUNC void vstore(void)
vpushi(size);
gfunc_call(3);
/* leave source on stack */
-
+#ifdef TCC_TARGET_NATIVE_STRUCT_COPY
+}
+#endif
} else if (ft & VT_BITFIELD) {
/* bitfield store handling */
diff --git a/x86_64-gen.c b/x86_64-gen.c
index 29871d5..cad4da1 100644
--- a/x86_64-gen.c
+++ b/x86_64-gen.c
@@ -2282,6 +2282,56 @@ ST_FUNC void gen_vla_alloc(CType *type, int align) {
}
}
+/*
+ * Assmuing the top part of the stack looks like below,
+ * src dest src
+ */
+void gen_struct_copy(int size)
+{
+save_reg(TREG_RSI);
+load(TREG_RSI,vtop);
+vtop->r = TREG_RSI;
+vswap();/* dest src src */
+save_reg(TREG_RDI);
+load(TREG_RDI,vtop);
+vtop->r = TREG_RDI;
+/* Not aligned by 8bytes */
+if (size & 0x04) {
+o(0xa5);
+}
+if (size & 0x02) {
+o(0xa566);
+}
+if (size & 0x01) {
+o(0xa4);
+}
+
+size >>= 3;
+if (!size)
+goto done;
+/* Although this function is only called when the struct is smaller*/
+/* than 32 bytes(4 * PTR_SIZE),a common implementation is included */
+if (size <= 4 && size) {
+switch (size) {
+case 4: o(0xa548);
+case 3: o(0xa548);
+case 2: o(0xa548);
+case 1: o(0xa548);
+}
+} else {
+save_reg(TREG_RCX);
+vpushi(size);
+load(TREG_RCX,vtop);
+vtop->r = TREG_RCX;
+o(0xa548f3);
+vpop();
+}
+done:
+vpop();
+vpop();
+return;
+}
+
/* end of x86-64 code generator */
/*/
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] new tcc release
I vote yes.It is the time for a new release. On Fri, Jul 08, 2022 at 01:39:43AM +0200, Detlef Riekenberg wrote: > The last tcc release is very old, and tcc has received > many fixes and new features since then.What are the plans for > a new release?I vote for a 0.9.28 rc with the current > features, see, what simple fixes are possible and then make a > release in the next weeks.(Would help distros to include a recent > tcc)Afterwarde prepare for tcc 1.0 later this year.That would > make it possible for distros to addtcc 1.0 in there spring/LTS > releases.Unfortunately, we missed the 20. anniversary for tcc > 1.0(first commit: 27. Oct. 2001),but releasing at the 21. > anniversary is still possible.For 1.0, i vote for fixing more > bugs and verified C99 support, either excluding Complex math or > with optional Complex math (enable during configure, but defaults > off)tcc already understand some C11 featuresand > newer extensions (example: __has_include)but the related implementation > is missing or buggy (_Atomic)I would see fixes for C11 things > as cool, when working, but optional for tcc 1.0.What > are you think?-- Regards, > Detlef ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Constant Initializer for Static Variables
Hi list,
I recently found that TinyCC complaint about code like this
int main(void)
{
const int one = 1;
static const int a = one; // error: initializer element is
// not constant
return 0;
}
But GCC10 and Clang11 both accept it.
Ziyao
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Linking with libtcc1.a
Hi list, I am working to port musl to TinyCC.Because musl is an implementation of libc,-nostdlib option is used to stop TinyCC from linking the standard libc to the executable files. But -nostdlib option also prevents TinyCC from linking libtcc1.a,which contains serveral runtime functions (e.g. __va_arg).As for GCC,its manual points out that using -lgcc option may be needed to work with -nostdlib option.But it seems that there is no way to make TinyCC add libtcc1.a to the executable file.Simply adding "-ltcc1" does not work because libtcc1.a is not in the usual library searching path. Will there be a solution for this? Ziyao ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Enabling TinyCC to Create Empty Archives
On Mon, Apr 04, 2022 at 11:03:11AM +0800, Ziyao wrote:
> Hi list,
>
> On my machine (x86_64 Ubuntu 18.04LTS,GNU ar 2.30),it is OK to create an
> empty archive with
> ar rc libempty.a
> This will create libempty.a which only contains an ar archive header.
>
> But TinyCC refuses to do that:
> tcc -ar rc libempty.a # This will print the usage
> I made a patch for that.
I recently found that after applying the patch,creating an empty archive
in the above way will make TinyCC return 2,which breaks the building
progress of make.
A new fix is contained in this mail.
Best wishes,
Ziyao
---
diff --git a/tcctools.c b/tcctools.c
index 4567b81..2bcc990 100644
--- a/tcctools.c
+++ b/tcctools.c
@@ -61,7 +61,7 @@ static int contains_any(const char *s, const char *list) {
}
static int ar_usage(int ret) {
-fprintf(stderr, "usage: tcc -ar [rcsv] lib file...\n");
+fprintf(stderr, "usage: tcc -ar [rcsv] lib [file...]\n");
fprintf(stderr, "create library ([abdioptxN] not supported).\n");
return ret;
}
@@ -115,8 +115,9 @@ ST_FUNC int tcc_tool_ar(TCCState *s1, int argc, char **argv)
}
}
-if (!i_obj) // i_obj implies also i_lib. we require both.
+if (!i_lib) // i_obj implies also i_lib.
ret = 1;
+i_obj = i_obj ? i_obj : argc; // An empty archive will be generated if no
input file is given
if (ret == 1)
return ar_usage(ret);
@@ -242,6 +243,11 @@ ST_FUNC int tcc_tool_ar(TCCState *s1, int argc, char
**argv)
hofs++, fpos = 1;
// write header
fwrite("!\n", 8, 1, fh);
+// create an empty archive
+if (!funccnt) {
+ret = 0;
+goto the_end;
+}
sprintf(stmp, "%-10d", (int)(strpos + (funccnt+1) * sizeof(int)));
memcpy(_size, stmp, 10);
fwrite(, sizeof(arhdr), 1, fh);
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] [PATCH] Add Support of SSE Instructions ldmxcsr and stmxcsr
Hi list, I have made a patch which adds the support of two SEE instructions to TinyCC --ldmxcsr and stmxcsr.Both x86_64 and i386 build have been tested on Ubuntu 18.04LTS and they generate proper machine code which is the same as what GNU as does.It only includes 4 lines. Best wishes, Ziyao diff --git a/i386-asm.h b/i386-asm.h index 65d5179..dfc5183 100644 --- a/i386-asm.h +++ b/i386-asm.h @@ -447,6 +447,8 @@ ALT(DEF_ASM_OP2(psrlq, 0x0f73, 2, OPC_MODRM, OPT_IM8, OPT_MMXSSE )) DEF_ASM_OP2(pxor, 0x0fef, 0, OPC_MODRM, OPT_EA | OPT_MMXSSE, OPT_MMXSSE ) /* sse */ +DEF_ASM_OP1(ldmxcsr, 0x0fae, 2, OPC_MODRM, OPT_EA) +DEF_ASM_OP1(stmxcsr, 0x0fae, 3, OPC_MODRM, OPT_EA) DEF_ASM_OP2(movups, 0x0f10, 0, OPC_MODRM, OPT_EA | OPT_REG32, OPT_SSE ) ALT(DEF_ASM_OP2(movups, 0x0f11, 0, OPC_MODRM, OPT_SSE, OPT_EA | OPT_REG32 )) DEF_ASM_OP2(movaps, 0x0f28, 0, OPC_MODRM, OPT_EA | OPT_REG32, OPT_SSE ) diff --git a/x86_64-asm.h b/x86_64-asm.h index cb9eb16..4e03773 100644 --- a/x86_64-asm.h +++ b/x86_64-asm.h @@ -483,6 +483,8 @@ ALT(DEF_ASM_OP2(psrlq, 0x0f73, 2, OPC_MODRM, OPT_IM8, OPT_MMXSSE )) DEF_ASM_OP2(pxor, 0x0fef, 0, OPC_MODRM, OPT_EA | OPT_MMXSSE, OPT_MMXSSE ) /* sse */ +DEF_ASM_OP1(ldmxcsr, 0x0fae, 2, OPC_MODRM, OPT_EA) +DEF_ASM_OP1(stmxcsr, 0x0fae, 3, OPC_MODRM, OPT_EA) DEF_ASM_OP2(movups, 0x0f10, 0, OPC_MODRM, OPT_EA | OPT_REG32, OPT_SSE ) ALT(DEF_ASM_OP2(movups, 0x0f11, 0, OPC_MODRM, OPT_SSE, OPT_EA | OPT_REG32 )) DEF_ASM_OP2(movaps, 0x0f28, 0, OPC_MODRM, OPT_EA | OPT_REG32, OPT_SSE ) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Enabling TinyCC to Create Empty Archives
Hi list,
On my machine (x86_64 Ubuntu 18.04LTS,GNU ar 2.30),it is OK to create an
empty archive with
ar rc libempty.a
This will create libempty.a which only contains an ar archive header.
But TinyCC refuses to do that:
tcc -ar rc libempty.a # This will print the usage
I made a patch for that.
musl libc uses this feature to create dummy libraries(it combines all
libraries into a single file,rather than many libraries like libc.a,libm.a
etc.Dummy libraries are used to avoid linking errors when using common
linking flags like -lm).
I do not know whether there are other projects using this feature.But I
think it is a good idea to keep compatible with GNU ar.
Best wishes,
Ziyao
-
diff --git a/tcctools.c b/tcctools.c
index 4567b81..7c643dc 100644
--- a/tcctools.c
+++ b/tcctools.c
@@ -61,7 +61,7 @@ static int contains_any(const char *s, const char *list) {
}
static int ar_usage(int ret) {
-fprintf(stderr, "usage: tcc -ar [rcsv] lib file...\n");
+fprintf(stderr, "usage: tcc -ar [rcsv] lib [file...]\n");
fprintf(stderr, "create library ([abdioptxN] not supported).\n");
return ret;
}
@@ -115,8 +115,9 @@ ST_FUNC int tcc_tool_ar(TCCState *s1, int argc, char **argv)
}
}
-if (!i_obj) // i_obj implies also i_lib. we require both.
+if (!i_lib) // i_obj implies also i_lib.
ret = 1;
+i_obj = i_obj ? i_obj : argc; // An empty archive will be generated if no
input file is given
if (ret == 1)
return ar_usage(ret);
@@ -242,6 +243,9 @@ ST_FUNC int tcc_tool_ar(TCCState *s1, int argc, char **argv)
hofs++, fpos = 1;
// write header
fwrite("!\n", 8, 1, fh);
+// create an empty archive
+if (!funccnt)
+goto the_end;
sprintf(stmp, "%-10d", (int)(strpos + (funccnt+1) * sizeof(int)));
memcpy(_size, stmp, 10);
fwrite(, sizeof(arhdr), 1, fh);
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] A Patch for -dumpmachine Option
Hi list,
I have made a small patch which adds option "-dumpmachine" support to
TinyCC.This option is widely supported by both gcc and clang.Some configure
scripts detect the platform information by passing this option to the
C compiler,such as musl libc.
And by the way,what is the proper way to contribute? Just send patches to
this maillist or what?Should I send a normal patch or formatted patch?
Thanks for answering.
(To avoid messing the plaintext mail readers up,I add my patch to the bottom
of this mail.)
Cheers,
Ziyao
--
diff --git a/libtcc.c b/libtcc.c
index b6dbb01..6e5cf17 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1456,6 +1456,7 @@ enum {
TCC_OPTION_g,
TCC_OPTION_c,
TCC_OPTION_dumpversion,
+TCC_OPTION_DUMPMACHINE,
TCC_OPTION_d,
TCC_OPTION_static,
TCC_OPTION_std,
@@ -1488,7 +1489,7 @@ enum {
TCC_OPTION_MMD,
TCC_OPTION_x,
TCC_OPTION_ar,
-TCC_OPTION_impdef,
+TCC_OPTION_impdef
};
#define TCC_OPTION_HAS_ARG 0x0001
@@ -1518,6 +1519,7 @@ static const TCCOption tcc_options[] = {
{ "g", TCC_OPTION_g, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
{ "c", TCC_OPTION_c, 0 },
{ "dumpversion", TCC_OPTION_dumpversion, 0},
+{ "dumpmachine", TCC_OPTION_DUMPMACHINE , 0 },
{ "d", TCC_OPTION_d, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
{ "static", TCC_OPTION_static, 0 },
{ "std", TCC_OPTION_std, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
@@ -1952,6 +1954,8 @@ reparse:
printf ("%s\n", TCC_VERSION);
exit(0);
break;
+case TCC_OPTION_DUMPMACHINE:
+return OPT_DUMPMACHINE;
case TCC_OPTION_x:
x = 0;
if (*optarg == 'c')
diff --git a/tcc.c b/tcc.c
index 42a251b..ed9c143 100644
--- a/tcc.c
+++ b/tcc.c
@@ -95,6 +95,7 @@ static const char help2[] =
" -isystem dir add 'dir' to system include path\n"
" -static link to static libraries (not
recommended)\n"
" -dumpversion print version\n"
+" -dumpmachine print platform information\n"
" -print-search-dirsprint search paths\n"
" -dt with -run/-E: auto-define 'test_...'
macros\n"
"Ignored options:\n"
@@ -289,6 +290,47 @@ redo:
return 0;
++opt;
}
+
+if (opt == OPT_DUMPMACHINE) {
+fputs(
+#ifdef TCC_TARGET_I386
+"i386"
+#elif defined TCC_TARGET_X86_64
+"x86_64"
+#elif defined TCC_TARGET_C67
+"c67"
+#elif defined TCC_TARGET_ARM
+"arm"
+# ifdef TCC_ARM_EABI
+" eabi"
+# ifdef TCC_ARM_HARDFLOAT
+"hf"
+# endif
+# endif
+#elif defined TCC_TARGET_ARM64
+"aarch64"
+#elif defined TCC_TARGET_RISCV64
+"riscv64"
+#endif
+ "-"
+#ifdef TCC_TARGET_PE
+"windows"
+#elif defined(TCC_TARGET_MACHO)
+"darwin"
+#elif TARGETOS_FreeBSD || TARGETOS_FreeBSD_kernel
+"freebsd"
+#elif TARGETOS_OpenBSD
+"openbsd"
+#elif TARGETOS_NetBSD
+"netbsd"
+#else
+"linux"
+#endif
+"-tcc\n",stdout);
+return 0;
+
+}
+
if (opt == OPT_HELP2) {
fputs(help2, stdout);
return 0;
diff --git a/tcc.h b/tcc.h
index 9724848..3812241 100644
--- a/tcc.h
+++ b/tcc.h
@@ -1279,6 +1279,7 @@ ST_FUNC char *tcc_load_text(int fd);
#define OPT_PRINT_DIRS 4
#define OPT_AR 5
#define OPT_IMPDEF 6
+#define OPT_DUMPMACHINE 7
#define OPT_M32 32
#define OPT_M64 64
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
