This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Is this a bug?


> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]