Fix argument pushes to unaligned stack slots

hi folks.

i'm having a problem with GCC 4.5.3 on netbsd-m68k target.  i've tracked
it down to this change from several years ago:

> 2007-02-06  Joseph Myers  <joseph@codesourcery.com>
> 
> 	* expr.c (emit_push_insn): If STRICT_ALIGNMENT, copy to an
> 	unaligned stack slot via a suitably aligned slot.

the problem is that emit_library_call_value_1() calls emit_push_insn()
with TYPE_NULL which ends up triggering a NULL deref when emit_push_insn()
calls assign_temp() with type = TYPE_NULL, and assign_temp() crashes.

this simple change seems to be sufficient to avoid the crash and the
generated code appears to run OK.  if it is OK, could someone please
commit it?  thanks.  (feel free to update my log message if it could
be clearer or more correct.)


.mrg.


2011-07-10  matthew green  <mrg@eterna.com.au>

	* expr.c (emit_push_insn): Don't copy a TYPE_NULL expression
	to the stack for correct alignment.

On Tue, 12 Jul 2011, matthew green wrote:

> i'm having a problem with GCC 4.5.3 on netbsd-m68k target.  i've tracked
> it down to this change from several years ago:
> 
> > 2007-02-06  Joseph Myers  <joseph@codesourcery.com>
> > 
> > 	* expr.c (emit_push_insn): If STRICT_ALIGNMENT, copy to an
> > 	unaligned stack slot via a suitably aligned slot.
> 
> the problem is that emit_library_call_value_1() calls emit_push_insn()
> with TYPE_NULL which ends up triggering a NULL deref when emit_push_insn()
> calls assign_temp() with type = TYPE_NULL, and assign_temp() crashes.
> 
> this simple change seems to be sufficient to avoid the crash and the
> generated code appears to run OK.  if it is OK, could someone please

I don't see how it can be safe; if the stack slot is insufficiently 
aligned, the special handling will be needed.  Maybe the alignment being 
passed to this code is wrong, but if it's correct then you need a way to 
handle the unaligned move properly; I don't know if it would be possible 
or safe to pass a non-NULL type here, for example.

> On Tue, 12 Jul 2011, matthew green wrote:
> 
> > i'm having a problem with GCC 4.5.3 on netbsd-m68k target.  i've tracked
> > it down to this change from several years ago:
> > 
> > > 2007-02-06  Joseph Myers  <joseph@codesourcery.com>
> > > 
> > > 	* expr.c (emit_push_insn): If STRICT_ALIGNMENT, copy to an
> > > 	unaligned stack slot via a suitably aligned slot.
> > 
> > the problem is that emit_library_call_value_1() calls emit_push_insn()
> > with TYPE_NULL which ends up triggering a NULL deref when emit_push_insn()
> > calls assign_temp() with type = TYPE_NULL, and assign_temp() crashes.
> > 
> > this simple change seems to be sufficient to avoid the crash and the
> > generated code appears to run OK.  if it is OK, could someone please
> 
> I don't see how it can be safe; if the stack slot is insufficiently 
> aligned, the special handling will be needed.  Maybe the alignment being 
> passed to this code is wrong, but if it's correct then you need a way to 
> handle the unaligned move properly; I don't know if it would be possible 
> or safe to pass a non-NULL type here, for example.

how can i confirm if it is wrong alignment being passed down?

i looked around for a little bit to see if some non-NULL type
could be passed in from emit_library_call_value_1() (or other
callers in the path) but i did not see any way.

i happy to play around with trying to fix this the right way,
but i haven't looked at this part of GCC before so any guidance
would be greatly appreciated.  thanks.


.mrg.

On Fri, 22 Jul 2011, matthew green wrote:

> > I don't see how it can be safe; if the stack slot is insufficiently 
> > aligned, the special handling will be needed.  Maybe the alignment being 
> > passed to this code is wrong, but if it's correct then you need a way to 
> > handle the unaligned move properly; I don't know if it would be possible 
> > or safe to pass a non-NULL type here, for example.
> 
> how can i confirm if it is wrong alignment being passed down?

By comparing the alignment passed with what, according to the ABI in use 
(which may or may not be documented), is the actual guaranteed alignment 
of the stack slot.