This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Unreviewed patches
- From: Jim Wilson <wilson at specifixinc dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 10 Sep 2003 22:59:29 -0700
- Subject: Re: Unreviewed patches
- References: <20030908.081201.130231675.kazu@cs.umass.edu>
Kazu Hirata wrote:
[patch] Clean up FUNCTION_ARG_PADDING.
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00128.html
Playing with FUNCTION_ARG_PADDING is very dangerous. You could easily
break an ABI, and not realize it until well after a release.
Eliminating the duplicate definitions is a good idea though, and the
patch does seem reasonably safe.
I don't really see the point of making FUNCTION_ARG_PADDING into a
function though. None of the other related macros in this file are
functions. Why not just rename it to DEFAULT_FUNCTION_ARG_PADDING, and
then make that the default definition of FUNCTION_ARG_PADDING?
[patch] combine.c: Convert (ne (and (lshiftrt (xor X CST) Y) 1) 0) into (eq (and (lshiftrt X Y) 1) 0). (take 3)
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01315.html
1 << INTVAL (shift_count))))
This part can fail. You want to use (HOST_WIDE_INT) 1 instead of just
1, and you need to verify that the shift_mode is smaller than or equal
to the size of HOST_WIDE_INT. See similar examples in simplify_shift_const.
If handling XOR here makes sense, then does it also make sense in the
similar code immediately above?
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com