* gcc 3.3 -03 produces bad code @ 2003-04-17 20:10 Ronald Kukuck 2003-04-17 20:25 ` Daniel Jacobowitz 0 siblings, 1 reply; 8+ messages in thread From: Ronald Kukuck @ 2003-04-17 20:10 UTC (permalink / raw) To: gcc [-- Attachment #1: Type: text/plain, Size: 620 bytes --] 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? Thanks Ronald [-- Attachment #2: test1.C --] [-- Type: text/plain, Size: 1826 bytes --] // // g++ -O -o test test1.C // OK // // g++ -O3 -funroll-loops -Wuninitialized -mcpu=pentiumpro -Wno-deprecated -o test test1.C // BUG #include <cstring> #include <cstdlib> #include <iostream> using namespace std; #define NIL 1 short s_in[12]; class Cq_rab { public: int first; int last; int akt; int pred; int succ; int next; Cq_rab() { first=NIL; last=NIL; akt=NIL; pred=NIL; succ=NIL; next=NIL; }; }; 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); } inline void Gthdpa(int *objide, int *objqcn, int *objiln, int *objcln, Cq_rab *rab, int rcunit) { short infopa[4]; ReadDbRecHead(&rab->pred,&rab->succ,&rab->next,infopa,rab->akt,rcunit); *objide = infopa[0]; *objqcn = infopa[1]; *objcln = infopa[2]; *objiln = infopa[3]; return; } int main() { int objcln, objide, objiln, objqcn; int unit = 81; Cq_rab rab; s_in[6]=11111; s_in[7]=12222; s_in[8]=13333; s_in[9]=14444; // // If you uncomment the following lines, only the second line(value) is // wrong // /* short s_out[4]; int out[4]; memcpy(s_out,s_in,8); out[0] = s_out[0]; out[1] = s_out[1]; out[2] = s_out[2]; out[3] = s_out[3]; */ Gthdpa(&objide,&objqcn,&objiln,&objcln,&rab,unit); cout << objide << endl; cout << objqcn << endl; cout << objcln << endl; cout << objiln << endl; return(0); } ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gcc 3.3 -03 produces bad code 2003-04-17 20:10 gcc 3.3 -03 produces bad code Ronald Kukuck @ 2003-04-17 20:25 ` Daniel Jacobowitz [not found] ` <20030418002154.5a50789b.ates100@web.de> 0 siblings, 1 reply; 8+ messages in thread From: Daniel Jacobowitz @ 2003-04-17 20:25 UTC (permalink / raw) To: Ronald Kukuck; +Cc: gcc 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <20030418002154.5a50789b.ates100@web.de>]
[parent not found: <20030417222524.GA28275@nevyn.them.org>]
* Re: type aliasing (was: gcc 3.3 -03 produces bad code) [not found] ` <20030417222524.GA28275@nevyn.them.org> @ 2003-04-17 23:01 ` Tolga Dalman 2003-04-17 23:22 ` Daniel Jacobowitz 0 siblings, 1 reply; 8+ messages in thread From: Tolga Dalman @ 2003-04-17 23:01 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gcc 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@mvista.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@mvista.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? Tolga Dalman. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: type aliasing (was: gcc 3.3 -03 produces bad code) 2003-04-17 23:01 ` type aliasing (was: gcc 3.3 -03 produces bad code) Tolga Dalman @ 2003-04-17 23:22 ` Daniel Jacobowitz 2003-04-17 23:38 ` Tolga Dalman 0 siblings, 1 reply; 8+ messages in thread From: Daniel Jacobowitz @ 2003-04-17 23:22 UTC (permalink / raw) To: Tolga Dalman; +Cc: gcc 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@mvista.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@mvista.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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: type aliasing (was: gcc 3.3 -03 produces bad code) 2003-04-17 23:22 ` Daniel Jacobowitz @ 2003-04-17 23:38 ` Tolga Dalman 2003-04-18 0:27 ` Daniel Jacobowitz 2003-04-18 10:41 ` Andrew Haley 0 siblings, 2 replies; 8+ messages in thread From: Tolga Dalman @ 2003-04-17 23:38 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gcc On Thu, 17 Apr 2003 18:41:49 -0400 Daniel Jacobowitz <drow@mvista.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@mvista.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@mvista.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 */ } thanks, Tolga Dalman. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: type aliasing (was: gcc 3.3 -03 produces bad code) 2003-04-17 23:38 ` Tolga Dalman @ 2003-04-18 0:27 ` Daniel Jacobowitz 2003-04-18 1:11 ` Tolga Dalman 2003-04-18 10:41 ` Andrew Haley 1 sibling, 1 reply; 8+ messages in thread From: Daniel Jacobowitz @ 2003-04-18 0:27 UTC (permalink / raw) To: Tolga Dalman; +Cc: gcc 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@mvista.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@mvista.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@mvista.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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: type aliasing (was: gcc 3.3 -03 produces bad code) 2003-04-18 0:27 ` Daniel Jacobowitz @ 2003-04-18 1:11 ` Tolga Dalman 0 siblings, 0 replies; 8+ messages in thread From: Tolga Dalman @ 2003-04-18 1:11 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gcc On Thu, 17 Apr 2003 19:22:54 -0400 Daniel Jacobowitz <drow@mvista.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@mvista.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@mvista.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@mvista.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... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: type aliasing (was: gcc 3.3 -03 produces bad code) 2003-04-17 23:38 ` Tolga Dalman 2003-04-18 0:27 ` Daniel Jacobowitz @ 2003-04-18 10:41 ` Andrew Haley 1 sibling, 0 replies; 8+ messages in thread From: Andrew Haley @ 2003-04-18 10:41 UTC (permalink / raw) To: Tolga Dalman; +Cc: Daniel Jacobowitz, gcc Tolga Dalman writes: > On Thu, 17 Apr 2003 18:41:49 -0400 Daniel Jacobowitz <drow@mvista.com> wrote: > > > 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? Yes. > or this one: > > char* c = "teststring"; > int* p; > > for (p = (int*) c; p; p++) { > /* do something */ > } Yes. This isn't the place to have this discussion. For information about type based optimization, please read http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm. Please also note that if you want to access data via an lvalue of a different type, use a union. Redirected to gcc-help@gcc.gnu.org. Andrew. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-04-18 7:43 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-04-17 20:10 gcc 3.3 -03 produces bad code Ronald Kukuck 2003-04-17 20:25 ` Daniel Jacobowitz [not found] ` <20030418002154.5a50789b.ates100@web.de> [not found] ` <20030417222524.GA28275@nevyn.them.org> 2003-04-17 23:01 ` type aliasing (was: gcc 3.3 -03 produces bad code) Tolga Dalman 2003-04-17 23:22 ` Daniel Jacobowitz 2003-04-17 23:38 ` Tolga Dalman 2003-04-18 0:27 ` Daniel Jacobowitz 2003-04-18 1:11 ` Tolga Dalman 2003-04-18 10:41 ` Andrew Haley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).