Compiler bug

Compiler bug

[Maciej Sobczak]

Consider a trivial example with composition of interfaces:

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

Re: Compiler bug

[Ludovic Brenta]

Hi Maciej, why did you report the bug here instead of at http://gcc.gnu.org/bugzilla?

--
Ludovic Brenta.

Re: Compiler bug

[Maciej Sobczak]

On 1 Kwi, 15:00, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Hi Maciej, why did you report the bug here instead of athttp://gcc.gnu.org/bugzilla?

To warn others. ;-)

I will try to report there.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Compiler bug

[Alex R. Mosteo]

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

Re: Compiler bug

[Per Sandberg]

Well it was still in AdaCore:s compiler yesterday so I took the liberty 
to report it since people at my company is using the Ada2005 features in 
GNAT and I want to be proactive.

/Per

Maciej Sobczak wrote:
> Consider a trivial example with composition of interfaces:
> 
> 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

Compiler Bug

[REH]

I have an issue that my compiler vendor is trying to tell me is not a
bug.  I have two functions.  They both have a local variable of the
same name.  One calls the other (which is inlined).  The compiler
treats the variable in the caller as if it is of the same type as the
one in the callee.  Because of this, we get a constraint_error
exception.  The problem goes away when the pragma inline is removed.
The vendor is trying to tell me that this behavior is acceptable and
correct.  I do not believe that it is.  Please tell me who it right.

REH

Re: Compiler Bug

[Lucretia]

On Dec 4, 9:58 pm, REH <spamj...@stny.rr.com> wrote:
> I have an issue that my compiler vendor is trying to tell me is not a
> bug.  I have two functions.  They both have a local variable of the
> same name.  One calls the other (which is inlined).  The compiler
> treats the variable in the caller as if it is of the same type as the
> one in the callee.  Because of this, we get a constraint_error
> exception.  The problem goes away when the pragma inline is removed.
> The vendor is trying to tell me that this behavior is acceptable and
> correct.  I do not believe that it is.  Please tell me who it right.
>
> REH

Which compiler? Have you tried it in GNAT?

Can you post the code?

Thanks,
Luke.

Re: Compiler Bug

[REH]

On Dec 4, 5:25 pm, Lucretia <lucret...@lycos.co.uk> wrote:
> On Dec 4, 9:58 pm, REH <spamj...@stny.rr.com> wrote:
>
> > I have an issue that my compiler vendor is trying to tell me is not a
> > bug.  I have two functions.  They both have a local variable of the
> > same name.  One calls the other (which is inlined).  The compiler
> > treats the variable in the caller as if it is of the same type as the
> > one in the callee.  Because of this, we get a constraint_error
> > exception.  The problem goes away when the pragma inline is removed.
> > The vendor is trying to tell me that this behavior is acceptable and
> > correct.  I do not believe that it is.  Please tell me who it right.
>
> > REH
>
> Which compiler? Have you tried it in GNAT?
>
> Can you post the code?
>
> Thanks,
> Luke.

No, I can't, sorry.  But the gist of it is:

function F1 return T1;
pragma Inline(F1);

function F1 return T1 is
  R : T1;
begin
  -- do stuff
  return R;
end F1;

function F2 return T2 is
  V : T1 := F1;
  R : T2;
begin
  -- do stuff
  return R;
end F2;

The compiler and debugger treat the R in F2 as if it is of type T1,
not T2.  Exceeding the bounds of T1 cause F2 to raise a
constraint_error.  The problem goes away if the pragma inline is
removed.

Thanks,
REH

Re: Compiler Bug

[Randy Brukardt]

"REH" <spamjunk@stny.rr.com> wrote in message
news:97d0825d-ee08-45ef-b736-ca005caf1a81@e23g2000prf.googlegroups.com...
> No, I can't, sorry.  But the gist of it is:
>
> function F1 return T1;
> pragma Inline(F1);
>
> function F1 return T1 is
>   R : T1;
> begin
>   -- do stuff
>   return R;
> end F1;
>
> function F2 return T2 is
>   V : T1 := F1;
>   R : T2;
> begin
>   -- do stuff
>   return R;
> end F2;
>
> The compiler and debugger treat the R in F2 as if it is of type T1,
> not T2.  Exceeding the bounds of T1 cause F2 to raise a
> constraint_error.  The problem goes away if the pragma inline is
> removed.

