"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. 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.) 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. Richard
