Re: Thumb2 code size improvements

[Chung-Lin Tang]

This reminds me of a PR that Bernd did:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657

It is also support for adding the r0-r3 registers to the 
epilogue/prologue push-pop for sake of reducing code size, though in a 
sense even more aggressive; it tries to merge the local stack allocation 
SP sub/add with the stm/ldm.

Bernd's patch was for Thumb-1, though I don't see why it can't be 
implemented for ARM/Thumb-2 too.

Chung-Lin


On 2010/9/7 21:36, Julian Brown wrote:
> On Tue, 07 Sep 2010 21:06:10 +0800
> Yao Qi  wrote:
>
>> Julian Brown wrote:
>>> So yeah, I think there is indeed a possible improvement here (and we
>>> don't even need to break the EABI, I don't think). Unless I've
>>> overlooked something, anyway...
>> Julian,
>> I revert back the first example, and add your comments in it.
>> https://wiki.linaro.org/YaoQi/Sandbox/Thumb2SizeOptimize
>>
>> In order to teach gcc chooses low register when keeping stack
>> alignment, which part of gcc shall I have a look? Is it about RA or
>> regrename?
>
> No, all the code to generate prologues&  epilogues is target-specific,
> and happens after register allocation. Take a look at e.g.
> arm.c:arm_expand_prologue and friends. (Beware though, they can be
> quite fiddly!)
>
> Julian

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

binutils testsuite Thumb-2 coverage

[Chung-Lin Tang]

Hi,
about the status of binutils testsuite Thumb coverage (CS204 in the 
workplan), I have filed two Launchpad bugs:

#640263: Testsuite coverage: Thumb-2 VFP/NEON encodings
https://bugs.launchpad.net/binutils-linaro/+bug/640263

#640272: Testsuite coverage: Thumb relocations
https://bugs.launchpad.net/binutils-linaro/+bug/640272

To summarize: I currently do not see any testing of Thumb-2 VFP/NEON 
encodings; Thumb mode relocations are also only barely tested in the ld 
testsuite.

Also, please inform if there are any other areas of binutils Thumb 
testing that may be of concern to Linaro.

Thanks,
Chung-Lin

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Help on merging two patches

[Chung-Lin Tang]

Yao Qi wrote:

