X-Authentication-Warning:	ieva01.lanet.lv: pavenis owned process doing -bs
Date:	Tue, 8 Jun 1999 10:41:37 +0300 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Nate Eldredge <nate AT cartsys DOT com>
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:	<Pine.A41.4.05.9906081035170.59440-100000@ieva01.lanet.lv>
MIME-Version:	1.0
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

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

- Raw text -