From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,51b019c4f21867e3
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "Alex R. Mosteo" <devnull@mailinator.com>
Newsgroups: comp.lang.ada
Subject: Re: Compiler bug
Date: Wed, 02 Apr 2008 13:39:23 +0200
Message-ID: <65h9jcF2f60qgU1@mid.individual.net>
References: <95883266-bd95-499f-a2dc-59580f2c5089@2g2000hsn.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Trace: individual.net grMVderAIjGN1jcyE3Oncwzz8M1sq8LA3CIjzEFA9DO8zURvs=
Cancel-Lock: sha1:3d8ZDcbs6+NGRB9hQcvA0K4h6U0=
User-Agent: KNode/0.10.5
Xref: g2news1.google.com comp.lang.ada:20754
Date: 2008-04-02T13:39:23+02:00
List-Id: <comp.lang.ada>

Maciej Sobczak wrote:

> Consider a trivial example with composition of interfaces:

My experience with interfaces (even without composition) in gpl-2007 has been
that they're not ready for use. I don't know if gcc-4.4 has advanced in that
front.

For sure if you continue to stress test them you'll find interesting bugs. And
it's great that you're doing so with small test cases. I usually hit these
bugs in large setups and when simplifying things for report they tend to go
away on me.

> 
> with Ada.Text_IO;
> 
> procedure A is
> 
>    package Stuff is
> 
>       type Base_1 is interface;
>       procedure P_1 (X : in Base_1) is abstract;
> 
>       type Base_2 is interface;
>       procedure P_2 (X : in Base_2) is abstract;
> 
>       type Middle is interface and Base_1 and Base_2;
> 
>       type Concrete is new Middle with null record;
>       procedure P_1 (X : in Concrete);
>       procedure P_2 (X : in Concrete);
> 
>       function Make_Concrete return Concrete;
> 
>    end Stuff;
> 
>    package body Stuff is
> 
>       procedure P_1 (X : in Concrete) is
>       begin
>          Ada.Text_IO.Put_Line ("Concrete.P_1");
>       end P_1;
> 
>       procedure P_2 (X : in Concrete) is
>       begin
>          Ada.Text_IO.Put_Line ("Concrete.P_2");
>       end P_2;
> 
>       function Make_Concrete return Concrete is
>          C : Concrete;
>       begin
>          return C;
>       end Make_Concrete;
> 
>    end Stuff;
> 
>    use Stuff;
> 
>    B_1 : Base_1'Class := Make_Concrete;
>    B_2 : Base_2'Class := Make_Concrete;
> 
> begin
>    B_1.P_1;
>    B_2.P_2;
> end;
> 
> $ gnatmake a
> $ ./a
> Concrete.P_1
> Concrete.P_1
> $
> 
> In other words, both calls dispatched to the same procedure.
> 
> Some experiments led me to the interesting observation:
> Changing this:
> 
>       type Middle is interface and Base_1 and Base_2;
> 
> to this:
> 
>       type Middle is interface and Base_2 and Base_1;
> 
> results in:
> 
> $ ./a
> Concrete.P_2
> Concrete.P_2
> 
> Again, both calls dispatched to the same procedure, but now I know
> that in both cases the dispatch goes to the *first* progenitor of the
> Middle interface. Obviously against 3.9.4-1/b.
> 
> Things get particularly funny when the signatures of P_1 and P_2 are
> different (say, they have different sets of parameters).
> 
> It all looks like the v-table got messed up.
> 
> $ gnatmake --version
> GNATMAKE 4.4.0 20080314 (experimental) [trunk revision 133226]
> 
> It is the newest version I could find for my system.
> 
> --
> Maciej Sobczak * www.msobczak.com * www.inspirel.com