Re: STT_GNU_IFUNC and R_ARM_IRELATIVE
Richard, On Wed, 2010-11-17 at 17:12 +, Richard Sandiford wrote: > The STT_GNU_IFUNC blueprint: > > https://wiki.linaro.org/WorkingGroups/ToolChain/Specs/Binutils-STT_GNU_IFUNC > > says "the ARM EABI will be updated to support STT_GNU_IFUNC's requirements". > I suppose the most obvious thing that needs to be defined is the relocation > number for R_ARM_IRELATIVE. What's the best way of handling that? > The main options seem to be: > >1. Reserve a relocation number with ARM first (129?). > >2. Go ahead and implement it without having the EABI updated. > See whether the results are good before deciding whether > to bless it in the EABI. > >3. Since STT_GNU_IFUNC is a GNU-specific, treat R_ARM_IRELATIVE > as GNU-specific too, and pinch one of the R_ARM_PRIVATE relocs. > > I'm pretty sure (3)'s not the way to go, but I was aiming for > completeness. :-) The correct thing to do is to email arm.e...@arm.com with a request for some numbers to be allocated to the relocations you require. You email should contain: * The number of relocations desired; * Suggested names for the relocations; * Relocation types (static or dynamic); * A description of the intended use/behaviour of the relocations. You will then be allocated the numbers. However, if you need to start developing before numbers are assigned in the ABI you should use relocations in the private space: R_ARM_PRIVATE_ (number = 112+n, n=0...15). These private relocations are guaranteed not to be assigned for other uses, and no released tool should be using them, so they are suitable for development purposes. However, by the time you come to release anything you need to use the numbers assigned by the ABI. Thanks, Matt -- Matthew Gretton-Dann Principal Engineer - PDSW Tools ARM Ltd ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Vector-alignment patch performance regressions
On 8 August 2012 16:24, Ulrich Weigand wrote: > > Hello, > > I've had a look at the mp3player performance regressions (just with *some* > data sets) with the vector-alignment patch. Interestingly it turns out > that the patch basically does not change the generated code for the hot > spot (inv_mdct routine) at all. (The *only* change is which bits of the > incoming pointer the run-time alignment check generated by the vectorizer > tests for. But this has no practical consequences, since the check itself > is not hot, and the *decision* made by the check is the same anyway -- > everything is in fact properly aligned at runtime.) > > The other difference, outside of code, introduced by the vector-alignment > patch is that some global arrays used to be forcibly aligned to 16 bytes by > the vectorizer, and they are now only aligned to 8 bytes. To check whether > this makes a difference, I've modified the compiler as a hack to always > force all global arrays to be 16 byte aligned. And interestingly enough, > this appears to fix this particular performance regression ... > > Any thoughts as to why this might be the case? What are the > recommendations on the ARM hardware side as to what alignment is prefered? This suggests to me that the data layout changes now mean that some of the loads hit two-cache lines (for 8-byte alignment) as opposed to one (for 16-byte alignment) The naive comment is that everything should be aligned to 32-bytes for A9 (as that is the A9 cache line size: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388-/CIHGGJAB.html). However for loads of less than 32-bytes alignment to the load-size is OK (as that shouldn't cross a cache line boundary). Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Aug 6 - Aug 10
== Progress == * Started Linaro ramp up process * Lots of admin, paperwork, and PC setup * Successfully built compilers from Linaro and upstream trees * Out of office Friday 10 == Next Week == * Out of office Friday 17 * Attend appropriate Virtual Connect sessions * Do the 2012.08 release of the Toolchain * Start working on symbol_ref split benchmarking. == Future == * Find a small patch to GCC to use to pipeclean the submission process -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Linaro 2012-08 GCC 4.6 and 4.7 releases
All, Is there anything left to go into the branches that needs to be in the releases this week? I believe Uli's patches have gone in - is there anything else required? I will start spinning the releases around 0800 UTC tomorrow if nothing else is needed for the release. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: PGO and LTO session preparation
On 15 August 2012 05:36, Michael Hope wrote: > Hi Matt. I've fleshed out the Etherpad for the PGO and LTO session at: > http://pad.linaro.org/GzRj35tXFt I've expanded it a bit further. > It's a topic list that needs some specifics. Could you make sure we > have basic answers to any correctness or performance questions? 'We are as correct as upstream - I found 101 PRs which are in the LTO/gcov-profile components. There are others. The performance of PGO on 'a popular embedded benchmark' is 14% improvement, LTO is 7%. Don't know both together, or SPEC. > Ramana, could you add the specifics from the performance call? I > can't seem to find the right meeting in the logs. Ramana and I had a discussion this afternoon - I think my strawman proposal for a blueprint for the next 3-6 months. goes something like the following: * Get Hot/Cold partitioning working * Pick a benchmark/application and ensure PGO/LTO works for it * Then look at how the performance changes, and find the changes * I-I into the next app to look at, and what needs doing. Candidates for the benchmark/application: * Spec * Firefox * Linux Kernel * OpenOffice/LibreOffice SPEC is because Ramana's current Hot/Cold partitioning breaks it. Firefox, Linux, and OOo all have bugs raised against them in the GCC BugZilla - indicating people are interested in them. But a discussion at the session at what others would be interested in would be good. Do we need a slide as Kiko suggested or will the EtherPad be good enough? I plan to be lurking at the VC session into Android later on today so we can have a side discussion then if you want. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Aug 13 - Aug 17
== Progress == * Out of office Friday 17 * Attended Virtual Connect sessions * Vectorization * Ran PGO/LTO session * Lurked on AArch64/OpenEmbedded and Dalvik Performance sessions * Did the 2012.08 release of the Toolchain * Ran into infrastructure problems with armv5 builds * Most of the build process is now done * Start working on symbol_ref split benchmarking. * Struggled to get my jobs to spawn * Started to backport Ramana's fix to PR54212 * Submitted merge request for 4.7 backport == Next Week == * Ensure 2012.08 release is completed * Get symbol_ref benchmarking going properly * Complete backports of PR54212 * Follow up to Virtual Connect Sessions == Future == * Get my name against some blue-prints * Find a small patch to GCC to use to pipeclean the submission process -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Actions from Toolchain Performance Call 21 August 2012
All, I have updated the minutes from today's Performance Call here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-08-21 The following are the actions from the meeting: * michaelh to folow-up and ping Mans on getting a hold of his benchmark runs * michaelh to investigate regression with movw/movt patch by hand * mgrettondann to run current symbol ref splitting patch over SPEC against FSF trunk * michaelh to point mgrettondann to existing cards * michaelh and mgrettondann to start writing card for PGO work * mgrettondann to pick up Hot/Cold Partitioning patch from ramana, cross-test against SPEC for correctness, and then do a benchmarking run * ramana to create a Blueprint for min-idion in middle-end and update Todo list with link * mgrettondann to update todo list with changes in 2012.08 release. * zchen to work on shrink-wrapping * clyon to update his vext patch The next meeting is on 4 September and a proposed Agenda is here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-09-04 Please add any items you wish to discuss to the agenda. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Function alignment and benchmark results
Michael, On 23 August 2012 03:09, Michael Hope wrote: > Zhenqiang's been working on the later split 2 patch which causes more > constants to be built using a movw/movt instead of a constant pool > load. There was an unexpected ~10 % regression in one benchmark which > seems to be due to function alignment. I think we've tracked down the > reason but not the action. > > Compared to the baseline, the split2 branch took 113 % of the time to > run, i.e. 13 % longer. Adding an explicit 16 byte alignment to the > function changed this to 97 % of the time, i.e. 3 % faster. The > reason Zhenqiang and I got different results was the build-id. He > used the binary build scripts to make the cross compiler, which turn > on the build ID, which added an extra 20 bytes ahead of .text, which > happened to align the function to 16 bytes. cbuild doesn't use the > build-id (although it should) which happened to align the function to > an 8 byte boundary. > > The disassembly is identical so I assume the regression is cache or > fast loop related. I'm not sure what to do, so let's talk about this > at the next performance call. I've made a note in the agenda for the performance call, but here are some quick notes/questions that come to my mind: My guesses would include cache alignment and wide Thumb-2 instructions straddling cache-line boundaries changing core performance. My thoughts on further investigations would be - does the function need to be aligned, or is it a hot loop in the function? Can we manually alter the code to choose different instructions to make sure there are none that straddle a cache-line boundary - and if so what happens as we change alignment? If it is code (either function or loop) alignment and not instruction sizes that are the issue then we can probably do something about it. If it is instruction sizes then we need to work out a way to mitigate the effects - as GCC doesn't have precise instruction size knowledge. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 20 August - 24 August
== Progress == * Follow up from 2012.08 Toolchain release * Updated Wiki pages * Start working on symbol_ref split benchmarking. * Backport to PR54212 done upstream to 4.6 and 4.7 * Started picking up Hot/Cold partitioning in PGO blueprint: * https://blueprints.launchpad.net/gcc-linaro/+spec/hot-cold-partitioning-in-pgo * Got SPEC running locally and I think I have reproduced Ramana's failures. == Next Week == * Bank Holiday on Monday * Investiagte SPEC failures in Hot/Cold PGO * Get symbol_ref benchmarking going properly == Future == * Look at Cards for Vectorization, PGO and LTO with Michael. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Week of 27 - 31 August
== Progress == * Bank Holiday on Monday * Got symbol_ref split benchmarking going * Hot/Cold partitioning in PGO: * https://blueprints.launchpad.net/gcc-linaro/+spec/hot-cold-partitioning-in-pgo * Investigated and fixed all compile-time failures in SPEC * Investigated and fixed a silent code-gen fault in SPEC == Next Week == * Look at symbol_ref split benchmarking results * Hot/Cold Partitioning: * Investigate remaining silent code-gen faults and non-termination issue in SPEC * If failures are fixed start profiledbootstraps and tests on the central boards. == Future == * Look at Cards for Vectorization, PGO and LTO with Michael. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Linaro-toolchain-dev] Linaro tool chain manuals
Assaf, Just to let you know that linaro-toolchain-...@lists.launchpad.net is a closed list, a better place for this question is linaro-toolchain@lists.linaro.org. On 3 September 2012 11:41, Assaf Hoffman wrote: > Hi, > > Where can I find Linaro toolchain manuals? The manuals are distributed as *.info files, as per FSF GCC. These are found in .../share/info/ under wherever you installed your toolchain. One way to view these is to run info as follows: info -f .../share/info/gcc.info > I’m looking for Linaro supported optimization flag list. > > Is it a super set of FSF GCC? Linaro GCC 4.X supports all the options of FSF GCC 4.X, it may also support options that were added in later versions of FSF GCC if the appropriate functionality has been backported. The info files will document these new options. Unfortunately, I do not have an easy to read list of these options (if indeed there are any), so I can't provide you with any further pointers at the moment. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Issue with reload and indirect branches
-freorder-blocks-and-partition
-fno-common -fdump-noaddr -O3 -dp -save-temps iterate.c -o iterate.o
Does anyone have any hints as to where I should go looking?
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index c62b5bc..341ea9e 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -1572,6 +1572,11 @@ rtl_tidy_fallthru_edge (edge e)
if (INSN_P (q))
return;
+ /* If the two blocks are in different partitions we do not want to mark
+ this as a fallthru edge. */
+ if (BB_PARTITION (b) != BB_PARTITION (c))
+return;
+
/* Remove what will soon cease being the jump insn from the source block.
If block B consisted only of this single jump, turn it into a deleted
note. */
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 2805b7c..21d2213 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -1989,16 +1989,6 @@ arm_option_override (void)
else
max_insns_skipped = current_tune->max_insns_skipped;
- /* Hot/Cold partitioning is not currently supported, since we can't
- handle literal pool placement in that case. */
- if (flag_reorder_blocks_and_partition)
-{
- inform (input_location,
- "-freorder-blocks-and-partition not supported on this
architecture");
- flag_reorder_blocks_and_partition = 0;
- flag_reorder_blocks = 1;
-}
-
if (flag_pic)
/* Hoisting PIC address calculations more aggressively provides a small,
but measurable, size reduction for PIC code. Therefore, we decrease
@@ -13479,9 +13469,19 @@ arm_reorg (void)
minipool_pad = 0;
/* Scan all the insns and record the operands that will need fixing. */
- for (insn = next_nonnote_insn (insn); insn; insn = next_nonnote_insn (insn))
+ for (insn = next_nondebug_insn (insn); insn; insn = next_nondebug_insn
(insn))
{
- if (GET_CODE (insn) == BARRIER)
+ if (NOTE_P (insn))
+ {
+ if (NOTE_KIND (insn) == NOTE_INSN_SWITCH_TEXT_SECTIONS)
+ {
+ /* Given we can't address a range greater than 4MB go ahead
+and increase the address sky high to force all pools before
+this note to be dumped. */
+ address += 0x40;
+ }
+ }
+ else if (GET_CODE (insn) == BARRIER)
push_minipool_barrier (insn, address);
else if (INSN_P (insn))
{
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 8acde0e..9ccc283 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1922,20 +1922,25 @@ enum arm_auto_incmodes
|| (TARGET_THUMB1 \
&& (optimize_size || flag_pic)))
+/* TODO: When partitioning we cannot use tbh/tbb or other short forms as the
+ branches may be in different sections. We could improve this by looking
+ at the labels in BODY and determining whether we cross HOT/COLD boundaries.
*/
#define CASE_VECTOR_SHORTEN_MODE(min, max, body) \
- (TARGET_THUMB1 \
- ? (min >= 0 && max < 512\
- ? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 1, QImode) \
- : min >= -256 && max < 256 \
- ? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 0, QImode) \
- : min >= 0 && max < 8192 \
- ? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 1, HImode) \
- : min >= -4096 && max < 4096 \
- ? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 0, HImode) \
- : SImode)
\
- : ((min < 0 || max >= 0x2 || !TARGET_THUMB2) ? SImode \
- : (max >= 0x200) ? HImode
\
- : QImode))
+ (flag_reorder_blocks_and_partition \
+ ? SImode\
+ : (TARGET_THUMB1\
+ ? (min >= 0 && max < 512 \
+ ? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 1, QImode) \
+ : min >= -256 && max < 256 \
+ ? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 0, QImode) \
+ : min >= 0 && max < 8192\
+ ? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 1, HImode) \
+ : min >= -4096 && max < 4096\
+ ? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 0, HImode) \
[ACTIVITY] Week 3 - 7 September
== Progress == * Started looking at symbol_ref splitting benchmark results * One big regression ~18% * Started to investigate whether code alignment was the problem as before * Hot/Cold partitioning in PGO: * https://blueprints.launchpad.net/gcc-linaro/+spec/hot-cold-partitioning-in-pgo * Sent fixes so far upstream * Spent most of the week looking at a Silent Code Gen fault in reload. * Admin * Some interviewing == Next Week == * symbol_ref splitting * Test code alignment hypothesis * Test v2 patch. * Hot/Cold Partitioning: * Investigate remaining silent code-gen faults and non-termination issue in SPEC * If failures are fixed start profiledbootstraps and tests on the central boards. == Future == * Look at Cards for Vectorization, PGO and LTO with Michael. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 10 - 14 September
== Progress == * Started looking at https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/1029454 * Confirmed the failure * Unfortunately the git bisect I thought would find the fix didn't * Hot/Cold partitioning in PGO: * Some further investigations * Talked to Uli about one failure - he gave me some further pointers * Admin * Some interviewing == Next Week == * Continue looking at 1029454: cselim tree optimizer generates incorrect code * Start looking at merging the ARM public 4.7 GCC branch into gcc-linaro/4.7 * Hot/Cold Partitioning: * Investigate remaining silent code-gen faults and non-termination issue in SPEC * If failures are fixed start profiledbootstraps and tests on the central boards. * symbol_ref splitting * Test code alignment hypothesis * Test v2 patch. == Future == * Look at Cards for Vectorization, PGO and LTO with Michael. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 17 - 21 September
== Progress == * Fixed https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/1029454 * After investigating further found that this was actually an issue already fixed in FSF upstream * 4.7 AArch64 merge into gcc-linaro/4.7 * Did an initial merge of upstream ARM/aarch64-4.7-branch into gcc-linaro/4.7 * So far it hasn't broken other platforms * Investigated getting FastModels working for me * Hot/Cold partitioning in PGO: * Tidied up current patches ready for reposting upstream * Handed current status to Christophe == Next Week == * HOT/COLD partitioning for PGO: * Complete hand-over to Christophe * Get two current patches accepted upstream * Post question upstream about register allocation 'mistakes' I am seeing * ARM/aarch64-4.7-branch merge into gcc-linaro/4.7. * Get a test run of aarch64 targetted compiler complete * Confirm no code generation changes for other back-ends * symbol_ref splitting * Test code alignment hypothesis * Test v2 patch. * Admin * Several interviews == Future == * Look at Cards for Vectorization, PGO and LTO with Michael. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 24 - 28 September 2012
== Progress == * 4.7 AArch64 merge into gcc-linaro/4.7 * Got Foundation model working * Ran testsuite - results OK - some obvious infrastructure issues though * Hot/Cold partitioning in PGO: * Posted second patch upstream * Had basic flaw with it pointed out (shame was the flaw fixed the issue) * Admin * Interviewing == Next Week == * Start of month branch merges. * HOT/COLD partitioning for PGO: * Get two current patches accepted upstream * Post question upstream about register allocation 'mistakes' I am seeing * ARM/aarch64-4.7-branch merge into gcc-linaro/4.7. * Investigate failure in testsuite run * Check that I am merging the svn branches correctly. * Participate in sprint * symbol_ref splitting * Test code alignment hypothesis * Test v2 patch. == Future == * Look at Cards for Vectorization, PGO and LTO with Michael. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 1 - 5 October 2012
== Progress == * 4.6 and 4.7 start of month merges * Fixed missing binary files issues whilst doing this. * 4.7 AArch64 merge into gcc-linaro/4.7 * Completed initial merge * Admin * Interviewing == Next Week == * Deputise for Michael * Do GCC-Linaro releases * Fix up any issues with aarch64 merge. * HOT/COLD partitioning for PGO: * Get two current patches accepted upstream * Post question upstream about register allocation 'mistakes' I am seeing * symbol_ref splitting * Test code alignment hypothesis * Test v2 patch. == Future == * Look at Cards for Vectorization, PGO and LTO with Michael. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Test Case to verify the support of VFPV3 and VFPV4
On 9 October 2012 10:37, Jubi Taneja wrote:
> Hi All,
>
> I wanted to see the difference in objdump of an application where I can make
> the difference between the VFPV3 and VFPV4 support. I tried enabling the
> flag -mfpu=vfpv3 and -mfpu=vfpv4 for ARM Cortex A15 toolchain in my test
> code but cannot see the difference in two objdumps.
Try the following (tested against FSF GCC:
/* arm-none-linux-gnueabi-gcc -mcpu=cortex-a15 -mfpu=vfpv4 -S -o-
/tmp/fma.c -mfloat-abi=hard -O2 */
float f(float a, float b, float c)
{
return a * b + c;
}
/* end of tmp.c */
(Note that -mfloat-abi=softfp will also work in this example. Which
one you want to use depends on whether you have configured your system
for hard or soft-float ABIs).
> According to my survey, the fused multiply and accumulate is the only
> instruction that can create the difference in two. Can any one provide the
> sample test code for the same? Precisely, I wish to see the difference in
> performance for vfpv3 and vfpv4.
I would be surprised if you see much difference at all. VFPv3 has the
VMLA (non-fused multiply-accumulate) instruction, which does an extra
rounding-step, but I expect will have similar performance
characteristics to VFMA.
Note that between -mfpu=vfpv3 and -mfpu=vfpv4 there is also
-mfpu=vfpv3-fp16 which added support for loading and storing
half-precision floating-point values. Again this won't make a
performance difference unless you use half-precision as your storage
format.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Test Case to verify the support of VFPV3 and VFPV4
On 9 October 2012 12:09, Peter Maydell wrote:
> On 9 October 2012 11:21, Matthew Gretton-Dann
> wrote:
>> On 9 October 2012 10:37, Jubi Taneja wrote:
>>> I wanted to see the difference in objdump of an application where I can make
>>> the difference between the VFPV3 and VFPV4 support. I tried enabling the
>>> flag -mfpu=vfpv3 and -mfpu=vfpv4 for ARM Cortex A15 toolchain in my test
>>> code but cannot see the difference in two objdumps.
>>
>> Try the following (tested against FSF GCC:
>>
>> /* arm-none-linux-gnueabi-gcc -mcpu=cortex-a15 -mfpu=vfpv4 -S -o-
>> /tmp/fma.c -mfloat-abi=hard -O2 */
>> float f(float a, float b, float c)
>> {
>> return a * b + c;
>> }
>> /* end of tmp.c */
>
> I would have expected that you would need a gcc option to tell it that
> non-IEEE floating point results are OK. Otherwise it's not valid to
> emit a fused multiply-add for a*b+c because IEEE specifies that you
> should get a rounding step between the multiply and the add. Or
> does gcc default to non-IEEE arithmetic?
GCC defaults to -ffp-contract=fast which according to the manual:
> enables floating-point expression contraction
> such as forming of fused multiply-add operations if the target has
> native support for them
Which as Peter notes is not IEEE compliant.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Test Case to verify the support of VFPV3 and VFPV4
On 9 October 2012 11:58, Jubi Taneja wrote:
> Hi Matt,
>
> Thanks for sharing the information.
>
> On Tue, Oct 9, 2012 at 3:51 PM, Matthew Gretton-Dann
> wrote:
>>
>> On 9 October 2012 10:37, Jubi Taneja wrote:
>> > Hi All,
>> >
>> > I wanted to see the difference in objdump of an application where I can
>> > make
>> > the difference between the VFPV3 and VFPV4 support. I tried enabling the
>> > flag -mfpu=vfpv3 and -mfpu=vfpv4 for ARM Cortex A15 toolchain in my test
>> > code but cannot see the difference in two objdumps.
>>
>> Try the following (tested against FSF GCC:
>>
>> /* arm-none-linux-gnueabi-gcc -mcpu=cortex-a15 -mfpu=vfpv4 -S -o-
>> /tmp/fma.c -mfloat-abi=hard -O2 */
>> float f(float a, float b, float c)
>> {
>> return a * b + c;
>> }
>> /* end of tmp.c */
>>
>> (Note that -mfloat-abi=softfp will also work in this example. Which
>> one you want to use depends on whether you have configured your system
>> for hard or soft-float ABIs).
>>
> I checked both with -mfpu=vfpv3 and -mfpu=vfpv4 and it generates the same
> assembly code. VMLA insn is emitted for both the cases. I was wondering if I
> can get any test case so that I may observe the difference in the two
> objdumps.
Which compiler are you using? VFMA support is only in trunk FSF GCC.
Linaro has not yet backported support to 4.7.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Test Case to verify the support of VFPV3 and VFPV4
On 9 October 2012 14:44, Jubi Taneja wrote:
>
>
> On Tue, Oct 9, 2012 at 5:21 PM, Matthew Gretton-Dann
> wrote:
>>
>> >> /* arm-none-linux-gnueabi-gcc -mcpu=cortex-a15 -mfpu=vfpv4 -S -o-
>> >> /tmp/fma.c -mfloat-abi=hard -O2 */
>> >> float f(float a, float b, float c)
>> >> {
>> >> return a * b + c;
>> >> }
>> >> /* end of tmp.c */
>> >>
>> >> (Note that -mfloat-abi=softfp will also work in this example. Which
>> >> one you want to use depends on whether you have configured your system
>> >> for hard or soft-float ABIs).
>> >>
>> > I checked both with -mfpu=vfpv3 and -mfpu=vfpv4 and it generates the
>> > same
>> > assembly code. VMLA insn is emitted for both the cases. I was wondering
>> > if I
>> > can get any test case so that I may observe the difference in the two
>> > objdumps.
>>
>> Which compiler are you using? VFMA support is only in trunk FSF GCC.
>> Linaro has not yet backported support to 4.7.
>
>
> I am using FSF GCC only.
What version of GCC (what does arm-none-linux-gneabi-gcc -v report?).
When I compile the test case above with a recent (within last month or
so) trunk GCC I get the following output which uses vfma:
$
/work/builds/gcc-fsf-arm-none-linux-gnueabi/tools/bin/arm-none-linux-gnueabi-gcc
-mcpu=cortex-a15 -mfpu=vfpv4 -S -o- /tmp/fma.c -mfloat-abi=hard -O2
.cpu cortex-a15
.eabi_attribute 27, 3
.eabi_attribute 28, 1
.fpu vfpv4
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file "fma.c"
.text
.align 2
.global f
.type f, %function
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vfma.f32s2, s0, s1
fcpys s0, s2
bx lr
.size f, .-f
.ident "GCC: (GNU) 4.8.0 20120913 (experimental)"
.section.note.GNU-stack,"",%progbits
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ANNOUNCE] Linaro GCC 4.7 and Linaro GCC 4.6 2012.10 released
The Linaro Toolchain Working Group is pleased to announce the 2012.10 release of both Linaro GCC 4.7 and Linaro GCC 4.6. Linaro GCC 4.7 2012.10 is the seventh release in the 4.7 series. Based off the latest GCC 4.7.2+svn191881 release, it includes ARM-focused performance improvements and bug fixes. Interesting changes include: * Updates to GCC 4.7.2+svn191881 * Backport changes to use VLD1 for Neon quad loads. Fixes: * LP 1053348: Missing binary files Linaro GCC 4.6 2012.10 is the twentieth release in the 4.6 series. Based off the latest GCC 4.6.3+svn191880 release, this is the seventh release after entering maintenance. Interesting changes include: * Updates to 4.6.3+svn191880 * A fix to LP #1029454 The source tarballs are available from: https://launchpad.net/gcc-linaro/+milestone/4.7-2012.10 https://launchpad.net/gcc-linaro/+milestone/4.6-2012.10 Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro More information on the features and issues are available from the release pages: https://launchpad.net/gcc-linaro/4.7/4.7-2012.10 https://launchpad.net/gcc-linaro/4.6/4.6-2012.10 Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain Bugs: https://bugs.launchpad.net/gcc-linaro/ Questions? https://ask.linaro.org/ Interested in commercial support? Inquire at supp...@linaro.org -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 8 - 12 October 2012
== Progress == * Deputising for Michael * 4.6 and 4.7 2012.10 releases * Included extra AArch64 merge into gcc-lianro/4.7 * AArch64 support * Did another merge * Starting another one. * HOT/COLD partitioning for PGO * PINGed If/Then/Else block conversion patch * Started reworking postreload-gcse.c patch * Ran into issues with vanilla gcc-linaro/4.7 not being able to build for 'arm-none-linux-gnueabihf' without some configury magic * Admin * Interviewing == Next Week == * Do another AArch64 merge. * HOT/COLD partitioning for PGO: * Get two current patches accepted upstream * Post question upstream about register allocation 'mistakes' I am seeing * symbol_ref splitting * Test code alignment hypothesis * Test v2 patch. == Future == * Look at Cards for Vectorization, PGO and LTO with Michael. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 15 - 19 October
== Progress == * HOT/COLD partitioning for PGO * Submitted merge request for current changes so that we can benchmark and see how much benefit we can actually expect * Patch Tracking & Backporting * Backported Uli's fix for insn splitting at -O0 to 4.7 * Started backporting Doko's configury changes for arm-none-linux-gnueabihf support * Connect Prep * Started investigating LRA * Admin * Interviewing == Next Week == * Prepare for Connect * Investigate zero/sign extension * Investigate LRA * Investigate Conditional Comparison benefits * AArch64 * Document processes == Future == * Attend Connect * HOT/COLD partitioning for PGO: * Get two current patches accepted upstream * Post question upstream about register allocation 'mistakes' I am seeing -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Test Case to verify the support of VFPV3 and VFPV4
On 20 October 2012 09:41, Jubi Taneja wrote:
> Hi Mathew
>
> On Tue, Oct 9, 2012 at 11:37 PM, Matthew Gretton-Dann
> wrote:
>>
>> On 9 October 2012 14:44, Jubi Taneja wrote:
>> >
>> >
>> > On Tue, Oct 9, 2012 at 5:21 PM, Matthew Gretton-Dann
>> > wrote:
>> >>
>> >> >> /* arm-none-linux-gnueabi-gcc -mcpu=cortex-a15 -mfpu=vfpv4 -S -o-
>> >> >> /tmp/fma.c -mfloat-abi=hard -O2 */
>> >> >> float f(float a, float b, float c)
>> >> >> {
>> >> >> return a * b + c;
>> >> >> }
>> >> >> /* end of tmp.c */
>> >> >>
>> >> >> (Note that -mfloat-abi=softfp will also work in this example. Which
>> >> >> one you want to use depends on whether you have configured your
>> >> >> system
>> >> >> for hard or soft-float ABIs).
>> >> >>
>> >> > I checked both with -mfpu=vfpv3 and -mfpu=vfpv4 and it generates the
>> >> > same
>> >> > assembly code. VMLA insn is emitted for both the cases. I was
>> >> > wondering
>> >> > if I
>> >> > can get any test case so that I may observe the difference in the two
>> >> > objdumps.
>> >>
>> >> Which compiler are you using? VFMA support is only in trunk FSF GCC.
>> >> Linaro has not yet backported support to 4.7.
>> >
>> >
>> > I am using FSF GCC only.
>>
>> What version of GCC (what does arm-none-linux-gneabi-gcc -v report?).
>
> # arm-none-linux-gneabi-gcc -v
> Using built-in specs.
> COLLECT_GCC=arm-none-linux-gneabi-gcc
> COLLECT_LTO_WRAPPER=/opt/toolchains/arm/bin/../libexec/gcc/arm-none-linux-gneabi/4.6.3/lto-wrapper
> Target: arm-none-linux-gneabi
> Configured with: /home/user/arm-src/build/sources/gcc_1/configure
> --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
> --target=arm-none-linux-gneabi --prefix=/opt/arm
> --with-sysroot=/opt/arm/arm-none-linux-gneabi/sys-root --disable-libmudflap
> --disable-libssp --disable-libgomp --disable-nls --disable-libstdcxx-pch
> --with-interwork --with-mode=arm --with-fpu=vfp3 --with-cpu=cortex-a9
> --with-tune=cortex-a9 --with-float=softfp --enable-extra-vd-multilibs
> --enable-poison-system-directories --enable-long-long --enable-threads
> --enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu
> --enable-__cxa_atexit --with-pkgversion=arm-toolchain.v1 --with-gnu-as
> --with-gnu-ld --with-host-libstdcxx='-static-libgcc
> -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-build-time-tools=/opt/arm/bin
> --with-gmp=/opt/arm --with-mpfr=/opt/arm --with-ppl=/opt/arm
> --with-cloog=/opt/arm --with-libelf=/opt/arm
> Thread model: posix
> gcc version 4.6.3 (arm-toolchain.v1)
This is gcc 4.6.3 not current trunk (which would report gcc version 4.8.0).
GCC 4.6.3 does not support VFMA.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 22-26 October
== Progress == * HOT/COLD partitioning for PGO * Initial look at results * Patch Tracking & Backporting * Testing Doko's configury changes for arm-none-linux-gnueabihf support * Connect Prep * LRA Investigations * Sign/zero extension II == Next Week == * Linaro Connect == Future == * Attend Connect * HOT/COLD partitioning for PGO: * Get two current patches accepted upstream * Post question upstream about register allocation 'mistakes' I am seeing -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: ARM cross mismatch error
Naveen, On 31 October 2012 13:10, naveen yadav wrote: > Dear All, > > We have ARM cross compiler, and building our code. we got below error. > we have GCC Linaro 4.6.4. > > arm-linux-gnueabi/bin/ld: DIV usage mismatch between > /home/Release/libasm.a(Blt32_Neon.o) and /home/Release/liblayer.so > arm-linux-gnueabi/bin/ld: failed to merge target specific data of file > /home/Release/libasm.a(Blt32_Neon.o) There isn't enough information here for us to tell what is going wrong here. Can you provide a small test case please? This should include the C source that you compile, along with the compiler and linker command lines used. I would expect that to invoke this error you would need only two C source files. > is it related to below link ? > > http://sourceware.org/ml/binutils/2012-03/msg00211.html Unlikely as the error in that link was due to missing files in the binutils repository. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 29 Oct - 2 Nov
== Progress == * Attended Linaro Connect * Worked out focus for performance in next iteration: * Cortex-A15 * Other discussions on: * Transitioning from cbuild->LAVA * ARMv8 GNU Tools support * big.LITTLE Toolchain tuning == Next Week == * Backport Doko's configury changes for arm-none-linux-gnueabihf support * Remerge HOT/COLD partitioning to test like for like (TBB generation) * Benchmark LRA vs Reload on x86 and x86-64 * Write up strawman for non-multitest testing in GCC == Future == * Decide whether the effort to develop HOT/COLD partitioning is worth it. * Support LRA on ARM. * Attend Connect in Hong Kong... -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 5 - 9 November
== Blueprints == InitialCurrentActual initial-aarch64-backport31 Oct 201230 Nov 2012 aarch64-baremetal-testing 31 Oct 201230 Nov 2012 fix-gcc-multiarch-testing 31 Dec 201231 Dec 2012 backport-fma-intrinsic 31 Dec 201231 Dec 2012 fused-multiply-add-support 31 Dec 201231 Dec 2012 gcc-investigate-lra-for-arm 31 Dec 201231 Dec 2012 == Progress == * Returned from Connect and followed up. * Updated performance blueprints for next iteration * Backporting Doko's triplet patches to 4.7 * Patches ready except for problems building Ada * HOT/COLD partitioning * Rebuilt with TBB/TBH disabled always * Started investigated LRA for ARM == Next Week == * Post triplet backport patches upstream * Run HOT/COLD partitioning benchmarks * On ARM to see if TBB/TBH is making the difference previously seen * On x86_64 to see what the actual benefit we could get * initial-aarch64-backport & aarch64-baremetal-testing * Finish documentation * gcc-investigate-lra-for-arm * Benchmark on x86_64 to see what the benfit could be. * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. == Future == * backport-fma-intrinsic & fused-multiply-add-support * Backport patches once fix-gcc-multiarch-testing has been done. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ANNOUNCE] Linaro GCC 4.7 and Linaro GCC 4.6 2012.11 released
The Linaro Toolchain Working Group is pleased to announce the 2012.11 release of both Linaro GCC 4.7 and Linaro GCC 4.6. Linaro GCC 4.7 2012.11 is the eigth release in the 4.7 series. Based off the latest GCC 4.7.2+svn193200 release, it includes ARM-focused performance improvements and bug fixes. Interesting changes include: * Updates to GCC 4.7.2+svn193200 * Also includes arm/aarch64-4.7-branch up to svn revision 193328. Fixes: * LP #1065122 * LP #1065559 * LP #1067760 Linaro GCC 4.6 2012.11 is the 21st release in the 4.6 series. Based off the latest GCC 4.6.3+svn193199 release, this is the eigth release after entering maintenance. Interesting changes include: * Updates to 4.6.3+svn193199 The source tarballs are available from: https://launchpad.net/gcc-linaro/+milestone/4.7-2012.11 https://launchpad.net/gcc-linaro/+milestone/4.6-2012.11 Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro More information on the features and issues are available from the release pages: https://launchpad.net/gcc-linaro/4.7/4.7-2012.11 https://launchpad.net/gcc-linaro/4.6/4.6-2012.11 Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain Bugs: https://bugs.launchpad.net/gcc-linaro/ Questions? https://ask.linaro.org/ Interested in commercial support? Inquire at supp...@linaro.org -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 12-16 November
== Blueprints == InitialCurrentActual initial-aarch64-backport31 Oct 201230 Nov 2012 aarch64-baremetal-testing 31 Oct 201230 Nov 2012 fix-gcc-multiarch-testing 31 Dec 201231 Dec 2012 backport-fma-intrinsic 31 Dec 201231 Dec 2012 fused-multiply-add-support 31 Dec 201231 Dec 2012 gcc-investigate-lra-for-arm 31 Dec 201231 Dec 2012 == Progress == * Admin * Interviewing * Hand over prep with Michael * Release Week * Made 2012.11 releases of gcc-linaro 4.6 and 4.7. * LEG interations: * Investigated CILK+ and how much work to port to AArch64. * HOT/COLD partitioning * Ran benchmarks on ARM * LRA * Ran x86-64 benchmarks == Next Week == * Investigate patches for literal pool layout bug * Post triplet backport patches upstream * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * initial-aarch64-backport & aarch64-baremetal-testing * Finish documentation * gcc-investigate-lra-for-arm * Analyse benchmarks * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. == Future == * backport-fma-intrinsic & fused-multiply-add-support * Backport patches once fix-gcc-multiarch-testing has been done. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 19-23 November 2012
== Blueprints == InitialCurrentActual initial-aarch64-backport31 Oct 201230 Nov 2012 aarch64-baremetal-testing 31 Oct 201230 Nov 2012 fix-gcc-multiarch-testing 31 Dec 201231 Dec 2012 backport-fma-intrinsic 31 Dec 201231 Dec 2012 fused-multiply-add-support 31 Dec 201231 Dec 2012 gcc-investigate-lra-for-arm 31 Dec 201231 Dec 2012 == Progress == * Admin * Interviewing * Investigate patches for literal pool layout bug * Took longer than expected as the 'simple' fix is wrong due to GCC not knowing how large instructions actually are. * Patch posted upstream * Post triplet backport patches upstream * Other bug issues * Including an issue running SPEC2K on x86 with recent trunk == Next Week == * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * initial-aarch64-backport & aarch64-baremetal-testing * Finish documentation * gcc-investigate-lra-for-arm * Analyse benchmarks * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. == Future == * backport-fma-intrinsic & fused-multiply-add-support * Backport patches once fix-gcc-multiarch-testing has been done. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[MINUTES] Toolchain Performace Call 2012-11-27
All, [Editiorial: Michael & I discussed making what we do as a working group more visible at Connect. One thing we discussed was making our meeting minutes more visible by emailing actions out after each meeting. This will be part of the job of the 'minuter' - a job I plan to spread around as I am useless at it whilst also running a call - more info on the Wiki: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings] The minutes of the performance call held on 27 November 2012 can be found at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-11-27 In summary the actions from the meting are: * mgrettondann split LRA blueprint * Christophe to update Hot/Cold partitioning bugzilla * mgrettondann: benchmark on Hold/Cold partitioning * Michael to log a ticket to improve reporting of benchmarks when the run complete. * Ramana to log EEMBC failure with Hot/Cold partitioning into bugzilla. * Christophe to backport bswap16 builtin, except for the testcase which fails in one of our configurations (Thumb1 + hard FP ABI) The next performance call will be on 11 December 2012 and the agenda can be found at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-12-11 Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 26-30 November
== Blueprints == InitialCurrentActual initial-aarch64-backport31 Oct 20127 Dec 2012* aarch64-baremetal-testing 31 Oct 20127 Dec 2012* fix-gcc-multiarch-testing 31 Dec 201231 Dec 2012 backport-fma-intrinsic 31 Dec 201231 Dec 2012 fused-multiply-add-support 31 Dec 201231 Dec 2012 gcc-investigate-lra-for-arm 31 Dec 201231 Dec 2012 == Progress == * Admin * Interviewing * Preparation for taking over from Michael * Investigate patches for literal pool layout bug * Applied * PINGed triplet backport patches upstream * Other bug issues * Including an issue running SPEC2K on x86 with recent trunk * And a 4.6 gcc-linaro only issue == Next Week == * Start leading Toolchain team * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * initial-aarch64-backport & aarch64-baremetal-testing * Finish documentation * gcc-investigate-lra-for-arm * Analyse benchmarks * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. == Future == * backport-fma-intrinsic & fused-multiply-add-support * Backport patches once fix-gcc-multiarch-testing has been done. == Planned Leave == * Monday 24 December - Monday 31 December -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Toolchain Working Group Meeting Times
All, As I mentioned on Monday, due to new members of the team coming on board I am going to rejig the meeting times from 18th December. My proposal is as follows (all times UK Local - UTC+0h winter, UTC+1h summer): 0. These changes will come into effect the week commencing 18th December. 1. The weekly call will happen on a Monday, at 0930 and 1600. You only need to make it to one instance of the call. For those who are physically near each other arranging it so that both calls get attended would be good and notes shared would be good. 2. The Stand-up call will happen on a Thursday, alternating between 0930 and 1600. This is 'best effort' - but please try to attend at least every other week. 3. The performance call will go weekly, and will happen on a Thursday, alternating between 0930 and 1600. If you are on the invite list to this call again please try to attend at least every other week, but if you can manage every week that would be great. If you have any comments on these please can you raise them by the end of the week as I would like to confirm what we are going to do at the call on Monday (at the normal time of 0915UTC). Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: selected processor does not support Thumb mode `smc 0'
Hi, On 7 December 2012 13:19, Shivamurthy Shastri wrote: > Hi, > > I am trying to compile UEFI code with linaro toolchain version: > > # arm-linux-gnueabi-gcc --version > arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.1-5ubuntu1~ppa1) 4.7.1 > Copyright (C) 2012 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > I got the erros as follows: > > "/usr/bin/arm-linux-gnueabi-gcc" -mthumb -march=armv7-a > -I/home/shiva/workspace/arndale/edk2/SamsungPlatformPkg/ExynosPkg/Exynos5250/Include/Platform > -g -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-missing-braces > -Wno-array-bounds -c -include AutoGen.h -mword-relocations -mlittle-endian > -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char > -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -O0 -o > /home/shiva/workspace/arndale/edk2/Build/Arndale-Exynos/DEBUG_ARMLINUXGCC/ARM/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec/OUTPUT/./Smc.obj > -I/home/shiva/workspace/arndale/edk2/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec > -I/home/shiva/workspace/arndale/edk2/Build/Arndale-Exynos/DEBUG_ARMLINUXGCC/ARM/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec/DEBUG > -I/home/shiva/workspace/arndale/edk2/MdePkg > -I/home/shiva/workspace/arndale/edk2/MdePkg/Include > -I/home/shiva/workspace/arndale/edk2/MdePkg/Include/Arm > -I/home/shiva/workspace/arndale/edk2/MdeModulePkg > -I/home/shiva/workspace/arndale/edk2/MdeModulePkg/Include > -I/home/shiva/workspace/arndale/edk2/ArmPkg > -I/home/shiva/workspace/arndale/edk2/ArmPkg/Include > -I/home/shiva/workspace/arndale/edk2/ArmPlatformPkg > -I/home/shiva/workspace/arndale/edk2/ArmPlatformPkg/Include > -I/home/shiva/workspace/arndale/edk2/SamsungPlatformPkg/ExynosPkg/Exynos5250 > -I/home/shiva/workspace/arndale/edk2/SamsungPlatformPkg/ExynosPkg/Exynos5250/Include > /home/shiva/workspace/arndale/edk2/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Smc.c > Smc.s: Assembler messages: > Smc.s:51: Error: selected processor does not support Thumb mode `smc 0' > > Is there any issue with the toolchain or any flags I am using? The issue is the -march=armv7-a option. Technically, baseline ARMv7-A does not support the 'smc' instruction - it is added by the Security Extensions. Gas (which is the program producing your error message) is following this behaviour. Gas does expose -march=armv7-a+sec which does allow 'smc', unfortunately GCC does not understand this option. There are two ways around this: 1) Use -mcpu= instead of -march=armv7-a. If all you want is 'smc', using -mcpu=cortex-a8 will do. 2) If you are using inline assembly to generate the 'smc' instruction, add '.arch_extension sec' to the assembly before the sec instruction. I hope this helps. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 3-7 December 2012
== Blueprints == InitialCurrentActual initial-aarch64-backport31 Oct 201214 Dec 2012 aarch64-baremetal-testing 31 Oct 201214 Dec 2012 fix-gcc-multiarch-testing 31 Dec 201231 Dec 2012 backport-fma-intrinsic 31 Dec 201231 Dec 2012 fused-multiply-add-support 31 Dec 201231 Dec 2012 gcc-investigate-lra-for-arm 31 Dec 201231 Dec 2012 == Progress == * Admin * Interviewing * Took over from Michael * Preparation for taking over from Michael * re-PINGed triplet backport patches upstream * Patch review * Initial thoughts about cards == Next Week == * initial-aarch64-backport and aarch64-baremetal-testing * Complete documentation * gcc-investigate-lra-for-arm * Analyse benchmarks * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. == Future == * backport-fma-intrinsic & fused-multiply-add-support * Backport patches once fix-gcc-multiarch-testing has been done. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: FPU error with arm-linux-gnueabihf-gcc 3.7.3
On 10 December 2012 14:53, Zhangfei Gao wrote: > We met build error when using arm-linux-gnueabihf-gcc 3.7.3 for Huawei > s40v200 kernel, which is 3.0.8, log is below. > > HAVE issue: > gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux.tar.bz2 > gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux.tar.bz2 > gcc-linaro-arm-linux-gnueabi-2012.03-20120326_linux.tar.bz2, with build flag > --with-float=softfp > > > NO issue: > arm-eabi-gcc 4.4.0, which comes from android package. > > Any suggestion? > > Thanks > > make[1]: `include/generated/mach-types.h' is up to date. > CALLscripts/checksyscalls.sh > CHK include/generated/compile.h > AS arch/arm/mach-godbox/hi_pm_sleep.o > arch/arm/mach-godbox/hi_pm_sleep.S: Assembler messages: > arch/arm/mach-godbox/hi_pm_sleep.S:456: Error: selected processor does not > support requested special purpose register -- `mrs r10,FPEXC' > arch/arm/mach-godbox/hi_pm_sleep.S:456: Error: selected processor does not > support requested special purpose register -- `msr FPEXC,r2' > arch/arm/mach-godbox/hi_pm_sleep.S:456: Error: selected processor does not > support requested special purpose register -- `mrs r2,FPSCR' > arch/arm/mach-godbox/hi_pm_sleep.S:546: Error: selected processor does not > support requested special purpose register -- `msr FPEXC,r2' > arch/arm/mach-godbox/hi_pm_sleep.S:546: Error: selected processor does not > support requested special purpose register -- `msr FPSCR,r10' > arch/arm/mach-godbox/hi_pm_sleep.S:546: Error: selected processor does not > support requested special purpose register -- `msr FPEXC,r9' > make[1]: *** [arch/arm/mach-godbox/hi_pm_sleep.o] Error 1 > make: *** [arch/arm/mach-godbox] Error 2 > make: *** Waiting for unfinished jobs Can you show me the complete command line for assembling arch/arm/mach-godbox/hi_pm_sleep.S into arch/arm/mach-godbox/hi_pm_sleep.o please? And also the output of gcc -v? My guess is that you are building GCC yourself have specified --with-float=softfp, but not specified the actual floating point architecture with --with-fpu= on the GCC configure line. See the documentation for -mfpu= in the GCC manuals to see what values are valid here (again guessing but you probably want --with-fpu=vfpv3 or --with-fpu=neon - but I don't know what architecture you are actually compiling for). Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 10 - 14 December
== Blueprints == InitialCurrentActual initial-aarch64-backport31 Oct 201231 Dec 2012 aarch64-baremetal-testing 31 Oct 201231 Dec 2012 backport-fma-intrinsic 31 Dec 2012Brice fused-multiply-add-support 31 Dec 2012Brice gcc-investigate-lra-for-arm 31 Dec 201231 Dec 2012 fix-gcc-multiarch-testing 31 Dec 201231 Jan 2013 == Progress == * Admin * Interviewing * Took over from Michael * New Starter prep * Updated card drafts * Discussions about LEG/TCWG interactions * Discussions about KVM * Discussions about Toolchain/Platform interactions == Next Week == * Upload card drafts into Jira. * initial-aarch64-backport and aarch64-baremetal-testing * Complete documentation == Future == * gcc-investigate-lra-for-arm * Analyse benchmarks * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Merge] lp:~brice-dobry/gcc-linaro/fma into lp:gcc-linaro
On 21 December 2012 09:54, Yvan Roux wrote: > Matt, do you have something particular in mind to put in a shared and > versioned .bzrignore file ? > My understanding of its usage is that it is more a user side configuration of > the archive. > (Maybe we could chat about this topic on another channel) Yes this conversation should probably be conducted elsewhere :-) - moved to linaro-toolchain. If you look at upstream SVN GCC and do svn propget svn:ignore you get a long list of files that SVN is set up to ignore. And whilst there isn't a .gitignore other upstream projects which have git mirrors do put a .gitignore in place (see GDB for instance). I think having a .bzrignore which is a copy of the svn:ignore set up (and the defaults that SVN ignores but aren't on bzr's list) would be valid in the repo. Although as I said in the original thread - let's do this when we branch 4.8 and not to the historic branches. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 17-21 December 2012
== Blueprints == InitialCurrentActual initial-aarch64-backport31 Oct 201231 Dec 201221 Dec 2012 aarch64-baremetal-testing 31 Oct 201231 Dec 201221 Dec 2012 backport-fma-intrinsic 31 Dec 2012Brice fused-multiply-add-support 31 Dec 2012Brice gcc-investigate-lra-for-arm 31 Dec 2012Brice fix-gcc-multiarch-testing 31 Dec 201231 Jan 2013 == Progress == * Admin * Interviewing * Welcomed Brice Dobry to the working group * Started inputting cards into cards.linaro.org * Discussions about KVM * Discussions about Toolchain/Platform interactions * initial-aarch64-backport and aarch64-baremetal-testing * Finished documentation == Next (working) week == * Admin * Finish loading card drafts into Jira. * Welcome Renato to working group. * Do monthly GCC merges * Prepare Cortex Strings release * Ensure GCC backports are up to date. == Future == * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: R_ARM_TLS_DTPMOD32 Relocation
[gcc-help removed from CC as this is probably not a GCC issue.] On 31 December 2012 13:12, naveen yadav wrote: > Dear All, > > When doing prelink I got following error. > > /a.out > /a.out: R_ARM_TLS_DTPMOD32 reloc in executable? > > Gcc version 4.6 > > I have following question: > 1. What this relocation do. ? The answer to this is found in the ABI document: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044-/index.html Sections 4.6.1.9 and 4.6.1.10 detail the purpose of this relocation and how it is to be interpreted. In summary it resolves to the module number of the relocated symbol or of the current module. > 2. Is it problem in tool chain ? The toolchain is allowed to generate this relocation - so it probably isn't a toolchain issue. But you don't give enough information to be able to work this out - we need a full testcase with source and command lines used. > 3. Are we need to fix this in Prelink utils As I said above, I don't have enough information to answer this with confidence. But my guess is that yes - you are going to have to handle this (and the related relocations) in the prelink utilities. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 2-4 January 2013
== Blueprints == InitialCurrentActual fix-gcc-multiarch-testing 31 Dec 201231 Jan 2013 == Progress == * Short week, working Weds-Fri * Admin * Welcomed Renato to the team, and discussions with him about LLVM * Initial project setup for llvm-linaro. * Finished putting current set of card drafts into Jira * Did GCC merges * Backport of Thumb literal pool issues to 4.7. == Next week == * Prepare Cortex Strings release * Ensure GCC backports are up to date. * Merge reviewing week. * Catch up on outstanding cards. == Future == * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [PATCH] Cortex Strings AArch64 optimized implementations of memmove, strlen and strncmp
On 04/01/13 17:18, Marcus Shawcroft wrote: Folks, This series of patches adds aarch64 specific implementations of memmove, strlen, strncmp to the cortex strings library and the corresponding test cases lifted directly from glibc. These are OK and have been applied. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[Minutes] Minutes of Weekly Team meeting 7 Jan 2013
All, The minutes from today's meeting are online at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2013-01-07 The Action items are: TODO: Matt to investigate EEMBC Office gs8 failures TODO: Matt to talk to Dave Pigott about HF builders TODO: Matt blueprint backport of binutils 2.23.1 TODO: Matt to blueprint options for reducing QEMU based cross test noise ACTION: Matt to unreserve Michael Hope's reservations ACTION: Matt to look at why Cortex-A9 softfloat bootstraps fail in Stage2. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [PATCH] cortex strings adding aarch64 specific strnlen
This has been applied. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [PATCH] Adding test-strnlen to cortex strings.
On 07/01/13 15:31, Marcus Shawcroft wrote: This patch adds the strnlen test from glibc in preparation for an AArch64 specific strnlen implementation... This has been applied. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [PATCH] cortex strings adding aarch64 specific memcmp
This has been applied. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: compiler crash while building c++ libs
Anup, On 10/01/13 11:16, Anup Kini wrote: Hi All, I am using linaro-precise-ubuntu-desktop-20120626 on my ZYNQ ZC702 board which has an ARM Cortex-A9 dual core processor. I am trying to compile Point Cloud Library and its dependent libraries like FLANN, VTK, EIGEN etc.. which are basically c++ libraries. The compiler crashes with the following error msg and i am unable to figure out where the problem is. linaro@linaro-ubuntu-desktop:~/flann/flann-1.8.3-src/build$ make install [ 33%] Building CXX object src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o In file included from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/algorithms/kmeans_index.h:51:0, from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/algorithms/all_indices.h:38, from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/flann.hpp:45, from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/flann.h:466, from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/flann.cpp:31: /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/util/logger.h:73:9: note: the mangling of ‘va_list’ has changed in GCC 4.4 c++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. make[2]: *** [src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o] Error 4 make[1]: *** [src/cpp/CMakeFiles/flann_s.dir/all] Error 2 make: *** [all] Error 2 linaro@linaro-ubuntu-desktop:~/flann/flann-1.8.3-src/build$ Let me know if someone has faced similar issue or has any solution for this. I'm afraid I don't have enough information to give much help here. However, here are some ideas: > c++: internal compiler error: Killed (program cc1plus) One of the causes of this is that the compiler has run out of available memory. How much memory do you have on your machine? There are other possibilities though - so can you try and reproduce the failure outside of the make file? It looks to me as if you are using cmake so do make VERBOSE=1 and grep the output for the g++ command line that builds flann.cpp. Then in the build directory repeat that command adding -save-temps on the command-line. This should create a *.ii file in the current directory which contains the preprocessed source. Try compiling the *.ii file to see if it generates the failure. If it does then please file a bug against gcc-linaro in Launchpad (if the GCC you are using is Linaro GCC) - if it isn't please file a bug in the appropriate place for that GCC distribution. Attach the *.ii file in the bug report as this will enable others to try and reproduce the problem. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: compiler crash while building c++ libs
On 10/01/13 13:38, Anup Kini wrote: Hi Matthew, Thanks for the reply. I tried with VERBOSE=1 command and the virtual memory has been exhausted. I check for the free space and its around 5.3 GB. Let me know if there is any additional compiler tags i can use to free up or use less memory. I looked into the forums and found that similar issues were faced with 4.4 and 4.5 release but they were all baselined to 4.6. GCC --version = gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) --- cut above this -- No need to remake target `../src/cpp/flann/flann.hpp'. Pruning file `src/cpp/CMakeFiles/flann_s.dir/flags.make'. Finished prerequisites of target file `src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o'. Must remake target `src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o'. make[2]: Entering directory `/home/linaro/flann/flann-1.8.3-src/build' /usr/bin/cmake -E cmake_progress_report /home/linaro/flann/flann-1.8.3-src/build/CMakeFiles 3 Putting child 0x00040958 (src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o) PID 3390 on the chain. Live child 0x00040958 (src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o) PID 3390 [ 33%] Reaping winning child 0x00040958 PID 3390 Live child 0x00040958 (src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o) PID 3391 Building CXX object src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o Reaping winning child 0x00040958 PID 3391 *cd /home/linaro/flann/flann-1.8.3-src/build/src/cpp && /usr/bin/c++ -D_FLANN_VERSION=1.8.3 -DFLANN_STATIC -fopenmp -O2 -g -I/home/linaro/flann/flann-1.8.3-src/src/cpp-Wall -Wno-unknown-pragmas -Wno-unused-function -fPIC -o CMakeFiles/flann_s.dir/flann/flann.cpp.o -c /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/flann.cpp* Live child 0x00040958 (src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o) PID 3393 In file included from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/algorithms/kmeans_index.h:51:0, from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/algorithms/all_indices.h:38, from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/flann.hpp:45, from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/flann.h:466, from /home/linaro/flann/flann-1.8.3-src/src/cpp/flann/flann.cpp:31: */home/linaro/flann/flann-1.8.3-src/src/cpp/flann/util/logger.h:73:9: note: the mangling of ‘va_list’ has changed in GCC 4.4 virtual memory exhausted: Cannot allocate memory Reaping losing child 0x00040958 PID 3393 * make[2]: *** [src/cpp/CMakeFiles/flann_s.dir/flann/flann.cpp.o] Error 1 Removing child 0x00040958 PID 3393 from chain. make[2]: Leaving directory `/home/linaro/flann/flann-1.8.3-src/build' Reaping losing child 0x00045828 PID 3389 make[1]: *** [src/cpp/CMakeFiles/flann_s.dir/all] Error 2 Removing child 0x00045828 PID 3389 from chain. make[1]: Leaving directory `/home/linaro/flann/flann-1.8.3-src/build' Reaping losing child 0x000382c0 PID 3385 make: *** [all] Error 2 Removing child 0x000382c0 PID 3385 from chain. linaro@linaro-ubuntu-desktop:~/flann/flann-1.8.3-src/build$ When i run it on my laptop it does not require more than 300 mb to compile. I am not sure what the problem is on my board (ZNQ ZC702). It has an SD Card with 7.4 gb for the filesystem and 5.3 GB is free. That 5.3GB won't be used for virtual memory unless you create a swap partition. To find out how much memory your board has (assuming you are running Linux on it use the 'free' command. If your board has significantly more than 300MB available then can you please raise a bug report in Launchpad. I don't think we will get this fixed in 4.6 - but it is a good test case to check memory usage in 4.8. The difference in memory usage between x86 and ARM can be down to the different targets being compiled for requiring different code generation strategies. As for working round the issue - my suggestion is either: a) Use a cross compiler (so build on x86 targetting ARM); or b) split the source file into many smaller files. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: compiler crash while building c++ libs
On 10/01/13 14:05, Anup Kini wrote: The free command returned the following details. Does this mean the system has no SWAP ?? total used free sharedbuffers cached Mem: 1029884 440069 589016 0 16364138784 -/+ buffers/cache : 284920 744164 swap: 0 0 0 Yes this means you have no swap on your system. But you do have 1GB of memory of which about 575 MB is free, so I would still say the evidence is that this test case is using excessive amounts of memory and so raising a bug report would be useful. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 7-11 January 2013
== Blueprints == InitialCurrentActual fix-gcc-multiarch-testing 31 Dec 201231 Jan 2013 == Progress == * Infrastructure * Investigations of why Cortex-A9 HF boards are failing * Admin * Booked tickets to Connect * 'Onboarding' prep for new starters and assignees * Cortex Strings * Applied patches == Next week == * Prepare Cortex Strings release * Ensure GCC backports are up to date. * Release week. * Catch up on outstanding cards. == Future == * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[MINUTES] Toolchain Working Group Weekly Meeting 14/Jan/2013
All, The minutes for today's calls are here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2013-01-14 Action items are: TODO: Matt to investigate EEMBC Office gs8 failures ONGOING: Matt to talk to Dave Pigott about HF builders TODO: Matt blueprint backport of binutils 2.23.1 - backport just needs merging TODO: Matt to blueprint options for reducing QEMU based cross test noise TODO: Matt to unreserve Michael Hope's reservations TODO: Matt to look at why Cortex-A9 softfloat bootstraps fail in Stage2. TODO: Zhenqiang to do GCC Release: https://wiki.linaro.org/WorkingGroups/ToolChain/GCC/ReleaseProcess TODO: Matt to do Cortex Strings release. TODO: Matt chase up EEMBC Networking License TODO: Matt chase up with morvek who is leading KVM Virtual team. TODO: All to think of proposals for GNU Tools Caudron The agenda for next week's call is here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2013-01-21 Please feel free to add your own agenda items before hand. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [PATCH] Cortex Strings AArch64 strnlen.S fix
On 16/01/13 14:22, Marcus Shawcroft wrote: This patch fixes an issue in the AArch64 strncmp implementation which occurs if ULONG_MAX-15 <= n <= ULONG_MAX. Matt, this is the last of my outstanding patches for cortex-strings. /Marcus Applied. Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [PATCH] Cortex Strings AArch64 fix for strncmp.S
On 16/01/13 14:21, Marcus Shawcroft wrote: This patch fixes an issue in the AArch64 strncmp implementation which occurs if ULONG_MAX-15 <= n <= ULONG_MAX. /Marcus ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain Applied. Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Thursday 17th January 2013 1600 UTC Performance Call cancelled
All, Due to items in the performance call being covered in other meetings, travel and other issues I have decided to cancel today's 1600 UTC call. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 31 Jan - 1 Feb
== Progress == * Welcomed Omair to the team working on GDB * Starting investigating cortex-a9 bootstrap failure * Blueprints updating * Preparing for two new starters next week == Next week == * Welcome two new members to the team. * Finish cortex-a9 bootstrapping investigations == Future == * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Hard Floating Point Question
On 2 February 2013 00:13, Derek Rollend wrote: > Hello, > > I am currently trying to determine how much I can optimize OpenCV using the > ARM's VFP and the Linaro nano image. I have downloaded the > arm-linux-gnueabihf-gcc & arm-linux-gnueabihf-g++ compilers, successfully > cross-compiled OpenCV using those compilers (with -O3 -mfloat-abi=hard > -ftree-vectorize -funroll-loops), and compiled an example OpenCV program > with the arm-linux-gnueabihf-g++ compiler (with the same flags). However, > when I try and run my executable within Linaro (running on a gumstix overo) > I get "/lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.15' not found > (required by /usr/lib/libopencv_core.so.2.2). > > I assume that this is because on my build machine (x86 Ubuntu 10.04) where I > cross compiled the OpenCV libraries I am using libc-2.15, and on the target > (gumstix) the loader can't find libc-2.15. However, within the > gcc-linaro-arm-linux-gnueabihf-4.7 tar ball I downloaded today, there is a > libc-2.15.so file in there that I copied into /lib/ on the gumstix. Still > no success though when I try running my executable. > > Any recommendations on things to try? I am hesitant to just put a newer > version of glibc in Linaro as it seems like that could screw a lot of things > up. Should I attempt to re-build OpenCV somehow with an older version of > glibc (namely libc-2.13)? Expand the entire sysroot tarball you have onto your ARM board into some location (say /opt/gcc-linaro - but anywhere will do). Then do: LD_LIBRARY_PATH=/opt/gcc-linaro/lib/arm-linux-gnueabihf program-to-execute args Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: using linaro toolcahin to cross compile simple .c file
On 06/02/13 10:40, Swati Deshmukh wrote:
hi,
i am using linaro toolcahin binaries to execute simple .c file , so that it
creates ARM executable output file i can run on Linaro installed on Hackberry
board.
this are the all steps i follwed from beginnng..
please let me know if i am missing something here..
1. i have downloaded gcc for ubuntu from this link
https://launchpad.net/linaro-toolchain-binaries/+milestone/2012.04
2. on ubuntu, i did tar xjf
gcc-linaro-arm-linux-gnueabi-2012.04-20120426_linux.tar.bz2 export
ARM_CROSS_TOOLS=pwd/gcc-linaro-arm-linux-gnueabi-2012.04-20120426_linux/bin/arm-linux-gnueabi-
export ARMCC=${ARMEL_CROSS_TOOLS}gcc
& then
$ARMCC hello.c
it created a.out (which is simple executable file and not ARM executable)
GCC's default output file name for any executable is a.out - no matter what
format.
If you do execute the following this should show that the a.out you have is
indeed an ARM executable:
file a.out
The expected output will be something like:
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.16, not stripped
To get GCC to give the output file a particular name you need to use the -o
option to GCC.
Thanks,
Matt
--
Matthew Gretton-Dann
Toolchain Working Group, Linaro
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 4-8 Feb 2013
== Progress == * Welcomed Kugan to the team working on GCC * Welcomed James Elliott to the team as project manager * Found Cortex-A9 bootstrapping issue raised as PR56184 * Fixed build issues in GCC and GDB. * Patch reviews. == Next week == * Investigate PR56184 further. == Future == * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 11-12 February 2013
== Progress == * Very short working week. * Discussions about next steps in Lava integration. * Followed up on Arndale/GCC build issues. == Next week == * Review pending Backports * Investigate bootstrap ICE PR56184 further == Future == * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
New IRC Channel for Linaro Toolchain Working Group
All, During Connect the suggestion was made that each working group should have its own IRC Channel for discussions and topics relating to the group in particular (as opposed to #linaro which is 'generic' Linaro conversations). Therefore I have just set up #linaro-tcwg on Freenode for the Toolchain Working Group. This channel is public and open to anyone who wants to talk with the TCWG group about anything toolchain related. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Linaro GCC 4.7 and 4.6 2013.03 released
The Linaro Toolchain Working Group is pleased to announce the 2013.03 release of both Linaro GCC 4.7 and Linaro GCC 4.6. Linaro GCC 4.7 2013.03 is the twelth release in the 4.7 series. Based off the latest GCC 4.7.2+svn195745 release, it includes ARM-focused performance improvements and bug fixes. Interesting changes include: * Updates to GCC 4.7.2+svn196272 * Includes arm/aarch64-4.7-branch up to svn revision 196225 * A fix for LP #1135633: [linaro regression] alsa-tools FTBFS with error "unable to find a register to spill in class ‘AREG’" Linaro GCC 4.6 2013.02 is the 25th release in the 4.6 series. Based off the latest GCC 4.6.3+svn196247 release, this is the twelth release after entering maintenance. Interesting changes include: * Updates to 4.6.3+svn196247 The source tarballs are available from: https://launchpad.net/gcc-linaro/+milestone/4.7-2013.03 https://launchpad.net/gcc-linaro/+milestone/4.6-2013.03 Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro More information on the features and issues are available from the release pages: https://launchpad.net/gcc-linaro/4.7/4.7-2013.03 https://launchpad.net/gcc-linaro/4.6/4.6-2013.03 Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain Bugs: https://bugs.launchpad.net/gcc-linaro/ Questions? https://ask.linaro.org/ Interested in commercial support? Inquire at supp...@linaro.org -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: cbuild binutils job
On 08/04/13 14:29, Will Newton wrote: Hi all, Currently the binutils job that gets run via cbuild configures with --enable-gold. I guess this could be useful to ensure the gold build is not broken, but has the downside of slowing down the build and causing make check to fail. I propose we do not enable gold until such a time as we wish to formally support gold and fix the broken make check. Does anybody have any objections to doing that? Yes... In theory binutils includes gold - and at least for arm*-*-* targets it should work. However, I can also see your point. Can I suggest we do something different then: 1) Disable gold in the binutils cbuild job. 2) Have a new binutils-gold job which disable the traditional BFD linker and enables gold. This keeps the fact that gold is broken 'alive' in the build system, but allows us to show that binutils with ld is fine. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Thoughts on progressing Toolchain Working Group Lava integration
Paul, I've been having some thoughts about CBuild and Lava and the TCWG integration of them both. I wish to share them and open them up for general discussion. The background to this has been the flakiness of the Panda's (due to heat), the Arndale (due to board 'set-up' issues), and getting a batch of Calxeda nodes working. The following discussion refers to building and testing only, *not* benchmarking. If you look at http://cbuild.validation.linaro.org/helpers/scheduler you will see a bunch of calxeda01_* nodes have been added to CBuild. After a week of sorting them out they provide builds twice as fast as the Panda boards. However, during the setup of the boards I came to the conclusion that we set build slaves up incorrectly, and that there is a better way. The issues I encountered were: * The Calxeda's run quantal - yet we want to build on precise. * Its hard to get a machine running in hard-float to bootstrap a soft-float compiler and vice-versa. * My understanding of how the Lava integration works is that it runs the cbuild install scripts each time, and so we can't necessarily reproduce a build if the upstream packages have been changed. Having thought about this a bit I came to the conclusion that the simple solution is to use chroots (managed by schroot), and to change the architecture a bit. The old architecture is everything is put into the main file-system as one layer. The new architecture would be to split this into two: 1. Rootfs - Contains just enough to boot the system and knows how to download an appropriate chroot and start it. 2. Chroots - these contain a setup build system that can be used for particular builds. The rootfs can be machine type specific (as necessary), and for builds can be a stock linaro root filesystem. It will contain scripts to set the users needed up, and then to download an appropriate chroot and run it. The chroot will be set up for a particular type of build (soft-float vs hard-float) and will be the same for all platforms. The advantage of this is that I can then download a chroot to my ChromeBook and reproduce a build locally in the same environment to diagnose issues. The Calxeda nodes in cbuild use this type of infrastructure - the rootfs is running quantal (and I have no idea how it is configured - it is what Steve supplied me with). Each node then runs two chroots (precise armel and precise armhf) which take it in turns to ask the cbuild scheduler whether there is a job available. So my first question is does any of the above make sense? Next steps as I see it are: 1. Paul/Dave - what stage is getting the Pandaboards in the Lava farm cooled at? One advantage of the above architecture is we could use a stock Pandaboard kernel & rootfs that has thermal limiting turned on for builds, so that things don't fall over all the time. 2. Paul - how hard would it be to try and fire up a Calxeda node into Lava? We can use one of the ones assigned to me. I don't need any fancy multinode stuff that Michael Hudson-Doyle is working on - each node can be considered a separate board. I feel guilty that I put the nodes into CBuild without looking at Lava - but it was easier to do and got me going - I think correcting that is important 3. Generally - What's the state of the Arndale boards in Lava? Fathi has got GCC building reliably, although I believe he is now facing networking issues. 4. Paul - If Arndale boards are available in Lava - how much effort would it be to make them available to CBuild? One issue the above doesn't solve as far as I see it is being able to say to Lava that we can do a build on any ARMv7-A CBuild compatible board. I don't generally care whether the build happens on an Arndale, Panda, or Calxeda board - I want the result in the shortest possible time. A final note on benchmarking. I think the above scheme could work for benchmarking targets all we need to do is build a kernel/rootfs that is setup to provide a system that produces repeatable benchmarking results. Comments welcome from all. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: g++ 4.7.3 ICEs building SNU
On 15/04/13 21:29, Tom Gall wrote: Hi, Feel free to point me at a newer toolchain. Was building the SNU OpenCL SDK native on my chromebook running ubuntu raring when I hit the following: make: Entering directory `/home/tgall/opencl/SNU/src/runtime/build/cpu' arm-linux-gnueabihf-g++ - -mfpu=neon -ftree-vectorize -ftree-vectorizer-verbose=0 -fsigned-char -fPIC -DDEF_INCLUDE_ARM -g -c -o smoothstep.o /home/tgall/opencl/SNU/src/runtime/hal/device/cpu/common/smoothstep.c -I/home/tgall/opencl/SNU/inc -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/async -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/atomic -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/common -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/conversion -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/geometric -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/integer -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/math -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/reinterpreting -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/relational -I/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/vector -O0 -g In file included from /home/tgall/opencl/SNU/src/runtime/hal/device/cpu/cl_cpu_ops.h:47:0, from /home/tgall/opencl/SNU/src/runtime/hal/device/cpu/common/smoothstep.c:34: /home/tgall/opencl/SNU/src/runtime/hal/device/cpu/type/cl_ops_floatn.h: In function 'float2 operator-(float, float2)': /home/tgall/opencl/SNU/src/runtime/hal/device/cpu/type/cl_ops_floatn.h:114:1: internal compiler error: output_operand: invalid operand for code 'P' Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/cciluYVq.out file, please attach this to your bugreport. Traceback (most recent call last): File "/usr/share/apport/gcc_ice_hook", line 34, in pr.write(open(apport.fileutils.make_report_path(pr), 'w')) File "/usr/lib/python2.7/dist-packages/problem_report.py", line 254, in write self._assert_bin_mode(file) File "/usr/lib/python2.7/dist-packages/problem_report.py", line 632, in _assert_bin_mode assert (type(file) == BytesIO or 'b' in file.mode), 'file stream must be in binary mode' AssertionError: file stream must be in binary mode make: *** [smoothstep.o] Error 1 I can reproduce this with upstream 4.7 and trunk (and so presumably with 4.8). I've raised it upstream with a reduced testcase. See http://gcc.gnu.org/PR56979. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Thoughts on progressing Toolchain Working Group Lava integration
On 16/04/13 14:08, Matthias Klose wrote: Am 16.04.2013 11:49, schrieb Matthew Gretton-Dann: The issues I encountered were: * Its hard to get a machine running in hard-float to bootstrap a soft-float compiler and vice-versa. hmm, why? when using precise or quantal as the build environment, then having these packages installed should be good enough: libc6-dev-armhf [armel], libc6-dev-armel [armhf] binutils g++-multilib Although I still have a local patch to support the multilib configuration: http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.8/debian/patches/arm-multilib-defaults.diff?revision=6640&view=markup I honestly don't know what the issue is - except that when I try to bootstrap a vanilla FSF GCC arm-none-linux-gnueabi with the initial host compiler as arm-none-linux-gnueabihf I get failures during libraries builds in stage 1. Also given that we try to build vanilla compilers, and so for 4.6 & 4.7 that requires fiddling with links in /usr/lib and /usr/include to point into the multiarch stuff, doing this in a chroot is safer than on the main system. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
http://cbuild.validation.linaro.org/helpers/recent ISE today
All, http://cbuild.validation.linaro.org/helpers/recent was reporting an Internal Server Error earlier today, and after looking at the logs the resultant cause was because the gcc-4.8+svn198079 Lava job (https://validation.linaro.org/lava-server/scheduler/job/52224) decided that it was an a9 (as opposed to a9hf) job and that it didn't no which version of Ubuntu it was running on. The caused the logs to be put in http://cbuild.validation.linaro.org/build/gcc-4.8+svn198079/logs/armv7l--cbuild-panda-es06-cortexa9r1/ The tcwg-web app then fell over because it couldn't pass the armv7l--cbuild-panda-es06-cortexa9r1 name. I fixed the issue by manually renaming the build log directory to: http://cbuild.validation.linaro.org/build/gcc-4.8+svn198079/logs/armv7l-precise-cbuild-panda-es06-cortexa9r1/ And once the cron job which scans the builds had run everything now works. Actions: 1. Paul - do you mind taking a look at the build and seeing what went wrong - my initial cursory glance makes me believe its the board having heat issues causing random things to happen. 2. Paul & Matt - Looking at the code (and from something else Michael said to me last week) I think having hostnames with '-' characters in them will confuse the cbuild interface. I propose changing cbuild to do a s/-/_/g on all the hostname it reads as a workaround. I don't plan on changing actual hostnames of boards. Paul is this going to cause a problem for you in Lava? Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Undefined __aeabi_uidiv references in blobs with 4.8 toolchain
Bero,
On 26/04/13 22:17, Bernhard Rosenkränzer wrote:
Hi,
I'm running into an interesting problem with driver blobs when building
Android with the 4.8 toolchain:
E/libEGL ( 1219):
load_driver(/vendor/lib/egl/libEGL_POWERVR_SGX540_120.so): Cannot load
library: soinfo_link_image(linker.cpp:1635): could not load library
"libIMGegl.so" needed by "libEGL_POWERVR_SGX540_120.so"; caused by
soinfo_link_image(linker.cpp:1635): could not load library "libsrv_um.so"
needed by "libIMGegl.so"; caused by soinfo_relocate(linker.cpp:975): cannot
locate symbol "__aeabi_uidiv" referenced by "libsrv_um.so"...
__aeabi_uidiv is a libgcc.a function (Android doesn't have libgcc_s) - and
the blob makers didn't link libgcc.a properly, so it is understandable why
this would be missing.
However, Android's libc has an ugly but (up until now) working workaround
that is supposed to address this sort of issue.
So technically if you don't provide these functions somewhere in your
toolchain you aren't ABI compliant. And this hack looks odd.
It includes libgcc_compat.c, which comes down to
#define COMPAT_FUNCTIONS_LIST \
XX(__aeabi_uidiv) \
... (same for other libgcc functions)
#define XX(f) extern void f(void);
COMPAT_FUNCTIONS_LIST
#undef XX
void __bionic_libgcc_compat_hooks(void)
{
#define XX(f) f();
COMPAT_FUNCTIONS_LIST
#undef XX
}
Running nm on libc.so shows the symbol is actually in libc.so, and it seems
to be visible.
$ nm /system/lib/libc.so |grep aeabi_uidiv
0004f5d8 t __aeabi_uidiv
0004f680 t __aeabi_uidivmod
libsrv_um.so is linked to libc too, so it should see it...
$ objdump -x /vendor/lib/libsrv_um.so |grep libc.so
NEEDED libc.so
Can anyone think of a reason why this would work fine if the system is
built with the 4.7 toolchain, but break with 4.8?
My first thought was that 4.8 might have miscompiled the dynamic linker -
but the problem remains if I copy in /system/bin/linker from the 4.7 build.
Has the symbol visibility of __aeabi_uidiv changed?
What are you building for? Cortex-A15 and -A7 have divide instructions, so
you might have issues there.
It might also be worth seeing what libgcc_s looks like in 4.7 and 4.8 and
see what has changed about the objects there.
Thanks,
Matt
--
Matthew Gretton-Dann
Toolchain Working Group, Linaro
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Undefined __aeabi_uidiv references in blobs with 4.8 toolchain
On 04/05/13 00:21, Bernhard Rosenkränzer wrote: Hi, I've looked into this some more today... But it still looks rather odd. Has the symbol visibility of __aeabi_uidiv changed? Apparently not... I've checked a diff between gcc-4.7/libgcc and gcc-4.8/libgcc and didn't find any changes that seem related. Given I also didn't see any relevant ABI changes, I ran a little experiment and removed libgcc.a from 4.8, and copied in libgcc.a from 4.7 (yes, I know that's pure evil ;) ). How did you diff gcc-4.7/libgcc and gcc-4.8/libgcc? What does readelf give as the symbol types and visibility? Interestingly enough, that toolchain produces a fully functional (including blobs) Android build. I still don't see anything relevant in the diff - but of course another difference is that 4.7's libgcc.a is compiled with 4.7 while 4.8's is compiled with 4.8, so it may be related to something 4.8 does differently while building libgcc.a. This looks like a linkage issue and as 4.7's libgcc works even with 4.8 built objects I think its a change in the libgcc library (and not how things are getting called - although that would be worth checking - what's the difference between the callers from both objects). So if you could diff the objects within libgcc.a that contain __aeabi_uidiv that would be great. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Undefined __aeabi_uidiv references in blobs with 4.8 toolchain
Bero, So looking at how I build GCC __aeabi_uidiv is HIDDEN for 4.7 and 4.8. Looking at the source for libgcc one way the use of the hidden attribute is determined at configure time with an assembler test. So can you you post your libgcc/config.log somewhere for 4.7 & 4.8, and point us to them? (To save time I'm also probably going to want the complete build log at some stage for libgcc - so it is probably worth posting those as well). In particular I am interested in the values of vs_hide and libgcc_cv_hidden_visibility_attribute. Thanks, Matt On 08/05/13 10:10, Bernhard Rosenkränzer wrote: On 7 May 2013 10:37, Matthew Gretton-Dann wrote: On 04/05/13 00:21, Bernhard Rosenkränzer wrote: How did you diff gcc-4.7/libgcc and gcc-4.8/libgcc? Checked out the sources and looked at the output of diff -urN gcc-4.7/libgcc gcc-4.8/libgcc What does readelf give as the symbol types and visibility? Symbol visibility does seem to have changed (even though I didn't spot it in the source)... 4.7: File: libgcc.a(_udivsi3.o) 16: 0 FUNCGLOBAL DEFAULT1 __aeabi_uidiv 4.8: File: libgcc.a(_udivsi3.o) 16: 0 FUNCGLOBAL HIDDEN 1 __aeabi_uidiv Will take another look to see where it changed... Either I missed it or it's a default setting outside of the libgcc directory. ttyl bero -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Undefined __aeabi_uidiv references in blobs with 4.8 toolchain
On 08/05/13 20:53, Bernhard Rosenkränzer wrote: On 8 May 2013 15:29, Bernhard Rosenkränzer wrote: I've attached the config logs - full builds are still running. I've figured out what's going on. In libgcc/Makefile.in, lines 368+ (in 4.8)/lines 375+ (in 4.7), there's some AWK trickery to add .hidden to asm code. The difference is that in 4.7, that code is inside ifeq ($(enable_shared),yes) while 4.8 moved it outside of that block. The result is that on regular Linux, you'd have the symbols hidden in both 4.7 and 4.8 -- but on Android (where for whatever reason the decision was not to have a libgcc_s), it gets hidden only in 4.8. The problematic upstream commit is svn 190588. I think for now I'll just revert that change in Android toolchain builds to keep the hack in Bionic working - but I wonder what a proper fix could look like (or rather, a proper fix that we can do - meaning one that doesn't involve fixing up blobs we don't have the source to or getting Android upstream to introduce libgcc_s). The original discussion about this patch is here: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01462.html Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: hot spot on the vsub.f32 instruction
YongQin, On 13/05/13 13:52, YongQin Liu wrote: Hi, All The attachment file is analysed by the streamline tool. How to do you think about the vsub.f32 hot spot there? Is there any way we can improve that? Maybe - but you give very little information for us to help you. We need more context - a screengrab is not enough: * What is your source code? * How did you compile your source code? * What compiler did you use? * What platform are you testing on? * Is there anyway you can generate a smaller test case? Also please don't attach images to emails, use text files wherever possible, and if you need to attach an image please provide a link to it rather than including it in the email. Don't get too focused on the one instruction Streamline reports as being hot. Streamline is restricted to reporting what it is told by the kernel, and in an out-of-order super-scalar core it doesn't always match what is precisely happening. In this case my intuition tells me that the problem is the code sequence before the VSUB: LDR r5, [r4, #0x16c] @ 1 MOVS r3, #0xa4 @ 2 MLA r5, r3, r2, r5 @ 3 VLDR s15, [r5, #0x68]@ 4 VSUB.F32 s15, s15, s16 @ 5 Note the s15 source into insn 5 is loaded in the previous insn. Insn 4's base register is calculated from a Multiply-accumulate inn Insn 3, for which one of the sources is loaded in Insn 1. So I *think* the 'hotness' is coming from the dependent chain of instructions which when you get to the VSUB the core is waiting to complete before it can do the calculation. But this is a guess - I don't have enough information. There are instantly many theories I have around why is this the case, but I can't work out what is going on without the information I asked for above. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ANNOUNCE] Linaro GDB 7.6 2013.05 released
The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.6. Linaro GDB 7.6 2013.05 is the first release in the 7.6 series. ***NOTE*** Linaro GDB 7.6 2013.05 is identical to the FSF GDB 7.6 release, except for the change in version number and Linaro branding, since all Linaro GDB features were already accepted upstream and are included in the FSF release as-is. Future releases in the Linaro GDB 7.6 series may include additional ARM-focused bug fixes and enhancements. The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.6-2013.05 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Semi-hosting on v8 Foundation Model using gnu tools
Don, On 17/05/13 20:57, Padgett Don-B43265 wrote: The v8 Foundation Model User Guide has a bare metal hello world example that uses semi-hosting. The Makefile uses ARM tools, however. Is there equivalent support for this example using a bare metal version of the gnu tools, such as gcc-linaro-aarch64-none-elf-4.8-2013.04-20130422_linux.tar.xz? I took a look, but didn't see a way to do this. It is possible but not necessarily easy. Using the binary tools you've downloaded you will want to do something like the following: aarch64-none-elf-gcc -specs=elf-aem-ve.specs ... The -specs option has to be on all your invocations of GCC and G++. You should also invoke the linker through GCC with this option. Then you need to invoke the model, given an image called foo.axf: Foundation_v8 --image foo.axf --semi-host="foo.axf OPT1 OPT2" --quiet Note that the first option to --semi-host is the name of the image again. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Malloc usage
All, In the Toolchain Working Group Mans has been doing some examination of SPEC 2000 and SPEC 2006 to see what C Library (glibc) routines impact performance the most, and are worth tuning. This has come up with two areas we consider worthy of further investigation: 1) malloc performance 2) Floating-point rounding functions. This email is interested with the first of these. Analysis of malloc shows large amounts of time is spent in executing synchronization primitives even when the program under test is single-threaded. The obvious 'fix' is to remove the synchronization primitives which will give a performance boost. This is, of course, not safe and will require reworking malloc's algorithms to be (substantially) synchronization free. A quick Google suggests that there are better performing algorithms available (TCMalloc, Lockless, Hoard, &c), and so changing glibc's algorithm is something well worth investigating. Currently we see around 4.37% of time being spent in libc for the whole of SPEC CPU 2006. Around 75% of that is in malloc related functions (so about 3.1% of the total). One benchmark however spends around 20% of its time in malloc. So overall we are looking at maybe 1% improvement in the SPEC 2006 score, which is not large given the amount of effort I estimate this is going to require (as we have to convince the community we have made everyone's life better). 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? * Do you have any benchmarks that stress malloc and would provide us with some more data points? But any and all comments on the subject are welcome. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Failure to optimise (a/b) and (a%b) into single __aeabi_idivmod call
Kugan,
I don't have the source code to hand but how are the
sin()/cos()->sincos() optimizations handled?
Thanks,
Matt
On 5 June 2013 11:44, Kugan wrote:
> Hi,
>
> I am looking at best approach for
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721 - Failure to optimise
> (a/b) and (a%b) into single __aeabi_idivmod call in ARM architecture
>
> In sumary, the following c code results in __aeabi_idivmod() call and one
> __aeabi_idiv() call even though the former already calculates the quotient.
> int q = a / b;
> int r = a % b;
> return q + r;
>
> My question is what would be the best way to handle it. As I see there are
> few options with some issues.
>
> 1. Handling in gimple level, try to reduce the operations to equivalent of
> this. We should do this for the targets without integer divide.
>{q, r} = a % b;
> Gimple assign stmts have only one lhs operation (?). Therefore, lhs has to
> be made 64bit to signify return values of R0 and R1 returned together. I am
> not too sure of any implications on other architectures here.
>
> 2. Handling in expand_divmod. Here, when we see a div or mod operation, we
> will have to do a linear search to see if there is a valid equivalent
> operation to combine. If we find one, we can generate __aeabi_idivmod() and
> cache the result for the equivalent operation. As I see, this can get messy
> and might not be acceptable.
>
> 3. An RTL pass to process and combine these library calls. Possibly using
> cse. I am still looking at this.
>
> 4. Ramana tried a prototype to do the same using target pattens. He has
> ruled this out. (if you want more info, please refer to at
> https://code.launchpad.net/~ramana/gcc-linaro/divmodsi4-experiments)
>
> Any suggestion for best way to handle this?
>
> Thanks,
> Kugan
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: process for enabling gccgo in Linaro GCC binary distributions
Michael, There are two things here: 1. Enabling Go for AArch64 in GCC upstream 2. Supporting it in the Toolchain Working Group releases. For 1 please post your patches to this list for initial review along with testsuite results. Once we are happy you are not making any obvious mistakes you can post to the gcc-patc...@gcc.gnu.org list, and submit upstream. For 2 we need to go through TSC to get some changes to present cards. I am assuming this is coming from LEG? Can you send Kate Stewart, James Elliott, Andrea, Anmar & me an email detailing what you think you want in terms of support? Thanks, Matt On 2 October 2013 03:44, Michael Hudson-Doyle wrote: > 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 -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [PATCH] libatomic is now supported on AArch64
Michael, Yvan, Michael - thanks for posting upstream. Yvan can you do the commit on Michael's behalf as and when it gets approved? Thanks, Matt On 3 October 2013 23:45, Michael Hudson-Doyle wrote: > 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 >> >> -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [question]multi-arch support for arm and arm64
Hi, On 16 October 2013 11:45, Zhou Zhu wrote: > Hi, > We are working on userspace aarch64 and aarch32 apps and we are trying to > run 32/64 mode app simultaneously. > Is there any multi-arch support for mixed rootfs (has linkers/libs of both > arm and arm64)? It is possible to run both AArch32 (arm) and AArch64 (arm64) applications under an arm64 kernel. What is not possible is for an AArch32 user-space program to use an AArch64 user-space library (or any combination like this). So if you want to run 32-bit user-space programs you need to have installed all the 32-bit user-space libraries as well. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [PATCH] libatomic is now supported on AArch64
Michael, So you've made the request now :-). It has technically missed the deadline for the 2013.11 release, but will be in the 2013.12 release. Thanks, Matt On 20 October 2013 22:21, Michael Hudson-Doyle wrote: > Hello again, > > My patch has been committed to trunk now (in two parts, r203773, and > r203774). Is it appropriate to ask for this to be backported to the > linaro branch? If so can you do it? Apologies if this would have > happened anyway without the pestering... > > Cheers, > mwh > > Yvan Roux writes: > >> 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, >>> >>> Matt >>> >>> On 3 October 2013 23:45, Michael Hudson-Doyle >>> wrote: >>>> 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 >>>>> >>>>> >>> >>> >>> >>> -- >>> Matthew Gretton-Dann >>> Linaro Toolchain Working Group >>> matthew.gretton-d...@linaro.org -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: MMU Off / Strict Alignment
On 20 November 2013 17:57, Christopher Covington wrote: > Hi, > > We've noticed an issue trying to use the Linaro AArch64 binary bare metal > toolchain release with the MMU turned off for some low-level tests. > > Anytime puts, sprintf, etc. gets called, a reent structure gets created with > references to STDIN, STDOUT, STDERR FILE types. A member in the __sFile > struct, _mbstate, is an 8 byte struct, but is not aligned on an 8 byte > boundary. This means that when memset (or a similar function) gets called on > this struct, and doesn't operate one byte at a time, a data alignment fault > will be generated when operating out of device memory, such as on a system > where the MMU has not yet been turned on yet. > > I'm still examining possible fixes (I'll probably look at building with > -mstrict-align first), but I wanted to check if anyone had thoughts on the > subject and if Newlib upstream or Linaro consider using Newlib with the MMU > turned off to be a valid use case or if running the code that turns on the MMU > is considered a prerequisite to everything else. I've always viewed newlib as a C Library - and as such it doesn't provide system 'startup' code but rather assumes that has been run before you enter newlib (possibly by using libgloss). Certainly this is how the aarch64 port is structured - it provides system startup code which installs exception vectors and turns the MMU on for when using the AEM models. It also provides the .specs files to use with GCC to get that installed. So I think you want to write some CPU initialisation code for your particular core and hook it into libgloss. Basically this should involve writing a _cpu_init_hook of your own, and getting it built into its own .o file with libgloss, and providing appropriate .specs files. However, I can see the other viewpoint as well - the newlib should work without the MMU turned on. So I leave it to wiser heads than me to make a definitive statement on what newlib presupposes about the CPU state. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: segfault using __thread variable
+Ryan, +Kugan, On 17 December 2013 08:45, Michael Hudson-Doyle wrote: > 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_symndx) >>>+ globals->root.sgot->output_section->vma >>>+ globals->root.sgot->output_section->output_offset); >>> >>> and this is the code that determines the offset as written into the >>> relocation (elfnn-aarch64.c line 4248): >>> >>> off = symbol_got_offset (input_bfd, h, r_symndx); >>> ... >>> rela.r_offset = globals->root.sgot->output_section->vma + >>> globals->root.sgot->output_offset + off; >>> >>> Can you see the difference? The former is >>> "root.sgot->output_section->output_offset", the latter is >>> "root.sgot->output_offset". >> >> Yes, that does look a bit odd. > > Yes. And one is the difference between the reloc and the code value and > the other is zero... > >>> This suggests the rather obvious attached patch. I haven't tested this >>> exact patch, but its an obvious translation from a patch to >>> 692e2b8bcdd8325ebfbe1daace87100d53d15ad6^ which does work. I also >>> haven't tested the second hunk at all, but it seems plausible... >> >> Thanks for you analysis, the fix does look plausible indeed. ;-) >> >> Have you verified it fixes the problem you were seeing? > > To be super correct, I have not verified that the patch I sent you, when > applied to binutils tip, fixes the problem. But a patch that's > basically the same when applied to a slightly random commit from June > results in working binaries (and the unpatched version does not). > >> I'm about to disappear to sunnier climes > > One advantage of the southern hemisphere: my climes are already sunny... > >> for three weeks but I'll definitely look at it when I get back. I've >> added Marcus to CC in case he isn't reading this list. > > Cool. Would it be useful to report the bug in > https://sourceware.org/bugzilla/ as well? Yes please. Ryan or Kugan can you look at fixing this please? Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: "invalid expression as operand" in aarch64 inline asm
On 12 February 2014 02:29, Kugan wrote:
> Hi,
>
> I finally got around to checking the attached patch for the
> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1270789
>
> I noticed attached patch causes regression for pr38151.c in gcc test-suite.
>
> A reduced test-case that triggers this is:
> static unsigned long global_max_fast;
> int __libc_mallopt (int param_number, int value)
> {
> __asm__ __volatile__ ("# %[_SDT_A2]" :: [_SDT_A2] "nor"
> ((global_max_fast)));
> global_max_fast = 1;
> }
>
> In this regard I have couple of questions:
>
> 1. Is the in-line asm valid? Look ok to me.
> 2. For the pr38151.c regression, asm diff is as shown below.
>
> < add x0, x0, :lo12:.LANCHOR0
> < ldr x0, [x0]
> ---
>> ldr x0, [x0,#:lo12:.LANCHOR0]
>
> This causes:
> pr38151.c:(.text+0x10c): relocation truncated to fit:
> R_AARCH64_LDST64_ABS_LO12_NC against `.rodata'
> collect2: error: ld returned 1 exit status.
>
> If I however increase the alignment of .rodata where .LANCHOR0 is
> defined, this passes. Is alignment of BITS_PER_UNIT valid for
> SYMBOL_REF? If I change it as I am doing this attached patch, is there
> anything else I need to do.
>From the ARMARM:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0487a.b/index.html
The range on an LDR is:
Is the signed immediate byte offset, in the range -256 to 255,
encoded in the "imm9" field.
For the 32-bit variant: is the optional positive immediate
byte offset, a multiple of 4 in the range 0 to 16380, defaulting to 0
and encoded in the "imm12" field as /4.
For the 64-bit variant: is the optional positive immediate
byte offset, a multiple of 8 in the range 0 to 32760, defaulting to 0
and encoded in the "imm12" field as /8.
So in this case where we're taking the low 12-bits of ANCHOR0 we
should be ensuring it is aligned to 8-bytes (or less than 256 - but we
can't necessarily tell that at compile time).
So I think your patch is correct - the symbol needs to be aligned to
the size of the thing the symbol points to.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Reg: Recommended options for aarch64
Ganesh, Thank you for your email - please note this question is best directed at linaro-toolchain@lists.linaro.org where it is more likely to get picked up quickly. Our general rules for benchmarking are to use -mcpu=cortex-a## -O3 as the compiler flags (where ## is the particular CPU you are interested in). Linaro's philosophy is to try and get the best results possible that normal users will see, we don't go looking for 'magic' options that may give better performance on one benchmark, but not in general. Thanks, Matt On 20 February 2014 09:22, Gopalasubramanian, Ganesh wrote: > Hi, > > We would like to run some benchmarks in the foundation model. > I like to know which is the best option-set (GCC compiler options) that the > linaro community recommends for aarch64. > > Regards > Ganesh > -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
