This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: type aliasing (was: gcc 3.3 -03 produces bad code)
On Thu, 17 Apr 2003 19:22:54 -0400 Daniel Jacobowitz <drow at mvista dot com> wrote:
> On Fri, Apr 18, 2003 at 12:59:45AM +0200, Tolga Dalman wrote:
> > On Thu, 17 Apr 2003 18:41:49 -0400 Daniel Jacobowitz <drow at mvista dot com>
> > wrote:
> >
> > > On Fri, Apr 18, 2003 at 12:32:24AM +0200, Tolga Dalman wrote:
> > > > hello,
> > > >
> > > > i missed to reply to the group, only Daniel got the message. sorry about
> > > > that.
> > > >
> > > > On Thu, 17 Apr 2003 18:25:24 -0400 Daniel Jacobowitz <drow at mvista dot com>
> > > > wrote:
> > > >
> > > > > On Fri, Apr 18, 2003 at 12:21:54AM +0200, Tolga Dalman wrote:
> > > > > > hello,
> > > > > >
> > > > > > On Thu, 17 Apr 2003 16:04:24 -0400 Daniel Jacobowitz
> > > > > > <drow at mvista dot com> wrote:
> > > > > >
> > > > > > > On Thu, Apr 17, 2003 at 09:32:23PM +0200, Ronald Kukuck wrote:
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I'm using:
> > > > > > > >
> > > > > > > > gcc version 3.3 20030226 (prerelease) (SuSE Linux)
> > > > > > > >
> > > > > > > > A large application (~25MB), which worked fine with the gcc
> > > > > > > > included in Suse 8.1, is now crashing in some modules if I
> > > > > > > > compile it with"-O3".
> > > > > > > >
> > > > > > > > I have tried to make the bug reproducible in a small file
> > > > > > > > (test1.C). To see it working OK use:
> > > > > > > >
> > > > > > > > g++ -O -o test test1.C
> > > > > > > >
> > > > > > > > to see it fail use:
> > > > > > > >
> > > > > > > > g++ -O3 -funroll-loops -mcpu=pentiumpro -o test test1.C
> > > > > > > >
> > > > > > > > or use simply:
> > > > > > > >
> > > > > > > > g++ -O3 -o test test1.C
> > > > > > > >
> > > > > > > > which is producing different results then above one.
> > > > > > > >
> > > > > > > >
> > > > > > > > Is there a workaround for this problem or is there a place where
> > > > > > > > I can download a new binary?
> > > > > > >
> > > > > > > > inline int ReadDbRecHead(int *pred,int *succ,int *next, short
> > > > > > > > *infopa, const int rec_no, const int dbunit) {
> > > > > > > > int *adress, *iptr;
> > > > > > > >
> > > > > > > > // DbsFindReadAdr(dbunit, rec_no);
> > > > > > > > adress = (int*)&s_in;
> > > > > > > > iptr=(int*)infopa;
> > > > > > > > *pred=*adress++;
> > > > > > > > *succ=*adress++;
> > > > > > > > *next=*adress++;
> > > > > > > > *iptr++=*adress++;
> > > > > > > > *iptr=*adress;
> > > > > > > > return(*adress);
> > > > > > > > }
> > > > > > >
> > > > > > > You can't cast a short * to an int * that way. I recommend
> > > > > > > searching for information on type aliasing, or seeing the effect
> > > > > > > of-fno-strict-aliasing on your code.
> > > > > >
> > > > > > well, i was wondering about type aliasing and the effect of
> > > > > > -fno-strict-aliasing for a long time. could you give a brief
> > > > > > explaination about aliasing? the example in the man page was not
> > > > > > really enlightening to me :( when "should" i use
> > > > > > -fno-strict-aliasing and when not?
> > > > >
> > > > > You should never use it - fix the code. I really can't explain it any
> > > > > better than that example.
> > > >
> > > > can't there be a case, where it can't be avoided to violate aliasing
> > > > rules? i haven't got an example handy, but as far as i understood, i
> > > > can't access to the low 8-bit data of a 32-bit variable directly, right?
> > >
> > > If you use "char *", that's not an aliasing violation. It's often not
> > > the best way to do it, but it's not an aliasing violation.
> >
> > sorry for insisting, but what is it then? my example was not meant to be a
> > "char*", but how about:
> >
> > uint32_t i = /* a value */;
> > uint8_t l;
> >
> > l = ((uint8_t*) &i)[1];
> >
> > would that be a violation? or this one:
> >
> > char* c = "teststring";
> > int* p;
> >
> > for (p = (int*) c; p; p++) {
> > /* do something */
> > }
>
> If it's a char *, then it's OK. If it's a uint8_t, then it's a
> violation. I'm not sure if the second one would be a problem but I
> think it might be, since you're accessing char data through an int*.
> You have to access an object through a pointer of the appropriate type,
> OR a pointer to char.
>
> I seriously recommend picking up a copy of the language standard, which
> explains this quite well.
>
after some digging in the iso c99 standard, most of my questions resolved.
so, whenever i access to a variable with it's type or any sub-type, no violation
will be performed.
thanks alot...