From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp58.i.mail.ru (smtp58.i.mail.ru [217.69.128.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 73AC2469710 for ; Sat, 21 Nov 2020 14:29:14 +0300 (MSK) References: <848eefec50be4135d9ae3a50f3816d7e334fbc02.1605828734.git.artemreyt@tarantool.org> From: Aleksandr Lyapunov Message-ID: <25943aa1-3cb1-0a89-8099-b56c332ff04d@tarantool.org> Date: Sat, 21 Nov 2020 14:29:12 +0300 MIME-Version: 1.0 In-Reply-To: <848eefec50be4135d9ae3a50f3816d7e334fbc02.1605828734.git.artemreyt@tarantool.org> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [Tarantool-patches] [PATCH 2/2] bitset: fix GCC 10 build List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artem Starshov , Alexander Turenko Cc: tarantool-patches@dev.tarantool.org Hi! Thanks for the patch! I have the following thoughts: 1. It's not obvious for me that if a function does not allocate of free memory then it can't have influence on memory access. For example, deletion from tree can break tree structure and returned pages are not correct page anymore. I think we should dig more. 2. I'm sure we should not switch off the check for entire project because of one file. At least we should use smth like set_source_file_properties On 11/20/20 5:23 AM, Artem Starshov wrote: > GCC 10 reports: "warning: writing 1 byte into > a region of size 0 [-Wstringop-overflow=]" > > It's false positive. In order to fix build > i tried to add ignoring gcc -Wstringop-overflow via > preprocessor directive `pragma GCC ignored`. > But it doesn't work, so added -Wnostringop-overflow > flag in complier.cmake for gcc version equal or greather 10. > > > Explaining of false positive: > The problem is: > In file included from /root/ttar/src/lib/bitset/bitset.h:45, > from /root/ttar/src/lib/bitset/bitset.c:32: > In function ‘bit_set’, > inlined from ‘tt_bitset_set’ at /root/ttar/src/lib/bitset/bitset.c:112:14: > /root/ttar/src/lib/bit/bit.h:230:15: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] > 230 | ldata[chunk] |= (1UL << offset); > | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ > > I made a research and found out that if to explicitly init bitset->realloc = realloc > than a warning is still triggers, but if not to call rb_tree functions (tt_bitset_pages_search and > tt_bitset_pages_insert) it's ok. But these functions don't allocate or free a memory, so they can't > influence on memory region which `page` variable points to. > > Part-of #4966 > --- > cmake/compiler.cmake | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/cmake/compiler.cmake b/cmake/compiler.cmake > index db2ae6227..5db636812 100644 > --- a/cmake/compiler.cmake > +++ b/cmake/compiler.cmake > @@ -430,3 +430,17 @@ else() > set(CMAKE_HOST_C_COMPILER ${CMAKE_C_COMPILER}) > set(CMAKE_HOST_CXX_COMPILER ${CMAKE_CXX_COMPILER}) > endif() > + > +if (CMAKE_COMPILER_IS_GNUCC AND CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL 10) > +# In file included from src/lib/bitset/bitset.h:45, > +# from src/lib/bitset/bitset.c:32: > +# In function ‘bit_set’, > +# inlined from ‘tt_bitset_set’ at src/lib/bitset/bitset.c:111:14: > +# src/lib/bit/bit.h:230:15: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] > +# 230 | ldata[chunk] |= (1UL << offset); > +# | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ > +# > +# false positive for gcc version 10 > +# macro 'GCC diagnostic ignored "-Wstringop-overflow"' doesn't help > + add_compile_flags("C" "-Wno-stringop-overflow") > +endif()