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