[Bug c/20689] New: strict aliasing with temporary variable never gives warnings

2005-03-30 Thread varun0005 at gmail dot com
int i;
void *p=(void *)&i;
gives strict-aliasing warning
 but
int i,*o;
o=&i;
void *p= o;
doesn't give any warning

-- 
   Summary: strict aliasing with temporary variable never gives
warnings
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: varun0005 at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20689


[Bug c/20689] strict aliasing with temporary variable never gives warnings

2005-03-30 Thread varun0005 at gmail dot com

--- Additional Comments From varun0005 at gmail dot com  2005-03-30 12:02 
---
I mean that since in case where you are doing "void *p=(void *)&i" then
according to strict-aliasing rules we get " warning: dereferencing type-punned
pointer will break strict-aliasing rules" , but same thing if done using a
temporary variable then why strict-aliasing warning doesn't appear.. According
to my understanding of strict aliasing if some unqualified version of pointer is
pointing to the address space(in out case void pointer pointing to int address
space) then it is violating  strict aliasing rule. So in second case also void
pointer is pointing to the int address space then why strict aliasing rules are
not violated. If ther is some error in my understanding of strict aliasing then
please inform .

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20689


[Bug c/20689] strict aliasing with temporary variable never gives warnings

2005-03-30 Thread varun0005 at gmail dot com

--- Additional Comments From varun0005 at gmail dot com  2005-03-31 05:05 
---
please ignore previous code and consider this piece as example ... problem is
same .the exact programs are following and command line was gcc -Wall -O2
test1.c test2.cIn this why test1.c not giving warning but test2.c giving
violation of strict-aliasing warning.
//test1.c
#include 
#include 
int main()
{ int *i;
float **q;
int **r;
i =(int *)malloc(sizeof(int));
r=&i;
q=(float **)r;
return 0;
}
//test2.c
int main(){
int *i;
float **q; 
i =(int *)malloc(sizeof(int));
q= (float **) &i;
return 0;
}

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20689


[Bug c/20689] strict aliasing with temporary variable never gives warnings

2005-03-31 Thread varun0005 at gmail dot com

--- Additional Comments From varun0005 at gmail dot com  2005-03-31 10:18 
---
please ignore previous code and consider this piece as example ... problem is
same .the exact programs are following and command line was gcc -Wall -O2
test1.c test2.cIn this why test1.c not giving warning but test2.c giving
violation of strict-aliasing warning.
//test1.c
#include 
#include 
int main()
{ int *i;
float **q;
int **r;
i =(int *)malloc(sizeof(int));
r=&i;
q=(float **)r;
return 0;
}
//test2.c
int main(){
int *i;
float **q; 
i =(int *)malloc(sizeof(int));
q= (float **) &i;
return 0;
}



-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20689


[Bug c/20708] New: strict aliasing warning

2005-03-31 Thread varun0005 at gmail dot com
since in case where you are doing "float **q=(void *)&i" then
according to strict-aliasing rules we get " warning: dereferencing type-punned
pointer will break strict-aliasing rules" , but same thing if done using a
temporary variable then why strict-aliasing warning doesn't appear.. According
to my understanding of strict aliasing if some unqualified version of pointer is
pointing to the address space then it is violating  strict aliasing rule. So in
second case also float ** pointer is pointing to the int address space then why
strict aliasing rules are not violated. If ther is some error in my
understanding of strict aliasing then please inform .

 .the exact programs are following and command line was gcc -Wall -O2
test1.c test2.cIn this why test1.c not giving warning but test2.c giving
violation of strict-aliasing warning.
//test1.c
#include 
#include 
int main()
{ int *i;
float **q;
int **r;
i =(int *)malloc(sizeof(int));
r=&i;
q=(float **)r;
return 0;
}
//test2.c
int main(){
int *i;
float **q; 
i =(int *)malloc(sizeof(int));
q= (float **) &i;
return 0;
}

-- 
   Summary: strict aliasing warning
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: varun0005 at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20708


[Bug c/20709] New: strict aliasing warning with float pointer pointing to int pointer

2005-03-31 Thread varun0005 at gmail dot com
since in case where you are doing "float **q=(float **)&i" then
according to strict-aliasing rules we get " warning: dereferencing type-punned
pointer will break strict-aliasing rules" , but same thing if done using a
temporary variable then why strict-aliasing warning doesn't appear.. According
to my understanding of strict aliasing if some unqualified version of pointer is
pointing to the address space then it is violating  strict aliasing rule. So in
second case also float ** pointer is pointing to the int address space then why
strict aliasing rules are not violated. If ther is some error in my
understanding of strict aliasing then please inform .

 .the exact programs are following and command line was gcc -Wall -O2
test1.c test2.cIn this why test1.c not giving warning but test2.c giving
violation of strict-aliasing warning.
//test1.c
#include 
#include 
int main()
{ int *i;
float **q;
int **r;
i =(int *)malloc(sizeof(int));
r=&i;
q=(float **)r;
return 0;
}
//test2.c
int main(){
int *i;
float **q; 
i =(int *)malloc(sizeof(int));
q= (float **) &i;
return 0;
}

-- 
   Summary: strict aliasing warning with float pointer pointing to
int pointer
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: varun0005 at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20709