Incomplete type generic formal interactions with Implicit_Dereference

Incomplete type generic formal interactions with Implicit_Dereference

[Jere]

Recently I was working in a generic package that had an Incomplete type
in its specification.  Something like:

generic
   type Some_Type(<>);
   -- ...other stuff
package Some_Package is
   -- stuff
end Some_Package;

In it, I needed to return an access type of the Incomplete type, and I
figured I would just do that through an implicit derefernced object.
I made something like:

type Some_Type_Holder(Ref : not null access Some_Type) is 
   limited null record
with
   Implicit_Dereference => Ref;

At some point it led to a crash in GNAT, which I reported to AdaCore, 
and they said they fixed it in a future rev (side note, do I need to
report that to the FSF team as well and how if so?).  

Recently, I've been wondering if what I tried to do was even meant to 
be legal?  I don't actually use Some_Type_Holder directly in the
package.  It's just a return type of a function for a client to call.

Part of me thinks that since Some_Type is incomplete, that Ada wouldn't
allow for an Implicit_Dereference declared on it.  I guess it depends on
if it is meant to be evaluated in the compilation of the generic itself
or at the point at which the function is called.  

Anyone have any thoughts on this?

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

> At some point it led to a crash in GNAT, which I reported to AdaCore, 
> and they said they fixed it in a future rev (side note, do I need to
> report that to the FSF team as well and how if so?).  

I don't know how many FSF GNAT contributors aren't AdaCore people, but
it's not many! This sort of problem (deep in the compiler) isn't very
likely to be solved by non-AdaCore folk.

I've always felt uncomfortable when I report a bug to AdaCore (which
won't contain proprietary info, since I don't have any) that no one else
can see it. Not sure how reporting it to FSF as well as to AdaCore would
be received; I try to go for one or the other.

In any case, FSF won't accept reports on GNAT GPL (any more than AdaCore
will accept reports on FSF GCC): you'd need to make sure the bug also
happened with FSF GCC.

To report a GNAT bug to FSF, set up an account on GCC Bugzilla
<https://gcc.gnu.org/bugzilla/index.cgi>, and raise the bug on Product:
gcc, Component: ada.

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Jere]

On Saturday, January 20, 2018 at 3:25:34 PM UTC-5, Simon Wright wrote:
> Jere writes:
> 
> > At some point it led to a crash in GNAT, which I reported to AdaCore, 
> > and they said they fixed it in a future rev (side note, do I need to
> > report that to the FSF team as well and how if so?).  
> 
> I don't know how many FSF GNAT contributors aren't AdaCore people, but
> it's not many! This sort of problem (deep in the compiler) isn't very
> likely to be solved by non-AdaCore folk.
> 
> I've always felt uncomfortable when I report a bug to AdaCore (which
> won't contain proprietary info, since I don't have any) that no one else
> can see it. Not sure how reporting it to FSF as well as to AdaCore would
> be received; I try to go for one or the other.
> 
> In any case, FSF won't accept reports on GNAT GPL (any more than AdaCore
> will accept reports on FSF GCC): you'd need to make sure the bug also
> happened with FSF GCC.
> 
> To report a GNAT bug to FSF, set up an account on GCC Bugzilla
> <https://gcc.gnu.org/bugzilla/index.cgi>, and raise the bug on Product:
> gcc, Component: ada.

There were actually two bugs.
One occurred on both GNAT GPL 2017 and GNAT FSF 7.2 on mingw64/msys2 x86_64
A second one only affected GNAT FSF 7.2 on mingw64/msys2 x86_64

The odd thing is for the second bug, GNAT GPL is 6.3, while the FSF is 7.2,
yet the bug was fixed for the GPL version (6.3) and not the FSF version (7.2).

I also wasn't sure if I should have reported the bug to FSF directly or to
the maker of the mingw64 port of it.  Based on your reply, it sounds like
I should report that second one to FSF directly?  Given that they don't seem
to be incorporating bug fixes from GPL into FSF, I am concerned that the first
bug I submitted to Adacore may not get fixed in the FSF version. It might,
I just don't know since one of the bugs is fixed in an earlier version of
GNAT but not a later version.

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

