This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Is this a bug?
- To: slayer at ccl dot itri dot org dot tw
- Subject: Re: Is this a bug?
- From: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Date: Sun, 30 Jan 2000 11:43:02 +0100
- CC: gcc-bugs at gcc dot gnu dot org
- References: <007d01bf6988$d2fb0c40$795d608c@ccl.itri.org.tw>
> As a result, we can't use this compiler to compile
> libgcc1.c in order to provide the unsigned integer mod.
> This situation becames to a self-calling recurrsive.
> Some other machine is containing this umodsi3 in
> ".md" file but Vax is not. Should we patch this one
> to vax.md or in libgcc1?
I believe the way this is supposed to work is the following: If the
architecture does not define perform_umodsi3, it is defined as
#define perform_umodsi3(a, b) return a % b
This is compiled with the native compiler of the host system (i.e. a
VMS compiler), which knows how to perform integer division. Then
you'll use the implementation of perform_umodsi3 provided by that
compiler.
That approach breaks for cross-compilation. Please see "(gcc)Cross
Runtime" in the manual for a detailed discussion; you essentially have
to provide a precompiled libgcc1 for the target system.
Alternatively, you could provide definitions of the relevant perform_
macros for the VAX. You should put them into vax.h (or into a separate
perform.h, as done for i386). When you follow this approach, please
send your patches to gcc-patches@gcc.gnu.org when you are done.
Yet another alternative is to modify the .md file, and avoid
generation of function calls for these insns altogether. If you are
familiar with GCC backend technology, that approach might be even more
useful.
Regards,
Martin