[Bug tree-optimization/50602] New: ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[Bug tree-optimization/50602] New: ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

             Bug #: 50602
           Summary: ICE in tree_nrv, at tree-nrv.c:155 during large LTO
                    build
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: andi-gcc@firstfloor.org


I get this at the end of a large 32bit LTO build. Cannot give you a small test
case unless you want the full builddir. Bisect is difficult because
the build relies on some recent other fixes.

But I have a core file:

#6  0x0000000000b47eb4 in fancy_abort (file=Unhandled dwarf expression opcode
0xf3
) at ../../gcc/gcc/diagnostic.c:893
#7  0x000000000075ac05 in tree_nrv () at ../../gcc/gcc/tree-nrv.c:155
#8  0x000000000068d7ab in execute_one_pass (pass=0x10a9ac0) at
../../gcc/gcc/passes.c:2064
#9  0x000000000068dae5 in execute_pass_list (pass=0x10a9ac0) at
../../gcc/gcc/passes.c:2119
#10 0x000000000075df39 in tree_rest_of_compilation (fndecl=0x2b84d3ea6900) at
../../gcc/gcc/tree-optimize.c:420
#11 0x000000000051ad36 in cgraph_expand_function (node=0x2b84e28a7360) at
../../gcc/gcc/cgraphunit.c:1805
#12 0x000000000051c612 in cgraph_output_in_order () at
../../gcc/gcc/cgraphunit.c:1962
#13 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:2136
#14 0x00000000004cb7c5 in lto_main () at ../../gcc/gcc/lto/lto.c:2872


...

#7  0x000000000075ac05 in tree_nrv () at ../../gcc/gcc/tree-nrv.c:155
155                     gcc_assert (ret_val == result);

(gdb) p ret_val
$3 = (tree_node *) 0x0

(gdb) pt result
type = union tree_node {
    tree_base base;
    tree_typed typed;
    tree_common common;
    tree_int_cst int_cst;
    tree_real_cst real_cst;
    tree_fixed_cst fixed_cst;
    tree_vector vector;
    tree_string string;
    tree_complex complex;
    tree_identifier identifier;
    tree_decl_minimal decl_minimal;
    tree_decl_common decl_common;
    tree_decl_with_rtl decl_with_rtl;
    tree_decl_non_common decl_non_common;
    tree_parm_decl parm_decl;
    tree_decl_with_vis decl_with_vis;
    tree_var_decl var_decl;
    tree_field_decl field_decl;
    tree_label_decl label_decl;
    tree_result_decl result_decl;
    tree_const_decl const_decl;
    tree_type_decl type_decl;
    tree_function_decl function_decl;
    tree_translation_unit_decl translation_unit_decl;
    tree_type_common type_common;
    tree_type_with_lang_specific type_with_lang_specific;
    tree_type_non_common type_non_common;
    tree_list list;
    tree_vec vec;
    tree_exp exp;
    tree_ssa_name ssa_name;
    tree_block block;
    tree_binfo binfo;
    tree_statement_list stmt_list;
    tree_constructor constructor;
    tree_omp_clause omp_clause;
    tree_optimization_option optimization;
    tree_target_option target_option;
} *

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

Andi Kleen <andi-gcc at firstfloor dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |4.7.0

--- Comment #1 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-10-03 16:40:47 UTC ---
Seen with 
gcc version 4.7.0 20111002 (experimental) (GCC)

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-04 11:03:58 UTC ---
#7  0x000000000075ac05 in tree_nrv () at ../../gcc/gcc/tree-nrv.c:155
155                     gcc_assert (ret_val == result);

(gdb) p ret_val
$3 = (tree_node *) 0x0

but ...

              ret_val = gimple_return_retval (stmt);
              if (ret_val)
                gcc_assert (ret_val == result);

