[PATCH] Add word-sized conversion functions to libgcc2

[Adam Nemet]

Richard Sandiford writes:
> This message is probably going to annoy you, sorry, because I'm
> going to propose an alternative patch.  However, even if we go with
> that alternative patch, your description of the problem has surely
> helped me get this far.  I'll leave it up to the reviewer (hi Mark!) 
> to decide which approach to go for, or whether we should do
> something else entirely.

The only time I get annoyed if my patch gets ignored.  Everything else
is fine with me:).

You raise three issues with my patch:

  1. The counter-intuitive naming convention of conversion functions
  in libgcc2.c is now exposed to the backend.

  This is easy to fix as you do in your patch I could just have a
  boolean flag like LIB2WORD_CONVERSION_FUNCS that backends can
  define.  Based on this flag I can later add the new names in
  mklibgcc.in.

  2. I don't generate the functions Roger has added but basically keep
  them around.  This I think is easy to fix too but just adding the
  names into LIB2FUNCS_OPT.  I just wanted to minimize my changes so
  that I could apply the same patch to 4.1 as well.

  3. I extend the old unfortunate design which apparently is very
  prone to error.

  This I think is the decisive argument either way and I think the
  question that we need to answer is whether your design is a step in
  the right direction.

  The other possible argument that my change is less intrusive is
  probably not a very strong one.  I read Richard's patch and I think
  it is very easy to see that on other targets it falls back on the
  existing behavior so I think the solution is at least as safe as
  mine is.

  But getting back to the design question, I think we all agree that
  the current design of libgcc2.c and how it works for 64-bit targets
  is broken and needs to be revised.  The basic idea of your patch is
  to add an optional format to how lib2funcs are requested.  The
  format is <objfile>:<func>:<wordsize>.  The question is whether this
  is required in the long run interface-wise and whether just
  specifying e.g. fixunsdfdi would not hold enough information for
  libgcc2.c to generate the right functionality.  Note that even with
  this patch we still have misnamed object files for all other
  DI-functions.

  If we need to keep word size "changeable" across different libgcc2.c
  complations then I agree that Richard's patch is a step in the right
  direction if not then I am not sure why go through the hassle of
  generalizing something that should really go away.

  Now I can see that Mark has already approved the patch but I would
  still appreciate a reply clarifying this last issue.

Adam