On Thu, 2012-06-21 at 19:05 +0100, Richard Sandiford wrote:
> "Steve Ellcey " <sell...@mips.com> writes:
> > This patch addresses the problem of building GCC for mips with the
> > '--with-synci' configure option. If you do that and then compile a
> > program with GCC and specify an architecture that does not support synci
> > (such as the -mips32 option), GCC will issue a warning that synci
> > is not supported. This results in many problems including an inability
> > to build a multilib version of GCC that includes -mips32. This
> > patch changes the gcc driver to pass --msynci-if-supported to cc1
> > instead of -msynci so that cc1 will only turn on synci if it is
> > supported on the architecture being compiled for and will leave it off
> > (and not generate a warning) if it is not supported on that architecture.
> > If the user specifically uses -msynci, they still get the warning.
>
> I think --with-synci should be equivalent to -msynci, to maintain
> consistency.
>
> This wouldn't affect targets with -mabi-only multilibs like
> mips64-linux-gnu, so I assume you're trying to provide a stock
> one-size-fits-all configuration like mips-sde-elf, but with synci
> on by default for r2 and above. If so, then maybe we should have
> a configuration for that.
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.
> 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.
> The reason I'm asking is that, if we're having to adjust certain
> multilibs in a configuration in this way, it sounds to me like we're
> either missing multilibs in that configuration, or have chosen the
> wrong out-of-the-box defaults.
I think the problem is that we don't have a good default behavior for
synci, which would be 'use it if you have it but don't give a warning if
you don't have it' and that is what I am trying to create here.
Steve Ellcey
sell...@mips.com