so the assert is guarded against this case.

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #3 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-10-04 13:22:09 UTC ---
Hmm, are you saying gdb fooled me? 
Any other suggestions how to debug it?

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-04 14:19:56 UTC ---
(In reply to comment #3)
> Hmm, are you saying gdb fooled me? 

Yes.

> Any other suggestions how to debug it?

Can you provide the output of

(gdb) call debug_function (cfun->decl, TDF_UID)

at the point of the crash?  And eventually look which pass introduces
the 'return XXX;' with XXX that does not match what you get with

(gdb) call print_generic_expr (stderr, result, TDF_UID)

?

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #5 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-10-09 02:31:38 UTC ---
Looked at this now again

debug_function doesn't work. TDF_UID was also not available, but i hardcoded
it.

(gdb)  call debug_function (cfun->decl, 1<<8)
(gdb)

neither the other call

(gdb)  call print_generic_expr(stderr, result, 1 << 8)
(gdb) 

Looking at the code

0x000000000075a827 <tree_nrv()+311>:    test   %rax,%rax
0x000000000075a82a <tree_nrv()+314>:    je     0x75a7f2 <gsi_next>
0x000000000075a82c <tree_nrv()+316>:    cmp    %rax,%rbx
0x000000000075a82f <tree_nrv()+319>:    je     0x75a7f2 <gsi_next>
0x000000000075a831 <tree_nrv()+321>:    mov    $0xbe3bb7,%edx
0x000000000075a836 <tree_nrv()+326>:    mov    $0x9b,%esi
0x000000000075a83b <tree_nrv()+331>:    mov    $0xbe3b7a,%edi
0x000000000075a840 <tree_nrv()+336>:    callq  0xb488e0 <fancy_abort(char
const*, int, char const*)>
0x000000000075a845 <tree_nrv()+341>:    nopl   (%rax)


I'm in the fancy_abort

When I go up and print $rax I get 0

(gdb) p $rax
$11 = 0

But this cannot be because the test tested it for 0.  Perhaps the 
unwind information below is wrong?

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #6 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-10-09 04:05:52 UTC ---
i changed the code now to save ret_val in a volatile global.

This is a bit better

(gdb) p saved_ret_val
$5 = (volatile tree) 0x2afc557b68c0
(gdb) p result
$6 = (tree_node *) 0x2afbfb754a00

Still not sure how to print them, maybe stderr is broken.

Looking at raw output I see one of them is a VAR_DECL and the other
a RESULT_DECL

(gdb) p result->decl_minimal.uid
$9 = 83837
(gdb) p saved_ret_val->decl_minimal.uid
$10 = 3599083
(gdb) p cfun->decl->decl_minimal.uid
$3 = 83835


Searching for the second uid in the dump files I see it first in 
045i.whole-program:

 <bb 7>:
  return D.3599083;

and the first doesn't appear in any file (that means the current pass added
it?)
 The third is first in 049.inline

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #7 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-10-29 12:12:09 UTC ---
Created attachment 25659
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25659
reproducer


Managed to minimize now

Unpack the tar file and on x86-64

% gcc47 -m32 -O2 -flto arch/x86/kernel/apic/io_apic.i -c
% gcc47 -m32 -O2 -flto arch/x86/kernel/apic/io_apic.o
In file included from :10:0:
/home/ak/lsrc/git/linux-lto-2.6/arch/x86/kernel/apic/io_apic.c: In function
'ioapic_read_entry':
/home/ak/lsrc/git/linux-lto-2.6/arch/x86/kernel/apic/io_apic.c:397:35: internal
compiler error: in tree_nrv, at tree-nrv.c:155

The strange thing is that it doesn't reproduce if you copy the .i file to
another file name?!? And see also the weird ":10:0". Some memory corruption?

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

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

--- Comment #8 from Steven Bosscher <steven at gcc dot gnu.org> 2011-10-30 14:23:24 UTC ---
Can you please see if the failure reproduces if you build (not bootstap!) a
compiler with --enable-checking=gcac.

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #9 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-10-30 15:53:10 UTC ---
Sorry made a mistake and i supplied the wrong command line

With this

gcc47 -O2 -m32    -freg-struct-return io_apic.i -flto -c
gcc47 -O2 -flto io_apic.o

the test case ICEs hwith any path name.

