Hi,
On Mon, 4 Dec 2017, grischka wrote:
> Michael Matz wrote:
> >> Here 'x5' should have the g[lobal] binding from C.
> >
> > ... I have fixed this in mob with a one-liner instead :)
>
> Well, however this one line
> > + if (esym && s->type.t == VT_VOID) {
>
> gives an interesting hint too because if after all we "post-process"
> only asm symbols then this means (IMO) that logically equivalently
> the same changes can be made to the symbol in place as well.
>
> Anyway, while at it (and making more tests), I tried that and it
> seems to work quite well.
>
> I've attached it as "no-asm-stack.patch".
Oh, shiny! :) I like it. It also works on my linux kernel sources, and
some other things, so it's a definite improvement. I'd say, apply.
> It clearly still has unwanted behavior with compiling multiple files
> if symbols with same name are defined as global in one file and
> then as static in another file.
Yeah, that, but not worse than before.
> The other "patch-type.patch" somewhat unifies type redefinition
And that's nice as well, I always wanted to do something similar, and
never came to it. Less lines --> good! :)
> Anyway. you might use these patches as just ideas or to run some tests
> to see if we can include them as is for the release.
As is.
> Apropos release, I don't have problems if the released version has
> "limitations" say with some corner cases, as long as unlikely an
> even simpler approach exist with equal or even less limitations.
Yeah, releases will always have problems, and there always will be new
releases (err, hopefully :) ), so I also don't see problems with
limitations. I'm basically fine with a release whenever there aren't
known regressions (i.e. something worked fine say two months ago, but
doesn't anymore). That's the case right now, no regressions. And with
your patches (also no regressions) tcc code is even smaller :)
> IOW if we're possibly somewhere close to such possibly simpler and
> better approach then I think it's worth to still wait, 1, 2, 3 ...
> weeks doesn't matter ;)
But, but ... Christmas! :)
Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
