* 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
* 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).