X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2FEA6386101E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1614976195; bh=H8LTCLNjnl71itCmoCtotQ515Ki2vdOjgih6nRRLoG0=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=TfS4Qn43hzVibon3+Jeh4ENqlTfjUW2yiPdkZS+kouxWHkAvp/vpRsl1hp+l8FZv7 Xkx9A+pc+01LfbDv1kVTF5huUGeXfA+qBD4JuheqicG+qkGiNKpPJmlKGweM5Cji2d Khoh5YxcDSYTrzt88MiLJvpivABiI9t+21MV47qU= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1F1A63857C66 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ujaSNryx7NfKOq9gNfFEjFVoNOwkJgt5J4RAaCMt7Es=; b=QyOHi6uAnfgZV4x4wIFUy/3q5Qhi5qFWy14RS7A9xYHSPgow35OTXkYSzKBbDyRvZ+ Nz819Uhr/wvurDKO3JDI3LBE3SfCbXbO71hTfBTycYfeRUZKB0xZXn6gWbZ1V6eWXlEG WYyqw76bG+1Dr4Fhlwjrv4EniDixEBTxrPZjhbr7q8atNGfZ9diqynNLT5H5POS9k0Q/ cw80q/1OVyv4C1Tadg+tfaNxwWobA8icOCyozy1EvD3HYyEtEVqcgTBRRohNb1c+eSxs aI7N1KtdxW1G884eW+IuN1r6TRnVYDhcWDOgTiANQJs5hqcWxelTv2MEU1WNhBxHYTbo JT+Q== X-Gm-Message-State: AOAM5316ifvQa41FThXbvzHHrGQHqAx8O/I5xdC2KGQixxO9wK+zlbLE 3iXeZXhNZL0vS0H7HM9NDRJn/XU3zey08A== X-Google-Smtp-Source: ABdhPJxZiekCKGZKUi5ht2xCDU9P3tfR6UM4cInFifPxTYpoWZPsJxd+v2MjEydTDc7I2n/P3f40KQ== X-Received: by 2002:a17:906:1bf2:: with SMTP id t18mr4119082ejg.418.1614976191246; Fri, 05 Mar 2021 12:29:51 -0800 (PST) Subject: Re: stack grow direction wrongly detected To: cygwin AT cygwin DOT com References: <6eded5d3-93f3-7c98-5055-ee5ac2566bc8 AT gmail DOT com> Message-ID: Date: Fri, 5 Mar 2021 21:29:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: it X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_ASCII_DIVIDERS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Marco Atzeri via Cygwin Reply-To: Marco Atzeri Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: cygwin-bounces AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 125KTwCv016445 On 05.03.2021 19:58, Brian Inglis wrote: > On 2021-03-05 05:18, Marco Atzeri via Cygwin wrote: >> Hi Guys, >> noted trying to rebuild guile 1.8.8. >> >> The following piece of code in the past >> was setting SCM_I_GSC_STACK_GROWS_UP=0 >> and now produces SCM_I_GSC_STACK_GROWS_UP=1 >> >> I assume some change in the gcc compiler is causing the issue. >> I presume most of the programs and libraries do not care, >> but some special one like guile crashes during build for this issue, >> so be aware. >> >> Regards >> Marco >> >> >> #-------------------------------------------------------------------- >> # >> # Which way does the stack grow? >> # >> # Following code comes from Autoconf 2.61's internal _AC_LIBOBJ_ALLOCA >> # macro (/usr/share/autoconf/autoconf/functions.m4).  Gnulib has >> # very similar code, so in future we could look at using that. >> # >> # An important detail is that the code involves find_stack_direction >> # calling _itself_ - which means that find_stack_direction (or at >> # least the second find_stack_direction() call) cannot be inlined. >> # If the code could be inlined, that might cause the test to give >> # an incorrect answer. >> #-------------------------------------------------------------------- >> >> SCM_I_GSC_STACK_GROWS_UP=0 >> AC_RUN_IFELSE([AC_LANG_SOURCE( >> [AC_INCLUDES_DEFAULT >> int >> find_stack_direction () >> { >>    static char *addr = 0; >>    auto char dummy; >>    if (addr == 0) >>      { >>        addr = &dummy; >>        return find_stack_direction (); >>      } >>    else >>      return (&dummy > addr) ? 1 : -1; >> } >> >> int >> main () >> { >>    return find_stack_direction () < 0; >> }])], >>                 [SCM_I_GSC_STACK_GROWS_UP=1], >>                 [], >>                 [AC_MSG_WARN(Guessing that stack grows down -- see >> scmconfig.h)]) > > Report it upstream to guile and [better] autoconf for correction - > suggest a patch or not as you feel appropriate. > > It's an issue that the code does not assume --push and pop++ as that is > the common implementation -- then do adequate due diligence to inhibit > optimizations that avoid stack usage, eliminate tail recursion, and > generate inline code, to prove the opposite. Some implementations (used > to?) not natively support or use stacks and emulated them with > dynamically allocated memory blocks. > > I am surprised that this has not occurred previously, and wonder if > someone recently replaced, eliminated, or "optimized" code, or some > necessary settings, that allow such autoconf tests to do their jobs > properly. guile 1.8.8 is 10 years old, but it is still used by some programs as all the guile 2.x series were slower. the code on recent guile 3.0.x is different, with no recursion at all. SCM_I_GSC_STACK_GROWS_UP=0 AC_RUN_IFELSE([AC_LANG_SOURCE( [AC_INCLUDES_DEFAULT int find_stack_direction (int *addr, int depth) { int dir, dummy = 0; if (! addr) addr = &dummy; *addr = addr < &dummy ? 1 : addr == &dummy ? 0 : -1; dir = depth ? find_stack_direction (addr, depth - 1) : 0; return dir + dummy; } int main (int argc, char **argv) { return find_stack_direction (0, argc + !argv + 20) < 0; }])], > We all love the advantage such transformations provide our code at large > compile time and space costs, but most are unaware of the effort that > detection code like the above now has to go thru to avoid being rendered > useless. it is always impossible to guess in which direction programming paradigms evolve, due to the large number of elements involved. But testing for functionality remain much more resistent to hard coded solution. Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple