This problem potentiall affects all all targets The data flow information that combine uses can cause Segmentation fault. I have found this with AVR experimental build but it would seem that it can affect any target.
The problem is that the LOG_LINKS that combine creates from DF can include multiple references between instruction pairs. DF will produce multiple reference between instructions if they share a register that decomposes into several smaller registers. The multiple cross references are then used by Combine to select instruction pairs and triples to match. This results in repeat trials of the same instructions! By was on an example, tThe RTL that triggered my problem was: (insn 45 42 46 4 920625-1.c:55 (set (reg:SI 22 r22 [ temp.24 ]) (mem:SI (reg/v/f:HI 71 [ alpha ]) [2 S4 A8])) 19 {*movsi} (nil)) (insn 46 45 47 4 920625-1.c:55 (set (reg:SI 18 r18) (mem:SI (plus:HI (reg:HI 68 [ ivtmp.18 ]) (const_int 4 [0x4])) [2 S4 A8])) 19 {*movsi} (nil)) (insn 47 46 48 4 920625-1.c:55 (parallel [ (set (reg:SI 22 r22) (mult:SI (reg:SI 22 r22) (reg:SI 18 r18))) (clobber (reg:HI 26 r26)) (clobber (reg:HI 30 r30)) ]) 43 {*mulsi3_call} (expr_list:REG_DEAD (reg:SI 18 r18) (expr_list:REG_UNUSED (reg:HI 30 r30) (expr_list:REG_UNUSED (reg:HI 26 r26) (nil))))) This is call to library function, and the parameter for instruction 47 are hard registers like SI:R22 - which is decomposed in DF as R22,23,24 and 25. DF marks all 4 sub parts in def/use chains (which seems entirely correct) When DF information is transferred into LOG_LINKS we still have 4 references back to the definition in instructions 45 and 47. From gdb this was: (gdb) print uid_log_links[47] $8 = (rtx) 0x7ff140d0 (gdb) pr (insn_list:REG_DEP_TRUE 45 (insn_list:REG_DEP_TRUE 45 (insn_list:REG_DEP_TRUE 45 (insn_list:REG_DEP_TRUE 45 (insn_list:REG_DEP_TRUE 46 (insn_list:REG_DEP_TRUE 4 6 (insn_list:REG_DEP_TRUE 46 (insn_list:REG_DEP_TRUE 46 (nil))))))))) These multiple references causes COMBINE to try the same combination of instruction 45 and 47 multiple times ( thinking they are different instructions). In this case the match is tried 4 times - 3 more than needed. Thi part appears most benign - except for processing time/memory used. BUT when combine tries three instructions, it can crash. In this example, combine ends up trying to combine 2 duplicate instruction 45 with 47: I1= (insn 45 42 46 4 920625-1.c:55 (set (reg:SI 22 r22 [ temp.24 ]) (mem:SI (reg/v/f:HI 71 [ alpha ]) [2 S4 A8])) 19 {*movsi} (nil)) I2= (insn 45 42 46 4 920625-1.c:55 (set (reg:SI 22 r22 [ temp.24 ]) (mem:SI (reg/v/f:HI 71 [ alpha ]) [2 S4 A8])) 19 {*movsi} (nil)) I3= (insn 47 46 48 4 920625-1.c:55 (parallel [ (set (reg:SI 22 r22) (mult:SI (reg:SI 22 r22) (reg:SI 18 r18))) (clobber (reg:HI 26 r26)) (clobber (reg:HI 30 r30)) ]) 43 {*mulsi3_call} (expr_list:REG_DEAD (reg:SI 18 r18) (expr_list:REG_UNUSED (reg:HI 30 r30) (expr_list:REG_UNUSED (reg:HI 26 r26) (nil))))) Combine merges I1 into i3 and deletes I1. Combine notes that the life of R22 terminates in I2 and attempt to put a REG_DEAD note on I2 - except of course the deletion of I1 also deletes the identical i2. Segmentation fault occurs. -- Summary: COMBINE repeating same matches and can SEG fault Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hutchinsonandy at aim dot com GCC host triplet: i686-oc-cyqwin GCC target triplet: avr-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35519