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]

GCC-current fails to build for a Hitachi/H8 cross compiler


I am using a slightly modified version of the current branch of GCC
for building a Java cross compiler with for the Lego Mindstorms microcontroller,
which has a Hitachi/H8 microcontroller.  Since a few days now, the 
GCC-current has stopped to compile due to the introduction of the
new libgcc2.h file and some changes in the handling of PTRDIFF_TYPE, SIZE_TYPE
and WCHAR_TYPE.

The GCC version: gcc-current, CVS read access
Host system: FreeBSD 3.2
Target system: Hitachi/H8 (h8300), custom operating system

When compiling GCC, everything goes well until the compilation
of libgcc2.  Then, during the first attempt, the compilation
breaks at libgcc2.h

In file included from ../../gcc-current/egcs/gcc/libgcc2.c:52:
../../gcc-current/egcs/gcc/libgcc2.h:274: conflicting types for `__fixunsdfhi'
../../gcc-current/egcs/gcc/libgcc2.h:272: previous declaration of `__fixunsdfhi'
../../gcc-current/egcs/gcc/libgcc2.h:276: conflicting types for `__fixunssfhi'
../../gcc-current/egcs/gcc/libgcc2.h:273: previous declaration of `__fixunssfhi'

This seems to be caused by the earlier definitions of 
__fixunsdfsi, __fixunsdfdi, __fixunssfsi, and __fixunssfdi.
The net result of the macros _NW and _NDW seems to be

#define __fixunsdfdi __fixunsdfsi
#define __fixunsdfsi __fixunsdfhi

which results both __fixunsdfdi and __fixunsdfsi being
defined as __fixunsdfhi.  Since the types of __fixunsdfsi
and __fixunsdfdi are different, the compilation fails.
The same applies for __fixunssfdi and __fixunssfsi.

If I hack around this problem, the second problem seems to be emerge
from the changed usage of PTRDIFF_TYPE, SIZE_TYPE and WCHAR_TYPE.
For some reason, these get defined on the preprosessor command
line as _empty_strings_.  That causes compilation of anything using
stddef.h to fail.  The Hitachi H8 backend has its own definitions
for these macros; maybe the are prosessed somehow wrong?

These two problems may be related or not, I don't know the internals
of GCC well enough.

I am willing to try to fix these problems myself, and have tried for
a couple of days, but since I don't know enough of the intended usage
of the used macros, I am pretty much on thin ice.  If someone is willing
to guide me, I can try to provide patches. 

--Pekka Nikander
  Helsinki University of Technology

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