This time it compiles and all tests passed on Aarch64. Good job!!
C. -----Original Message----- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of uso ewin Sent: mercredi 23 janvier 2019 19:44 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support fix, sorry for the bug. On Wed, Jan 23, 2019 at 5:59 PM Christian Jullien <eli...@orange.fr> 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:tinycc-devel-bounces+eligis=orange...@nongnu.org] > On Behalf Of uso ewin > Sent: mercredi 23 janvier 2019 17:28 > To: tinycc-devel@nongnu.org > 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 <eli...@orange.fr> 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:tinycc-devel-bounces+eligis=orange...@nongnu.org] > > On Behalf Of uso ewin > > Sent: lundi 21 janvier 2019 11:16 > > To: tinycc-devel@nongnu.org > > Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support > > > > On Sun, Jan 20, 2019 at 9:19 AM Christian Jullien <eli...@orange.fr> > 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:tinycc-devel-bounces+eligis=orange...@nongnu.org] > > > On Behalf Of uso ewin > > > Sent: samedi 19 janvier 2019 14:59 > > > To: tinycc-devel@nongnu.org > > > Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support > > > > > > On Tue, Jan 15, 2019 at 1:20 PM uso ewin <uso.cosmo....@gmail.com> > wrote: > > > > > > > > On Fri, Jan 11, 2019 at 8:10 PM uso ewin <uso.cosmo....@gmail.com> > > wrote: > > > > > > > > > > On Tue, Jan 8, 2019 at 8:42 PM uso ewin <uso.cosmo....@gmail.com> > > 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 <uso.cosmo....@gmail.com> > > > wrote: > > > > > > > > > > > > > > On Fri, Jan 4, 2019 at 10:27 AM uso ewin > <uso.cosmo....@gmail.com> > > > wrote: > > > > > > > > > > > > > > > > On Thu, Jan 3, 2019 at 6:51 PM Michael Matz > > <matz....@frakked.de> > > > 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, 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 > > > 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 > > > > > > _______________________________________________ > > 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 _______________________________________________ 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