gcc/gnat 4.1.1 bug

gcc/gnat 4.1.1 bug

[M E Leypold]

Dear All,

In an attempt to circumvent the persistent problem when storing (via
the Read/Write attributes) variant record with controlled field type
I've set aside some time to try with newer compilers.

As I already reported gcc-3.4 (debian sarge package) also has the bug
in question.

Preleiminary results for gcc-4.1.1 (this time compiled) look good but
now I've found something that looks like a bug in Gcc-Gnat 4.1.1.

I'll shortly report my findings here for posteriority, then add
pointers to bug reports to relevant bug trackers when I've them
submitted. Considering the size of the code base in which the error
occurs (GtkAda 2.4.0), the fact that I've been going into that
adventure in an attempt to get rid of another much mor harmful bug and
considering that the bug actually doesn't bode well for gcc 4.1.1
anyway, I probably won't be able to follow that problem to its logical
conclusion.

Now, the bug:

When compiling GtkAda 2.4.0 (vanilla as it came from libre) with a
vanilla (as it cam from gnu.org) Gcc 4.1.1 (C, Ada enabled, no special
configuration, just configure/make/make install) I got some
gtkada-mdi.adb, announcing that at line 4774 the case 'None' would be
missing. There we find:

  ...
  4772        for Side in MDI.Docks'Range loop
  4773           Ref (MDI.Docks (Side));
  4774           case Side is
  4775              when Left | Right =>
  4776                 Widths (Side)  := Get_Allocation_Width (MDI.Docks (Side));
  4777                 Heights (Side) := 0;
  4778              when Top | Bottom =>
  4779                 Widths (Side)  := 0;
  4780                 Heights (Side) := Get_Allocation_Height (MDI.Docks (Side));
  4781           end case;
  ...

Indeed, the case 'None' is missing. MDI has the following type

  4752     procedure Set_Priorities
  4753       (MDI : access MDI_Window_Record; Prio : Priorities_Array)
  4754     is
  ...

where MDI_Window_Record is defined in the Interface as


   786     type MDI_Window_Record is new Gtk.Table.Gtk_Table_Record with record
   ...

   792        Docks : Notebook_Array := (others => null);
   793        --  The five possible docks (one on each side and one in the middle.
   ...

Ans Notebook_Array and its index range are defined as follows

    92     type Dock_Side is (Left, Right, Top, Bottom, None);
   ...
   772     type Notebook_Array is array (Left .. Bottom) of Gtk.Notebook.Gtk_Notebook;


So indeed, one would expect Side in line 4774 to be of subtype Left
.. Bottom, which it isn't (instead it seems to take the full range
Left .. None). Somehow the range is lost on the way from type
Notebook_Array to Side.

To test this, I've patched gtkada-mdi.ads like this

  4772        for Side in Notebook_Array'Range loop
  4773           Ref (MDI.Docks (Side));
  4774           case Side is

that is, to refer to Notebook_Array'Range explicitely. And voila --
everything compiles fine.

Request: Could anybody knowing more about the Ada type system state
that this is indeed a bug in gcc 4.1.1 or did some subtle point change
here between Ada 95 and Ada 2005?

If that is indeed a bug it saddens me no end: We're now back to the
old days where the type system doesn't work correctly anymore.

Regards -- Markus 

Request: Could anybody knowing more about the Ada type system ...

[M E Leypold]

Request: Could anybody knowing more about the Ada type system state
that this is indeed a bug in gcc 4.1.1 or did some subtle point change
here between Ada 95 and Ada 2005?

Regards -- Markus

Re: Request: Could anybody knowing more about the Ada type system ...

[Jeffrey R. Carter]

M E Leypold wrote:
> 
> Request: Could anybody knowing more about the Ada type system state
> that this is indeed a bug in gcc 4.1.1 or did some subtle point change
> here between Ada 95 and Ada 2005?

This kind of error existed in earlier versions of GNAT. I've sometimes used

when [values not in subtype] =>
    raise Program_Error;

to work around the error.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: Request: Could anybody knowing more about the Ada type system ...

[M E Leypold]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> M E Leypold wrote:
> > Request: Could anybody knowing more about the Ada type system state
> > that this is indeed a bug in gcc 4.1.1 or did some subtle point change
> > here between Ada 95 and Ada 2005?
> 
> This kind of error existed in earlier versions of GNAT. I've sometimes used
> 
> when [values not in subtype] =>
>     raise Program_Error;
> 
> to work around the error.

