[Bug target/94711] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[Bug target/94711] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[jakub at gcc dot gnu.org]

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

            Bug ID: 94711
           Summary: [8/9/10 Regression] class with empty base passed
                    incorrectly with -std=c++17 on arm
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: ABI, wrong-code
          Severity: blocker
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org, ktkachov at gcc dot gnu.org,
                    matmal01 at gcc dot gnu.org, mpolacek at gcc dot gnu.org,
                    rearnsha at gcc dot gnu.org, redi at gcc dot gnu.org,
                    rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org
        Depends on: 94383
            Blocks: 94704, 94706, 94707
  Target Milestone: ---
            Target: aarch64-*-linux

+++ This bug was initially created as a clone of Bug #94383 +++

The same issue applies to 32-bit ARM too.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
[Bug 94383] [8/9/10 Regression] class with empty base passed incorrectly with
-std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
[Bug 94704] [8/9/10 Regression] class with empty base passed incorrectly with
-std=c++17 on s390x/s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706
[Bug 94706] [8/9/10 Regression] class with empty base passed incorrectly with
-std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
[Bug 94707] [8/9/10 Regression] class with empty base passed incorrectly with
-std=c++17 on powerpc64le

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Blocks|94704, 94706, 94707         |
             Target|aarch64-*-linux             |arm-*-linux
   Target Milestone|---                         |10.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
[Bug 94704] [8/9/10 Regression] class with empty base passed incorrectly with
-std=c++17 on s390x/s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706
[Bug 94706] [8/9/10 Regression] class with empty base passed incorrectly with
-std=c++17 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
[Bug 94707] [8/9/10 Regression] class with empty base passed incorrectly with
-std=c++17 on powerpc64le

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711
Bug 94711 depends on bug 94383, which changed state.

Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-04-23
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, what exactly needs changing on ARM?
>From quick skimming, maybe arm_return_in_memory, very likely
aapcs_vfp_sub_candidate, and maybe arm_needs_doubleword_align.
What about comp_not_to_clear_mask_str_un ?

Note, we'd like to do 10.1-rc1 as early possible and this PR is one of the last
two remaining blockers.

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Matthew Malcomson <matmal01@gcc.gnu.org>:

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

commit r10-8013-ga5bff8af0a68d039e1586087639c86d6931c9b81
Author: Matthew Malcomson <matthew.malcomson@arm.com>
Date:   Tue Apr 28 15:38:43 2020 +0100

    [Arm] Account for C++17 artificial field determining Homogeneous Aggregates

    In C++14, an empty class deriving from an empty base is not an
    aggregate, while in C++17 it is.  In order to implement this, GCC adds
    an artificial field to such classes.

    This artificial field has no mapping to Fundamental Data Types in the
    Arm PCS ABI and hence should not count towards determining whether an
    object can be passed using the vector registers as per section
    "7.1.2 Procedure Calling" in the arm PCS
   
https://developer.arm.com/docs/ihi0042/latest?_ga=2.60211309.1506853196.1533541889-405231439.1528186050

    This patch avoids counting this artificial field in
    aapcs_vfp_sub_candidate, and hence calculates whether such objects
    should be passed in vector registers in the same manner as C++14 (where
    the artificial field does not exist).

    Before this change, the test below would pass the arguments to `f` in
    general registers.  After this change, the test passes the arguments to
    `f` using the vector registers.

    The new behaviour matches the behaviour of `armclang`, and also matches
    the GCC behaviour when run with `-std=gnu++14`.

    > gcc -std=gnu++17 -march=armv8-a+simd -mfloat-abi=hard test.cpp

    ``` test.cpp
    struct base {};

    struct pair : base
    {
      float first;
      float second;
      pair (float f, float s) : first(f), second(s) {}
    };

    void f (pair);
    int main()
    {
      f({3.14, 666});
      return 1;
    }
    ```

    We add a `-Wpsabi` warning to catch cases where this fix has changed the
ABI for
    some functions.  Unfortunately this warning is not emitted twice for
multiple
    calls to the same function, but I feel this is not much of a problem and
