From: Alexander Turenko <alexander.turenko@tarantool.org> To: AKhatskevich <avkhatskevich@tarantool.org> Cc: georgy@tarantool.org, tarantool-patches@freelists.org Subject: [tarantool-patches] Re: [PATCH 1/3] Fix: prevent guard-breaker optimization Date: Wed, 10 Oct 2018 17:26:11 +0300 [thread overview] Message-ID: <20181010142610.m7aojo6ro5cuvpqq@tkn_work_nb> (raw) In-Reply-To: <ee81c4f7e457319226c9ed5f9ac9f926e8d617ef.1533726342.git.avkhatskevich@tarantool.org> On Wed, Aug 08, 2018 at 02:10:01PM +0300, AKhatskevich wrote: > In case of very aggressive optimizations the compiler can > optimize guard-breaker function away and the `unit/guard` > test would fail. I think it is good to mention the specific compiler options (and a certain compiler you are using to reproduce it) to give a user an idea when things are going wrong and so what is the fix does. Is it due to discarding the noinline attribute in case of LTO on gcc? So 'volatile' prevents inlining the function? I just guessing here, but I think the commit message should clarify such things if possible. > --- > test/unit/guard.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/test/unit/guard.cc b/test/unit/guard.cc > index 231b44c7d..2082dfd48 100644 > --- a/test/unit/guard.cc > +++ b/test/unit/guard.cc > @@ -13,7 +13,7 @@ static int __attribute__((noinline)) > stack_break_f(char *ptr) > { > char block[2048]; > - char sum = 0; > + volatile char sum = 0; I think a reason of using 'volatile' keyword should be always properly commented in the code, because it always fix some unobvious compiler behaviour. > memset(block, 0xff, 2048); > sum += block[block[4]]; > ptrdiff_t stack_diff = ptr > block ? ptr - block : block - ptr; > -- > 2.14.1 > >
next prev parent reply other threads:[~2018-10-10 14:26 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-08 11:10 [tarantool-patches] [PATCH 0/3] LTO && travis AKhatskevich 2018-08-08 11:10 ` [tarantool-patches] [PATCH 1/3] Fix: prevent guard-breaker optimization AKhatskevich 2018-10-10 14:26 ` Alexander Turenko [this message] 2018-10-11 16:02 ` [tarantool-patches] " Alex Khatskevich 2018-08-08 11:10 ` [tarantool-patches] [PATCH 2/3] Add LTO support AKhatskevich 2018-10-10 14:29 ` [tarantool-patches] " Alexander Turenko 2018-10-11 16:01 ` Alex Khatskevich 2018-08-08 11:10 ` [tarantool-patches] [PATCH 3/3] Add LTO testing && refactor travis.yml AKhatskevich 2018-10-10 14:43 ` [tarantool-patches] " Alexander Turenko 2018-10-11 16:12 ` [tarantool-patches] [PATCH] Enable 0069 policy AKhatskevich 2018-10-11 16:14 ` [tarantool-patches] [tarantool-small] " AKhatskevich 2018-10-11 16:15 ` [tarantool-patches] [tarantool-libyaml] " AKhatskevich 2018-10-11 16:18 ` [tarantool-patches] [tarantool-msgpuck] " AKhatskevich
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=20181010142610.m7aojo6ro5cuvpqq@tkn_work_nb \ --to=alexander.turenko@tarantool.org \ --cc=avkhatskevich@tarantool.org \ --cc=georgy@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH 1/3] Fix: prevent guard-breaker optimization' \ /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