On 7 March 2016 at 05:43, Ramana Radhakrishnan
wrote:
> On Wed, Feb 17, 2016 at 10:20 AM, Christophe Lyon
> wrote:
>> On 17 February 2016 at 11:05, Kyrill Tkachov
>> wrote:
>>>
>>> On 17/02/16 10:03, Christophe Lyon wrote:
On 15 February 2016 at 12:32, Kyrill Tkachov
wrote:
>
On Wed, Feb 17, 2016 at 10:20 AM, Christophe Lyon
wrote:
> On 17 February 2016 at 11:05, Kyrill Tkachov
> wrote:
>>
>> On 17/02/16 10:03, Christophe Lyon wrote:
>>>
>>> On 15 February 2016 at 12:32, Kyrill Tkachov
>>> wrote:
On 04/02/16 08:58, Ramana Radhakrishnan wrote:
>
> On
On 17 February 2016 at 11:22, Kyrill Tkachov
wrote:
>
> On 17/02/16 10:20, Christophe Lyon wrote:
>>
>> On 17 February 2016 at 11:05, Kyrill Tkachov
>> wrote:
>>>
>>> On 17/02/16 10:03, Christophe Lyon wrote:
On 15 February 2016 at 12:32, Kyrill Tkachov
wrote:
>
> On 04/02
On 17/02/16 10:20, Christophe Lyon wrote:
On 17 February 2016 at 11:05, Kyrill Tkachov
wrote:
On 17/02/16 10:03, Christophe Lyon wrote:
On 15 February 2016 at 12:32, Kyrill Tkachov
wrote:
On 04/02/16 08:58, Ramana Radhakrishnan wrote:
On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson
wrote:
Th
On 17 February 2016 at 11:05, Kyrill Tkachov
wrote:
>
> On 17/02/16 10:03, Christophe Lyon wrote:
>>
>> On 15 February 2016 at 12:32, Kyrill Tkachov
>> wrote:
>>>
>>> On 04/02/16 08:58, Ramana Radhakrishnan wrote:
On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson
wrote:
>
> This
On 17/02/16 10:03, Christophe Lyon wrote:
On 15 February 2016 at 12:32, Kyrill Tkachov
wrote:
On 04/02/16 08:58, Ramana Radhakrishnan wrote:
On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson wrote:
This is my suggested fix for PR 65932, which is a linux kernel
miscompile with gcc-5.1.
The proble
On 15 February 2016 at 12:32, Kyrill Tkachov
wrote:
>
> On 04/02/16 08:58, Ramana Radhakrishnan wrote:
>>
>> On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson wrote:
>>>
>>> This is my suggested fix for PR 65932, which is a linux kernel
>>> miscompile with gcc-5.1.
>>>
>>> The problem here is caused by
On Mon, Feb 15, 2016 at 11:32 AM, Kyrill Tkachov
wrote:
>
> On 04/02/16 08:58, Ramana Radhakrishnan wrote:
>>
>> On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson wrote:
>>>
>>> This is my suggested fix for PR 65932, which is a linux kernel
>>> miscompile with gcc-5.1.
>>>
>>> The problem here is cause
On 04/02/16 08:58, Ramana Radhakrishnan wrote:
On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson wrote:
This is my suggested fix for PR 65932, which is a linux kernel
miscompile with gcc-5.1.
The problem here is caused by a chain of events. The first is that
the relatively new eipa_sra pass create
On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson wrote:
> This is my suggested fix for PR 65932, which is a linux kernel
> miscompile with gcc-5.1.
>
> The problem here is caused by a chain of events. The first is that
> the relatively new eipa_sra pass creates fake parameters that behave
> slightly d
On 16/07/15 16:00, Michael Matz wrote:
> Hi,
>
> On Thu, 16 Jul 2015, Richard Earnshaw wrote:
>
> Now that we do have the problem, we can't fix it without an ARM port
> ABI change, which is undesirable, so we may have to fix it with a MI
> change.
What's the ABI implicatio
Hi,
On Thu, 16 Jul 2015, Richard Earnshaw wrote:
> >>> Now that we do have the problem, we can't fix it without an ARM port
> >>> ABI change, which is undesirable, so we may have to fix it with a MI
> >>> change.
> >>
> >> What's the ABI implication of fixing the inconsistency?
> >
>
> I thin
On 15/07/15 16:54, Jim Wilson wrote:
> On Wed, Jul 15, 2015 at 6:04 AM, Michael Matz wrote:
>> Hi,
>>
>> On Tue, 14 Jul 2015, Jim Wilson wrote:
>>
>>> Now that we do have the problem, we can't fix it without an ARM port ABI
>>> change, which is undesirable, so we may have to fix it with a MI chang
On Wed, Jul 15, 2015 at 6:04 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 14 Jul 2015, Jim Wilson wrote:
>
>> Now that we do have the problem, we can't fix it without an ARM port ABI
>> change, which is undesirable, so we may have to fix it with a MI change.
>
> What's the ABI implication of fixing t
Hi,
On Tue, 14 Jul 2015, Jim Wilson wrote:
> Now that we do have the problem, we can't fix it without an ARM port ABI
> change, which is undesirable, so we may have to fix it with a MI change.
What's the ABI implication of fixing the inconsistency?
> There were two MI changes suggested, one wa
Hi,
On Tue, 14 Jul 2015, Richard Earnshaw wrote:
> > I think it's a backend bug that parameters and locals are extended
> > differently. The code in tree-outof-ssa was written with the
> > assumption that the modes of RTL objects might be different (larger)
> > than the tree types suggest, bu
On July 14, 2015 6:49:18 PM GMT+02:00, Jim Wilson wrote:
>On Tue, Jul 14, 2015 at 9:13 AM, Richard Earnshaw
> wrote:
>> We went through this a couple of weeks back. The backend
>documentation
>> for PROMOTE_MODE says:
>
>I disagree that this is a fully resolved issue. I see clear problems
>with
On Tue, Jul 14, 2015 at 9:13 AM, Richard Earnshaw
wrote:
> We went through this a couple of weeks back. The backend documentation
> for PROMOTE_MODE says:
I disagree that this is a fully resolved issue. I see clear problems
with how the ARM port uses PROMOTE_MODE.
> " For most machines, the ma
On July 14, 2015 6:13:13 PM GMT+02:00, Richard Earnshaw
wrote:
>On 13/07/15 16:29, Michael Matz wrote:
>> Hi,
>>
>> On Mon, 13 Jul 2015, Richard Biener wrote:
>>
>>> On Fri, Jul 10, 2015 at 5:46 PM, Jim Wilson
>wrote:
On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener
wrote:
> On Ju
On 13/07/15 16:29, Michael Matz wrote:
> Hi,
>
> On Mon, 13 Jul 2015, Richard Biener wrote:
>
>> On Fri, Jul 10, 2015 at 5:46 PM, Jim Wilson wrote:
>>> On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener
>>> wrote:
On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson
wrote:
> signed sub-
On Mon, Jul 13, 2015 at 8:29 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 13 Jul 2015, Richard Biener wrote:
>
>> On Fri, Jul 10, 2015 at 5:46 PM, Jim Wilson wrote:
>> > On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener
>> > wrote:
>> >> On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson
>> >> wrote:
Hi,
On Mon, 13 Jul 2015, Richard Biener wrote:
> On Fri, Jul 10, 2015 at 5:46 PM, Jim Wilson wrote:
> > On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener
> > wrote:
> >> On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson
> >> wrote:
> >>>signed sub-word locals. Thus to detect the need for a conve
On Fri, Jul 10, 2015 at 5:46 PM, Jim Wilson wrote:
> On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener
> wrote:
>> On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson
>> wrote:
>>>signed sub-word locals. Thus to detect the need for a conversion, you
>>>have to have the decls, and we don't have them
On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener
wrote:
> On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson
> wrote:
>>signed sub-word locals. Thus to detect the need for a conversion, you
>>have to have the decls, and we don't have them here. There is also
>
> It probably is. The decks for the
On Wed, Jul 8, 2015 at 3:54 PM, Jeff Law wrote:
> On 07/07/2015 10:29 AM, Jim Wilson wrote:
> This is critically important as various parts of the compiler will take a
> degenerate PHI node and propagate the RHS of the PHI into the uses of the
> LHS of the PHI -- without doing any conversions.
I
On 07/07/2015 10:29 AM, Jim Wilson wrote:
My years at Cisco didn't give me a chance to work on the SSA passes,
so I don't know much about how they work. But looking at this, I see
that PHI nodes are eventually handed by emit_partition_copy in
tree-outof-ssa.c, which calls convert_to_mode, so it
On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson wrote:
>On Tue, Jul 7, 2015 at 8:07 AM, Jeff Law wrote:
>> On 06/29/2015 07:15 PM, Jim Wilson wrote:
>> So if these "copies" require a conversion, then isn't it
>fundamentally
>> wrong to have a PHI node which copies between them? That would seem
On Thu, Jul 2, 2015 at 2:07 AM, Richard Earnshaw
wrote:
> Not quite, ARM state still has more flexible addressing modes for
> unsigned byte loads than for signed byte loads. It's even worse with
> thumb1 where some signed loads have no single-register addressing mode
> (ie you have to copy zero i
On Tue, Jul 7, 2015 at 8:07 AM, Jeff Law wrote:
> On 06/29/2015 07:15 PM, Jim Wilson wrote:
> So if these "copies" require a conversion, then isn't it fundamentally
> wrong to have a PHI node which copies between them? That would seem to
> implicate the eipa_sra pass as needing to be aware of th
On 06/29/2015 07:15 PM, Jim Wilson wrote:
This is my suggested fix for PR 65932, which is a linux kernel
miscompile with gcc-5.1.
The problem here is caused by a chain of events. The first is that
the relatively new eipa_sra pass creates fake parameters that behave
slightly differently than nor
On 30/06/15 02:15, Jim Wilson wrote:
> This is my suggested fix for PR 65932, which is a linux kernel
> miscompile with gcc-5.1.
>
> The problem here is caused by a chain of events. The first is that
> the relatively new eipa_sra pass creates fake parameters that behave
> slightly differently tha
This is my suggested fix for PR 65932, which is a linux kernel
miscompile with gcc-5.1.
The problem here is caused by a chain of events. The first is that
the relatively new eipa_sra pass creates fake parameters that behave
slightly differently than normal parameters. The second is that the
opti
32 matches
Mail list logo
