This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Is this a bug?
- To: gcc-bugs at gcc dot gnu dot org
- Subject: Is this a bug?
- From: Kuo Yu Chuang <slayer at felix dot os dot nctu dot edu dot tw>
- Date: Mon, 31 Jan 2000 08:30:54 +0800 (CST)
Good days, and sorry for the inconvenience I made ^_^
I don't know if this is a bug, or just a misunderstanding :-P
I am currently using the GCC as a corss-compiler which
target is VAX machine. The host is i386 arch with linux.
Here is the test program I wrote:
main( )
{
unsigned int a, b;
a = 10;
b = 5;
a = a % b;
}
In the VAX-assembly, it calls "umodsi3" to achieve mod of
the two unsigned integer. However, in libgcc1.c, the umodsi3
is also implemented in following statements:
#define perform_umodsi3(a, b) return a % b
nongcc_SI_type
__umodsi3 (a, b)
unsigned nongcc_SI_type a, b;
{
perform_umodsi3 (a, b);
}
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?
(to emulate umodsi3 with signed integer?)
Thank you in advance :-)
==================
Kuo-Yu Slayer Chuang
Computer & Communications Research Laboratories
Software Engineer
Industrial Technology Research Institute, Taiwan.
E-mail: slayer@itri.org.tw
==================