From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 712362BF06 for ; Wed, 10 Oct 2018 10:26:14 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxkdOSt7pOY4 for ; Wed, 10 Oct 2018 10:26:14 -0400 (EDT) Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 2F4B02BEFF for ; Wed, 10 Oct 2018 10:26:14 -0400 (EDT) Date: Wed, 10 Oct 2018 17:26:11 +0300 From: Alexander Turenko Subject: [tarantool-patches] Re: [PATCH 1/3] Fix: prevent guard-breaker optimization Message-ID: <20181010142610.m7aojo6ro5cuvpqq@tkn_work_nb> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: AKhatskevich Cc: georgy@tarantool.org, tarantool-patches@freelists.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 > >