[Adding gcc@] On Jun 26, 2012, "H.J. Lu" <hjl.to...@gmail.com> wrote:
> On Tue, Jun 26, 2012 at 3:39 PM, Mike Stump <mikest...@comcast.net> wrote: >> On Jun 26, 2012, at 2:04 PM, Alexandre Oliva wrote: >>> I test i686-linux-gnu in a presumably unusual setting >> >> I like the setup and testing... >> >>> This worked fine for regression testing, but I've recently realized >>> (with the PR49888/53671 mishap) that I'm getting tons of LTO testsuite >>> failures (before and after, so no regression), because the 32-bit LTO >>> plugin built in this setting can't possibly be used by the 64-bit linker >>> installed on the system. Obviously, passing -melf_i386 to the linker >>> through the wrapper is not enough for it to be able to dlopen a 32-bit >>> plugin ;-) >> So, let's kick this back to the gcc list for all the interested >> parties to chime in on... I'd rather have 5 interested people >> architect the right, nice solution that is engineered to work and >> then use it. >> H.J.'s solution seems like the most reasonable short term solution It's not a “solution”, it's just the same local arrangement I mentioned I was leaning towards, after fixing the problem in the test harness, that lets GCC use the plugin and fail even after explicitly testing for that. I don't see how that can possibly be perceived as not a bug. Which is not to say that there aren't *other* bugs in place, and that some of them might alleviate this one. >> If we build the plugin after sensing the 64-bitness of ld, using the >> flags appropriate for the linker... Then we'd be disobeying the host setting specified or detected by configure. >> failing the build early when mismatched Why? We don't demand a working plugin. Indeed, we disable the use of the plugin if we find a linker that doesn't support it. We just don't account for the possibility of finding a linker that supports plugins, but that doesn't support the one we'll build later. > Bootstrap/test -m32/-mx32 with LTO on -m64 is similar to cross-compile, > in the sense that the native linker may not work with plugin. We just > need to make the right linker available to GCC. My kludge uses PATH. > One can also include binutils source in GCC source tree. These are all reasonable suggestions to make the plugin work. But that's not what the patch addresses, namely what to do during testing when the plugin is found to NOT work. As I wrote in the original post, even if we were to detect that the plugin is not supported and refrain from building it and testing it, it's more valuable that the test summaries explicitly indicate, in each FAIL or XFAIL, that the plugin was not used, rather than make room for uncertainty as to whether the plugin was implicitly used or not. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer