From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jEs3Bw4PYWpmgSYAWB0awg (envelope-from ) for ; Wed, 22 Jul 2026 14:42:22 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ZN+7Q0I3; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0856C1E033; Wed, 22 Jul 2026 14:42:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 194DD1E033 for ; Wed, 22 Jul 2026 14:42:21 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EF3134BA2E1B for ; Wed, 22 Jul 2026 18:42:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EF3134BA2E1B Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ZN+7Q0I3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 114B84BA2E07 for ; Wed, 22 Jul 2026 18:41:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 114B84BA2E07 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 114B84BA2E07 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784745713; cv=none; b=K1W+OcHhduUIoYx+4cbkz6SS27eDaBmefm3Zk1Jzag66shhkrOXurEelR4mZ0/COgyJ8ai2CqUOFREhK2/6tvGbwswYU8/wnKByr5d81JVwRrs+G+wFLJp4nvfONO8Fx2YUwRfE+bpSqGRi5zE5wmjnDA3YPgMjLRVBYR3Wm8Yc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784745713; c=relaxed/simple; bh=rBZAZ/T40r67ugL0gbeS7JR6j/rgmrpXSoirEioDf3s=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=kPqFa0YvlJJ7G62mFFdHKsNH52ZpoaDLfe6gdEfg+OH5a9/DBJe0MT0OssMBKffxRjlq+bc+EyOl+MxZzJDqMnzV/rsgir10Yvu08nqAl9UuOg4cDeNMUIsscInIYxvoR5MK/fYkFfjGEJsAqT1pYWYicf73ckF5YsZr9fUwlnc= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ZN+7Q0I3 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 114B84BA2E07 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784745712; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gQ4utB7s+IMUBAdY4UqDUp0yhzT00uMcjTUGIZ5b3lM=; b=ZN+7Q0I3NZi6l6VVvBaRfnpAzxtdKOIOaiaSvPXRLIlvSkAF2yBu5EFohQbEintKxv2vlG djVAf1vEoXsVv1LFymkPOXvaH9HARKtH6MVz8dlUfflkdKyt4uPWCc2GwrK7lBh3S+L6rK HP3hQ9Qz7t1bpEBWAsoMJVL/lQZKlBI= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-187-NQMppBhJNquIMWzo4nfLyA-1; Wed, 22 Jul 2026 14:41:51 -0400 X-MC-Unique: NQMppBhJNquIMWzo4nfLyA-1 X-Mimecast-MFC-AGG-ID: NQMppBhJNquIMWzo4nfLyA_1784745710 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4955ce558d8so37234755e9.3 for ; Wed, 22 Jul 2026 11:41:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784745710; x=1785350510; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=gQ4utB7s+IMUBAdY4UqDUp0yhzT00uMcjTUGIZ5b3lM=; b=al37ySzJRc4vFjTCPvtAl3W3vmT44LGRvp3Lpq3wrxhG24fVmJlmJYGUXF3Q4TyYj2 aDHLbpiySU94zTL0HCb5n9r5+d2nmNb2YTgXJb8ksy8j65nyPHzdOmNure2NnD5sn7Cy WXTcFdyjpjcGYP+E8JebAUA7F/VqZtXUYEAxtgK+pDrZLxdqBicYSZwf7uL7QqRxx5il BOS0/oAisItgVZl0oVHEIvWAZTibvKVUqC/ofOOLjpyTshpu8JG+m7uUJz5entCdmpMj O3LbddKO+yJBp+r/TffEOCd9y8kzTpXG5BVC/QKUIyTjYxttw7bAtEOUUOT0MVVGmvaw aWpQ== X-Forwarded-Encrypted: i=1; AHgh+RpMStf1PQSMzdb2e1z99yCXQXr3x2LQTF9eXM5S+62owmE1fSvYved6plYRTu+V9xlpK3p9sFwbjvwUjQ==@sourceware.org X-Gm-Message-State: AOJu0YyKyKHWorzw7GaLYySH7V7KT/fNo1iWc7zuYKak6g8PljMkAFj2 kh+/3qkoewy7PZC2v0isgqG+BKfgReUC30e6uOd6l00FnP2hme+TzS45z+JQWv1JSvqLTNByBIp cgFLHojhqQBFvDvcFmx5Zbu2U/TvWMiQqffk7uzgR0ZWN7ipw7/lBBwZ7lGbthpU7TMEE1gQ= X-Gm-Gg: AR+sD12rtepnxLkuCQ5L6Cg5bUgkYeAuIPXokGfNtF95QKp3/tBdMXlF1ZcAG773iIk UId241tIcwAjMh7+HjmiomWbtj8yuiC4IAt82DNTp7rxE5ike1EWwnha8FW9pw7Q5rgv73253vs +NXT+zHOJk5zJAmxU/rQ0NAiRMU3N1cSGTwnBYlYdAP+nEL7TRhhEEUFbvhU2jUOA0Ndy8UJgtk b92n2zSeesQj+3iLR94K9i91/5OSrfFw2hl5O7uL/vDMBIiFBpN0+1iWvRFuf/LkgYwjTrQ39ej IcwauW8khXAv3y4H41aXQAm/V6R5lP2IKgdMXz+xUvjH37ncz15Dh3I8KBm1Gbv3mtERF55gJ3m KTNCfTKgOOmNnJX5k3ro9g24s X-Received: by 2002:a05:600c:4f56:b0:495:4dd3:ca97 with SMTP id 5b1f17b1804b1-4954dd3cb28mr252871715e9.29.1784745710047; Wed, 22 Jul 2026 11:41:50 -0700 (PDT) X-Received: by 2002:a05:600c:4f56:b0:495:4dd3:ca97 with SMTP id 5b1f17b1804b1-4954dd3cb28mr252871435e9.29.1784745709573; Wed, 22 Jul 2026 11:41:49 -0700 (PDT) Received: from localhost (92.40.185.177.threembb.co.uk. [92.40.185.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-495653698bcsm148380815e9.2.2026.07.22.11.41.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jul 2026 11:41:49 -0700 (PDT) From: Andrew Burgess To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH 1/4] gdb.base/nodebug.exp: Add long double testing In-Reply-To: <215cfb6b-c439-4958-aea2-5787bf2da2d6@palves.net> References: <20260714220631.1499846-1-pedro@palves.net> <20260714220631.1499846-2-pedro@palves.net> <87zezqd4cf.fsf@redhat.com> <215cfb6b-c439-4958-aea2-5787bf2da2d6@palves.net> Date: Wed, 22 Jul 2026 19:41:46 +0100 Message-ID: <87bjbyq32t.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -18SICItJ4icTD5AgNP9sGMNfCg8hKU-en2nkLB0X10_1784745710 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Pedro Alves writes: > On 2026-07-16 22:14, Andrew Burgess wrote: >> Pedro Alves writes: > ... > >> Not that it really matters, but the ordering seems a bit weird, the >> existing functions are all: >> >> X >> X_noproto >> Y >> Y_noproto >> etc... >> >> but you broke this pattern. > > Whoops, that was not intentional. I think I misread the pattern earlier. I reordered it now: > > $ grep "^mult" testsuite/gdb.base/nodebug.c > multf (float v1, float v2) > multf_noproto (v1, v2) > mult (double v1, double v2) > mult_noproto (v1, v2) > mult_long_double (long double v1, long double v2) > mult_long_double_noproto (v1, v2) > > Thanks for spotting this. > >> I only mention it because I have some >> actual worthwhile points to raise below... >> >>> + >>> uint8_t >>> add8 (uint8_t v1, uint8_t v2) >>> { >>> diff --git a/gdb/testsuite/gdb.base/nodebug.exp b/gdb/testsuite/gdb.base/nodebug.exp >>> index e4138a801da..1a16e86ed2c 100644 >>> --- a/gdb/testsuite/gdb.base/nodebug.exp >>> +++ b/gdb/testsuite/gdb.base/nodebug.exp >>> @@ -78,6 +78,12 @@ proc test_call_promotion {} { >>> gdb_test "p ((double (*) ()) mult_noproto)(2.0f, 3.0f)" " = 6" >>> gdb_test "p ((double (*) ()) mult_noproto)(2.0, 3.0)" " = 6" >>> >>> + # Same, but for long double. >>> + gdb_test "p (long double) mult_long_double(2.0L, 3.0L)" " = 6" >>> + gdb_test "p ((long double (*) (long double, long double)) mult_long_double)(2.0L, 3.0L)" " = 6" >>> + gdb_test "p ((long double (*) (long double, long double)) mult_long_double)(2, 3)" " = 6" >>> + gdb_test "p ((long double (*) ()) mult_long_double_noproto)(2.0L, 3.0L)" " = 6" >> >> I noticed that the double test also includes a case which tests float to >> double promotion, but that case is skipped here. Wouldn't it be a good >> idea to include both float to long double and double to long double >> tests here too? > > That's because the double test is exercising the standard C default argument > promotion rules, for floating point, which says that for non-prototyped functions, > float is promoted to double. > > So for this float function: > > float > multf_noproto (v1, v2) > float v1, v2; > { > return v1 * v2; > } > > called like so: > > multif_noproto (1.0f, 2.0f); > > this happens: > > 1. Caller promotes 1.0f/2.0f to double, passes the double values. > 2. Callee receives doubles. > 3. Callee's prologue converts to float, because the declared param type is float. > 4. Body uses v1/v2 as float. > > ================================ > > And for the double case: > > double > mult_noproto (v1, v2) > double v1, v2; > { > return v1 * v2; > } > > called like so: > > multi_noproto (1.0f, 2.0f); > > this happens: > > 1. Caller promotes 1.0f/2.0f to double, passes the double values. > 2. Callee receives a double. > 3. Body uses v1/v2 as double. > > ================================ > > The long double case is different. The C default promotion is float->double, NOT float->long double. > > long double > mult_long_double_noproto (v1, v2) > long double v1, v2; > { > return v1 * v2; > } > > mult_long_double_noproto (1.0f, 2.0f); > > so this happens: > > 1. Caller promotes 1.0f/2.0f to double, passes the double values. > 2. Callee receives doubles. > 3. Body uses v1/v2 as long double. (with no conversion! undefined behavior.) > > On ABIs where double and long double are distinct types/sizes, the body sees bogus/corrupt values. > > =============================== > > For the prototyped case, the calls where we pass int, like: > > p ((float (*) (float, float)) multf)(2, 3) > > cover coercion from int to declared type, which is basically testing that gdb does a cast there. > testing float -> double, etc. for the prototyped cases would not add extra coverage, as it'd just > be testing that gdb knows how to cast from float -> double. > > > > I've added some comments to the test to try to make it a little clearer. I also corrected a couple > references to "coercion" to "promotion" to be more accurate. The existing comments are using the terms > interchangeably, but that's not 100% correct. > > Let me know what you think. Sorry, missed this. Thanks for the explanation above. LGTM. Approved-By: Andrew Burgess Thanks, Andrew > > From 3f7db94982bb02473e89199a93dde2d27e06014a Mon Sep 17 00:00:00 2001 > From: Pedro Alves > Date: Tue, 14 Jul 2026 00:34:43 +0100 > Subject: [PATCH] gdb.base/nodebug.exp: Add long double testing > > gdb.base/nodebug.exp is missing testing calling long double functions. > This commit adds such tests. > > With a GDB that doesn't know that "long double" is 64-bit on > x86_64-pc-windows-msvc, we get: > > FAIL: gdb.base/nodebug.exp: p (long double) mult_long_double(2.0L, 3.0L) > FAIL: gdb.base/nodebug.exp: p ((long double (*) (long double, long double)) mult_long_double)(2.0L, 3.0L) > FAIL: gdb.base/nodebug.exp: p ((long double (*) (long double, long double)) mult_long_double)(2, 3) > FAIL: gdb.base/nodebug.exp: p ((long double (*) ()) mult_long_double_noproto)(2.0L, 3.0L) > > Passes cleanly on: > > - x86_64-pc-linux-gnu > - x86_64-w64-mingw32 > - x86_64-pc-windows-msvc, with the "long double" fix > > Change-Id: If9ee749187e1d30fedcba17ae12634f3bd90de2f > --- > gdb/testsuite/gdb.base/nodebug.c | 13 +++++++++++++ > gdb/testsuite/gdb.base/nodebug.exp | 21 ++++++++++++++++----- > 2 files changed, 29 insertions(+), 5 deletions(-) > > diff --git a/gdb/testsuite/gdb.base/nodebug.c b/gdb/testsuite/gdb.base/nodebug.c > index c7bc93991b8..00e854844bf 100644 > --- a/gdb/testsuite/gdb.base/nodebug.c > +++ b/gdb/testsuite/gdb.base/nodebug.c > @@ -79,6 +79,19 @@ mult_noproto (v1, v2) > return v1 * v2; > } > > +long double > +mult_long_double (long double v1, long double v2) > +{ > + return v1 * v2; > +} > + > +long double > +mult_long_double_noproto (v1, v2) > + long double v1, v2; > +{ > + return v1 * v2; > +} > + > uint8_t > add8 (uint8_t v1, uint8_t v2) > { > diff --git a/gdb/testsuite/gdb.base/nodebug.exp b/gdb/testsuite/gdb.base/nodebug.exp > index e4138a801da..7a5ab273bde 100644 > --- a/gdb/testsuite/gdb.base/nodebug.exp > +++ b/gdb/testsuite/gdb.base/nodebug.exp > @@ -51,8 +51,8 @@ proc nodebug_runto {func} { > } > > # Test calling no-debug functions involving argument types that may > -# require coercion/promotion, both prototyped and unprototyped, both > -# return-type-cast style, and function-pointer-cast styles. > +# require coercion or promotion, both prototyped and unprototyped, > +# both return-type-cast style, and function-pointer-cast styles. > proc test_call_promotion {} { > if {[target_info exists gdb,cannot_call_functions]} { > return > @@ -60,14 +60,15 @@ proc test_call_promotion {} { > > # Call prototyped function with float parameters via both > # return-type cast and function-pointer cast. This checks that > - # GDB doesn't do float->double coercion. > + # GDB doesn't do float->double promotion. > gdb_test "p (float) multf(2.0f, 3.0f)" " = 6" > - gdb_test "p ((float (*) (float, float)) multf)(2, 3)" " = 6" > gdb_test "p ((float (*) (float, float)) multf)(2.0f, 3.0f)" " = 6" > + # This tests int->float coercion. > + gdb_test "p ((float (*) (float, float)) multf)(2, 3)" " = 6" > > # Call unprototyped function with float parameters via > # function-pointer cast, only. return-type cast assumes > - # protototyped. Check that GDB does float->double coercion. > + # prototyped. Check that GDB does float->double promotion. > gdb_test "p ((float (*) ()) multf_noproto)(2.0f, 3.0f)" " = 6" > gdb_test "p ((float (*) ()) multf_noproto)(2.0, 3.0)" " = 6" > > @@ -78,6 +79,16 @@ proc test_call_promotion {} { > gdb_test "p ((double (*) ()) mult_noproto)(2.0f, 3.0f)" " = 6" > gdb_test "p ((double (*) ()) mult_noproto)(2.0, 3.0)" " = 6" > > + # Same, but for long double. > + gdb_test "p (long double) mult_long_double(2.0L, 3.0L)" " = 6" > + gdb_test "p ((long double (*) (long double, long double)) mult_long_double)(2.0L, 3.0L)" " = 6" > + gdb_test "p ((long double (*) (long double, long double)) mult_long_double)(2, 3)" " = 6" > + # For unprototyped calls, the standard C default argument > + # promotion (for floating point) applies only to float and > + # promotes to double, so test only with the expected type, using > + # L-suffixed literals to pass long doubles. > + gdb_test "p ((long double (*) ()) mult_long_double_noproto)(2.0L, 3.0L)" " = 6" > + > # Check that GDB promotes char->int correctly. > gdb_test "p /d (uint8) add8((uint8) 2, (uint8) 3)" " = 5" > gdb_test "p /d ((uint8 (*) (uint8, uint8)) add8)((uint8) 2, (uint8) 3)" " = 5" > > base-commit: 490469846dcef89fe53668bdbba73591c64bed61 > -- > 2.54.0