The way you describe it, it sounds like a compiler bug. But without seeing
the actual code, it is impossible to tell for sure. (It's not unusual for a
compiler-bug-reporter to see one problem when something totally different is
going on -- it even happens to me from time-to-time.) Ada's visibility rules
are complex enough that you could be getting some other kind of conflict
without realizing it.

                                       Randy.

Re: Compiler Bug

[REH]

On Dec 4, 5:45 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "REH" <spamj...@stny.rr.com> wrote in message
>
> news:97d0825d-ee08-45ef-b736-ca005caf1a81@e23g2000prf.googlegroups.com...
>
>
>
> > No, I can't, sorry.  But the gist of it is:
>
> > function F1 return T1;
> > pragma Inline(F1);
>
> > function F1 return T1 is
> >   R : T1;
> > begin
> >   -- do stuff
> >   return R;
> > end F1;
>
> > function F2 return T2 is
> >   V : T1 := F1;
> >   R : T2;
> > begin
> >   -- do stuff
> >   return R;
> > end F2;
>
> > The compiler and debugger treat the R in F2 as if it is of type T1,
> > not T2.  Exceeding the bounds of T1 cause F2 to raise a
> > constraint_error.  The problem goes away if the pragma inline is
> > removed.
>
> The way you describe it, it sounds like a compiler bug. But without seeing
> the actual code, it is impossible to tell for sure. (It's not unusual for a
> compiler-bug-reporter to see one problem when something totally different is
> going on -- it even happens to me from time-to-time.) Ada's visibility rules
> are complex enough that you could be getting some other kind of conflict
> without realizing it.
>
>                                        Randy.

Sure, I understand completely.  Thank you both for your help.

REH

Re: Compiler Bug

[Adam Beneschan]

On Dec 4, 2:45 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "REH" <spamj...@stny.rr.com> wrote in message
>
> news:97d0825d-ee08-45ef-b736-ca005caf1a81@e23g2000prf.googlegroups.com...
>
>
>
> > No, I can't, sorry.  But the gist of it is:
>
> > function F1 return T1;
> > pragma Inline(F1);
>
> > function F1 return T1 is
> >   R : T1;
> > begin
> >   -- do stuff
> >   return R;
> > end F1;
>
> > function F2 return T2 is
> >   V : T1 := F1;
> >   R : T2;
> > begin
> >   -- do stuff
> >   return R;
> > end F2;
>
> > The compiler and debugger treat the R in F2 as if it is of type T1,
> > not T2.  Exceeding the bounds of T1 cause F2 to raise a
> > constraint_error.  The problem goes away if the pragma inline is
> > removed.
>
> The way you describe it, it sounds like a compiler bug. But without seeing
> the actual code, it is impossible to tell for sure. (It's not unusual for a
> compiler-bug-reporter to see one problem when something totally different is
> going on -- it even happens to me from time-to-time.) Ada's visibility rules
> are complex enough that you could be getting some other kind of conflict
> without realizing it.

Right... but pragma Inline isn't supposed to affect the visibility
rules at all.  So no matter what he's doing, if he's actually seeing a
case where a program with an Inline pragma raises a Constraint_Error,
and removing the pragma (without doing anything else to the program)
causes the Constraint_Error to go away, then I can't think of any way
that this could happen with a correct compiler.  (That's not true in
reverse, by the way... there are legitimate cases when adding an
Inline pragma could make a Constraint_Error go away, if an optimizer
determines that some of the inlined code can be eliminated for a
particular call.  But adding an Inline pragma should never make a
Constraint_Error appear that didn't appear before, I don't think.)

                            -- Adam

Re: Compiler Bug

[Samuel Tardieu]

>>>>> "Adam" == Adam Beneschan <adam@irvine.com> writes:

Adam> That's not true in reverse, by the way... there are legitimate
Adam> cases when adding an Inline pragma could make a Constraint_Error
Adam> go away, if an optimizer determines that some of the inlined
Adam> code can be eliminated for a particular call.

Can you produce such an example? I am curious about it.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: Compiler Bug

