On Jun 28, 2012, Mike Stump <mikest...@comcast.net> wrote: > On Jun 28, 2012, at 4:39 AM, Alexandre Oliva <aol...@redhat.com> wrote: >> That still doesn't sound right to me: why should the compiler refrain >> from using a perfectly functional linker plugin on the machine where >> it's installed (not where it's built?
> See your point below for one reason. My point below suggests a reason for us to *verbosely* indicate the change, e.g., in the test command line, like my patch does. > The next would be because it would be a speed hit to re-check at > runtime the qualities of the linker and do something different. But then, our testsuite *does* re-check at runtime, but without my patch, we're not using completely the result of the test. > If the system had an architecture to avoid the speed hit and people > wanted to do the work to support the runtime reconfigure, that'd be > fine with me. Me too, but I'm not arguing for or against that. I'm just arguing for a change to the test harness that will use the result of the dynamic test, and verbosely so. >> Also, this scenario of silently deciding whether or not to use the >> linker plugin could bring us to different test results for the same >> command lines. I don't like that. > Right, which is why the static configuration of the host system at > build time is forever after an invariant. That doesn't even match *current* reality. We can run the testsuite on a machine that's neither the build system nor the run-time target. That's presumably why the test harness tests whether the plugin works. And that's one reason why we should use that result instead of letting the compiler override it. > The linker is smelled, it doesn't support plugins, therefore we can't > ever use it, therefore we never build it... 'cept even in the build system it *does* support plugins, so it's just reasonable for us to build the plugin, and for the compiler to expect to be able to use it. Now, this will work just fine if the compiler is installed on a system that matches the host=target (i.e., native compiler) triplet specified when building the compiler. It might not work on the build machine, but that's irrelevant, for we're not supposed to be able to use the compiler on the build machine. It might not work on the test machine, and that's why the test harness tests for plugin support. But the test harness doesn't communicate back to the compiler its findings without my patch, so if the test system doesn't happen to support plugins, we'd get tons of pointless failures. If we change the compiler configuration so that it disables the plugin just because it guesses some potential incompatibility between the linker and the plugin we're about to build, we'll lose features and testing. If we change the compiler to detect it dynamically, we'll get ambiguous test results. “did this -flto test use the plugin or not?” Why would you want any of the scenarios in the two paragraphs above? If you wouldn't, what do you have against the patch that complements the plugin detection on the test machine in the test harness? -- 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
