From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88709 invoked by alias); 5 May 2018 14:36:34 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 88673 invoked by uid 89); 5 May 2018 14:36:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Green, Hx-spam-relays-external:ESMTPA X-HELO: smtp-out-so.shaw.ca Received: from smtp-out-so.shaw.ca (HELO smtp-out-so.shaw.ca) (64.59.136.138) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 05 May 2018 14:36:32 +0000 Received: from kylheku.com ([70.79.163.252]) by shaw.ca with ESMTPA id EyIVfQamDSzNNEyIXfyuwG; Sat, 05 May 2018 08:36:30 -0600 X-Authority-Analysis: v=2.3 cv=KuxjJ1eN c=1 sm=1 tr=0 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=VUJBJC2UJ8kA:10 a=ubArCifLrr_Fzw-dUNIA:9 a=QEXdDO2ut3YA:10 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from <382-725-6798@kylheku.com>) id 1fEyIV-00038Y-Me; Sat, 05 May 2018 07:36:27 -0700 To: Anthony Green Subject: Re: libffi trunk: new regressions on =?UTF-8?Q?x=38=36=5F=36=34-l?= =?UTF-8?Q?inux-gnu=2C=20some=20test=20failures=20left=20on=20i=36=38=36-l?= =?UTF-8?Q?inux-gnu?= X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Sat, 05 May 2018 14:36:00 -0000 From: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Cc: Matthias Klose , libffi-discuss@sourceware.org, "H.J. Lu" In-Reply-To: References: Message-ID: <95c5ed34fcb8394f33e67ac6f65a3cce@mail.kylheku.com> X-Sender: 382-725-6798@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfBnhb2pWszfzPk6K+wpmKSY6/Mmx5qi6ijw4ZQMVU/eivhjpfbysbqlEFgld4ld0VHlxG06hfTbQY0sZBW4RZ6t9USKPbLjofs04M72sQkQMIBQVKa1v uOrl2H0CpAhvG6mDi98DLfUojPxzGZwqEC9jisQ0JPFR2UHdRADqUl7WZWS6hHtYKKsDnbLx1a4VCc55zJOYHhorNZcOB3kRReqkBZa40soiXaUzOlRYDxmz n+wE4+HOWX5XHjyJtEXXJEdpM+MHTSHDlvJWrLFcMmY= X-IsSubscribed: yes X-SW-Source: 2018/txt/msg00030.txt.bz2 On 2018-05-05 06:51, Anthony Green wrote: > These failures are showing up because we're testing the microsoft ABI=20 > now. >=20 > This looks like a bug in GCC. It's not returning small structures with > floating point values in the right registers when following the=20 > Microsoft > ABI. I'm going to figure out how to 'xfail' those tests and open a bug > against GCC. Clang appears to get it right. When would this be an actual issue? What function in what Windows DLL returns a structure with=20 floating-point values, and is that Windows DLL compiled with GCC so that=20 the return representation is wrong? Cygwin code, maybe? It the situation broken, or is it consistent? I mean, can a test case be=20 written for GCC which shows that the structure return is corrupted, when=20 both the caller and callee are compiled with the same GCC and same ABI?=20 Or does the calling code match the return conventions? If things are consistent, then fixing it in GCC requires versioning of=20 some sort. If someone upgrades GCC to the fix and then recompiles only=20 the caller of such a function, or only the callee, the now mismatching=20 call will misbehave. In a distro, if program P depends on library L, usually we can update P=20 independently of L. If the compiler used for P has changed, this is no=20 longer the case; the new P has an ABI change which has to pull in a new=20 L. (At least, if the ABI change is relevant to P-L; who is going to=20 check that for all packages?)