On Tue, 2006-02-21 at 12:46 -0500, Richard Kenner wrote: > But if the values in there do not reflect the reality of what values > are valid for the type, then I don't see how they can be generally > useful -- that's my point. We have two fields that are inaccurate, > apparently on purpose, and as a result they are basically unusable. > > No, they *do* reflect the "reality of what values are valid for the type". Err, no they don't. Clearly an object of the type can hold a value outside TYPE_MIN_VALUE/TYPE_MAX_VALUE at runtime. That IMHO means that TYPE_MIN_VALUE/TYPE_MAX_VALUE do not reflect reality.
> The only glitch, which is not what we're talking about here, is that you have > to have a way to implement the language-defined test to see if the value is > valid or not. However, the need to implement that relative-uncommon test > should't drive the basic methodology used to represent types. Having a consistent TYPE_MIN_VALUE and TYPE_MAX_VALUE in no way prohibits you from implementing these tests. As I've told you before, if you've got a case where the tests are being incorrectly removed or casts are being incorrectly removed I'll happily investigate. But I'll repeat again, a consistent TYPE_MIN_VALUE/TYPE_MAX_VALUE in no way changes your ability to emit those tests in the Ada front-end. > With checking enabled, "normal" Ada usage should not be able to generate an > invalid value, so the assumption by VRP that the values are in the valid > range is a correct one (of course, you do have to be able to generate those > checks!). With checking disabled, an Ada program is erroneous if it > generates a value outside that range, so again VRP can assume the values are > in the specififed range. OK, so then we can claim the Ada code in question in bogus? Or at least put the burden of proving the code is correct back in your court? I've clearly showed that VRP is "miscompiling" the code because of the bogus values for TYPE_MAX_VALUE. But if you claim that having a value outside TYPE_MAX_VALUE is invalid according to the language, then the source code must be incorrect. > > There's only one exception here. It's valid to do a "unchecked conversion" > from arbitrary data into a value of a subtype with a restricted range. You > are then allowed to test (using 'Valid) whether or not the value is in range. > But any use of an out-of-range value (other than 'Valid) is also erroneous. Which implies that TYPE_MIN_VALUE/TYPE_MAX_VALUE need to reflect the set of values which can be placed into the object by way of an unchecked conversion. ANything else is simply lying to the language independent parts of the compiler. > > So the Ada rules and what VRP are assuming are precisely consistent. No they are not. The ADa front-end says that an object of a particular type as a set of values [x .. y]. However, at runtime the object is allowed to have values outside that range. That is _not_ consistent. > improperly. These simply have to be found and fixed. I found one quite a > while ago (when folding ranges) and I'm sure there are more (somebody > speculated that perhaps fold is removing conversions that are, in fact, > needed). I'm open to this possiblity as well, but this is completely and totally disjoint from the inconsistent TYPE_MIN_VALUE/TYPE_MAX_VALUE presented by the Ada front-end. jeff
