From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-266606-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 1924 invoked by alias); 15 Nov 2008 09:27:39 -0000
Received: (qmail 24346 invoked by uid 48); 15 Nov 2008 09:26:26 -0000
Date: Sat, 15 Nov 2008 09:27:00 -0000
Subject: [Bug target/38130]  New: [4.4.0 regression]__builtin_alloca (vs IRA?)  testsuite failures on  mingw32
X-Bugzilla-Reason: CC
Message-ID: <bug-38130-4066@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "dannysmith at users dot sourceforge dot net" <gcc-bugzilla@gcc.gnu.org>
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
X-SW-Source: 2008-11/txt/msg01180.txt.bz2

Execution testcases c-torture/execute/920929-1.c and
c-torture/execute/built-in-setjmp.c began failing on mingw32 in late August,
coincident with merge of IRA into trunk. 

In both cases, the execution tests pass if -fno-ira is added to command line.

The problem appears to be in the call of the target stack-probing code
(__chkstk) in cygwin.asm from allocate_stack_worker instruction. __chkstk has
unusual calling convention, with the input argument as well as the
output passed in eax.

>>From i386.md:

(define_insn "allocate_stack_worker_32"
  [(set (match_operand:SI 0 "register_operand" "+a")
        (unspec_volatile:SI [(match_dup 0)] UNSPECV_STACK_PROBE))
   (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (match_dup 0)))
   (clobber (reg:CC FLAGS_REG))]
  "!TARGET_64BIT && TARGET_STACK_PROBE"
  "call\t___chkstk"
  [(set_attr "type" "multi")
   (set_attr "length" "5")])


The relevant part of the output of 
gcc  -S  -O -funroll-all-loops  920929-1.c -o 920929-1-IRA.s:

f:
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ebx
        subl    $4, %esp
        movl    8(%ebp), %edx
        call    ___chkstk
        leal    15(%esp), %ecx
        andl    $-16, %ecx
        testl   %edx, %edx
        ...

__chkstk allocates only 1 byte and the code segfault on the first
attempt to assign a double to the allocated array.


The output, with -fno-ira 
gcc  -S  -O -funroll-all-loops -fno-ira 920929-1.c -o 920929-1-NOIRA.s:
_f:
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ebx
        subl    $4, %esp
        movl    8(%ebp), %ebx
        leal    30(,%ebx,8), %eax
        andl    $-16, %eax
        call    ___chkstk
        leal    15(%esp), %eax
        movl    %eax, %edx
        andl    $-16, %edx
        testl   %ebx, %ebx

__chkstk allocates 816 bytes


A comparison of built-in-setjmp.c with amd without -fno-ira switch also shows
incorrect input to __chkstk

Probably related to these failure is miscompilation of the C++ compiler
code cp/pt.c, which segfaults following call to alloca in
process_partial_specialization when building libstdc++. If cp/pt.c is
compiled with -fno-ira, libstdc++ builds successfully.

Danny


-- 
           Summary: [4.4.0 regression]__builtin_alloca (vs IRA?)  testsuite
                    failures on  mingw32
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dannysmith at users dot sourceforge dot net
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130