[Adam Beneschan]

On Dec 5, 1:46 am, Samuel Tardieu <s...@rfc1149.net> wrote:
> >>>>> "Adam" == Adam Beneschan <a...@irvine.com> writes:
>
> Adam> That's not true in reverse, by the way... there are legitimate
> Adam> cases when adding an Inline pragma could make a Constraint_Error
> Adam> go away, if an optimizer determines that some of the inlined
> Adam> code can be eliminated for a particular call.
>
> Can you produce such an example? I am curious about it.

I think this is such an example.  It's possible that I'm technically
wrong about what the language requires, though; if so, I'm hoping one
of the other language experts will jump in.  Some of the language
rules about optimization have, I think, always been seen as a bit
fuzzy.


subtype Int10 is Integer range 1..10;

procedure P1 (X : in Int10; Y, Z : out Int10) is
begin
   Y := X + 1;
   Z := X + 5;
end P1;

procedure P2 is
   A1, A2, A3 : Int10;
begin
   ... code whose effect puts the value 6 in A1
   P1 (A1, A2, A3);
   ... code that uses A2 but does nothing with A3
end P2;


Without any inlining, a Constraint_Error will surely be raised when P1
assigns to Z.  If P1 is inlined, however, the compiler could change
the call to P1 to code that, in effect, performs "A2 := A1 + 1; A3 :=
A1 + 5;"; then it could notice that since A3 is a local variable and
is used in the remainder of P2, the assignment "A3 := A1 + 5" is
pointless and can be eliminated---and thus the Constraint_Error would
not be raised.  I believe the Implementation Permissions of 11.6 allow
this result.

                              -- Adam

Re: Compiler Bug

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:9984a3f8-1e45-44c0-96d6-4bd9462c57d5@d27g2000prf.googlegroups.com...
...
> I think this is such an example.  It's possible that I'm technically
> wrong about what the language requires, though; if so, I'm hoping one
> of the other language experts will jump in.  Some of the language
> rules about optimization have, I think, always been seen as a bit
> fuzzy.
>
>
> subtype Int10 is Integer range 1..10;
>
> procedure P1 (X : in Int10; Y, Z : out Int10) is
> begin
>    Y := X + 1;
>    Z := X + 5;
> end P1;
>
> procedure P2 is
>    A1, A2, A3 : Int10;
> begin
>    ... code whose effect puts the value 6 in A1
>    P1 (A1, A2, A3);
>    ... code that uses A2 but does nothing with A3
> end P2;
>
>
> Without any inlining, a Constraint_Error will surely be raised when P1
> assigns to Z.  If P1 is inlined, however, the compiler could change
> the call to P1 to code that, in effect, performs "A2 := A1 + 1; A3 :=
> A1 + 5;"; then it could notice that since A3 is a local variable and
> is used in the remainder of P2, the assignment "A3 := A1 + 5" is
> pointless and can be eliminated---and thus the Constraint_Error would
> not be raised.  I believe the Implementation Permissions of 11.6 allow
> this result.

I think that you are right in this case. If there were exception handlers in
the code, then some optimizations wouldn't be allowed.

                    Randy.

Re: Compiler Bug

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:9984a3f8-1e45-44c0-96d6-4bd9462c57d5@d27g2000prf.googlegroups.com...
...
> I think this is such an example.  It's possible that I'm technically
> wrong about what the language requires, though; if so, I'm hoping one
> of the other language experts will jump in.  Some of the language
> rules about optimization have, I think, always been seen as a bit
> fuzzy.
>
>
> subtype Int10 is Integer range 1..10;
>
> procedure P1 (X : in Int10; Y, Z : out Int10) is
> begin
>    Y := X + 1;
>    Z := X + 5;
> end P1;
>
> procedure P2 is
>    A1, A2, A3 : Int10;
> begin
>    ... code whose effect puts the value 6 in A1
>    P1 (A1, A2, A3);
>    ... code that uses A2 but does nothing with A3
> end P2;
>
>
> Without any inlining, a Constraint_Error will surely be raised when P1
> assigns to Z.  If P1 is inlined, however, the compiler could change
> the call to P1 to code that, in effect, performs "A2 := A1 + 1; A3 :=
> A1 + 5;"; then it could notice that since A3 is a local variable and
> is used in the remainder of P2, the assignment "A3 := A1 + 5" is
> pointless and can be eliminated---and thus the Constraint_Error would
> not be raised.  I believe the Implementation Permissions of 11.6 allow
> this result.

