Tarantool development patches archive
 help / color / mirror / Atom feed
From: Aleksandr Lyapunov <alyapunov@tarantool.org>
To: Artem Starshov <artemreyt@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: Sat, 21 Nov 2020 14:29:12 +0300	[thread overview]
Message-ID: <25943aa1-3cb1-0a89-8099-b56c332ff04d@tarantool.org> (raw)
In-Reply-To: <848eefec50be4135d9ae3a50f3816d7e334fbc02.1605828734.git.artemreyt@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()

  reply	other threads:[~2020-11-21 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 [this message]
2020-11-25 11:29     ` Artem

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=25943aa1-3cb1-0a89-8099-b56c332ff04d@tarantool.org \
    --to=alyapunov@tarantool.org \
    --cc=alexander.turenko@tarantool.org \
    --cc=artemreyt@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