From 17849cac84f4c9a529d935da81fcd8d38d0e132e Mon Sep 17 00:00:00 2001 From: Kefu Chai Date: Tue, 1 Jan 2019 15:49:05 +0800 Subject: [PATCH] librbd: workaround an ICE of GCC GCC is somehow annoyed at seeing the combination of decltype and initializer_list in this place. i tried to remove the `if` clause, and only left the `else` block, GCC was happy with that change. i also tried to pass an empty `{}` to `decltype(reply.lockers)`, and GCC was also happy with that. so i guess there are multiple factors taking effect in this problem. probably any of them could be the last straw that breaks GCC. but we cannot have a minimal reproducer for this issue here without more efforts. and `reply.lockers` is empty after `reply` is constructed, so it would be simpler if we just add the locker info to it instead of assigning a newly constructed `map` to it. Fixes: http://tracker.ceph.com/issues/37719 Signed-off-by: Kefu Chai --- src/test/librbd/managed_lock/test_mock_GetLockerRequest.cc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/test/librbd/managed_lock/test_mock_GetLockerRequest.cc b/src/test/librbd/managed_lock/test_mock_GetLockerRequest.cc index 627de21cd8f..69e987e4d09 100644 --- a/src/test/librbd/managed_lock/test_mock_GetLockerRequest.cc +++ b/src/test/librbd/managed_lock/test_mock_GetLockerRequest.cc @@ -62,9 +62,9 @@ public: cls_lock_get_info_reply reply; if (r != -ENOENT) { - reply.lockers = decltype(reply.lockers){ - {rados::cls::lock::locker_id_t(entity, locker_cookie), - rados::cls::lock::locker_info_t(utime_t(), entity_addr, "")}}; + reply.lockers.emplace( + rados::cls::lock::locker_id_t(entity, locker_cookie), + rados::cls::lock::locker_info_t(utime_t(), entity_addr, "")); reply.tag = lock_tag; reply.lock_type = lock_type; } -- 2.39.5