Confirmed. Also happens when building Firefox with -march=amdfam10.
Vladimir?

Started with r210964 (doesn't compile) or r210965.

This is due to the use of the "enabled" attribute in:

(define_insn "*float<SWI48:mode><MODEF:mode>2_sse"
  [(set (match_operand:MODEF 0 "register_operand" "=f,x,x")
	(float:MODEF
	  (match_operand:SWI48 1 "nonimmediate_operand" "m,r,m")))]
  "SSE_FLOAT_MODE_P (<MODEF:MODE>mode) && TARGET_SSE_MATH"
  "@
   fild%Z1\t%1
   %vcvtsi2<MODEF:ssemodesuffix><SWI48:rex64suffix>\t{%1, %d0|%d0, %1}
   %vcvtsi2<MODEF:ssemodesuffix><SWI48:rex64suffix>\t{%1, %d0|%d0, %1}"
  [(set_attr "type" "fmov,sseicvt,sseicvt")
   (set_attr "prefix" "orig,maybe_vex,maybe_vex")
   (set_attr "mode" "<MODEF:MODE>")
   (set (attr "prefix_rex")
     (if_then_else
       (and (eq_attr "prefix" "maybe_vex")
	    (match_test "<SWI48:MODE>mode == DImode"))
       (const_string "1")
       (const_string "*")))
   (set_attr "unit" "i387,*,*")
   (set_attr "athlon_decode" "*,double,direct")
   (set_attr "amdfam10_decode" "*,vector,double")
   (set_attr "bdver1_decode" "*,double,direct")
   (set_attr "fp_int_src" "true")
   (set (attr "enabled")
     (cond [(eq_attr "alternative" "0")
              (symbol_ref "TARGET_MIX_SSE_I387
                           && X87_ENABLE_FLOAT (<MODEF:MODE>mode,
                                                <SWI48:MODE>mode)")
            (eq_attr "alternative" "1")
              /* ??? For sched1 we need constrain_operands to be able to
                 select an alternative.  Leave this enabled before RA.  */
              (symbol_ref "TARGET_INTER_UNIT_CONVERSIONS
                           || optimize_function_for_size_p (cfun)
                           || !(reload_completed
                                || reload_in_progress
                                || lra_in_progress)")
           ]
           (symbol_ref "true")))
   ])

"enabled" was really only supposed to be used to enable or disable
alternatives according to the current subtarget, rather than enable
or disable them based on the current stage in the pass pipeline
or on whether the function is being compiled for size or speed.
I have an idea for handling the size/speed thing, but we need
to fix the ??? as well.

Any update on this?
Almost the entire polyhedron benchmark suite fails with -Ofast -march=bdver3.

If anyone is interested in what architecutres are affected without looking at the source code, there are rough statistics of ICEs encountered since it first appeared:
ICEs count | switch
     21 -march=bdver3
    160 -mtune=amdfam10
    134 -mtune=barcelona
    153 -mtune=bdver1
    129 -mtune=bdver2
    176 -mtune=bdver3
    145 -mtune=bdver4

The reason for so low -march= count is that I am no longer using the -march= switch. Other architectures are likely not affected.

*** Bug 61774 has been marked as a duplicate of this bug. ***

*** Bug 61824 has been marked as a duplicate of this bug. ***

Not sure if same or different - I am seeing

ChooseInitialTour.c:177:1: internal compiler error: in lra_update_insn_recog_data, at lra.c:1218

from trunk 20140820.

ice goes away when I remove -march=native.

Patch that fixes this issue has been submitted 
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02179.html

The idea is to prohibit changes to the "enabled" attribute during lra and reload pass.

(In reply to GGanesh from comment #9)
> Patch that fixes this issue has been submitted 
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02179.html
> 
> The idea is to prohibit changes to the "enabled" attribute during lra and
> reload pass.

I've tested your patch, but unfortunately gcc still ICEs (during Firefox
LTO build with -march=native on ancient Phenom II X4):

/var/tmp/mozilla-central/dom/mathml/nsMathMLElement.h: In member function ‘GetClientTop’:
/var/tmp/mozilla-central/dom/mathml/nsMathMLElement.h:42:0: internal compiler error: in lra_update_insn_recog_data, at lra.c:1221
   NS_FORWARD_NSIDOMELEMENT_TO_GENERIC
 ^
0x8136bc lra_update_insn_recog_data(rtx_insn*)
        ../../gcc/gcc/lra.c:1220
0x82a705 eliminate_regs_in_insn
        ../../gcc/gcc/lra-eliminations.c:1077
0x82a705 process_insn_for_elimination
        ../../gcc/gcc/lra-eliminations.c:1344
0x82a705 lra_eliminate(bool, bool)
        ../../gcc/gcc/lra-eliminations.c:1408
0x8247b0 lra_constraints(bool)
        ../../gcc/gcc/lra-constraints.c:4040
0x815001 lra(_IO_FILE*)
        ../../gcc/gcc/lra.c:2193
0x7d3406 do_reload
        ../../gcc/gcc/ira.c:5310
0x7d3406 execute
        ../../gcc/gcc/ira.c:5469
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

(In reply to GGanesh from comment #9)
> Patch that fixes this issue has been submitted 
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02179.html
> 
> The idea is to prohibit changes to the "enabled" attribute during lra and
> reload pass.

Here's a small testcase that still ICE's even with your patch applied:

 % cat utils.i
int a, b, c, e, f, g, h;
long *d;
__attribute__((cold)) void fn1() {
  int i = g | 1;
  for (; g; h++) {
    for (; a; e++) d[0] = c;
    if (0.002 * i) break;
    for (; b; f++) d[h] = 0;
  }
}

 % gcc -march=amdfam10 -O2 -c utils.i
utils.i: In function ‘fn1’:
utils.i:10:1: internal compiler error: in lra_update_insn_recog_data, at lra.c:1223
 }
 ^
0x8ddb6c lra_update_insn_recog_data(rtx_insn*)
        ../../gcc/gcc/lra.c:1222
0x8f4595 eliminate_regs_in_insn
        ../../gcc/gcc/lra-eliminations.c:1077
0x8f4595 process_insn_for_elimination
        ../../gcc/gcc/lra-eliminations.c:1344
0x8f4595 lra_eliminate(bool, bool)
        ../../gcc/gcc/lra-eliminations.c:1408
0x8df81e lra(_IO_FILE*)
        ../../gcc/gcc/lra.c:2278
0x89ddf6 do_reload
        ../../gcc/gcc/ira.c:5311
0x89ddf6 execute
        ../../gcc/gcc/ira.c:5470
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Created attachment 33496 [details]
Patch that splits float<...>_sse to interunit and nointerunit parts

I have patch that avoids problematic "enable" attribute in testing.

(In reply to Uroš Bizjak from comment #12)
 
> I have patch that avoids problematic "enable" attribute in testing.

Eh, the patch hits PR 60704...

LRA reuses data about enabled alternatives (through code in recog.c) from previous passes.  And the data are not right anymore.  There are two ways of fixing that:

o enable the alternative with only "m" for LRA (remove lra_in_progress from the definition of the attribute) as LRA can handle only "m" although reload can't.

o prevent reusing the data

I'll prepare and submit the patch for the second solution.  Although it would be wise with perfomance point of view to implement the first one too but I handle over this joba and the decision to x86 maintainers.

Author: vmakarov
Date: Thu Sep 18 15:57:06 2014
New Revision: 215358

URL: https://gcc.gnu.org/viewcvs?rev=215358&root=gcc&view=rev
Log:
2014-09-18  Vladimir Makarov  <vmakarov@redhat.com>

	PR target/61360
	* lra.c (lra): Call recog_init.

2014-09-18  Vladimir Makarov  <vmakarov@redhat.com>

	PR target/61360
	* gcc.target/i386/pr61360.c: New.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr61360.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra.c
    trunk/gcc/testsuite/ChangeLog

I see r216557 has been committed, isn't this resolved by that change?

(In reply to Jakub Jelinek from comment #16)
> I see r216557 has been committed, isn't this resolved by that change?

Yes, fixed by r216557.