I tested --enable-checking=gcac and expect for running extremly slowly it
didn't show any difference.

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #10 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-11-23 00:22:46 UTC ---
FWIW the problem is still there and prevents any 32bit kernel LTO builds

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
   Target Milestone|---                         |4.8.0

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-07 22:16:57 UTC ---
(In reply to comment #10)
> FWIW the problem is still there and prevents any 32bit kernel LTO builds

-freg-struct-return changes the ABI so I don't think this is testcase is valid.
 Can someone explain why -freg-struct-return used not on the link line also?

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #12 from Andi Kleen <andi-gcc at firstfloor dot org> 2012-01-08 01:37:29 UTC ---
LTO saves the options in the object files and collects them for the final
link. This works as far as I know.

The only thing it cannot handle is different incompatible options in different
files (but that's more a limitation in LTO than "incorrect code"). The test
case doesn't do that.

I disagree with your assessment that the test case is invalid. Please undo it.

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #13 from Andi Kleen <andi-gcc at firstfloor dot org> 2012-05-02 14:23:57 UTC ---
This still happens with a recent 4.7 and bites 32bit Linux kernel builds badly

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf <markus at trippelsdorf dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markus at trippelsdorf dot
                   |                            |de

--- Comment #14 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2012-05-02 14:51:10 UTC ---
Here is a small testcase:

markus@x4 tmp % cat test.i
typedef __u32;
struct IO_APIC_route_entry {
  __u32:1
}
;
struct syscore_ops {
  int suspend
};
struct {
  struct IO_APIC_route_entry entry
    }
a;
b;
struct IO_APIC_route_entry
ioapic_read_entry () {
  io_apic_read (2 * b);
  return a.entry;
}
save_ioapic_entries () {
  ioapic_read_entry ();
}
print_ICs () {
  ioapic_read_entry ();
}
__initcall_print_ICs7 __attribute__ ((__used__)) = print_ICs;
struct syscore_ops c = {.suspend = save_ioapic_entries };
ioapic_init_ops () {
  register_syscore_ops (&c);
}
__initcall_ioapic_init_ops6 __attribute__ ((__used__)) = ioapic_init_ops;

markus@x4 tmp % gcc -w -flto -m32 -freg-struct-return -c test.i
markus@x4 tmp % gcc -O2 -flto test.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../x86_64-pc-linux-gnu/bin/ld:
error: test.o: incompatible target
In file included from :0:0:
test.i: In function ‘ioapic_read_entry’:
test.i:15:1: internal compiler error: in tree_nrv, at tree-nrv.c:155
Please submit a full bug report,
with preprocessed source if appropriate

gcc-4.6.3 is also affected.

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[markus at trippelsdorf dot de]

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

--- Comment #15 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2012-05-02 15:18:53 UTC ---
This one is nicer (compiles without warnings):

typedef __u32;
typedef (*initcall_t) ();
struct IO_APIC_route_entry {
  __u32 dest;
}
;
struct syscore_ops {
  int (*suspend) ();
}
;
struct {
  struct IO_APIC_route_entry entry;
}
a;
int b;
struct IO_APIC_route_entry
ioapic_read_entry () {
  io_apic_read (2 * b);
  return a.entry;
}
save_ioapic_entries () {
  ioapic_read_entry ();
}
print_ICs () {
  ioapic_read_entry ();
}
initcall_t c __attribute__ ((__used__)) = print_ICs;
struct syscore_ops d = {.suspend = save_ioapic_entries };
ioapic_init_ops () {
  register_syscore_ops (&d);
}
initcall_t e __attribute__ ((__used__)) = ioapic_init_ops;

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-05-03
          Component|tree-optimization           |lto
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-03 14:51:29 UTC ---
At least the last testcase is because the link line misses -freg-struct-return
which changes the ABI.

This (and similar switches) would need to be added to the LTO option merging
code in lto-wrapper.c.  It would be the first case where we need to complain.

So I think this bug is invalid - but we can do better and diagnose that.

I'll put it on my TODO (if you don't beat me to it).

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #17 from Andi Kleen <andi-gcc at firstfloor dot org> 2012-05-03 14:57:13 UTC ---
Hmm, my assumption was always that this option would be passed through and then
used by lto1 step. That's true  for other -f* options at least.

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> 2012-05-04 08:17:57 UTC ---
On Thu, 3 May 2012, andi-gcc at firstfloor dot org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
> 
> --- Comment #17 from Andi Kleen <andi-gcc at firstfloor dot org> 2012-05-03 14:57:13 UTC ---
> Hmm, my assumption was always that this option would be passed through and then
> used by lto1 step. That's true  for other -f* options at least.

No, we do

  /* The following does what the old LTO option code did,
     union all target and a selected set of common options.  */
  for (i = 0; i < fdecoded_options_count; ++i)
    {
      struct cl_decoded_option *foption = &fdecoded_options[i];
      switch (foption->opt_index)
        {
        default:
          if (!(cl_options[foption->opt_index].flags & CL_TARGET))
            break;

thus only pass through all target options and the explicitely listed
set of common options.

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-04 11:00:36 UTC ---
Patch I am testing:

Index: gcc/lto-wrapper.c
===================================================================
--- gcc/lto-wrapper.c   (revision 187148)
+++ gcc/lto-wrapper.c   (working copy)
@@ -414,6 +414,16 @@ merge_and_complain (struct cl_decoded_op
          if (j == *decoded_options_count)
            append_option (decoded_options, decoded_options_count, foption);
          break;
+
+       case OPT_freg_struct_return:
+       case OPT_fpcc_struct_return:
+         for (j = 0; j < *decoded_options_count; ++j)
+           if ((*decoded_options)[j].opt_index == foption->opt_index)
+             break;
+         if (j == *decoded_options_count)
+           fatal ("Option %s not used consistently in all LTO input files",
+                  foption->orig_option_with_args_text);
+         break;
        }
     }
 }
@@ -558,6 +568,8 @@ run_gcc (unsigned argc, char *argv[])
        case OPT_fcommon:
        case OPT_fexceptions:
        case OPT_fgnu_tm:
+       case OPT_freg_struct_return:
+       case OPT_fpcc_struct_return:
          break;

        default:
@@ -619,6 +631,12 @@ run_gcc (unsigned argc, char *argv[])
          /* We've handled these LTO options, do not pass them on.  */
          continue;

+       case OPT_freg_struct_return:
+       case OPT_fpcc_struct_return:
+         /* Ignore these, they are determined by the input files.
+            ???  We fail to diagnose a possible mismatch here.  */
+         continue;
+
        default:
          break;
        }

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-04 11:47:10 UTC ---
Author: rguenth
Date: Fri May  4 11:47:06 2012
New Revision: 187155

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187155
Log:
2012-05-04  Richard Guenther  <rguenther@suse.de>

    PR lto/50602
    * lto-wrapper.c (merge_and_complain): Complain about mismatches
    of -freg-struct-return and -fpcc-struct-return.
    (run_gcc): Pass through -freg-struct-return and -fpcc-struct-return
    from the input file options and ignore those from the link
    command line.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lto-wrapper.c

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
           Severity|normal                      |enhancement

