[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058

[abel at gcc dot gnu.org]

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

--- Comment #25 from Andrey Belevantsev  2010-12-24 
08:23:07 UTC ---
Zdenek, please don't worry about the set of flags, it does not make fixing the
problem any harder, and your work on finding these is invaluable for us.

Sigh, in this case I forgot that we now also stall when we have issued exactly
issue_rate instructions, so in this case we also need to recheck the DFA, not
only after the data dependency stall.  So the last patch should be amended like
below.

diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index edd6cb9..2f721fb 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -6990,7 +6990,7 @@ reset_sched_cycles_in_current_ebb (void)
 {
   int cost, haifa_cost;
   int sort_p;
-  bool asm_p, real_insn, after_stall;
+  bool asm_p, real_insn, after_stall, all_issued;
   int clock;

   if (!INSN_P (insn))
@@ -7026,8 +7026,8 @@ reset_sched_cycles_in_current_ebb (void)
   haifa_cost = cost;
   after_stall = 1;
 }
-  if (haifa_cost == 0
- && issued_insns == issue_rate)
+  all_issued = issued_insns == issue_rate;
+  if (haifa_cost == 0 && all_issued)
haifa_cost = 1;
   if (haifa_cost > 0)
{
@@ -7059,7 +7059,7 @@ reset_sched_cycles_in_current_ebb (void)
  become unavailable  to the DFA restrictions.  Looks strange
  but happens e.g. on x86-64.  So recheck DFA on the last
  iteration.  */
-  if (after_stall
+  if ((after_stall || all_issued)
   && real_insn
   && haifa_cost == 0)
 haifa_cost = estimate_insn_cost (insn, curr_state);

[Bug insn-scheduling][4.4 ARM] Scheduling error on -O2 -mfloat-abi=softfp -mfpu=vfp

[M.F. Wu]

Dear sir,

gcc-4.4.0 mis-schedules the instructions. It causes the wrong return
values in r0 and r1.
But, gcc-4.5.0 does the right thing to schedule the instructions. How
do I fix this in
gcc-4.4.0? Thank you.

Cheers
Mingfeng



Source code:

typedef unsigned long long float64;

float64 syst_float64_div( float64 a, float64 b )
{
float64 z;

*( (double *) &z ) = *( (double *) &a ) / *( (double *) &b );
return z;

}

Compile options:
-O2 -mfloat-abi=softfp -mfpu=vfp -S

GCC-4.4.0 outputs:
syst_float64_div:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
fmdrr   d5, r0, r1
fmdrr   d6, r2, r3
sub sp, sp, #8
ldr r0, [sp, #0]
fdivd   d7, d5, d6
ldr r1, [sp, #4]
fstdd7, [sp, #0]
add sp, sp, #8
bx  lr
.size   syst_float64_div, .-syst_float64_div

GCC-4.5.0 outputs:
syst_float64_div:
@ args = 0, pretend = 0, frame = 24
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #24
strdr0, [sp, #8]
strdr2, [sp]
flddd7, [sp, #0]
flddd6, [sp, #8]
fdivd   d7, d6, d7
fstdd7, [sp, #16]
ldr r0, [sp, #16]
ldr r1, [sp, #20]
add sp, sp, #24
bx  lr
.size   syst_float64_div, .-syst_float64_div

Re: [Bug insn-scheduling][4.4 ARM] Scheduling error on -O2 -mfloat-abi=softfp -mfpu=vfp

[Andreas Schwab]

"M.F. Wu"  writes:

> Source code:
>
> typedef unsigned long long float64;
>
> float64 syst_float64_div( float64 a, float64 b )
> {
> float64 z;
>
> *( (double *) &z ) = *( (double *) &a ) / *( (double *) &b );

Please read .

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Bug fortran/31821] character pointer => target(range) should detect if lengths don't match

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig  2010-12-24 
08:42:07 UTC ---
Author: tkoenig
Date: Fri Dec 24 08:42:04 2010
New Revision: 168224

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168224
Log:
2010-12-24  Thomas Koenig  

PR fortran/31821
* check.c (gfc_var_strlen):  New function, also including
substring references.
(gfc_check_same_strlen):  Use gfc_var_strlen.

2010-12-24  Thomas Koenig  

PR fortran/31821
* gfortran.dg/char_pointer_assign_6.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/31821] character pointer => target(range) should detect if lengths don't match

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Thomas Koenig  2010-12-24 
08:44:24 UTC ---
Fixed, closing.

[Bug tree-optimization/47059] New: compiler fails to coalesce loads/stores

[rahul at icerasemi dot com]

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

   Summary: compiler fails to coalesce loads/stores
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ra...@icerasemi.com
CC: sdkteam-...@icerasemi.com
  Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
 Build: i686-pc-linux-gnu


Consider the following test case compiled with GCC4.5.1 (x86) and the following
command:

gcc -S -Os test.c

struct struct1
{
  void *data;
  unsigned short f1;
  unsigned short f2;
};
typedef struct struct1 S1;

struct struct2
{
  int f3;
  S1 f4;
};
typedef struct struct2 S2;


extern void foo (S1 *ptr);
extern S2 gstruct2_var;
extern S1 gstruct1_var;

static S1 bar (const S1 *ptr) __attribute__ ((always_inline));

static S1
bar (const S1 *ptr)
{
  S1 ls_var = *ptr;
  foo (&ls_var);
  return ls_var;
}

int
main ()
{
  S2 *ps_var;

  ps_var = &gstruct2_var;
  ps_var->f4 = bar (&gstruct1_var);

  return 0;
}

We get:

main:
leal4(%esp), %ecx
andl$-16, %esp
pushl   -4(%ecx)
pushl   %ebp
movl%esp, %ebp
pushl   %ecx
subl$32, %esp
movlgstruct1_var, %eax
movlgstruct1_var+4, %edx
movl%eax, -16(%ebp)
leal-16(%ebp), %eax
pushl   %eax
movl%edx, -12(%ebp)
callfoo
movl-16(%ebp), %eax
movl-4(%ebp), %ecx
movl%eax, gstruct2_var+4
movl-12(%ebp), %eax<-- load1   [ebp - 12] @ 4 bytes
movw%ax, gstruct2_var+8<-- store1  [gstruct2_var + 8] @ 2 bytes
movw-10(%ebp), %ax <-- load2   [ebp - 10] @ 2 bytes
movw%ax, gstruct2_var+10   <-- store2  [gstruct2_var + 10] @ 2
bytes
xorl%eax, %eax
leave
leal-4(%ecx), %esp
ret
.size   main, .-main
.ident  "GCC: (GNU) 4.5.1"
.section.note.GNU-stack,"",@progbits


With GCC4.4.1 we get:

main:
leal4(%esp), %ecx
andl$-16, %esp
pushl   -4(%ecx)
pushl   %ebp
movl%esp, %ebp
pushl   %ecx
subl$32, %esp
movlgstruct1_var, %eax
movlgstruct1_var+4, %edx
movl%eax, -16(%ebp)
leal-16(%ebp), %eax
movl%edx, -12(%ebp)
pushl   %eax
callfoo
movl-12(%ebp), %eax   <-- Load1 [ebp - 12] @ 4 bytes
movl-4(%ebp), %ecx
movl%eax, gstruct2_var+8  <-- Store1 [gstruct2_var + 8] @ 4 bytes
movl-16(%ebp), %eax
movl%eax, gstruct2_var+4
xorl%eax, %eax
leave
leal-4(%ecx), %esp
ret
.size   main, .-main
.ident  "GCC: (GNU) 4.4.1"
.section.note.GNU-stack,"",@progbits


The extra load stores appear to be the result of change to SRA fully
scalarizing structure members f1 and f2. With GCC4.4.1 the access to these
fields is done using a BIT_FIELD_REF which combines the two loads and stores.

Talking to MartinJ on IRC I was told the changes to SRA make aggressive
scalarization of aggregates. In the past there was some functionality to try
and combine appropriate components into BIT_FIELD_REFs so as to reduce the
number of loads/stores. This has been removed from 4.5 in favour of simplicity
of the Gimple IR and working towards generic MEM_REFs. The plan is to introduce
new IR constructs to load/store individual bits and in a separate gimple pass
decide how to combine them together. But, this will only be available in 4.7+.

We also have the exact same issue on our port and causes a significant
performance regression on our software.

[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan  2010-12-24 
11:04:08 UTC ---
Ok I'll test this. (In reply to comment #4)
> Created attachment 22835 [details]
> gcc46-pr45701.patch
> 
> Remembering pointers to tail call insns is both wasteful (allocates stuff that
> is never used anywhere but on arm), error-prone (nothing adjusts the list if
> tail calls are deleted, or duplicated, etc.) and unnecessary, because
> the list is trivially available from the IL.
> 
> Here is completely untested patch (tested just on the 3 testcases with a
> cross).
> Could anyone interested in ARM target please bootstrap/regtest this?
> We have way too many open P1 bugs.

I'll test this.

[Bug tree-optimization/47060] New: [4.6 Regression] ICE: SIGSEGV in reduction_phi (tree-parloops.c:212) with -O -ffast-math -ftree-parallelize-loops=2 -fno-tree-dce

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: SIGSEGV in reduction_phi
(tree-parloops.c:212) with -O -ffast-math
-ftree-parallelize-loops=2 -fno-tree-dce
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22849
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22849
gcc.dg/graphite/id-14.c

Compiler output:
$ gcc -O -ffast-math -ftree-parallelize-loops=2 -fno-tree-dce id-14.c
==27629== Invalid read of size 4
==27629==at 0x9348B3: reduction_phi (tree-parloops.c:212)
==27629==by 0x936C9F: parallelize_loops (tree-parloops.c:1912)
==27629==by 0x9B75B8: tree_parallelize_loops (tree-ssa-loop.c:589)
==27629==by 0x7F1745: execute_one_pass (passes.c:1553)
==27629==by 0x7F1A34: execute_pass_list (passes.c:1608)
==27629==by 0x7F1A46: execute_pass_list (passes.c:1609)
==27629==by 0x7F1A46: execute_pass_list (passes.c:1609)
==27629==by 0x931D25: tree_rest_of_compilation (tree-optimize.c:422)
==27629==by 0xAF7311: cgraph_expand_function (cgraphunit.c:1508)
==27629==by 0xAF99E9: cgraph_optimize (cgraphunit.c:1567)
==27629==by 0xAF9F69: cgraph_finalize_compilation_unit (cgraphunit.c:1031)
==27629==by 0x50983B: c_write_global_declarations (c-decl.c:9845)
==27629==by 0x8DB515: toplev_main (toplev.c:591)
==27629==by 0x6369BBC: (below main) (in /lib64/libc-2.11.2.so)
==27629==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==27629== 
id-14.c: In function 'foo':
id-14.c:7:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Program received signal SIGSEGV, Segmentation fault.
reduction_phi (reduction_list=0x17b9630, phi=0x0) at
/mnt/svn/gcc-trunk/gcc/tree-parloops.c:212
212   tmpred.reduc_version = gimple_uid (phi);
(gdb) bt
#0  reduction_phi (reduction_list=0x17b9630, phi=0x0) at
/mnt/svn/gcc-trunk/gcc/tree-parloops.c:212
#1  0x00936ca0 in try_create_reduction_list () at
/mnt/svn/gcc-trunk/gcc/tree-parloops.c:1912
#2  parallelize_loops () at /mnt/svn/gcc-trunk/gcc/tree-parloops.c:2035
#3  0x009b75b9 in tree_parallelize_loops () at
/mnt/svn/gcc-trunk/gcc/tree-ssa-loop.c:589
#4  tree_parallelize_loops () at /mnt/svn/gcc-trunk/gcc/tree-ssa-loop.c:584
#5  0x007f1746 in execute_one_pass (pass=0x16375a0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1553
#6  0x007f1a35 in execute_pass_list (pass=0x16375a0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1608
#7  0x007f1a47 in execute_pass_list (pass=0x1637b40) at
/mnt/svn/gcc-trunk/gcc/passes.c:1609
#8  0x007f1a47 in execute_pass_list (pass=0x1636d60) at
/mnt/svn/gcc-trunk/gcc/passes.c:1609
#9  0x00931d26 in tree_rest_of_compilation (fndecl=0x75cc4f00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:422
#10 0x00af7312 in cgraph_expand_function (node=0x75ce4000) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1508
#11 0x00af99ea in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1567
#12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1827
#13 0x00af9f6a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1031
#14 0x0050983c in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9845
#15 0x008db516 in compile_file (argc=17, argv=0x7fffda88) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591
#16 do_compile (argc=17, argv=0x7fffda88) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1874
#17 toplev_main (argc=17, argv=0x7fffda88) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1937
#18 0x76586bbd in __libc_start_main () from /lib/libc.so.6
#19 0x004f0415 in _start ()


Tested revisions:
r168214 - crash
r165699 - OK
4.5 r168062 - OK

[Bug rtl-optimization/47036] [4.6 Regression] ICE: in move_cond_jump, at sel-sched.c:4901 with -fschedule-insns -fselective-scheduling -fno-dce

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  2010-12-24 
14:19:26 UTC ---
Author: amonakov
Date: Fri Dec 24 14:19:23 2010
New Revision: 168225

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168225
Log:
PR rtl-optimization/47036
* sel-sched-ir.c (fallthru_bb_of_jump): Remove special support for
unconditional jumps.
* sel-sched.c (moveup_expr): Ditto.

testsuite:
* g++.dg/opt/pr47036.C: New.


Added:
trunk/gcc/testsuite/g++.dg/opt/pr47036.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-ir.c
trunk/gcc/sel-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/47036] [4.6 Regression] ICE: in move_cond_jump, at sel-sched.c:4901 with -fschedule-insns -fselective-scheduling -fno-dce

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Alexander Monakov  2010-12-24 
14:20:29 UTC ---
Fixed.

[Bug tree-optimization/47061] New: VRP doesn't propagate through x<<=1, but it does for x*=2

[zsojka at seznam dot cz]

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

   Summary: VRP doesn't propagate through x<<=1, but it does for
x*=2
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22850
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22850
testcase

The attached testcase should be optimised to "return 0;", as it is when
x <<= 1;
is replaced by
x *= 2;

$ gcc -O3 pr47061.c -fdump-tree-vrp -S -masm=intel
shows in the .vrp1/2 dumps (among others):

x_1: [-10, -9]
x_2: [-10, -8]
x_3: [-10, -7]
x_4: [-10, -6]
x_11: [-9, -8]
x_14: [-9, -7]
x_17: [-9, -6]
x_18: VARYING

...

:
  # x_4 = PHI 
  x_18 = x_4 << 2;

Neither gcc version I tested works (3.3.6-4.6.0)

[Bug tree-optimization/47061] VRP doesn't propagate through x<<=1, but it does for x*=2

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  2010-12-24 15:54:35 
UTC ---
Created attachment 22851
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22851
another testcase

This testcase seems to be optimised at the RTL level.

$ gcc pr47061-2.c -S -O3 -fdump-tree-vrp

.vrp1/2 dumps show:
...
c_1(D): VARYING
D.2684_2: [-128, 127]
i_3: VARYING
D.2685_4: [0, 1]
...
:
  D.2684_2 = (int) c_1(D);
  i_3 = D.2684_2 << 1;
  D.2685_4 = i_3 > 1000;
  return D.2685_4;
...

So the value is known before the shift as well. For the right shift, the
function is optimised correctly.

[Bug target/47038] gcc.dg/pr46685.c FAILs on Solaris 10/SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.24 16:07:24
 Ever Confirmed|0   |1

--- Comment #2 from Eric Botcazou  2010-12-24 
16:07:24 UTC ---
> Hmmm... is this a dup of pr40483? Can someone confirm?

No, this looks unrelated.  This has been introduced by:

2010-12-20  Iain Sandoe  
Jan Hubicka  

PR middle-end/46916
* opts.c (finish_options): Enable -freorder-functions
when -freorder-blocks-and-partition is active.

[Bug target/47038] gcc.dg/pr46685.c FAILs on Solaris 10/SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org

--- Comment #3 from Eric Botcazou  2010-12-24 
16:09:03 UTC ---
Investigating.

[Bug tree-optimization/47061] VRP doesn't propagate through x<<=1, but it does for x*=2

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  2010-12-24 19:25:21 
UTC ---
(In reply to comment #1)
> For the right shift, the
> function is optimised correctly.

Actually, no, it's just the cast what optimises the range, but not the shift -
.vrp1 dump for "int i = c >> 1;":
...
c_1(D): VARYING
D.2684_2: VARYING
i_3: [-128, 127]
D.2685_4: [0, 0]
...
:
  D.2684_2 = c_1(D) >> 1;
  i_3 = (int) D.2684_2;
  D.2685_4 = 0;
  return 0;
...

[Bug ada/47017] [4.6 Regression] gnatlib ICE on sparc64-linux

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ebotcazou at gcc dot|
   |gnu.org |
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org

--- Comment #3 from Eric Botcazou  2010-12-24 
21:12:12 UTC ---
Investigating.

[Bug other/47062] New: -mfpmath=sse,387 causes pow() to produce incorrect results

[bero at arklinux dot org]

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

   Summary: -mfpmath=sse,387 causes pow() to produce incorrect
results
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@arklinux.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu


If (e)glibc is compiled with -mfpmath=sse,387, the pow() (and __builtin_pow())
function provides incorrect [beyond expectable inaccuracies] results.

#include 
#include 
int main(int argc, char **argv) {
double n = 0.703167;
printf("%f %f %f\n", pow(n, 1.0/2.2), __builtin_pow(n, 1.0/2.2),
pow(0.703167, 1.0/2.2));
}

(correctly) results in

0.852081 0.852081 0.852081

without -mfpmath=sse,387.
With -mfpmath=sse,387, the result is

1.14 1.14 0.852081

[Bug c++/46626] [4.6 Regression] simple use of virtual methods causes pure virtual method call in c++0x mode

[roman at binarylife dot net]

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

--- Comment #8 from Roman Kononov  2010-12-25 
01:49:05 UTC ---
With the patch applied to r168236:

$ cat test.cpp 
struct X {
virtual int& x(int&)=0;
virtual ~X() {}
};

struct Y {
virtual int& y(int&)=0;
virtual ~Y() {}
};

struct Z: X, Y {
int& x(int&);
int& y(int&);
};

void func() {
Z z;
}

$ g++ -c -std=c++0x test.cpp
test.cpp: In function 'void func()':
test.cpp:17:7:   in constexpr expansion of 'z.Z::Z()'
test.cpp:17:7: internal compiler error: in cxx_eval_bare_aggregate, at
cp/semantics.c:6352
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Without the patch, with the same test.cpp:

$ g++ -c -std=c++0x test.cpp; echo $?
0

Without the patch, with slightly different test1.cpp:

0 r...@wata:~/tmp/qqq>cat test1.cpp 
struct X {
virtual int& x(int&)=0;
//  virtual ~X() {}
};

struct Y {
virtual int& y(int&)=0;
//  virtual ~Y() {}
};

struct Z: X, Y {
int& x(int&);
int& y(int&);
};

void func() {
Z z;
}

0 r...@wata:~/tmp/qqq>g++ -c -std=c++0x test1.cpp
test1.cpp: In function 'void func()':
test1.cpp:17:7:   in constexpr expansion of 'z.Z::Z()'
test1.cpp:17:7: internal compiler error: in cxx_eval_bare_aggregate, at
cp/semantics.c:6338
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.