Re: [Tinycc-devel] Add gcc cleanup attribute support
Hi
I've fix my problem,
cleanup should now work correctly on my github(I've push -f)
I will now work on a new branch to remove the dual parsing.
Matthias.
On Sun, Jan 6, 2019 at 7:35 PM uso ewin wrote:
>
> On Fri, Jan 4, 2019 at 10:27 AM uso ewin wrote:
> >
> > On Thu, Jan 3, 2019 at 6:51 PM Michael Matz wrote:
> > >
> > > Hi,
> > >
> > > On Thu, 3 Jan 2019, uso ewin wrote:
> > >
> > > >> * your way of dealing with the "goto forward" problem is to read and
> > > >>remember all tokens after the goto until you find the label (and if
> > > >> so
> > > >>do the cleanups), rereading all these tokens afterwards.
> > > >>
> > > >>This feels ugly and against the one-pass nature (and is quadratic
> > > >> if you
> > > >>have very many gotos); several alternatives come to mind, though I
> > > >>haven't tried any of them to see if they result in less ugly code:
> > > >> e.g.
> > > >>you could remember all potentially scope-exiting gotos and check
> > > >> them at
> > > >>scope exit (redirecting them to the cleanup and then further to the
> > > >> real
> > > >>destination).
> > > >
> > > > Well, the problem with checking this at scope exit or at the label
> > > > declaration
> > > > is that as TCC do single pass generation, I can't go back and
> > > > regenerate the goto.
> > >
> > > Not the goto, but you can adjust where the goto goes to.
> > Ok, I did not think about the possibility to do that,
> > but now you say that, I will definitively test this implementation.
> > Thanks a lot for the idea.
> > > You wouldn't
> > > link these gotos in the label->jnext members, but in some on-the-side
> > > structure (also remembering the ultimate label they would have to go to,
> > > you could probably use the existing dynarray_* code).
> > > When you reach a label definition you remove all pending gotos for that
> > > label (they don't skip over the scope exit). When you reach a scope exit
> > > all pending gotos must first go to the cleanup snippet and then to the
> > > ultimate label.
> > >
> > > > A way to solve this would be either to create a switch case after each
> > > > label
> > > > that might need cleanup, or a dummy function for each goto in need.
> > >
> > > That latter is what you're essentially having right now: you check if the
> > > current goto in question leaves the scope, and if so emit all the cleanup
> > > code first and then the goto. I.e. for multiple gotos you repeat the
> > > cleanup code. That seems a sensible approach (the switch approach might
> > > lead to smaller code, but this shouldn't matter much here and is more
> > > complicated).
> > >
> > > > Either way, the code needed to handle that would be a lot more complex
> > > > that current implementation which is ~30line for handling the forward
> > > > goto case
> > > > and that is call only in scope that contain cleanup variable.
> > >
> > > Remembering gotos would also only be done when there are pending cleanups.
> > > It might be that you're right that it would take even more code. But I'm
> > > not so sure. The remembering and reiteration over tokens really gripes at
> > > me. E.g. think about this code:
> > >
> > > { int a CLEANUP(foo);
> > > ... goto later1; ...
> > > ... goto later2; ...
> > > large chunk of code
> > > }
> > > later1:
> > > ...
> > > later2:
> > >
> > > For both gotos you iterate over the large chunk of code shifting tokens
> > > back and forth between the token strings and the parser. As I said, it's
> > > a cute trick to get what you need, but there has to be a better way.
> > >
> > > We could also declare that forward jumps within scopes needing cleanups is
> > > simply not supported in TCC (with an appropriate error message). I would
> > > prefer even that crippling of the support compared to the token sifting.
> > >
> > > > If I use Sym but keep the dual parsing that would happen only
> > > > when we have a goto forward and a scope containing cleanup,
> > > > would the balance switch to the advantage side ?
> > >
> > > A bit, but the dual parsing makes me really unhappy :-) Do you have
> > > cycles for trying an alternative approach to at least compare both?
> > >
> > >
> > > Ciao,
> > > Michael.
> > >
> > > ___
> > > Tinycc-devel mailing list
> > > Tinycc-devel@nongnu.org
> > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> >
> > Well, I will at first remove the Token usage for cleanup call, because
> > it's buggy and ugly.
> > Then I will try to use label pointer for cleanup.
> > As it should use a lot of tcc code that are still obscure to me, I
> > might take time to do so.
> >
> > Thanks,
> > Matthias.
>
> Hi,
>
> I've got some improvement on removing token usage,
> and generate call directly:
> It mostly work, except when I try to call a function
> with a float(or double) pointer as parameter,
> When a function with a float is call,
> the function receive NULL,
[Tinycc-devel] Insert arm-xxx_FILES into Makefile to suport CROSS_TARGET and Remove duplicate function lexpand_nr
1.CROSS_TARGET option don't work correctly.
I added arm-xxx_FILES in Makefile so we can build cross target by using command
like this:
make libtcc.a CROSS_TARGET=arm-vfp
2.function 'lexpand_nr' seems doing the same thing as 'lexpand'. So I remove
lexpand_nr function and change the reference to lexpand
The patch detail show below, If no one protests, I would push this patch.
diff --git a/Makefile b/Makefile
index 02d3625..d5e10c8 100644
--- a/Makefile
+++ b/Makefile
@@ -164,6 +164,12 @@ x86_64-win32_FILES = $(x86_64_FILES) tccpe.c
x86_64-osx_FILES = $(x86_64_FILES)
arm_FILES = $(CORE_FILES) arm-gen.c arm-link.c arm-asm.c
arm-wince_FILES = $(arm_FILES) tccpe.c
+arm-eabihf_FILES = $(arm_FILES)
+arm-fpa_FILES = $(arm_FILES)
+arm-fpa-ld_FILES = $(arm_FILES)
+arm-vfp_FILES = $(arm_FILES)
+arm-eabi_FILES= $(arm_FILES)
+arm-eabihf_FILES = $(arm_FILES)
arm64_FILES = $(CORE_FILES) arm64-gen.c arm64-link.c
c67_FILES = $(CORE_FILES) c67-gen.c c67-link.c tcccoff.c
diff --git a/arm-gen.c b/arm-gen.c
index c5de065..e766ce4 100644
--- a/arm-gen.c
+++ b/arm-gen.c
@@ -1141,7 +1141,7 @@ again:
/* XXX: implicit cast ? */
size=4;
if ((pplan->sval->type.t & VT_BTYPE) == VT_LLONG) {
-lexpand_nr();
+lexpand();
size = 8;
r = gv(RC_INT);
o(0xE52D0004|(intr(r)<<12)); /* push r */
@@ -1165,7 +1165,7 @@ again:
case CORE_CLASS:
if ((pplan->sval->type.t & VT_BTYPE) == VT_LLONG) {
-lexpand_nr();
+lexpand();
gv(regmask(pplan->end));
pplan->sval->r2 = vtop->r;
vtop--;
diff --git a/tcc.h b/tcc.h
index cc85291..165249f 100644
--- a/tcc.h
+++ b/tcc.h
@@ -1321,9 +1321,11 @@ ST_FUNC void vpush_global_sym(CType *type, int v);
ST_FUNC void vrote(SValue *e, int n);
ST_FUNC void vrott(int n);
ST_FUNC void vrotb(int n);
+#if PTR_SIZE == 4
+ST_FUNC void lexpand(void);
+#endif
#ifdef TCC_TARGET_ARM
ST_FUNC int get_reg_ex(int rc, int rc2);
-ST_FUNC void lexpand_nr(void);
#endif
ST_FUNC void vpushv(SValue *v);
ST_FUNC void save_reg(int r);
diff --git a/tccgen.c b/tccgen.c
index 9f671e0..9b3749d 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -1521,7 +1521,7 @@ static int reg_fret(int t)
#if PTR_SIZE == 4
/* expand 64bit on stack in two ints */
-static void lexpand(void)
+ST_FUNC void lexpand(void)
{
int u, v;
u = vtop->type.t & (VT_DEFSIGN | VT_UNSIGNED);
@@ -1542,34 +1542,6 @@ static void lexpand(void)
}
#endif
-#ifdef TCC_TARGET_ARM
-/* expand long long on stack */
-ST_FUNC void lexpand_nr(void)
-{
-int u,v;
-
-u = vtop->type.t & (VT_DEFSIGN | VT_UNSIGNED);
-vdup();
-vtop->r2 = VT_CONST;
-vtop->type.t = VT_INT | u;
-v=vtop[-1].r & (VT_VALMASK | VT_LVAL);
-if (v == VT_CONST) {
- vtop[-1].c.i = vtop->c.i;
- vtop->c.i = vtop->c.i >> 32;
- vtop->r = VT_CONST;
-} else if (v == (VT_LVAL|VT_CONST) || v == (VT_LVAL|VT_LOCAL)) {
- vtop->c.i += 4;
- vtop->r = vtop[-1].r;
-} else if (v > VT_CONST) {
- vtop--;
- lexpand();
-} else
- vtop->r = vtop[-1].r2;
-vtop[-1].r2 = VT_CONST;
-vtop[-1].type.t = VT_INT | u;
-}
-#endif
-
#if PTR_SIZE == 4
/* build a long long from two ints */
static void lbuild(int t)___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add max_align_t to stddef.h and C11
> Maybe add a global variable
Not global but a new member of TCCState, for example cversion
If (s->cversion >= 201112) {
/* Hello C11 */
}
Diff becomes:
jullien@sims3:~/new-tcc $ git diff
diff --git a/libtcc.c b/libtcc.c
index df7adab..7883734 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1790,8 +1790,16 @@ reparse:
s->static_link = 1;
break;
case TCC_OPTION_std:
- /* silently ignore, a current purpose:
- allow to use a tcc as a reference compiler for "make test" */
+if (*optarg == '=') {
+++optarg;
+if (strcmp(optarg, "c11") == 0) {
+ tcc_undefine_symbol(s, "__STDC_VERSION__");
+ tcc_define_symbol(s, "__STDC_VERSION__", "201112L");
+ s->cversion = 201112;
+}
+}
+ /* silently ignore other values, a current purpose:
+allow to use a tcc as a reference compiler for "make test"
*/
break;
case TCC_OPTION_shared:
x = TCC_OUTPUT_DLL;
diff --git a/tcc.c b/tcc.c
index f780389..2d4e1ea 100644
--- a/tcc.c
+++ b/tcc.c
@@ -33,6 +33,8 @@ static const char help[] =
" -o outfile set output filename\n"
" -runrun compiled source\n"
" -fflag set or reset (with 'no-' prefix) 'flag' (see tcc -hh)\n"
+" -std=c99Conform to the ISO 1999 C standard (default).\n"
+" -std=c11Conform to the ISO 2011 C standard.\n"
" -Wwarning set or reset (with 'no-' prefix) 'warning' (see tcc
-hh)\n"
" -w disable all warnings\n"
" -v -vv show version, show search paths or loaded files\n"
diff --git a/tcc.h b/tcc.h
index cc85291..8416cc5 100644
--- a/tcc.h
+++ b/tcc.h
@@ -651,6 +651,7 @@ struct TCCState {
int rdynamic; /* if true, all symbols are exported */
int symbolic; /* if true, resolve symbols in the current module first
*/
int filetype; /* file type for compilation (NONE,C,ASM) */
+int cversion; /* supported C ISO version, either 0 (199901), 201112,
... */
char *tcc_lib_path; /* CONFIG_TCCDIR or -B option */
char *soname; /* as specified on the command line (-soname) */
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add max_align_t to stddef.h and C11
On Tue, Jan 8, 2019 at 5:06 PM Christian Jullien wrote:
>
> If no one protests, I can push this patch:
> jullien@sims3:~/new-tcc $ git diff
> diff --git a/libtcc.c b/libtcc.c
> index df7adab..eb55d8a 100644
> --- a/libtcc.c
> +++ b/libtcc.c
> @@ -1790,8 +1790,15 @@ reparse:
> s->static_link = 1;
> break;
> case TCC_OPTION_std:
> - /* silently ignore, a current purpose:
> - allow to use a tcc as a reference compiler for "make test" */
> +if (*optarg == '=') {
> +++optarg;
> +if (strcmp(optarg, "c11") == 0) {
> + tcc_undefine_symbol(s, "__STDC_VERSION__");
> + tcc_define_symbol(s, "__STDC_VERSION__", "201112L");
> +}
> +}
> + /* silently ignore other values, a current purpose:
> +allow to use a tcc as a reference compiler for "make test"
> */
> break;
> case TCC_OPTION_shared:
> x = TCC_OUTPUT_DLL;
> diff --git a/tcc.c b/tcc.c
> index f780389..2d4e1ea 100644
> --- a/tcc.c
> +++ b/tcc.c
> @@ -33,6 +33,8 @@ static const char help[] =
> " -o outfile set output filename\n"
> " -runrun compiled source\n"
> " -fflag set or reset (with 'no-' prefix) 'flag' (see tcc -hh)\n"
> +" -std=c99Conform to the ISO 1999 C standard (default).\n"
> +" -std=c11Conform to the ISO 2011 C standard.\n"
> " -Wwarning set or reset (with 'no-' prefix) 'warning' (see tcc
> -hh)\n"
> " -w disable all warnings\n"
> " -v -vv show version, show search paths or loaded files\n"
>
> It allows to start to play with -std=c11 new option. It correctly handles
> c11 and ignore all other values to be compatible with gcc.
>
> jullien@sims3:~/new-tcc $ cat foo.c
> #include
>
> int
> main() {
> printf("__STDC_VERSION__ == %d\n", __STDC_VERSION__);
> }
> jullien@sims3:~/new-tcc $ ./tcc foo.c -o foo && ./foo
> __STDC_VERSION__ == 199901
> jullien@sims3:~/new-tcc $ ./tcc -std=c11 foo.c -o foo && ./foo
> __STDC_VERSION__ == 201102
> jullien@sims3:~/new-tcc $ ./tcc -std=c42 foo.c -o foo && ./foo
> __STDC_VERSION__ == 199901
>
>
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of uso ewin
> Sent: mardi 8 janvier 2019 15:31
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Add max_align_t to stddef.h and C11
>
> On Tue, Jan 8, 2019 at 2:35 PM Christian Jullien wrote:
> >
> > IMHO,
> >
> > The right solution is to start to implement C11 features and surround them
> > with right #if _STDC_VERSION >= xxx.
> > This is how gcc/Linux handle differences between C/C++/POSIX/...
> >
> > Even gcc is not totally fair when it claims it supports a given version.
> >
> > I spent several hours to figure out why my -std=c++11 regexp always
> returned
> > false with gcc 4.8.2 until I discovered that and all API was
> > present ... BUT NOT IMPLEMENTED and all calls where returning error!!!
> >
> > I personally vote in favor of -std=c11 new option which supports ... only
> > what is actually implemented (without complex for instance).
> >
> > What other maintainers think about by opinion?
> >
>
> I'm not a maintainer, but am totally in favor to add a support for -std=C11
> and maybe latter for -std=C99.
>
> ___
> 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
Maybe add a global variable
int c_version = 99;
and set it to 11 if std=c11 is use
so we can directly use this variable to "disable" C11 feature when C11
isn't set.
also, (but not completely related to the subject)
it could be interesting to add support for std=gnu11/99 (but not in
the same commit as this could bring bugs)
so we can define _GNUC_ which would make gcc attribute easier to use
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add max_align_t to stddef.h and C11
If no one protests, I can push this patch:
jullien@sims3:~/new-tcc $ git diff
diff --git a/libtcc.c b/libtcc.c
index df7adab..eb55d8a 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1790,8 +1790,15 @@ reparse:
s->static_link = 1;
break;
case TCC_OPTION_std:
- /* silently ignore, a current purpose:
- allow to use a tcc as a reference compiler for "make test" */
+if (*optarg == '=') {
+++optarg;
+if (strcmp(optarg, "c11") == 0) {
+ tcc_undefine_symbol(s, "__STDC_VERSION__");
+ tcc_define_symbol(s, "__STDC_VERSION__", "201112L");
+}
+}
+ /* silently ignore other values, a current purpose:
+allow to use a tcc as a reference compiler for "make test"
*/
break;
case TCC_OPTION_shared:
x = TCC_OUTPUT_DLL;
diff --git a/tcc.c b/tcc.c
index f780389..2d4e1ea 100644
--- a/tcc.c
+++ b/tcc.c
@@ -33,6 +33,8 @@ static const char help[] =
" -o outfile set output filename\n"
" -runrun compiled source\n"
" -fflag set or reset (with 'no-' prefix) 'flag' (see tcc -hh)\n"
+" -std=c99Conform to the ISO 1999 C standard (default).\n"
+" -std=c11Conform to the ISO 2011 C standard.\n"
" -Wwarning set or reset (with 'no-' prefix) 'warning' (see tcc
-hh)\n"
" -w disable all warnings\n"
" -v -vv show version, show search paths or loaded files\n"
It allows to start to play with -std=c11 new option. It correctly handles
c11 and ignore all other values to be compatible with gcc.
jullien@sims3:~/new-tcc $ cat foo.c
#include
int
main() {
printf("__STDC_VERSION__ == %d\n", __STDC_VERSION__);
}
jullien@sims3:~/new-tcc $ ./tcc foo.c -o foo && ./foo
__STDC_VERSION__ == 199901
jullien@sims3:~/new-tcc $ ./tcc -std=c11 foo.c -o foo && ./foo
__STDC_VERSION__ == 201102
jullien@sims3:~/new-tcc $ ./tcc -std=c42 foo.c -o foo && ./foo
__STDC_VERSION__ == 199901
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of uso ewin
Sent: mardi 8 janvier 2019 15:31
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Add max_align_t to stddef.h and C11
On Tue, Jan 8, 2019 at 2:35 PM Christian Jullien wrote:
>
> IMHO,
>
> The right solution is to start to implement C11 features and surround them
> with right #if _STDC_VERSION >= xxx.
> This is how gcc/Linux handle differences between C/C++/POSIX/...
>
> Even gcc is not totally fair when it claims it supports a given version.
>
> I spent several hours to figure out why my -std=c++11 regexp always
returned
> false with gcc 4.8.2 until I discovered that and all API was
> present ... BUT NOT IMPLEMENTED and all calls where returning error!!!
>
> I personally vote in favor of -std=c11 new option which supports ... only
> what is actually implemented (without complex for instance).
>
> What other maintainers think about by opinion?
>
I'm not a maintainer, but am totally in favor to add a support for -std=C11
and maybe latter for -std=C99.
___
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] Add max_align_t to stddef.h and C11
On Tue, Jan 8, 2019 at 2:35 PM Christian Jullien wrote: > > IMHO, > > The right solution is to start to implement C11 features and surround them > with right #if _STDC_VERSION >= xxx. > This is how gcc/Linux handle differences between C/C++/POSIX/... > > Even gcc is not totally fair when it claims it supports a given version. > > I spent several hours to figure out why my -std=c++11 regexp always returned > false with gcc 4.8.2 until I discovered that and all API was > present ... BUT NOT IMPLEMENTED and all calls where returning error!!! > > I personally vote in favor of -std=c11 new option which supports ... only > what is actually implemented (without complex for instance). > > What other maintainers think about by opinion? > I'm not a maintainer, but am totally in favor to add a support for -std=C11 and maybe latter for -std=C99. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add max_align_t to stddef.h and C11
IMHO,
The right solution is to start to implement C11 features and surround them
with right #if _STDC_VERSION >= xxx.
This is how gcc/Linux handle differences between C/C++/POSIX/...
Even gcc is not totally fair when it claims it supports a given version.
I spent several hours to figure out why my -std=c++11 regexp always returned
false with gcc 4.8.2 until I discovered that and all API was
present ... BUT NOT IMPLEMENTED and all calls where returning error!!!
I personally vote in favor of -std=c11 new option which supports ... only
what is actually implemented (without complex for instance).
What other maintainers think about by opinion?
C.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Petr Skocík
Sent: mardi 8 janvier 2019 12:38
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Add max_align_t to stddef.h and C11
Hi,
adding that one line was bad snap judgment on my part. I didn't realize
max_align_t was C11 and since C99 doesn't appear to properly reserve all
*_t names (out of C99, only {,u}int*_t names are reserved (by
stdint.h)), let's revert it.
tinycc supports some C11 features like _Generic, but since _Generic is a
reserved word in all contexts, there are no name conflicts. max_align_t
is conflicting, IMO.
I've reverted the patch.
Thanks.
Best regards,
Petr Skocik
On 1/8/19 7:51 AM, Christian Jullien wrote:
> Hi all,
>
>
>
> Last commit made by Petr Skocik introduces definition of max_align_t
> which is ISO/IEC 9899:2011
>
>
>
> p. 286
>
> max_align_t
>
> which is an object type whose alignment is as great as is supported by
> the implementation in all contexts
>
>
>
> But, currently, tcc is supposed to implement C99 (ISO/IEC 9899:1999)
>
>
>
> printf("%d\n", __STDC_VERSION__); => 199901
>
>
>
> Hence, it should not be defined.
>
>
>
> Now the REAL question:
>
> It is not clear to me which C version tcc implements. Its an incomplete
> C99 implementation, it lacks for example complex.
>
>
>
> As it pretend to be 199901, we should take care that most C99 are
> implemented.
>
> New C11 features already implemented should be only available with a new
> flag (like std=c11)
>
>
>
> For example, here are the __STDC_ macros that a compiler C99 should use
> or test:
>
>
>
> __STDC__ macro, 6.10.8
>
> __STDC_CONSTANT_MACROS macro, 7.18.4
>
> __STDC_FORMAT_MACROS macro, 7.8.1
>
> __STDC_HOSTED__ macro, 6.10.8
>
> __STDC_IEC_559__ macro, 6.10.8, F.1
>
> __STDC_IEC_559_COMPLEX__ macro, 6.10.8, G.1
>
> __STDC_ISO_10646__ macro, 6.10.8
>
> __STDC_LIMIT_MACROS macro, 7.18.2, 7.18.3
>
> __STDC_VERSION__ macro, 6.10.8
>
>
>
> When we introduce a new tcc feature we should take care for which C
> version it is and correctly protect its implementation when the right
> std flag is set.
>
>
>
> Wdyt?
>
>
>
> C.
>
>
> ___
> 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
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add max_align_t to stddef.h and C11
As for allowing features conditionally, there's no harm in always
allowing things like _Generic or _Alignof (always reserved identifiers).
The max_align_t could be defined and protected by an `#if
__STDC_VERSION__ >= 201101L` as long as -std= were changed so that
-std=c11 set that macro. I think there wouldn't be much harm in that
even when C11 support is incomplete, as long as users know that tinycc's
C11 support is incomplete.
One possible issue might be that somebody might do
#if __STDC_VERSION__ >= 201101L
//use a not yet supported C11 feature such as _Alignas
#endif
so perhaps the macro controlling whether the max_align_t definition is
provided had better be an internal tcc macro (e.g.,
__TINYC_REQUESTED_STDC_VERSION__) instead of the publicly known
__STDC_VERSION__.
Best regards,
Petr Skocik
On 1/8/19 7:51 AM, Christian Jullien wrote:
> Hi all,
>
>
>
> Last commit made by Petr Skocik introduces definition of max_align_t
> which is ISO/IEC 9899:2011
>
>
>
> p. 286
>
> “max_align_t
>
> which is an object type whose alignment is as great as is supported by
> the implementation in all contexts”
>
>
>
> But, currently, tcc is supposed to implement C99 (ISO/IEC 9899:1999)
>
>
>
> printf("%d\n", __STDC_VERSION__); => 199901
>
>
>
> Hence, it should not be defined.
>
>
>
> Now the REAL question:
>
> It is not clear to me which C version tcc implements. It’s an incomplete
> C99 implementation, it lacks for example complex.
>
>
>
> As it pretend to be 199901, we should take care that “most” C99 are
> implemented.
>
> New C11 features already implemented should be only available with a new
> flag (like –std=c11)
>
>
>
> For example, here are the __STDC_ macros that a compiler C99 should use
> or test:
>
>
>
> __STDC__ macro, 6.10.8
>
> __STDC_CONSTANT_MACROS macro, 7.18.4
>
> __STDC_FORMAT_MACROS macro, 7.8.1
>
> __STDC_HOSTED__ macro, 6.10.8
>
> __STDC_IEC_559__ macro, 6.10.8, F.1
>
> __STDC_IEC_559_COMPLEX__ macro, 6.10.8, G.1
>
> __STDC_ISO_10646__ macro, 6.10.8
>
> __STDC_LIMIT_MACROS macro, 7.18.2, 7.18.3
>
> __STDC_VERSION__ macro, 6.10.8
>
>
>
> When we introduce a new tcc feature we should take care for which C
> version it is and correctly protect its implementation when the right
> –std flag is set.
>
>
>
> Wdyt?
>
>
>
> C.
>
>
> ___
> 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
