------- Comment #4 from hjl dot tools at gmail dot com 2008-02-14 20:16 -------
The first time we saw it is last Nov. But it is very hard to reproduce.
Any changes in input will make the warning to disappear. Here is what
Xuepeng got
The warning are caused by SSA and type-punning:
[EMAIL PROTECTED] gas]$ cat foo.c
typedef union i386_operand_type
{
struct
{
unsigned int reg8:1;
} bitfield;
unsigned int array[1];
} i386_operand_type;
extern void f(int *p)
{
*p = 100;
}
int main()
{
i386_operand_type t;
t.bitfield.reg8 = 1;
f(&t.array[1]);
return 0;
}
[EMAIL PROTECTED] gas]$ /usr/gcc-4.3/bin/gcc -O2 foo.c -S -Wall
foo.c: In function main:
foo.c:21: warning: pointer targets in passing argument 1 of f differ in
signedness
foo.c:21: warning: likely type-punning may break strict-aliasing rules: object
*{unknown} of main type int is referenced at or around foo.c:12 and may be
aliased to object {unknown} of main type unsigned char:1 which is
referenced at or around foo.c:21.
[EMAIL PROTECTED] gas]$
It's not the exactly extracted case. But it's enough to
explain the bug698. The SSA and function-inline bring about this bug. If using
-fdump-tree-salias we can get .salias file for the exacted case in which you
can see that compiler will generate a STRUCTURE-FIELD-TAG tree node for each
field of union t, like below:
;;Function main(main)
structure field tag SFT.13 created for var t offset 33 size 31
structrue field tag SFT.14 created for var t offset 32 size 32
structrue field tag SFT.15 created for var t offset 32 size 1
...................
structrue field tag SFT.47 created for var t offset 0 size 32
structrue field tag SFT.48 created for var t offset 0 size 1
Here we can treat the SFT.x as a pointer that points to the field of t. So the
SFT.13 is a pointer that points to t.bitfield.unused whose offset is 33 and
size is 31 and main type is assumed as "unsigned int:31", SFT.14 is a pointer
that points to t.array[1] whose offset is 32 and size is 32 and main type is
int, SFT.15 points t.bitfield.regmem whose offset is 32 and size is 1 and main
type is assumed as "unsigned char:1".
Because of -O2, the function main will inline the function f, the final codes
look like below:
main()
{
union i386_operand_type t;
int i;
int *D.1586;
<bb 2>:
t.bitfield.reg8 = 1;
D.1586_1 = (int *)&t.array;
i_6 = *D.1586_1;
return i_6;
}
D.1586_1 is a pointer in SSA form that points to t.array and will be used in
the next line. So according to strict aliasing rules, D.1586_1 will be conflict
with SFT.13~SFT.48 because their main types are different(except SFT.14 and
SFT.47)but point to the same memory area union t. The number of warnings equals
to the number of SFT.
In tc-i386.c, function uints_equal has statements:
....
case 2:
if(x[1]!=y[1])
return 0;
......
function update_imm has statements:
........
if((....&&!UINTS_EQUAL(overlap, imm8) &&...))
....
and function md_assemble calls function finalize_imm, and finalize_imme calls
update_imm, update_imm calls uints_equal. The optimization of function-inline
will get final statements(in ssa form) like below:
structure field tag SFT.10215 created for var imm8 offset 33 size 31
............
<L168>:;
...
D.29407_741 = &imm8.array[1];
D.29408_742 = *D.29407_741
...
So the ssa variable D.29407_741 is conflict with SFT.10215(and others)
according to the strict-aliasing rules. And please notice that without the
using in the next line, without this warning.
You may be wonder that why I am sure about my conclusion. That because there is
only one place in gcc source files to generate this warning, function
strict_aliasing_warn(tree alias_site, tree object1, bool is_ptr1, tree object2,
bool is_ptr2, bool filter_artificials) in tree-ssa-alias-warnings.c. I have
debuged into this function and investigated the object1 and object2. So it
does.
If you modified the file tc-i386.c, the compiler will not inline some specific
functions based on the inline strategy and at last you won't get code like
above and warnings. That's why I have said it's "unstable".
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Joey dot ye at intel dot
| |com, xuepeng dot guo at
| |intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35200
