public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/27464] New: unsuitable aliasing rule warning
@ 2006-05-06 22:14 thor at math dot tu-berlin dot de
2006-05-07 2:56 ` [Bug c++/27464] " pinskia at gcc dot gnu dot org
0 siblings, 1 reply; 2+ messages in thread
From: thor at math dot tu-berlin dot de @ 2006-05-06 22:14 UTC (permalink / raw)
To: gcc-bugs
Enter the following program and compile with -Wall -fstrict-aliasing
int main(int argc,char **argv)
{
float f = 0.5;
return reinterpret_cast<int &>(f);
}
g++ will return the following warning message:
warning: dereferencing type-punned pointer will break strict-aliasing rules
However, this warning message is confusing at best since no pointer handling
is involved here. And then, this program cannot exhibit pointer-aliasing
breakage since the variable "f" and the return code cannot interpret the same
variable as two different types - the re-interpretation of the floating point
value as integer-bit pattern is copied before any aliasing problems could
possibly enter the scene.
Interestingly, g++ explicitly allows the re-interpretation of bit patterns of a
specific type thru the "union trick", i.e.
union {
float i;
int o;
} u;
then assigning the input value to u.i and reading the bit-pattern back from
u.o.
However, the former "reinterpret_cast" is only implementation-defined (as the
implementation defines the bit-pattern transition from float and its re-inter-
pretation as int) whereas the latter "union cast" is undefined behaivour:
A compiler is free to re-organize the access patterns by moving the assignment
to u.i *behind* the read-back from u.o. Thus, the first method is clearly
preferable when this kind of type-reinterpretation is apropriate at all, and
thus should be allowed to pass without a warning. The latter is only defined
because g++ took the freedom to allow it and to avoid the instruction
re-ordering.
--
Summary: unsuitable aliasing rule warning
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thor at math dot tu-berlin dot de
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27464
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug c++/27464] unsuitable aliasing rule warning
2006-05-06 22:14 [Bug c++/27464] New: unsuitable aliasing rule warning thor at math dot tu-berlin dot de
@ 2006-05-07 2:56 ` pinskia at gcc dot gnu dot org
0 siblings, 0 replies; 2+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-05-07 2:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-07 02:56 -------
You are wrong that pointers is not involved. References are really just
pointers.
And it is not implemention defined as it still violates C++ aliasing rules.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27464
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-05-07 2:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-06 22:14 [Bug c++/27464] New: unsuitable aliasing rule warning thor at math dot tu-berlin dot de
2006-05-07 2:56 ` [Bug c++/27464] " pinskia at gcc dot gnu dot org
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).