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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9479ab5b9a099a61,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: gcc/gnat 4.1.1 bug From: M E Leypold Date: 26 Jun 2006 20:50:27 +0200 Message-ID: <5llkrjn43w.fsf@hod.lan.m-e-leypold.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Some cool user agent (SCUG) NNTP-Posting-Host: 88.72.218.245 X-Trace: news.arcor-ip.de 1151347458 88.72.218.245 (26 Jun 2006 20:44:18 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!newsfeed0.kamp.net!newsfeed.kamp.net!news.unit0.net!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:5085 Date: 2006-06-26T20:50:27+02:00 List-Id: 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