[Bug c++/64877] strange warning message from -Waddress

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-31
                 CC|                            |paolo.carlini at oracle dot com
            Version|unknown                     |5.0
     Ever confirmed|0                           |1

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #3)
> Oops, had the wrong gcc in $PATH.
> That test case does warn:
> 
> pokyo. g++ -std=c++11 -c -Wall -Waddress -O2 x.cc
> x.cc: In instantiation of ‘S<Derived>::S() [with Derived = T]’:
> x.cc:19:8:   required from here
> x.cc:9:29: warning: the address of ‘void S<Derived>::Unwrap() [with Derived
> = T]’ will never be NULL [-Waddress]
>      if (&S<Derived>::Unwrap != &Derived::Unwrap)
>                              ^
> 
> 
> I think I would expect a warning on the second assert, but not the first.

We hit this code in cp/typeck.c

                /* We generate:

                   (op0.pfn == op1.pfn
                   && (!op0.pfn || op0.delta == op1.delta))

                   The reason for the `!op0.pfn' bit is that a NULL
                   pointer-to-member is any member with a zero PFN; the
                   DELTA field is unspecified.  */

                e1 = cp_build_binary_op (location,
                                         EQ_EXPR, delta0, delta1, complain);
                e2 = cp_build_binary_op (location,
                                         EQ_EXPR,
                                         pfn0,
                                         build_zero_cst (TREE_TYPE (pfn0)),
                                         complain);
                e1 = cp_build_binary_op (location,
                                         TRUTH_ORIF_EXPR, e1, e2, complain);

thus, the !op0.pfn triggers the warning. It may be enough to pass tf_none
instead of complain for the two compiler-generated expressions. Alternatively,
since we know pfn0 cannot be NULL, do not generate this check. It seems quite
wasteful to go through the huge cp_build_binary_op just to build something that
will get optimized out.

Not working on this, but it seems feasible to fix. If it is a regression, you
may even convince someone to approve it for GCC 5.