| Summary: | Missed aliasing warning | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Volker Reichelt <reichelt> |
| Component: | middle-end | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | enhancement | CC: | gcc-bugs |
| Priority: | P3 | Keywords: | alias, diagnostic, monitored |
| Version: | 4.4.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2009-02-27 22:37:30 | |
| Bug Depends on: | 39117 | ||
| Bug Blocks: | |||
Actually this is not a bogus aliasing warning at all. You are accessing a character type as an int which is an aliasing violation. We should give a warning on both lines. The FE warning code doesn't warn for *((int *) &a + 4) because it doesn't recognize the form. This is what we get in both cases from the C frontend and in the second case from the C++ frontend. The PTA warning code doesn't trigger here because we do not prune a from the points-to sets. Related a little bit to bug 39117 or at least for the PTA side of things. > Actually this is not a bogus aliasing warning at all. You are accessing a
> character type as an int which is an aliasing violation.
Yeah, you're right. One can only access an int array via a char pointer, but not
the other way round. Sorry for screwing things up.
|
A IMHO the trunk issues a bogus warning for the following code snippet when compiling it with "-O2 -Wall" using the C++ frontend: ============================== int foo() { char a[10]; int i = *(int*)&a[4]; int j = *(int*)(a+4); return i+j; } ============================== bug.cc: In function 'int foo()': bug.cc:4: warning: dereferencing type-punned pointer will break strict-aliasing rules Interestingly, the warning is given only for line 4, but not line 5. Also the C frontend is not affected. If there's wrong alias info involved, this might lead to wrong-code bugs.