[Bug c/34621] New: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[Bug c/34621] New: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

gcc.c-torture/execute/va-arg-25.c fails at -Os with gcc version 4.3.0 20071230:

/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c: In
function 'main':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c:32:
internal compiler error: in expand_call, at calls.c:2785

The test pass with gcc version 4.0.1 (Apple Inc. build 5465) and gcc version
4.2.2.


-- 
           Summary: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32:
                    internal compiler error: in expand_call, at calls.c:2785
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug c/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-13 15:22 -------
Please provide preprocessed source, as this test pulls in system headers.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |WAITING


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

[Bug c/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2008-01-13 16:55 -------
> Please provide preprocessed source, as this test pulls in system headers.

Do you need the system headers for Darwin9?

# 1 "/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c"

# 1 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include/stdarg.h" 1 3 4

# 19 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include/stdarg.h" 3 4

typedef __builtin_va_list __gnuc_va_list;

# 91 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include/stdarg.h" 3 4

typedef __gnuc_va_list va_list;
# 125 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include/stdarg.h" 3 4

# 4 "/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c" 2

# 1 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h"
1 3 4

# 1
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/syslimits.h" 1
3 4

# 1 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h"
1 3 4

# 120
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h" 3 4

# 1 "/usr/include/limits.h" 1 3 4

# 23 "/usr/include/limits.h" 3 4

# 59 "/usr/include/limits.h" 3 4

# 1 "/usr/include/sys/cdefs.h" 1 3 4

# 28 "/usr/include/sys/cdefs.h" 3 4

# 66 "/usr/include/sys/cdefs.h" 3 4

# 105 "/usr/include/sys/cdefs.h" 3 4

# 128 "/usr/include/sys/cdefs.h" 3 4

# 155 "/usr/include/sys/cdefs.h" 3 4

# 166 "/usr/include/sys/cdefs.h" 3 4

# 180 "/usr/include/sys/cdefs.h" 3 4

# 198 "/usr/include/sys/cdefs.h" 3 4

# 253 "/usr/include/sys/cdefs.h" 3 4

# 288 "/usr/include/sys/cdefs.h" 3 4

# 298 "/usr/include/sys/cdefs.h" 3 4

# 322 "/usr/include/sys/cdefs.h" 3 4

# 387 "/usr/include/sys/cdefs.h" 3 4

# 410 "/usr/include/sys/cdefs.h" 3 4

# 456 "/usr/include/sys/cdefs.h" 3 4

# 64 "/usr/include/limits.h" 2 3 4

# 1 "/usr/include/machine/limits.h" 1 3 4

# 1 "/usr/include/i386/limits.h" 1 3 4

# 35 "/usr/include/i386/limits.h" 3 4

# 1 "/usr/include/i386/_limits.h" 1 3 4

# 24 "/usr/include/i386/_limits.h" 3 4

# 41 "/usr/include/i386/limits.h" 2 3 4

# 61 "/usr/include/i386/limits.h" 3 4

# 83 "/usr/include/i386/limits.h" 3 4

# 96 "/usr/include/i386/limits.h" 3 4

# 9 "/usr/include/machine/limits.h" 2 3 4
# 65 "/usr/include/limits.h" 2 3 4

# 1 "/usr/include/sys/syslimits.h" 1 3 4

# 28 "/usr/include/sys/syslimits.h" 3 4

# 64 "/usr/include/sys/syslimits.h" 3 4

# 87 "/usr/include/sys/syslimits.h" 3 4

# 104 "/usr/include/sys/syslimits.h" 3 4

# 66 "/usr/include/limits.h" 2 3 4

# 75 "/usr/include/limits.h" 3 4

# 89 "/usr/include/limits.h" 3 4

# 107 "/usr/include/limits.h" 3 4

# 118 "/usr/include/limits.h" 3 4

# 123
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h" 2 3
4

# 8
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/syslimits.h" 2
3 4
# 12 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h"
2 3 4

# 55 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h"
3 4

# 102
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h" 3 4

# 5 "/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c" 2

__const __attribute__((vector_size(16))) unsigned int v1 = {10,11,12,13};
__const __attribute__((vector_size(16))) unsigned int v2 = {20,21,22,23};

void foo(int a, ...)
{
  va_list args;
  __attribute__((vector_size(16))) unsigned int v;

  __builtin_va_start(args, a);
  v = __builtin_va_arg(args, __attribute__((vector_size(16))) unsigned int);
  if (a != 1 || memcmp (&v, &v1, sizeof (v)) != 0)
    abort ();
  a = __builtin_va_arg(args, int);
  if (a != 2)
    abort ();
  v = __builtin_va_arg(args, __attribute__((vector_size(16))) unsigned int);
  if (memcmp (&v, &v2, sizeof (v)) != 0)
    abort ();
  __builtin_va_end(args);
}

int main(void)
{

  foo (1, (__attribute__((vector_size(16))) unsigned int){10,11,12,13}, 2,
       (__attribute__((vector_size(16))) unsigned int){20,21,22,23});

  return 0;
}


-- 


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

[Bug c/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-13 17:01:48
               date|                            |


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
          Component|c                           |middle-end
   Target Milestone|---                         |4.3.0


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2008-01-21 15:14 -------
Reproducible even with x86_64-linux -> i686-darwin9 cross, at -Os as well as
-O2 -mno-accumulate-outgoing-args.  The difference between i686-linux and
i686-darwin9 that matters here is that darwin defines STACK_BOUNDARY to 128,
while linux to 4.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2008-01-21 15:22 -------
Shorter testcase:
void foo (int, ...);
__attribute__ ((vector_size (16))) int v;

void
bar (void)
{
  foo (1, v);
}
with -O2 -mno-accumulate-outgoing-args -m32 or -Os -m32.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2008-01-21 15:38 -------
And varargs aren't even needed:
typedef __attribute__ ((vector_size (16))) int V;
void foo (int, V, V, V, V);
V v;

void
bar (void)
{
  foo (1, v, v, v, v);
}

The regression has been caused by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125555

pad_to_arg_alignment in this case doesn't increase alignment_pad:
            if (boundary > PARM_BOUNDARY && boundary > STACK_BOUNDARY)
              alignment_pad->constant = offset_ptr->constant - save_constant;
because boundary in this case is equal to STACK_BOUNDARY.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |geoffk at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
           Priority|P3                          |P2


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[geoffk at gcc dot gnu dot org]

------- Comment #6 from geoffk at gcc dot gnu dot org  2008-01-21 16:43 -------
I suspect that the patch changed bad code generation into a crash, which is not
a regression...


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2008-01-21 17:46 -------
(In reply to comment #6)
> I suspect that the patch changed bad code generation into a crash, which is not
> a regression...

Yes it is.  Anything into an ICE is a regression in my book.  I thought we
documented this somewhere too.

Thanks,
Andrew Pinski


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2008-01-21 20:53 -------
And, on these testcases that patch hasn't changed bad code generation into ICE,
but good code generation into ICE, at least as far as I can eyeball the
assembly,
e.g. on the #c5 testcase with -Os and STACK_BOUNDARY redefinition in
config/i386/darwin.h commented out I get:
        .text
.globl _bar
_bar:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $36, %esp
        movaps  _v, %xmm0
        movaps  %xmm0, 12(%esp)
        movaps  %xmm0, %xmm2
        pushl   $1
        movaps  %xmm0, %xmm1
        call    _foo
        addl    $32, %esp
        leave
        ret
.comm _v,16,4
        .subsections_via_symbols
which keeps the right stack alignment and passes the args in correct locations.
So this is clearly a regression.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #9 from ubizjak at gmail dot com  2008-02-12 15:11 -------
By disabling asserts, we can compare -O2 call frame for va-arg-25.c test
vs. what would -Os call frame look like:

gcc -O2 -fomit-frame-pointer:

main:
        subl    $76, %esp
        movdqa  .LC0, %xmm0
        movl    $2, 32(%esp)
        movdqa  %xmm0, 48(%esp)
        movl    $1, (%esp)
        movdqa  .LC1, %xmm0
        movdqa  %xmm0, 16(%esp)
        call    foo

vs. gcc -Os (aka -mno-accumulate-outgoing-args) -fomit-frame-pointer:

main:
        subl    $28, %esp
        movaps  .LC0, %xmm0
        movaps  %xmm0, (%esp)
        pushl   $2
        movaps  .LC1, %xmm0
        subl    $16, %esp
        movaps  %xmm0, (%esp)
        pushl   $1
        call    foo
        ...

So, at the call, we have -O2 stack:

 +76
 +72
 +68
 +64
 +60  .LC0
 +56  .LC0
 +52  .LC0 
 +48  .LC0
 +44   pad
 +40   pad
 +36   pad
 +32  $2
 +28  .LC1
 +24  .LC1
 +20  .LC1
 +16  .LC1
 +12   pad
 +8    pad      
 +4    pad
esp   $1
--------------

For -Os stack gets misaligned after "pushl $2". It looks that gcc should
decrease stack for additional 12 bytes before $2 is pushed, so the stack
is consistent with -O2.

For i686-linux-*, we generate correct sequence for -Os:

main:
        leal    4(%esp), %ecx
        andl    $-16, %esp
        pushl   -4(%ecx)
        pushl   %ecx
        subl    $36, %esp
        movaps  .LC0, %xmm0
        movaps  %xmm0, 12(%esp)
        pushl   $2
        movaps  .LC1, %xmm0
        subl    $28, %esp
        movaps  %xmm0, 12(%esp)
        pushl   $1
        call    foo
        ...


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[hjl dot tools at gmail dot com]

------- Comment #10 from hjl dot tools at gmail dot com  2008-02-12 15:46 -------
(In reply to comment #3)
> Reproducible even with x86_64-linux -> i686-darwin9 cross, at -Os as well as
> -O2 -mno-accumulate-outgoing-args.  The difference between i686-linux and
> i686-darwin9 that matters here is that darwin defines STACK_BOUNDARY to 128,
> while linux to 4.
> 

I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
hardware related, not ABI related.  They should set PREFERRED_STACK_BOUNDARY
instead, which is set to 128 already. On stack alignment branch, we
introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #11 from ubizjak at gmail dot com  2008-02-12 18:46 -------
(In reply to comment #10)

> I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
> hardware related, not ABI related.  They should set PREFERRED_STACK_BOUNDARY
> instead, which is set to 128 already. On stack alignment branch, we
> introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs.
> 

Also, STACK_BOUNDARY is somehow connected to PARM_BOUNDARY:

 -- Macro: STACK_BOUNDARY
     Define this macro to the minimum alignment enforced by hardware
     for the stack pointer on this machine.  The definition is a C
     expression for the desired alignment (measured in bits).  This
     value is used as a default if `PREFERRED_STACK_BOUNDARY' is not
     defined.  On most machines, this should be the same as
     `PARM_BOUNDARY'.

If PARM_BOUNDARY is set to 128, va-arg-25.c tests OK for all optimizations with
-m32 -msse2 additional flags.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[hjl dot tools at gmail dot com]

------- Comment #12 from hjl dot tools at gmail dot com  2008-02-12 18:52 -------
(In reply to comment #11)
> (In reply to comment #10)
> 
> > I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
> > hardware related, not ABI related.  They should set PREFERRED_STACK_BOUNDARY
> > instead, which is set to 128 already. On stack alignment branch, we
> > introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs.
> > 
> 
> Also, STACK_BOUNDARY is somehow connected to PARM_BOUNDARY:
> 
>  -- Macro: STACK_BOUNDARY
>      Define this macro to the minimum alignment enforced by hardware
>      for the stack pointer on this machine.  The definition is a C
>      expression for the desired alignment (measured in bits).  This
>      value is used as a default if `PREFERRED_STACK_BOUNDARY' is not
>      defined.  On most machines, this should be the same as
>      `PARM_BOUNDARY'.
> 
> If PARM_BOUNDARY is set to 128, va-arg-25.c tests OK for all optimizations with
> -m32 -msse2 additional flags.
> 

That is not a surprise. But changing PARM_BOUNDARY may change ABI on Apple.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[geoffk at geoffk dot org]

------- Comment #13 from geoffk at geoffk dot org  2008-02-12 22:43 -------
Subject: Re:  [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal
compiler error: in expand_call, at calls.c:2785


On 12/02/2008, at 7:46 AM, hjl dot tools at gmail dot com wrote:

> ------- Comment #10 from hjl dot tools at gmail dot com  2008-02-12  
> 15:46 -------
> (In reply to comment #3)
>> Reproducible even with x86_64-linux -> i686-darwin9 cross, at -Os  
>> as well as
>> -O2 -mno-accumulate-outgoing-args.  The difference between i686- 
>> linux and
>> i686-darwin9 that matters here is that darwin defines  
>> STACK_BOUNDARY to 128,
>> while linux to 4.
>>
>
> I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
> hardware related, not ABI related.  They should set  
> PREFERRED_STACK_BOUNDARY
> instead, which is set to 128 already. On stack alignment branch, we
> introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs.

If you do not align the stack at a 128-bit boundary, your program will  
crash.  The hardware that it is related to is SSE2.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[hjl dot tools at gmail dot com]

------- Comment #14 from hjl dot tools at gmail dot com  2008-02-12 23:45 -------
(In reply to comment #13)

> > I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
> > hardware related, not ABI related.  They should set  
> > PREFERRED_STACK_BOUNDARY
> > instead, which is set to 128 already. On stack alignment branch, we
> > introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs.
> 
> If you do not align the stack at a 128-bit boundary, your program will  
> crash.  The hardware that it is related to is SSE2.

Stack alignment is controlled by PREFERRED_STACK_BOUNDARY. When it is
set to 128, gcc will generate codes aligned at 128bit. STACK_BOUNDARY
is more or less "natural" hardware stack boundary, which should be
the size of pointer.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[geoffk at geoffk dot org]

------- Comment #15 from geoffk at geoffk dot org  2008-02-13 05:54 -------
Subject: Re:  [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal
compiler error: in expand_call, at calls.c:2785

STACK_BOUNDARY
>>
> is more or less "natural" hardware stack boundary, which should be
> the size of pointer.

That is not what is documented and if you are proposing a change, I do  
not see how your proposal is useful.

The distinguishing property of STACK_BOUNDARY is that the compiler is  
allowed to rely on the stack being aligned by it.  There is no notion  
of "hardware" or "pointer" or "natural" involved; either the stack is  
always aligned on call boundaries or it is not.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[hjl dot tools at gmail dot com]

------- Comment #16 from hjl dot tools at gmail dot com  2008-02-13 06:41 -------
(In reply to comment #15)
> Subject: Re:  [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal
> compiler error: in expand_call, at calls.c:2785
> 
> STACK_BOUNDARY
> >>
> > is more or less "natural" hardware stack boundary, which should be
> > the size of pointer.
> 
> That is not what is documented and if you are proposing a change, I do  
> not see how your proposal is useful.
> 
> The distinguishing property of STACK_BOUNDARY is that the compiler is  
> allowed to rely on the stack being aligned by it.  There is no notion  
> of "hardware" or "pointer" or "natural" involved; either the stack is  
> always aligned on call boundaries or it is not.
> 

Here is our proposal:

http://gcc.gnu.org/ml/gcc/2007-12/msg00567.html


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[geoffk at geoffk dot org]

------- Comment #17 from geoffk at geoffk dot org  2008-02-13 07:50 -------
Subject: Re:  [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal
compiler error: in expand_call, at calls.c:2785


On 12/02/2008, at 10:41 PM, hjl dot tools at gmail dot com wrote:

> ------- Comment #16 from hjl dot tools at gmail dot com  2008-02-13  
> 06:41 -------
> (In reply to comment #15)
>> Subject: Re:  [4.3 Regression] gcc.c-torture/execute/va-arg-25.c: 
>> 32: internal
>> compiler error: in expand_call, at calls.c:2785
>>
>> STACK_BOUNDARY
>>>>
>>> is more or less "natural" hardware stack boundary, which should be
>>> the size of pointer.
>>
>> That is not what is documented and if you are proposing a change, I  
>> do
>> not see how your proposal is useful.
>>
>> The distinguishing property of STACK_BOUNDARY is that the compiler is
>> allowed to rely on the stack being aligned by it.  There is no notion
>> of "hardware" or "pointer" or "natural" involved; either the stack is
>> always aligned on call boundaries or it is not.
>>
>
> Here is our proposal:
>
> http://gcc.gnu.org/ml/gcc/2007-12/msg00567.html

It is to be expected that this proposal usually has no effect on  
Darwin, because the problem it is trying to solve, of local variables  
that require alignment greater than the default, does not usually  
exist on Darwin.

Under the definitions in your proposal, on Darwin, STACK_BOUNDARY  
should be 128, because 128 is the "minimum stack boundary" on Darwin,  
and this is also the value "preferred by hardware".  There is a  
contradiction in your proposal in which it says that it is "preferred  
by hardware" but also the "minimum stack boundary"; on many x86  
platforms, the hardware would really prefer 128 bits, but the ABI  
actually specifies a smaller value.

I think your proposal would be more clear if it left the definition of  
STACK_BOUNDARY alone.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[hjl dot tools at gmail dot com]

------- Comment #18 from hjl dot tools at gmail dot com  2008-02-13 15:39 -------
(In reply to comment #17)
>
> It is to be expected that this proposal usually has no effect on  
> Darwin, because the problem it is trying to solve, of local variables  
> that require alignment greater than the default, does not usually  
> exist on Darwin.

attribute may increase alignment larger than 128bit and it won't work
on Darwin.

> 
> Under the definitions in your proposal, on Darwin, STACK_BOUNDARY  
> should be 128, because 128 is the "minimum stack boundary" on Darwin,  
> and this is also the value "preferred by hardware".  There is a  

On x86, STACK_BOUNDARY is the stack size change when pop/push is used
on register by gcc. Some special instructions on some hardware 
require 512bit alignment. It doesn't make those hardwares to use
512 as STACK_BOUNDARY.

> contradiction in your proposal in which it says that it is "preferred  
> by hardware" but also the "minimum stack boundary"; on many x86  
> platforms, the hardware would really prefer 128 bits, but the ABI  
> actually specifies a smaller value.
> 

On i386, gcc uses 128bit stack alignment for all OSes as specified by
PREFERRED_STACK_BOUNDARY, which controls stack alignment, including
Linux and Darwin. The only difference is gcc doesn't conform to Linux
psABI and gcc on Darwin does. There is no need at all for Darwin to
use 128 for STACK_BOUNDARY to get 128bit stack alignment because
gcc does it already, independent of STACK_BOUNDARY.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

------- Comment #19 from dominiq at lps dot ens dot fr  2008-02-13 16:07 -------
I am quite confused by the following:

>> STACK_BOUNDARY to 128,
>> while linux to 4.
>>
...
> If you do not align the stack at a 128-bit boundary, your program will  
> crash.  The hardware that it is related to is SSE2.

In which unit is expressed STACK_BOUNDARY? If linux set it to 4, is it correct
to understand that it is bytes and not bits (4 bits would not make any sense)?
Now, if Darwin requires 128 bits, should not the value be 16?


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #20 from ubizjak at gmail dot com  2008-02-13 16:18 -------
(In reply to comment #19)

> >> STACK_BOUNDARY to 128,
> >> while linux to 4.

> In which unit is expressed STACK_BOUNDARY? If linux set it to 4, is it correct
> to understand that it is bytes and not bits (4 bits would not make any sense)?
> Now, if Darwin requires 128 bits, should not the value be 16?

Currently, it is defined as:

#define STACK_BOUNDARY BITS_PER_WORD

> 


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

------- Comment #21 from dominiq at lps dot ens dot fr  2008-02-13 16:40 -------
> Currently, it is defined as:
>
> #define STACK_BOUNDARY BITS_PER_WORD

In this case how can it be 4? should not it be 32 or 64?


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #22 from ubizjak at gmail dot com  2008-02-13 17:03 -------
(In reply to comment #21)
> > Currently, it is defined as:
> >
> > #define STACK_BOUNDARY BITS_PER_WORD
> 
> In this case how can it be 4? should not it be 32 or 64?

Yes, it _is_ 32 or 64. The point is, that IT IS NOT 128, so x86_64 (that has
sse2 enabled by default) would break left and right if STACK_BOUNDARY was
required to be 128 bit.

Looking through calls.c, it is obvious that PREFERRED_STACK_BOUNDARY pretty
much guarantees 128 bit stack alignment:

--cut here--
  /* Ensure current function's preferred stack boundary is at least
     what we need.  We don't have to increase alignment for recursive
     functions.  */
  if (cfun->preferred_stack_boundary < preferred_stack_boundary
      && fndecl != current_function_decl)
    cfun->preferred_stack_boundary = preferred_stack_boundary;
  if (fndecl == current_function_decl)
    cfun->recursive_call_emit = true;
--cut here--

IMO, there is no need for extra paranoia in darwin.h and following defines
should be removed:

/* On Darwin, the stack is 128-bit aligned at the point of every call.
   Failure to ensure this will lead to a crash in the system libraries
   or dynamic loader.  */
#undef STACK_BOUNDARY
#define STACK_BOUNDARY 128

/* Since we'll never want a stack boundary less aligned than 128 bits
   we need the extra work here otherwise bits of gcc get very grumpy
   when we ask for lower alignment.  We could just reject values less
   than 128 bits for Darwin, but it's easier to up the alignment if
   it's below the minimum.  */
#undef PREFERRED_STACK_BOUNDARY
#define PREFERRED_STACK_BOUNDARY (ix86_preferred_stack_boundary > 128   \
                                  ? ix86_preferred_stack_boundary       \
                                  : 128)

(Could someone with darwin bootstraps and regtest removal of these defines? Do
we even have an example of a failure for latest 4.3 if these are not defined?)

AFAICS, STACK_BOUNDARY should be set to the value of "push" insn - in the sense
that x86_64 doesn't define it to (...say...) 25 or some other random value. For
sure, it should mirror PARM_BOUNDARY, otherwise various strange things happen.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[pinskia at gcc dot gnu dot org]

------- Comment #23 from pinskia at gcc dot gnu dot org  2008-02-13 17:18 -------
Why is it STACK_BOUNDARY on PowerPC to 128 (for both AIX and Darwin) and why
does it work that way and x86 does not work that way?

-- Pinski


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #24 from ubizjak at gmail dot com  2008-02-13 18:11 -------
(In reply to comment #23)
> Why is it STACK_BOUNDARY on PowerPC to 128 (for both AIX and Darwin) and why
> does it work that way and x86 does not work that way?

Don't know rs6000 to tell, but it looks to me that for i686 target, gcc _tries_
to push 128bit constants to the stack due to STACK_BOUNDARY redefinition.

Please look at Comment #2, -mno-accumulate-outgoing-args (aka -Os) asm dump.
Everything would be perfectly aligned _if_ both push insn would increase SP for
128 bit.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

------- Comment #25 from dominiq at lps dot ens dot fr  2008-02-13 23:41 -------
> (Could someone with darwin bootstraps and regtest removal of these defines? Do
> we even have an example of a failure for latest 4.3 if these are not defined?)

I bootstraped without the defines and I have a bus error on two tests in my
list, the simplest is:

!module CHECK_SEM

! Submitted by Walt Brainerd, The Fortran Company
! GNU Fortran 95 (GCC 4.1.0 20050322 (experimental))
! Windows XP

! Produces "a.exe has encountered a problem" window.

! Same problem if comments are removed so that
!    the function is in a module.

!  contains

function CHECK_INTEGER4_RANK1 (EXPECTED)
!  integer(4), dimension(:), intent(in) ::  EXPECTED
  integer(4), dimension(1:) ::  EXPECTED
  logical  :: CHECK_INTEGER4_RANK1
  print *, EXPECTED
  CHECK_INTEGER4_RANK1 = all(EXPECTED == 0)
end function CHECK_INTEGER4_RANK1

!end module CHECK_SEM

program array_test
!use CHECK_SEM
integer(4), dimension(3) ::  dat
logical :: CHECK_INTEGER4_RANK1, res

!  print *, CHECK_INTEGER4_RANK1 ((/8,5,12/))
  dat = (/8,5,12/)
  print *, dat
  res = CHECK_INTEGER4_RANK1 (dat)
  print *,  res

end program array_test

These tests passed with my previous build, so the regression is probably due to
the defines removal, though I cannot rule out that it has been introduced by
recent changes (not in gfortran). I have launched a full regtesting, but the
results will be available tomorrow morning.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #26 from ubizjak at gmail dot com  2008-02-14 06:45 -------
(In reply to comment #25)
> > (Could someone with darwin bootstraps and regtest removal of these defines? Do
> > we even have an example of a failure for latest 4.3 if these are not defined?)
> 
> I bootstraped without the defines and I have a bus error on two tests in my
> list, the simplest is:

This one also fails for i686-linux-gnu, plain -O2.

(gdb) run
Starting program: /home/uros/test/a.out 
           8           5          12

Program received signal SIGSEGV, Segmentation fault.
extract_int (p=0x8, len=4) at ../../../gcc-svn/trunk/libgfortran/io/write.c:151


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[jpr at csc dot fi]

------- Comment #27 from jpr at csc dot fi  2008-02-14 08:12 -------

I think that the test program shown in comment #25 is invalid, as the main
program does not know about the call interface of the check_integer4_rank1()
function. If you add the module related lines in the comments, all is well (at
least on a i686-linux machine).


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

------- Comment #28 from dominiq at lps dot ens dot fr  2008-02-14 09:46 -------
With darwin bootstraps and regtest removal of the defines in
cc/config/i386/darwin.h

I have the following for gfortran:

FAIL: gfortran.dg/c_f_pointer_tests.f90  -O0  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O1  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O2  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O3 -g  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -Os  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O0  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O1  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O2  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O3 -g  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -Os  execution test

These tests pass with the defines.

I see also numerous failures in libstdc++ :

                === libstdc++ tests ===


Running target unix
XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test
XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test
FAIL: 23_containers/bitset/invalidation/1.cc execution test
FAIL: 23_containers/deque/invalidation/1.cc execution test
FAIL: 23_containers/deque/invalidation/2.cc execution test
FAIL: 23_containers/deque/invalidation/3.cc execution test
FAIL: 23_containers/deque/invalidation/4.cc execution test
FAIL: 23_containers/list/invalidation/1.cc execution test
FAIL: 23_containers/list/invalidation/2.cc execution test
FAIL: 23_containers/list/invalidation/3.cc execution test
FAIL: 23_containers/list/invalidation/4.cc execution test
FAIL: 23_containers/map/invalidation/1.cc execution test
FAIL: 23_containers/map/invalidation/2.cc execution test
FAIL: 23_containers/map/modifiers/insert/16813.cc execution test
FAIL: 23_containers/multimap/invalidation/1.cc execution test
FAIL: 23_containers/multimap/invalidation/2.cc execution test
FAIL: 23_containers/multiset/invalidation/1.cc execution test
FAIL: 23_containers/multiset/invalidation/2.cc execution test
FAIL: 23_containers/set/invalidation/1.cc execution test
FAIL: 23_containers/set/invalidation/2.cc execution test
FAIL: 23_containers/vector/invalidation/1.cc execution test
FAIL: 23_containers/vector/invalidation/2.cc execution test
FAIL: 23_containers/vector/invalidation/3.cc execution test
FAIL: 23_containers/vector/invalidation/4.cc execution test
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)
FAIL: ext/mt_allocator/deallocate_local_thread-5.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-7.cc execution test

                === libstdc++ Summary for unix ===

# of expected passes            4934
# of unexpected failures        24
# of unexpected successes       3
# of expected failures          59
# of unsupported tests          328

Running target unix/-m64
FAIL: 21_strings/basic_string/cons/char/6.cc execution test
FAIL: 21_strings/basic_string/cons/wchar_t/6.cc execution test
XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test
XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/char/1.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/char/6.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/char/7.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/char/8.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/wchar_t/1.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/wchar_t/6.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/wchar_t/7.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/wchar_t/8.cc execution test
FAIL: 22_locale/money_get/get/char/14.cc execution test
FAIL: 22_locale/money_get/get/char/22131.cc execution test
FAIL: 22_locale/money_get/get/char/6.cc execution test
FAIL: 22_locale/money_get/get/char/7.cc execution test
FAIL: 22_locale/money_get/get/char/8.cc execution test
FAIL: 22_locale/money_get/get/char/9.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/14.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/22131.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/6.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/7.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/8.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/9.cc execution test
FAIL: 22_locale/num_get/get/char/10.cc execution test
FAIL: 22_locale/num_get/get/char/11.cc execution test
FAIL: 22_locale/num_get/get/char/12.cc execution test
FAIL: 22_locale/num_get/get/char/13.cc execution test
FAIL: 22_locale/num_get/get/char/14.cc execution test
FAIL: 22_locale/num_get/get/char/16.cc execution test
FAIL: 22_locale/num_get/get/char/2.cc execution test
FAIL: 22_locale/num_get/get/char/22131.cc execution test
FAIL: 22_locale/num_get/get/char/23953.cc execution test
FAIL: 22_locale/num_get/get/wchar_t/10.cc execution test
FAIL: 22_locale/num_get/get/wchar_t/11.cc execution test
FAIL: 22_locale/num_get/get/wchar_t/12.cc execution test
FAIL: 22_locale/num_get/get/wchar_t/13.cc execution test
FAIL: 22_locale/num_get/get/wchar_t/14.cc execution test
FAIL: 22_locale/num_get/get/wchar_t/16.cc execution test
FAIL: 22_locale/num_get/get/wchar_t/2.cc execution test
FAIL: 22_locale/num_get/get/wchar_t/22131.cc execution test
FAIL: 22_locale/num_get/get/wchar_t/23953.cc execution test
FAIL: 22_locale/num_put/put/char/10.cc execution test
FAIL: 22_locale/num_put/put/wchar_t/10.cc execution test
FAIL: 22_locale/time_get/get_date/char/1.cc execution test
FAIL: 22_locale/time_get/get_date/wchar_t/1.cc execution test
FAIL: 22_locale/time_get/get_monthname/char/1.cc execution test
FAIL: 22_locale/time_get/get_monthname/char/4.cc execution test
FAIL: 22_locale/time_get/get_monthname/wchar_t/1.cc execution test
FAIL: 22_locale/time_get/get_monthname/wchar_t/4.cc execution test
FAIL: 22_locale/time_get/get_weekday/char/1.cc execution test
FAIL: 22_locale/time_get/get_weekday/wchar_t/1.cc execution test
FAIL: 22_locale/time_get/get_year/char/1.cc execution test
FAIL: 22_locale/time_get/get_year/wchar_t/1.cc execution test
FAIL: 23_containers/bitset/invalidation/1.cc execution test
FAIL: 23_containers/bitset/to_ulong/1.cc execution test
FAIL: 23_containers/deque/cons/2.cc execution test
FAIL: 23_containers/deque/invalidation/1.cc execution test
FAIL: 23_containers/deque/invalidation/2.cc execution test
FAIL: 23_containers/deque/invalidation/3.cc execution test
FAIL: 23_containers/deque/invalidation/4.cc execution test
FAIL: 23_containers/list/invalidation/1.cc execution test
FAIL: 23_containers/list/invalidation/2.cc execution test
FAIL: 23_containers/list/invalidation/3.cc execution test
FAIL: 23_containers/list/invalidation/4.cc execution test
FAIL: 23_containers/map/invalidation/1.cc execution test
FAIL: 23_containers/map/invalidation/2.cc execution test
FAIL: 23_containers/map/modifiers/insert/16813.cc execution test
FAIL: 23_containers/multimap/invalidation/1.cc execution test
FAIL: 23_containers/multimap/invalidation/2.cc execution test
FAIL: 23_containers/multiset/invalidation/1.cc execution test
FAIL: 23_containers/multiset/invalidation/2.cc execution test
FAIL: 23_containers/set/invalidation/1.cc execution test
FAIL: 23_containers/set/invalidation/2.cc execution test
FAIL: 23_containers/vector/invalidation/1.cc execution test
FAIL: 23_containers/vector/invalidation/2.cc execution test
FAIL: 23_containers/vector/invalidation/3.cc execution test
FAIL: 23_containers/vector/invalidation/4.cc execution test
FAIL: 24_iterators/istream_iterator/2.cc execution test
FAIL: 24_iterators/istreambuf_iterator/2.cc execution test
FAIL: 25_algorithms/copy/streambuf_iterators/char/1.cc execution test
FAIL: 25_algorithms/copy/streambuf_iterators/char/2.cc execution test
FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/1.cc execution test
FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/2.cc execution test
FAIL: 25_algorithms/find/istreambuf_iterators/char/1.cc execution test
FAIL: 25_algorithms/find/istreambuf_iterators/wchar_t/1.cc execution test
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)
FAIL: 27_io/basic_istream/extractors_arithmetic/char/01.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/char/03.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/char/06.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/char/07.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/char/08.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/char/09.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/char/10.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/char/11.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/char/13.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/01.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/03.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/06.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/07.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/08.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/09.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/10.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/11.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/13.cc execution test
FAIL: 27_io/basic_istream/extractors_character/char/3.cc execution test
FAIL: 27_io/basic_istream/extractors_character/wchar_t/3.cc execution test
FAIL: 27_io/basic_istream/extractors_other/char/1.cc execution test
FAIL: 27_io/basic_istream/extractors_other/char/26181.cc execution test
FAIL: 27_io/basic_istream/extractors_other/char/9318-in.cc execution test
FAIL: 27_io/basic_istream/extractors_other/char/exceptions_null.cc execution
test
FAIL: 27_io/basic_istream/extractors_other/wchar_t/1.cc execution test
FAIL: 27_io/basic_istream/extractors_other/wchar_t/26181.cc execution test
FAIL: 27_io/basic_istream/extractors_other/wchar_t/9318-in.cc execution test
FAIL: 27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc execution
test
FAIL: 27_io/basic_istream/get/char/1.cc execution test
FAIL: 27_io/basic_istream/get/char/3.cc execution test
FAIL: 27_io/basic_istream/get/wchar_t/1.cc execution test
FAIL: 27_io/basic_istream/get/wchar_t/3.cc execution test
FAIL: 27_io/basic_istream/getline/char/1.cc execution test
FAIL: 27_io/basic_istream/getline/char/2.cc execution test
FAIL: 27_io/basic_istream/getline/char/3.cc execution test
FAIL: 27_io/basic_istream/getline/char/6.cc execution test
FAIL: 27_io/basic_istream/getline/wchar_t/1.cc execution test
FAIL: 27_io/basic_istream/getline/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/getline/wchar_t/3.cc execution test
FAIL: 27_io/basic_istream/getline/wchar_t/6.cc execution test
FAIL: 27_io/basic_istream/peek/char/1.cc execution test
FAIL: 27_io/basic_istream/peek/char/12296.cc execution test
FAIL: 27_io/basic_istream/peek/wchar_t/1.cc execution test
FAIL: 27_io/basic_istream/peek/wchar_t/12296.cc execution test
FAIL: 27_io/basic_istream/read/char/1.cc execution test
FAIL: 27_io/basic_istream/read/char/2.cc execution test
FAIL: 27_io/basic_istream/read/wchar_t/1.cc execution test
FAIL: 27_io/basic_istream/read/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/seekg/char/8348-1.cc execution test
FAIL: 27_io/basic_istream/seekg/char/8348-2.cc execution test
FAIL: 27_io/basic_istream/seekg/wchar_t/8348-1.cc execution test
FAIL: 27_io/basic_istream/seekg/wchar_t/8348-2.cc execution test
FAIL: 27_io/basic_istream/sentry/char/1.cc execution test
FAIL: 27_io/basic_istream/sentry/char/12297.cc execution test
FAIL: 27_io/basic_istream/sentry/char/2.cc execution test
FAIL: 27_io/basic_istream/sentry/char/3.cc execution test
FAIL: 27_io/basic_istream/sentry/wchar_t/1.cc execution test
FAIL: 27_io/basic_istream/sentry/wchar_t/12297.cc execution test
FAIL: 27_io/basic_istream/sentry/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/sentry/wchar_t/3.cc execution test
FAIL: 27_io/basic_istream/tellg/char/8348.cc execution test
FAIL: 27_io/basic_istream/tellg/wchar_t/8348.cc execution test
FAIL: 27_io/basic_istream/ws/char/1.cc execution test
FAIL: 27_io/basic_istream/ws/wchar_t/1.cc execution test
FAIL: 27_io/basic_istringstream/str/char/1.cc execution test
FAIL: 27_io/basic_istringstream/str/wchar_t/1.cc execution test
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/5.cc execution test
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/6.cc execution test
FAIL: 27_io/basic_ostream/inserters_arithmetic/wchar_t/5.cc execution test
FAIL: 27_io/basic_ostream/inserters_arithmetic/wchar_t/6.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/char/1.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/char/3.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/char/9318-out.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/wchar_t/1.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/wchar_t/3.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/wchar_t/9318-out.cc execution test
FAIL: 27_io/basic_ostream/seekp/char/2346-sstream.cc execution test
FAIL: 27_io/basic_ostream/seekp/wchar_t/2346-sstream.cc execution test
FAIL: 27_io/basic_stringbuf/in_avail/char/21955.cc execution test
FAIL: 27_io/basic_stringbuf/overflow/char/9988.cc execution test
FAIL: 27_io/basic_stringbuf/overflow/wchar_t/9988.cc execution test
FAIL: 27_io/basic_stringbuf/seekoff/char/1.cc execution test
FAIL: 27_io/basic_stringbuf/seekoff/wchar_t/1.cc execution test
FAIL: 27_io/basic_stringbuf/sgetn/char/1.cc execution test
FAIL: 27_io/basic_stringbuf/sgetn/wchar_t/1.cc execution test
FAIL: 27_io/basic_stringstream/str/char/1.cc execution test
FAIL: 27_io/basic_stringstream/str/wchar_t/1.cc execution test
FAIL: 27_io/fpos/14320-5.cc execution test
WARNING: program timed out.
FAIL: 27_io/ios_base/storage/2.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-5.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-7.cc execution test
FAIL: tr1/5_numerical_facilities/random/discard_block/operators/serialize.cc
execution test
FAIL:
tr1/5_numerical_facilities/random/linear_congruential/operators/serialize.cc
execution test
FAIL: tr1/5_numerical_facilities/random/mersenne_twister/operators/serialize.cc
execution test
FAIL:
tr1/5_numerical_facilities/random/subtract_with_carry/operators/serialize.cc
execution test
FAIL:
tr1/5_numerical_facilities/random/subtract_with_carry_01/operators/serialize.cc
execution test
FAIL: tr1/5_numerical_facilities/random/xor_combine/operators/serialize.cc
execution test

                === libstdc++ Summary for unix/-m64 ===

# of expected passes            4775
# of unexpected failures        183
# of unexpected successes       3
# of expected failures          59
# of unsupported tests          328

                === libstdc++ Summary ===

# of expected passes            9709
# of unexpected failures        207
# of unexpected successes       6
# of expected failures          118
# of unsupported tests          656


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #29 from ubizjak at gmail dot com  2008-02-14 09:58 -------
(In reply to comment #28)
> With darwin bootstraps and regtest removal of the defines in
> cc/config/i386/darwin.h

Hm... I assume you did recompile libgfortran and libstdc++...


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

------- Comment #30 from dominiq at lps dot ens dot fr  2008-02-14 10:09 -------
> Hm... I assume you did recompile libgfortran and libstdc++...

In comment #25 I have said:

> I bootstraped without the defines

Anyway, even if the change had solved the problem, I would not have considered
it as a long term fix.
I do not know the technicalities around the *STACK_BOUNDARY stuff to
participate to the discussion, but I think this PR only expose an underlying
bug that should be analyzed.

>From what I understand, if *STACK_BOUNDARY is larger than the size of what is
pushed in the stack, some padding is performed. So the basic question is why
this done for -O2 and not for -Os.

I am currently regtesting libstdc++-v3 rev. 132313, with the defines to confirm
that the failures has not been induced by something else.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #31 from ubizjak at gmail dot com  2008-02-14 12:48 -------
(In reply to comment #30)

> participate to the discussion, but I think this PR only expose an underlying
> bug that should be analyzed.
> 
> From what I understand, if *STACK_BOUNDARY is larger than the size of what is
> pushed in the stack, some padding is performed. So the basic question is why
> this done for -O2 and not for -Os.

Well, _if_ we want STACK_BOUNDARY larger than PARM_BOUNDARY, then following
patch is needed:

ndex: function.c
===================================================================
--- function.c  (revision 132313)
+++ function.c  (working copy)
@@ -3436,7 +3436,7 @@ pad_to_arg_alignment (struct args_size *
     sp_offset = 0;
 #endif

-  if (boundary > PARM_BOUNDARY && boundary > STACK_BOUNDARY)
+  if (boundary > PARM_BOUNDARY || boundary > STACK_BOUNDARY)
     {
       save_var = offset_ptr->var;
       save_constant = offset_ptr->constant;
@@ -3462,7 +3462,7 @@ pad_to_arg_alignment (struct args_size *
          offset_ptr->var = size_binop (MINUS_EXPR, rounded, sp_offset_tree);
          /* ARGS_SIZE_TREE includes constant term.  */
          offset_ptr->constant = 0;
-         if (boundary > PARM_BOUNDARY && boundary > STACK_BOUNDARY)
+         if (boundary > PARM_BOUNDARY || boundary > STACK_BOUNDARY)
            alignment_pad->var = size_binop (MINUS_EXPR, offset_ptr->var,
                                             save_var);
        }
@@ -3474,7 +3474,7 @@ pad_to_arg_alignment (struct args_size *
 #else
            CEIL_ROUND (offset_ptr->constant + sp_offset, boundary_in_bytes);
 #endif
-           if (boundary > PARM_BOUNDARY && boundary > STACK_BOUNDARY)
+           if (boundary > PARM_BOUNDARY || boundary > STACK_BOUNDARY)
              alignment_pad->constant = offset_ptr->constant - save_constant;
        }
     }


This patch fixes va-arg-25.c testcase I'm testing with STACK_BOUNDARY = 128.
The patch bootstraps and regression tests on i686-pc-linux-gnu, but due to
STACK_BOUNDARY == PARM_BOUNDARY on this target, it has not much effect there.

Without this patch, alignment pad is always 0, which is just wrong for
va-arg-25.c case with mixed int/SSE/int/SSE arguments pushed on stack. Note
that sse requires 16 byte alignment.

Using -maccumulate-outgoing-args (-O2), we subtract %esp and stick arguments
into the call frame using offseted moves. We have no other %esp manipulation in
this case.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #32 from ubizjak at gmail dot com  2008-02-14 17:08 -------
Dominique, could you regtest
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00507.html on darwin?


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2008-
                   |                            |02/msg00507.html


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

------- Comment #33 from dominiq at lps dot ens dot fr  2008-02-14 19:37 -------
> Dominique, could you regtest

I just finished a fresh build, I'll start to regtest as soon as the install is
finished, the full regtest takes approximately 5 hours, so the results will
only be available tomorrow morning. I have checked that the patch fix this PR.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

------- Comment #34 from dominiq at lps dot ens dot fr  2008-02-15 07:21 -------
With the patch in http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00507.html, the
PR is fixed without regression on intel(32/64 bit) and ppc(32 bit) darwin9.
I'll post the test results ASAP.

Thanks for your patience and the fix.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #35 from ubizjak at gmail dot com  2008-02-15 08:01 -------
(In reply to comment #34)
> With the patch in http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00507.html, the
> PR is fixed without regression on intel(32/64 bit) and ppc(32 bit) darwin9.
> I'll post the test results ASAP.

Great! OTOH, the test for STACK_BOUNDARY can simply be removed, because
PARM_BOUNDARY is always equal or smaller than STACK_BOUNDARY. I have checked
all targets, and this is true everywhere.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[uros at gcc dot gnu dot org]

------- Comment #36 from uros at gcc dot gnu dot org  2008-02-15 09:56 -------
Subject: Bug 34621

Author: uros
Date: Fri Feb 15 09:55:36 2008
New Revision: 132336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132336
Log:
        PR middle-end/34621
        * function.c (pad_to_arg_alignment): Remove test for STACK_BOUNDARY
        when calculating alignment_pad.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/function.c


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

------- Comment #37 from ubizjak at gmail dot com  2008-02-15 10:01 -------
Fixed with the patch that removes the test for STACK_BOUNDARY.

[Let's wait to see if there are any targets that break with this change...]


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
                   |patches/2008-               |patches/2008-
                   |02/msg00507.html            |02/msg00541.html
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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