This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SIZE_TYPE predefine not following CPU flags on embedded mips
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: Neil Booth <neil at daikokuya dot co dot uk>, gcc at gcc dot gnu dot org, echristo at redhat dot com
- Date: Thu, 09 Jan 2003 08:34:14 -0600
- Subject: Re: SIZE_TYPE predefine not following CPU flags on embedded mips
- Organization: OAR Corporation
- References: <3E1C5845.28553FA2@OARcorp.com> <20030108200950.GA20681@daikokuya.co.uk>
Neil Booth wrote:
>
> Joel Sherrill wrote:-
>
> > I have tracked this down to size_t being an "unsigned int".
> > NO_BUILTIN_SIZE_TYPE is set in the mips config
> > files and the specs I see with -dumpspecs appear to
> > trip on the combination "-mabi=eabi -mips3" instead of just
> > -mips3.
> >
> > This is in an odd corner of the mips port and I don't the right
> > thing to do. Help would definitely be appreciated.
>
> Does GCC 3.3 get it right? It should do.
It does work well enough to let me add the mips3 multilib variants,
successfully build the compiler, and link the application that would
not link before because it couldn't find a mips3 libc.a.
> Do you really need it
> to work in 3.2? The problem will be in the SPECS in the header file.
No. RTEMS keeps up with gcc releases so if I can successfully
use gcc 3.3 with Eric's patch to address the remaining issues
he knew of, then I am happy.
When the MIPS rework is merged into the trunk will it be OK for
mips-elf to build mips3 variants also?
Also I noticed that in the 3.3 branch, the multilib match for
4650 is gone. What is the proper way to compile and link for
a 4600/4650 these days?
> Neil.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985