This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [testsuite] don't use lto plugin if it doesn't work
On Jun 28, 2012, at 4:39 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jun 28, 2012, Jakub Jelinek <jakub@redhat.com> wrote:
>
>> On Thu, Jun 28, 2012 at 04:16:55AM -0300, Alexandre Oliva wrote:
>>> I'd very be surprised if I asked for an i686 native build to package and
>>> install elsewhere, and didn't get a plugin just because the build-time
>>> linker wouldn't have been able to run the plugin.
>
>> Not disable plugin support altogether, but disable assuming the linker
>> supports the plugin.
>
> 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. 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. 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. I don't think you system supports this, and I don't think you want to do that work, do you?
> 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. The linker is smelled, it doesn't support plugins, therefore we can't ever use it, therefore we never build it...