[Bug target/66754] [4.9/5/6] gcc.dg/builtin-apply2.c aborts with -m32 -mregparm=3

["mikpelinux at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Martin Liška from comment #1)
> That means, libc hasn't been built with the option and it explain the abort.
> Am I right?

No, libc isn't involved in the code leading up to the abort.

The abort can also be triggered by adding attribute((regparm(3))) to the foo()
and bar() function definitions and compiling with -m32 -O0 w/o -mregparm=3.  In
that case however there is also a warning:

builtin-apply2.c: In function 'bar':
builtin-apply2.c:38:19: warning: passing argument 1 of '__builtin_apply' from
incompatible pointer type [-Wincompatible-pointer-types]
   __builtin_apply(foo, __builtin_apply_args(), STACK_ARGUMENTS_SIZE);
                   ^
builtin-apply2.c:38:19: note: expected 'void (*)()' but argument is of type
'void (__attribute__((__regparm__(3))) *)(char *, double,  double,  double, 
int'
>From gcc-bugs-return-491391-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 03 16:07:03 2015
Return-Path: <gcc-bugs-return-491391-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 48144 invoked by alias); 3 Jul 2015 16:07:03 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 48082 invoked by uid 48); 3 Jul 2015 16:06:59 -0000
From: "jgreenhalgh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66755] New: [ARM] TARGET_ASM_OUTPUT_MI_THUNK should be rewritten to an RTL implementation
Date: Fri, 03 Jul 2015 16:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jgreenhalgh at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone cf_gcchost cf_gcctarget
Message-ID: <bug-66755-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg00281.txt.bz2
Content-length: 1212

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf755

            Bug ID: 66755
           Summary: [ARM] TARGET_ASM_OUTPUT_MI_THUNK should be rewritten
                    to an RTL implementation
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jgreenhalgh at gcc dot gnu.org
                CC: ramana at gcc dot gnu.org
  Target Milestone: ---
              Host: *-*-*
            Target: arm*-*-*

The ARM target has some technical debt, in that it has not updated
TARGET_ASM_OUTPUT_MI_THUNK to an RTL implementation, it continues to write
directly to the assembler file.

For ARM this can mean going through the heavyweight generic thunks
implementation, rather than potentially putting out something much lighter. The
generic implementation is very rarely tested now, as most (heavily tested)
targets define TARGET_ASM_CAN_OUTPUT_MI_THUNK to
hook_bool_const_tree_hwi_hwi_const_tree_true .

See pr66666 for an example where this caused an issue for the ARM target with
copy constructors wrapped through a virtual function call.