From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0JJ+N0ElYGKMKwEAWB0awg (envelope-from ) for ; Wed, 20 Apr 2022 11:22:41 -0400 Received: by simark.ca (Postfix, from userid 112) id DFE8D1E15F; Wed, 20 Apr 2022 11:22:41 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=LwkdyZz6; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 210241E15D for ; Wed, 20 Apr 2022 11:22:41 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C5AAF3857356 for ; Wed, 20 Apr 2022 15:22:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C5AAF3857356 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1650468160; bh=twhdP8HyxbpwQFWk4gBHJz5PXusjimt3+jPv+6lBaSw=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=LwkdyZz69snrQLNTlEcDeHFl6OUmfRl5mVsZAneF4UpGmW3FV3yxn3nUl/sMMY2k6 IgeED44nK7ROEwotL466lw9yr/Ehawy9GZzh4q9HHp2hSQQrBAdSG2AaupC0Z7sZwi Fz2T1zPKfP6SO5Doq0EhC9pb3XsJ9Zp4vAHhFsrg= 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 CC5B43858D1E for ; Wed, 20 Apr 2022 15:22:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CC5B43858D1E Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-191-cfZMmbO0OiS3b06WgjCkYw-1; Wed, 20 Apr 2022 11:22:19 -0400 X-MC-Unique: cfZMmbO0OiS3b06WgjCkYw-1 Received: by mail-wr1-f70.google.com with SMTP id i64-20020adf90c6000000b00203f2b5e090so497534wri.9 for ; Wed, 20 Apr 2022 08:22:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=twhdP8HyxbpwQFWk4gBHJz5PXusjimt3+jPv+6lBaSw=; b=xEXHnX0PHXkFUH4+KhRY8v7kvdCZEyxm756Y5Cs/C3bmzDvgzjnGX2pWO5bbgg1iQ+ SzK1a+QtbbLDhosQlQOe589kvPWGCzHKDCF+45aUr1qb2x0/sGR2Jinc23022yG2x147 5TmwweVDFGZUdJEkIRKxCkwFIEAurzUV4EqM8j7Gk5XA5iK0piIuXKWJLpT+AV93QE+s HT06rkbc0LJ/itxQRE1G5Qrc7UMevPiTMdbxx84j5Cydv5upODRq3537cDSl2UuQADSR O3IRligD7pUnwNCOV3z+MZMuhqLqfrhlwak9bu8V9OcXP8a9DJWhvpE7AsbdMP1s1l00 CI/Q== X-Gm-Message-State: AOAM530aW4F3jlJV3AwJFmoxHq8w3aPs/28Y1kJmSPggCXSrIP1GNtZI PTQjf8IIHu4YGw99qiICenrfYPEXBdJoz5xf+cpnIe2DkRilTuzpDgttDWqn+xl2T0S976+xEyD PQV5CmKZpr+z1rKfX5uc9aQ== X-Received: by 2002:a5d:6c68:0:b0:20a:8d5f:681a with SMTP id r8-20020a5d6c68000000b0020a8d5f681amr14760955wrz.470.1650468137589; Wed, 20 Apr 2022 08:22:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy5PPPUakyr5h35qy/s1BhgLw+uc9lfERu03WzNVCfUAS0nxeWyp6Wc90d8QCrAKHnuF/XWlw== X-Received: by 2002:a5d:6c68:0:b0:20a:8d5f:681a with SMTP id r8-20020a5d6c68000000b0020a8d5f681amr14760941wrz.470.1650468137343; Wed, 20 Apr 2022 08:22:17 -0700 (PDT) Received: from localhost (host81-136-113-48.range81-136.btcentralplus.com. [81.136.113.48]) by smtp.gmail.com with ESMTPSA id h2-20020a05600c414200b0038ec7a4f07esm120989wmm.33.2022.04.20.08.22.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Apr 2022 08:22:16 -0700 (PDT) To: "Potharla\, Rupesh" , Tom Tromey , "Potharla\, Rupesh via Gdb-patches" Subject: RE: GDB/Fortran: Support for Assumed Rank Zero. In-Reply-To: References: <20220413112753.4c6f1128@f35-zws-1> <20220414142845.281b878d@f35-zws-1> <20220415123112.697ff872@f35-zws-1> <87tuaqy0uz.fsf@tromey.com> Date: Wed, 20 Apr 2022 16:22:15 +0100 Message-ID: <87sfq7rd94.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: , From: Andrew Burgess via Gdb-patches Reply-To: Andrew Burgess Cc: "George, Jini Susan" , "Parasuraman, Hariharan" , "Sharma, Alok Kumar" Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" "Potharla, Rupesh via Gdb-patches" writes: > [AMD Official Use Only] > > Thanks Tom, > > Made the suggested change and attached the updated patch. > > Regards, > Rupesh P > > >> -----Original Message----- >> From: Tom Tromey >> Sent: Monday, April 18, 2022 7:01 PM >> To: Potharla, Rupesh via Gdb-patches >> Cc: Kevin Buettner ; Potharla, Rupesh >> ; George, Jini Susan >> ; Parasuraman, Hariharan >> ; Sharma, Alok Kumar >> >> Subject: Re: GDB/Fortran: Support for Assumed Rank Zero. >> >> [CAUTION: External Email] >> >> >>>>> Potharla, Rupesh via Gdb-patches >> writes: >> >> > Requesting to review the attached patch with suggested code changes. >> >> > + type->main_type->target_type->main_type->dyn_prop_list = >> > + type->main_type->dyn_prop_list; >> >> In the gdb style, the '=' goes on the next line, and also the continuation line is >> just indented 2 spaces. >> >> thanks, >> Tom > From 5357e50f3083d6fcbdcab4ca8932ae123d32773b Mon Sep 17 00:00:00 2001 > From: rupothar > Date: Fri, 8 Apr 2022 16:05:41 +0530 > Subject: [PATCH] gdb/fortran: Support for assumed rank zero > > If a variable is passed to function in FORTRAN as an argument the > variable is treated as an array with rank zero. GDB currently does > not support the case for assumed rank 0. This patch provides support > for assumed rank 0 and updates the testcase as well. > > Without patch: > Breakpoint 1, arank::sub1 (a= failed to resolve dynamic array rank>) at assumedrank.f90:11 > 11 PRINT *, RANK(a) > (gdb) p a > failed to resolve dynamic array rank > (gdb) p rank(a) > failed to resolve dynamic array rank > > With patch: > Breakpoint 1, arank::sub1 (a=0) at assumedrank.f90:11 > 11 PRINT *, RANK(a) > (gdb) p a > $1 = 0 > (gdb) p rank(a) > $2 = 0 > --- > gdb/gdbtypes.c | 11 +++++++---- > gdb/gdbtypes.h | 1 - > gdb/testsuite/gdb.fortran/assumedrank.exp | 7 +++++++ > gdb/testsuite/gdb.fortran/assumedrank.f90 | 3 +++ > 4 files changed, 17 insertions(+), 5 deletions(-) > > diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c > index 49ecb199b07..afedd1f61b7 100644 > --- a/gdb/gdbtypes.c > +++ b/gdb/gdbtypes.c > @@ -2398,10 +2398,13 @@ resolve_dynamic_array_or_string (struct type *type, > > if (rank == 0) > { > - /* The dynamic property list juggling below was from the original > - patch. I don't understand what this is all about, so I've > - commented it out for now and added the following error. */ > - error (_("failed to resolve dynamic array rank")); > + /* Rank is zero, if a variable is passed as an argument to a > + function. GDB considers the variable as an array so discard > + the array type and return the target type which is of variable. */ > + type->main_type->target_type->main_type->dyn_prop_list > + = type->main_type->dyn_prop_list; > + type = TYPE_TARGET_TYPE (type); > + return type; I don't think this is correct, but I'm not completely sure what the correct thing to do is. TYPE here was created with a call to copy_type. After this call TYPE is a copy of the original dynamic type, but I believe that this is only a shallow copy (see copy_type in gdbtypes.c), so target_type will point at the same type object as the original dynamic type. When you copy the dyn_prop_list like you do above you are modifying the original target_type object. The next time this function is called we'll end up modifying the same target_type object again. I don't think this is correct. Also I don't think we are supposed to be creating multiple pointers to the same dyn_prop_list object like you're doing, I think you need to call copy_dynamic_prop_list. That said, I'm a little concerned that by just copying over the properties like this you're discarding any dynamic properties that might already exist on the target_type - though I'm not sure if it's possible to create a target_type that actually has any dynamic properties of its own.... maybe that's a problem we can leave until such a case crops up? I do suspect it might only be the data location that you really care about, so maybe we should only be copying that property? Anyway, if we don't worry about dynamic properties that might already exist on target_type, then the following code seems to work, but I've only done a quick test: if (rank == 0) { /* Rank is zero if a variable is passed as an argument to a function. In this case the resolved type should not be an array, but should instead be that of an array element. */ struct type *dynamic_array_type = type; type = copy_type (TYPE_TARGET_TYPE (dynamic_array_type)); struct dynamic_prop_list *prop_list = TYPE_MAIN_TYPE (dynamic_array_type)->dyn_prop_list; if (prop_list != nullptr) { struct obstack *obstack = &type->objfile_owner ()->objfile_obstack; TYPE_MAIN_TYPE (type)->dyn_prop_list = copy_dynamic_prop_list (obstack, prop_list); } return type; } You'll notice I also changed the comment within this block as I found the original comment hard to understand. What do you think? Thanks, Andrew > } > else if (type->code () == TYPE_CODE_STRING && rank != 1) > { > diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h > index 769328cc9cd..7437e1db8ab 100644 > --- a/gdb/gdbtypes.h > +++ b/gdb/gdbtypes.h > @@ -2092,7 +2092,6 @@ extern void allocate_gnat_aux_type (struct type *); > #define TYPE_REFERENCE_TYPE(thistype) (thistype)->reference_type > #define TYPE_RVALUE_REFERENCE_TYPE(thistype) (thistype)->rvalue_reference_type > #define TYPE_CHAIN(thistype) (thistype)->chain > -#define TYPE_DYN_PROP(thistype) TYPE_MAIN_TYPE(thistype)->dyn_prop_list > /* * Note that if thistype is a TYPEDEF type, you have to call check_typedef. > But check_typedef does set the TYPE_LENGTH of the TYPEDEF type, > so you only have to call check_typedef once. Since allocate_value > diff --git a/gdb/testsuite/gdb.fortran/assumedrank.exp b/gdb/testsuite/gdb.fortran/assumedrank.exp > index 69cd168125f..bd058e01e89 100644 > --- a/gdb/testsuite/gdb.fortran/assumedrank.exp > +++ b/gdb/testsuite/gdb.fortran/assumedrank.exp > @@ -58,6 +58,13 @@ while { $test_count < 500 } { > } > } > > + # XFAIL rank 0 for flang. > + if {$test_count == 1 && [test_compiler_info {clang-*}]} { > + setup_xfail "*-*-*" > + fail "compiler does not support rank 0" > + continue > + } > + > if ($found_final_breakpoint) { > break > } > diff --git a/gdb/testsuite/gdb.fortran/assumedrank.f90 b/gdb/testsuite/gdb.fortran/assumedrank.f90 > index 7f077c3f014..7f7cf2c1f3e 100644 > --- a/gdb/testsuite/gdb.fortran/assumedrank.f90 > +++ b/gdb/testsuite/gdb.fortran/assumedrank.f90 > @@ -19,16 +19,19 @@ > > PROGRAM arank > > + REAL :: array0 > REAL :: array1(10) > REAL :: array2(1, 2) > REAL :: array3(3, 4, 5) > REAL :: array4(4, 5, 6, 7) > > + array0 = 0 > array1 = 1.0 > array2 = 2.0 > array3 = 3.0 > array4 = 4.0 > > + call test_rank (array0) > call test_rank (array1) > call test_rank (array2) > call test_rank (array3) > -- > 2.17.1