> There were actually two bugs.
> One occurred on both GNAT GPL 2017 and GNAT FSF 7.2 on mingw64/msys2
> x86_64 A second one only affected GNAT FSF 7.2 on mingw64/msys2 x86_64
>
> The odd thing is for the second bug, GNAT GPL is 6.3, while the FSF is
> 7.2, yet the bug was fixed for the GPL version (6.3) and not the FSF
> version (7.2).
>
> I also wasn't sure if I should have reported the bug to FSF directly
> or to the maker of the mingw64 port of it.  Based on your reply, it
> sounds like I should report that second one to FSF directly?  Given
> that they don't seem to be incorporating bug fixes from GPL into FSF,
> I am concerned that the first bug I submitted to Adacore may not get
> fixed in the FSF version. It might, I just don't know since one of the
> bugs is fixed in an earlier version of GNAT but not a later version.

Under those circumstances I'd report the FSF bugs to FSF (I've been
tracking the GCC 8 developments so that I can leap in with macOS
binaries ASAP after the release!, so I'd check whether the bug was fixed
in 8).

AdaCore's timeline vs FSF isn't straighforward (there's some
not-up-to-date info at [1]).

AdaCore produce a Pro release about once a year, which they base on a
well-known GCC release (in the case of GNAT GPL 2017, 6.3). This
involves changes to Ada front-end code, to the C back-end code, and to
the interface between them (and of course to Ada & C in the runtime).

FSF GCC begins a new major release phase (currently for 8) also
approximately once a year, not synced with AdaCore's releases. What
AdaCore do (visibly, anyway) is to port the changes made in their own
source tree at that time to the FSF tree; there's commonly a rush of
commits at this point. After that, things slow down and bugs get fixed.

So one would expect some of the bugs still present in GCC 7 to have been
fixed in the GPL 2017 release (and, hopefully, in GCC 8).

[1] https://people.debian.org/~lbrenta/debian-ada-policy.html#Timeline-of-GNAT-releases

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Jere]

On Sunday, January 21, 2018 at 5:04:18 AM UTC-5, Simon Wright wrote:
> Jere writes:
> 
> > There were actually two bugs.
> > One occurred on both GNAT GPL 2017 and GNAT FSF 7.2 on mingw64/msys2
> > x86_64 A second one only affected GNAT FSF 7.2 on mingw64/msys2 x86_64
> >
> > The odd thing is for the second bug, GNAT GPL is 6.3, while the FSF is
> > 7.2, yet the bug was fixed for the GPL version (6.3) and not the FSF
> > version (7.2).
> >
> > I also wasn't sure if I should have reported the bug to FSF directly
> > or to the maker of the mingw64 port of it.  Based on your reply, it
> > sounds like I should report that second one to FSF directly?  Given
> > that they don't seem to be incorporating bug fixes from GPL into FSF,
> > I am concerned that the first bug I submitted to Adacore may not get
> > fixed in the FSF version. It might, I just don't know since one of the
> > bugs is fixed in an earlier version of GNAT but not a later version.
> 
> Under those circumstances I'd report the FSF bugs to FSF (I've been
> tracking the GCC 8 developments so that I can leap in with macOS
> binaries ASAP after the release!, so I'd check whether the bug was fixed
> in 8).
> 
> AdaCore's timeline vs FSF isn't straighforward (there's some
> not-up-to-date info at [1]).
> 
> AdaCore produce a Pro release about once a year, which they base on a
> well-known GCC release (in the case of GNAT GPL 2017, 6.3). This
> involves changes to Ada front-end code, to the C back-end code, and to
> the interface between them (and of course to Ada & C in the runtime).
> 
> FSF GCC begins a new major release phase (currently for 8) also
> approximately once a year, not synced with AdaCore's releases. What
> AdaCore do (visibly, anyway) is to port the changes made in their own
> source tree at that time to the FSF tree; there's commonly a rush of
> commits at this point. After that, things slow down and bugs get fixed.
> 
> So one would expect some of the bugs still present in GCC 7 to have been
> fixed in the GPL 2017 release (and, hopefully, in GCC 8).
> 
> [1] https://people.debian.org/~lbrenta/debian-ada-policy.html#Timeline-of-GNAT-releases

Ok, that makes sense.  It had just seemed odd that 6.3 had a bug fixed when 
7.2 did not.  Now I understand.  I'll work on getting two bug reports to 
the FSF people.  I only have the windows version of FSF GNAT to test on, 
so I don't know if it affects other platforms, but my gut says it will 
probably be the same since they result in GNAT crashes.

Thanks!

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Jere]

On Saturday, January 20, 2018 at 3:25:34 PM UTC-5, Simon Wright wrote:
> Jere writes:
> 
> > At some point it led to a crash in GNAT, which I reported to AdaCore, 
> > and they said they fixed it in a future rev (side note, do I need to
> > report that to the FSF team as well and how if so?).  
> 
> I don't know how many FSF GNAT contributors aren't AdaCore people, but
> it's not many! This sort of problem (deep in the compiler) isn't very
> likely to be solved by non-AdaCore folk.
> 
> I've always felt uncomfortable when I report a bug to AdaCore (which
> won't contain proprietary info, since I don't have any) that no one else
> can see it. Not sure how reporting it to FSF as well as to AdaCore would
> be received; I try to go for one or the other.
> 
> In any case, FSF won't accept reports on GNAT GPL (any more than AdaCore
> will accept reports on FSF GCC): you'd need to make sure the bug also
> happened with FSF GCC.
> 
> To report a GNAT bug to FSF, set up an account on GCC Bugzilla
> <https://gcc.gnu.org/bugzilla/index.cgi>, and raise the bug on Product:
> gcc, Component: ada.

Thanks, I submitted the bug (took a while to get an account).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84142

My first bug report so I probably noobed it up, but hopefully they won't
be too upset if I did.

Thanks for the help!

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

> Thanks, I submitted the bug (took a while to get an account).
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84142
>
> My first bug report so I probably noobed it up, but hopefully they won't
> be too upset if I did.

Looks good to me ...

> Thanks for the help!

A pleasure.

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:21b6b4fb-4648-419e-ae6c-c361d54eaa2f@googlegroups.com...
...
> Part of me thinks that since Some_Type is incomplete, that Ada wouldn't
> allow for an Implicit_Dereference declared on it.  I guess it depends on
> if it is meant to be evaluated in the compilation of the generic itself
> or at the point at which the function is called.
>
> Anyone have any thoughts on this?

I don't think we ever considered this case. But I think it is OK.

Specifically, 4.1.5(6/3) says that a generalized reference denotes a view 
equivalent to that of a dereference of the reference discriminant of the 
reference object. Thus, any Legality Rules that apply to the dereference of 
the discriminant apply to the generalized reference as well. For instance, 
this includes any accessibility rules (which was an important part of the 
design, as the accessibility rules prevent the access value from living 
longer than the object containing the access discriminant).

As such, any other Legality Rules, like the ones about incomplete types 
would also apply. Specifically, 3.10.1(10/3): "A prefix that denotes an 
object shall not be of an incomplete view."

So a use of an Implicit_Dereference wherever the type is incomplete would 
usually be illegal (there are a few ways that a dereference of an incomplete 
view can be used, mainly to be passed as a parameter to some routine with an 
access-to-incomplete parameter). But it would be OK where the type has been 
completed (in this case, outside of the generic instantiation, the way you 
intended to use this). This sounds like what you intended.

                                   Randy.

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Jere]

On Monday, January 22, 2018 at 8:08:59 PM UTC-5, Randy Brukardt wrote:
> "Jere" wrote in message 
> ...
> > Part of me thinks that since Some_Type is incomplete, that Ada wouldn't
> > allow for an Implicit_Dereference declared on it.  I guess it depends on
> > if it is meant to be evaluated in the compilation of the generic itself
> > or at the point at which the function is called.
> >
> > Anyone have any thoughts on this?
> 
> I don't think we ever considered this case. But I think it is OK.
> 
> Specifically, 4.1.5(6/3) says that a generalized reference denotes a view 
> equivalent to that of a dereference of the reference discriminant of the 
> reference object. Thus, any Legality Rules that apply to the dereference of 
> the discriminant apply to the generalized reference as well. For instance, 
> this includes any accessibility rules (which was an important part of the 
> design, as the accessibility rules prevent the access value from living 
> longer than the object containing the access discriminant).
> 
> As such, any other Legality Rules, like the ones about incomplete types 
> would also apply. Specifically, 3.10.1(10/3): "A prefix that denotes an 
> object shall not be of an incomplete view."
> 
> So a use of an Implicit_Dereference wherever the type is incomplete would 
> usually be illegal (there are a few ways that a dereference of an incomplete 
> view can be used, mainly to be passed as a parameter to some routine with an 
> access-to-incomplete parameter). But it would be OK where the type has been 
> completed (in this case, outside of the generic instantiation, the way you 
> intended to use this). This sounds like what you intended.
> 
>                                    Randy.