6801 ldr r1, [r0, #0]
f831 3013 ldrh.w r3, [r1, r3, lsl #1]
-f413 6f00 tst.w r3, #2048 ; 0x800
-f43f af41 beq.w cc 
+0518 lsls r0, r3, #20
+f57f af44 bpl.w cc 
4610 mov r0, r2



Someone suggests that the slowdown might be caused by usage of r0 in
first instruction. Since r0 is used in the first insn, the third insn
lsls can't overwrite r0 until first insn ldr is done.


It depends on whether the Cortex-A8 implemented any form of register 
renaming features. If they did, this should not be the problem.



The second patch is Bernd's "Fix an if statement in arm_rtx_costs_1"
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02096.html
After this patch applied, EEMBC benchmark number is not changed. Shall
we merge this patch to linaro 4.5 tree? I am inclined to merge it, but
if you have concerns on this patch, let us discuss here.


As we discussed in the meeting yesterday, the criteria of us picking up
upstreams patches is that patches don't slow down speed and don't
increase code size.

Code size is not reduced either on A8. I'll re-test this patch on A9. If
still no benefit either size or speed, we don't backport it to Linaro 4.5.


Well, you might try some other benchmarks? Maybe building ffmpeg or the 
Linux kernel to see if any code generation differences? Even slight 
improvements may warrant the backport, as it seems quite harmless.


Chung-Lin

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Upstream GCC feature freeze

[Chung-Lin Tang]

On 2010/11/8 下午 07:01, Andrew Stubbs wrote:

Here's my proposal:

  * Create a new Launchpad branch for GCC 4.6.

  * Synchronize this branch with upstream regularly
* once per week, perhaps.

  * Try to get upstream approval for all new patches in the usual way
* on the understanding that they won't be applied until stage 1
* bug fixes are unaffected and may commit as usual.

  * Commit all pending patches to our own 4.6 branch
* and backport them to our 4.5, branch, of course.

  * Usual "no test regressions" policy applies to our own patches
* but beware regressions from merges from upstream.
* we may want to track the clean 4.6 test results for comparison

This is little different to what we do with the 4.5 release branch now.


This looks fine, it actually isn't that much different from what we're 
doing now, except using another branch to hold our changes.


Still, I would like to see a 'linaro-trunk' branch under 
svn://gcc.gnu.org/svn/branches. It would actually serve a different 
purpose than a LP branch; the LP GCC 4.6 would probably eventually turn 
into Linaro 4.6, while a SVN branch would be a preparation for 
re-merging into mainline trunk when 4.7-stage1 opens. Also, for the GCC 
community, a SVN branch would probably be more convenient.


We can have our patches submitted to gcc-patches, and have it reviewed 
under the usual [patch, ] format, rather than the odd condition 
where we ask for approval, then accumulate in an outside repository.


Chung-Lin

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Nov.15 -- Nov.21

[Chung-Lin Tang]

== Linaro and upstream GCC ==
* Linaro launchpad issues:
- LP #672833, x64-64 varargs regression: after testing pushed bzr branch 
for merging.

- LP #634738, inefficient low bit extraction: some discussion with Yao.
- LP #618684, ICE when building ziproxy: looked into and quickly found 
not reproducible anymore of Linaro 4.5 trunk.


* Worked on some GCC bugzilla PRs:
- PR44557, ICE in Thumb-1 secondary reload: this should be fixed by a 
change of the scratch operand constraint of "reload_inhi" from "r" to 
"l". Interesting to note that this was from the 
merged-arm-thumb-backend-branch merge, from about 10 years ago.
- PR46508: libffi fails to build on VFP asm instructions, seems to need 
a '.fpu vfp' directive. Probably missed earlier because my toolchain was 
configured with --with-fpu=vfp.
- PR45416: 4.6 code generation regression on ARM, after expand from SSA 
changes. Looking at this currently.


== This week ==
* Look at Linaro issues with higher priority.
* Continue working on GCC PRs.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Nov.22 -- Nov.28

[Chung-Lin Tang]

== Linaro and upstream GCC ==
* LP #674146, dpkg segfaults during debootstrap on natty armel: analyzed 
and found this should be a case of PR44768, backported mainline revision 
161947 to fix this.


* LP #641379, bitfields poorly optimized. Discussed some with Andrew Stubbs.

* GCC bugzilla PR45416: Code generation regression on ARM. Been looking 
at this regression, that started from the expand from SSA changes since 
4.5-experimental. The problem seems to be TER not properly being 
substituted during expand (compared to prior "convert to GENERIC then 
expand"). I now have a patch for this, which fixes the PR's testcase, 
but when testing current upstream trunk, hit an assert fail ICE on 
several testcases in the alias-oracle; it does however, test without 
regressions on a 4.5 based compiler. I am still looking at the upstream 
failures.


== This week ==
* Continue with GCC issues and PRs.
* Think about GCC performance opportunities (Linaro)

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: A question about thumb2 cbnz/cbz implementation in thumb2.md

[Chung-Lin Tang]

Unfortunately, cbnz/cbz has a 6-bit:'0' (7-bit aligned to 2) immediate 
offset that is *zero extended*, i.e. it is only for forward branches.


Chung-Lin

On 2010/11/29 下午 04:14, Revital1 Eres wrote:


Hello,

I have a question about cbnz/cbz thumb-2 instruction implementation in
thumb2.md file:

I have an example where we jump to a label which appears before the branch;
for example:

 L4
 ...
 cmp r3, 0
 bne .L4

It seems that cbnz instruction should be applied in this loop; replacing
cmp+bne; however, cbnz fails to be applied as diff = ADDRESS (L4) - ADDRESS
(bne .L4) is negative and according to thumb2_cbz in thumb2.md it should
be 2<=diff<=128 (please see snippet below taken from thumb2_cbz).

So I want to double check if the current implementation of thumb2_cbnz
in thumb2.md needs to be changed to enable it.

The following is from thumb2_cbnz in thumb2.md:

   [(set (attr "length")
 (if_then_else
 (and (ge (minus (match_dup 1) (pc)) (const_int 2))
  (le (minus (match_dup 1) (pc)) (const_int 128))
  (eq (symbol_ref ("which_alternative")) (const_int 0)))
 (const_int 2)
 (const_int 8)))]

Thanks,
Revital


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain



___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: A question about thumb2 cbnz/cbz implementation in thumb2.md

[Chung-Lin Tang]

In the ARM architecture: Under ARM mode, the PC(r15) register value is 
"address of current insn + 8", while in Thumb mode (including Thumb-2), 
it is "address of current insn + 4"


With the way the cbz/cbnz immediate is defined, which is 0--126 (even), 
the branch range is then: +4 to +130  :)


On the issue of the doloop_end pattern for ARM/Thumb-2 in the context of 
enabling SMS, I actually have tried it in the past. IIRC, I used a 
"subs+bne" assembly sequence then.


Chung-Lin


On 2010/11/29 下午 04:37, Revital1 Eres wrote:

OK, thanks for your answer.
Is there other instruction for backward jumps that can be used
to replace cmp to zero+bne?

btw, in the following link of thumb-2 instructions set I understood that
the label can appear before the branch so it was confusing...

CB{N}Z Rn,  If Rn {== or !=} 0 then PC := label. label is (this
instruction + 4-130).

http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf

Thanks,
Revital




From:   Chung-Lin Tang
To: Revital1 Eres/Haifa/i...@ibmil
Cc: linaro-toolchain@lists.linaro.org
Date:   29/11/2010 10:21 AM
Subject:Re: A question about thumb2 cbnz/cbz implementation in
 thumb2.md



Unfortunately, cbnz/cbz has a 6-bit:'0' (7-bit aligned to 2) immediate
offset that is *zero extended*, i.e. it is only for forward branches.

Chung-Lin

On 2010/11/29 下午 04:14, Revital1 Eres wrote:


Hello,

I have a question about cbnz/cbz thumb-2 instruction implementation in
thumb2.md file:

I have an example where we jump to a label which appears before the

branch;

for example:

  L4
  ...
  cmp r3, 0
  bne .L4

It seems that cbnz instruction should be applied in this loop; replacing
cmp+bne; however, cbnz fails to be applied as diff = ADDRESS (L4) -

ADDRESS

(bne .L4) is negative and according to thumb2_cbz in thumb2.md it should
be 2<=diff<=128 (please see snippet below taken from thumb2_cbz).

So I want to double check if the current implementation of thumb2_cbnz
in thumb2.md needs to be changed to enable it.

The following is from thumb2_cbnz in thumb2.md:

[(set (attr "length")
  (if_then_else
  (and (ge (minus (match_dup 1) (pc)) (const_int 2))
   (le (minus (match_dup 1) (pc)) (const_int 128))
   (eq (symbol_ref ("which_alternative")) (const_int 0)))
  (const_int 2)
  (const_int 8)))]

Thanks,
Revital


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain







___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Nov.29 -- Dec.05

[Chung-Lin Tang]

== GCC related ==
* PR44557, Thumb-1 ICE: originally thought a fix of constraint will 
work, however after simplifying the testcase, received another ICE in 
postreload, due to a load of IP, which is not permitted in Thumb-1. 
Looking at some reload internals as part of fixing this.


* PR45416, ARM code generation regression. First fix from last week hit 
an assert FAIL in the alias-oracle due to ARRAY_REFs not being handled 
there. Also, further found some expand code quality regressions due to 
this change. Turned to a more conservative fix by adding the related TER 
substitution to expr.c:do_store_flag(), which produced more focused 
results. However, 32-bit x86 slightly regressed in the same flag storing 
code (did not use the 'testl' insn after the change). Still WIP.


* PR46667, submitted a section type conflict bug fix upstream, see 
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00137.html , which 
supposedly fixes the upstream ARM-Linux C++ build. Jan Hubicka later 
gave another fix, so still in discussion.


* PR45886, this PR is call for backporting the __ARM_PCS* preprocessor 
symbols to gcc-4_5-branch. Submitted a mail to ask for approval, no 
response.


== libffi VFP hard-float ==
* PR46508, libffi VFP assembly error. I missed this earlier due to using 
a compiler configured with --with-fpu=vfp. Submitted assembly fix to add 
the needed FPU directives. Committed to upstream trunk.


== This week ==
* Hope to wrap up the above in-progress PRs, as well as continue to look 
at other PRs of interest.
* LP #685534 popped up on Sunday, and manifests on upstream trunk too. 
Add this to queue.

* Think about GCC performance opportunities (Linaro)

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Dec.6th -- Dec.12th

[Chung-Lin Tang]

== GCC related ==
* PR44557, Thumb-1 ICE: found two small needed corrections in the ARM 
backend to fix this. Sent patch upstream.


* LP:641397/PR46888: bitfield insert optimization. Posted patch along 
with Andrew Stubbs' CSE patch upstream. The two-patch situation seemed 
to stir some discussion :)  It seems both patches were deemed okay, 
though it would be better if there was some testcase that passed through 
unhandled by Andrew's CSE patch, but processed by my combine fix later 
in the pass pipeline. Both patches queued at GCC bugzilla page, to be 
handled in the next stage1.


* LP:687406/PR46865, -save-temps creating different code. Analyzed 
problem, though slow to send fix upstream. Had some discussion on the 
list on how the fix should be like.


* PR46667, section type conflicts. Tested and sent mail to gcc-patches. 
Jan Hubicka picked it up and pinged for an approval again. Hope this get 
resolved soon.


* PR45416, ARM code regression. ARM considerations are mostly okay, main 
issue remaining is how to solve the x86 regression. The current expand 
code does a full DImode shift just to obtain a single bit, might be 
point of improvement to solve this.


* LP:685534, ftbfs with gcc-linaro 4.5 on amd64. Found to be another 
erroneous inline asm case. Fixed and updated on LP.


== This week ==
* More upstream and Linaro GCC issues.
* Start dealing with January travel.
* Think more about larger (Linaro) GCC optimization projects.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Dec.13 -- Dec.19

[Chung-Lin Tang]

== GCC related ==
* CS Issue #10201 / PR46883, unrecognizable insn ICE when compiling
Samba. Fixed this by changing the predicates of two split patterns.
Patch reviewed in CS internally and upstream, committed upstream, will
backport to SG++ and Linaro soon.

* LP:641397/PR46888: bitfield insert optimization. Andrew Pinski found a
testcase that escapes the CSE patch gets handled by combine, and also
found another bug with REG_EQUIV notes. Only looked at this minimally
last week, will really work on this later.

* LP:687406/PR46865, -save-temps creating different code. Backported and
bzr-pushed the upstream fix by Jakub Jelinek.

* PR45416, ARM code regression. Mostly can generate what I wanted by
now, under ARM and x86, although patch is still not in a submittable state.

* VFP index patch. Uncommitted GCC patch of mine from last year; added
Thumb-2 bits and corrected some things in the testcase. Committed upstream.

== This week ==
* Really get January travel stuff nailed.
* Upstream patch review is probably going to start getting
slow/suspended this week. Will probably do some study stuff on larger
projects.
* Continue to look at GCC issues.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Dec.20 -- Dec.26

[Chung-Lin Tang]

== GCC related ==
* Launchpad #693686, GCC ARM segfault ICE when building Chromium in V8.
Spent some time reproducing; this ICE seems to be in the maverick
gcc-4.5, at the vectorizer phase. As the ICE happens in
tree-vect-stmts.c:supportable_widening_operation(), I'm suspecting
(without further verification yet) this might be due to vmovn not
backported? (Linaro 4.5 does has this ported I think)

* PR44557, Thumb-1 ICE. Looking further after seeing Richard Earnshaw's
comment on my patch. It would be nice if we could upgrade the entire
secondary reload bits, looking into this.

== This week ==
* Look into more GCC issues.
* Get some backports done.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Dec.27 -- Jan.02

[Chung-Lin Tang]

== GCC issues ==
* PR44557, Thumb-1 ICE, looked at the ARM specific secondary reload
parts, as well as some general reload internals context. Concluded that
concerns on Thumb-2 about my submitted patch should be unneeded, as the
reload_in/out patterns should never be used for Thumb-2. Also looked a
bit on how we should upgrade ARM to use TARGET_SECONDARY_RELOAD.

* PR45416, ARM code regression. Started working on this again, cleaning
up patch to submit.

* Had some email discussion with Revital Eres on Swing Modulo Scheduling
(SMS) for ARM issues, mainly on how the doloop_end pattern should be
done on ARM.

* Submitted and committed an obvious small patch for a VFP testsuite case.

== This week ==
* Continue on GCC issues.
* Flying to Dallas on Sunday, prepare for trip.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Jan.3 -- Jan.9

[Chung-Lin Tang]

== Last week ==
* Some discussion about libffi variadic function support. The current
proposed design is an additional API function to prepare a new call
interface (CIF) structure with the argument number settings for each
variadic call site. This IMHO, is slightly less flexible that doing a
call-time placement style interface, but should be faster and easier to
implement.

* Collecting a few cases of ARM/Thumb-2 integration in the GCC ARM backend.

* Prepared and traveled to Dallas for the Linaro sprint.

== This week ==
* The Linaro sprint.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Bug fixes for -Os issues in GCC 4.5.x in Linaro?

[Chung-Lin Tang]

On 2011/1/25 04:22, Wolfgang Denk wrote:
> Hello,
> 
> could you please provide some comments about the state of "-Os"
> (optimising for size) in the gcc 4.5.x versions of Linaro's tool
> chain?
> 
> It appears there are a number of issues with recent versions of GCC
> that get triggered when optimising for size, for example
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
> 
> Some other projects like the Linux Foundation driven Poky (resp.
> Yocto project) capitulated and stopped using -Os, see for example
> here:
> http://thread.gmane.org/gmane.linux.embedded.poky/2311/focus=2565
> 
> 
> On the other hand, I can see that Linaro even adds improvements for
> "-Os", see for example here:
> http://thread.gmane.org/gmane.linux.linaro.toolchain/367
> 
> 
> So I wonder what the state of these problems with "-Os" is in the
> Linaro tool chain?  Have these issues been solved, and is "-Os"
> reliably working with the Linaro tool chain?

Well, a check of the ChangeLogs show that PR45052 should be fixed on the
upstream 4.5 branch, which Linaro 4.5 has updated past by now.

PR44392 is fixed on trunk, though not backported to 4.5 yet. Ramana, I
see this was fixed by you upstream, care to backport this? (maybe on
upstream gcc-4_5-branch too)

Do you have any more specific cases/PRs, or is this all that's on your
current list?

Thanks,
Chung-Lin

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Jan 24--30

[Chung-Lin Tang]

== Last week ==
* PR47246, VFP index range on Thumb-2. Submitted and committed patch
upstream.

* Pinged two upstream submissions on gcc-patches, one for PR44557 and
the other a patch for LP:689887; still awaiting approval.

== This week ==
* Chinese New Year Holiday, I'll be off until Feb.8th.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Jan 31 -- Feb 13

[Chung-Lin Tang]

== Week of Jan.31st--Feb.6th ==
* Vacation, Chinese New Year Holiday.

== Last week ==
* Monday (Feb.7th), last day of vacation.

* LP #711819, ICE in push_minipool_fix: this turned out to be a simple
case where a memory load alternative was not tagged with the minipool
range attributes. Patch sent upstream, awaiting approval.

* LP #709453, wrong code generated for NEON. Tracked this down and
mostly know how to fix this, but discussion with Ramana brought the
issue up that the entire idea of using NEON vmov.i32 for loading VFP
constants may not be good for A9, and unclear for A8. We probably should
just revert the patch from the Linaro tree for now.

* PR46002, IRA internal compiler error with -fira-algorithm=priority.
Been looking at this as a part of my background IRA studies. Have a
possible patch for this, plus found another assert fail ICE under ARM.
Will see if can post upstream this week.

== This week ==
* Continue to look at above unfinished issues, as well as other new ones.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Feb 14 -- Feb 20

[Chung-Lin Tang]

== Last week ==
* PR46178, PR46002: both upstream issues related to the priority
coloring mode of IRA. Both patches submitted, the first already approved
and committed.  Vladimir M. did mention that the priority algorithm
would be removed once his newer "cover class-less" patches goes in
during stage1. Anyways, I got more familiar with IRA during the process,
and the patches will still be applicable to 4.5/4.6.

* PR43872: incorrectly aligned VLAs under ARM. This turned out to be a
one-liner fix. Submitted upstream awaiting approval.

* Discussed on email/IRC with Revital Eres on SMS and ARM doloop pattern
issues.

* Launchpad #721021: Linaro GCC ICE under -mtune=xscale. Investigated a
bit; did not see ICE immediately, but GCC went into infinite loop (Khem
Raj, the reporter, says it runs for a while then ICEs).

* Coremark ARMv5TE vs ARMv7-A performance regression: reproduced
consistently using our own Tegra boards. Investigated and seem to have
found something, will post more detailed findings later.

== This week ==
* Coremark investigation.
* More GCC issues.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Feb 21 -- Feb 27

[Chung-Lin Tang]

== Last week ==
* Launchpad #721021 GCC ICE on ARM/XScale: identified as case of
upstream PR45177; backported and pushed to Linaro.

* Launchpad #709453/CS Issue #7122: Neon vmov 0.0 issues; some progress
on my current WIP patch, but tests showed another 3 regressions, still
on-going.

* Launchpad #711819/GCC PR47719: ICE in push_minipool_fix. Ramana
reminded that my patch, which added some pool range attributes, were
actually removed earlier by Bernd in the fix for PR43137. Discussed and
mostly concluded that we should add them back for now. Will re-submit
patch with testcase to gcc-patches this week.

* Coremark ARMv7-A regressions: still work in progress.

== This week ==
* TW Public Holiday Feb.28 (Mon).
* Ping some of my upstream patch submissions.
* Get incompleted issues done.
* Coremark regression investigation.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Feb.28 -- Mar.06

[Chung-Lin Tang]

Last week:
* Launchpad #711819 / PR47719: ARM minipool ICE. Followed up on
discussion with Bernd and Ramana. Later posted discussion results on
gcc-patches, where Richard Earnshaw took it over with a final fix.

* Coremark ARMv7/v6 regressions: mostly pinpointed the exact cases where
RTL simplification fails to optimize away ZERO_EXTEND expressions. Still
working on how to enhance it.

* TW Public Holiday on Feb.28 (Mon), was off for one day.

This week:
* Try to turn Coremark regression investigation into code form.
* Other GCC issues.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Mar.07 -- Mar.13

[Chung-Lin Tang]

== Last week ==
* Working on Coremark ARMv6 regressions. Identified a major cause being
RTL ifcvt failing on one of the crc routines, due to combine pass
failing to optimize a particular sequence, causing the if-conversion
estimates to give up on conditional executing (too many insns).   The
combine pass failed on ARMv6 and above, due to the existence of true
zero_extend insns. On ARMv5, the use of two shifts actually allowed
combine to phase reduce the shifts one by one, thus producing better
code.  On ARMv6, combine produced a (xor (and ...) ) which did not
match any insn.  Analyzed and sent a patch upstream which should work on
such XOR cases. Patch is due for upstream commit for 4.7-stage1.
(http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00609.html)

* Another situation of un-optimized uxth insns still exists;  trying
to solve this by another combine patch I am currently testing, will send
upstream later.

== This week ==
* verify the improvements the above patches should have on Coremark for
ARMv6/v7.
* Work on sending them to Linaro and SG++ branches.
* Other bug issues.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Mar.14 -- Mar.20

[Chung-Lin Tang]

== Last week ==
* CoreMark ARMv6/v7 regressions: posted another combine patch upstream,
which was quickly approved and committed. The XOR simplification one is
now approved too, but needs a little more revising of comments before
committing.

* The above two patches now bring CoreMark under -march=armv7-a to very
close of the performance of -march=armv5te. However, a regression where
uxtb+cmp cannot be combined into 'ands ... #255' still causes v7 to lose
slightly. This should be the final issue to solve...

* Launchpad #736007/GCC Bugzilla PR48183: NEON ICE in
emit-rtl.c:immed_double_const() under -g. Posted patch upstream, but
looks like more discussion is needed before we know if this is the
"right" way to do it.

* Launchpad #736661, armel FTBFS (G++ ICE in expand_expr_real_1()).
Looking at this.

* Pinged a few upstream patch submissions.

== This week ==
* Launchpad #723185/CS issue #9845 now assigned to me, start looking at
this.
* Get the XOR patch committed upstream, and the above described uxtb+cmp
issue solved.
* Work on other GCC issues.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Mar.21 -- Mar.27

[Chung-Lin Tang]

== Last week ==
* PR46934: Thumb-1 ICE, small fix in the "casesi" jump-table expand
code. Quickly approved and committed upstream.

* Enhance XOR patch for gcc/simplify-rtx.c. Updated comments and
committed upstream.

* PR48250 / CS Issue #9845 / Launchpad #723185. Unaligned DImode reload
under NEON. Submitted patch upstream, but still need to do some more
verification that older pre-ARMv5TE cases are safe. Should complete this
week.

* Working on a type of ICE seen currently on upstream trunk, a few
testcases failing under '-O3 -g'. It seems VTA related, but also might
have something to do with register elimination not fully done for
(var_location (entry_value ...)) expressions, leaving [afp+#num] memory
addresses existing in debug insns after reload. Still investigating.

* Launchpad #689887, ICE in get_arm_condition_code(). Pushed a merge
request to Linaro 4.5 for this patch. Also another LP#742961 appeared as
another case of this ICE...

* Still working on (what I think should be) the last of the CoreMark
ARMv6 regressions. The problem is to combine uxtb+cmp into ands #255.
This could be done by adding (set (cc) (compare (zero_extend...)))
patterns, implemented by ands assembly, but still looking if this can be
done (probably more elegantly) by something like CANONICALIZE_COMPARISON
(replacing compare operands) in the ARM backend.

* Launchpad #736007, ICE immed_double_const under -mfpu=neon -g. Some
discussion on gcc-patches about this, still unclear on what should be
done...

== This week ==
* Push forward on above issues.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Mar.28 -- Apr.03

[Chung-Lin Tang]

== Last week ==
* PR48250 / CS Issue #9845 / Launchpad #723185. Unaligned DImode reload
under NEON. Went back and forth with Richard Earnshaw on gcc-patches for
most of the week. The issues should finally be clear, and I think it
would be better to modify the significant parts of
arm_legitimize_reload_address() to do the right thing rather than just
fixing the bug. I have a new patch done over the weekend, though it
still shows a few regressions after some testing. I hope this gets done
by this week...

* PR48325 / Launchpad #744754, another NEON ICE in postreload. This
appears to be the IA/DB modes for VLDM/VSTM for NEON struct modes were
not enabled. This ICE actually does not happen currently on upstream
trunk, but sent patch anyways. Pending review.

* Spent some time on Launchpad #736661 (C++ ICE in expr.c), and looked
at upstream testsuite regressions of gcc.dg/pr17957.c and
gcc.dg/torture/pr47975.c under -mfpu=neon (ICE on OImode const0_rtx
assignment).

* Call with Ramana on ARM optimization work.

== This week ==
* Get PR48250/Launchpad #723185 nailed.
* Other pending GCC issues.
* TW Public Holiday, Mon. and Tue. (Apr.4-5)

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Apr.04 -- Apr.10

[Chung-Lin Tang]

== Last week ==
* Mon/Tue (Apr.4--5): Tomb-sweeping Day, public holiday.

* PR48250 / CS Issue #9845 / Launchpad #723185. Unaligned DImode reload
under NEON. Worked on new patch, submitted to gcc-patches after testing
on Friday. Awaiting review.

== This week ==
* CoreMark ARMv6/v7 regressions: working on new combine patch.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

CoreMark Status

[Chung-Lin Tang]

Hi, I've just pushed a merge of the current upstream patches for
resolving the CoreMark regressions.
(https://code.launchpad.net/~cltang/gcc-linaro/coremark-part1)

To give a quick benchmark of the current status, testing Linaro 4.5
before/after the merge of those two patches:

Optimization options used were just plain '-O2 -mtune=cortex-a9', tested
on one of our Pandaboards running Maverick; all numbers are
Iterations/Sec averaged from 3 runs.

r99492   r9942+patches  improve %
-march=armv5te  2786.87  2848.12 2.20 %
-march=armv7-a  2474.50  2775.9212.18 %
-march=armv7-a -mthumb  2297.86  2356.59 2.56 %

I'll have to re-test to be sure, but the numbers/improvements obtained
using upstream trunk should not be too far off, at least the ARM mode ones.

As we discussed in prior meetings, there's still one point of regression
identified that's in solving, which hopefully will finally bring the
ARMv7-A numbers above ARMv5TE.

Chung-Lin

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Apr.11 -- 17

[Chung-Lin Tang]

== Last week ==
* CoreMark regressions: pushed a merge of my two upstream patches to
Linaro 4.5, some current numbers are here:
http://lists.linaro.org/pipermail/linaro-toolchain/2011-April/001087.html.

* Continued working on another combine patch for improving CoreMark,
hopefully ready to submit this week.

* Committed fix for PR48325 (NEON POST_INC/PRE_DEC load/stores for
struct modes) upstream.

* Committed fix for PR48250 / Launchpad #723185 upstream.

* Launchpad #689887, ICE in get_arm_condition_code(). My prior patch was
tested to cause native bootstrap failure on Linaro 4.5, though retesting
on upstream trunk worked fine. Still investigating.

* Booked travel for Linaro-Budapest event.

== This week ==
* Current combine patch.
* Some unresolved patches, like PR46888.
* Launchpad #689887, hope to figure this out.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Apr.18 -- Apr.24

[Chung-Lin Tang]

== Last week ==
* PR48250, rehaul arm_legitimize_reload_address(). Richard Sandiford
caught a bug of mine where I overlooked the valid index range of NEON
quad-word load/stores. Quickly whipped up a fix, soon approved and
committed upstream.

* LP #744754, ICE in NEON struct-mode auto-inc-dec MEMs. Pushed upstream
patch for a merge to Linaro 4.5.

* PR46888, bit-field insert optimization patch. Resumed investigating,
mailed Andrew Pinski for more information on that REG_EQUAL note issue
he mentioned on gcc-patches; can't quite reproduce it myself.

* CoreMark ARMv6/v7 regressions: posted a patch set to gcc-patches.
Still waiting review.

* Reported to Bernd and AndrewS on an issue (LP #748138) which seems to
be related to the shrink-wrap patch. This ICE does not seem to be
avoided by doing -fno-shrink-wrap.

* A few tasks related to Linaro-Budapest event travel.

== This week ==
* Do the merge of the new combine patches to Linaro, and test.
* LP #689887 is still in progress.
* Hope to experiment with a few more optimization ideas.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: "BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

[Chung-Lin Tang]

I think I've seen this assert fail myself before, a long time ago...

While this is probably a BFD bug of some sort, do you happen to have
assembly code source files among the .o objects? Could you try adding
".eabi_attribute 27, 3" to the asm files and see if it links?


On 2011/4/28 06:06 PM, Barry Song wrote:
> Hi Andrew,
> 
> 2011/4/28 Andrew Stubbs  >:
>> On 28/04/11 09:59, Barry Song wrote:
>>>
>>> my other two mails explain what happened, in fact link input file is
>>> simple:
>>
>> There must be more than one input file to the link, otherwise I
> believe you
>> wouldn't see this problem. We need to find out what the other ones are.
>>
>>> ASSERT found just because we are using -nostdlib flag since we don't
>>> call any library. This flag changed out_attr[Tag_FP_arch] to 0, which
>>> is generically 4 for linaro new toolchain by watching a normal
>>> compile/link process.
>>
>> The -nostdlib flag only changes the list of libraries that will be linked.
>> It shouldn't change any attributes directly.
>>
>> Here's how a link should work, if I understand it correctly:
>>
>> 1. The linker creates an empty output file (conceptually). This file will
>> have all attributes set to default settings (i.e. zero).
>>
>> 2. Each input file is then merged into the output file in turn. New
> sections
>> are added, or existing ones appended to, and the symbol tables and
> such are
>> built incrementally. At each step, the attributes are merged from the
> input
>> file to the output file.
>>
>> For the first input file, the attribute merge is basically just a
> copy. Both
>> Tag_FP_arch and Tag_ABI_HardFP_use should be zero in the (empty) output
>> file, so we should not be able to hit this condition.
>>
>> For the second input file, the attribute merge is more complicated.
> For each
>> attribute the result will be either be the union, or the intersection
> of the
>> two attributes, or else it will throw an error.
>>
>> So, it should be that this can't happen, but clearly it does, so something
>> is broken, but I can't tell what without reproducing it, or at least
> seeing
>> what inputs you're dealing with.
>>
>> So, please help me figure out what the full set of input files are and
> I see
>> if I can work from there.
> 
> Thanks very much. i can't send you all source codes, but i can send you
> the related binaries causing ASSERT.  All link log is as below. Note the
> red part is where ASSERT happen. Input is dir_soc.o, output is a elf
> file. It is the first time the elf file begin to born.
> 
> !-
> out_attr[i].i:2, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2,
> in_attr[Tag_ABI_HardFP_use].i:3
> ibfd:
> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/chip/nand_controller/soc_nand/dir_soc_nand.o
> obfd:
> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/chip/nand_controller/dir_nand_controller.o
> 
> -!
> 
> make[6]: Leaving directory
> `/home/vmuser/development/svn/Current/Linux/Main/firmware/nanddisk/src/soc/prima2/chip/nand_controller'
> make[6]: Entering directory
> `/home/vmuser/development/svn/Current/Linux/Main/firmware/nanddisk/src/soc/prima2/chip/zone_mgr'
> make[6]: Leaving directory
> `/home/vmuser/development/svn/Current/Linux/Main/firmware/nanddisk/src/soc/prima2/chip/zone_mgr'
> 
> 
> !-
> out_attr[i].i:2, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2,
> in_attr[Tag_ABI_HardFP_use].i:3
> ibfd:
> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/chip/nand_controller/dir_nand_controller.o
> obfd:
> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/chip/dir_chip.o
> 
> -!
> 
> 
> 
> !-
> out_attr[i].i:2, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2,
> in_attr[Tag_ABI_HardFP_use].i:3
> ibfd:
> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/chip/zone_mgr/dir_zone_mgr.o
> obfd:
> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/chip/dir_chip.o
> 
> -!
> 
> make[5]: Leaving directory
> `/home/vmuser/development/svn/Current/Linux/Main/firmware/nanddisk/src/soc/prima2/chip'
> make[5]: Entering directory
> `/home/vmuser/development/svn/Current/Linux/Main/firmware/nanddisk/src/soc/prima2/prima2cb'
> 
> 
> !-
> out_attr[i].i:2, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2,
> in_attr[Tag_ABI_HardFP_use].i:3
> ibfd:
> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/prima2cb/nand/dir_nand.o
> obfd:
> /home/vmuser/development/svn/Current/Li

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Chung-Lin Tang]

On 2011/4/27 07:10 PM, Andrew Stubbs wrote:
> On 27/04/11 10:57, Michael Hope wrote:
>> Hi Andrew.  I uploaded the wrong preprocessed source to the GCC
>> bugzilla entry.  It included the __attribute__((noinline)) workaround
>> which hides the problem.
> 
> OK, I've now reproduced the problem and reduced the test case.
> 
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
> 
> Andrew

I think I've found the source of this, to summarize: during RTL expand
(yes during *expand*), .global __aeabi_* directives are added to the asm
output when seeing use of the libcalls. Later the calls get optimized
out in some way, leaving the unused .global symbols...

I would think that, under an EABI toolchain environment, all the AAPCS
defined __aeabi_* runtime functions should always be available (e.g.
libgcc)  Thus we should be able to skip adding these .global __aeabi_*
directives completely? Ramana?

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Apr.25 -- May.01

[Chung-Lin Tang]

== Last week ==
* CoreMark ARMv6/v7 regression patch set for combine: exchanged some
comments on upstream list with Jeff Law. Started some testing on
powerpc64, hit some issues with native bootstrap that I
don't think I completely overcome, but at least completed a 32-bit
bootstrap successfully. Unfortunately hit two regressions after running
tests, will work on fixing this week, and update the upstream submission.

* PR48783: unused reference to __aeabi_uldivmod. Investigated and found
this to be a case where during RTL expand, .global directives for the
__aeabi_* runtime symbols are directly inserted after some div optab
didn't have the insns, and a libfunc was to be used. However later
optimizations that removed the divisions left the .global symbols
dangling with no uses. We could probably just avoid adding the
directives completely for the EABI functions.

* PR42017: ARM LR register not used in leaf functions. This is a case
where DF takes EPILOGUE_USES as part of the initial live registers at
end of functionn, and liveness computations never get to kill it, since
there are no function calls to clobber in a leaf function. Submitted a
patch to remove LR from EPILOGUE_USES before reload, awaiting review.

* LP #689887: investigated more; not much progress, but found that the
bootstrap fail happens only under --with-mode=thumb (Thumb-2). Under ARM
mode the native bootstrap succeeds.

== This week ==
* Try to fix the problems with the CoreMark combine patches.
* Investigate more optimizations/bugs.
* Prepare for travel to Budapest on Saturday.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] May.02 -- May.08

[Chung-Lin Tang]

== Last week ==
* Launchpad #748138: "ICE in redirect_jump, at jump.c:1443". Related to
shrink-wrap, discussed a bit with Bernd off-list. Sent fix today (Mon.)
to gnu-internal; will need to merge to Linaro.

* CoreMark combine canonicalize compares patch set: bootstrapped and
tested with clean results on powerpc, added comments and updated
upstream submission. Machine independent parts okayed by Jeff Law, now
committed upstream. ARM parts still pending review.

* Compiled back-list of upstream patches, and sent to patc...@linaro.org

* Traveled to Budapest, Hungary for Linaro Developer Summit on Saturday.

== This week ==
* Linaro Developer Summit at Budapest all week.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] May.09 -- May.15

[Chung-Lin Tang]

== Last week ==
* At Linaro@UDS; I am still typing this in Budapest. Sparingly did some
work between sessions.

* PR42017, ARM LR register not being used. Discussed the patch with
Richard Sandiford at LDS. Re-tested a bit and about to resend a revised
patch according to his suggestion.

* LP:748138, redirect_jump() ICE. Committed patch to CS stable and
trunk. Submitted merge request to Linaro 4.5 branch.

* LP:689887. Got some suggestions from Revital on how to debug the
bootstrap failure caused by my patch, will look into applying it.

== This week ==
* Taking Monday off, I'll be flying back to Taiwan on Tuesday.
* Continue with issues after getting home.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] May.16 -- May.22

[Chung-Lin Tang]

== Last week ==
* Took Monday off, flew back to Taiwan on Tues., got home Wed. night.

* LP:689887, ICE in get_arm_condition_code(). Finally have some new
progress on this. Found my code was rejecting DImode comparisons,
causing uses of __aeabi_lcmp, etc. in expanded RTL. While this still
does not fully explain a bootstrap fail, it may be related, and it's
good I found this here rather then scratch heads on performance
regressions later... :)

* LP:771903: invalid ubfx asm produced by GCC. Mostly got down to the
bottom of this. This bug is rather well hidden, first avoided due to
some inlining heuristic changes after FSF 4.5 was branched (hence 4.6
and trunk doesn't show on the testcase), then hidden again later by
-ftree-bit-ccp. Was able to reproduce on mainline trunk after some
changes to testcase and options. Will send patch later.

* Talked with Ramana on IRC and mail about the '+' constraint modifiers
in the VFP fmul/fdiv patterns. Mostly concluded that these are typos,
and should be fixed.

== This week ==
* Continue with issues.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] May.23 -- May.29

[Chung-Lin Tang]

== Last week ==
* Investigated the CoreMark numbers posted by Michael Hope, mainly the
oddities of a significant Linaro 4.6 regression versus FSF 4.6. Later
verified to be a false alarm.

* Pushed a merge of some of my upstream CoreMark patches to Linaro 4.6.

* Did archeology for PR42017. Traced some history of the ARM prologue
from 2000 to 2007 (DF branch), posted upstream. Hope this clarification
gets my patch an approval soon.

* Tried the above PR42017 patch (which is supposed to release the use of
LR as a general register in leaf functions) on CoreMark, using Linaro
4.6, and was surprised to find that despite many reductions in spill
code and epilogue (now more often directly return by ldmfd), the
generated code still regresses in performance (!).

* Continuing above, suspecting something from experience (cough) added
-falign-functions=8 to the CoreMark compile options. Finally produced a
small improvement, while causing a regression for the
without-PR42017-patch case (victory?).

* Worked on PR48808, PR48792 over the weekend, which are cases where
paradoxical subregs caused ICE in reload. Posted an ARM backend patch
upstream, though now mostly taken over by Richard Sandiford :)

== This week ==
* Some other PRs, ideas, still work in progress.
* Started using the porter boards, will try to get LP:689887 over with
this week.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: How to fail an ARMv5T u-boot build when libgcc is ARMv7T2?

[Chung-Lin Tang]

On 2011/11/10 06:04 PM, Loïc Minier wrote:
> When building u-boot for an ARMv5T platform (versatileqemu_config), the
>  Ubuntu-packaged Linaro cross-toolchain isn't suitable because it
>  only offers an ARMv7T2 libgcc.  But I'd like the build to fail when
>  that happens rather than silently generating an u-boot.bin which will
>  trigger a SIGILL when it hits the first non-ARMv5T instruction.
> 
>  I heard that gcc/ld are supposed to check this, but I'm not sure how
>  it's supposed to work; perhaps the way u-boot does its final link
>  prevents this from working properly?
> 
>  I tried building u-boot as follows:
> make O=obj-broken \
> CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm \
> OPTFLAGS="-marm -march=armv5te" \
> versatileqemu_config
> 
> make O=obj-broken \
> CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm \
> OPTFLAGS="-marm -march=armv5te" \
> -j2

I'd assume the Ubuntu-packaged toolchain probably doesn't have a ARMv5
multilib? You could either expand the toolchain configuration and
rebuild, or more simply, use a CodeSourcery toolchain. Our default
multilib is ARMv5TE.

If you truly mean v5T and not v5TE (I can't really tell from the
inconsistency between your description and the listed options above),
then you should use -march=armv4t, we ship v4T libraries too.

Chung-Lin

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Triage of #914703

[Chung-Lin Tang]

On 2012/1/17 07:51 PM, Asa Sandahl wrote:
> Hi Michael,
> 
> So, I gave my best shot at:
> 
> https://bugs.launchpad.net/gcc-linaro/+bug/914703
> 
> 
> Kind of similar to the one in your walk-through, but I couldn't actually
> reproduce on the version reported.
> 
> Could you please check if this looks OK?
> 
> 
> Regards
> Åsa

This looks like #736007.

Chung-Lin

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain