X-Authentication-Warning: ieva01.lanet.lv: pavenis owned process doing -bs Date: Tue, 8 Jun 1999 10:41:37 +0300 (WET) From: Andris Pavenis To: Nate Eldredge cc: djgpp-workers AT delorie DOT com Subject: Re: egcs-19990602 (gcc-2.95 prerelease) binaries for testing In-Reply-To: <375C565E.B33A7060@cartsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 7 Jun 1999, Nate Eldredge wrote: > Andris Pavenis wrote: > > > > On Mon, 07 Jun 1999, pavenis AT lanet DOT lv wrote: > > > compiler generates code which access class member > > > via wrong address (result is SIGSEGV for me). Below is > > > some test data I got (I simply copied this from rhide watch > > > window and added some comments) > > > > > > this: (TEphApp *) 0x240f20 > > > App: (TEphApp *) 0x240f20 > > > &slrcfg: (LoadedConfigFile *) 0x240f84 > > > &App->slrcfg: (LoadedConfigFile *) 0x240f84 > > > &satinfo: (LoadedConfigFile *) 0x240fa5 - false address > > > (but this address is used both when I call satinfo.foo() and > > > App->satinfo.foo() (name changed) from member function) > > > &(App->satinfo): (LoadedConfigFile *) 0x240fa8 - right value (I can > > > get contents here) > > > > > > I have this problem in rather big application (TVision + different > > > other stuff, TEphApp is derived from TApplication such stuff as > > > virtual base classes etc is present) only. > > > > > > I tried to reproduce this problem in a simple test example but didn't > > > succeed. Perhaps I'll check the same sometime under Linux as this > > > app can be built (and it should normally work) also under Linux. > > > > > > > I reproduced the same thing with egcs-19990601 (I updated gcc 2.95 > > branch with CVS then) under Linux (kernel 2.2.9, glibc-2.1.1). > > As I don't have good test example to send then perhaps I'll retry the same > > with later snapshots. Perhaps it would be worth to try also with > > gcc-2.96 tree to see whether something changes. > > I don't fully understand all the issues involved, but I understand > recent EGCS releases (since 1.1.2) do some special optimizations > regarding something called aliasing. (As you can tell, I haven't done > my homework :) This is said to break a lot of extant code. (The Linux > kernel folks, for instance, are having a lot of trouble.) There is an > option to turn it off; you might try that and see if it helps. > #pragma pack(1) /* Some definitions */ #pragma pack() is broken. Alignment remains 1 after second line (#pragma pack()) with gcc-2.95 prerelease but is 4 with earlier versions (I tested egcs-1.1.2). I sent small testsuite to djgpp-workers and egcs-bugs mailing lists. Using __attribute__((packed)) instead solves the problem (I tested this in Linux only yet). __attribute__((packed)) didn't work with C++ with some old gcc versions as far as I remeber, but now it's no more so So the situation is not so grave and I think we can continue tests with these binaries Andris