From: Indu Bhagat <indu.bhagat@oracle.com>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 3/3] Refactor and update CTF testcases [PR105089]
Date: Wed, 30 Mar 2022 16:31:35 -0700 [thread overview]
Message-ID: <20220330233135.1762317-4-indu.bhagat@oracle.com> (raw)
In-Reply-To: <20220330233135.1762317-1-indu.bhagat@oracle.com>
This commit splits the ctf-array-2.c into ctf-array-5.c and
ctf-variables.c with the following responsibilities:
[1] ctf-array-2.c: Test CTF generation for unsized arrays.
[2] ctf-array-5.c: Test CTF generation for unsized but initialized array.
[3] ctf-variables-3.c: Test CTF generation for extern variable with defining
decl.
Earlier all three tests above were being done in ctf-array-2.c.
Further, the checks around [3] were very loose in the original version of
ctf-array-2.c in that the testcase was only checking that the types are as
expected. The compiler was emitting two CTF variable records as follows:
Variables:
_CTF_NEWSTR -> 5: const const char [0] (size 0x0) -> 4: const char [0] (size 0x0)
_CTF_NEWSTR -> 8: const const char [8] (size 0x8) -> 7: const char [8] (size 0x8)
This is incorrect behaviour as it creates ambiguity. The testcase
ctf-variables-3.c now has added checks that only one CTF variable record
is expected.
2022-03-30 Indu Bhagat <indu.bhagat@oracle.com>
gcc/testsuite/ChangeLog:
PR debug/105089
* gcc.dg/debug/ctf/ctf-array-2.c: Refactor testcase. Move some
checks ...
* gcc.dg/debug/ctf/ctf-array-5.c: ... to here.
* gcc.dg/debug/ctf/ctf-variables-3.c: ... and here. Add
additional checks for one CTF variable and one CTF object info
record.
---
gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c | 22 ++++++-------------
gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c | 17 ++++++++++++++
.../gcc.dg/debug/ctf/ctf-variables-3.c | 22 +++++++++++++++++++
3 files changed, 46 insertions(+), 15 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c
create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c b/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c
index 2a19da050fe7..4721c4fb2f97 100644
--- a/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c
@@ -5,34 +5,26 @@
TBD_CTF_FORMAT_OPEN_ISSUES (1) -
This testcase makes a note of the case of a probable misrepresentation.
- See Note 1 and Note 2 below.
+ See Note 1 below.
In the CTF section, these types are encoded as :
Variables:
- _CTF_NEWSTR -> 7: const char [0] (size 0x0)
- _CTF_SECTION -> 6: const char [5] (size 0x5)
- b1 -> 2: int [0] (size 0x0)
- b2 -> 3: int [0] (size 0x0)
+ b1 -> 3: int [0] (size 0x0)
+ b2 -> 5: int [0] (size 0x0)
Note 1 : There is misrepresentation in that b1 and b2 are specified
differently by the user.
- Note 2 : It is arguable though whether the representation for
- _CTF_NEWSTR is incorrect. */
+
+ In this testcase, two CTF array records each of type int [0] is expected. */
/* { dg-do compile ) */
/* { dg-options "-O0 -gctf -dA" } */
-/* { dg-final { scan-assembler-times "0x12000000\[\t \]+\[^\n\]*ctt_info" 5 } } */
+/* { dg-final { scan-assembler-times "0x12000000\[\t \]+\[^\n\]*ctt_info" 2 } } */
-/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*cta_nelems" 3 } } */
-/* { dg-final { scan-assembler-times "\[\t \]0x5\[\t \]+\[^\n\]*cta_nelems" 1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*cta_nelems" 2 } } */
static int b1[] = {};
int b2[0];
-
-const char _CTF_SECTION[] = ".ctf";
-
-extern const char _CTF_NEWSTR[];
-const char _CTF_NEWSTR[] = "ctfinfo";
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c b/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c
new file mode 100644
index 000000000000..ec504412ef56
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c
@@ -0,0 +1,17 @@
+/* CTF generation for unsized (but initialized) arrays
+
+ In this testcase, one CTF array type record of size 5 is expected.
+
+ Variables:
+ _CTF_SECTION -> 5: const const char [5] (size 0x5) -> 4: const char [5] (size 0x5)
+
+*/
+
+/* { dg-do compile ) */
+/* { dg-options "-O0 -gctf -dA" } */
+
+/* { dg-final { scan-assembler-times "0x12000000\[\t \]+\[^\n\]*ctt_info" 1 } } */
+
+/* { dg-final { scan-assembler-times "\[\t \]0x5\[\t \]+\[^\n\]*cta_nelems" 1 } } */
+
+const char _CTF_SECTION[] = ".ctf";
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c b/gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c
new file mode 100644
index 000000000000..8aea1e82749e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c
@@ -0,0 +1,22 @@
+/* CTF generation for extern variable with defining and non-defining decl
+ in the same CU.
+
+ This testcase checks the case when a non-defining decl is followed by
+ a defining decl for the same variable. See PR debug/105089.
+
+ In this testcase, although two CTF array types are generated, only a
+ single CTF variable and a single entry in the CTF object info section
+ are expected. */
+
+/* { dg-do compile ) */
+/* { dg-options "-O0 -gctf -dA" } */
+
+/* { dg-final { scan-assembler-times "0x12000000\[\t \]+\[^\n\]*ctt_info" 2 } } */
+
+/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*cta_nelems" 1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x8\[\t \]+\[^\n\]*cta_nelems" 1 } } */
+/* { dg-final { scan-assembler-times "ctv_name" 1 } } */
+/* { dg-final { scan-assembler-times "objtinfo_var_type" 1 } } */
+
+extern const char _CTF_NEWSTR[];
+const char _CTF_NEWSTR[] = "ctfinfo";
--
2.31.1
next prev parent reply other threads:[~2022-03-30 23:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 23:31 [PATCH 0/3] Fix PR debug/105089 Indu Bhagat
2022-03-30 23:31 ` [PATCH 1/3] ctfc: get rid of the static variable in ctf_list_add_ctf_vars () Indu Bhagat
2022-03-30 23:31 ` [PATCH 2/3] CTF for extern variable fix [PR105089] Indu Bhagat
2022-03-30 23:31 ` Indu Bhagat [this message]
2022-04-07 20:04 ` [PATCH 0/3] Fix PR debug/105089 Indu Bhagat
2022-04-08 6:37 ` Richard Biener
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=20220330233135.1762317-4-indu.bhagat@oracle.com \
--to=indu.bhagat@oracle.com \
--cc=gcc-patches@gcc.gnu.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).