can be
    fixed later if needs be.

    (i.e. if `main` called `f` twice in a row we only emit a diagnostic for the
    first).

    Testing:
        Bootstrapped and regression tested on arm-linux.
        This change fixes the struct-layout-1 tests Jakub added
        https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544204.html
        Regression tested on arm-none-eabi.

    gcc/ChangeLog:

    2020-04-28  Matthew Malcomson  <matthew.malcomson@arm.com>
                Jakub Jelinek  <jakub@redhat.com>

            PR target/94711
            * config/arm/arm.c (aapcs_vfp_sub_candidate): Account for C++17
empty
            base class artificial fields.
            (aapcs_vfp_is_call_or_return_candidate): Warn when PCS ABI
            decision is different after this fix.

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[matmal01 at gcc dot gnu.org]

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

--- Comment #3 from Matthew Malcomson <matmal01 at gcc dot gnu.org> ---
This has been fixed by.
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544625.html

In the email linked above I mentioned another problem using `-mabi=apcs-gnu`.
Since that ABI is obsolete (Kyrylo pointed that out to me) I don't think that
problem should hold up GCC10.

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[matmal01 at gcc dot gnu.org]

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

Matthew Malcomson <matmal01 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #4 from Matthew Malcomson <matmal01 at gcc dot gnu.org> ---
Resolving since the issue with the obsolete ABI is different to this ticket.

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[timturnerc at yahoo dot com]

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

Tim Turner <timturnerc at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timturnerc at yahoo dot com

--- Comment #5 from Tim Turner <timturnerc at yahoo dot com> ---
[gdb/breakpoints] Handle glibc with debuginfo in
create_exception_master_breakpoint
    http://www-look-4.com/computers/huawei-computers/
    The test-case nextoverthrow.exp is failing on targets with unstripped libc.
    https://komiya-dental.com/category/services/
    This is a regression since commit 1940319c0ef "[gdb] Fix internal-error in
    process_event_stop_test".
    http://www.iu-bloomington.com/category/services/
    The problem is that this code in create_exception_master_breakpoint:
    ...
          for (objfile *sepdebug = obj->separate_debug_objfile;
https://waytowhatsnext.com/category/services/
               sepdebug != nullptr; sepdebug =
sepdebug->separate_debug_objfile)
            if (create_exception_master_breakpoint_hook (sepdebug))
    ... http://www.wearelondonmade.com/computers/car-computers/
    iterates over all the separate debug object files, but fails to handle the
    case that obj itself has the debug info we're looking for.
    http://www.jopspeech.com/health/nvidia-rtx-2060/
    Fix this by using the separate_debug_objfiles () range instead, which does
    iterate both over obj and the obj->separate_debug_objfile chain.
http://joerg.li/health/xiaomi/

    Tested on x86_64-linux.
    http://connstr.net/computers/chargers-tech/
    gdb/ChangeLog:
[gdb/breakpoints] Handle glibc with debuginfo in
create_exception_master_breakpoint
    http://embermanchester.uk/computers/video-conversation/
    The test-case nextoverthrow.exp is failing on targets with unstripped libc.
    http://www.slipstone.co.uk/computers/isofix/
    This is a regression since commit 1940319c0ef "[gdb] Fix internal-error in
    process_event_stop_test".
http://www.logoarts.co.uk/computers/printer-types/

    The problem is that this code in create_exception_master_breakpoint:
    ... http://www.acpirateradio.co.uk/technology/facetime/
          for (objfile *sepdebug = obj->separate_debug_objfile;
               sepdebug != nullptr; sepdebug =
sepdebug->separate_debug_objfile)
            if (create_exception_master_breakpoint_hook (sepdebug))
http://www.compilatori.com/computers/smartphones/
    ...
    iterates over all the separate debug object files, but fails to handle the
    case that obj itself has the debug info we're looking for.
     https://www.webb-dev.co.uk/category/services/
    Fix this by using the separate_debug_objfiles () range instead, which does
    iterate both over obj and the obj->separate_debug_objfile chain.

    Tested on x86_64-linux.

    gdb/ChangeLog: