[Bug c/66275] New: __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[Bug c/66275] New: __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[peter at cordes dot ca]

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

            Bug ID: 66275
           Summary: __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc
                    generates incorrect code
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: peter at cordes dot ca
  Target Milestone: ---

Created attachment 35615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35615&action=edit
main.c, asm-test.h, and less-stripped-down intrin-pinsrw.c

gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2

w64 mingw gcc is mis-compiling functions declared with
__attribute__((sysv_abi)).  Registers holding args are getting clobbered with
temp values, but then used as if they still held function args.

This code is mis-compiled by
x86_64-w64-mingw32-gcc -g -Wall -funroll-loops -O3 -std=gnu11 intrin-pinsrw.c
... main.c


cat > intrin-pinsrw.c <<"EOF"
#include <emmintrin.h>
#include <stdint.h>

#define SYSV_ABI __attribute__((sysv_abi))


union wordbytes { uint16_t w; uint8_t b[2]; };

void SYSV_ABI rs_process_pinsrw_intrin(void* dstvoid, const void* srcvoid,
size_t size, const uint32_t* LH)
{
        const uint64_t *src = srcvoid;
        __m128i d, l, h;
        __m128i *dst = dstvoid;

        for (size_t i = 0; i < size/sizeof(d) ; i+=1) {
                uint64_t s0 = src[i*2 + 0];

#define LO(x) ((uint8_t)x)
#define HI(x) (( (union wordbytes) ((uint16_t)x) ).b[1])

                l = _mm_cvtsi32_si128( LH[      LO(s0)] );
                h = _mm_cvtsi32_si128( LH[256 + HI(s0)] );
                s0 >>= 16;
 // commented-out code that wasn't needed to trigger the bug
                d = _mm_xor_si128(l, h);
                d = _mm_xor_si128(d, dst[i]);
                _mm_store_si128(&dst[i], d);
        }
}
EOF
x86_64-w64-mingw32-gcc -Wall -funroll-loops -O3 -std=gnu11 intrin-pinsrw.c -S

search for "si" in the output, and notice how %rsi is used as a pointer to load
src data, but also used as a tmp.

.L5:
        movq    (%rsi,%r10), %rdx
        movzbl  %dl, %esi              ## clobbered here
        movzbl  %dh, %eax
        movd    (%rcx,%rsi,4), %xmm8
        movd    1024(%rcx,%rax,4), %xmm9
        pxor    %xmm8, %xmm9
        pxor    (%rdi,%r10), %xmm9
        movaps  %xmm9, (%rdi,%r10)
        movq    16(%rsi,%r10), %rdx    ## not restored after use as a tmp
        ...

%rdi is also clobbered and then used as a pointer again, later in the loop.

In the AMD64 sysv ABI, %rdi holds the 1st arg, %rsi holds the 2nd, %rdx holds
the 3rd, and %rcx holds the 4th.  

(and see attached for a less-stripped-down and a main.c to call it)

-funroll-loops is needed to trigger the problem on this reduced test-case.  It
might not be needed with a bigger function that would run out of registers
without unrolling.  Even the less-stripped-down version in the attachment runs
fine under WINE when compiled without -funroll-loops.


If testing by actually running the code with WINE, note that wine and wine64
seem to have incompatible requirements for the contents of ~/.wine.  I
eventually made a wrapper like:
 #!/bin/sh
 WINEPREFIX=~/.wine64 /usr/bin/wine64 "$@"


For anyone curious why I had this code in the first place:
This code is from par2 (the reed-solomon inner-loop that multiplies a buffer of
GF16 values by a constant factor, using a pre-computed lookup table).  See
https://github.com/pcordes/par2-asm-experiments

 I have some functions written directly in asm.  They're written for the Linux
SysV ABI.  I could make an alternate entry point for win ABI, with extra mov
instructions, and push/pop the extra regs that are callee-save in MS-ABI but
not SYSV.  Or I could just declare their prototypes with
__attribute__((sysv_abi)), and gcc will call them properly.

I tried making a version of the function using intrinsics, so of course my test
harness needs to call it, too.  Since I call via function pointer, I had to
declare it the same way.

It was working fine until a recent change to the code of the function.  Old
version that didn't tickle this bug (partial diff):

-       uint64_t s0, s1;
-       for (size_t i = 0; i < size ; i+=16) {
-               s0 = *((uint64_t*) ((char*)srcvoid + i));       // byte address
math, 64bit load
-               s1 = *((uint64_t*) ((char*)srcvoid+8 + i));     // byte address
math, 64bit load

-               d = _mm_xor_si128(d, *(dst+i/16));
-               _mm_store_si128(dst+i/16, d);

I wrote it in that ugly way initially because I was basically porting my ASM
code to intrinsics.  BTW, the results were terrible.  gcc generates
ridiculously bad code for getting the src bytes into zero-extended 64bit regs,
for use as scaled-offsets in an address, compared to

movzx %dl, %eax
movxz %dh, %ebx
shr   $16, %rdx
use rax/rbx
movzx %dl, %eax
movxz %dh, %ebx
shr   $16, %rdx
use rax/rbx
 ...

 gcc never just shifts the reg holding src data.  Instead if copies, and shifts
the copy by $16, $32, or $48.

 gcc's code is about 35% slower than the hand-written version, even letting it
use avx so it doesn't emit useless movdqa instructions when it doesn't realize
that an old value is no longer needed.  Just un-comment the mostly-commented
loop body in the testcase (attachment version).

 Anyway, slow code is off-topic, this bug is about wrong code!

[Bug rtl-optimization/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-05-25
          Component|c                           |rtl-optimization
   Target Milestone|---                         |4.9.3
     Ever confirmed|0                           |1

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
This problem can also be seen on x86_64-linux with gcc-6.0 and

gcc -O3 -funroll-loops -mabi=ms

In _.ce3 dump, we have following sequence:

  ...
   73: L73:
   72: NOTE_INSN_BASIC_BLOCK 5
   44: dx:DI=[si:DI+ax:DI]
      REG_EQUIV [si:DI+ax:DI]
   45: r9:DI=zero_extend(dx:QI)
   46: NOTE_INSN_DELETED
   47: xmm0:V4SI=vec_merge(vec_duplicate([r9:DI*0x4+cx:DI]),const_vector,0x1)
      REG_DEAD r9:DI
   50: NOTE_INSN_DELETED
   51: NOTE_INSN_DELETED
   52: dx:DI=zero_extract(dx:DI,0x8,0x8)
   53: NOTE_INSN_DELETED
   54: NOTE_INSN_DELETED
   55:
xmm1:V4SI=vec_merge(vec_duplicate([dx:DI*0x4+cx:DI+0x400]),const_vector,0x1)
      REG_DEAD dx:DI
   56: xmm0:V2DI=xmm0:V2DI^xmm1:V2DI
      REG_DEAD xmm1:V2DI
   57: xmm0:V2DI=xmm0:V2DI^[di:DI+ax:DI]
      REG_EQUIV [di:DI+ax:DI]
   58: [di:DI+ax:DI]=xmm0:V2DI
      REG_DEAD xmm0:V2DI
  183: dx:DI=[si:DI+ax:DI+0x10]
      REG_EQUIV [si:DI+ax:DI+0x10]
  ...

Please note (insn 183), a consumer of SI register.

In _.rnreg dump, the above sequence is transformed to:

  ...
   73: L73:
   72: NOTE_INSN_BASIC_BLOCK 5
   44: dx:DI=[si:DI+r10:DI]
      REG_EQUIV [si:DI+ax:DI]
   45: si:DI=zero_extend(dx:QI)
   46: NOTE_INSN_DELETED
   47: xmm8:V4SI=vec_merge(vec_duplicate([si:DI*0x4+cx:DI]),const_vector,0x1)
      REG_DEAD r9:DI
   50: NOTE_INSN_DELETED
   51: NOTE_INSN_DELETED
   52: ax:DI=zero_extract(dx:DI,0x8,0x8)
   53: NOTE_INSN_DELETED
   54: NOTE_INSN_DELETED
   55:
xmm9:V4SI=vec_merge(vec_duplicate([ax:DI*0x4+cx:DI+0x400]),const_vector,0x1)
      REG_DEAD dx:DI
   56: xmm8:V2DI=xmm8:V2DI^xmm9:V2DI
      REG_DEAD xmm1:V2DI
   57: xmm8:V2DI=xmm8:V2DI^[di:DI+r10:DI]
      REG_EQUIV [di:DI+ax:DI]
   58: [di:DI+r10:DI]=xmm8:V2DI
      REG_DEAD xmm0:V2DI
  183: dx:DI=[si:DI+r10:DI+0x10]
      REG_EQUIV [si:DI+ax:DI+0x10]
  ...

So, (insn 45) now indeed clobbers SI register that is needed by (insn 183).

Confirmed as RTL optimization problem, specifically, a rnreg pass problem.
>From gcc-bugs-return-487216-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 25 11:20:35 2015
Return-Path: <gcc-bugs-return-487216-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 107982 invoked by alias); 25 May 2015 11:20:35 -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 107934 invoked by uid 48); 25 May 2015 11:20:31 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler
Date: Mon, 25 May 2015 11:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-65979-4-Fi1iIX3b7h@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65979-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65979-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-05/txt/msg02056.txt.bz2
Content-length: 1621

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

--- Comment #27 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #25)
> So, if I understand correctly ...
> - 4.9.something doesn't bootstrap because of something unknown

It doesn't bootstrap because the D compiler fails the compare test. This
happens both on gcc-4.8 and gcc-4.9, here's the excerpt from 4.8 [1]:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/d/ctfeexpr.dmd.o differs

> - 5.something doesn't bootstrap because of c#19
>
> ... right?

Yeah, that seems to be unrelated. Sorry for the confusion. I assumed those were
the same.

> Adrian, which compiler do you use to build the SH native compiler(s)?
> Last time I've tried to do a native GCC 5 build on the SH4 debian box,
> vanilla GCC would not build and I gave up.  Sorry for my impatience.

gcc-4.9.2_10 which is SVN_r218987 (20141220).

> > But in any case, I am super happy you guys are fixing this. I will be back
> > in Japan in October, so if I have a chance to meet either of you, I owe you
> > some beer/sake/wine etc :).
>
> Will trade beer for Mohnkuchen.
> Will trade many other things for an SH4A-X4 8-core board with 2+ GB RAM.

Heh. I could try to talk to Nobuhiro again. Maybe he has some ideas where to
get hold of faster SH4 hardware.

Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.8&arch=sh4&ver=4.8.4-2&stamp\x1432515052

[Bug rtl-optimization/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Target|                            |x86_64-w64-mingw32
   Target Milestone|4.9.3                       |---

[Bug rtl-optimization/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-w64-mingw32          |

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
This is RTL infrastructure problem, not target specific.
>From gcc-bugs-return-487279-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 26 11:10:13 2015
Return-Path: <gcc-bugs-return-487279-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24413 invoked by alias); 26 May 2015 11:10:12 -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 24058 invoked by uid 48); 26 May 2015 11:09:54 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/66288] parallelized loop vectorized with runtime alias check
Date: Tue, 26 May 2015 11:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: vries 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:
Message-ID: <bug-66288-4-5dtiPYpFbV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66288-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66288-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-05/txt/msg02119.txt.bz2
Content-length: 467

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

--- Comment #2 from vries at gcc dot gnu.org ---
Before parallelization, we have:
...
  doubleD.32 dataD.1837[1000];
  doubleD.32 resultsD.1836[1000];

  ...

  # VUSE <.MEM_19>
  _6 = dataD.1837[idx_18];
  _7 = _6 * 1.2199999999999999289457264239899814128875732421875e+1;
  # .MEM_8 = VDEF <.MEM_19>
  resultsD.1836[idx_18] = _7;
...

We could annotate these memory references with dependence clique information.

[Bug target/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-w64-mingw32-gcc
                 CC|                            |ktietz at gcc dot gnu.org,
                   |                            |ubizjak at gmail dot com
          Component|rtl-optimization            |target

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
At the end of the day, this is target problem.

From _.dfinit dump:

;;  entry block defs     1 [dx] 2 [cx] 6 [bp] 7 [sp] 16 [argp] 20 [frame] 21
[xmm0] 22 [xmm1] 23 [xmm2] 24 [xmm3] 25 [xmm4] 26 [xmm5] 27 [xmm6] 28 [xmm7] 37
[r8] 38 [r9]

Registers DI and SI should also be listed here.

I have a patch.
>From gcc-bugs-return-487750-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 01 19:55:56 2015
Return-Path: <gcc-bugs-return-487750-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10721 invoked by alias); 1 Jun 2015 19:55:56 -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 10678 invoked by uid 48); 1 Jun 2015 19:55:53 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code
Date: Mon, 01 Jun 2015 19:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
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: attachments.created
Message-ID: <bug-66275-4-yMnv5XVWKq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66275-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66275-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-06/txt/msg00082.txt.bz2
Content-length: 344

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
Created attachment 35670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35670&action=edit
Proposed patch

Patch that fixes ix86_function_arg_regno_p and ix86_function_value_regno_p to
follow the ABI attribute.
>From gcc-bugs-return-487751-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 01 19:59:15 2015
Return-Path: <gcc-bugs-return-487751-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 41328 invoked by alias); 1 Jun 2015 19:59:15 -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 41271 invoked by uid 48); 1 Jun 2015 19:59:12 -0000
From: "chrisloonam at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug objc/66367] New: Objective-C Variadic Method Not Working
Date: Mon, 01 Jun 2015 19:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: objc
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chrisloonam at gmail dot com
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 target_milestone attachments.created
Message-ID: <bug-66367-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-06/txt/msg00083.txt.bz2
Content-length: 1271

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

            Bug ID: 66367
           Summary: Objective-C Variadic Method Not Working
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: objc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chrisloonam at gmail dot com
  Target Milestone: ---

Created attachment 35671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35671&action=edit
The source file that is generating the error, pre-compiled with gcc -save-temps

This error is being experienced on GCC 5.1.0 on an Arch Linux system. 

When making a variadic method like the following

    - (void)method:(id)o, ...
    {
        int c = 1;
        va_list list;
        va_start(list, o);
        while (va_arg(list, id))
            c++;
        va_end(list);
    }
the compiler reports the following error

    error: expected expression before ‘id’
If `id` is replaced with `void *`, the same error occurs.

Attached is the pre-compiled source of the file where you can find this code.
The file succssfully compiles in clang, leading me to believe that this is in
fact a bug and not a programmer error.
>From gcc-bugs-return-487752-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 01 20:02:37 2015
Return-Path: <gcc-bugs-return-487752-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 52545 invoked by alias); 1 Jun 2015 20:02:37 -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 52479 invoked by uid 48); 1 Jun 2015 20:02:32 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code
Date: Mon, 01 Jun 2015 20:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-66275-4-QXMjDRpfdU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66275-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66275-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-06/txt/msg00084.txt.bz2
Content-length: 1013

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

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
Kai, can you please test the patch on x86_64-w64-mingw32 ?

The patch has been bootstrapped and regression tested on x86_64-linux-gnu, but
there is the comment which I'm not sure still applies:

   /* TODO: The function should depend on current function ABI but
      builtins.c would need updating then. Therefore we use the
      default ABI.  */

The patch fixes ix86_function_arg_regno_p and ix86_function_value_regno_p to
follow the ABI attribute. So, if there is ABI attribute specified, it won't
just change mid-compilation. If cfun is non-NULL, we can look into
cfun->machine->call_abi, to determine current ABI.

With the proposed patch, we get:

;;  entry block defs     0 [ax] 1 [dx] 2 [cx] 4 [si] 5 [di] 6 [bp] 7 [sp] 16
[argp] 20 [frame] 21 [xmm0] 22 [xmm1] 23 [xmm2] 24 [xmm3] 25 [xmm4] 26 [xmm5]
27 [xmm6] 28 [xmm7] 37 [r8] 38 [r9]

And AFAICS the assembly looks correct.
>From gcc-bugs-return-487753-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 01 21:27:09 2015
Return-Path: <gcc-bugs-return-487753-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 56887 invoked by alias); 1 Jun 2015 21:27:09 -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 56811 invoked by uid 48); 1 Jun 2015 21:27:05 -0000
From: "doko at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/66368] New: [5 Regression] go tool crashes on powerpc-linux-gnu
Date: Mon, 01 Jun 2015 21:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: doko at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
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
Message-ID: <bug-66368-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-06/txt/msg00085.txt.bz2
Content-length: 2194

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

            Bug ID: 66368
           Summary: [5 Regression] go tool crashes on powerpc-linux-gnu
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: doko at gcc dot gnu.org
                CC: cmang at google dot com
  Target Milestone: ---

"go version" on powerpc-linux-gnu works with the 5.1 release candidate, but
crashes with the 5.1.0 release, and the current branch.

reverting the changes made in PR65787 fixes the issue. Seen on Ubuntu 15.04 and
15.10 systems, however I can't reproduce this in Debian unstable. Same binutils
version, Debian has glibc-2.19, Ubuntu glibc-2.21.  It looks like I can't
reproduce this with a GCC trunk build on either platform. So I'm a bit lost ...

$ go version
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x3]

goroutine 16 [running]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

goroutine 0 [idle]:
panic during panic

goroutine 0 [idle]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_startpanic
        ../../../src/libgo/runtime/panic.c:100
