[Top][All Lists]

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

Re: [Tinycc-devel] can't build mob branch on x86 64

From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] can't build mob branch on x86 64
Date: Sat, 5 Feb 2011 02:40:51 +0100
User-agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )

Le samedi 05 février 2011 02:21:42, Joe Soroka a écrit :
> On Fri, Feb 4, 2011 at 3:49 PM, Thomas Preud'homme <address@hidden> 
> > Really? You want to rewrite it entirely? Took me so much time and it work
> > well now :( Couldn't just some CONFIG_TCC_ALLOCA macro be defined in
> > Makefile when compiling?
> Rewrite it entirely, no.  I apologize for accidentally implying that.
> While there *are* problems with your patch (doesn't handle size==0,
> doesn't work with bcheck, some others) I don't mean to throw it out.
Well, for bcheck I just found it could come in a separate commit as it's still 
an improvement over no VLA at all. About the size, the test should even be 
about size < 0 I guess.
> I guess I just mean that the fact you missed the "TOK_alloca is an
> enum" bit plus a few other simple things makes me worry about how well
> tested the *complicated* stuff is and I'd kinda like to see you pull
> it back, sleep on it, think on it, polish it a little bit and then
> bring it back.  I went through the same kind of thing with my patch
> for weak symbols - I had to throw it out and start over and ended up
> with a much smaller, much better version.
You did something about weak symbols? Great, then I'd like to talk to you 
about it as I have small question. We'll talk about this off list.
> Plus, I had my own partially-working VLA patch in my queue that "took
> me so much time" and I hate to throw it out as well, so I know what it
> feels like. :)
> > Anyway, however you code VLA, you need alloca and need a way to detect if
> > alloca is available or not. Do you have suggestion on how to rewrite it?
> I have a few ideas, but basically if libtcc1.a doesn't have an alloca
> for the target, (or perhaps CONFIG_USE_LIBGCC) then don't do it.
> That's the safest way I can think of, at least for tccgen.c.  For
> tcctest, you'd need an ifdef that works with gcc too, or modify the
> test Makefile.  I'll try to come up with a patch now.
Yeah but currently only the Makefile in lib/ knows if the lib has alloca or 
not, and the information should be reified in the main Makefile.
> Also, it wouldn't hurt to introduce a __builtin_alloca and use that
> for stuff like VLA, so there's no link-time confusion with any other
> libc allocas, if they exist.  That gawk report about missing
> "__builtin_malloc" after the introduction of VLA seems to hint at that
> as a problem.
> I dunno, the whole build/test/cross system is a bit of a mess.  I'm
> leaning towards my own friendly-fork a-la landley which focuses solely
> on x86 and gets it working perfectly there, without regard for other
> targets, because I have a lot more patches and with each one I'm
> afraid of stomping on something I can't test.
Well, it could just be dropped on an external repository while the patches are 
tested and adapted to the other architecture. I hope you are not thinking 
about a permanent fork, although it's up to you of course.
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tinycc-devel

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

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