On Jul 2, 2012, at 4:06 AM, Alexandre Oliva wrote:
> On Jun 29, 2012, Mike Stump wrote:
>> First, let get to the heart of the matter. That is the behavior of
>> compiler.
>
> That's a distraction in the context of a patch to improve a feature
> that's already present in the testsuite machinery,
On Mon, Jul 2, 2012 at 1:06 PM, Alexandre Oliva wrote:
> On Jun 29, 2012, Mike Stump wrote:
>
>> First, let get to the heart of the matter. That is the behavior of
>> compiler.
>
> That's a distraction in the context of a patch to improve a feature
> that's already present in the testsuite machi
On Jun 29, 2012, Mike Stump wrote:
> First, let get to the heart of the matter. That is the behavior of
> compiler.
That's a distraction in the context of a patch to improve a feature
that's already present in the testsuite machinery, isn't it? I have no
objection to discussing this other topi
On Jun 28, 2012, at 3:19 PM, Alexandre Oliva wrote:
> On Jun 28, 2012, Mike Stump wrote:
>> 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
>
On Jun 28, 2012, Mike Stump wrote:
> On Jun 28, 2012, at 4:39 AM, Alexandre Oliva 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 bel
On Thu, Jun 28, 2012 at 4:08 PM, Jakub Jelinek wrote:
> On Thu, Jun 28, 2012 at 07:03:37AM -0700, Mike Stump wrote:
>> > 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 tha
On Thu, Jun 28, 2012 at 07:03:37AM -0700, Mike Stump wrote:
> > 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
On Jun 28, 2012, at 4:39 AM, Alexandre Oliva wrote:
> On Jun 28, 2012, Jakub Jelinek 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 becau
On Jun 28, 2012, at 12:16 AM, Alexandre Oliva wrote:
> On Jun 27, 2012, Mike Stump wrote:
>> On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
>>> 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
>>
On Thu, Jun 28, 2012 at 1:39 PM, Alexandre Oliva wrote:
> On Jun 28, 2012, Jakub Jelinek 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 be
On Jun 28, 2012, Jakub Jelinek 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 t
On Thu, Jun 28, 2012 at 04:16:55AM -0300, Alexandre Oliva wrote:
> On Jun 27, 2012, Mike Stump wrote:
>
> > On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
> >> 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.
On Jun 27, 2012, Mike Stump wrote:
> On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
>> 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 supp
On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
> 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 t
[Adding gcc@]
On Jun 26, 2012, "H.J. Lu" wrote:
> On Tue, Jun 26, 2012 at 3:39 PM, Mike Stump 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 te
15 matches
Mail list logo