public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Cupertino Miranda <cupertino.miranda@oracle.com>
To: gcc-patches@gcc.gnu.org
Cc: cupertino.miranda@oracle.com, jose.marchesi@oracle.com
Subject: [PATCH 2/2] Corrected pr25521.c target matching.
Date: Fri,  2 Dec 2022 17:52:25 +0000	[thread overview]
Message-ID: <20221202175225.2780-3-cupertino.miranda@oracle.com> (raw)
In-Reply-To: <20221202175225.2780-1-cupertino.miranda@oracle.com>

This commit is a follow up of bugzilla #107181.

The commit /a0aafbc/ changed the default implementation of the
SELECT_SECTION hook in order to match clang/llvm behaviour w.r.t the
placement of `const volatile' objects.

However, the following targets use target-specific selection functions
and they choke on the testcase pr25521.c:

 *rx - target sets its const variables as '.section C,"a",@progbits'.

 *powerpc - its 32bit version is eager to allocate globals in .sdata
            sections.

Normally, one can expect for the variable to be allocated in .srodata,
however, in case of powerpc-*-* or powerpc64-*-* (with -m32)
'targetm.have_srodata_section == false' and the code in
categorize_decl_for_section(varasm.cc), forces it to allocate in .sdata.

  /* If the target uses small data sections, select it.  */
  else if (targetm.in_small_data_p (decl))
    {
      if (ret == SECCAT_BSS)
	ret = SECCAT_SBSS;
      else if targetm.have_srodata_section && ret == SECCAT_RODATA)
	ret = SECCAT_SRODATA;
      else
	ret = SECCAT_SDATA;
    }

LLVM compiler does not generate .sdata symbols at all, having different code
generation even for non const volatile symbols.
Targets that for acceptable reasons could not match the LLVM generated code
were marked as XFAIL.

gcc/testsuite/ChangeLog:

	* lib/target-supports.exp: Added
	  check_effective_target_const_volatile_readonly_section.
	* gcc.dg/pr25521.c: Added XFAIL.
---
 gcc/testsuite/gcc.dg/pr25521.c        |  3 +--
 gcc/testsuite/lib/target-supports.exp | 12 ++++++++++++
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/pr25521.c b/gcc/testsuite/gcc.dg/pr25521.c
index 63363a03b9f..597a2fc25d8 100644
--- a/gcc/testsuite/gcc.dg/pr25521.c
+++ b/gcc/testsuite/gcc.dg/pr25521.c
@@ -6,5 +6,4 @@
 
 const volatile int foo = 30;
 
-
-/* { dg-final { scan-assembler "\\.s\?rodata" } } */
+/* { dg-final { scan-assembler-symbol-section {^_?foo$} {^\.(const|s?rodata)} { xfail { ! const_volatile_readonly_section } } } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 2a058c67c53..631d4593447 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -12196,3 +12196,15 @@ proc check_is_prog_name_available { prog } {
 
     return 1
 }
+
+# returns 1 if target does selects a readonly section for const volatile variables.
+proc check_effective_target_const_volatile_readonly_section { } {
+
+    if { [istarget rx*-*-*]
+	  || [istarget powerpc-*-*]
+	  || [istarget rs6000*-*-*]
+    	  || [check-flags { "" { powerpc64-*-* } { -m32 } }] } {
+	return 0
+    }
+  return 1
+}
-- 
2.30.2


  parent reply	other threads:[~2022-12-02 17:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 17:52 [PATCH] `const volatile' sections selection - bugzilla #107181 Cupertino Miranda
2022-12-02 17:52 ` [PATCH 1/2] select .rodata for const volatile variables Cupertino Miranda
2022-12-05 18:06   ` Jeff Law
2022-12-07 15:12     ` Cupertino Miranda
2022-12-15 10:13       ` Cupertino Miranda
2022-12-22 17:21         ` [PING] " Cupertino Miranda
2023-01-02 10:42           ` Cupertino Miranda
2023-01-09  7:57     ` Richard Biener
2023-01-13 15:06       ` Cupertino Miranda
2023-01-19  9:59         ` Cupertino Miranda
2023-01-22 18:43           ` Jeff Law
2023-01-22 18:49       ` Jeff Law
2022-12-02 17:52 ` Cupertino Miranda [this message]
2022-12-05 18:47   ` [PATCH 2/2] Corrected pr25521.c target matching Jeff Law
2022-12-07 15:45     ` Cupertino Miranda
2022-12-15 10:14       ` Cupertino Miranda
2022-12-22 17:22         ` [PING] " Cupertino Miranda
2023-01-02 10:43           ` Cupertino Miranda
2023-01-13 15:13       ` Cupertino Miranda
2023-01-22 19:04       ` Jeff Law
2023-01-24 12:24         ` Cupertino Miranda
2023-01-31  9:10           ` [PING] " Cupertino Miranda
2023-02-07  9:53             ` Cupertino Miranda
2023-02-17 14:33               ` Cupertino Miranda
2023-02-27 10:17                 ` Cupertino Miranda
2023-03-09  9:51                   ` [PING, PING] " Cupertino Miranda
2023-03-11 16:25           ` Jeff Law
2023-03-13 17:52             ` Cupertino Miranda
2023-03-13 17:57               ` Cupertino Miranda
2023-04-03  4:16                 ` Jeff Law

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=20221202175225.2780-3-cupertino.miranda@oracle.com \
    --to=cupertino.miranda@oracle.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jose.marchesi@oracle.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).