> Given that we've had this bake sufficiently on trunk and have seen no
> regressions reported it should be fine to go back to these branches.
>
> Further we've had the 4.9.1 and 4.8.3 releases recently so I'd say Yes,
> unless the RM's object in the next 24 hours.
Make check passed on 4.8 and 4.9
On 31/07/14 11:53, Christophe Lyon wrote:
On 5 July 2014 16:12, Charles Baylis wrote:
On 3 July 2014 15:26, Richard Earnshaw wrote:
So OK, but if you're considering back-ports, I suggest you let it bake a
while on trunk first.
Committed as r212303.
It was a few weeks ago now, so is it
On 5 July 2014 16:12, Charles Baylis wrote:
> On 3 July 2014 15:26, Richard Earnshaw wrote:
>
>> So OK, but if you're considering back-ports, I suggest you let it bake a
>> while on trunk first.
>
> Committed as r212303.
It was a few weeks ago now, so is it OK to backport this to 4.8 and
4.9 bra
On 3 July 2014 15:26, Richard Earnshaw wrote:
> So OK, but if you're considering back-ports, I suggest you let it bake a
> while on trunk first.
Committed as r212303.
On 02/07/14 13:05, Charles Baylis wrote:
> On 30 June 2014 14:26, Richard Earnshaw wrote:
>> On 30/06/14 13:53, Charles Baylis wrote:
>>> I see two options to fix it - one is to teach the back-end to
>>> successfully generate code for this insn, and the other is to teach
>>> the back-end that such
On 30 June 2014 14:26, Richard Earnshaw wrote:
> On 30/06/14 13:53, Charles Baylis wrote:
>> I see two options to fix it - one is to teach the back-end to
>> successfully generate code for this insn, and the other is to teach
>> the back-end that such an insn is not valid. My proposed patch does
>
On 30/06/14 13:53, Charles Baylis wrote:
> On 18 June 2014 00:02, Ramana Radhakrishnan wrote:
>>
>> Interesting workaround but can we investigate further how to fix this
>> at the source rather than working around in the backend in this form.
>> It's still a kludge that we carry in the backend rat
On 18 June 2014 00:02, Ramana Radhakrishnan wrote:
>
> Interesting workaround but can we investigate further how to fix this
> at the source rather than working around in the backend in this form.
> It's still a kludge that we carry in the backend rather than fix the
> problem at it's source. I'd
On Wed, Apr 2, 2014 at 2:29 PM, Charles Baylis
wrote:
> Hi
>
> This patch fixes the push_minipool_fix ICE, which occurs when the ARM
> backend encounters a zero/sign extending load from a constant pool.
>
> I don't have a current test case for trunk, lp1296601 has a test case
> which affects the l
Ping?
On 6 May 2014 17:05, Charles Baylis wrote:
> Ping?
>
> At this stage looking for general feedback on whether the define_split
> approach in this patch is appropriate. If it is, I'll do a clean patch
> for full review.
>
> Archive link: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00078.html
On Tue, 6 May 2014 17:05:16 +0100
Charles Baylis wrote:
> Ping?
>
> At this stage looking for general feedback on whether the define_split
> approach in this patch is appropriate. If it is, I'll do a clean patch
> for full review.
>
> Archive link: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg0
Ping?
At this stage looking for general feedback on whether the define_split
approach in this patch is appropriate. If it is, I'll do a clean patch
for full review.
Archive link: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00078.html
On 2 April 2014 14:29, Charles Baylis wrote:
> Hi
>
> This p
On 2 April 2014 14:29, Charles Baylis wrote:
> Tested on arm-unknown-linux-gnueabihf (qemu), bootstrap in progress.
bootstrapped successfully on a Chromebook arm-unknown-linux-gnueabihf.
Hi
This patch fixes the push_minipool_fix ICE, which occurs when the ARM
backend encounters a zero/sign extending load from a constant pool.
I don't have a current test case for trunk, lp1296601 has a test case
which affects the linaro-4.8 branch. As far as I know, there has been
no fix for this
14 matches
Mail list logo
