Looks like a possible bug in the .md:

          gcc_assert (insn_data[(int) icode].n_operands == 3);

but more information would be appreciated here.

Note, it is only a regression if it worked in a previous _released_ version of GCC.  You have not filled out the "known-to-..."-fields.  Did this work in earlier releases?

This seems to have started with revision 130333, but I don't think that change is to blame:

(gdb) bt
#0  frv_secondary_reload_class (class=ICC_REGS, mode=BImode, x=0x2b0f0ec48d80, in_p=0) at /n/12/rask/src/all/gcc/config/frv/frv.c:6347
#1  0x000000000073430a in default_secondary_reload (in_p=0 '\0', x=0x2b0f0ec48d80, reload_class=GPR_REGS, reload_mode=BImode, sri=0x7fff9c430880)
    at /n/12/rask/src/all/gcc/targhooks.c:595
#2  0x00000000006bca5c in secondary_reload_class (in_p=1 '\001', class=GPR_REGS, mode=VOIDmode, x=0x7) at /n/12/rask/src/all/gcc/reload.c:525
#3  0x00000000006aa82f in init_regs () at /n/12/rask/src/all/gcc/regclass.c:1285
#4  0x0000000000737032 in backend_init_target () at /n/12/rask/src/all/gcc/toplev.c:2040
#5  0x000000000073751a in toplev_main (argc=<value optimized out>, argv=<value optimized out>) at /n/12/rask/src/all/gcc/toplev.c:2086
#6  0x00002b0f0ea1d4ca in __libc_start_main () from /lib/libc.so.6
#7  0x0000000000403c2a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) fin
Run till exit from #0  frv_secondary_reload_class (class=ICC_REGS, mode=BImode, x=0x2b0f0ec48d80, in_p=0) at /n/12/rask/src/all/gcc/config/frv/frv.c:6347
default_secondary_reload (in_p=0 '\0', x=0x2b0f0ec48d80, reload_class=GPR_REGS, reload_mode=BImode, sri=0x7fff9c430880)
    at /n/12/rask/src/all/gcc/targhooks.c:597
Value returned is $16 = GPR_REGS

The next few lines of code read:
  if (class != NO_REGS)
    {
      enum insn_code icode = (in_p ? reload_in_optab[(int) reload_mode]
                              : reload_out_optab[(int) reload_mode]);

(gdb) print icode
$19 = 0
(gdb) print insn_data[0]->name
$20 = 0xb8e5ba "*movqi_load"
(gdb) print insn_data[0]->n_operands
$21 = 2 '\002'

   I.e. we get the wrong icode.

(gdb) print reload_in_optab
$22 = {0 <repeats 45 times>}
(gdb) print reload_out
$23 = {0 <repeats 45 times>}

   I would have expected a default of CODE_FOR_nothing, not 0. I think this is a problem with the new lazy optab initialization. We now call backend_init_target() and init_regs() before calling init_optabs().

Created attachment 14643 [details]
patch v1

This patch makes the ICE go away.

FRV is not a primary or secondary platform.  Is there a test-case for this on another platform?

Created attachment 14678 [details]
patch v2

The first patch caused build failure on sh and arm, this one fixes that.

It's the dataflow merge (125624) that broke it. Revision 125623 with 130333 on top is fine, but 125624 with 125851 (so it builds) and 130333 on top fails.
The patch in comment #6 has one testsuite regression on arm-unknown-elf:
FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors)

Subject: Re:  [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612

On 16 Dec 2007 12:55:21 -0000, rask at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
> The patch in comment #6 has one testsuite regression on arm-unknown-elf:
> FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error)
> FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors)

That is not a regression ....  Just an already existing failure.

-- Pinski

> That is not a regression ....  Just an already existing failure.

Unmodified trunk revision 130944 doesn't have it:
diff -u build/arm-unknown-elf-results-unpatched/summary build/arm-unknown-elf-results-patched/summary
--- build/arm-unknown-elf-results-unpatched/summary     2007-12-15 02:26:10.000000000 +0100
+++ build/arm-unknown-elf-results-patched/summary       2007-12-16 04:17:59.000000000 +0100
@@ -17,6 +17,9 @@
 FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized "nasty_local" 0
 FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
 FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
+FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error)
+FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors)
+UNRESOLVED: gcc.dg/struct/wo_prof_malloc_size_var.c compilation failed to produce executable
 FAIL: gcc.dg/struct/wo_prof_single_str_global.c execution test
 FAIL: gcc.dg/struct/wo_prof_single_str_local.c execution test
 FAIL: gcc.dg/struct/wo_prof_single_str_pointer.c execution test

> That is not a regression ....  Just an already existing failure.
OK, looks like an intermittent failure which happens about one out of four times.

Update milestone after 4.3.0 release.

A simple
'int main (int argc, char *argv[]) { return 0; }'
still fails with "error: in default_secondary_reload, at
targhooks.c:612" in rev. 133684 (trunk).

                                           

Rask, what is the status of your patch?

It would be nice if this bug was fixed.

4.3.1 is being released, adjusting target milestone.

4.3.2 is released, changing milestones to 4.3.3.

GCC 4.3.3 is being released, adjusting target milestone.

GCC 4.3.4 is being released, adjusting target milestone.

GCC 4.3.5 is being released, adjusting target milestone.

4.3 branch is being closed, moving to 4.4.7 target.

4.4 branch is being closed, moving to 4.5.4 target.

Doesn't ice for me at trunk r193358.