| Message ID | 6D39441BF12EF246A7ABCE6654B0235320F78EC2@LEMAIL01.le.imgtec.org |
|---|---|
| State | New |
| Headers | show |
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? > 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. Thanks, Richard. > 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
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. 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
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
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
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. 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? Matthew gcc/testsuite/ * lib/gcc-dg.exp: Set gcc_force_conventional_output for whenever LTO is used.