Jeffrey A Law wrote: > My suspicions appear to be correct. This never triggers except for > Ada code and it's relatively common in Ada code. No surprise since > I don't think any other front-end abuses TYPE_MAX_VALUE in the way > the Ada front-end does. This wouldn't be the first time we've had > to hack up something in the generic optimizers to deal with the > broken TYPE_MAX_VALUE.
What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value allowed by given type. For range types it is clearily the upper bound of the range. Of course, upper bound should be representable, so TYPE_MAX_VALUE <= (2**TYPE_PRECISION - 1) for unsigned types and TYPE_MAX_VALUE <= (2**(TYPE_PRECISION - 1) - 1) for signed types. However, if the language has non-trivial range types you can expect strict inequality. Note, that if you do not allow strict inequality above, TYPE_MAX_VALUE would be redundant. FYI GNU Pascal is using such representation for range types, so for example: type t = 0..5; will give you TYPE_PRECISION equal to 32 (this is an old decision which tries to increase speed at the cost of space, otherwise 8 would be enough) and TYPE_MAX_VALUE equal to 5. GNU Pascal promotes arguments of operators, so that arithmetic take place in "standard" types -- I belive Ada is doing the same. BTW, setting TYPE_PRECISION to 3 for the type above used to cause wrong code, so the way above was forced by the backend. If you think that such behaviour is "abuse" then why to have sparate TYPE_MAX_VALUE. How to represent range types so that optimizers will know about allowed ranges (and use them!)? And how about debug info? -- Waldek Hebisch [EMAIL PROTECTED]