This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC,PATCH,testsuite] Set gcc_force_conventional_output even without LTO linker plugin
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "'gcc-patches at gcc dot gnu dot org' (gcc-patches at gcc dot gnu dot org)" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 24 Nov 2014 13:42:06 +0100
- Subject: Re: [RFC,PATCH,testsuite] Set gcc_force_conventional_output even without LTO linker plugin
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320F78EC2 at LEMAIL01 dot le dot imgtec dot org> <CAFiYyc3Ji4nucJP=qyn1_DSCE856A_o-o_ZAJhr1ZLiiaWsaqA at mail dot gmail dot com> <6D39441BF12EF246A7ABCE6654B0235320F79326 at LEMAIL01 dot le dot imgtec dot org>
On Mon, Nov 24, 2014 at 1:40 PM, Matthew Fortune
<Matthew.Fortune@imgtec.com> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Sun, Nov 23, 2014 at 10:15 AM, Matthew Fortune
>> <Matthew.Fortune@imgtec.com> wrote:
>> > Hi,
>> >
>> > I have had to use this patch several times when performing cross testing
>> > but I'm not sure if it is the right fix. The MIPS target testsuite runs
>> > all tests regardless of the current compiler configuration and
>> downgrades
>> > run tests to link tests and then to assembly tests depending on what
>> > libraries and hardware is available in the current run.
>> >
>> > In order to experiment with how the tests behave for a different
>> > configurations I add things like:
>> >
>> > --target_board=multi-sim/-msoft-float
>> >
>> > Where the option I am trying may not have libraries available.
>> >
>> > The problem comes when the LTO options are tested. The choice of which
>> > LTO options are used is based on a test for whether the LTO linker
>> plugin
>> > is available. This test fails in my case because there are no suitable
>> > libraries to link against.
>> >
>> > if [check_effective_target_lto] {
>> > # When having plugin test both slim and fat LTO and plugin/nonplugin
>> > # path.
>> > if [check_linker_plugin_available] {
>> > set LTO_TORTURE_OPTIONS [list \
>> > { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
>> > { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
>> > ]
>> > set gcc_force_conventional_output "-ffat-lto-objects"
>> > } else {
>> > set LTO_TORTURE_OPTIONS [list \
>> > { -O2 -flto -flto-partition=none } \
>> > { -O2 -flto }
>> > ]
>> > }
>> > }
>> >
>> > The problem as I see it is that the gcc_force_conventional_output line
>> > only applies to the first case. I understand why this is generally OK
>> > but if the linker plugin is seen to be available at GCC config time
>> > but is not available for a specific test configuration then there is
>> > a problem.
>>
>> But don't you get errors from the -fuse-linker-plugin path if
>> that happens?
>
> No, my description was a bit poor. The use-case is pretty non-standard as
> I am using compile options for which no link can succeed, owing to missing
> libraries for the ABI under test. So the plugin is there and usable but
> the testsuite check for it will always fail given the compile options.
> This then leads to no assembly output as the compiler will default to
> -fno-fat-lto-objects and the tests which need assembly text then fail.
> Link tests in the rest of the testsuite will fail regardless but it is just
> experimentation in the mips.exp testsuite that I want to cover without
> building 50+ multilibs.
>
>> > I'd therefore like to apply the following. Any suggestions on the
>> > testing that this needs? Would a build + regression run of GCC
>> > with binutils configured --disable-plugins be sufficient?
>>
>> Sure, that sounds reasonable. Note that I think the patch is ok
>> anyway - passing a "redundant" -ffat-lto-objects won't break
>> anything.
>>
>> Thus, ok.
>
> OK, I wasn't sure if there were any scenarios where an explicit
> -ffat-lto-objects would make a difference. I keep getting lost when
> trawling through the LTO option handling logic.
AFAIK it's only set for dg-scan-assembler and friends which always
needs fat LTO objects.
> I'll run a quick test anyway and commit.
>
> Thanks,
> Matthew
>
>>
>> > Matthew
>> >
>> > gcc/testsuite/
>> >
>> > * lib/gcc-dg.exp: Set gcc_force_conventional_output for whenever
>> > LTO is used.
>> >
>> > diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
>> > index 6df8ae1..8d5bf9b 100644
>> > --- a/gcc/testsuite/lib/gcc-dg.exp
>> > +++ b/gcc/testsuite/lib/gcc-dg.exp
>> > @@ -88,13 +88,13 @@ if [check_effective_target_lto] {
>> > { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
>> > { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
>> > ]
>> > - set gcc_force_conventional_output "-ffat-lto-objects"
>> > } else {
>> > set LTO_TORTURE_OPTIONS [list \
>> > { -O2 -flto -flto-partition=none } \
>> > { -O2 -flto }
>> > ]
>> > }
>> > + set gcc_force_conventional_output "-ffat-lto-objects"
>> > }
>> >
>> > global orig_environment_saved