Re: [Tinycc-devel] TinyCC -std=c2x support?
Another thought would be to weigh the effect of potential patches to tcc on compile-time and run-time performance. In this benchmark, tcc 0.9.27 has the fastest compile and run times compared to several other compilers: https://github.com/nordlow/compiler-benchmark It mentions that gcc and clang get "significantly worse performance with each new release". While I can't personally vouch for the quality of that benchmark, the idea would be to have _some_ benchmark as a line in the sand that would help keep tcc from bloat when considering modifications. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC -std=c2x support?
Hello Christian and list, >> Since when do we tell other people what to do and until when, in tinycc? > I'm sorry about that. You're right it is not my role. Thanks for sharing your ideas and suggestions. Here are some of mine (which overlap some of what you mentioned): Short: In general, keep doing what they have been doing on the compiler itself. Getting a list of project goals, priorities, and a policy on patches would help everyone. (If anarchy is the policy, that would be nice to know as well. ;) Consider an updated release. Long: My use of tcc includes: 1) Dynamic code compilation and execution for geometric modeling 2) R on reduced power consumption computing 3) Further study on compiler design/implementation, with a focus on minimalism 4) Work on compile-time meta-programming and OO with C I'm fairly sure 1 and 4 are going to require me to fork or rewrite tcc in a production system, due to code size/complexity increases--it would approach MediumCC. Item 3 is an important use for me, though, with the existing tcc. It is great to have a compact, comprehensible compiler like tcc as a model for study. Tcc is used in at least one minimal, reproducible bootstrapping project (GNU Mes, which mentions having to use a patched tcc--why I don't currently know). Tcc could have a role in Item 2, even substantially "as-is". One focus of tcc seems to be on compile-time performance, which is important during development for energy efficiency and shorter build turn-around-time. A compiler which generates more highly-optimized code could be used for released software. Currently, my 3D modeling software does textual C code generation from an external, pre-optimized AST, which is then dynamically compiled and run with an unpatched tcc. The dynamic code generation feature of tcc has been an very valuable feature for my prototype of this project. My suggestion of a list of priorities would be (in increasing order): A) Fix known bugs before adding new features B) Add regression tests for (A) C) Work towards more complete standard compliancy D) Add tests for demonstration of (C) E) Keep it simple, keep it small, keep compilation time fast F) Compatibility with other projects, (my opinionated list): a) the Linux kernel (version?) b) other tiny compilers like Mes or Femtolisp c) musl d) C container template library G) Additional external (gcc, MS) extensions, especially for platform support, remembering (E) Having a (not necessarily strict) list of priorities could reduce the workload of the devs/maintainers and reduce uncertainty when considering patches. -Original Message- From: Christian Jullien To: tinycc-devel@nongnu.org Sent: Tue, Jun 22, 2021 5:18 am Subject: Re: [Tinycc-devel] TinyCC -std=c2x support? Hello Grischka, > Since when do we tell other people what to do and until when, in tinycc? I'm sorry about that. You're right it is not my role. I wrote this because I see many positive energies to improve TinyCC but we lack clear directives to where we want to go and what it is allowed to do or not. Some push (sometimes) wrong patches without asking other ask but get no replies. They give up or, worse, fork! I use daily tcc as my main C compiler but I still don't know what is its goal and where it goes. Among things I understand (unsorted), tcc is: - tiny, but it is no longer true, I prefer to say it is small. - fast to compile, really true this time - conforming to C standard (which ones?), what should be the main efforts? C90 probably almost complete C99 not complete, it lacks complex C11 most new features but other are missing C2X none, that's why I suggested to start support and add -sdt=c2x as -std=c11 - Able to compile Linux kernel, which version? Chase recently made this request: [FEATURE REQUEST] asm-goto and got no replies. Do we want to support him? - Compatible with gcc and VC++ (until which point?), for example to you want we add __faststorefence() to allow concurrent access of SQLite on Windows as recently proposed? About commits, it would be nice to have a rule, like summit a patch and expect a reply from maintainers within a "reasonable" amount of time: accepted, rejected, postponed, Another thing, I know it seems you're reluctant to make a new official version (e.g. 0.9.28) but many distributions use only the official and quite old 0.9.27 version and users complain with bugs which have been fixed long ago. That's why I added recently the git short version to -v option. Can you consider to make a new official version anytime soon? I probably miss many other things that will help us (and maintainers) to know how improve tcc. Christian P.S. we all love tcc -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of grischka Sent: Monday, June 21, 2021 22:25 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Tin
Re: [Tinycc-devel] TinyCC -std=c2x support?
On Tue, 22 Jun 2021, Christian Jullien wrote: I see many positive energies to improve TinyCC but we lack clear directives to where we want to go and what it is allowed to do or not. I use daily tcc as my main C compiler but I still don't know what is its goal and where it goes About commits, it would be nice to have a rule, like summit a patch and expect a reply from maintainers within a "reasonable" amount of time: accepted, rejected, postponed, I agree with all of these. P.S. we all love tcc <3 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC -std=c2x support?
Hello Grischka, > Since when do we tell other people what to do and until when, in tinycc? I'm sorry about that. You're right it is not my role. I wrote this because I see many positive energies to improve TinyCC but we lack clear directives to where we want to go and what it is allowed to do or not. Some push (sometimes) wrong patches without asking other ask but get no replies. They give up or, worse, fork! I use daily tcc as my main C compiler but I still don't know what is its goal and where it goes. Among things I understand (unsorted), tcc is: - tiny, but it is no longer true, I prefer to say it is small. - fast to compile, really true this time - conforming to C standard (which ones?), what should be the main efforts? C90 probably almost complete C99 not complete, it lacks complex C11 most new features but other are missing C2X none, that's why I suggested to start support and add -sdt=c2x as -std=c11 - Able to compile Linux kernel, which version? Chase recently made this request: [FEATURE REQUEST] asm-goto and got no replies. Do we want to support him? - Compatible with gcc and VC++ (until which point?), for example to you want we add __faststorefence() to allow concurrent access of SQLite on Windows as recently proposed? About commits, it would be nice to have a rule, like summit a patch and expect a reply from maintainers within a "reasonable" amount of time: accepted, rejected, postponed, Another thing, I know it seems you're reluctant to make a new official version (e.g. 0.9.28) but many distributions use only the official and quite old 0.9.27 version and users complain with bugs which have been fixed long ago. That's why I added recently the git short version to -v option. Can you consider to make a new official version anytime soon? I probably miss many other things that will help us (and maintainers) to know how improve tcc. Christian P.S. we all love tcc -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of grischka Sent: Monday, June 21, 2021 22:25 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] TinyCC -std=c2x support? Christian Jullien wrote: > Hi no one complains or comments, I suggest you push your patches end of June Since when do we tell other people what to do and until when, in tinycc? -- gr ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC -std=c2x support?
Christian Jullien wrote: Hi no one complains or comments, I suggest you push your patches end of June Since when do we tell other people what to do and until when, in tinycc? -- gr ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC -std=c2x support?
Hi no one complains or comments, I suggest you push your patches end of June
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Christian Jullien
Sent: Friday, June 18, 2021 13:21
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] TinyCC -std=c2x support?
Hi Elijah,
I'm not a maintainer but as far as I see, I vote a big YES for your patch.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Elijah Stone
Sent: Friday, June 18, 2021 12:24
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] TinyCC -std=c2x support?
On Fri, 18 Jun 2021, Christian Jullien wrote:
> C evolves and supports new features over the time.
>
> Do we want to support upcoming features like prototypes without
> parameters (as in C++)?
I think it would be a good idea. As far as I can tell, the current c2x
draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf) entails
the following compiler changes:
+ void f(int) {} (N2480)
+ single-argument _Static_assert (N2265) (already implemented) get rid
+ of k definitions (N2432)
+ also: void foo(){} is equivalent to void foo(void){}. The meaning of
void foo() (just a prototype) is unchanged + allow labels to precede
declarations (e.g. lb: int x;) (N2508) + 'true' and 'false' have type
bool (N2393)
- use of booleans in arithmetic expressions is 'deprecated'; consider
emiting warnings?
+ support binary literals (N2549, already supported as a gnu ext.
Actually as a 'tcc ext', but it's a gnu ext)
- u8'x' -> (unsigned char)'x' (N2418)
- u8"", U"" et al (from c11) are already not supported, need to add them
- mixed-type literal concatenation is now illegal (u"" U"" is an error;
"" u"" is fine though. See above) (N2594)
- Change rules about conversions of pointers to qualified arrays (N2607)
- [[attributes]] (N2335)
I've attached a patch implementing the changes marked '+'. Currently
they're all guarded behind -std=c2x, but perhaps that should be limited to
the backwards-incompatible ones?
-E
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC -std=c2x support?
Hi Elijah,
I'm not a maintainer but as far as I see, I vote a big YES for your patch.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Elijah Stone
Sent: Friday, June 18, 2021 12:24
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] TinyCC -std=c2x support?
On Fri, 18 Jun 2021, Christian Jullien wrote:
> C evolves and supports new features over the time.
>
> Do we want to support upcoming features like prototypes without
> parameters (as in C++)?
I think it would be a good idea. As far as I can tell, the current c2x
draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf) entails
the following compiler changes:
+ void f(int) {} (N2480)
+ single-argument _Static_assert (N2265) (already implemented) get rid
+ of k definitions (N2432)
+ also: void foo(){} is equivalent to void foo(void){}. The meaning of
void foo() (just a prototype) is unchanged + allow labels to precede
declarations (e.g. lb: int x;) (N2508) + 'true' and 'false' have type
bool (N2393)
- use of booleans in arithmetic expressions is 'deprecated'; consider
emiting warnings?
+ support binary literals (N2549, already supported as a gnu ext.
Actually as a 'tcc ext', but it's a gnu ext)
- u8'x' -> (unsigned char)'x' (N2418)
- u8"", U"" et al (from c11) are already not supported, need to add them
- mixed-type literal concatenation is now illegal (u"" U"" is an error;
"" u"" is fine though. See above) (N2594)
- Change rules about conversions of pointers to qualified arrays (N2607)
- [[attributes]] (N2335)
I've attached a patch implementing the changes marked '+'. Currently
they're all guarded behind -std=c2x, but perhaps that should be limited to
the backwards-incompatible ones?
-E
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC -std=c2x support?
On Fri, 18 Jun 2021, Christian Jullien wrote:
C evolves and supports new features over the time.
Do we want to support upcoming features like prototypes without
parameters (as in C++)?
I think it would be a good idea. As far as I can tell, the current c2x
draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf) entails
the following compiler changes:
+ void f(int) {} (N2480)
+ single-argument _Static_assert (N2265) (already implemented)
+ get rid of k definitions (N2432)
+ also: void foo(){} is equivalent to void foo(void){}. The meaning of
void foo() (just a prototype) is unchanged + allow labels to precede
declarations (e.g. lb: int x;) (N2508) + 'true' and 'false' have type
bool (N2393)
- use of booleans in arithmetic expressions is 'deprecated'; consider
emiting warnings?
+ support binary literals (N2549, already supported as a gnu ext.
Actually as a 'tcc ext', but it's a gnu ext)
- u8'x' -> (unsigned char)'x' (N2418)
- u8"", U"" et al (from c11) are already not supported, need to add them
- mixed-type literal concatenation is now illegal (u"" U"" is an error;
"" u"" is fine though. See above) (N2594)
- Change rules about conversions of pointers to qualified arrays (N2607)
- [[attributes]] (N2335)
I've attached a patch implementing the changes marked '+'. Currently
they're all guarded behind -std=c2x, but perhaps that should be limited to
the backwards-incompatible ones?
-Ediff --git a/include/stdbool.h b/include/stdbool.h
index d2ee446..8fcd97b 100644
--- a/include/stdbool.h
+++ b/include/stdbool.h
@@ -4,8 +4,13 @@
/* ISOC99 boolean */
#define bool _Bool
-#define true 1
-#define false 0
+#if __STDC_VERSION__ >= 202000L
+# define true ((_Bool)1)
+# define false ((_Bool)0)
+#else
+# define true 1
+# define false 0
+#endif
#define __bool_true_false_are_defined 1
#endif /* _STDBOOL_H */
diff --git a/libtcc.c b/libtcc.c
index ec33591..c46fd49 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -782,7 +782,6 @@ LIBTCCAPI TCCState *tcc_new(void)
#undef gnu_ext
s->gnu_ext = 1;
-s->tcc_ext = 1;
s->nocommon = 1;
s->dollars_in_identifiers = 1; /*on by default like in gcc/clang*/
s->cversion = 199901; /* default unless -std=c11 is supplied */
@@ -1808,10 +1807,32 @@ reparse:
case TCC_OPTION_static:
s->static_link = 1;
break;
-case TCC_OPTION_std:
-if (strcmp(optarg, "=c11") == 0)
-s->cversion = 201112;
+case TCC_OPTION_std: {
+const char *targ = optarg;
+if (strncmp(targ, "=gnu", 4) == 0) {
+s->gnu_ext = 1;
+targ += 4;
+} else if (strncmp(targ, "=c", 2) == 0) {
+/*s->gnu_ext = 0;*/ /*TODO- tccdefs requires gnu extensions*/
+targ += 2;
+} else {
+tcc_warning("no such version '%s'", optarg);
+break;
+}
+if (strcmp(targ, "89") == 0)
+s->cversion = 199409L;
+else if (strcmp(targ, "99") == 0)
+s->cversion = 199901L;
+else if (strcmp(targ, "11") == 0)
+s->cversion = 201112L;
+else if (strcmp(targ, "17") == 0 || strcmp(targ, "18") == 0)
+s->cversion = 201710L;
+else if (strcmp(targ, "2x") == 0)
+s->cversion = 202000L;
+else
+tcc_warning("no such version '%s'", optarg);
break;
+}
case TCC_OPTION_shared:
x = TCC_OUTPUT_DLL;
goto set_output_type;
diff --git a/tccgen.c b/tccgen.c
index c36032a..ed26711 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -1283,6 +1283,8 @@ ST_FUNC Sym *sym_push(int v, CType *type, int r, int c)
Sym *s, **ps;
TokenSym *ts;
+if (!v)
+return NULL;
if (local_stack)
ps = _stack;
else
@@ -5364,17 +5366,19 @@ static int post_type(CType *type, AttributeDef *ad, int
storage, int td)
if (tok == '(') {
/* function type, or recursive declarator (return if so) */
next();
- if (td && !(td & TYPE_ABSTRACT))
- return 0;
- if (tok == ')')
- l = 0;
- else if (parse_btype(, ))
- l = FUNC_NEW;
- else if (td) {
- merge_attr (ad, );
- return 0;
- } else
- l = FUNC_OLD;
+if (td && !(td & TYPE_ABSTRACT))
+return 0;
+if (tok == ')')
+l = 0;
+else if (parse_btype(, ))
+l = FUNC_NEW;
+else if (td) {
+merge_attr (ad, );
+return 0;
+} else if (tcc_state->cversion >= 202000L)
+tcc_error("K function definitions are not allowed in c2x");
+else
+l = FUNC_OLD;
first = NULL;
plast =
arg_size = 0;
@@ -5411,10 +5415,17 @@ static int post_type(CType *type, AttributeDef *ad, int
storage, int td)
[Tinycc-devel] TinyCC -std=c2x support?
Hi,
C evolves and supports new features over the time.
Do we want to support upcoming features like prototypes without parameters
(as in C++)? See below:
jullien@fedora:~ $ cat foo.c
void foo(int) {}
jullien@fedora:~ $ tcc -c foo.c
foo.c:1: error: identifier expected
It is otherwise supported by recent gcc/clang compilers
jullien@fedora:~ $ gcc -v
.
gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC)
jullien@fedora:~ $ clang -v
.
clang version 12.0.0 (Fedora 12.0.0-2.fc34)
jullien@fedora:~ $ clang -std=c2x -c foo.c
jullien@fedora:~ $ gcc -std=c2x -c foo.c
gcc11 works even w.o. -std=c2x
jullien@fedora:~ $ gcc -c foo.c
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
