emit_library_call_value_1() in calls.c can call emit_push_insn() with type=NULL_TREE and mode != BLKMode If STRICT_ALIGNMENT is defined for the target, then, emit_push_insn() will call assign_temp (see about 40 lines into the function), passing NULL_TREE as the first param. This results in a SEGFAULT as assign_temp calls DECL_P on NULL_TREE.
emit_push_insn (val, mode, NULL_TREE, NULL_RTX, PARM_BOUNDARY, partial, reg, 0, argblock, GEN_INT (argvec[argnum].locate.offset.constant), reg_parm_stack_space, ARGS_SIZE_RTX (argvec[argnum].locate.alignment_pad)); This only causes an issue if: enum machine_mode mode = argvec[argnum].mode; is going to be BLKmode or PARM_BOUNDARY < GET_MODE_ALIGNMENT (mode).
So the question comes what target has a mode where STRICT_ALIGNMENT is going to be true and the alignment of the stack is going to be less than the alignment of that mode? I think this is invalid. Now x86 has a mode who's alignment is less than PARM_BOUNDARY but that is because the ABI was set in stone before those registers was added. Do you have a target which this effects? Is there a reason why the stack alignment is less than the largest required alignment of the modes?
This is a port to a new target I am working on, so thanks for investigating. Are you saying that PARAM_BOUNDARY and STACK_BOUNDARY must be >= BIGGEST_ALIGNMENT? Looking through the other ports it appears this may not be the case for m68k (depending upon command line options) and also the score port. However, for the port I'm currently updating, I think I can reduce the size of BIGGEST_ALIGNMENT to match STACK_BOUNDARY and PARAM_BOUNDARY. Thanks.
Problem with an out-of-tree port doing something that GCC doesn't support. Good note about the m68k issue that affects the netbsd port, which is being tracked via a different BZ.