public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Nathan Sidwell <nathan@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc/devel/c++-modules] gcc.dg/pr94600-5.c .. -8.c: Align struct t0 explictly, as a type, PR middle-end/94600
Date: Thu, 27 Aug 2020 18:09:01 +0000 (GMT)	[thread overview]
Message-ID: <20200827180901.880D73870906@sourceware.org> (raw)

https://gcc.gnu.org/g:5db1fa9bc69dd58ce2f93dd707d05efcfe89ffa8

commit 5db1fa9bc69dd58ce2f93dd707d05efcfe89ffa8
Author: Hans-Peter Nilsson <hp@axis.com>
Date:   Thu Aug 13 05:12:23 2020 +0200

    gcc.dg/pr94600-5.c .. -8.c: Align struct t0 explictly, as a type, PR middle-end/94600
    
    The bitfield-struct t0 in gcc.dg/pr94600-1.c ..-4.c is assigned to a
    pointer that is a (volatile-and-pointer-)cast literal, so gcc doesn't
    need to be otherwise told that the address is aligned.  But, variants
    pr94600-5.c ..-8.c are assigned through a "volatile t0 *", and rely on
    the *type* being naturally aligned, or that the machine has
    non-strict-alignment moves.
    
    Unfortunately, systems exist (for some definitions of exist) where
    such structs aren't always naturally aligned, for example if it
    contains only (small) bitfields, even though the size is a naturally
    accessible size.  Specifically, the mmix-knuth-mmixware port has only
    *byte* alignment for this struct.  (If an int is added to the struct,
    alignment is promoted.)  IOW, a prerequisite of the test is false: the
    struct doesn't have the same alignment as an integer of the same size.
    The effect is assignment in byte-size pieces, and the test fails.
    (For a non-volatile assignment, memcpy is called.)  That's easily
    fixable by defining the type as having a specific alignment.  This is
    also closer to the type in the original code, and also as the first
    variants aren't affected, no second thought or re-visit of pre-fixed
    compiler is needed.  I don't plan to back-port this to gcc-10 branch
    however.  I did sanity-check that the tests still pass on
    ppc64le-linux.
    
    gcc/testsuite:
    
            PR middle-end/94600
            * gcc.dg/pr94600-5.c, gcc.dg/pr94600-6.c, gcc.dg/pr94600-7.c,
            gcc.dg/pr94600-8.c: Align t0 to 4-byte boundary.

Diff:
---
 gcc/testsuite/gcc.dg/pr94600-5.c | 2 +-
 gcc/testsuite/gcc.dg/pr94600-6.c | 2 +-
 gcc/testsuite/gcc.dg/pr94600-7.c | 2 +-
 gcc/testsuite/gcc.dg/pr94600-8.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/pr94600-5.c b/gcc/testsuite/gcc.dg/pr94600-5.c
index 90085b3b1df..3be0249273e 100644
--- a/gcc/testsuite/gcc.dg/pr94600-5.c
+++ b/gcc/testsuite/gcc.dg/pr94600-5.c
@@ -9,7 +9,7 @@ typedef struct {
   unsigned int f1 : 11;
   unsigned int f2 : 10;
   unsigned int f3 : 7;
-} t0;
+} t0 __attribute__((__aligned__(4)));
 
 static t0 a0[] = {
  { .f0 = 7, .f1 = 99, .f3 = 1, },
diff --git a/gcc/testsuite/gcc.dg/pr94600-6.c b/gcc/testsuite/gcc.dg/pr94600-6.c
index 23a81a01f49..c247afef11a 100644
--- a/gcc/testsuite/gcc.dg/pr94600-6.c
+++ b/gcc/testsuite/gcc.dg/pr94600-6.c
@@ -9,7 +9,7 @@ typedef struct {
   unsigned int f1 : 11;
   unsigned int f2 : 10;
   unsigned int f3 : 7;
-} t0;
+} t0 __attribute__((__aligned__(4)));
 
 void
 bar(volatile t0 *b)
diff --git a/gcc/testsuite/gcc.dg/pr94600-7.c b/gcc/testsuite/gcc.dg/pr94600-7.c
index 2f5c759d3a1..81c5231e44c 100644
--- a/gcc/testsuite/gcc.dg/pr94600-7.c
+++ b/gcc/testsuite/gcc.dg/pr94600-7.c
@@ -9,7 +9,7 @@ typedef struct {
   unsigned int f1 : 11;
   unsigned int f2 : 10;
   unsigned int f3 : 7;
-} t0;
+} t0 __attribute__((__aligned__(4)));
 
 static t0 a0[] = {
  { .f0 = 7, .f1 = 99, .f3 = 1, },
diff --git a/gcc/testsuite/gcc.dg/pr94600-8.c b/gcc/testsuite/gcc.dg/pr94600-8.c
index ded814b3b95..201b2add4d9 100644
--- a/gcc/testsuite/gcc.dg/pr94600-8.c
+++ b/gcc/testsuite/gcc.dg/pr94600-8.c
@@ -9,7 +9,7 @@ typedef struct {
   unsigned int f1 : 11;
   unsigned int f2 : 10;
   unsigned int f3 : 7;
-} t0;
+} t0 __attribute__((__aligned__(4)));
 
 void
 bar(volatile t0 *b)


                 reply	other threads:[~2020-08-27 18:09 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=20200827180901.880D73870906@sourceware.org \
    --to=nathan@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).