I think I gotcha.  Just wanted to verify since I realized that I presented
the example a bit disjointed.  If I have a dummy example:

procedure Main is
   generic
      type Some_Item(<>);
   package Some_Package is

      type New_Type is tagged limited private;

      type Some_Item_Holder(Ref : not null access Some_Item)
      is limited null record
         with
            Implicit_Dereference => Ref;

      function Get_Some_Item
         (Object : New_Type)
       return Some_Item_Holder;

   private

      type Some_Item_Access is access Some_Item;

      type New_Type is tagged limited record
         Some_Access : Some_Item_Access;
      end record;

   end Some_Package;

     

   package body Some_Package is
      function Get_Some_Item
         (Object : New_Type)
       return Some_Item_Holder
      is
      begin
         return (Ref => Object.Some_Access);
      end Get_Some_Item;
   end Some_Package;
   
   type Test;
   package Test_Pkg is new Some_Package(Test);
   
   type Test is record
      value : Integer;
   end record;
   
   Thing : Test_Pkg.New_Type;
   
begin
   Thing.Get_Some_Item.Value := 4;
end Main;


From your last response, if I understand correctly, then this
should be OK, legal Ada.  Sorry for the contrived example, I
just wanted to make sure I didn't mislead with my original message,
so I generated a minimal example.  I would normally have stuff
broken up into separate files with better naming, etc.

If Simon is seeing this, then the above code is one example of 
what causes one of the crashes.  It is the one that breaks in
both versions (GPL 2017 and FSF 7.2):


$ gcc --version
gcc.exe (Rev1, Built by MSYS2 project) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gprbuild default.gpr
gcc -c -gnatn -gnato -gnatE -fstack-check -gnat12 -O3 main.adb
+===========================GNAT BUG DETECTED==============================+
| 7.2.0 (x86_64-w64-mingw32) Segmentation fault                            |
| Error detected at main.adb:49:9                                          |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

Ada\Scratch\src\main.adb

compilation abandoned
gprbuild: *** compilation phase failed


My NOTE:  the compilation flags just happened to be
whatever they were last.  This is from my scratch project
space.  I don't think they actually matter.
 

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Jere]

