Hi all,
I've just filed a bug on glibc I'd love you to take a look at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16796
Here's the description to save clicking:
Hi,
There is a test in glibc (tst-tls5) that tests that
((uintptr_t)pthread_self())%16 is zero. But watch this:
(t-mwhudson)mwh
Hi,
I filed this on bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59744 but I thought I'd
mention it here too.
This slightly strangely written program (it's distilled down from
frame_offset_overflow in the gcc source itself) should print "bigger" if
the first argument is bigger than 10 (o
Matthew Gretton-Dann writes:
> On 17 December 2013 08:45, Michael Hudson-Doyle
> wrote:
>> Cool. Would it be useful to report the bug in
>> https://sourceware.org/bugzilla/ as well?
>
> Yes please.
https://sourceware.org/bugzilla/show_bug.c
Will Newton writes:
> On 17 December 2013 07:53, Michael Hudson-Doyle
> wrote:
>> Ah... found it! This is the code that determines the offset to patch
>> into the code (elfnn-aarch64.c line 3845):
>>
>> value = (symbol_got_offset (input_bfd, h, r_symnd
Michael Hudson-Doyle writes:
> Michael Hudson-Doyle writes:
>
>> Will Newton writes:
>>
>>> On 16 December 2013 03:36, Michael Hudson-Doyle
>>> wrote:
>>>> Michael Hudson-Doyle writes:
>>>>
>>>>> Aaah, you might
Michael Hudson-Doyle writes:
> Will Newton writes:
>
>> On 16 December 2013 03:36, Michael Hudson-Doyle
>> wrote:
>>> Michael Hudson-Doyle writes:
>>>
>>>> Aaah, you might be onto something there. I built myself a cross gcc-4.8
>>>>
Will Newton writes:
> On 16 December 2013 03:36, Michael Hudson-Doyle
> wrote:
>> Michael Hudson-Doyle writes:
>>
>>> Aaah, you might be onto something there. I built myself a cross gcc-4.8
>>> today and it appeared to compile things correctly (I didn&#
On 16 Dec 2013 16:37, "Michael Hudson-Doyle"
wrote:
>
> Michael Hudson-Doyle writes:
>
> > Aaah, you might be onto something there. I built myself a cross gcc-4.8
> > today and it appeared to compile things correctly (I didn't actually get
> > to run it
Michael Hudson-Doyle writes:
> Aaah, you might be onto something there. I built myself a cross gcc-4.8
> today and it appeared to compile things correctly (I didn't actually get
> to run it, but the objdump poking looked right) and I got a bit worried
> that this was all down t
Will Newton writes:
> On 12 December 2013 23:14, Michael Hudson-Doyle
> wrote:
>> Will Newton writes:
>>
>>> On 12 December 2013 21:59, Michael Hudson-Doyle
>>> wrote:
>>>> Will Newton writes:
>>
>> [snp]
>>
>&
Will Newton writes:
> On 12 December 2013 21:59, Michael Hudson-Doyle
> wrote:
>> Will Newton writes:
[snp]
>>> I would guess that 0x64c000 is the base of the GOT and 776 is the
>>> offset into it (but I could be wrong). objdump -h will give you the
>>
Will Newton writes:
> On 12 December 2013 21:02, Michael Hudson-Doyle
> wrote:
>> Hi,
>>
>> Thanks for the respsonse.
>>
>> Will Newton writes:
>>
>>> On 12 December 2013 08:00, Michael Hudson-Doyle
>>> wrote:
>>>>
Michael Hudson-Doyle writes:
> I guess I don't understand the adrp code. My understanding is that:
>
> 0x004b4b78 <+12>:adrpx0, 0x64c000
>
> would result in 0x4b4000 + 0x64c000 in x0 and then
>
> 0x004b4b7c <+16>:ldr
Hi,
Thanks for the respsonse.
Will Newton writes:
> On 12 December 2013 08:00, Michael Hudson-Doyle
> wrote:
>> Hi all,
>>
>> I have a bit of a strange one. I'm not after a full solution, just any
>> hints that quickly come to mind :)
>>
>&g
Hi all,
I have a bit of a strange one. I'm not after a full solution, just any
hints that quickly come to mind :)
After a few simple patches I have a build of mongodb for aarch64 (built
with gcc-4.8). However, all of the test binaries that the build spits
out immediately segfault. gdb-ing show
:
> Yes, no problem.
>
> Yvan
>
> On 4 October 2013 10:56, Matthew Gretton-Dann
> wrote:
>> Michael, Yvan,
>>
>> Michael - thanks for posting upstream.
>>
>> Yvan can you do the commit on Michael's behalf as and when it gets approved?
>>
>>
Thanks, I've just posted it to gcc-patches.
Yvan Roux writes:
> Hi Michael,
>
> If think it's ok for an upstreaming request.
>
> Thanks,
> Yvan
>
>
[...]
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mai
_DATA="/usr/bin/install -c -m 644" \
INSTALL_PROGRAM="/usr/bin/install -c" \
INSTALL_SCRIPT="/usr/bin/install -c" \
all); then \
true; \
else \
thing that had "experimental,
unsupported, if it breaks you lose" written all over it, or would you
rather only ship things that you are willing to support?
Cheers,
mwh
> Thanks,
>
> Matt
>
>
> On 2 October 2013 03:44, Michael Hudson-Doyle
> wrote:
>> Hi,
&
Hi,
With the patch I just sent to this list in place, gccgo builds for
aarch64. I don't know how well it _works_ -- "hello world" builds and
runs -- but I would like to ask what the process would be to get gccgo
included in the binary distributions of GCC that Linaro makes.
Cheers,
mwh
---
Hi,
Can you review this patch for me and help me get it upstream?
This is an official request for help from LEG to the TCWG, if that
matters :-)
Cheers,
mwh
libatomic/configure.tgt | 5 -
1 file changed, 5 deletions(-)
diff --git a/libatomic/configure.tgt b/libatomic/configure.t
---
Hi all,
The reason for my most recent question on the list was that I was
investigating if gccgo targeting aarch64 would work. It turns out that
it's really close (to building and working for trivial programs, at
least): it depends on libatomic which explicitly does not support
AArch64, but
Hi,
Thanks to the advice from this list I've managed to build GCC targeting
aarch64 (thanks!).
Is there some way I can now run the tests in a Foundation model? I
don't really know how this would work -- I guess using
aarch64-unknown-linux-gnu-gcc etc to build binaries, scp them onto the
model, r
Hi Will,
Thanks for the reply.
Will Newton writes:
> On 27 August 2013 04:16, Michael Hudson-Doyle
> wrote:
>
> Hi Michael,
>
>> There has been interest from LEG members to ensure that optimal library
>> routines are used on their platforms. My understanding is t
Will Newton writes:
> On 27 August 2013 04:25, Michael Hudson-Doyle
> wrote:
>> Hi,
>>
>> Apologies in advance for any chinese whispers effects that happen, but
>> colleagues at Canonical are attempting to backport this change:
>>
>>
>> ht
Hi,
Apologies in advance for any chinese whispers effects that happen, but
colleagues at Canonical are attempting to backport this change:
https://sourceware.org/git/?p=glibc.git;a=commit;h=ae65139d140ac85808c0666c363
to the (e)glibc in current versions of Ubuntu, 2.17, but are
encountering
Hi all,
There has been interest from LEG members to ensure that optimal library
routines are used on their platforms. My understanding is that the
"correct" way of doing this these days is to use ifuncs to select the
best implementation for a given system.
I see that glibc 2.18 contains an ifunc
al Message-
> From: linaro-toolchain-boun...@lists.linaro.org
> [mailto:linaro-toolchain-boun...@lists.linaro.org] On Behalf Of Michael
> Hudson-Doyle
> Sent: Monday, August 19, 2013 10:20 AM
> To: linaro-toolchain
> Subject: building gcc-linaro for AArch64
>
> Hi,
>
Hi,
I was trying to build a gcc-linaro that targets AArch64 (mostly
following guides such as http://jk.ozlabs.org/docs/arm64-toolchain/) and
failing, to be short and simple. Unfortunately I don't have the errors
I was encountering to hand, so instead I'll ask: Is the build process
for building aa
Matthew Gretton-Dann writes:
> All,
[snip]
> So before we go any further I would like to see what the view of LEG is
> about a better malloc. My questions boil down to:
>
> * Is malloc important - or do server applications just implement their own?
I got sent this question and a list of "s
Mans Rullgard writes:
> On 22 May 2013 05:13, Michael Hudson-Doyle
> wrote:
>> Hi all,
>>
>> I've spent a little while porting an optimization from Python 3 to
>> Python 2.7 (http://bugs.python.org/issue4753). The idea of the patch is
>> to impr
Hi all,
I've spent a little while porting an optimization from Python 3 to
Python 2.7 (http://bugs.python.org/issue4753). The idea of the patch is
to improve performance by dispatching opcodes on computed labels rather
than a big switch -- and so confusing the branch predictor less.
The problem
Michael Hope writes:
> On 9 May 2012 12:14, Michael Hudson-Doyle
> wrote:
>> On Tue, 8 May 2012 15:56:27 +1200, Michael Hope
>> wrote:
>>> On 7 May 2012 20:10, Zygmunt Krynicki wrote:
>>> > Hi.
>>> >
>>> > We'll see s
On Tue, 8 May 2012 15:56:27 +1200, Michael Hope wrote:
> On 7 May 2012 20:10, Zygmunt Krynicki wrote:
> > Hi.
> >
> > We'll see some beta deployments this week. I have not tried doing any
> > KVM testing. What I can currently offer you is vexpress x4 or x1 (both
> > A7+A15) that you can run lava-
34 matches
Mail list logo
