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

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

[julia.koval at intel dot com]

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

            Bug ID: 66754
           Summary: [4.9/5/6] gcc.dg/builtin-apply2.c aborts with -m32
                    -mregparm=3
           Product: gcc
           Version: 4.9.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: julia.koval at intel dot com
  Target Milestone: ---

Reproduce:
gcc builtin-apply2.c -m32 -mregparam=3

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

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Hello.

Correct command line:
gcc builtin-apply2.c -m32 -mregparm=3

BT:
Program received signal SIGABRT, Aborted.
0xf7fd8d40 in __kernel_vsyscall ()
(gdb) bt
#0  0xf7fd8d40 in __kernel_vsyscall ()
#1  0xf7e10eb6 in raise () from /lib/libc.so.6
#2  0xf7e124b1 in abort () from /lib/libc.so.6
#3  0x08048476 in foo (name=0xf7f99de0 <environ> "\f\316\377\377",
d=-2.6030469739081194e-220, e=-1.1363900720223263e-307,
f=2.8014219794078323e+283, g=-12908) at
/home/marxin/Programming/gcc3/gcc/testsuite/gcc.dg/builtin-apply2.c:33
#4  0x08048535 in bar (name=0x8048630 "eeee") at
/home/marxin/Programming/gcc3/gcc/testsuite/gcc.dg/builtin-apply2.c:38
#5  0x0804859d in main () at
/home/marxin/Programming/gcc3/gcc/testsuite/gcc.dg/builtin-apply2.c:43


As I've been reading GCC documentation:

Warning: if you use this switch, and num is nonzero, then you must build all
modules with the same value, including any libraries.  This includes the system
libraries and startup modules.

That means, libc hasn't been built with the option and it explain the abort.
Am I right?

Martin
>From gcc-bugs-return-491387-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 03 15:50:20 2015
Return-Path: <gcc-bugs-return-491387-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16264 invoked by alias); 3 Jul 2015 15:50:20 -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 16237 invoked by uid 48); 3 Jul 2015 15:50:16 -0000
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/66744] [6 Regression] Bootstrap failure due to conflicting access() on i686-w64-mingw32
Date: Fri, 03 Jul 2015 15:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin 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: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-66744-4-WdFD2vdPgm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66744-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66744-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg00277.txt.bz2
Content-length: 299

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 35905
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35905&action=edit
Suggested patch

Can you please test that the patch works?

Thanks,
Martin
>From gcc-bugs-return-491388-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 03 15:52:51 2015
Return-Path: <gcc-bugs-return-491388-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20649 invoked by alias); 3 Jul 2015 15:52:51 -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 20579 invoked by uid 48); 3 Jul 2015 15:52:44 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66742] abort on sorting list with custom compiler that is not stateless
Date: Fri, 03 Jul 2015 15:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66742-4-ZjSJsEtxTr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66742-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66742-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/msg00278.txt.bz2
Content-length: 300

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
A candidate patch has been posted to
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00217.html

With that fix your testcase segfaults, because you allocate n bytes not
n*sizeof(Tp).

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

[mikpelinux at gmail dot com]

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.

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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-07-03
   Target Milestone|---                         |6.0
     Ever confirmed|0                           |1

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

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
extern void foo (char *name, double d, double e, double f, int g);

void
bar (char *name, ...)
{
  __builtin_apply(foo, __builtin_apply_args(), 64);
}

is miscompiled.  IA MCU passes everything on stack for vararg functions.

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

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Doc says:

Using the built-in functions described below, you can record the
arguments a function received, and call another function with the same
arguments, without knowing the number or types of the arguments.

 You can also record the return value of that function call, and later
return that value, without knowing what data type the function tried to
return (as long as your caller expects that data type).

 However, these built-in functions may interact badly with some
sophisticated features or other extensions of the language.  It is,
therefore, not recommended to use them outside very simple functions
acting as mere forwarders for their arguments.

We have

extern void foo (char *name, double d, double e, double f, int g);

void
bar (char *name, ...)
{
  __builtin_apply(foo, __builtin_apply_args(), 64);
}

calling foo with bar's arguments won't work for IA MCU since all bar's
arguments are passed on stack and some foo's arguments are passed in
registers.

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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
Here is a testcase without -mregparm=N:

[hjl@gnu-tools-1 pr66754]$ cat x.i
extern void abort(void);

typedef double __v2df __attribute__ ((__vector_size__ (16)));
__v2df val;

void
foo (char *name, __v2df x, __v2df y, __v2df z)
{
  if (!__builtin_ia32_comisdeq (z, val))
    abort();
}

void
bar (char *name, ...)
{
  __builtin_apply(foo, __builtin_apply_args(), 64);
}

int main(void)
{
  __v2df x = { 3.1, 3.2 };
  __v2df y = { 2.1, 5.2 };
  __v2df z = { 1.1, 7.2 };
  val = z;
  bar("eeee", x, y, z);

  return 0;
}
[hjl@gnu-tools-1 pr66754]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -m32 -msse2 -S -o x.s x.i
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -g -m32 -msse2 -o x x.s
./x
Makefile:12: recipe for target 'all' failed
make: *** [all] Aborted (core dumped)
[hjl@gnu-tools-1 pr66754]$ 

The vector parameters have the same issue.  All arguments of vararg
functions argument are passed on stack while the first 3 vector arguments
are passed in registers for non-vararg functions.