If you remember: 3.15p didn't have the bug?  And it comes back in 4.1.1? Wow.

Regards (and thanks) -- Markus

Re: Request: Could anybody knowing more about the Ada type system ...

[Jeffrey R. Carter]

M E Leypold wrote:
> 
> If you remember: 3.15p didn't have the bug?  And it comes back in 4.1.1? Wow.

3.15p did the same thing, IIRC. And, after reading Beneschan's post, 
maybe what I ran into was that kind of thing, and it wasn't an error 
after all.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: Request: Could anybody knowing more about the Ada type system ...

[M E Leypold]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> M E Leypold wrote:
> > If you remember: 3.15p didn't have the bug?  And it comes back in
> > 4.1.1? Wow.
> 
> 3.15p did the same thing, IIRC. And, after reading Beneschan's post,
> maybe what I ran into was that kind of thing, and it wasn't an error
> after all.

Well, what I compiled there was GtkAda 2.4.0 which supposedly built
with Gnat without evoking that error. I'll check that some time when
I've the leisure.

Regards -- Markus

Re: Request: Could anybody knowing more about the Ada type system ...

[M E Leypold]

M E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:
> 
> > M E Leypold wrote:
> > > If you remember: 3.15p didn't have the bug?  And it comes back in
> > > 4.1.1? Wow.
> > 
> > 3.15p did the same thing, IIRC. And, after reading Beneschan's post,
> > maybe what I ran into was that kind of thing, and it wasn't an error
> > after all.
> 
> Well, what I compiled there was GtkAda 2.4.0 which supposedly built
> with Gnat without evoking that error. I'll check that some time when

"with Gnat 3.15p"

> I've the leisure.
> 
> Regards -- Markus

Re: Request: Could anybody knowing more about the Ada type system ...

[Ludovic Brenta]

GtkAda is known to contain some illegal code that GNAT 3.15p
mistakenly accepts.

See Debian bugs #249663, #249664 and #249665 (http://bugs.debian.org)

-- 
Ludovic Brenta.

Re: Request: Could anybody knowing more about the Ada type system ...

[M E Leypold]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> GtkAda is known to contain some illegal code that GNAT 3.15p
> mistakenly accepts.
> 
> See Debian bugs #249663, #249664 and #249665 (http://bugs.debian.org)

Ah! Thanks. 

Regards -- Markus

Re: gcc/gnat 4.1.1 bug

[Adam Beneschan]

M E Leypold wrote:

> When compiling GtkAda 2.4.0 (vanilla as it came from libre) with a
> vanilla (as it cam from gnu.org) Gcc 4.1.1 (C, Ada enabled, no special
> configuration, just configure/make/make install) I got some
> gtkada-mdi.adb, announcing that at line 4774 the case 'None' would be
> missing. There we find:
>
>   ...
>   4772        for Side in MDI.Docks'Range loop
>   4773           Ref (MDI.Docks (Side));
>   4774           case Side is
>   4775              when Left | Right =>
>   4776                 Widths (Side)  := Get_Allocation_Width (MDI.Docks (Side));
>   4777                 Heights (Side) := 0;
>   4778              when Top | Bottom =>
>   4779                 Widths (Side)  := 0;
>   4780                 Heights (Side) := Get_Allocation_Height (MDI.Docks (Side));
>   4781           end case;
>   ...
>
> Indeed, the case 'None' is missing. MDI has the following type
>
>   4752     procedure Set_Priorities
>   4753       (MDI : access MDI_Window_Record; Prio : Priorities_Array)
>   4754     is
>   ...
>
> where MDI_Window_Record is defined in the Interface as
>
>
>    786     type MDI_Window_Record is new Gtk.Table.Gtk_Table_Record with record
>    ...
>
>    792        Docks : Notebook_Array := (others => null);
>    793        --  The five possible docks (one on each side and one in the middle.
>    ...
>
> Ans Notebook_Array and its index range are defined as follows
>
>     92     type Dock_Side is (Left, Right, Top, Bottom, None);
>    ...
>    772     type Notebook_Array is array (Left .. Bottom) of Gtk.Notebook.Gtk_Notebook;
>
>
> So indeed, one would expect Side in line 4774 to be of subtype Left
> .. Bottom, which it isn't (instead it seems to take the full range
> Left .. None). Somehow the range is lost on the way from type
> Notebook_Array to Side.
>
> To test this, I've patched gtkada-mdi.ads like this
>
>   4772        for Side in Notebook_Array'Range loop
>   4773           Ref (MDI.Docks (Side));
>   4774           case Side is
>
> that is, to refer to Notebook_Array'Range explicitely. And voila --
> everything compiles fine.
>
> Request: Could anybody knowing more about the Ada type system state
> that this is indeed a bug in gcc 4.1.1 or did some subtle point change
> here between Ada 95 and Ada 2005?


I think it was a bug for the compiler to accept the above code (i.e.
the code before you patched it).  It's not legal in either Ada 95 or
Ada 2005 as far as I can tell.  (And you can't assume that Ada code you
get from a public source is legal.  I've found numerous examples of
illegal code that still gets distributed because it's only been tried
on one compiler and that compiler has a bug.)

Here's how I piece things together: 3.6.2(7) says that for an array A,
A'Range is equivalent to A'First..A'Last (except that A is evaluated
only once).  4.9(8) says that a 'First or 'Last attribute reference is
static if its prefix statically denotes a statically constrained array
object.  4.9(14) defines what "statically denotes" means: the prefix
has to refer to a "direct name", "expanded name", or character literal.

However, MDI.Docks is not any of these.  A direct name is a simple
identifier, and an expanded name is just like a direct name except that
it could be qualified with package names or names of subprograms or
blocks that you're inside, or things like that.  MDI is an access
object, however.

This means that the prefix of MDI.Docks'Range does not statically
denote anything, and therefore MDI.Docks'First and 'Last (and therefore
'Range) are not static.  Thus, the subtype of "Side" is *not* a static
subtype.

The rules for a CASE statement say that if the index's type is a static
subtype, the choices must cover just that subtype range; while if it's
not a static subtype, the choices must cover the entire base range.  So
it's correct for the compiler to require that None be one of the
choices, and incorrect for the compiler to accept a CASE statement that
doesn't have that choice (or an "others" clause).  As far as I can
tell, none of the relevant rules have changed between Ada 95 and Ada
2005; therefore, the Ada 95 compiler was incorrect.

This does seem counter-intuitive.  But apparently requiring that the
prefix of 'First *statically* *denotes* the array object was put there
deliberately, and I'm sure there was a good reason, although I don't
know what it is.  In general, if you apply 'First on something that you
have to go through an access value to get to, the compiler has to make
sure the access value is not null, even if the 'First could be
determined at compile time (see the next paragraph).  Considering a
value that requires a null check to be "static" would undoubtedly cause
problems for other parts of the language.

(In Ada 95, MDI is not allowed to be null; in Ada 2005, it is.  Perhaps
that's why the Ada 95 compiler erroneously accepted the program: since
no null check was necessary, the compiler viewed MDI.Docks'First as a
constant, and then erroneously decided that it must be static, while
the Ada 2005 compiler includes a "null check" as part of the logic to
compute the value of 'First.  However, I don't see how whether null is
a legal value or not affects whether the attribute reference is treated
as static by 4.9.  Experiment: Change the definition of MDI from
"access MDI_Window_Record" to "not null access MDI_Window_Record".  If
this causes the program to compile, then the Ada 2005 compiler is wrong
too.)

Hope this helps.

Also, I assume that if I got something wrong, someone more
knowledgeable than I will correct me.

                                    -- Adam

Re: gcc/gnat 4.1.1 bug

[Ludovic Brenta]

Adam, I think your explanation is correct, and sufficient to construct
a minimal test case. But now I'm going to bed :)

-- 
Ludovic Brenta.

Re: gcc/gnat 4.1.1 bug

[M E Leypold]

"Adam Beneschan" <adam@irvine.com> writes:
> > Request: Could anybody knowing more about the Ada type system state
> > that this is indeed a bug in gcc 4.1.1 or did some subtle point change
> > here between Ada 95 and Ada 2005?
> 
> 
> I think it was a bug for the compiler to accept the above code (i.e.
> the code before you patched it).  It's not legal in either Ada 95 or


Just say that again: "for i in a'Range" is illegal if a is an array
variable? I don't understand.

> Ada 2005 as far as I can tell.  (And you can't assume that Ada code you
> get from a public source is legal.  I've found numerous examples of
> illegal code that still gets distributed because it's only been tried
> on one compiler and that compiler has a bug.)

That I understand very well: Gnat 3.15p accepted a number of
constructs in my program that were plainly illegal and which I had to
change when going to 4.1.1. Like that with

  generic

     type Element_Type is ...;

  package Alib.Set ....


a reference of the kind 

  S.Element_Type 

was legal (for S being an instance of the generic) whereas I
understand that should not have been the case.

> Here's how I piece things together: 3.6.2(7) says that for an array A,
> A'Range is equivalent to A'First..A'Last (except that A is evaluated

Ahh, here it comes.

> only once).  4.9(8) says that a 'First or 'Last attribute reference is
> static if its prefix statically denotes a statically constrained array
> object.  4.9(14) defines what "statically denotes" means: the prefix
> has to refer to a "direct name", "expanded name", or character literal.

> However, MDI.Docks is not any of these.  A direct name is a simple
> identifier, and an expanded name is just like a direct name except that
> it could be qualified with package names or names of subprograms or
> blocks that you're inside, or things like that.  MDI is an access
> object, however.

Sounds logical. I'll have to follow that on a weekend again when I
have more time.

> This means that the prefix of MDI.Docks'Range does not statically
> denote anything, and therefore MDI.Docks'First and 'Last (and therefore
> 'Range) are not static.  Thus, the subtype of "Side" is *not* a static
> subtype.

I can see, why that rule has bee introduced. But: Apart from how that
is formulated in the RM: Either MDI is null, than the dereferencing
fails and the case will not be executed or it is not null, then refers
to a range which is fixed at compile time. 

It might not be static in the sense of the letter in the RM, but it
certainly is in effect (uh - am I clear?). So I wonder why the
restriction (no access type) was introduced.

> 
> The rules for a CASE statement say that if the index's type is a static
> subtype, the choices must cover just that subtype range; while if it's
> not a static subtype, the choices must cover the entire base range.  So
> it's correct for the compiler to require that None be one of the
> choices, and incorrect for the compiler to accept a CASE statement that
> doesn't have that choice (or an "others" clause).  As far as I can
> tell, none of the relevant rules have changed between Ada 95 and Ada
> 2005; therefore, the Ada 95 compiler was incorrect.

OK.

> This does seem counter-intuitive.  

Yes.

> But apparently requiring that the prefix of 'First *statically*
> *denotes* the array object was put there deliberately, and I'm sure
> there was a good reason, although I don't know what it is.

I'd like to hear about that reason if anybody here knows about it. I'm
not only a complainer about license issues but also an avid
connoisseur of languages :-).

> In general, if you apply 'First on something that you
> have to go through an access value to get to, the compiler has to make
> sure the access value is not null, even if the 'First could be
> determined at compile time (see the next paragraph).  

> Considering a value that requires a null check to be "static" would
> undoubtedly cause problems for other parts of the language.

That is the point I don't see. I don't come the parts where the static
value is used except if the access value is /= null. So within the
block in question, actually starting from the ' of 'First, the access
value is guaranteed to be not null (like with access
discriminants). And this is a static condition applying to the block
in question. 

(I hope I'm understandable here: I'm not very well versed in the
jargon of the ARM, so please, just ignore me if I become garbled)


> 
> (In Ada 95, MDI is not allowed to be null; in Ada 2005, it is.  Perhaps
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why that?

> that's why the Ada 95 compiler erroneously accepted the program: since
> no null check was necessary, the compiler viewed MDI.Docks'First as a
> constant, and then erroneously decided that it must be static, while
> the Ada 2005 compiler includes a "null check" as part of the logic to
> compute the value of 'First.  However, I don't see how whether null is
> a legal value or not affects whether the attribute reference is treated
> as static by 4.9.  Experiment: Change the definition of MDI from
> "access MDI_Window_Record" to "not null access MDI_Window_Record".  If
> this causes the program to compile, then the Ada 2005 compiler is wrong
> too.)

I see. I'll have to postpone that experiment. I already pickled the
compiler and put it into my bit cellar for the winter and I'm now
trying to teach 3.15p not to barf on my data structure (which was the
original reason for this excursion).

> 
> Hope this helps.

It does. At last I can see, were I have to look. :-)

Thanks.

Regards -- Markus

Re: gcc/gnat 4.1.1 bug

[Adam Beneschan]

M E Leypold wrote:

> > This means that the prefix of MDI.Docks'Range does not statically
> > denote anything, and therefore MDI.Docks'First and 'Last (and therefore
> > 'Range) are not static.  Thus, the subtype of "Side" is *not* a static
> > subtype.
>
> I can see, why that rule has bee introduced. But: Apart from how that
> is formulated in the RM: Either MDI is null, than the dereferencing
> fails and the case will not be executed or it is not null, then refers
> to a range which is fixed at compile time.
>
> It might not be static in the sense of the letter in the RM, but it
> certainly is in effect (uh - am I clear?). So I wonder why the
> restriction (no access type) was introduced.

I think what you're saying is clear.

What's worse, perhaps, is that there's a difference even if no access
type is involved.  The rule in 4.8(14) also means "statically denotes"
doesn't apply to record components, so that in this case:

   type Enum is (e1, e2, e3, e4, e5);
   subtype Enum_Subtype is Enum range e2..e4;
   type Arr is array (Enum_Subtype) of integer;
   type Rec is record
      f1 : Arr;
   end record;

   X : Arr;
   Y : Rec;

   for J in X'Range loop        -- J's subtype is static
   for K in Y.f1'Range loop     -- K's subtype is not static

if my understanding is correct.

However, it's not feasible to expect the language designers to handle
every little case and combination of cases and combination of
combinations of cases so that things do what you expect, all the time.
Any change to the definition of "staticness" is going to have a
potential impact on approximately 6.023*(10**23) other places in the
RM, and all of them would need to studied before any change can be
made.  And believe me, the amount of work the language designers
already do is incredible, as it is.


> > (In Ada 95, MDI is not allowed to be null; in Ada 2005, it is.  Perhaps
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Why that?

Anonymous access types were added in Ada 95, and the only places they
were allowed were in subprogram parameters and discriminants.  In both
cases, they were added for a specific purpose for which named access
types were unsuitable, and null values didn't need to be handled for
those purposes.  For Ada 2005, anonymous access types were further
generalized and allowed in more places,
and it was decided it would be a good idea to allow null values; the
best solution involved changing the definition of access parameters so
that null values were allowed by default.  If you're interested in more
details, check out
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00231.TXT .

                                 -- Adam

Re: gcc/gnat 4.1.1 bug

[M E Leypold]

"Adam Beneschan" <adam@irvine.com> writes:
> 
> However, it's not feasible to expect the language designers to handle
> every little case and combination of cases and combination of
> combinations of cases so that things do what you expect, all the time.

Yep. As I see it, that is - finally - the price one just has to pay
for the rather complex subtyping Ada provides.

> Any change to the definition of "staticness" is going to have a
> potential impact on approximately 6.023*(10**23) other places in the
> RM, and all of them would need to studied before any change can be
> made.  And believe me, the amount of work the language designers
> already do is incredible, as it is.

I believe that very well. I've been learning Ada mostly from Barnes
"Programming in Ada 95" and there has been many a time when I read and
thought "Wow, there is a language that finally does it right" or "I'd
never have been able to design this language". Even if it is probably
an overestimation of one's own capabilities, Pascal, Modula, C and
others just look like languages that one could have designed oneself
with a bit of work and patience. Not the details of their modern
incarnations, but the general outline.  After all, they were designed
in principle by single persons. But with Ada: Never. Where those other
languages are just either nicely architected houses or grown villages,
Ada is a cathedral. Beautiful, mathematical and complete.

Did i alread mention that I find the ARM quite readable? Have you ever
tried to read one of the C standards?


> > > (In Ada 95, MDI is not allowed to be null; in Ada 2005, it is.  Perhaps
> >                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Why that?
> 
> Anonymous access types were added in Ada 95, and the only places they

Yes of course. Me stupid, I see now. :-).

> were allowed were in subprogram parameters and discriminants.  In both
> cases, they were added for a specific purpose for which named access
> types were unsuitable, and null values didn't need to be handled for
> those purposes.  For Ada 2005, anonymous access types were further
> generalized and allowed in more places,
> and it was decided it would be a good idea to allow null values; the
> best solution involved changing the definition of access parameters so
> that null values were allowed by default.  If you're interested in more

Yes, it's probably better like that. All that non allowing null here
and there but elsewhere didn't keep me from shooting myself into my
own foot in Ada 95, but only made me defining more named access types.

But probably I'm misusing the language in a number of areas anyway.

> details, check out
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00231.TXT .

I will. I already skimmed Barnes excellent introduction into the new
features of Ada 2005 some time ago and it was a delight.

Regards -- Markus