Mail Archives: djgpp-workers/1999/06/07/19:32:53
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.
--
Nate Eldredge
nate AT cartsys DOT com
- Raw text -