Re: GCC 11 bug? lawyer needed

["Randy Brukardt" <randy@rrsoftware.com>]

"AdaMagica" <christ-usch.grein@t-online.de> wrote in message 
news:aaa58296-3298-4b70-ac7e-1393f579f217n@googlegroups.com...
> AdaMagica schrieb am Mittwoch, 5. Mai 2021 um 12:01:07 UTC+2:
>> I will try to grock the AI.
> Hm, I'm still confused. Can anyone please come up with some examples that 
> explain what this is all about?

See 6.4.1(6/3): there is an accessibility check on the actual parameter of 
an aliased parameter. This allows an aliased parameter to have the 
accessibility of the return object of a function, rather than local 
accessibility. There's a bunch of rules in 3.10.2 that combine to have the 
right effect.

You see the result in an operation like "Reference" in the containers. If 
you have:

     function Foo (A : in out Container; Idx : in Natural) return access 
Element;

then an implementation of:

     function Foo (A : in out Container) return access Element is
     begin
          return A.Data(Idx)'Access; -- (1)
     end Foo;

(1) is illegal, as A has local to Foo accessibility, while the anonymous 
access has the accessibility of the return object (the point of call), which 
is necessarily outside of Foo.

You can change (1) to:
          return A.Data(Idx)'Unchecked_Access; -- (1)
but now you can create a dangling pointer, for instance if Foo is assigned 
to a library-level access type and the actual for A is not library-level.

But you can change the parameter to "aliased", then the accessibility check 
is moved to the call site (where it must always suceeed for the vast 
majority of calls). There's no accessibility check at (1) in that case 
(which could be at best a dynamic check, which is a correctness hazard, and 
also has an overhead cost). And you still have the safety of not being able 
to create a dangling pointer.

It is a bit weird that this property is tied to "aliased" parameters. This 
property came first, and we discussed the syntax to use for a long time. 
Eventually it was decided to call them "aliased" parameters, but of course 
that meant it was necessary to generalize the usages.

This special rule does have the downside of being able to fail in some safe 
cases, like the one noted by the OP. That doesn't happen for procedures, 
since aliased parameters have no special semantics for procedures. We 
decided to remove the special semantics for functions for which it is 
impossible to return a part of the parameter (that is, any 
elementary-returning function), as that special semantics provides no 
benefit in such a case (but it does have a cost).

I agree that the original author of that program should not have used 
"aliased" in the way that they did (they don't need the special semantics), 
but we realize that some people would prefer to *explicitly* mark things as 
aliased when they are going to take 'Access (and not worry about the type of 
the parameter -- after all, it could change). That is, they don't want to 
depend on the implicit behavior of tagged types -- or perhaps they don't 
even know about it. Which leads to the problem that occurs here, as 
"aliased" has slightly different meanings for functions (now just composite 
functions) and procedures.

Since this is real code that didn't work as expected, it seemed to make 
sense to reduce the problem with a minor language tweak.

                                   Randy.