On 10/11/15 16:39, Alan Lawrence wrote:
Since r229878, I've been seeing
FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
UNRESOLVED: gcc.dg/attr-weakref-1.c compilation failed to produce executable
(both previously passing) on aarch64-none-elf, aarch64_be-none-elf, and
aarch64-none-linux-
On Tue, Nov 10, 2015 at 4:39 PM, Alan Lawrence wrote:
> On 04/11/15 14:26, Ramana Radhakrishnan wrote:
>>
>>
>> True and I've just been reading more of the backend - We could now start
>> using blocks for constant pools as well. So let's do that.
>>
>> How does something like this look ?
>>
>> Tes
On 04/11/15 14:26, Ramana Radhakrishnan wrote:
True and I've just been reading more of the backend - We could now start using
blocks for constant pools as well. So let's do that.
How does something like this look ?
Tested on aarch64-none-elf - no regressions.
2015-11-04 Ramana Radhakrishnan
On Mon, Nov 09, 2015 at 04:46:01PM +, Ramana Radhakrishnan wrote:
>
>
> On 08/11/15 11:42, Andreas Schwab wrote:
> > This is causing a bootstrap comparison failure in gcc/go/gogo.o.
> >
> > Andreas.
> >
>
> I've had a look at this for sometime this afternoon and the trigger is the
> aarch6
On 08/11/15 11:42, Andreas Schwab wrote:
> This is causing a bootstrap comparison failure in gcc/go/gogo.o.
>
> Andreas.
>
I've had a look at this for sometime this afternoon and the trigger is the
aarch64_use_constant_blocks_p change which appears to be causing a bootstrap
comparison failur
On 08/11/15 11:42, Andreas Schwab wrote:
> This is causing a bootstrap comparison failure in gcc/go/gogo.o.
I'm looking into this - this is now PR68256.
regards
Ramana
>
> Andreas.
>
This is causing a bootstrap comparison failure in gcc/go/gogo.o.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Wed, Nov 04, 2015 at 02:26:31PM +, Ramana Radhakrishnan wrote:
>
>
> On 03/11/15 17:09, James Greenhalgh wrote:
> > On Tue, Nov 03, 2015 at 04:36:45PM +, Ramana Radhakrishnan wrote:
> >> Hi,
> >>
> >>Now that PR63304 is fixed and we have an option to address
> >> any part of the me
On 03/11/15 17:09, James Greenhalgh wrote:
> On Tue, Nov 03, 2015 at 04:36:45PM +, Ramana Radhakrishnan wrote:
>> Hi,
>>
>> Now that PR63304 is fixed and we have an option to address
>> any part of the memory using adrp / add or adrp / ldr instructions
>> it makes sense to switch out lit
On Tue, Nov 03, 2015 at 04:36:45PM +, Ramana Radhakrishnan wrote:
> Hi,
>
> Now that PR63304 is fixed and we have an option to address
> any part of the memory using adrp / add or adrp / ldr instructions
> it makes sense to switch out literal pools into their own
> mergeable sections by
Hi,
Now that PR63304 is fixed and we have an option to address
any part of the memory using adrp / add or adrp / ldr instructions
it makes sense to switch out literal pools into their own
mergeable sections by default.
This would mean that by default we could now start getting
the benefit
11 matches
Mail list logo
