DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 49DK7MeQ3035343
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=pWrGtFk2
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org E5483385694C
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1728850040;
	bh=2Fy1+j0hCbJAEnSptYRetRhtINPGJzX0r64wxu6OFLQ=;
	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=pWrGtFk26B08tVpKK6UQANKRioyWKEpGGamic0UxblRwvurEw6ANy3qdxQTAXzoPs
	uNBZVpgthrn1/g0yLr8A4wDDfMHCvVuxzyFloXqJMx2JBSzuDrbpqMb9Td7oMsjAR3
	e3X/sBOC4tLTTQdE2fnWM1cpL3FtrB3HxbAMbAVE=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 376C0385AE7F
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 376C0385AE7F
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728850017; cv=none;
	b=r1Dd3hdmtBuuSjkpWWP1cxnEU7rcaBnaira6hdz5fcAwkrLCviSbTtHBxI1xWjzCxl1baceUX/WwApCAcag8g8KzGsPrlJPMil6kadYoAYw44MLEqvgynuTNd02F9vEihRm6pdwPCMDpuN1nXK/jGiQnu13Jxd7VcSc35FizOAA=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1728850017; c=relaxed/simple;
	bh=PNbaSpkTNyUoD1HNv+jzn64EZ4lO21kDiREC8nm+o58=;
	h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
	b=TWqAePsxm7q7vb0VkpYL79wkqZCSnTqw/Ap/F/9WnDD6nBeKePhS/nWruc5zlNCejfew/22QitzW3YTB4Cfw7j6WG4wVVH6rMasEbbqwVWsc7I92KqUTTRFrI+TBHdVlcOjrocYK4l35O1xfeDXl3fydLqo8Do+PccpNPVnZ6aU=
ARC-Authentication-Results:	i=1; server2.sourceware.org
Date:	Mon, 14 Oct 2024 05:06:49 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: cygwin 3.5.4-1: signal handling destroys 'long double' values
Message-Id:	<20241014050649.ddaa7e0d14365a86d8523f1d@nifty.ne.jp>
In-Reply-To:	<51e4e5dd-57ef-4cbc-aff4-572eebb863e2@SystematicSW.ab.ca>
References:	<922a6d7e-3ee1-9bb7-dfd7-b94c53a7b9d4 AT t-online DOT de>
	<20241008202057 DOT abd3dc5bb4df172c530e7655 AT nifty DOT ne DOT jp>
	<79171662-eede-4b14-aaf4-ebd98e6d98de AT SystematicSW DOT ab DOT ca>
	<99f51137-2889-4985-b4c6-a460e05befb8 AT SystematicSW DOT ab DOT ca>
	<20241013081407 DOT f07402abe9f721924f461dcc AT nifty DOT ne DOT jp>
	<51e4e5dd-57ef-4cbc-aff4-572eebb863e2 AT SystematicSW DOT ab DOT ca>
X-Mailer:	Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version:	1.0
X-Spam-Status:	No, score=-4.0 required=5.0 tests=BAYES_00, BODY_8BITS,
	DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A,
	RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS,
	TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
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~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 49DK7MeQ3035343

Hi Brian

On Sun, 13 Oct 2024 10:41:58 -0600
Brian Inglis wrote:
> On 2024-10-12 17:14, Takashi Yano via Cygwin wrote:
> > Hi Brian,
> > 
> > On Tue, 8 Oct 2024 10:37:14 -0600
> > Brian Inglis wrote:
> >> On 2024-10-08 10:14, Brian Inglis via Cygwin wrote:
> >>> On 2024-10-08 05:20, Takashi Yano via Cygwin wrote:
> >>>> On Mon, 7 Oct 2024 15:11:52 +0200
> >>>> Christian Franke wrote:
> >>>>> $ gcc -o sigtest -O2 sigtest.c
> >>>>>
> >>>>> $ ./sigtest > out.txt
> >>>>> (press ^C 42x :-)
> >>>>>
> >>>>> $ sort out.txt | uniq -c
> >>>>>          3 x = 0x1.23456789p+0, y = -nan, d = -nan
> >>>>>          6 x = 0x1.23456789p+0, y = 0x1.23456789p+0, d = -nan
> >>>>>         33 x = 0x1.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
> >>>>>
> >>>>> The problem also occurs if compiled without -O2, but less often. No
> >>>>> problem occurs if compiled with -DWORKS which suggests that only 'long
> >>>>> double' is affected.
> >>>>
> >>>> Thanks for the report. I looked into this problem and might find the
> >>>> cause. It seems due to a bug of scripts/gendef. It generates signal
> >>>> handler caller (sigfe.s) which stores/restores the registers.
> >>>>
> >>>> In sigdelayed, control word is stored/restored by fnstcw/fldcw instruction,
> >>>> however, fninit instruction destroys some status registers in FPU (x87).
> >>>>
> >>>> I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and fninit.
> >>>> However, I'm not familiar with x87 instructions, so I may overlook
> >>>> something.
> >>>>
> >>>> Could anyone expert of x87 instructions and sigfe stuff give some
> >>>> comments?
> >>>
> >>> AIUI x87 FP handling is outdated and mainly unused on current systems, as
> >>> current systems do more and use more than the legacy x87 instructions and stack.
> >>>
> >>> See https://en.cppreference.com/w/c/numeric/fenv and related docs for more
> >>> modern approaches.
> >>>
> >>> You would have to look into the AMD/Intel/IEEE docs for lower level details.
> >>
> >> This is basically what ISTR:
> >>
> >> https://beta.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/rationale/x86_and_floating_point_env.html
> >>
> >> where legacy x87 and MMX registers are not used or preserved on x86_64/amd64, as
> >> SSE... instructions and XMM registers are used.
> > 
> > Thanks for the advice. I read throuh the web pages and related documents
> > and made a patch which uses fxsave/fxrstor and xsave/xrstror to
> > cygwin-patches AT cygwin DOT com mailing list.
> > https://cygwin.com/pipermail/cygwin-patches/2024q4/012804.html
> > 
> > Is this as you intended?
> 
> That seems to be the preferred approach now, as long as you can correctly 
> determine adequate space for fxsave and xsave, given the varying feature sets, 
> register counts, and register sizes of recent processors: 
> sse/2/3/4.1/4.2/4a/5/ssse3 avx2/512 128/256/512 bits X/Y/ZMM registers.

Thanks for checking.

According to https://cdrdv2.intel.com/v1/dl/getContent/671110 ,
fxsave uses 512 bytes fixed length memory to save the current
state of the x87 FPU, MMX technology, XMM, and MXCSR registers.

The patch allocates 0x238 bytes:
 0x200 (512 bytes): fxsave area
 0x008 (  8 bytes): for 16-byte alignment
 0x010 ( 16 bytes): work area
 0x020 ( 32 bytes): reserved for later processing

According to https://cdrdv2.intel.com/v1/dl/getContent/671436 ,
cpuid instruction with eax=0dh and ecs=00h returns the maximum
size required by xsave in ebx. So the patch allocates:
ebx + 0x048 bytes.
 0x018 ( 24 bytes): for 64-byte alignment
 0x010 ( 16 bytes): work area
 0x020 ( 32 bytes): reserved for later processing

-- 
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 -