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 A8F103836E81 for ; Thu, 18 May 2023 08:32:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A8F103836E81 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684398739; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KPgtibORkOeCpXCU2ltCEYNOKeH/zmFbORfLvmN4ExI=; b=DoAL+1NRh1IzZZOkpipwywNO9bpfQMp49J90pm0vYre1DzRRogv+uHDthE9OwtgU+y+cEt MdGh3VbIMk+h5V7BzjQenP9BItIFjE5r4kdXUze+4PuAZvzu8QqePnClXbPutrvBoUjE8q OthsJw39ZThHuAglP0rlUA14gdaLWAU= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-395-gWyLay0gO7W0OUqdSby6fQ-1; Thu, 18 May 2023 04:32:18 -0400 X-MC-Unique: gWyLay0gO7W0OUqdSby6fQ-1 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3079c6648e3so1093435f8f.2 for ; Thu, 18 May 2023 01:32:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684398737; x=1686990737; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Pt1rcN6VDPzDBwj2dxKpZpTHypY+wWmHHDGyMEyNFlM=; b=guvv1Xy4fS1YCuxlvQhtVQ2SvpaePz9lAf3wld7FRcyAnf5LihvLHh7X6+xk+5sIrt /Zdtw02s3ncOSOtk0wy3s7PmnrapSzCzox1q7vebxYr0krW8ek9Wi40+Sa1rvihO8mwj wCQgwyGJgJZ2LkQqP8KLIKiRjpzOm0mKC1vGNuGVpx1ULsA+JXctN6zBI6TOV/B/6vAg VATKPIw8xestUJBYcIL8sWLsdBdDYPGOZRNhiQfjAPeSy98S1XtGW6k3nbRwLVcKzfaY HyJ6ADLasEZokSLFOYn4X4bbnH8lPiKtqHEvuoDkgsH/6huu73u8DyeoJ+/+T2S9mdbf IWYw== X-Gm-Message-State: AC+VfDzqBrBXZpNv4yQLd2OJ9FDrvPVYqp8He/dq1t1wjqNmjkDptxUZ MgT5M/HP0tWRjpZS27JFZvG8Wkr7JgyGroWPuPmDROYd1G54kXDvnYovFIVChjyusYGDSprlPLe bNkksSXSIxx8B2OVbEgqyUQ== X-Received: by 2002:a5d:5606:0:b0:2f9:4fe9:74bb with SMTP id l6-20020a5d5606000000b002f94fe974bbmr897075wrv.40.1684398736929; Thu, 18 May 2023 01:32:16 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6wEcL3Vos2Vv+hZkeJUcEJGr0YmUVyaWJCTMmJqGsDJs/Zw8GzuG7hnoditZpLDXiL2k2l2g== X-Received: by 2002:a5d:5606:0:b0:2f9:4fe9:74bb with SMTP id l6-20020a5d5606000000b002f94fe974bbmr897054wrv.40.1684398736516; Thu, 18 May 2023 01:32:16 -0700 (PDT) Received: from localhost (11.72.115.87.dyn.plus.net. [87.115.72.11]) by smtp.gmail.com with ESMTPSA id l8-20020a5d4108000000b003064088a94fsm1410270wrp.16.2023.05.18.01.32.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 May 2023 01:32:15 -0700 (PDT) From: Andrew Burgess To: Simon Marchi , Simon Marchi via Gdb-patches Cc: Simon Marchi Subject: Re: [PATCH] gdb.fortran/lbound-ubound.exp: read expected lbound and ubound from function parameters (PR 30414) In-Reply-To: References: <20230504154829.34338-1-simon.marchi@efficios.com> <87o7mp5vq8.fsf@redhat.com> Date: Thu, 18 May 2023 09:32:13 +0100 Message-ID: <87ilcq9h0y.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Simon Marchi writes: > On 5/12/23 13:02, Andrew Burgess via Gdb-patches wrote: >>> @@ -96,6 +68,17 @@ while { $test_count < 500 } { >>> =09 break >>> =09} >>> =20 >>> +=09set expected_lbound [get_valueof "" "lb" "get expected lbound"] >>=20 >> I don't think this is doing what you expect (given the lines below). >> The default value is going to be 'get expected lbound', while the >> testname will be generated by the get_valueof call. You can just do >> this: >>=20 >> set expected_lbound [get_integer_valueof "lb" "" "get expected lbound"= ] > > You're right, I'm missing a parameter to get_valueof. It should have > been: > > =09set expected_lbound [get_valueof "" "lb" "" "get expected lbound"] > =09set expected_ubound [get_valueof "" "ub" "" "get expected ubound"] > > Note that I don't want to use get_integer_valueof here, because that > proc specifically expects one integer, whereas I get an array of > integers: > > print lb^M > $1 =3D (-8, -10)^M > (gdb) PASS: gdb.fortran/lbound-ubound.exp: test 0: get expected lboun= d > print ub^M > $2 =3D (-1, -2)^M > (gdb) PASS: gdb.fortran/lbound-ubound.exp: test 0: get expected uboun= d > > Luckily, GDB outputs them in the same format as the inferior outputs > them before my patch. So the rest of the test doesn't see the > difference. > >>> +=09set expected_ubound [get_valueof "" "ub" "get expected ubound"] >>> + >>> +=09if { $expected_lbound =3D=3D "" } { >>> +=09 error "failed to extract expected results for lbound" >>> +=09} >>> + >>> +=09if { $expected_ubound =3D=3D "" } { >>> +=09 error "failed to extract expected results for ubound" >>> +=09} >>=20 >> I was originally going to suggest dropping these checks -- having the >> default expected result be the empty string (or maybe use some other >> invalid string, e.g. '*INVALID*'?) will cause the following tests to >> fail anyway, so the check doesn't seem to add much. >>=20 >> But I see all you really did was move the checks I already had ... so I >> guess that's fine. I don't think I'd write this test in this way today >> though. > > I am fine with dropping the checks. > >> I do wonder why the switch from perror to error though? The original >> perror would print the error but then continue to try the next test, >> while error aborts the whole test script. I guess if one goes wrong >> then they all go wrong... I guess it doesn't really matter much. > > I'm not a big fan of perror in the first place, I find it's really easy > to mis-use. Like here, the test calls perror, but then return. So > what is the next test that it intends to mark as unresolved? Is it > going to affect the next .exp to be executed? I feel like something > like that happened to me before and I chased the source of random > unresolveds for a long time. > > I just re-read the documentation, and noticed: > > If the optional numeric value is 0, then there are no further side > effects to calling this function, and the following test outcome > doesn=E2=80=99t become UNRESOLVED. This can be used for errors with n= o known > side effects. > > So I suppose that calling perror with 0 would be fine here. Except > that I just tried it and: > > Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbou= nd-ubound.exp ... > ERROR: hello > ... > # of expected passes 5 > ... > $ echo $? > 0 > > That error doesn't leave a trace in the summary and the exit status is > 0, so it seems very easy to miss. > > So, my preference in that case is to use "error", it's impossible to > miss. It means we abort the whole test, but that seems fine in this > situation where something just unrecoverable happened. Honestly, I wasn't even aware of perror changing the next test to unresolved. So, that's my one thing learned for today :) I'm happy with using error, or no checks and just collecting the FAILs, whatever you prefer. Thanks for getting this test fixed up. Andrew > > But again, I'm fine with not having checks at all, it means we would get > a bunch of FAILs in that case, which is also impossible to miss. > > Simon