--- Comment #21 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-04 11:47:55 UTC ---
Fixed on trunk.

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #22 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-05-05 10:02:15 UTC ---
great, backporting to 4.7 should be easy, right?

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> 2012-05-07 08:54:10 UTC ---
On Sat, 5 May 2012, hubicka at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
> 
> Jan Hubicka <hubicka at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |hubicka at gcc dot gnu.org
> 
> --- Comment #22 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-05-05 10:02:15 UTC ---
> great, backporting to 4.7 should be easy, right?

I'm not sure we should backport option handling changes.  In general
we still expect consistent options at compile and link time (that did
not change in 4.7 - what changed was the implementation).

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi at firstfloor dot org]

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

--- Comment #24 from andi at firstfloor dot org 2012-05-07 13:08:08 UTC ---
On Mon, May 07, 2012 at 08:54:10AM +0000, rguenther at suse dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
> 
> --- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> 2012-05-07 08:54:10 UTC ---
> On Sat, 5 May 2012, hubicka at gcc dot gnu.org wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
> > 
> > Jan Hubicka <hubicka at gcc dot gnu.org> changed:
> > 
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >                  CC|                            |hubicka at gcc dot gnu.org
> > 
> > --- Comment #22 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-05-05 10:02:15 UTC ---
> > great, backporting to 4.7 should be easy, right?
> 
> I'm not sure we should backport option handling changes.  In general
> we still expect consistent options at compile and link time (that did
> not change in 4.7 - what changed was the implementation).

I worked around it in my kernel build, so it's not critial.

But there are other problems back now :-(

-Andi