From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 513633858421 for ; Tue, 4 Jan 2022 14:26:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 513633858421 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-385-Plj0mUcwN4SiZAE7tk90xw-1; Tue, 04 Jan 2022 09:26:28 -0500 X-MC-Unique: Plj0mUcwN4SiZAE7tk90xw-1 Received: by mail-wm1-f71.google.com with SMTP id m9-20020a05600c4f4900b0034644da3525so361588wmq.3 for ; Tue, 04 Jan 2022 06:26:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6mVnlWFY27+q+A7fAmlr8cAB+AHOm5PkxeIZolebJEM=; b=cPFcxI0lFNO4JVgGhaqZjFkULauVM5jeZudArjOr4Ibj82PY3ajzol91IJ7mvcMkSK shjfg+tRuAyapwtrbeCWjxA8dyXAJW/VtfTRyDxqDD9QOOMDicJYkgmWwtgABKyYVJtW sRPzbrbRDj3WUl/8+RzQN3muVOognlxrf9ycxERArOGgelaBQyb3qOlpJRW4rq7zv986 3N93CqKa6okEek0o/8ClCpfdtw/75zLwN97i0Cbmc1o8JeojZFaG1xgQY9VVhEC8dGJu nEAz3t/zkin280o9KaAiL74decWn7ONghXuXCKw6hzgxUs1lNpCAw6VE2g8BCOCVnf9W Qu9A== X-Gm-Message-State: AOAM532x8VUqxb3CJmUqa0w5RH2ktqf/z9pTpqS0aTqztgl9hFpngY+K hxIYUU6RF3NHKd8EZoF9pttm4s/q+m94AAGk54mEKNLT2493sVRew8hpyDPAJCKklnNYAghARTu pLjKUBxQNXlhMiUun0LyrWQ== X-Received: by 2002:a7b:c448:: with SMTP id l8mr42024582wmi.173.1641306387068; Tue, 04 Jan 2022 06:26:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJxO7mxtN17T7rQBfFbIgpt0rEig0JTgX7ZsZR+GueKQEDEKqh4DQ4rLFUDgD+VRigNDu0IUug== X-Received: by 2002:a7b:c448:: with SMTP id l8mr42024571wmi.173.1641306386828; Tue, 04 Jan 2022 06:26:26 -0800 (PST) Received: from localhost (host109-154-163-67.range109-154.btcentralplus.com. [109.154.163.67]) by smtp.gmail.com with ESMTPSA id j39sm35732120wms.0.2022.01.04.06.26.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jan 2022 06:26:26 -0800 (PST) Date: Tue, 4 Jan 2022 14:26:25 +0000 From: Andrew Burgess To: Lancelot SIX Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 11/29] gdb/testsuite: Remove duplicates from gdb.base/dfp-test.exp Message-ID: <20220104142625.GL1845520@redhat.com> References: <20211121175636.779325-1-lsix@lancelotsix.com> <20211121175636.779325-12-lsix@lancelotsix.com> MIME-Version: 1.0 In-Reply-To: <20211121175636.779325-12-lsix@lancelotsix.com> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 14:23:31 up 2 days, 23:17, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP 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: Tue, 04 Jan 2022 14:26:31 -0000 * Lancelot SIX via Gdb-patches [2021-11-21 17:56:18 +0000]: > When running the testsuite, I have: > > Running .../gdb/testsuite/gdb.base/dfp-test.exp ... > DUPLICATE: gdb.base/dfp-test.exp: 1.23E is an invalid number > DUPLICATE: gdb.base/dfp-test.exp: 1.23E45A is an invalid number > DUPLICATE: gdb.base/dfp-test.exp: 1.23E is an invalid number > DUPLICATE: gdb.base/dfp-test.exp: 1.23E45A is an invalid number > > Fix by adjusting the test names. > > Tested on x86_64-linux. > --- > gdb/testsuite/gdb.base/dfp-test.exp | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/gdb/testsuite/gdb.base/dfp-test.exp b/gdb/testsuite/gdb.base/dfp-test.exp > index 379794a1b31..c2ca7e7f032 100644 > --- a/gdb/testsuite/gdb.base/dfp-test.exp > +++ b/gdb/testsuite/gdb.base/dfp-test.exp > @@ -61,10 +61,10 @@ proc d32_set_tests {} { > gdb_test "p d32=1.234567E+97df" " = Infinity" "1.234567E+97 is Infinity" > > # Test that gdb could detect the errors in the string representation of _Decimal32 > - gdb_test "p d32=12345.df" " = 12345" "12345. is a valid number" > - gdb_test "p d32=12345df" ".*Invalid number.*" "12345 is an invalid number" > - gdb_test "p d32=1.23Edf" ".*Conversion syntax.*" "1.23E is an invalid number" > - gdb_test "p d32=1.23E45Adf" ".*Conversion syntax.*" "1.23E45A is an invalid number" > + gdb_test "p d32=12345.df" " = 12345" "12345. is a valid Decimal32 number" > + gdb_test "p d32=12345df" ".*Invalid number.*" "12345 is an invalid Decimal32 number" > + gdb_test "p d32=1.23Edf" ".*Conversion syntax.*" "1.23E is an invalid Decimal32 number" > + gdb_test "p d32=1.23E45Adf" ".*Conversion syntax.*" "1.23E45A is an invalid Decimal32 number" > } Did you consider using proc_with_prefix? You could change d32_set_tests and d64_set_tests like this: proc_with_prefix d32_set_tests {} { ... } proc_with_prefix d64_set_tests {} { ... } And this will cause all of the enclosed tests to be prefixed with 'd32_set_tests' or 'd64_set_tests'. This seems a slightly neater solution, what do you think? Thanks, Andrew > > proc d64_set_tests {} { > @@ -92,9 +92,9 @@ proc d64_set_tests {} { > gdb_test "p d64=1.234567890123456E385dd" " = Infinity" "d64=1.234567890123456E385 is Infinity" > > # Test that gdb could detect the errors in the string representation of _Decimal64 > - gdb_test "p d64=12345dd" ".*Invalid number.*" "12345dd is an invalid number" > - gdb_test "p d64=1.23Edd" ".*Conversion syntax.*" "1.23E is an invalid number" > - gdb_test "p d64=1.23E45Add" ".*Conversion syntax.*" "1.23E45A is an invalid number" > + gdb_test "p d64=12345dd" ".*Invalid number.*" "12345 is an invalid Decimal64 number" > + gdb_test "p d64=1.23Edd" ".*Conversion syntax.*" "1.23E is an invalid Decimal64 number" > + gdb_test "p d64=1.23E45Add" ".*Conversion syntax.*" "1.23E45A is an invalid Decimal64 number" > } > > proc d128_set_tests {} { > @@ -121,9 +121,9 @@ proc d128_set_tests {} { > gdb_test "p d128=1.234567890123456E6145dl" "Infinity" "d128=1.234567890123456E6145 is Infinity" > > # Test that gdb could detect the errors in the string representation of _Decimal128 > - gdb_test "p d128=12345dl" ".*Invalid number.*" "12345dl is an invalid number" > - gdb_test "p d128=1.23Edl" ".*Conversion syntax.*" "1.23E is an invalid number" > - gdb_test "p d128=1.23E45Adl" ".*Conversion syntax.*" "1.23E45A is an invalid number" > + gdb_test "p d128=12345dl" ".*Invalid number.*" "12345dl is an invalid Decimal128 number" > + gdb_test "p d128=1.23Edl" ".*Conversion syntax.*" "1.23E is an invalid Decimal128 number" > + gdb_test "p d128=1.23E45Adl" ".*Conversion syntax.*" "1.23E45A is an invalid Decimal128 number" > } > > # Different tests on 32-bits decimal floating point, including the printing > -- > 2.33.1 >