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).