------- Comment #19 from manu at gcc dot gnu dot org  2007-01-17 03:49 -------

(In reply to comment #16)
> Subject: Re:  unsigned warning in template
> 
> "manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> 
> | (In reply to comment #14)
> | > | We don't emit a warning when instantiated as a signed char, so 
> everything
> | > boils
> | > | down to having an option to disable the warning, doesn't it?
> | > 
> | > the logical inference escapes me.
> | > 
> | 
> | Is having an option to disable the warning the right fix for this PR or is 
> it
> | not?
> 
> You made an inference in an earlier message, and I would like to
> understand it.  Because, I do not believe a nobe in form
> of "hey, you can silence it with with sledge-hammer" is the solution to this
> particular type of constructs -- note that constants are involved.
> 
> Care to explain further your earlier message?
> 

Of course. I was reflecting on the fact that we don't warn when the template is
instantiated as signed int. Also, we don't warn for template parameters:

template <typename Int, Int D>
void g(void) {
  assert(0 <= D);
}
int gg(void) {
  g<unsigned char, 2>();
}


However, those are different from the template testcase discussed here. Yet,
since the comparison in the template testcase seems to me as constant as in
this case:

#include <cassert> 
void f(unsigned char c) { 
  assert(0 <= c and c <= 2); 
} 
int main() { 
  f(5); 
} 

and as far as I know front-ends cannot do dataflow solving, I wrongly concluded
that there was nothing else we could do. If you have a solution in mind, that
is great! I hope you manage to find time to implement it. Being able to know
the value of c would be very useful for many other warnings, -Wconversion in
particular, so I will learn a lot from your patch.

Nonetheless, having an individual option -Wcomparison-fixed to enabled/disable
this unnamed warning seems worthwhile by itself and it is also useful as a
temporary work-around while you are working in your patch.

Also, the same patch will close PR 23587 and PR 12963 and come closer to fix PR
7651. 

We can keep this PR open until your patch is committed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856

Reply via email to