tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] const_wanted


From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] const_wanted
Date: Sun, 31 Jul 2011 21:31:52 +0200
User-agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )

Le dimanche 31 juillet 2011 18:48:04, grischka a écrit :
> Thomas Preud'homme wrote:
> >> Plus running the const_wanted branch without const_wanted being
> >> actually set doesn't look like a good idea.  It could still
> >> generate code in the gen_cast() or gexpr() calls below.
> > 
> > Thanks, I'll set (and unset at the end of the function) const_wanted in
> > the next experimental upload. I was thinking about doing it each time
> > cur_text_section is non NULL but it requires a static variable to store
> > the previous value of const_wanted accross functions.
> 
> If you want to fix a bug then adding tests on 'cur_text_section'
> is wrong because we don't have any such test anywhere currently.
> Which means that the code relies on the fact that it is always
> set when needed.
I was not suggesting to test cur_text_section, merely to change the value of 
const_wanted when the value of cur_text_section change since each time we are 
outside code const_wanted should be set to 1.
> 
> If however you want to clean up the relationship between
>     cur_text_section
> and
>     const_wanted
> and maybe
>     nocode_wanted
> which is probably possible, then your patch should remove more
> code than that it adds.  Otherwise it would not be a cleanup.
That's what I was thinking as fix for the problem I experienced. Something like 
setting const_wanted when cur_text_section is set to NULL and unsetting it 
when cur_text_section is set to a non NULL value. As to nocode_wanted, I 
prefer to not touch it since I can't see when const_wanted should not be equal 
nocode_wanted which means I don't know enough about the matter.
> 
> >>      int foo_array[fn() ? 2 : 42];
> >> 
> >> This should give an error such as with gcc:
> >>      test.c:10: error: variable-size type declared outside of any
> >>      function
> > 
> > Would the patch attached be satisfying or you prefer a better test for
> > the global level?
> 
> I'd prefer one that actually works.  And then one that doesn't
> mess with 'cur_text_section'. ;)
I knew you would answer something like this. That's why I didn't apply the 
patch straight forward.
> 
> I'd suggest you start here
>     http://repo.or.cz/w/tinycc.git/commitdiff/9b52e16a50
> or otherwise wait for Joe to do it.  Joe?
I've just found this commit when searching for what made the bug disappear. 
The "else if" should not have been removed, just the message changed. Is that 
ok if I put back the if else with the message you want? Sorry to annoy you, 
I'm sure it would be faster for Joe or you to patch it right away but I'm 
trying to learn in the process.
> 
> Btw, what about the multi-arch configuration.  Do you still plan
> to move some of the logic out from tcc into configure?
Yes absolutely, I just lack of time these days. My plan is to have a set of 
variable for each path in the tcc code (not much should be left) and set them 
from the configure. Then supporting a migration to multiarch (that is looking 
for /path/to/file and /path/to/file/<triplet>) would be just a bit more shell. 
I 
guess that the diffstat would be bigger but it would be due to configure 
changes, not tcc code changes.

I'd just like to know if you would agree to add a --multiarch-
triplet=<triplet> switch to configure for convenience. This switch would 
transform the various PATH from dir1:dir2 to 
dir1/<triplet>:dir1:dir2/<triplet>:dir2. If not, it would still be a big 
improvement for distributions using multiarch as it would allow to reduce the 
size of the patch to configure tcc with multiarch.
> 
> --- grischka

Thanks for your patience.

Thomas Preud'homme

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


reply via email to

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