int i; void *p=(void *)&i; gives strict-aliasing warning but int i,*o; o=&i; void *p= o; doesn't give any warning
I don't understand what you mean. Please provide a *complete* test case, with the command line you use and the output you get, and an explanation of why you want a warning.
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 .
(In reply to comment #2) > 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" No, you don't. Please provide a *complete* test case, with the command line you use and the output you get.
Also this is not done because void* cannot be dereferenced.
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.c....In this why test1.c not giving warning but test2.c giving violation of strict-aliasing warning. //test1.c #include <stdio.h> #include <stdlib.h> 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; }
Even the example you gave in comment #6 is hard to get unless you have flow analysis in the front-end which I really doubt is even going to be.
*** Bug 20709 has been marked as a duplicate of this bug. ***
Closing as invalid based comment #7.
*** Bug 23106 has been marked as a duplicate of this bug. ***