monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] gcc warnings


From: Zack Weinberg
Subject: Re: [Monotone-devel] gcc warnings
Date: Wed, 4 Mar 2009 10:17:10 -0800

On Wed, Mar 4, 2009 at 9:29 AM, Thomas Moschny <address@hidden> wrote:
> commands.cc: In function 'commands::command_id
> commands::complete_command(const args_vector&)':
> commands.cc:427: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> commands.cc:437: warning: dereferencing type-punned pointer will break
> strict-aliasing rules

These are another manifestation of the same false positive that causes
a flood of warnings with 4.2.1: CMD_REF() contains a cast to
commands::command * from a pointer to a type that is always a subclass
of commands::command...  I guess we really should clean that up, but I
don't have time to do it in the next few weeks.

> hybrid_map.hh: In member function 'virtual void
> commands::cmd_revert::exec(app_state&, const commands::command_id&,
> const args_vector&) const':
> hybrid_map.hh:167: warning: dereferencing pointer '<anonymous>' does
> break strict-aliasing rules
> hybrid_map.hh:167: note: initialized from here

Well, this gets an Unhelpful Diagnostics award -- you have to figure
out for yourself that the code it doesn't like is actually in
hybrid_map<K,V>::const_iterator::operator== and has been inlined into
cmd_revert::exec.  And then it makes no sense anyway; I don't see any
dirty pointer tricks in hybrid_map.hh...

> migrate_ancestry.cc: In member function
> 'void<unnamed>::anc_graph::fixup_node_identities(const
> parent_roster_map&, roster_t&, const legacy::rename
> migrate_ancestry.cc:553: warning: dereferencing pointer '<anonymous>'
> does break strict-aliasing rules
> /usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_tree.h:259:
> note: initialized from here

... hm. There _is_ cast trickery on line 259 of bits/stl_tree.h.
Which suggests a bug either in the compiler or in libstdc++, as the
ultimate cause of both this and the hybrid_map problem (line 167 of
hybrid_map.hh ends up calling std::map::const_iterator::operator->).
I don't have gcc4.4 to hand, but do you get the same diagnostic with
this test case?

#include <map>
typedef std::map<unsigned int, unsigned long> M;

bool test(M m, unsigned int k, unsigned long v)
{
  M::const_iterator i = m.find(k);
  if (i == m.end()) return false;
  return (i->second == v);
}

zw




reply via email to

[Prev in Thread] Current Thread [Next in Thread]