Longstanding GNAT bug, bad code, or both

Longstanding GNAT bug, bad code, or both

[Jeff C,]

The old Intermetrics X11 bindings have been broken since about GNAT 3.13 or
so because
of problems handling events from the X system.. I just verified this is
still broken (solaris 2.8) in gcc 3.4.1

I believe this is due to a GNAT bug related to aliasing and incorrect
assumptions.

The question is this really a GNAT bug or is this code perhaps illegal.

I believe I have a nice simple test case that does not even require the
bindings that shows how
the failure happens.

Basically the problem is that we have a variant record with a default value
for the discriminat at the
point of the type declaration.

A variable of this type is passed to a procedure via a 'access. The
procedure changes the entire
object in what appears to be a legal manner but when the procedure exits and
the main code
tries to access an element of the type that is not available for the default
discriminant value, the code
generates a constraint error due to a discriminant check.

It seemed to me that GNAT is assuming that the variable is not changing when
passed to a procedure
via a 'access. This seemed like a wrong assumption

I also tried it where the procedure that modifies the variable does so via
an out parameter mode.
Again same failure.
Removing the aliased from the variable declaration fixes the problem though
in that case.

This seems pretty clearly to be a broken compiler issue but it has been
broken for so long I find it hard
to believe that this could be the case.




with Text_IO;
procedure Show_Bug is

  type var (A : integer := 0) is
    record
     case A is
      when 0 =>
        Ok : Integer;
      when 1 =>
       Bad : Integer;
      when others =>
         null;
      end case;
    end record;


  procedure see (A : access var) is

  begin
    a.all := (A => 1, Bad => 2);

  end see;

