[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gcc tri-arch support



On Fri, 4 Nov 2005, Thiemo Seufer wrote:

We should probably have an consistent naming scheme for o32/n32/n64, and
avoid _both_ mips32 and mips64 because they are already overloaded in
their meaning (I would expect a package with -mips32 to be a version
optimized for MIPS32 ISA). The names "mipsn32" and "mipsn64" may look
a bit funny, but at least it's clear what they stand for.

Good point. Which would be better? -mipsn32/-mipsn64 or just -n32/-n64
as Guido suggested? I don't think the pattern used on other archs helps
us much on this.


Not NPTL instead of linuxthreads?

I was under the impression that NPTL is not quite ready for mips. Also,
it looks like the current package is using linuxthread, so I wanted to
match that.


The canonical way to select the ABI for a mips compiler is via -mabi=.
-32/-64 stem from the IRIX compiler, and are only left for backward
compatibility.

I added this because I ran into something that was trying to use -32/-64
in a configure type script.

+# DP: Fix up the directory names so that o32 is the default and the
+# DP: 32 & 64 bit names follow the same convention as is used by glibc

Be aware that this is somewhat broken. A mips64-linux compiler has
different predefined macros than a mips-linux compiler when compiling
for the same ABI. I have a patch for this and hope to bring it upstream
in the next weeks.

Will this affect what the directory names should be?

-f95_no_cpus :=
+f95_no_cpus := mips mipsel

-ada_no_cpus := alpha arm armeb m68k sh3 sh3eb sh4 sh4eb
+ada_no_cpus := alpha arm armeb m68k sh3 sh3eb sh4 sh4eb mips mipsel

Does this generally lose Ada and Fortran support for mips/mipsel?

If left like this it would. 8-) I can take this part out. It is left
over from where I was trying to just build the base parts while working out
the details. I left them out as I didn't know of a good way to validate
that they were working correctly. I guess we can assume they do work,
until proven otherwise.


                                Stuart

Stuart R. Anderson                               anderson@netsweng.com
Network & Software Engineering                   http://www.netsweng.com/
1024D/37A79149:                                  0791 D3B8 9A4C 2CDC A31F
                                                 BD03 0A62 E534 37A7 9149



Reply to: