Re: Improved C warning messages

gopi@sankhya.com wrote in message 99-04-088...
> In the parse tree at each node, you could maintain in addition to
> the type of the expression, the smallest data type that is known to
> hold the value without losing any information. This can then be used
> to decide on whether or not a particular warning should be issued.


That is actually similar to the solution I have in mind. I attach a width
attribute to each (sub)expression; it specifies the actual number of
significant bits of its result. The rules for deriving the width attribute
are quite simple. For example (only for unsigned values):
        e1:w1 + e2:w2 -> (e1+e2):max(w1,w2)+1
        e1:w1 >> const -> (e1 >> const):(w1-const)
(In this notation the width attribute is after the colon)
The "width" of an expression can then easily be checked against the left
operand of an assignment. This could be applied on expression level during
parsing, on basic block level or even globally.
The information can also be used later on in an optimization I call "type
reduction" - it attempts to "reduce" the type of integral variables to a
smaller one (quite usefull for 8-bit CPU-s).


>
>> unsigned u;
>> short s;
>> ....
>> s = u >> 16; // must not produce warning about assigning int to short
>


> Assuming u is 32-bit int, the above can in fact be a correct worning
> -- unless the shift value is >= 17. (0xffffffff >> 16) != > (short)0xffff


You are right of course - my mistake. _s_ should be of type "unsigned
short".


>I believe a conservative use of the above method would result in an elegant
>solution.


thanks for the reply,
Tzvetan

Return to the comp.compilers page.
Search the comp.compilers archives again.