Re: [Tinycc-devel] add tcc uninitialized variable warning

[Thomas Preud'homme]

Le jeudi 05 juin 2014, 17:15:40 David Mertens a écrit :
> Hello jiang,
> 
> Under the assumption that you would like to improve your English skills,
> I'll try to revise what you wrote to what I think you meant. My changes are
> in *bold*. :-)
> 
> "Hello everyone! I want to add uninitialized variable warning*s to tcc*. *Do
> y*ou have any good ideas*?* *Please let me know if this *would not be too
> simple to *do. That is, would this be overly complicated to implement?*"
> (I'm really not certain about your intention with the last sentence.)
> 
> I think it is a very good thing that you brought this up on the list before
> implementing it. I see tcc as a fast, C99-compliant compiler. It tries to
> help where it can, but it does not focus on being nice. If you are not
> posing something that brings it closer to compliance, improving the speed,
> or pushing a new architecture, I think the tcc community may be
> uninterested. I for my part have a very slight preference towards not
> including the warning.

Agreed. When contributing to a project it's important to understand the focus 
of that project. A project cannot be everything. TinyCC's focus is on speed of 
compilation and size of the compiler itself, making it well suited to be used 
as a commit hook or in embedded system. Of course, if we can add a diagnostic 
without compromising one of these goals then it's a good idea to do so. 

> 
> Tracking whether a variable has been initialized or not will require adding
> an entry to the Sym struct somewhere, or co-opting some unused bit in one
> of the fields. You might be able to hack that into one of the bits of the
> associated number, but I am a bit fuzzy on how that's used for identifiers.
> Somebody else on the list might be able to say more about how those are
> used. If you can't fit it into the associated number, then you would have
> to add a field to the Sym struct, increasing the working memory footprint
> of the compiler. It would also require adding checks to that bit for any
> r-value operation. I don't know exactly how those are parsed. If you're
> lucky, it's only one place, but if you're unlucky, it'll be all over the
> place. In other words, it may be easy, or it may be difficult.

Yep so in other word you need to make sure the size doesn't increase 
noticeably, neither the time to compile a significant project but also that the 
complexity doesn't increase to much. I think it's nice to keep TinyCC small so 
that it can serve as a learning tool for compiler. For the story, that's how I 
learned about compilation (never followed any course on compilation at school 
and I'm now employed to work on GCC).

> 
> However, this will only impose a speed penalty on the compiler, it will not
> make it any faster. If you decide to try to implement it, you must write
> benchmarks showing how much slower tcc will run for some important
> compilation targets. Take a large project, such as Awk, and see how much
> slower it takes to compile with these warnings implemented. See how much
> more memory it will consume. If the numbers involve a negligible change,
> you might get buy-in. (Note: negligible is in the eye of the beholder. A 1%
> slow-down may be too much.)

Agreed again. First 1% + 1% + 1% + … can lead to a substantial decrease in 
performance. Second it's also a matter of cost / benefit. If this were to bring 
a x5 performance for the compiled program, that would be acceptable I'd say. 
If it's to display color in error message it definitely is not.

Cheers,

Thomas

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