X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 40C133AA7C8F
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1614954692;
	bh=W9ImeGsdc7dLo4hMlq3a7eVOp51srNbGU6BOkk9LGDk=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=pvhDDiV9AeX5zDMUNNtVfVfeKWO3B1H9jlR9xj5/6Ymp1v2pT7HlYjXmE/mQbilBM
	O++w2VUI1QDbRwgdGpO6XBIbLFRmAYZIR4kopz3o+RrC7tEDb9qN1pTkyNjIV7jw2U
	UufAF8tGOsV2taG/WPHb2voGwR4c7sBw7+GPq0+0=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org 5F15439960F0
DKIM-Filter:	OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com 125EV0Vw016601
X-Nifty-SrcIP:	[118.243.85.178]
Date:	Fri, 5 Mar 2021 23:31:04 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: stack grow direction wrongly detected
Message-Id:	<20210305233104.782838da83161a90f56a5369@nifty.ne.jp>
In-Reply-To:	<6eded5d3-93f3-7c98-5055-ee5ac2566bc8@gmail.com>
References:	<6eded5d3-93f3-7c98-5055-ee5ac2566bc8 AT gmail DOT com>
X-Mailer:	Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version:	1.0
X-Spam-Status:	No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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
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>
From:	Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>

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.

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
--
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 -