From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id D9dYGW01WmpFwQ4AWB0awg (envelope-from ) for ; Fri, 17 Jul 2026 10:00:13 -0400 Received: by simark.ca (Postfix, from userid 112) id 436411E033; Fri, 17 Jul 2026 10:00:13 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 2EB371E033 for ; Fri, 17 Jul 2026 10:00:12 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B0A6C4BA2E3D for ; Fri, 17 Jul 2026 14:00:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B0A6C4BA2E3D Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id 053244BA2E0C for ; Fri, 17 Jul 2026 13:59:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 053244BA2E0C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 053244BA2E0C Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784296785; cv=none; b=NE458S8k7Ui3GO0w1sQt3uwc9XbmO+0Mtu7ltrLjTP0tdnKQKu2+4nP0QStEsUQD/doXiK7s9W1bHGyZVxqDfTtlHgD358XdvwTFze8SAxAZ0scq9xowSgfWy0BQcQgd6YF1t0GEAswxZlfXgQFaL2qbIkraseTHDoGZNzrFZW0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784296785; c=relaxed/simple; bh=zgnwwl2j0SRNWVxLBgo7SB/SNUoSJMM0Rbx+cTWfjic=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=KtEcnw5SnY2I4EYJg76RfGIhPsDTNQz4Dv1T63IYGiUDDB28780QycTsJFEI9L1a2bUny+t2drSfUxNhrxROIWyZnfyNpdE15S+FrBQTg2BoGKC81EPMg0mrbELhOtdyLO09sK6b6DSURk52bgZV2OhB5fB0DbXfPkHClE8K9GQ= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 053244BA2E0C Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49548e01d02so4060455e9.0 for ; Fri, 17 Jul 2026 06:59:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784296784; x=1784901584; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=WD0MlIa+rgxD6vzvERxCUZVMIiO0mhx8ubvTVdpH2LM=; b=WckupDtID6cuvMUS4hdMuRTzZ/Bn2ntbXdbSXrQeMvP3toaH5JuAykw5Q52ubGMqdO 2GPAO8GkGmDxwlpctxYWXFetajjtRNT9dTmCHnuPGrjPLlZ7VoWv8qz2y0rrpRBKsBxt VzaXwWgEkVT7qcL/lIZjX4LrIV8RVNAKYBeZb3DXFmB4Li/ySy7QZmfZEeSCkR0ZZ7/U GA3Mi3BLDzr1Yslt1QulST0x9hVMpsIGZD1aKlZj/a3PRFqvA+3ieqzJB1E94tXj7deH dosUmYVGo8xru0I0IF2oFN6MzYwxnmkOJRBqJQ5P92bzEqs1xuRXZsW3LuQgauuox9+H r8bg== X-Forwarded-Encrypted: i=1; AHgh+RoWF1VRkuSflovxxYe6FEqekwyTVsrVbRY+qF58Nmpq5Y66RScPs6XYY0/W7tGA14K4Y4jzA7L92PYIgA==@sourceware.org X-Gm-Message-State: AOJu0Yy28YxZNbyc4KosCkKSAwJKUZ76oVSySMNhyTCC0Q/LcFSG3eE8 oRg7Y7ZYDQXDBdGe9V9kxRxx7cgNa+onGtGowE7SGzQhkiGwS89P4DDq X-Gm-Gg: AfdE7cls0ISDghtihjkiao5mGg5cy7CIxrXRInjUlEJXOL+20eP3LlslfNJfzqi4Amg q1y2PSJXyP3ivQRqI+VZQ4zbADFWKQgJI7QeCmKmxFBQFyGsAGZUoOmpWBO1V6XLELQfpG6GznU Zw+1cJrLpRF8NxqKtnNaGME9mfp5GrERXzkFJm4bxXGpJmgBvblxyMm4OnQ8K8APS8l/rNO0Fcl BJcmLea+aFaY/+ne7Nf/6Dy450z3PArm9NBM2pJEc1zpiv9r8PgxAlsdeQddZxokF8uF56NsWLD ddfP7TpJ1P6F8j17t8EkCRWObONga2Ggyjl2jMtwbw0eG9b2sSxSfBraBfOsSWHQR+FHgQ+5288 Vjc0wwmK9bM2kVhoNoFdIPossrBOHZjnfOALUnLLMwuvmRUZ4N8LRXtCYMwR0wvLkireyEbUVI8 oFEf7JgWNhjQZh32Dd7m36ZHDG4Yl7FMEcFbbDcPtaLiNC2phBQY2ztAo= X-Received: by 2002:a05:600c:4e92:b0:495:4cb6:71cc with SMTP id 5b1f17b1804b1-4954cb6729cmr18130935e9.5.1784296783318; Fri, 17 Jul 2026 06:59:43 -0700 (PDT) Received: from ?IPV6:2001:8a0:fae3:3700:4cbf:5b0f:68f7:7a14? ([2001:8a0:fae3:3700:4cbf:5b0f:68f7:7a14]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f63e49ce4sm4240319f8f.8.2026.07.17.06.59.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2026 06:59:42 -0700 (PDT) Message-ID: <215cfb6b-c439-4958-aea2-5787bf2da2d6@palves.net> Date: Fri, 17 Jul 2026 14:59:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/4] gdb.base/nodebug.exp: Add long double testing To: Andrew Burgess , gdb-patches@sourceware.org References: <20260714220631.1499846-1-pedro@palves.net> <20260714220631.1499846-2-pedro@palves.net> <87zezqd4cf.fsf@redhat.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <87zezqd4cf.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 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. >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