runtime_throw
        ../../../src/libgo/runtime/panic.c:191
runtime_gogo
        ../../../src/libgo/runtime/proc.c:251
runtime_tracebackothers
        ../../../src/libgo/runtime/proc.c:767
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:139
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

[Bug target/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jun  3 15:46:41 2015
New Revision: 224094

URL: https://gcc.gnu.org/viewcvs?rev=224094&root=gcc&view=rev
Log:
        PR target/66275
        * config/i386/i386.c (ix86_function_arg_regno): Use ix86_cfun_abi
        to determine current function ABI.
        (ix86_function_value_regno_p): Ditto.

testsuite/ChangeLog:

        PR target/66275
        * gcc.target/i386/pr66275.c: New test.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr66275.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jun  8 18:41:24 2015
New Revision: 224244

URL: https://gcc.gnu.org/viewcvs?rev=224244&root=gcc&view=rev
Log:
        Backport from mainline:
        2015-06-03  Uros Bizjak  <ubizjak@gmail.com>

        PR target/66275
        * config/i386/i386.c (ix86_function_arg_regno): Use ix86_cfun_abi
        to determine current function ABI.
        (ix86_function_value_regno_p): Ditto.

testsuite/ChangeLog:

        Backport from mainline:
        2015-06-03  Uros Bizjak  <ubizjak@gmail.com>

        PR target/66275
        * gcc.target/i386/pr66275.c: New test.


Added:
    branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr66275.c
Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/i386/i386.c
    branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[uros at gcc dot gnu.org]

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

--- Comment #10 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jun  8 20:07:08 2015
New Revision: 224247

URL: https://gcc.gnu.org/viewcvs?rev=224247&root=gcc&view=rev
Log:
        Backport from mainline:
        2015-06-03  Uros Bizjak  <ubizjak@gmail.com>

        PR target/66275
        * config/i386/i386.c (ix86_function_arg_regno): Use ix86_cfun_abi
        to determine current function ABI.
        (ix86_function_value_regno_p): Ditto.

testsuite/ChangeLog:

        Backport from mainline:
        2015-06-03  Uros Bizjak  <ubizjak@gmail.com>

        PR target/66275
        * gcc.target/i386/pr66275.c: New test.


Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr66275.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/i386/i386.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[uros at gcc dot gnu.org]

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

--- Comment #11 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jun  8 20:59:07 2015
New Revision: 224249

URL: https://gcc.gnu.org/viewcvs?rev=224249&root=gcc&view=rev
Log:
        Backport from mainline:
        2015-06-03  Uros Bizjak  <ubizjak@gmail.com>

        PR target/66275
        * config/i386/i386.c (ix86_function_arg_regno): Use ix86_cfun_abi
        to determine current function ABI.
        (ix86_function_value_regno_p): Ditto.

testsuite/ChangeLog:

        Backport from mainline:
        2015-06-03  Uros Bizjak  <ubizjak@gmail.com>

        PR target/66275
        * gcc.target/i386/pr66275.c: New test.


Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr66275.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/66275] __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code

[ubizjak at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3388 bytes --]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|5.2                         |4.8.5

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed everywhere.
>From gcc-bugs-return-488417-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 08 22:02:25 2015
Return-Path: <gcc-bugs-return-488417-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 50602 invoked by alias); 8 Jun 2015 22:02:25 -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 50551 invoked by uid 48); 8 Jun 2015 22:02:21 -0000
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
Date: Mon, 08 Jun 2015 22:02: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: aldyh at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-66448-4-AooZYYHPH6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66448-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66448-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-06/txt/msg00749.txt.bz2
Content-length: 1055

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

--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 35718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5718&actioníit
Tentative patch for issue #3

Regarding the Darwin ld64 warnings, I found one instance of a local static DIE
with two DW_AT_location's during x86-64 Linux bootstrap.  It was for something
like this:

void foo()
{
static const char msg[] = "asdf";
}

What is happening is that local statics during late dwarf are traversed twice,
once in final.c via debug_hooks->function_decl (and its subsequent local), and
once  in toplev.c as we traverse FOR_EACH_DEFINED_SYMBOL with
debug_hooks->late_global_decl.

However, the multiple DW_AT_location's never made it to the object file (on
Linux anyhow) because resolve_addr() removed one of the duplicates.

I wonder if the attached patch catches anything else in Darwin, or if it
eliminates the warning altogether.

Iain, could you try this and see if it either ICEs, or if the warnings are
removed?