This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Add word-sized conversion functions to libgcc2
- From: Adam Nemet <anemet at caviumnetworks dot com>
- To: Richard Sandiford <richard at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, roger at eyesopen dot com, mark at codesourcery dot com
- Date: Wed, 17 May 2006 13:59:16 -0700
- Subject: Re: [PATCH] Add word-sized conversion functions to libgcc2
- References: <email@example.com> <firstname.lastname@example.org>
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
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
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
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.