This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, mips] Fix warning when using --with-synci
Steve Ellcey <sellcey@mips.com> writes:
> That is basically what I am trying to do, build a GCC cross compiler for
> the mips-linux-gnu target that can support both ABI's/architectures that
> have synci and ones that don't.
>
> I haven't verified this but if I build a GCC for the mips64-linux-gnu
> target and configure it with --with-synci and then use that compiler
> with the -mabi=32 won't I run into this same problem? I think I would
> get a warning on those compilations and because of that the libstdc++
> build will fail. I will try that when I get a chance but I don't have a
> mips64-linux-gnu GCC right now.
It ought to work. mips64-linux-gnu itself defaults to MIPS I for 32-bit
and MIPS III for 64-bit, so --with-synci on its own wouldn't be much use.
But if you configure with --with-arch=mips64r2 --with-synci, say,
then -mabi=32 should build o32 for mips64r2.
>> Is it mips-sde-elf you're interested in, or something else? And do
>> you think builds both with and without --with-synci are useful for that
>> configuration? (Instead of having multilibs for both, say. The default
>> would be up to you.)
>
> I was looking at the mips-linux-gnu target and trying to build a
> multilib version of it with:
>
> MULTILIB_OPTIONS = EL/EB msoft-float mips32
>
> It is the -mips32 that gives me the problem. Even if I tied this to a
> different target name I would still have the problem of not wanting a
> warning message when compiling with -mips32 but wanting synci for the
> other compilations.
If you use a different target name, the specs for that target can
enforce whatever triplet-specific defaults you want. See the
DRIVER_SELF_SPECS in vr.h for a particularly involved example.
(Yours shouldn't need to be as bad!)
How are you expecting to use this configuration? Is the sysroot
that backs it going to have C libraries for all combinations?
I assume so, since otherwise you wouldn't be able to build
more than libgcc.
If so, we need to define what the OS library directories
are for -EB vs -EL, -mhard-float vs. -msoft-float, etc.
Are you planning to extend the IRIX lib/lib32/lib64 system,
or use the Debian/Ubuntu multiarch?
Richard