[Bug c++/38486] New: Missing warning about type punning

[Bug c++/38486] New: Missing warning about type punning

[dominik dot strasser at onespin-solutions dot com]

When compiling the attached source code with -Wall -O3 -UWARN, no warning on
type punning is printed.
If I compile with -Wall -O3 -DWARN, a warning is printed.
ff.C:31: warning: dereferencing type-punned pointer will break strict-aliasing
rules

While in the attached example, everything seems to work fine, my application
crashes.

Would it be feasible to print the warning also for the nested function calls ?


-- 
           Summary: Missing warning about type punning
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominik dot strasser at onespin-solutions dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug c++/38486] Missing warning about type punning

[dominik dot strasser at onespin-solutions dot com]

------- Comment #1 from dominik dot strasser at onespin-solutions dot com  2008-12-11 12:57 -------
Created an attachment (id=16884)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16884&action=view)
Source code which illustrates the problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug middle-end/38486] Missing warning about type punning

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2008-12-11 13:16 -------
The complication is that we "optimize" the code into a form that no longer
violates aliasing rules which effectively disables the warning that happens
after inlining.  IMHO we can issue alias warnings from the code that
propagates (const struct Func &) &D.1753 into *D.1793_4 (tree forwprop) if
and if only the propagation result is a VIEW_CONVERT_EXPR and its base object
does not contain a pointer dereference.  In turn further propagations of
invariant addresses into that VIEW_CONVERT_EXPR may then raise the warning
instead.

Note that this is really a middle-end issue, IMHO the FE based warnings should
be disabled if optimization is enabled as they warn on conversions and not
pointer dereferences thus giving too many false positives anyway.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |middle-end
     Ever Confirmed|0                           |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2008-12-11 13:16:35
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug middle-end/38486] Missing warning about type punning

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-12-12 00:20 -------
This is what I get for trying to get better optimizations in the first place
:).  Maybe we should warn when we do the VCE conversion if the aliasing sets
don't match?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug middle-end/38486] Missing warning about type punning

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2008-12-12 10:11 -------
Yes.  Though you have to be careful not to create false positives for

float f;
struct X { int i; };

struct X *p = (struct X *)&f;
float *q = (float *)&p->i;
return *q;

if the code is obfuscated enough that the definition of p is not visible.
Or, one could even say that creating VIEW_CONVERT_EXPR <float> (p->i) is
an invalid transformation and causes an alias violation.  Do we do this
transformation in this case?  I think we should avoid doing it here
(that is, whenever the expression we view-convert contains a pointer
dereference).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug middle-end/38486] Missing warning about type punning

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2008-12-20 18:53 -------
(In reply to comment #4)
> Yes.  Though you have to be careful not to create false positives for
> 
> float f;
> struct X { int i; };
> 
> struct X *p = (struct X *)&f;
> float *q = (float *)&p->i;
> return *q;

Actually that is an aliasing violation still as you still accessing *p, yes it
looks like it is not an access because of the address but you are still
accessing *p really.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug middle-end/38486] Missing warning about type punning

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2008-12-20 18:58 -------
(In reply to comment #5)
> Actually that is an aliasing violation still as you still accessing *p, yes it
> looks like it is not an access because of the address but you are still
> accessing *p really.

Oh and we do create a VCE for that case already:
  return VIEW_CONVERT_EXPR<int>(a->a);

Yes we thought about this when I was writing the original code which created
the VCE.  If it was just (float*)p, there would be no aliasing violation but
the access happens even if memory is not really accessed.  The address
expression still does not cause no access to happen, this is why doing
(int)(&((struct f*)(0))->a) is still undefined code as there is an access to a
NULL pointer (even if we supported this access).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug middle-end/38486] Missing warning about type punning

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2008-12-29 18:05 -------
Even if I cannot find the proper section of the standard that says &a->b is
not considered an access it does make sense for GIMPLE to do so.  Otherwise
we cannot transform (char *)a + 4 to &a->b because the latter would be a
(possibly invalid) access while the former is not.

So, we definitely should _not_ generate a V_C_E here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug middle-end/38486] Missing warning about type punning

[dominik dot strasser at onespin-solutions dot com]

------- Comment #8 from dominik dot strasser at onespin-solutions dot com  2009-04-27 15:12 -------
Are there any news on this guy here ?
I am really having a hard time porting my project to GCC 4.3 as I have a big
source file which seems to do a lot of type punning, but I get no warnings.
Depending on the compile options I get crashes. Or should I just turn off
strict aliasing for this source file to be on the safe side.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug middle-end/38486] Missing warning about type punning

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2009-04-27 15:18 -------
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-12-11 13:16:35         |2009-04-27 15:18:42
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486

[Bug middle-end/38486] Missing warning about type punning

[rguenth at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]



------- Comment #10 from rguenth at gcc dot gnu dot org  2009-05-20 15:15 -------
Note that I am going to fix the missing warning because of comment #2 only.
For 4.3 comment #2 does not apply, instead you get a warning with
-Wstrict-aliasing=1

g++-4.3 -Wall -O3 -S t.C -UWARN -fdump-tree-all -Wstrict-aliasing=1
t.C: In function ‘Term term(const Func&)’:
t.C:13: warning: dereferencing type-punned pointer might break strict-aliasing
rules
t.C: In function ‘const Func& func(const Term&)’:
t.C:23: warning: dereferencing type-punned pointer might break strict-aliasing
rules


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486