begin
  declare
   I : aliased var;
  begin
    see(I'access);
    Text_IO.Put_Line(Integer'image(I.bad));  --- < Blows up here because
compiler 'thinks' a = 0 but
                                                                    --- 
of course it really is 1 so it should be ok to access bad.
  end;
end Show_Bug;



Jeff Creem

Re: Longstanding GNAT bug, bad code, or both

[Jeff C,]

Ok..Original post was still a bit confused and pointed to the wrong
line...but the problem is still real.

I've decided this really is a longstanding GNAT bug so I created a bugzilla
report. If someone
can tell me that the code is not legal Ada then I'll cancel the report.


--- Here is what the bugzilla now says


I believe there is a longstanding bug that has been present in GNAT since
about GNAT 3.13. The old intermetrics Xlib Ada bindings stopped working at
that time and it seemed to be related to the processing of the XEvent
variant records. I have created a very small test program that  think
demonstrates the same failure mode.

The problem appears to be that if a variable that is a variant record is
declared as aliased, some of the constraint checking logic fails in such a
way that it relies on the default value of the discriminant rather than the
current value.

This program demonstrates the problem both on Solaris and Windows XP
using gcc 3.4.1


with Text_Io;
procedure Aaa is


  type Var (A : Integer:=0) is
  record
    case A is
      when 0 =>
        Ok : Integer;
      when 1 =>
        Bad : Integer;
      when others =>
        null;
    end case;
  end record;


  procedure See (
        X : in out Var ) is

  begin
    --
    -- The following will blow up with a discriminant
    -- check error (contraint_error) when the actual parameter
    -- associated with X is declared aliased. Note that
    -- in this code I realize there is no good reason to
    -- declare it as aliased however this still effectively
    -- shows the problem.
    --
    X:= (
      A   => 1,
      Bad => 2);

  end See;

begin
  declare
    I : aliased Var;  -- If you make this not aliased, everything works fine
    --I : Var;
  begin
    See(I);
    Text_Io.Put_Line(Integer'Image(I.Bad));
  end;
end Aaa;

Re: Longstanding GNAT bug, bad code, or both -- Answer..Bad code.

[Jeff C,]

Ok. I submitted a bugzilla report and it has already been cancelled.
Apparently, declaring a variable as aliased makes it contrained.  (According
to one of the gcc Ada maintainers)

I did spend a little time looking through the LRM for this but
obviously not enough. It seemed a little counter-intutitive since one might
think that given an aliased
variable one would have to really worry about the discriminant changing all
the time, so why was the compiler
surprised when it did.......After thinking about it, it is probably
why the rule was created since I suppose otherwise the alias
detection/contraint checking would get pretty hard and
potentially computationally expensive at run time...

Of course I could be wrong about why the rule is what it is...but I am
willing to believe it.

Re: Longstanding GNAT bug, bad code, or both

[Stephen Leake]

"Jeff C," <jcreem@yahoo.com> writes:

> I've decided this really is a longstanding GNAT bug so I created a bugzilla
> report. If someone
> can tell me that the code is not legal Ada then I'll cancel the report.

Gnat 5.02a1 shows the same symptom. I agree it's a compiler bug. Since
I might run into this in real code, I'll submit it as an ACT customer.

-- 
-- Stephe

Re: Longstanding GNAT bug, bad code, or both -- Answer..Bad code.

[Stephen Leake]

"Jeff C," <jcreem@yahoo.com> writes:

> Ok. I submitted a bugzilla report and it has already been cancelled.
> Apparently, declaring a variable as aliased makes it contrained.  (According
> to one of the gcc Ada maintainers)

Ah. LRM 3.3.1 (9) says this. (I just searched for 'aliased' in the
Emacs info version; guess I should have done that earlier :).

Presumably I'll get the same response from ACT. Nice to know the
Bugzilla list is monitored so closely!

> After thinking about it, it is probably why the rule was created
> since I suppose otherwise the alias detection/contraint checking
> would get pretty hard and potentially computationally expensive at
> run time...

Sounds reasonable to me. The Annotated reference manual sheds no light
on this.

-- 
-- Stephe

Re: Longstanding GNAT bug, bad code, or both -- Answer..Bad code.

[Simon Wright]

Stephen Leake <stephen_leake@acm.org> writes:

> "Jeff C," <jcreem@yahoo.com> writes:
> 
> > Ok. I submitted a bugzilla report and it has already been
> > cancelled.  Apparently, declaring a variable as aliased makes it
> > contrained.  (According to one of the gcc Ada maintainers)
> 
> Ah. LRM 3.3.1 (9) says this. (I just searched for 'aliased' in the
> Emacs info version; guess I should have done that earlier :).

I work round this in the Booch Components using a horrible trick with
System.Address_To_Access_Conversions -- which works with GNAT &
ObjectAda (and I guess Rational Apex, I know there are/were users and
they haven't complained!)

-- 
Simon Wright                               100% Ada, no bugs.

Re: Longstanding GNAT bug, bad code, or both -- Answer..Bad code.

[Randy Brukardt]

This is old, but some enlightenment is provided...

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.6.1091897074.414.comp.lang.ada@ada-france.org...
> "Jeff C," <jcreem@yahoo.com> writes:
> > Ok. I submitted a bugzilla report and it has already been
> > cancelled.  Apparently, declaring a variable as aliased makes it
> > contrained.  (According to one of the gcc Ada maintainers)

One would think that the attempt to modify the object inside the procedure
would cause Constraint_Error to be raised. Or was this non-Ada code?

> > After thinking about it, it is probably why the rule was created
> > since I suppose otherwise the alias detection/contraint checking
> > would get pretty hard and potentially computationally expensive at
> > run time...
>
> Sounds reasonable to me. The Annotated reference manual sheds no light
> on this.

If you really want to understand this, read AI-363
(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00363.TXT). The reason
for the rules have to do with access subtypes. Tucker says it best: "Once I
sat down and began to piece together the set of patches we made to
try to fix the problems with 3.6(11), I was somewhat appalled." (And I would
have left out the "somewhat"! :-)

Anyway, Ada0Y is going to have a bit of incompatibility in this area, making
various access subtypes illegal, and then will drop 3.6(11). That means
"aliased" will no longer have the bizarre side-effect of making things
constrained. (Janus/Ada never got this right anyway, so I'm happy. :-) So
this issue is fixed (it is unfortunate that we didn't get this right in Ada
95).

                      Randy.

Re: Longstanding GNAT bug, bad code, or both -- Answer..Bad code.

[Jeff C,]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:C4WdnYJjvPMFNrbcRVn-ow@megapath.net...
> This is old, but some enlightenment is provided...
>
> "Stephen Leake" <stephen_leake@acm.org> wrote in message
> news:mailman.6.1091897074.414.comp.lang.ada@ada-france.org...
>> "Jeff C," <jcreem@yahoo.com> writes:
>> > Ok. I submitted a bugzilla report and it has already been
>> > cancelled.  Apparently, declaring a variable as aliased makes it
>> > contrained.  (According to one of the gcc Ada maintainers)
>
> One would think that the attempt to modify the object inside the procedure
> would cause Constraint_Error to be raised. Or was this non-Ada code?
>

Thanks for the clarification! (In the part I deleted).. And yes it was 
modified in Non-Ada code.