It turned out that the front-end wasn't fully using the information about the
null exclusion either in some cases. This eliminates redundant access checks
in the callee for subprograms with IN or IN/OUT parameters of an null-exclusion
access subtype, which were introduced in Ada 2005. The compiler already omits
these checks in the case of non-null access parameters present in Ada 95. An
access check is generated in the caller in both cases.
The compiler must generate no access checks within P2 for the following unit:
package Pkg is
type Varray is array (Integer range <>) of Long_Float;
type Ptr is access Varray;
procedure P1 (X : not null access Varray);
procedure P2 (X : not null Ptr);
end Pkg;
package body Pkg is
procedure P1 (X : not null access Varray) is
begin
for I in X'Range loop
X (I) := 0.0;
end loop;
end;
procedure P2 (X : not null Ptr) is
begin
for I in X'Range loop
X (I) := 0.0;
end loop;
end;
end Pkg;
2011-09-26 Eric Botcazou <ebotca...@adacore.com>
Robert Dewar <de...@adacore.com>
* sem_ch6.adb (Set_Formal_Mode): Set Can_Never_Be_Null on an IN or IN
OUT formal parameter which is of an null-exclusion access subtype.
--
Eric Botcazou
Index: sem_ch6.adb
===================================================================
--- sem_ch6.adb (revision 179163)
+++ sem_ch6.adb (working copy)
@@ -10267,6 +10267,16 @@ package body Sem_Ch6 is
and then Can_Never_Be_Null (Etype (Formal_Id))
then
Set_Is_Known_Non_Null (Formal_Id);
+
+ -- We can also set Can_Never_Be_Null (thus preventing some junk
+ -- access checks) for the case of an IN parameter, which cannot
+ -- be changed, or for an IN OUT parameter, which can be changed but
+ -- not to a null value. But for an OUT parameter, the initial value
+ -- passed in can be null, so we can't set this flag in that case.
+
+ if Ekind (Formal_Id) /= E_Out_Parameter then
+ Set_Can_Never_Be_Null (Formal_Id);
+ end if;
end if;
Set_Mechanism (Formal_Id, Default_Mechanism);
