X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org F335A382D83E
Authentication-Results:	sourceware.org;
	dmarc=none (p=none dis=none) header.from=towo.net
Authentication-Results:	sourceware.org; spf=none smtp.mailfrom=towo AT towo DOT net
Subject:	Re: stack grow direction wrongly detected
To:	cygwin AT cygwin DOT com
References:	<6eded5d3-93f3-7c98-5055-ee5ac2566bc8 AT gmail DOT com>
	<20210305233104 DOT 782838da83161a90f56a5369 AT nifty DOT ne DOT jp>
From:	Thomas Wolff <towo AT towo DOT net>
Message-ID:	<7f5794ef-8e98-0caf-b2f2-fb9dd670bfb8@towo.net>
Date:	Fri, 5 Mar 2021 16:25:05 +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:	<20210305233104.782838da83161a90f56a5369@nifty.ne.jp>
X-Provags-ID:	V03:K1:U2lYI2GItALcFDCbM7BTRj/vlwkqgOMMQMCtYyWbMUoakYTWzP9
	nJ5AMsVqnw52eSWn+5nZvKjZ15eobagxiaRKWjSXrzTlc3ZE6HzPQnViVoTKcnqB6Dgw3j1
	m7EHXpQ7TuMLXA8uuM7tb7HF6hHBMBrch5elJxs0USlrBJX2iZldj+fAl3k6eaEy3hIvxze
	UXVhwLFCLfnSpvoFxssqw==
X-UI-Out-Filterresults:	notjunk:1;V03:K0:YUyzNiaM5Ww=:+qYk0wYOWD0D/AUbW4FO4m
	YgkAcpckXn/LvW/fMdu454mQvAPDH9XCmlpWPaisAAypjasPtenVecw+L+LedN2ZgAPJ/sDAo
	UBmujZEL5oDX6zA+Ie5AmtU822G6Qb4u3LzCHrYCtuIJjWI4ipWFpNhrjAJTcQ7/7fFioG//T
	/brh5jTvR8DGS18/1ZZ3IUikypzIAmbipAVpHNz0pbC+oIjosGP2Q9SKsP9BVIPjE8TWh5PX8
	ZOx/Tc1SaNcBynwR4/NpDuQq4g1DliBzFzpOgFR//gWeaqz23Y4nl4cu64lE72c6T5xFKaf/P
	pCBxq0OMYshgIWEXCqyUqVXJIbR3acp0WX8fI3BAjztbM1XzZs2x/7am7/JEx6P7k41mW9+Nt
	uZk7x5hmp726TU4ynJh+O9fC0Wo209FfzrLf0B/lfgtdD25WIg4fIhcshudvc
X-Spam-Status:	No, score=-1.0 required=5.0 tests=BAYES_00, KAM_ASCII_DIVIDERS,
	KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE,
	RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE,
	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
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>

Am 05.03.2021 um 15:31 schrieb Takashi Yano via Cygwin:
> On Fri, 5 Mar 2021 13:18:38 +0100
> Marco Atzeri 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)])
> This seems to be a result of optimization. With gcc v10.2.0,
> the return value of the code is:
> -O0: 1
> -O1: 1
> -O2: 0
> -O3: 1
> -O4: 1
>
> If find_stack_direction() is implemented as recursive call,
> and auto variable is allocated in the stack every time,
> in the first call, addr is initialized to the first stack
> position, and in the second call, second address of dummy
> is reduced because stack of x86 is reverse direction.
> Therefore (&dummy > addr) ? 1 : -1; returns -1.
> As a result, the return value find_stack_direction() < 0
> is 1. With -O0 or -O1 this implemented as recursive call,
> so the return value is 1.
>
> So, IIUC, the setting SCM_I_GSC_STACK_GROUS_UP is completly
> oposite.
>
> With the following modified code,
>
> #include <stdio.h>
> int
> find_stack_direction (int n)
> {
>    static char *addr = 0;
>    char dummy;
>    printf("%p\n", &dummy);
>    if (addr == 0)
>      addr = &dummy;
>    if (n)
>      return find_stack_direction (n - 1);
>    else
>      return (&dummy > addr) ? 1 : -1;
> }
>
> int
> main ()
> {
>    int ret = find_stack_direction (10) < 0;
>    printf("%d\n", ret);
>    return ret;
> }
>
> the result with -O0 is
> 0x62cc2f
> 0x62cbff
> 0x62cbcf
> 0x62cb9f
> 0x62cb6f
> 0x62cb3f
> 0x62cb0f
> 0x62cadf
> 0x62caaf
> 0x62ca7f
> 0x62ca4f
> 1
>
> This looks very reasonable. However, with -O2
> 0x62cc3d
> 0x62cc3e
> 0x62cc3f
> 0x62cc0d
> 0x62cc0e
> 0x62cc0f
> 0x62cbdd
> 0x62cbde
> 0x62cbdf
> 0x62cbad
> 0x62cbae
> 1
>
> This is very strange. The address is not decreased uniformly.
>
> Therefore, using -O0 and setting SCM_I_GSC_STACK_GROUS_UP
> reversely is the right thing, I think.
>
The function calls for tail recursion optimization, so it's not really 
suitable to make observations on recursion.
However, with real tail recursion easily performed, the address of the 
local variable should actually not change at all, unlike here. The 
reason for that is beyond me.
--
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

- Raw text -