From: "Potharla, Rupesh via Gdb-patches" <gdb-patches@sourceware.org>
To: Andrew Burgess <aburgess@redhat.com>, Tom Tromey <tom@tromey.com>,
"Potharla, Rupesh via Gdb-patches" <gdb-patches@sourceware.org>
Cc: "George, Jini Susan" <JiniSusan.George@amd.com>,
"Parasuraman, Hariharan" <Hariharan.Parasuraman@amd.com>,
"Sharma, Alok Kumar" <AlokKumar.Sharma@amd.com>
Subject: RE: GDB/Fortran: Support for Assumed Rank Zero.
Date: Wed, 20 Apr 2022 19:08:43 +0000 [thread overview]
Message-ID: <DM6PR12MB4219F77ECE1E36BCD2E07A0EE7F59@DM6PR12MB4219.namprd12.prod.outlook.com> (raw)
In-Reply-To: <87sfq7rd94.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 7303 bytes --]
[AMD Official Use Only]
Thanks, Andrew,
Made suggested code changes and attached the updated patch. Requesting to review the code changes.
Regards,
Rupesh P
>> From 5357e50f3083d6fcbdcab4ca8932ae123d32773b Mon Sep 17 00:00:00
>2001
>> From: rupothar <rupesh.potharla@amd.com>
>> 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=<error reading variable:
>> 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?
Yes, the change was made only for data location for printing the value.
>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:
So far, I have not seen dynamic properties for array elements for rank0. I picked up the below code changes and updated the patch.
> 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.
Apologies for the hard comment, Thanks for the correction.
>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
[-- Attachment #2: 0001-gdb-fortran-Support-for-assumed-rank-zero.patch --]
[-- Type: application/octet-stream, Size: 4849 bytes --]
From fbfa2f4c26eeef7547603aafafb9525d66d1b172 Mon Sep 17 00:00:00 2001
From: rupothar <rupesh.potharla@amd.com>
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=<error reading variable:
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 | 21 ++++++++++++++++-----
gdb/gdbtypes.h | 4 +++-
gdb/testsuite/gdb.fortran/assumedrank.exp | 6 ++++++
gdb/testsuite/gdb.fortran/assumedrank.f90 | 3 +++
4 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index 49ecb199b07..47cf442a2d5 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -2398,10 +2398,21 @@ 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. 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;
}
else if (type->code () == TYPE_CODE_STRING && rank != 1)
{
@@ -5589,7 +5600,7 @@ create_copied_types_hash (struct objfile *objfile)
/* Recursively copy (deep copy) a dynamic attribute list of a type. */
-static struct dynamic_prop_list *
+struct dynamic_prop_list *
copy_dynamic_prop_list (struct obstack *objfile_obstack,
struct dynamic_prop_list *list)
{
diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h
index 769328cc9cd..99273d14c1f 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
@@ -2882,6 +2881,9 @@ extern struct type *copy_type_recursive (struct objfile *objfile,
struct type *type,
htab_t copied_types);
+extern struct dynamic_prop_list * copy_dynamic_prop_list
+ (struct obstack *objfile_obstack, struct dynamic_prop_list *list);
+
extern struct type *copy_type (const struct type *type);
extern bool types_equal (struct type *, struct type *);
diff --git a/gdb/testsuite/gdb.fortran/assumedrank.exp b/gdb/testsuite/gdb.fortran/assumedrank.exp
index 69cd168125f..e9429b44a9a 100644
--- a/gdb/testsuite/gdb.fortran/assumedrank.exp
+++ b/gdb/testsuite/gdb.fortran/assumedrank.exp
@@ -58,6 +58,12 @@ while { $test_count < 500 } {
}
}
+ # Currently, flang does not support rank0.
+ if {$test_count == 1 && [test_compiler_info {clang-*}]} {
+ unsupported "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
next prev parent reply other threads:[~2022-04-20 19:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-13 9:55 Potharla, Rupesh via Gdb-patches
2022-04-13 18:27 ` Kevin Buettner via Gdb-patches
2022-04-14 10:30 ` Potharla, Rupesh via Gdb-patches
2022-04-14 21:28 ` Kevin Buettner via Gdb-patches
2022-04-15 13:33 ` Potharla, Rupesh via Gdb-patches
2022-04-15 19:31 ` Kevin Buettner via Gdb-patches
2022-04-16 18:29 ` Potharla, Rupesh via Gdb-patches
2022-04-18 13:31 ` Tom Tromey
2022-04-18 15:25 ` Potharla, Rupesh via Gdb-patches
2022-04-20 15:22 ` Andrew Burgess via Gdb-patches
2022-04-20 19:08 ` Potharla, Rupesh via Gdb-patches [this message]
2022-04-22 14:38 ` Andrew Burgess via Gdb-patches
2022-04-25 6:33 ` Potharla, Rupesh via Gdb-patches
2022-04-25 8:47 ` Andrew Burgess via Gdb-patches
2022-04-18 15:33 ` Kevin Buettner via Gdb-patches
2022-04-19 17:30 ` Kevin Buettner via Gdb-patches
2022-04-20 0:29 ` Potharla, Rupesh via Gdb-patches
2022-04-20 6:32 ` Kempke, Nils-Christian via Gdb-patches
2022-04-20 15:38 ` Kevin Buettner via Gdb-patches
2022-04-20 15:29 ` Andrew Burgess via Gdb-patches
2022-04-20 19:20 ` Potharla, Rupesh via Gdb-patches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM6PR12MB4219F77ECE1E36BCD2E07A0EE7F59@DM6PR12MB4219.namprd12.prod.outlook.com \
--to=gdb-patches@sourceware.org \
--cc=AlokKumar.Sharma@amd.com \
--cc=Hariharan.Parasuraman@amd.com \
--cc=JiniSusan.George@amd.com \
--cc=Rupesh.Potharla@amd.com \
--cc=aburgess@redhat.com \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox