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
10 matches
Mail list logo