I think that you are right in this case. If there were exception handlers in
the code, then some optimizations wouldn't be allowed.

                    Randy.

Re: Compiler Bug

[Randy Brukardt]

"REH" <spamjunk@stny.rr.com> wrote in message
news:97d0825d-ee08-45ef-b736-ca005caf1a81@e23g2000prf.googlegroups.com...
> No, I can't, sorry.  But the gist of it is:
>
> function F1 return T1;
> pragma Inline(F1);
>
> function F1 return T1 is
>   R : T1;
> begin
>   -- do stuff
>   return R;
> end F1;
>
> function F2 return T2 is
>   V : T1 := F1;
>   R : T2;
> begin
>   -- do stuff
>   return R;
> end F2;
>
> The compiler and debugger treat the R in F2 as if it is of type T1,
> not T2.  Exceeding the bounds of T1 cause F2 to raise a
> constraint_error.  The problem goes away if the pragma inline is
> removed.

The way you describe it, it sounds like a compiler bug. But without seeing
the actual code, it is impossible to tell for sure. (It's not unusual for a
compiler-bug-reporter to see one problem when something totally different is
going on -- it even happens to me from time-to-time.) Ada's visibility rules
are complex enough that you could be getting some other kind of conflict
without realizing it.

                                       Randy.

Re: Compiler Bug

[Keith Thompson]

REH <spamjunk@stny.rr.com> writes:
> On Dec 4, 5:25 pm, Lucretia <lucret...@lycos.co.uk> wrote:
>> On Dec 4, 9:58 pm, REH <spamj...@stny.rr.com> wrote:
>>
>> > I have an issue that my compiler vendor is trying to tell me is not a
>> > bug.  I have two functions.  They both have a local variable of the
>> > same name.  One calls the other (which is inlined).  The compiler
>> > treats the variable in the caller as if it is of the same type as the
>> > one in the callee.  Because of this, we get a constraint_error
>> > exception.  The problem goes away when the pragma inline is removed.
>> > The vendor is trying to tell me that this behavior is acceptable and
>> > correct.  I do not believe that it is.  Please tell me who it right.
>>
>> Which compiler? Have you tried it in GNAT?
>>
>> Can you post the code?
>
> No, I can't, sorry.  But the gist of it is:
>
> function F1 return T1;
> pragma Inline(F1);
>
> function F1 return T1 is
>   R : T1;
> begin
>   -- do stuff
>   return R;
> end F1;
>
> function F2 return T2 is
>   V : T1 := F1;
>   R : T2;
> begin
>   -- do stuff
>   return R;
> end F2;
>
> The compiler and debugger treat the R in F2 as if it is of type T1,
> not T2.  Exceeding the bounds of T1 cause F2 to raise a
> constraint_error.  The problem goes away if the pragma inline is
> removed.

If you can't post your original code for whatever reason (because it's
proprietary, or because it's too big, or whatever), can you construct
a small example that exhibits the same symptom?  Perhaps taking your
"gist of it" code above and adding definitions for T1 and T2 and some
output statements would do it.

Others here could try based on what you've posted, but without knowing
what compiler you're using they'd have no way of knowing if they've
reproduced the problem.

-- 
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Looking for software development work in the San Diego area.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Compiler Bug

[REH]

On Dec 6, 1:51 am, Keith Thompson <ks...@mib.org> wrote:
> Others here could try based on what you've posted, but without knowing
> what compiler you're using they'd have no way of knowing if they've
> reproduced the problem.
>
Sure, I understand that.  I didn't post it for the reasons you stated,
and I didn't mention the compiler because I didn't want to disparage
them (they are being responsive and helpful).  It turns out, thought,
that the problem was a bug in the debugger (it displayed T2 as the
wrong type).  The exception was cause by a different bug in the
compiler.  The two problems combined made it difficult the diagnose.
This was a bad coincidence; the compiler is normally very good.

Thanks to all for the comments.

REH