From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xy0oDN97el/2dQAAWB0awg (envelope-from ) for ; Sun, 04 Oct 2020 21:50:23 -0400 Received: by simark.ca (Postfix, from userid 112) id 2488B1EE0F; Sun, 4 Oct 2020 21:50:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 644381E965 for ; Sun, 4 Oct 2020 21:50:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D51323857020; Mon, 5 Oct 2020 01:50:21 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 7BF743857020 for ; Mon, 5 Oct 2020 01:50:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7BF743857020 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2489F1E965; Sun, 4 Oct 2020 21:50:19 -0400 (EDT) Subject: Re: [PATCH v2 1/2] Fix function argument and return value locations To: Hannes Domani , gdb-patches@sourceware.org References: <20200529150800.2013-1-ssbssa.ref@yahoo.de> <20200529150800.2013-1-ssbssa@yahoo.de> From: Simon Marchi Message-ID: Date: Sun, 4 Oct 2020 21:50:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200529150800.2013-1-ssbssa@yahoo.de> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-05-29 11:07 a.m., Hannes Domani via Gdb-patches wrote: > Fixes these testsuite fails on Windows: > FAIL: gdb.base/callfuncs.exp: p t_float_complex_values(fc1, fc2) > FAIL: gdb.base/callfuncs.exp: p t_float_complex_many_args(fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4) > FAIL: gdb.base/callfuncs.exp: noproto: p t_float_complex_values(fc1, fc2) > FAIL: gdb.base/callfuncs.exp: noproto: p t_float_complex_many_args(fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4) > FAIL: gdb.base/call-sc.exp: p/c fun(); call call-sc-tld > FAIL: gdb.base/call-sc.exp: advance to fun for return; return call-sc-tld > FAIL: gdb.base/call-sc.exp: zed L for return; return call-sc-tld > FAIL: gdb.base/call-sc.exp: return foo; return call-sc-tld > FAIL: gdb.base/call-sc.exp: return foo; synchronize pc to main() for 'call-sc-tld' > FAIL: gdb.base/call-sc.exp: return foo; synchronize pc to main() for 'call-sc-tld' > FAIL: gdb.base/call-sc.exp: advance to fun for finish; return call-sc-tld > FAIL: gdb.base/call-sc.exp: zed L for finish; return call-sc-tld > FAIL: gdb.base/call-sc.exp: finish foo; return call-sc-tld (the program is no longer running) > FAIL: gdb.base/call-sc.exp: value foo finished; return call-sc-tld > > For function arguments (callfuncs.exp), only TYPE_CODE_COMPLEX was > missing in the types passed via integer registers. > > For return values, there were a lot more issues: > - TYPE_CODE_DECFLOAT is NOT returned via XMM0. > - long double is NOT returned via XMM0. > - but __int128 IS returned via XMM0. > - the comments for TYPE_CODE_FLT state that __m128, __m128i and __m128d are > returned by XMM0, and this is correct, but it doesn't actually check for > them, because they are TYPE_CODE_ARRAY with TYPE_VECTOR > > So I had to add TYPE_CODE_DECFLOAT to the arguments passed via XMM register, > but I had to remove it from the values returned via XMM0 register. I won't pretend I cross-checked all of this with the ABI documentation, but that looks good to me. If you say the tests now pass, that gives me enough confidence, so please go ahead and merge. Simon