public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Indu Bhagat <ibhagat@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r12-8164] Refactor and update CTF testcases [PR105089]
Date: Thu, 14 Apr 2022 17:37:12 +0000 (GMT)	[thread overview]
Message-ID: <20220414173712.505AC3857815@sourceware.org> (raw)

https://gcc.gnu.org/g:d634c5d7c78c6ec0fa39d96984460475564519c8

commit r12-8164-gd634c5d7c78c6ec0fa39d96984460475564519c8
Author: Indu Bhagat <indu.bhagat@oracle.com>
Date:   Thu Apr 14 10:02:45 2022 -0700

    Refactor and update CTF testcases [PR105089]
    
    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.  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-04-14  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.

Diff:
---
 gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c     | 22 +++++++---------------
 gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c     | 17 +++++++++++++++++
 gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c | 22 ++++++++++++++++++++++
 3 files changed, 46 insertions(+), 15 deletions(-)

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 2a19da050fe..4721c4fb2f9 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 00000000000..ec504412ef5
--- /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 00000000000..8aea1e82749
--- /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";


                 reply	other threads:[~2022-04-14 17:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220414173712.505AC3857815@sourceware.org \
    --to=ibhagat@gcc.gnu.org \
    --cc=gcc-cvs@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).