[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 --- Comment #2 from Andrew Pinski --- I don't think this is a valid testcase, given: Both KeyId and Value may be non-trivial (non-POD) types provided a suitabe Traits class.
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Andrew Pinski --- You don't provide a hash_traits at all so this is invalid.
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 --- Comment #4 from Andrew Pinski --- *** Bug 92762 has been marked as a duplicate of this bug. ***
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761
Martin Sebor changed:
What|Removed |Added
Keywords||build
Status|RESOLVED|UNCONFIRMED
Resolution|WONTFIX |---
--- Comment #5 from Martin Sebor ---
Andrew, please avoid closing reports of valid problems that you don't
understand.
As I explained in comment #0, the hash_table invokes the assignment operator
directly, without going through the traits class. The hash traits classes also
don't provide an "assign" function, so defining such a class is not a solution.
A test case that includes a traits class is below.
struct S
{
S (): p (&p) { }
S (const S &s): p (&p) { gcc_assert (s.p == &s.p); }
S& operator= (const S &s) {
gcc_assert (p == &p);
gcc_assert (s.p == &s.p);
return *this; }
~S () { gcc_assert (p == &p); }
void *p;
};
typedef int_hash IntHash;
template
void destroy (T &x)
{
x.~T ();
}
template <>
struct simple_hashmap_traits
{
typedef IntHashTraits;
typedef Traits::value_type key_type;
static hashval_t hash (key_type x) { return x; }
static bool equal_keys (key_type x, key_type y) { return x == y; }
template
static void remove (T &x)
{
Traits::remove (x.m_key);
destroy (x.m_value);
}
template
static bool is_empty (const T &x)
{
return Traits::is_empty (x.m_key);
}
template static bool is_deleted (const T &x)
{
return Traits::is_deleted (x.m_key);
}
template static void mark_empty (T &x)
{
Traits::mark_empty (x.m_key);
}
template static void mark_deleted (T &x)
{
Traits::mark_deleted (x.m_key);
}
};
hash_map > x;
static void test_hash_table ()
{
for (int i = 1; i != 32; ++i)
x.put (i, S ());
x.empty ();
}
/* Parse one entire translation unit. */
void
c_parse_file (void)
{
test_hash_table ();
...
}
internal compiler error: in operator=, at cp/parser.c:43419
0xaeedd1 S::operator=(S const&)
/src/gcc/61339/gcc/cp/parser.c:43419
0xaf3bb2 hash_map,
S> >::hash_entry::operator=(hash_map, S> >::hash_entry const&)
/src/gcc/61339/gcc/hash-map.h:42
0xaf3d58 hash_table, S> >::hash_entry, false, xcallocator>::expand()
/src/gcc/61339/gcc/hash-table.h:822
0xaf2259 hash_table, S> >::hash_entry, false, xcallocator>::find_slot_with_hash(int
const&, unsigned int, insert_option)
/src/gcc/61339/gcc/hash-table.h:971
0xaf03b1 hash_map,
S> >::put(int const&, S const&)
/src/gcc/61339/gcc/hash-map.h:165
0xaea3b9 test_hash_table
/src/gcc/61339/gcc/cp/parser.c:43477
0xaea3eb c_parse_file()
/src/gcc/61339/gcc/cp/parser.c:43487
0xcd3645 c_common_parse_file()
/src/gcc/61339/gcc/c-family/c-opts.c:1185
Please submit a full bug report,
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- Only values are being used in the whole of GCC are all PODs. So you are the first one who are using non-PODs. This is now not the right place to complain about an internal data structure working correctly for all of the inputs that are used. If you need to use non-PODs, then you need to patch GCC to do the correct thing instead.
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > Only values are being used in the whole of GCC are all PODs.
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 Martin Sebor changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #8 from Martin Sebor --- Again, leave bugs alone that you don't understand. Quoting from the comment in hash-table.h: INTRODUCTION TO TYPES Users of the hash table generally need to be aware of three types. ... 2. The type used to describe how to handle the value type within the hash table. This descriptor type provides the hash table with several things. - A typedef named 'value_type' to the value type (from above). Provided a suitable Descriptor class it may be a user-defined, non-POD type. There are at least two existing uses of hash-based containers whose elements are non-trivial types. For example in gimple-ssa-isolate-paths.c: typedef hash_map locmap_t; or in attribs.c: typedef hash_set exclusion_set; Regardless, Bugzilla is exactly where change requests are tracked, whether they are to fix bugs or make enhancements.
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-12-03 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #9 from Martin Sebor --- Testing a fix.
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #10 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00180.html
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 --- Comment #11 from Martin Sebor --- Author: msebor Date: Mon Dec 9 20:54:11 2019 New Revision: 279139 URL: https://gcc.gnu.org/viewcvs?rev=279139&root=gcc&view=rev Log: PR middle-end/92761 - hash_table::expand invokes assignment on invalid objects PR middle-end/92762 - hash_table::empty_slow invokes assignment on invalid objects gcc/ChangeLog: PR middle-end/92761 PR middle-end/92762 * hash-map-tests.c (test_map_of_type_with_ctor_and_dtor): Tighten up tests. * hash-table.h (hash_table::expand): Use placement new to copy construct objects in uninitialized storage. (hash_table::empty_slow): Avoid invoking copy assignment on uninitialized objects. Modified: trunk/gcc/ChangeLog trunk/gcc/hash-map-tests.c trunk/gcc/hash-table.h
[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Martin Sebor --- Fixed in 279139. (Though there are outstanding problems with non-trivial types.)
