From: Artem <artemreyt@tarantool.org>
To: Aleksandr Lyapunov <alyapunov@tarantool.org>,
Alexander Turenko <alexander.turenko@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH 2/2] bitset: fix GCC 10 build
Date: Wed, 25 Nov 2020 14:29:29 +0300 [thread overview]
Message-ID: <9a4cdffe-9746-e050-6d6f-570c21e27616@tarantool.org> (raw)
In-Reply-To: <25943aa1-3cb1-0a89-8099-b56c332ff04d@tarantool.org>
[-- Attachment #1: Type: text/plain, Size: 4582 bytes --]
Hi, thanks for review!
See my 2 comments below.
Branch:
https://github.com/tarantool/tarantool/tree/artemreyt/gh-4966-gcc10-warns
Issue: https://github.com/tarantool/tarantool/issues/4966
21.11.2020 14:29, Aleksandr Lyapunov пишет:
> 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.
1. They may be not correct pages in a tree, but in this function
(tt_bitset_set) it doesn't matter
for displayed warning.
The most important thing - is it enough memory was allocated for
returned page AFTER
(uint8_t *) page + sizeof(tt_bitset_page). I will add a definition of
tt_bitset_page for visibility:
struct tt_bitset_page {
size_t first_pos; rb_node(struct tt_bitset_page)node; size_t cardinality; uint8_t data[0]; };
This is not trivial problem. I made a new ticket for this:
https://github.com/tarantool/tarantool/issues/5564
> 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
>
2. I agree with that, so i switched off the check only for bitset.c
referred to the created ticket:
diff --git a/src/lib/bitset/CMakeLists.txt b/src/lib/bitset/CMakeLists.txt
index 1339a02ef..0aba49a47 100644
--- a/src/lib/bitset/CMakeLists.txt
+++ b/src/lib/bitset/CMakeLists.txt
@@ -6,6 +6,11 @@ set(lib_sources
index.c
)
+if (CMAKE_COMPILER_IS_GNUCC AND CMAKE_C_COMPILER_VERSION
VERSION_GREATER_EQUAL 10)
+ # gh-5564: bitset: writing 1 byte into a region of size 0 (gcc 10)
+ set_source_files_properties(${CMAKE_CURRENT_SOURCE_DIR}/bitset.c
+ PROPERTIES COMPILE_OPTIONS -Wno-stringop-overflow)
+endif()
set_source_files_compile_flags(${lib_sources})
add_library(bitset STATIC ${lib_sources})
target_link_libraries(bitset bit)
> 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()
[-- Attachment #2: Type: text/html, Size: 8139 bytes --]
prev parent reply other threads:[~2020-11-25 11:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 2:23 [Tarantool-patches] [PATCH 0/2] GCC 10 warnings Artem Starshov
2020-11-20 2:23 ` [Tarantool-patches] [PATCH 1/2] sql: fix build with GCC 10 Artem Starshov
[not found] ` <20201123231440.GA17397@tarantool.org>
2020-11-25 9:25 ` Artem
2020-11-25 9:52 ` Artem
2020-11-25 11:30 ` Nikita Pettik
2020-11-20 2:23 ` [Tarantool-patches] [PATCH 2/2] bitset: fix GCC 10 build Artem Starshov
2020-11-21 11:29 ` Aleksandr Lyapunov
2020-11-25 11:29 ` Artem [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a4cdffe-9746-e050-6d6f-570c21e27616@tarantool.org \
--to=artemreyt@tarantool.org \
--cc=alexander.turenko@tarantool.org \
--cc=alyapunov@tarantool.org \
--cc=tarantool-patches@dev.tarantool.org \
--subject='Re: [Tarantool-patches] [PATCH 2/2] bitset: fix GCC 10 build' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox