public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/94707] [8/9 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le
Date: Wed, 29 Apr 2020 07:06:49 +0000	[thread overview]
Message-ID: <bug-94707-4-fFtBZNbBcY@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94707-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:575ac27fd5f18ffc9cfce8a99e987f52c5b898c9

commit r10-8027-g575ac27fd5f18ffc9cfce8a99e987f52c5b898c9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Apr 29 09:01:49 2020 +0200

    c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class
layout and [[no_unique_address]] handling [PR94707]

    As reported by Iain and David, powerpc-darwin and powerpc-aix* have C++14
    vs. C++17 ABI incompatibilities which are not fixed by mere adding of
    cxx17_empty_base_field_p calls.  Unlike the issues that were seen on other
    targets where the artificial empty base field affected function argument
    passing or returning of values, on these two targets the difference is
    during class layout, not afterwards (e.g.
    struct empty_base {};
    struct S : public empty_base { unsigned long long l[2]; };
    will have different __alignof__ (S) between C++14 and C++17 (or possibly
    with double instead of unsigned long long too)).

    I've tried:
    struct X { };
    struct Y { int : 0; };
    struct Z { int : 0; Y y; };
    struct U : public X { X q; };
    struct A { float a, b, c, d; };
    struct B : public X { float a, b, c, d; };
    struct C : public Y { float a, b, c, d; };
    struct D : public Z { float a, b, c, d; };
    struct E : public U { float a, b, c, d; };
    struct F { [[no_unique_address]] X x; float a, b, c, d; };
    struct G { [[no_unique_address]] Y y; float a, b, c, d; };
    struct H { [[no_unique_address]] Z z; float a, b, c, d; };
    struct I { [[no_unique_address]] U u; float a, b, c, d; };
    struct J { float a, b; [[no_unique_address]] X x; float c, d; };
    struct K { float a, b; [[no_unique_address]] Y y; float c, d; };
    struct L { float a, b; [[no_unique_address]] Z z; float c, d; };
    struct M { float a, b; [[no_unique_address]] U u; float c, d; };
     #define T(S, s) extern S s; extern void foo##s (S); int bar##s () { foo##s
(s); return 0; }
    T (A, a)
    T (B, b)
    T (C, c)
    T (D, d)
    T (E, e)
    T (F, f)
    T (G, g)
    T (H, h)
    T (I, i)
    T (J, j)
    T (K, k)
    T (L, l)
    T (M, m)
    testcase on powerpc64-linux.  Results:
    G++ 9 -std=c++14                A, B, C passed in fprs, the rest in gprs
    G++ 9 -std=c++17                A passed in fprs, the rest in gprs
    current trunk -std=c++14 & 17   A, B, C passed in fprs, the rest in gprs
    patched trunk -std=c++14 & 17   A, B, C, F, G, J, K passed in fprs, the
rest in gprs
    clang++ [*] -std=c++14 & 17     A, B, C, F, G, J, K passed in fprs, the
rest in gprs
    [*] clang version 11.0.0 (git@github.com:llvm/llvm-project.git
5c352e69e76a26e4eda075e20aa6a9bb7686042c)

    Is that what we want?  I think it matches the stated intent of P0840R2 or
    what Jason/Jonathan said, and doing something different like e.g. not
    treating C, G and K as homogenous because of the int : 0 in empty bases
    or in zero sized [[no_unique_address] fields would be quite hard to
    implement (because for C++14 the FIELD_DECL just isn't there).

    2020-04-29  Jakub Jelinek  <jakub@redhat.com>

            PR target/94707
            * tree-core.h (tree_decl_common): Note decl_flag_0 used for
            DECL_FIELD_ABI_IGNORED.
            * tree.h (DECL_FIELD_ABI_IGNORED): Define.
            * calls.h (cxx17_empty_base_field_p): Change into a temporary
            macro, check DECL_FIELD_ABI_IGNORED flag with no
"no_unique_address"
            attribute.
            * calls.c (cxx17_empty_base_field_p): Remove.
            * tree-streamer-out.c (pack_ts_decl_common_value_fields): Handle
            DECL_FIELD_ABI_IGNORED.
            * tree-streamer-in.c (unpack_ts_decl_common_value_fields):
Likewise.
            * lto-streamer-out.c (hash_tree): Likewise.
            * config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Rename
            cxx17_empty_base_seen to empty_base_seen, change type to int *,
            adjust recursive calls, use DECL_FIELD_ABI_IGNORED instead of
            cxx17_empty_base_field_p, if "no_unique_address" attribute is
            present, propagate that to the caller too.
            (rs6000_discover_homogeneous_aggregate): Adjust
            rs6000_aggregate_candidate caller, emit different diagnostics
            when c++17 empty base fields are present and when empty
            [[no_unique_address]] fields are present.
            * config/rs6000/rs6000.c (rs6000_special_round_type_align,
            darwin_rs6000_special_round_type_align): Skip
DECL_FIELD_ABI_IGNORED
            fields.

            * class.c (build_base_field): Set DECL_FIELD_ABI_IGNORED on C++17
empty
            base artificial FIELD_DECLs.
            (layout_class_type): Set DECL_FIELD_ABI_IGNORED on empty class
            field_poverlapping_p FIELD_DECLs.

            * lto-common.c (compare_tree_sccs_1): Handle
DECL_FIELD_ABI_IGNORED.

            * g++.target/powerpc/pr94707-1.C: New test.
            * g++.target/powerpc/pr94707-2.C: New test.
            * g++.target/powerpc/pr94707-3.C: New test.
            * g++.target/powerpc/pr94707-4.C: New test.
            * g++.target/powerpc/pr94707-5.C: New test.
            * g++.target/powerpc/pr94707-4.C: New test.

  parent reply	other threads:[~2020-04-29  7:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22  7:14 [Bug target/94707] New: [8/9/10 " redi at gcc dot gnu.org
2020-04-22  7:15 ` [Bug target/94707] " redi at gcc dot gnu.org
2020-04-22  8:53 ` jakub at gcc dot gnu.org
2020-04-22  8:59 ` jakub at gcc dot gnu.org
2020-04-22  9:13 ` jakub at gcc dot gnu.org
2020-04-22 10:12 ` jakub at gcc dot gnu.org
2020-04-22 12:11 ` jakub at gcc dot gnu.org
2020-04-22 13:32 ` jakub at gcc dot gnu.org
2020-04-22 16:08 ` wschmidt at gcc dot gnu.org
2020-04-22 16:08 ` wschmidt at gcc dot gnu.org
2020-04-22 16:11 ` wschmidt at gcc dot gnu.org
2020-04-22 16:33 ` jakub at gcc dot gnu.org
2020-04-22 16:56 ` redi at gcc dot gnu.org
2020-04-22 18:16 ` pinskia at gcc dot gnu.org
2020-04-23  8:00 ` cvs-commit at gcc dot gnu.org
2020-04-23  8:08 ` [Bug target/94707] [8/9 " jakub at gcc dot gnu.org
2020-04-23 12:44 ` cvs-commit at gcc dot gnu.org
2020-04-23 14:38 ` jakub at gcc dot gnu.org
2020-04-29  7:06 ` cvs-commit at gcc dot gnu.org [this message]
2021-11-05 23:18 ` timturnerc at yahoo dot com

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=bug-94707-4-fFtBZNbBcY@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).