On Tuesday, January 23, 2018 at 8:13:12 AM UTC-5, Jere wrote:
> On Monday, January 22, 2018 at 8:08:59 PM UTC-5, Randy Brukardt wrote:
> > "Jere" wrote in message 
> > ...
> > > Part of me thinks that since Some_Type is incomplete, that Ada wouldn't
> > > allow for an Implicit_Dereference declared on it.  I guess it depends on
> > > if it is meant to be evaluated in the compilation of the generic itself
> > > or at the point at which the function is called.
> > >
> > > Anyone have any thoughts on this?
> > 
> > I don't think we ever considered this case. But I think it is OK.
> > 
> > Specifically, 4.1.5(6/3) says that a generalized reference denotes a view 
> > equivalent to that of a dereference of the reference discriminant of the 
> > reference object. Thus, any Legality Rules that apply to the dereference of 
> > the discriminant apply to the generalized reference as well. For instance, 
> > this includes any accessibility rules (which was an important part of the 
> > design, as the accessibility rules prevent the access value from living 
> > longer than the object containing the access discriminant).
> > 
> > As such, any other Legality Rules, like the ones about incomplete types 
> > would also apply. Specifically, 3.10.1(10/3): "A prefix that denotes an 
> > object shall not be of an incomplete view."
> > 
> > So a use of an Implicit_Dereference wherever the type is incomplete would 
> > usually be illegal (there are a few ways that a dereference of an incomplete 
> > view can be used, mainly to be passed as a parameter to some routine with an 
> > access-to-incomplete parameter). But it would be OK where the type has been 
> > completed (in this case, outside of the generic instantiation, the way you 
> > intended to use this). This sounds like what you intended.
> > 
> >                                    Randy.
> 
> I think I gotcha.  Just wanted to verify since I realized that I presented
> the example a bit disjointed.  If I have a dummy example:
> 
> procedure Main is
>    generic
>       type Some_Item(<>);
>    package Some_Package is
> 
>       type New_Type is tagged limited private;
> 
>       type Some_Item_Holder(Ref : not null access Some_Item)
>       is limited null record
>          with
>             Implicit_Dereference => Ref;
> 
>       function Get_Some_Item
>          (Object : New_Type)
>        return Some_Item_Holder;
> 
>    private
> 
>       type Some_Item_Access is access Some_Item;
> 
>       type New_Type is tagged limited record
>          Some_Access : Some_Item_Access;
>       end record;
> 
>    end Some_Package;
> 
>      
> 
>    package body Some_Package is
>       function Get_Some_Item
>          (Object : New_Type)
>        return Some_Item_Holder
>       is
>       begin
>          return (Ref => Object.Some_Access);
>       end Get_Some_Item;
>    end Some_Package;
>    
>    type Test;
>    package Test_Pkg is new Some_Package(Test);
>    
>    type Test is record
>       value : Integer;
>    end record;
>    
>    Thing : Test_Pkg.New_Type;
>    
> begin
>    Thing.Get_Some_Item.Value := 4;
> end Main;
> 
> 
> From your last response, if I understand correctly, then this
> should be OK, legal Ada.  Sorry for the contrived example, I
> just wanted to make sure I didn't mislead with my original message,
> so I generated a minimal example.  I would normally have stuff
> broken up into separate files with better naming, etc.
> 
> If Simon is seeing this, then the above code is one example of 
> what causes one of the crashes.  It is the one that breaks in
> both versions (GPL 2017 and FSF 7.2):
> 
> 
> $ gcc --version
> gcc.exe (Rev1, Built by MSYS2 project) 7.2.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> $ gprbuild default.gpr
> gcc -c -gnatn -gnato -gnatE -fstack-check -gnat12 -O3 main.adb
> +===========================GNAT BUG DETECTED==============================+
> | 7.2.0 (x86_64-w64-mingw32) Segmentation fault                            |
> | Error detected at main.adb:49:9                                          |
> | Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
> | Use a subject line meaningful to you and us to track the bug.            |
> | Include the entire contents of this bug box in the report.               |
> | Include the exact command that you entered.                              |
> | Also include sources listed below.                                       |
> +==========================================================================+
> 
> Please include these source files with error report
> Note that list may not be accurate in some cases,
> so please double check that the problem can still
> be reproduced with the set of files listed.
> Consider also -gnatd.n switch (see debug.adb).
> 
> Ada\Scratch\src\main.adb
> 
> compilation abandoned
> gprbuild: *** compilation phase failed
> 
> 
> My NOTE:  the compilation flags just happened to be
> whatever they were last.  This is from my scratch project
> space.  I don't think they actually matter.

I realize that some might point out the null access type.  It doesn't
change the result (again, contrived example), but for completion:

procedure Main is
   generic
      type Some_Item(<>);
   package Some_Package is

      type Some_Item_Access is access Some_Item;

      type New_Type is tagged limited private;

      type Some_Item_Holder(Ref : not null access Some_Item)
      is limited null record
         with
            Implicit_Dereference => Ref;

      function Get_Some_Item
         (Object : New_Type)
          return Some_Item_Holder;
      
      function Make(Ref : not null Some_Item_Access) return New_Type;

   private

      type New_Type is tagged limited record
         Some_Access : Some_Item_Access;
      end record;

   end Some_Package;

     

   package body Some_Package is
      function Get_Some_Item
         (Object : New_Type)
       return Some_Item_Holder
      is
      begin
         return (Ref => Object.Some_Access);
      end Get_Some_Item;
      
      function Make(Ref : not null Some_Item_Access) return New_Type is
      begin
         return (Some_Access => Ref);
      end Make;
   end Some_Package;
   
   type Test;
   package Test_Pkg is new Some_Package(Test);
   
   type Test is record
      value : Integer;
   end record;
   
   Thing : Test_Pkg.New_Type := Test_Pkg.Make(new Test);
   
begin
   Thing.Get_Some_Item.Value := 4;
end Main;

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

> If Simon is seeing this, then the above code is one example of 
> what causes one of the crashes.  It is the one that breaks in
> both versions (GPL 2017 and FSF 7.2):

Also on FSF 8.0.0 (20171216).

Re: Incomplete type generic formal interactions with Implicit_Dereference

[Randy Brukardt]

Yes, I believe your example is legal. (I didn't actually try compiling it to 
see if there is any other problem.)

                  Randy.

"Jere" <jhb.chat@gmail.com> wrote in message 
news:97b909da-a35b-45f9-aa88-ad7cc192a1c9@googlegroups.com...
> On Monday, January 22, 2018 at 8:08:59 PM UTC-5, Randy Brukardt wrote:
>> "Jere" wrote in message
>> ...
>> > Part of me thinks that since Some_Type is incomplete, that Ada wouldn't
>> > allow for an Implicit_Dereference declared on it.  I guess it depends 
>> > on
>> > if it is meant to be evaluated in the compilation of the generic itself
>> > or at the point at which the function is called.
>> >
>> > Anyone have any thoughts on this?
>>
>> I don't think we ever considered this case. But I think it is OK.
>>
>> Specifically, 4.1.5(6/3) says that a generalized reference denotes a view
>> equivalent to that of a dereference of the reference discriminant of the
>> reference object. Thus, any Legality Rules that apply to the dereference 
>> of
>> the discriminant apply to the generalized reference as well. For 
>> instance,
>> this includes any accessibility rules (which was an important part of the
>> design, as the accessibility rules prevent the access value from living
>> longer than the object containing the access discriminant).
>>
>> As such, any other Legality Rules, like the ones about incomplete types
>> would also apply. Specifically, 3.10.1(10/3): "A prefix that denotes an
>> object shall not be of an incomplete view."
>>
>> So a use of an Implicit_Dereference wherever the type is incomplete would
>> usually be illegal (there are a few ways that a dereference of an 
>> incomplete
>> view can be used, mainly to be passed as a parameter to some routine with 
>> an
>> access-to-incomplete parameter). But it would be OK where the type has 
>> been
>> completed (in this case, outside of the generic instantiation, the way 
>> you
>> intended to use this). This sounds like what you intended.
>>
>>                                    Randy.
>
> I think I gotcha.  Just wanted to verify since I realized that I presented
> the example a bit disjointed.  If I have a dummy example:
>
> procedure Main is
>   generic
>      type Some_Item(<>);
>   package Some_Package is
>
>      type New_Type is tagged limited private;
>
>      type Some_Item_Holder(Ref : not null access Some_Item)
>      is limited null record
>         with
>            Implicit_Dereference => Ref;
>
>      function Get_Some_Item
>         (Object : New_Type)
>       return Some_Item_Holder;
>
>   private
>
>      type Some_Item_Access is access Some_Item;
>
>      type New_Type is tagged limited record
>         Some_Access : Some_Item_Access;
>      end record;
>
>   end Some_Package;
>
>
>
>   package body Some_Package is
>      function Get_Some_Item
>         (Object : New_Type)
>       return Some_Item_Holder
>      is
>      begin
>         return (Ref => Object.Some_Access);
>      end Get_Some_Item;
>   end Some_Package;
>
>   type Test;
>   package Test_Pkg is new Some_Package(Test);
>
>   type Test is record
>      value : Integer;
>   end record;
>
>   Thing : Test_Pkg.New_Type;
>
> begin
>   Thing.Get_Some_Item.Value := 4;
> end Main;
>
>
> From your last response, if I understand correctly, then this
> should be OK, legal Ada.  Sorry for the contrived example, I
> just wanted to make sure I didn't mislead with my original message,
> so I generated a minimal example.  I would normally have stuff
> broken up into separate files with better naming, etc.
>
> If Simon is seeing this, then the above code is one example of
> what causes one of the crashes.  It is the one that breaks in
> both versions (GPL 2017 and FSF 7.2):
>
>
> $ gcc --version
> gcc.exe (Rev1, Built by MSYS2 project) 7.2.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
>
>
> $ gprbuild default.gpr
> gcc -c -gnatn -gnato -gnatE -fstack-check -gnat12 -O3 main.adb
> +===========================GNAT BUG 
> DETECTED==============================+
> | 7.2.0 (x86_64-w64-mingw32) Segmentation fault 
> |
> | Error detected at main.adb:49:9 
> |
> | Please submit a bug report; see https://gcc.gnu.org/bugs/ . 
> |
> | Use a subject line meaningful to you and us to track the bug. 
> |
> | Include the entire contents of this bug box in the report. 
> |
> | Include the exact command that you entered. 
> |
> | Also include sources listed below. 
> |
> +==========================================================================+
>
> Please include these source files with error report
> Note that list may not be accurate in some cases,
> so please double check that the problem can still
> be reproduced with the set of files listed.
> Consider also -gnatd.n switch (see debug.adb).
>
> Ada\Scratch\src\main.adb
>
> compilation abandoned
> gprbuild: *** compilation phase failed
>
>
> My NOTE:  the compilation flags just happened to be
> whatever they were last.  This is from my scratch project
> space.  I don't think they actually matter.
>