From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) by sourceware.org (Postfix) with ESMTPS id 2897E3857806 for ; Wed, 16 Mar 2022 14:33:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2897E3857806 Received: from DB6PR0402CA0024.eurprd04.prod.outlook.com (2603:10a6:4:91::34) by VI1PR0802MB2494.eurprd08.prod.outlook.com (2603:10a6:800:b6::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.26; Wed, 16 Mar 2022 14:33:11 +0000 Received: from DB5EUR03FT028.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:91:cafe::26) by DB6PR0402CA0024.outlook.office365.com (2603:10a6:4:91::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.25 via Frontend Transport; Wed, 16 Mar 2022 14:33:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT028.mail.protection.outlook.com (10.152.20.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.14 via Frontend Transport; Wed, 16 Mar 2022 14:33:11 +0000 Received: ("Tessian outbound 341d209a0e52:v113"); Wed, 16 Mar 2022 14:33:10 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: fe39b8c2618494a6 X-CR-MTA-TID: 64aa7808 Received: from 20cddf066bfd.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id ECBA9A88-BFC0-4742-835E-4BA741ECF888.1; Wed, 16 Mar 2022 14:33:04 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 20cddf066bfd.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 16 Mar 2022 14:33:04 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K1zaQYfb2b5BeEVyaF+RY3orw/Qr5hTZ6KpT3vCH0noTSvspjgXYkAxJ+3YCHs51fApTG2r7lubt3IgsNuv5LUZI84mJlmJQaLfF25L/jjnFyZfklziHfGr2Y9uUrExPTdW9h4YnrRFMfx22ZeR2xsQ1LZ1HuHHTESE8X63UAPatbSFNucG0I19A3m+HCj5zY14Q8PFflBibzQRg9BqT4A96i+oHLSLGOkKIZgyw49/X1ohuwjTNSiKUU6gRameLGlrrtAQew5Qxg8S3HZR1S+eYN0c1T8DcIWmTdsRBUplm9BNxDmtQlxKwkYH50oJWw45iAX5sL1+SUuHYN4Xtkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gQlRpX9xg2MMInCa38N0neqbiRRJt3ovhfYd0+KUTXM=; b=CtoEpZY1M6Pdduj0/ri8bEtzZJt7YivhNi6rX8MqmxiD2ulzEwmDvdkkqyXNH5VLMNOLLO1G2ersJ74rX+BBYfJ+quGSW55dbg2DguyOiUC67IdYnkVmu5at7xSMKDtQ3xQocSdK3JrOHsiLYnl4Swo6ld7HTgJMPt8+Wg4ximdHBOrL93ZT6zzVar3oez9Ou0xZmUFrdMJJU2s4XepQmLtd+/EygXFuMGGelnzWCJvNWyoUuB3kqXCQWxyYQzxdedBD6fhEcoS2RV728oAJBFJj+qgh9H7cYeWDDHATxXsGOnzytw27B1Qytm8gR5WG5BXIPjCaIvcVcGVFNZxB9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by AS8PR08MB6485.eurprd08.prod.outlook.com (2603:10a6:20b:318::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.14; Wed, 16 Mar 2022 14:33:03 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::4d3d:c632:297e:1dcc]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::4d3d:c632:297e:1dcc%5]) with mapi id 15.20.5081.015; Wed, 16 Mar 2022 14:33:03 +0000 Message-ID: <77f98638-ec8f-5d79-8a00-d91db1253644@arm.com> Date: Wed, 16 Mar 2022 14:33:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH 2/3] Implement real literal extension for Ada Content-Language: en-US To: Tom Tromey , gdb-patches@sourceware.org References: <20220301170055.1520935-1-tromey@adacore.com> <20220301170055.1520935-3-tromey@adacore.com> From: Luis Machado In-Reply-To: <20220301170055.1520935-3-tromey@adacore.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0167.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18a::10) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 13b95033-d248-44d1-c710-08da0759e580 X-MS-TrafficTypeDiagnostic: AS8PR08MB6485:EE_|DB5EUR03FT028:EE_|VI1PR0802MB2494:EE_ X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: nLrtYAKKfKn7fhR9fZWvM6H3eMQpaCzW9iesuxCa5LIFbnic/HByLAiMS7BDzWqM2Y2GUvupzQSlhAnErMsmiNWWv2QdPBC1gx2cjm69nKZjwmr4i2RyjrfgQdh6fVVaVUvJNZgLNWMvRlJ72yDfKjbveKPGUf20dor3BN9r9ieOHvw3domwHEuV4KYk+l9ntWbIyxGT+Vv3EtUSKLbFu1cgRaK/tizgwZFK/rXxzmxkRIc5jbVvXaT0nx6QO8MvuXv8RPRZw6Lc3ODgZjIMG2JYnu+7X2Zz3XRpgBZuOYM/hYa4dkpm0bBM6vIm0AewlMfIuS6OvOW7GDK1ykECu4FPT4EMpVO2Spqib1ZtxMPIBH97AwanaNxloCirwfH1/endogFSBE3seW5B512ZVFdz0cv9IV8keAm67aMwaEbVycJ5Vtfc5Q79f2iyyytZ3S+ug/WTwyvMs9ZW/Opdu1vcBwPveXk/0FgRot08u66MYWWyB/A3Kq9x38YMwOEAwAQPukupcA0znQkX4ye+/1uMIOTavRpYW7XOLMtZur9Rq+shDFFHQ/Fyo/FOsCBB37oCWwBX3/OZ/o5AM+KOsL8hhpmmOb5WGJwtysNNlZ2LJlyAC6Yq2ltWQcsXSGLEidg0U/2nqaoCEJAhm9+IuCcO2Ye3L/F7HtQiqUVp0BA3l4EvwhkvSnwZXxzFpLLbkOoBlgOQWxgPdBBlwBmTFw7fCvAEzy5q7vRbx3Cz4DkQWkjmBzDA74T46MYbu9aBoistmQki7QI9LQuw7fM/9MxRRhiv/W2/7JDHvRiqwLIsmpljlr4R3eaxdWctJqD+p6KGzwQf1Lbvj0H1tUS3YbPqPQbsV7NwqsACBHXVTJXIoE548ggew2DbhfFsg3vd X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB3919.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(30864003)(8936002)(44832011)(5660300002)(186003)(26005)(53546011)(6506007)(36756003)(6512007)(83380400001)(38100700002)(84970400001)(31686004)(8676002)(66476007)(66556008)(66946007)(2906002)(31696002)(316002)(2616005)(6486002)(508600001)(86362001)(2004002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6485 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT028.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 08d73e43-a878-4c52-0cf4-08da0759e0a1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pNwZjiw5ckzxC9J7sftLmqW8y2PmDEB7uqQEjBF8hJm2jjAD49QdXe+YbC6mQFy8/qLQMhmoIMChIWmr+l6V9RVLD9bZshqo1rkfbanvunTPm/YKLdhBbNcKi2ghvXr3CjXkynhACv3Vs7FvWaenXeGm8zwKNzc0oD4C4MCCzuD/Y9W0gCo+bPIj716RId0n+kw+amtW8ONkFOmozYbODU/F7Ukpok/4rz8uzFWWCkIScNVMmJwFg9lfSPY+9nlG7GTpcqAq+2F5RP8CKKxrSX0pP+VvTZEzKB77jDpTB0X/OKBQAsxiejtS+NuynhiYjPmpTX4dTTlImnxsB/nBV9FRNXvqwIZNAJbCrK2BKpa5d2edJ3NAosBnbYub9+Zzf4kYYYp6zciB5Dc3sq8n0f+9VmJy9gduNWrrYVd997xyKJnEGn5i9BdlWSd/6fLTGjo+LZrTveHx5uODEDF6W29xv3K0ixz68CWs7babpg0DvkApDSCtaalsHKosAmYUE6jALGkchzBF1xo22Nxs6ddcrkNFILqII8rTl0D27kBu39FWeT0KBZeT+PnI19Cp8WMt+krO3rJhg6+oVco3BJ1AoP/chtUeRxifyc+I1v4ctXvx4GFAyKTcYiWHLcBzaZ4bNrYkENjbaKRy3GQkHjJNTjgxtcS++UI1GomueEnDUQ1O84Fug80UNECDQOhUq6skQWFWcZ+K+2vMsq4CR/B6ugptbzaBCTeOZL1ggc37c/flTwkypfM6f0hDfnxVKt7v/5D+4buli2FLIESLIdx3Qp8Pfr0Wl+rqKPvfHDCKKJx15KftFyKJTg7Jjq9BlESRq4XRh8pC6hdl3gl99TmtZh4I5MRsPAD7O5Y9BRM= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230001)(4636009)(40470700004)(36840700001)(46966006)(336012)(53546011)(6512007)(47076005)(6506007)(31686004)(36756003)(508600001)(36860700001)(40460700003)(6486002)(26005)(8936002)(2906002)(186003)(2616005)(5660300002)(8676002)(70206006)(70586007)(356005)(81166007)(316002)(83380400001)(30864003)(44832011)(31696002)(86362001)(82310400004)(84970400001)(2004002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2022 14:33:11.0096 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 13b95033-d248-44d1-c710-08da0759e580 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT028.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2494 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, KAM_LOTSOFHASH, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 16 Mar 2022 14:33:18 -0000 Hi Tom, On 3/1/22 17:00, Tom Tromey via Gdb-patches wrote: > Sometimes it is convenient to be able to specify the exact bits of a > floating-point literal. For example, you may want to set a > floating-point register to a denormalized value, or to a particular > NaN. > > In C, you can do this by combining the "{}" cast with an array > literal, like: > > (gdb) p {double}{0x576488BDD2AE9FFE} > $1 = 9.8765449999999996e+112 > > This patch adds a somewhat similar idea to Ada. It extends the lexer > to allow "l" and "f" suffixes in a based literal. The "f" indicates a > floating-point literal, and the "l"s control the size of the > floating-point type. > > Note that this differs from Ada's based real literals. I believe > those can also be used to control the bits of a floating-point value, > but they are a bit more cumbersome to use (simplest is binary but > that's also very lengthy). Also, these aren't implemented in GDB. > > I chose not to allow this extension to work with based integer > literals with exponents. That didn't seem very useful. > --- > gdb/NEWS | 8 ++ > gdb/ada-lex.l | 98 ++++++++++++++++++----- > gdb/doc/gdb.texinfo | 16 ++++ > gdb/testsuite/gdb.ada/float-bits.exp | 50 ++++++++++++ > gdb/testsuite/gdb.ada/float-bits/prog.adb | 22 +++++ > 5 files changed, 174 insertions(+), 20 deletions(-) > create mode 100644 gdb/testsuite/gdb.ada/float-bits.exp > create mode 100644 gdb/testsuite/gdb.ada/float-bits/prog.adb > > diff --git a/gdb/NEWS b/gdb/NEWS > index dc2cac1871b..2876ca822ad 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -136,6 +136,14 @@ info win > This command now includes information about the width of the tui > windows in its output. > > +* GDB's Ada parser now supports an extension for specifying the exact > + byte contents of a floating-point literal. This can be useful for > + setting floating-point registers to a precise value without loss of > + precision. The syntax is an extension of the based literal syntax. > + Use, e.g., "16lf#0123abcd#" -- the number of "l"s controls the width > + of the floating-point type, and the "f" is the marker for floating > + point. > + > * New targets > > GNU/Linux/LoongArch loongarch*-*-linux* > diff --git a/gdb/ada-lex.l b/gdb/ada-lex.l > index aab53b397ec..8e64d3a2926 100644 > --- a/gdb/ada-lex.l > +++ b/gdb/ada-lex.l > @@ -122,7 +122,11 @@ static int paren_depth; > e_ptr + 1); > } > > -{NUM10}"#"{HEXDIG}({HEXDIG}|_)*"#" { > + /* The "llf" is a gdb extension to allow a floating-point > + constant to be written in some other base. The > + floating-point number is formed by reinterpreting the > + bytes, allowing direct control over the bits. */ > +{NUM10}(l{0,2}f)?"#"{HEXDIG}({HEXDIG}|_)*"#" { > canonicalizeNumeral (numbuf, yytext); > return processInt (pstate, numbuf, strchr (numbuf, '#') + 1, > NULL); > @@ -347,18 +351,36 @@ static int > processInt (struct parser_state *par_state, const char *base0, > const char *num0, const char *exp0) > { > - ULONGEST result; > long exp; > int base; > - const char *trailer; > + /* For the based literal with an "f" prefix, we'll return a > + floating-point number. This counts the the number of "l"s seen, > + to decide the width of the floating-point number to return. -1 > + means no "f". */ > + int floating_point_l_count = -1; > > if (base0 == NULL) > base = 10; > else > { > - base = strtol (base0, (char **) NULL, 10); > + char *end_of_base; > + base = strtol (base0, &end_of_base, 10); > if (base < 2 || base > 16) > error (_("Invalid base: %d."), base); > + while (*end_of_base == 'l') > + { > + ++floating_point_l_count; > + ++end_of_base; > + } > + /* This assertion is ensured by the pattern. */ > + gdb_assert (floating_point_l_count == -1 || *end_of_base == 'f'); > + if (*end_of_base == 'f') > + { > + ++end_of_base; > + ++floating_point_l_count; > + } > + /* This assertion is ensured by the pattern. */ > + gdb_assert (*end_of_base == '#'); > } > > if (exp0 == NULL) > @@ -366,26 +388,62 @@ processInt (struct parser_state *par_state, const char *base0, > else > exp = strtol(exp0, (char **) NULL, 10); > > - errno = 0; > - result = strtoulst (num0, &trailer, base); > - if (errno == ERANGE) > - error (_("Integer literal out of range")); > - if (isxdigit(*trailer)) > - error (_("Invalid digit `%c' in based literal"), *trailer); > + gdb_mpz result; > + while (isxdigit (*num0)) > + { > + int dig = fromhex (*num0); > + if (dig >= base) > + error (_("Invalid digit `%c' in based literal"), *num0); > + mpz_mul_ui (result.val, result.val, base); > + mpz_add_ui (result.val, result.val, dig); > + ++num0; > + } > > while (exp > 0) > { > - if (result > (ULONG_MAX / base)) > - error (_("Integer literal out of range")); > - result *= base; > + mpz_mul_ui (result.val, result.val, base); > exp -= 1; > } > > - if ((result >> (gdbarch_int_bit (par_state->gdbarch ())-1)) == 0) > + if (floating_point_l_count > -1) > + { > + struct type *fp_type; > + if (floating_point_l_count == 0) > + fp_type = language_lookup_primitive_type (par_state->language (), > + par_state->gdbarch (), > + "float"); > + else if (floating_point_l_count == 1) > + fp_type = language_lookup_primitive_type (par_state->language (), > + par_state->gdbarch (), > + "long_float"); > + else > + { > + /* This assertion is ensured by the pattern. */ > + gdb_assert (floating_point_l_count == 2); > + fp_type = language_lookup_primitive_type (par_state->language (), > + par_state->gdbarch (), > + "long_long_float"); > + } > + > + yylval.typed_val_float.type = fp_type; > + result.write (gdb::make_array_view (yylval.typed_val_float.val, > + TYPE_LENGTH (fp_type)), > + type_byte_order (fp_type), > + true); > + > + return FLOAT; > + } > + > + gdb_mpz maxval (ULONGEST_MAX / base); > + if (mpz_cmp (result.val, maxval.val) > 0) > + error (_("Integer literal out of range")); > + > + LONGEST value = result.as_integer (); > + if ((value >> (gdbarch_int_bit (par_state->gdbarch ())-1)) == 0) > yylval.typed_val.type = type_int (par_state); > - else if ((result >> (gdbarch_long_bit (par_state->gdbarch ())-1)) == 0) > + else if ((value >> (gdbarch_long_bit (par_state->gdbarch ())-1)) == 0) > yylval.typed_val.type = type_long (par_state); > - else if (((result >> (gdbarch_long_bit (par_state->gdbarch ())-1)) >> 1) == 0) > + else if (((value >> (gdbarch_long_bit (par_state->gdbarch ())-1)) >> 1) == 0) > { > /* We have a number representable as an unsigned integer quantity. > For consistency with the C treatment, we will treat it as an > @@ -396,18 +454,18 @@ processInt (struct parser_state *par_state, const char *base0, > */ > yylval.typed_val.type > = builtin_type (par_state->gdbarch ())->builtin_unsigned_long; > - if (result & LONGEST_SIGN) > + if (value & LONGEST_SIGN) > yylval.typed_val.val = > - (LONGEST) (result & ~LONGEST_SIGN) > + (LONGEST) (value & ~LONGEST_SIGN) > - (LONGEST_SIGN>>1) - (LONGEST_SIGN>>1); > else > - yylval.typed_val.val = (LONGEST) result; > + yylval.typed_val.val = (LONGEST) value; > return INT; > } > else > yylval.typed_val.type = type_long_long (par_state); > > - yylval.typed_val.val = (LONGEST) result; > + yylval.typed_val.val = value; > return INT; > } > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index f7f5f7a6158..9d5f9b5aa94 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -18189,6 +18189,9 @@ context. > Should your program > redefine these names in a package or procedure (at best a dubious practice), > you will have to use fully qualified names to access their new definitions. > + > +@item > +Based real literals are not implemented. > @end itemize > > @node Additions to Ada > @@ -18247,6 +18250,19 @@ complex conditional breaks: > (@value{GDBP}) condition 1 (report(i); k += 1; A(k) > 100) > @end smallexample > > +@item > +An extension to based literals can be used to specify the exact bits > +of a real value. After the base, you can use from zero to two > +@samp{l} characters, followed by an @samp{f}. The number of @samp{l} > +characters controls the width of the resulting real constant: zero > +means @code{Float} is used, one means @code{Long_Float}, and two means > +@code{Long_Long_Float}. > + > +@smallexample > +(@value{GDBP}) print 16f#41b80000# > +$1 = 23.0 > +@end smallexample > + > @item > Rather than use catenation and symbolic character names to introduce special > characters into strings, one may instead use a special bracket notation, > diff --git a/gdb/testsuite/gdb.ada/float-bits.exp b/gdb/testsuite/gdb.ada/float-bits.exp > new file mode 100644 > index 00000000000..61db5f325ad > --- /dev/null > +++ b/gdb/testsuite/gdb.ada/float-bits.exp > @@ -0,0 +1,50 @@ > +# Copyright 2022 Free Software Foundation, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see . > + > +# Test floating-point literal extension. > + > +load_lib "ada.exp" > + > +if { [skip_ada_tests] } { return -1 } > + > +standard_ada_testfile prog > + > +if {[gdb_compile_ada "${srcfile}" "${binfile}" executable {debug}] != ""} { > + return -1 > +} > + > +clean_restart ${testfile} > + > +set bp_location [gdb_get_line_number "BREAK" ${testdir}/prog.adb] > +runto "prog.adb:$bp_location" > + > +gdb_test "print 16f#41b80000#" " = 23.0" > +gdb_test "print val_float" " = 23.0" > +gdb_test "print val_float := 16f#41b80000#" " = 23.0" > +gdb_test "print val_float" " = 23.0" \ > + "print val_float after assignment" > + > +gdb_test "print 16lf#bc0d83c94fb6d2ac#" " = -2.0e-19" > +gdb_test "print val_double" " = -2.0e-19" > +gdb_test "print val_double := 16lf#bc0d83c94fb6d2ac#" " = -2.0e-19" > +gdb_test "print val_double" " = -2.0e-19" \ > + "print val_double after assignment" > + > +gdb_test "print 16llf#7FFFF7FF4054A56FA5B99019A5C8#" " = 5.0e\\+25" > +gdb_test "print val_long_double" " = 5.0e\\+25" > +gdb_test "print val_long_double := 16llf#7FFFF7FF4054A56FA5B99019A5C8#" \ > + " = 5.0e\\+25" > +gdb_test "print val_long_double" " = 5.0e\\+25" \ > + "print val_long_double after assignment" > diff --git a/gdb/testsuite/gdb.ada/float-bits/prog.adb b/gdb/testsuite/gdb.ada/float-bits/prog.adb > new file mode 100644 > index 00000000000..0d8c18f8d47 > --- /dev/null > +++ b/gdb/testsuite/gdb.ada/float-bits/prog.adb > @@ -0,0 +1,22 @@ > +-- Copyright 2022 Free Software Foundation, Inc. > +-- > +-- This program is free software; you can redistribute it and/or modify > +-- it under the terms of the GNU General Public License as published by > +-- the Free Software Foundation; either version 3 of the License, or > +-- (at your option) any later version. > +-- > +-- This program is distributed in the hope that it will be useful, > +-- but WITHOUT ANY WARRANTY; without even the implied warranty of > +-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +-- GNU General Public License for more details. > +-- > +-- You should have received a copy of the GNU General Public License > +-- along with this program. If not, see . > + > +procedure Prog is > + Val_Float : Float := 23.0; > + Val_Double : Long_Float := -2.0e-19; > + Val_Long_Double : Long_Long_Float := 5.0e+25; > +begin > + null; -- BREAK > +end Prog; I think the floating point representations may differ between architectures/bit-sizes. I noticed 5 failures in this test for aarch64-linux and arm-linux. FAIL: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8# FAIL: gdb.ada/float-bits.exp: print val_long_double FAIL: gdb.ada/float-bits.exp: print val_long_double := 16llf#7FFFF7FF4054A56FA5B99019A5C8# FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment FAIL: gdb.ada/float-bits.exp: print Some of the expected values don't really match. If the output is supposed to differ, maybe we should compare hex values instead? Also, for 32-bit targets, I'm seeing size-related issues. Here's one example for aarch64: (expected) (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M $9 = 5.0e+25 (actual) (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8# $9 = 1.68104996779424899119072698287782049e-4932 And for arm 32-bit; (expected) (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M $9 = 5.0e+25 (actual) (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8# Cannot export value 2596145952482202326224873165792712 as 64-bits unsigned integer (must be between 0 and 18446744073709551615) Regards, Luis