With -gnatwa, GNAT emits very useful warnings; one of them is "condition is always False". However, GNAT does not emit this warning when it applies inside a generic, or a generic instantiation. The following test case demonstrates the problem. procedure Condition_Is_Always_False is type T is range 3 .. 4; function F return T is begin return T'First; end F; procedure OK is C : constant T := F; begin if C = 1 then -- warning: condition is always False null; end if; end OK; generic procedure NOK_G; procedure NOK_G is C : constant T := F; -- T'First instead of F gives the warning begin if C = 1 then -- no warning null; end if; end NOK_G; procedure NOK is new NOK_G; begin -- Condition_Is_Always_False OK; NOK; end Condition_Is_Always_False; gcc-4.1 -c -gnatwa condition_is_always_false.adb condition_is_always_false.adb:13:12: warning: condition is always False gnatbind -x condition_is_always_false.ali gnatlink condition_is_always_false.ali If, however, C is initialized directly with T'First (a static value) instead of the result of F (a static function), GNAT gives the warning even inside the generic.
Confirmed on GCC 4.4.0 20080303. I think this warning is disabled on purpose on instances because you may end up with conditions being always true or false *in somes instances only*. And in these cases, you certainly do not want the warning to occur, as the code may be perfectly legit. Reinstating the warning in instances would require analyzing whether the current test depends, directly or indirectly, on generic formal parameters, and issuing the warning only when there are no dependencies. This would require quite a lot of work to do it properly.
Also note that for the same reason, you will not get a warning from an inlined body. See sem_warn.adb (Warn_On_Known_Condition).
Right, this is really as intended, to avoid too many false positives. The warning circuitry is not prepared to handle more complex cases, which would require really a different kind of tool, so is out of the scope of the front-end. Arno