GNAT bugs around use of "for X'Address..." clause

GNAT bugs around use of "for X'Address..." clause

[erik.shadwick]

Consider the following declarations:

package P is
   type Checked_T is private
     with Type_Invariant => Check (Checked_T);

   type Tagged_T is tagged private;

   type Checked_Tagged_T is tagged private
     with Type_Invariant => Check (Checked_Tagged_T);

     function Check (M : Checked_T)        return Boolean with Inline;
     function Check (M : Checked_Tagged_T) return Boolean with Inline;

private
   type Checked_T is null record;
   type Tagged_T is tagged null record;
   type Checked_Tagged_T is tagged null record;

   function Check (M : Checked_T) return Boolean is (True);
   function Check (M : Checked_Tagged_T) return Boolean is (True);

end P;


Then the following 3 declarations each produce [similar] GNAT BUG DETECTED output:

X : P.Checked_T;
for X'Address use System.Null_Address;
--  However, if I do something like:
--     V : P.Checked_T;
--     X : P.Checked_T := V;
--     for X'Address use ...;
--  then no bug surfaces.

W : P.Tagged_T;
Y : P.Tagged_T := W;
for Y'Address use System.Null_Address;
--  If I do not perform the ":= W", then it works fine.
    
Z : P.Checked_Tagged_T;
for Z'Address use System.Null_Address;
--  With or without assignment to Z in its declaration, it fails.


(Compiled with `gnatmake -gnat2012`, with "GPL 2014 (20140331) (x86_64-apple-darwin12.5.0)")

Should I be submitting this to AdaCore, or GCC's http://gcc.gnu.org/bugs.html bug tracker? When running this with my copy of GNAT free/GPL, it suggests the former, but when compiling it through ideone.com I get the message to put it into GCC's tracker. It detects the error in "in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:347".

Further, what is the validity of assigning to a variable that has the 'Address clause on it -- is it legal and defined behaviour?

--
Erik Shadwick

Re: GNAT bugs around use of "for X'Address..." clause

[Simon Wright]

erik.shadwick@gmail.com writes:

> Should I be submitting this to AdaCore, or GCC's
> http://gcc.gnu.org/bugs.html bug tracker? When running this with my
> copy of GNAT free/GPL, it suggests the former, but when compiling it
> through ideone.com I get the message to put it into GCC's tracker. It
> detects the error in "in gnat_to_gnu_entity, at
> ada/gcc-interface/decl.c:347".

FSF GCC 4.9.1 raises a bug box (in a different place).
5.1.0 doesn't crash, but says (as I expected)

warning: default initialization of "X" may modify overlaid storage
warning: use pragma Import for "X" to suppress initialization (RM B.1(24))

(that is, "X : P.Checked_T with Import, Convention => Ada;")

Unfortunately, fixing that doesn't make your problem go away.

You could wait for GNAT GPL 2015, or you could try the FSF 5.1.0 at [1].

> Further, what is the validity of assigning to a variable that has the
> 'Address clause on it -- is it legal and defined behaviour?

Yes, but writing to System.Null_Address will probably not produce useful
behaviour. What you have here is an interaction between the type
invariant and the address setting.

[1] https://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac%20OS%20X/5.1.0/

Re: GNAT bugs around use of "for X'Address..." clause

[erik.shadwick]

On Friday, May 22, 2015 at 12:38:37 AM UTC-7, Simon Wright wrote:
> FSF GCC 4.9.1 raises a bug box (in a different place).
> 5.1.0 doesn't crash, but says (as I expected)
> ...
> You could wait for GNAT GPL 2015, or you could try the FSF 5.1.0 at [1].

Thank you -- it successfully compiles my project without those pesky bug boxes.
 
> > Further, what is the validity of assigning to a variable that has the
> > 'Address clause on it -- is it legal and defined behaviour?
> 
> Yes, but writing to System.Null_Address will probably not produce useful
> behaviour. What you have here is an interaction between the type
> invariant and the address setting.

Oh most definitely. I just found it the simplest System.Address to use in the minimal example.

Thanks for the link to 5.1.0, as that fully resolves my problem, and compiles all three cases without crashing.