tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Add gcc cleanup attribute support


From: uso ewin
Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support
Date: Wed, 23 Jan 2019 19:44:15 +0100

fix, sorry for the bug.

On Wed, Jan 23, 2019 at 5:59 PM Christian Jullien <address@hidden> wrote:
>
> Thanks,
>
> It work on ARM too, but only because my RPi uses gcc 6.x which is C99.
>
> On an Aarch64, using gcc 4.8, boostrap fails with:
>
> tccgen.c: In function 'reset_local_scope':
> tccgen.c:168:2: error: 'for' loop initial declarations are only allowed in
> C99 mode
>   for (int i = 0; i < cleanup_idx; ++i) {
>   ^
> tccgen.c:168:2: note: use option -std=c99 or -std=gnu99 to compile your code
> tccgen.c: In function 'is_scope_a_parent_of':
> tccgen.c:188:5: error: 'for' loop initial declarations are only allowed in
> C99 mode
>      for (ScopeTacker *cur = parent->prev; cur; cur = cur->prev) {
>      ^
> tccgen.c: In function 'try_call_scope_cleanup':
> tccgen.c:4804:2: error: 'for' loop initial declarations are only allowed in
> C99 mode
>   for (int i = 0; i < cleanup_idx; ++i) {
>   ^
> tccgen.c:4812:5: error: 'for' loop initial declarations are only allowed in
> C99 mode
>      for (int i = cleanup_info->nb_cleanup - 1; i >= 0; --i) {
>      ^
> tccgen.c: In function 'try_call_cleanup_goto':
> tccgen.c:4832:5: error: 'for' loop initial declarations are only allowed in
> C99 mode
>      for (ScopeTacker *cur_scope_tracker = scope_tracker;
>      ^
> tccgen.c: In function 'try_call_all_cleanup':
> tccgen.c:4843:5: error: 'for' loop initial declarations are only allowed in
> C99 mode
>      for (ScopeTacker *cur_scope_tracker = scope_tracker;
>      ^
> tccgen.c: In function 'block':
> tccgen.c:6285:6: error: 'for' loop initial declarations are only allowed in
> C99 mode
>       for (int i = 0; i < last_cleanup_goto; ++i) {
>       ^
> tccgen.c:6559:3: error: 'for' loop initial declarations are only allowed in
> C99 mode
>    for (int i = 0; i < last_cleanup_goto; ++i) {
>    ^
> make: *** [tccgen.o] Error 1
>
>
> Tcc source code should not use any C99 constructions. Can you please fix it?
> I'll try again
>
> -----Original Message-----
> From: Tinycc-devel [mailto:address@hidden
> On Behalf Of uso ewin
> Sent: mercredi 23 janvier 2019 17:28
> To: address@hidden
> Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support
>
> Hi,
>
> I've test on Linux intel 32/64 and windows 64 with MinGw, it work,
> So I've push.
>
> Thanks for your help
>
> Matthias
>
> On Mon, Jan 21, 2019 at 11:42 AM Christian Jullien <address@hidden> wrote:
> >
> > Hi,
> >
> > Windows x64, Linux Intel 32/64 is already nice, esp. if a test exists.
> I'll
> > make other tests when pushed on mob.
> >
> > C.
> >
> > -----Original Message-----
> > From: Tinycc-devel
> [mailto:address@hidden
> > On Behalf Of uso ewin
> > Sent: lundi 21 janvier 2019 11:16
> > To: address@hidden
> > Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support
> >
> > On Sun, Jan 20, 2019 at 9:19 AM Christian Jullien <address@hidden>
> wrote:
> > >
> > > Thank you for your patch. I adopt the same process: propose a patch
> then,
> > if
> > > nobody protest after a reasonable period of time, I push it on mod.
> > > Btw, have you a compressible set of tests for added feature?
> > > My **very modest** role I affect to myself in this project is to test
> mob
> > on
> > > the different platforms I have access to:
> > > - Windows 32/64
> > > - Linux Intel 32/64
> > > - Linux ARM 32/64
> > >
> > > I entirely rely on standard tests (+ running my own OpenLisp project
> which
> > > is an ISLISP Lisp compiler, this one includes non-regression performance
> > > benchmarks on generated code).
> > >
> > > Christian
> >
> > I've add a tests in TCC (101_cleanup), but I've tests only on a
> > x86_64 linux,
> > I will test on windows 64, linux 32 intel  and try to create an ARM
> > linux VM with qemu
> > before pushing.
> >
> > >
> > > -----Original Message-----
> > > From: Tinycc-devel
> > [mailto:address@hidden
> > > On Behalf Of uso ewin
> > > Sent: samedi 19 janvier 2019 14:59
> > > To: address@hidden
> > > Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support
> > >
> > > On Tue, Jan 15, 2019 at 1:20 PM uso ewin <address@hidden>
> wrote:
> > > >
> > > > On Fri, Jan 11, 2019 at 8:10 PM uso ewin <address@hidden>
> > wrote:
> > > > >
> > > > > On Tue, Jan 8, 2019 at 8:42 PM uso ewin <address@hidden>
> > wrote:
> > > > > >
> > > > > > 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 <address@hidden>
> > > wrote:
> > > > > > >
> > > > > > > On Fri, Jan 4, 2019 at 10:27 AM uso ewin
> <address@hidden>
> > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Jan 3, 2019 at 6:51 PM Michael Matz
> > <address@hidden>
> > > 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
> > > > > > > > > address@hidden
> > > > > > > > > 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, instead of the float pointer.
> > > > > > > Here is the code I use to generate the call
> > > > > > > https://github.com/cosmo-ray/tcc/blob/cleanup/tccgen.c#L4755
> > > > > > >
> > > > > > > Can you help me with that ?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Matthias
> > > > >
> > > > > new version that don't use dual parsing:
> > > > > https://github.com/cosmo-ray/tcc/tree/cleanup2
> > > > >
> > > > > any thoughts on this ?
> > > > >
> > > > > Thanks
> > > > > Matthias
> > > >
> > > > Hi,
> > > >
> > > > As no one answer, can I push this on mod
> > > > (the version without dual parsing) ?
> > > >
> > > >
> > > > Matthias
> > >
> > > Hello again,
> > >
> > > I saw I had some bug in my last branch,
> > > https://github.com/cosmo-ray/tcc/tree/cleanup2
> > > so I've push -f fixes on it
> > >
> > > I'm going to wait until Wednesday to see if someone is
> > > against my patch, if I receive no complaint I will push on mob
> > >
> > > Thanks,
> > > Matthias
> > >
> > > _______________________________________________
> > > Tinycc-devel mailing list
> > > address@hidden
> > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> > >
> > >
> > > _______________________________________________
> > > Tinycc-devel mailing list
> > > address@hidden
> > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> >
> > _______________________________________________
> > Tinycc-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> >
> >
> > _______________________________________________
> > Tinycc-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]