[Bug c++/38477] New: [strict-aliasing] warning message contains compiler-generated symbols

[Bug c++/38477] New: [strict-aliasing] warning message contains compiler-generated symbols

[dimhen at gmail dot com]

[root@localhost gcc_err]# g++ -Wall -c -O3 test.cpp
test.cpp: In member function 'void
test::bar(std::_List_iterator<KeyPairPtr<int, int> >&)':
test.cpp:14: warning: dereferencing pointer '__x.13' does break
strict-aliasing rules
/usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530:
note: initialized from here
test.cpp:14: warning: dereferencing pointer '__x.13' does break
strict-aliasing rules
/usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530:
note: initialized from here

[root@localhost gcc_err]# g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ :
(reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20081210 (experimental) [trunk revision 142645] (GCC)

[root@localhost gcc_err]# uname -a
Linux localhost.localdomain 2.6.26.6-49.fc8 #1 SMP Fri Oct 17 15:59:36
EDT 2008 i686 i686 i386 GNU/Linux

[root@localhost gcc_err]# cat test.cpp
#include <set>
#include <list>

template<class Key, class Info>
class KeyPairPtr
{
public:
   typedef typename std::pair< const Key, Info > Pair;
   Pair *pair_ptr;
};

template<class Key, class Info>
bool operator <( const KeyPairPtr<Key, Info> &left, const
KeyPairPtr<Key, Info> &right ) {
   return left.pair_ptr < right.pair_ptr;
}

typedef KeyPairPtr<int,int> key_val;

class test
{
   test();
   void bar( std::list<key_val>::iterator &ci );

   std::set<key_val> foo;
};

void test::bar( std::list<key_val>::iterator &ci )
{
   test ctx;
   ctx.foo.insert( *ci );
}


-- 
           Summary: [strict-aliasing] warning message contains compiler-
                    generated symbols
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dimhen at gmail 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=38477

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-12-10 17:37 -------
Note that the reason the diagnostic happens is either a bug in libstdc++ or
the points-to solver or the TBAA pruning in the points-to solver.

In the end we access the object 'ctx' via a pointer of type
const struct _Rb_tree_node *.  So the question is if anywhere in 'ctx' there
is such a struct.

It seems to access the _M_t._M_impl._M_header field which is a
_Rb_tree_node_base
but I cannot see a _Rb_tree_node object in it.  Instead _Rb_tree_node is
derived
from _Rb_tree_node_base and adds a _M_value_field.  But accessing this via
this path in

        struct _Rb_tree_impl : public _Node_allocator
        {
          _Key_compare          _M_key_compare;
          _Rb_tree_node_base    _M_header;
          size_type             _M_node_count;

certainly violates aliasing rules.  I do not see what _Rb_tree_impl::_S_value
wants to access.  There seems to be nothing there?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++
           Keywords|                            |diagnostic


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2008-12-10 17:44 -------
The relevant path through the CFG is

  struct test ctx;

<bb 2>:
  # ctx_108 = VDEF <ctx_103(D)>
  # SMT.120_109 = VDEF <SMT.120_104(D)>
  # SMT.121_110 = VDEF <SMT.121_105(D)>
  # SMT.122_111 = VDEF <SMT.122_106(D)>
  # SMT.123_112 = VDEF <SMT.123_107(D)>
  __comp_ctor  (&ctx);
  # VUSE <SMT.121_110>
  D.10437_5 = ci_1(D)->_M_node;
  D.10438_6 = (struct _List_node *) D.10437_5;
  # VUSE <ctx_108>
  D.10494_9 = ctx.foo._M_t._M_impl._M_header._M_parent;
  __y_10 = (struct _Rb_tree_node *) D.10494_9;
  __y_12 = (struct _Rb_tree_node *) &ctx.foo._M_t._M_impl._M_header;
...

<bb 7>:
  # __y_21 = PHI <__y_56(6), __y_12(2)>
...

<bb 21>:
  D.10504_36 = &__y_21->D.9518;
...

...
<bb 23>:
  __x.13_77 = (const struct _Rb_tree_node *) D.10504_36;
  # VUSE <SMT.123_100>
  D.11044_78 = D.10438_6->_M_data.pair_ptr;
  # VUSE <SMT.122_96>
  D.11045_79 = __x.13_77->_M_value_field.pair_ptr;


(it's not clear to me what &__y_21->D.9518 accesses - this seems to be a
magic, anonymous thing.  The constraints tell me its at offset zero though.)


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[paolo dot carlini at oracle dot com]

------- Comment #3 from paolo dot carlini at oracle dot com  2008-12-12 11:10 -------
Can you explain in better detail which aliasing issues you are seeing in
_Rb_tree_impl (per Comment #1)? At line 530 I cannot see anything obviously
wrong: a pointer to the base is casted to the derived type (just a static cast)
and then _M_value_field of the latter is accessed.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo at gcc dot gnu dot
                   |                            |org, rguenth at gcc dot gnu
                   |                            |dot org


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2008-12-12 11:24 -------
The access is
  ((const struct _Rb_tree_node *)
     &ctx.foo._M_t._M_impl._M_header.D.9518)->_M_value_field.pair_ptr

but _M_header is of type _Rb_tree_node_base (and is embedded in _M_impl).
 _Rb_tree_node_base does not have a _M_value_field member, so I do not see
that the memory that is accessed is really "there".  This "D.9518" thing
may somehow magically cover for it (but it's at offset zero of _M_header),
but certainly TBAA isn't aware that this is a legal access.

Of course I lack complete understanding of how the implementation details
of the rb tree are supposed to work.  So, if this is not a libstdc++
problem then it is a C++ FE problem.


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[paolo dot carlini at oracle dot com]

------- Comment #5 from paolo dot carlini at oracle dot com  2008-12-12 11:39 -------
Sorry, but I still do not understand: __x (a const _Rb_tree_node_base *) is
casted to _Const_Link_type (a const _Rb_tree_node<_Val> *) before the access,
then of course an _M_value_field esists. By the way, all these cast games are
very, very old (I hope we are not uncovering one more aliasing issue in the
HP/SGI code)...


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2008-12-12 11:44 -------
But there is no space for _Rb_tree_node<_Val> in ctx.foo._M_t._M_impl.

        struct _Rb_tree_impl : public _Node_allocator
        {
          _Key_compare          _M_key_compare;
          _Rb_tree_node_base    _M_header;
          size_type             _M_node_count;

the _M_header member is of type _Rb_tree_node_base, so I don't see how you
can cast that to _Rb_tree_node<_Val> and expect the _M_value_field to magically
appear in memory.  At least this is what the alias analysis code complains
about and thus says this access accesses nothing (legally).

Now you can of course tell me that .D.9518 makes the difference, but this
difference is not communicated to the middle-end properly by the C++
frontend.


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2008-12-12 11:53 -------
(In reply to comment #6)
> But there is no space for _Rb_tree_node<_Val> in ctx.foo._M_t._M_impl.
> 
>         struct _Rb_tree_impl : public _Node_allocator
>         {
>           _Key_compare          _M_key_compare;
>           _Rb_tree_node_base    _M_header;
>           size_type             _M_node_count;

This has nothing to do with the allocated nodes.

> 
> the _M_header member is of type _Rb_tree_node_base, so I don't see how you
> can cast that to _Rb_tree_node<_Val> and expect the _M_value_field to magically
> appear in memory.

Hey Richard, don't tell me it's the first time you see production code casting
a pointer from base to derived and accessing a member existing only in the
derived type. Indeed, the HP / SGI STL people did that, not the worse
programmers in the world ;) Anyway, if you think this is something wrong from
the aliasing specifications point of view, please point me to the relevant
sections of the Standard, let's work this out, is going to be painful and
risky, I'm afraid...


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2008-12-12 11:56 -------
Heh, of course not - I have been doing this myself gazillions of times.  I am
just looking at this from the middle-end perspective where the middle-end
appears to see an _object_ ctx with a specific member layout.  If you then
access this with a different layout then you are doomed.

I have to dig into the trees coming from the FE in this case, but now I'm
leaving
for a 2+ week vacation w/o internet access, so ... this has to wait.


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2008-12-12 12:09 -------
Btw, if you want to dig yourself - the problem is that the alias set of
const struct _Rb_tree_node is not a subset of struct test.  So the access
of any part of an object of type struct test through a pointer of type
const struct _Rb_tree_node * invokes undefined behavior (from the middle-end
perspective).

See alias.c:record_component_aliases for how the relationship is built.


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[bkoz at gcc dot gnu dot org]

------- Comment #10 from bkoz at gcc dot gnu dot org  2009-01-05 23:47 -------

Hey y'all, if this isn't a libstdc++ issue can it be re-categorized to the gcc
component?


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2009-01-06 19:45 -------
I'm not sure it isn't.


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2009-01-12 14:25 -------
This isn't really a warning from system headers:

test.cpp:14: warning: dereferencing pointer '__x.13' does break strict-aliasing
rules

the location for the dereference is in test.cpp (if that is correct or not
is another issue).  There is at least a bug that we will emit the note: part
even if the warning was suppressed - I am going to fix that.

I can omit the warning for pointers that are declared in system headers
in addition to that.  Probably this is what is the better behavior - but
I cannot easily report the dereference location even if it is in a system
header but the pointer is _not_ from a system header -- which is probably
what would be wanted here.

So,

t.h:
#pragma GCC system_header

inline float deref_float (float *p) { return *p; }

t.C:
#include "t.h"

float transform(int i)
{
  return deref_float ((float *)&i);
}

_should_ emit a warning?  Even if it looks like

t.h: In function 'float transform(int)':
t.h:3: warning:  dereferencing pointer 'i.0' does break strict-aliasing rules
t.C:5: note: initialized from here

?

IMHO we want to warn unless _both_, the declaration and the dereference is
in a system header.


-- 

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|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-12 14:25:54
               date|                            |


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[pluto at agmk dot net]

------- Comment #13 from pluto at agmk dot net  2009-01-12 14:43 -------
(In reply to comment #12)
> This isn't really a warning from system headers:
> 
> test.cpp:14: warning: dereferencing pointer '__x.13' does break strict-aliasing
> rules
> 
> the location for the dereference is in test.cpp (if that is correct or not
> is another issue).  There is at least a bug that we will emit the note: part
> even if the warning was suppressed - I am going to fix that.
> 
> I can omit the warning for pointers that are declared in system headers
> in addition to that.  Probably this is what is the better behavior - but
> I cannot easily report the dereference location even if it is in a system
> header but the pointer is _not_ from a system header -- which is probably
> what would be wanted here.
> 
> So,
> 
> t.h:
> #pragma GCC system_header
> 
> inline float deref_float (float *p) { return *p; }
> 
> t.C:
> #include "t.h"
> 
> float transform(int i)
> {
>   return deref_float ((float *)&i);
> }
> 
> _should_ emit a warning?  Even if it looks like
> 
> t.h: In function 'float transform(int)':
> t.h:3: warning:  dereferencing pointer 'i.0' does break strict-aliasing rules
> t.C:5: note: initialized from here
> 
> ?
> 
> IMHO we want to warn unless _both_, the declaration and the dereference is
> in a system header.
> 

this will be painfull for users, e.g. boost::optional uses so called
aligned_storage via mistic void*/casts/etc and now i'm getting these
warnings from boost-system-headers. in this way, the -isystem switch
is completely useless.


-- 

pluto at agmk dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pluto at agmk dot net


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2009-01-12 14:51 -------
Ok, how about -Wstrict-aliasing=3 warning only if both the dereference and the
declaration are not from system-headers (this is then the default for -Wall)
and with -Wstrict-aliasing=2 (or =1) warn if either of them is not from
system-headers?


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

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



------- Comment #15 from rguenth at gcc dot gnu dot org  2009-01-13 11:03 -------
Smaller testcase for the possible libstdc++ / C++ FE issue, build with
-O2 -finline-functions -Wstrict-aliasing -Wsystem-headers

#include <set>

class test
{
  test();
  void bar(int ci);

  std::set<int> foo;
};

void test::bar(int ci )
{
  test ctx;
  ctx.foo.insert( ci );
}

/usr/include/c++/4.4/bits/stl_function.h: In member function ‘void
test::bar(int)’:
/usr/include/c++/4.4/bits/stl_function.h:230: warning: dereferencing pointer
‘__x.13’ does break strict-aliasing rules
/usr/include/c++/4.4/bits/stl_tree.h:530: note: initialized from here
/usr/include/c++/4.4/bits/stl_function.h:230: warning: dereferencing pointer
‘__x.13’ does break strict-aliasing rules
/usr/include/c++/4.4/bits/stl_tree.h:530: note: initialized from here

I am now trying to investigate who is at fault.


-- 


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

[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2009-01-13 12:14 -------
There is only a conditional path through the program that violates aliasing
rules,
likely never executed.  We do not detect this fact because of a points-to
solver
issue, PR38826.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |38826


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

[Bug middle-end/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #17 from rguenth at gcc dot gnu dot org  2009-01-14 16:45 -------
Subject: Bug 38477

Author: rguenth
Date: Wed Jan 14 16:45:22 2009
New Revision: 143374

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143374
Log:
2009-01-14  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/38826
        PR middle-end/38477
        * tree-ssa-structalias.c (emit_alias_warning): Emit the pointer
        initialization notes only if we actually emitted a warning.
        (intra_create_variable_infos): Add constraints for a result decl
        that is passed by hidden reference.
        (build_pred_graph): Mark all related variables non-direct on
        address-taking.

        * gcc.dg/Wstrict-aliasing-bogus-pta-1.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-pta-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug middle-end/38477] [strict-aliasing] warning message contains compiler-generated symbols

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2009-01-14 16:47 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.4.0


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