* Richard Kenner:
Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity
Checking) require that such reads are NOT erroneous.
It depends what such reads mean. 13.9.1(12) clearly says that the
result of an Unchecked_Conversion is erroneous if it isn't a valid
Florian Weimer wrote:
If this still doesn't convince you, here's an example which doesn't
use Ada.Unchecked_Conversion at all.
this example must print Success, that is guaranteed by the RM
it is definitely critical that 'Valid not make in-range
assumptions. the actual problem is optimization
* Robert Dewar:
Florian Weimer wrote:
If this still doesn't convince you, here's an example which doesn't
use Ada.Unchecked_Conversion at all.
this example must print Success, that is guaranteed by the RM
Yes, I think so.
What about the first one in PR21573? IMHO, the GNAT Reference
Florian Weimer wrote:
I fear that such barriers are also needed for all checks on scalars,
by the way, not just 'Valid.
indded, and we do unchecked conversions to the base type in these
cases. i guess we could fix the enum case by using unsigned as the
arg type, but that would not help the
* Robert Dewar:
Florian Weimer wrote:
I fear that such barriers are also needed for all checks on scalars,
by the way, not just 'Valid.
indded, and we do unchecked conversions to the base type in these
cases. i guess we could fix the enum case by using unsigned as the
arg type, but that
* Richard Kenner:
If this still doesn't convince you, here's an example which doesn't
use Ada.Unchecked_Conversion at all.
Well sure, reading an uninitialized value is erroneous except for the use
of 'Valid.
No, it's not, as Ada is not C. And please not the presence of pragma
Well sure, reading an uninitialized value is erroneous except for the use
of 'Valid.
No, it's not, as Ada is not C.
What's not? My statement is based on the Ada RM.
And please note the presence of pragma Normalize_Scalars.
That doesn't affect validity or erroneousness.
* Richard Kenner:
Well sure, reading an uninitialized value is erroneous except for the
use
of 'Valid.
No, it's not, as Ada is not C.
What's not? My statement is based on the Ada RM.
Quote from section 13.9.1 follows. Note the but does not by itself
lead to erroneous or
Richard Kenner wrote:
If this still doesn't convince you, here's an example which doesn't
use Ada.Unchecked_Conversion at all.
Well sure, reading an uninitialized value is erroneous except for the use
of 'Valid.
That is wrong, it is a bounded error. and of course validit checks must
Quote from section 13.9.1 follows. Note the but does not by itself
lead to erroneous or unpredictable execution part.
Right, because it's a bounded error.
Richard Kenner wrote:
Well sure, reading an uninitialized value is erroneous except for the use
of 'Valid.
No, it's not, as Ada is not C.
What's not? My statement is based on the Ada RM.
the rm is quite clear, lack of initialization
never leads to erroneous behavior. an
Robert Dewar [EMAIL PROTECTED] wrote:
why can't we just
completely turn off this optimization for Ada since it is wrong!
Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a way
which is (now) incorrect, and this causes wrong optimizations. Of course,
this might be seen as an
Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a
way which is (now) incorrect,
No, that usage is correct. What's incorrect is the way that 'Valid and
range checks are being implemented and/or optimized. Those should not be
using the bounds of the subtype.
I'd
Richard Kenner wrote:
Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a
way which is (now) incorrect,
No, that usage is correct. What's incorrect is the way that 'Valid and
range checks are being implemented and/or optimized. Those should not be
using the bounds
Richard Kenner wrote:
which, contrary to your previous email, is definitely not an erroneous
situation. Precision is very important here!
Yes, and I'm sorry for the confusion. However, for the purposes of this
discussion, there's no difference between erroneous and bounded error:
the
The Ada front end works by doing an unchecked conversion of X to
t'Base, followed by a range check. The issue is to stop range
propagation through the unchecked conversion.
And as we discussed on the phone, the core of the problem is that Gigi
treats unchecked conversions of numeric
On Fri, 2005-08-12 at 11:53 -0400, Richard Kenner wrote:
I'm not saying that things aren't broken, just being very careful in the
definition of what a valid value in an object is. The point is that these
values are not valid (which is why 'Valid returns FALSE) and that the
compiler
Laurent GUERBY wrote:
My understanding is that VRP (the compiler) is free to remove all other
language mandated range checks based on type min/max information but has
to keep the ones generated for 'Valid.
and any implicit validity checks, and for gnat, validity checks from
-gnatVa
An
* Laurent GUERBY:
An implementation model could be for the front-end to generate for each
family of scalar type T a function Base_Type_Internal_Valid (X, Min,
Max : in Base_Type_Of_T) return Boolean, generate a call to it at all
'Valid uses and then tell the compiler to never do any inlining
compiler (specifically VRP) is *correct* in deducing that the values are
in the valid range of the type *except* for 'Valid and range checks.
You meant for 'Valid range checks right? (no and).
I meant and. Range checks are essentially 'Valid.
Richard Kenner wrote:
compiler (specifically VRP) is *correct* in deducing that the values are
in the valid range of the type *except* for 'Valid and range checks.
You meant for 'Valid range checks right? (no and).
I meant and. Range checks are essentially 'Valid.
no, range
In PR 23046 we ICE inside tree-vrp.c because fold() does not
realize that for
enum enumtype { ENUM1, ENUM2 } x;
the predicate 'if (x 1)' is always false. This causes VRP to
create the impossible range [2, 1] for that predicate.
While it would be trivial for VRP to paper over this problem, the
On Fri, 2005-08-05 at 09:59 -0400, Diego Novillo wrote:
In PR 23046 we ICE inside tree-vrp.c because fold() does not
realize that for
enum enumtype { ENUM1, ENUM2 } x;
the predicate 'if (x 1)' is always false. This causes VRP to
create the impossible range [2, 1] for that predicate.
On Fri, Aug 05, 2005 at 11:57:45AM -0600, Jeffrey A Law wrote:
IIRC the C standard does not guarantee that an object stay within
the bounds of its enumerated type. You'll have to do some digging
in the relevant standards.
For the record, I believe we've addressed these issues sometime
within
The TYPE_MIN/MAX_VALUE for an enum should be set to the range truely
required by the relevant language standards (different between C and
C++).
I don't know for a fact that Ada has been adjusted for this though.
But if an Ada developer can verify that enumerations are
* Richard Henderson:
For the record, I believe we've addressed these issues sometime
within the last year or two. The TYPE_MIN/MAX_VALUE for an enum
should be set to the range truely required by the relevant language
standards (different between C and C++).
I don't know for a fact that Ada
* Richard Kenner:
This is wrong (as discussed before) and is likely the cause of PR21573
(not VRP-related, the expanders for SWITCH_EXPR look at these
attributes, too). I'm not sure if it is safe to delete these
assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE
This is simply not true for Ada. Look at the definition of the 'Valid
attribute in the standard:
3. X'Valid
Yields True if and only if the object denoted by X is normal
and has a valid representation. The value of this attribute
is of the
* Richard Kenner:
This is simply not true for Ada. Look at the definition of the 'Valid
attribute in the standard:
3. X'Valid
Yields True if and only if the object denoted by X is normal
and has a valid representation. The value of this attribute
Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity
Checking) require that such reads are NOT erroneous.
It depends what such reads mean. 13.9.1(12) clearly says that the
result of an Unchecked_Conversion is erroneous if it isn't a valid
representation. There are some
30 matches
Mail list logo
