- linaro-toolchain - lists.linaro.org

by Ira Rosen

Hi, I continued to work on vect_interleave and vect_extract implementation on NEON: * debugged the compiler to find out what's the problem with neon_vzip/vuzp<mode>_internal * fixed it following Uli's advice * checked how neon_vzip/vuzp<mode>_internal work for intrinsics by writing tests * fixed the patch according to Uli's comments * now fully testing the patch Thanks, Ira

14 years, 10 months

1
0
0 0

Help with define_insn

by Ira Rosen

Hi, I am trying to implement interleave_high/low and extract_even/odd using vzip and vuzp instructions. I am attaching a patch that attempts to do that. It uses already existing neon_vzip<mode>_internal. The problem with it is that it doesn't express the fact that the two outputs of vzip depend on both inputs, which causes wrong code generation in CSE: for (a,b)<- vzip (c,d) and (e,f) <- vzip (g,d) CSE decides that b==f, since on RTL level b and f depend only on d. Here is neon_vzip<mode>_internal: (define_insn "neon_vzip<mode>_internal" [(set (match_operand:VDQW 0 "s_register_operand" "=w") (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")] UNSPEC_VZIP1)) (set (match_operand:VDQW 2 "s_register_operand" "=w") (unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")] UNSPEC_VZIP2))] "TARGET_NEON" "vzip.<V_sz_elem>\t%<V_reg>0, %<V_reg>2" [(set (attr "neon_type") (if_then_else (ne (symbol_ref "<Is_d_reg>") (const_int 0)) (const_string "neon_bp_simple") (const_string "neon_bp_3cycle")))] ) Is there a way to properly mark the dependence? Thanks, Ira

14 years, 10 months

4
8
0 0

qemu-linaro prerelease available

by Peter Maydell

Hi; this is a note to say that we have now produced a prerelease tarball of qemu-linaro. (The first formal qemu-linaro release will happen in sync with other toolchain group releases on 8th Feb.) This prerelease is primarily to pipeclean the release process and to allow work to start on producing Ubuntu and Linaro packages; however it does include a number of useful bugfixes which are required if you want to be able to boot a recent Linaro snapshot on the beagle model. So the enthusiastic might like to build it from source and give it a spin. Like the Linaro kernel trees, the qemu-linaro tree aims to only include patches we are confident will go upstream; at the moment this means the OMAP3 support and ARM correctness fixes from the qemu-meego tree, based on the qemu upstream trunk. You can download the source tarball from: https://launchpad.net/qemu-linaro/+milestone/2011.02 -- Peter Maydell

14 years, 10 months

1
1
0 0

IT block semantic question

by David Gilbert

Hi, What do people understand to be the expected semantics of IT blocks in the cases below, of which there has been some confusion in relation to a recent Qt issue. The code in question had a sequence something like: comparison IT... EQ blahEQ TEQ BEQ The important bits here are that we have an IT EQ block and two special cases: 1) There is a TEQ in the IT block - are all comparisons in the block allowed and do their effects immediately take effect? As far as I can tell this is allowed and any flag changes are used straight away; 2) There is a BEQ at the end of the IT block, as far as I can tell, as long as the destination of the BEQ is close it shouldn't make any difference if the BEQ is included in the IT block or not. Does that match everyone elses understanding? Dave

14 years, 10 months

2
3
0 0

Generating ancilliary sections with gas

by Dave Martin

Hi all, With gas, does anyone know of a way to create a section whose name is based on that of the current section? The specific requirement is to be able to define a generic macro like the example "fixup" below, whose purpose is to record ancilliary data related to some other section. To illustrate: .macro fixup 100\@ : .pushsection fixup<current section name>, "a" .long 100\@b .popsection .endm .text ... fixup .long sym1 ... .section .other, "ax" ... fixup .long sym2 The linux kernel uses a technique just like this for patching SMP kernels at bootup to work on uniprocessor platforms (when CONFIG_SMP_ON_UP is enabled), resulting in code looking something like this: void exit __attribute__ (( __section__ (".text.exit") )) { ... asm( ... FIXUP("something") ... ); } Note that the inline asm may actually come out of a generic header file rather than being explitly written for this invocation. So it may have to be truly generic. Is far as I have been able to determine, it's not possible to generate sections named based on the current section. In practice, the kernel puts all the fixups into a single section. The downside of this is that when sections are selectively discarded at link time (which in general may happen -- for example, Linux discards the "module exit" code for drivers which are built into the kernel and therefore never exit) there is no way to selectively discard the related fixup entries. Currently the only solution is to include all the module exit code in the image and discard it at run-time when the kernel boots. This is obviously wasteful. Attempting to discard that code at like time results in a link error, since fixups refer to the removed sections. Of course, the "fixup" macro could be given an extra parameter to name the containing section, but the macro can then no longer be called in a generic way: all the calls to that macro must be manually (and buggily) maintained to ensure that the referenced section name is correct, some object post-processing must be done before linking, and/or a tool must be created to implement the missing assembler functionality. Unfortunately, such solutions are likely to be too fragile or complex to make it upstream. It's interesting to note that the same problem will apply for any section containing ancilliary data for another section. In particular, it looks like either the ABI or the assembler has had to grow a special-case workaround for this in order to support exception unwind information sections generated by .fnstart ... .fnend in a sane way: the unwind information sections get called .ARM.ex{idx,tab} for .text, and .ARM.ex{idx,tab}<section> for any other section. As a consequence, link-time discarding can handle this information properly, but IMHO this is a bit of a cheat and admits the general need to create sections with names based transparently on those of other sections, without satisfying that need. .popsection is also an example of such a cheat: most other aspects of assmbler state still cannot be saved and restored. In general, it would be useful if gas supported some general reflective abilities: i.e., the ability to query the current assembler state (section, subsection, active instruction set, active macro mode, etc.) and/or the ability to wrap or hook existing pseudo-ops. For example, the above problem would almost certainly solvable using assembler macros (albeit painfully) if wrapper macros could be defined for the section manipulation directives (section, .text, .data, .bss, .pushsection, .popsection, .previous). However, supporting some magic macro parameters reflecting the assembler state would be a lot simpler. As an example of the kind of behaviour I think would be useful, the macro argument qualifier could be extended to allow macros to query the assembler state in a backwards-compatible way; something like: .macro fixup base_section:gas_current_section_name, old_altmacro:gas_macro_mode .altmacro LOCAL fixup_location fixup_location: .pushsection \base_section\().fixup .long 100\@b .popsection \old_altmacro .endm Existing assembler code will continue to work just fine with this approach. Note how this also enables a local label to be generated hygenically, by making it possible to save and restore the macro mode. Otherwise, .altmacro (and hence LOCAL) is hard to use safely, since the initial macro mode is unknown and can't be restored. Any thoughts / comments? Cheers. ---Dave

14 years, 10 months

2
3
0 0

[GCC 5.5 - Help on ERROR] Compilation fails with mfpu=neon

by ShankarGanesh Kandasamy

Hi, Following compilation fails with -O3 -mfpu=neon,(but successful on -O2, -mfpu=neon) for Cortex-A5. Could you please help me out to resolve this error ? ubuntu@tegra:~/$ gcc-4.5 -v -c -o utility.o -DLINUX -DUNIX -DHAS_LONGLONG -DLITTLE_ENDIAN_ARCH -DSPEC_CPU2000 -O3 -mcpu=cortex-a5 -marm -mfpu=neon -mfloat-abi=softfp utility.c Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.1/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.1-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.5.1 (Ubuntu/Linaro 4.5.1-7ubuntu2) COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'utility.o' '-DLINUX' '-DUNIX' '-DHAS_LONGLONG' '-DLITTLE_ENDIAN_ARCH' '-DSPEC_CPU2000' '-O3' '-mcpu=cortex-a5' '-marm' '-mfpu=neon' '-mfloat-abi=softfp' /usr/lib/gcc/arm-linux-gnueabi/4.5.1/cc1 -quiet -v -DLINUX -DUNIX -DHAS_LONGLONG -DLITTLE_ENDIAN_ARCH -DSPEC_CPU2000 utility.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase utility.c -mcpu=cortex-a5 -marm -mfpu=neon -mfloat-abi=softfp -auxbase-strip utility.o -O3 -version -fstack-protector -o /tmp/ccaZnpsw.s GNU C (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (arm-linux-gnueabi) compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64482 ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabi" ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/include" ignoring nonexistent directory "/usr/include/arm-linux-gnueabi" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/arm-linux-gnueabi/4.5.1/include /usr/lib/gcc/arm-linux-gnueabi/4.5.1/include-fixed /usr/include End of search list. GNU C (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (arm-linux-gnueabi) compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64482 Compiler executable checksum: 52c4962735600b49ca41dc70631edd04 COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'utility.o' '-DLINUX' '-DUNIX' '-DHAS_LONGLONG' '-DLITTLE_ENDIAN_ARCH' '-DSPEC_CPU2000' '-O3' '-mcpu=cortex-a5' '-marm' '-mfpu=neon' '-mfloat-abi=softfp' as -mcpu=cortex-a5 -mfloat-abi=softfp -mfpu=neon -meabi=5 -o utility.o /tmp/ccaZnpsw.s /tmp/ccaZnpsw.s: Assembler messages: /tmp/ccaZnpsw.s:460: Error: VFP/Neon double precision register expected -- `vmovl.s16 q5,s20' /tmp/ccaZnpsw.s:531: Error: VFP/Neon double precision register expected -- `vmovl.s16 q9,s14' /tmp/ccaZnpsw.s:537: Error: VFP/Neon double precision register expected -- `vmovl.s16 q7,s28' /tmp/ccaZnpsw.s:542: Error: VFP/Neon double precision register expected -- `vmovl.s16 q13,s12' /tmp/ccaZnpsw.s:543: Error: VFP/Neon double precision register expected -- `vmovl.s16 q14,s10' /tmp/ccaZnpsw.s:544: Error: VFP/Neon double precision register expected -- `vmovl.s16 q3,s8' /tmp/ccaZnpsw.s:546: Error: VFP/Neon double precision register expected -- `vmovl.s16 q2,s6' /tmp/ccaZnpsw.s:549: Error: VFP/Neon double precision register expected -- `vmovl.s16 q1,s4' /tmp/ccaZnpsw.s:550: Error: VFP/Neon double precision register expected -- `vmovl.s16 q0,s0' /tmp/ccaZnpsw.s:551: Error: VFP/Neon double precision register expected -- `vmovl.s16 q4,s16' Regards, Shankar -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

14 years, 10 months

1
0
0 0

[ACTIVITY] Jan 24--30

by 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.

14 years, 10 months

1
0
0 0

GCC 4.6 Upgrade Plan

by Andrew Stubbs

Hi All, The GCC 4.6 Upgrade plan can be found here: https://wiki.linaro.org/WorkingGroups/ToolChain/GCCUpgradePlan The plan describes how we should commit "upstream" patches while the FSF trunk is closed, and what we plan to use 4.6 for. Andrew

14 years, 10 months

1
0
0 0

[ACTIVITY] 24th -28th January 2011

by Andrew Stubbs

Created a Google docs spreadsheet to help visualise the benchmark results. The graphs are not very informative yet - too many lines and too much noise. I'm going to have to revisit them. Continued trying to build Android. The toolchains build fine, but Android itself complains about -Werror, and there are a few other real errors too. Considering I was told it built fine with GCC 4.6 and all I needed to do was tweak 4.5 to match, I'm not terribly impressed. I'm sinking too much time into fixing up Android, and I haven't even got to looking at the compiler trouble. Alexander Sack has said he will try to get me to a more appropriate starting place (I think), so I'll see what happens there. Discussed my maddhidi4 patch with Richard E (wearing his GCC ARM maintainer hat). He's not convinced that my change won't make something else produce worse code. I can't prove that it won't either, so I'm going to have to revisit it. Wrote up the GCC 4.6 branch policy and upgrade plan.

14 years, 10 months

1
0
0 0

New phone number for today's call

by Michael Hope

Just a reminder that the dial-in numbers for today's and all future calls has changed. See: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings for the new list. I'll hang out on IRC just before the meeting to help the lost... -- Michael

14 years, 10 months

1
0
0 0

[ACTIVITY] report week 04

by Peter Maydell

RAG: Red: Amber: Green: qemu-linaro RC0 prerelease uploaded Current Milestones: | Planned | Estimate | Actual | first qemu-linaro release | 2011-01-11 | 2011-01-11 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | handed off | * maintain-beagle-models: + went through diffs between qemu-linaro and qemu-meego to confirm we hadn't dropped any patches by mistake + tested qemu-linaro tree on ubuntu netbook image: boots OK + investigated and fixed qemu bugs caused by new x-loader https://bugs.launchpad.net/qemu-linaro/+bug/704484 and new u-boot: https://bugs.launchpad.net/qemu-linaro/+bug/703094 + made merge requests to meego for a CRIS compile failure and the x-loader bugfix http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/4 http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/5 + Went through the process of doing a qemu-linaro release with a "RC0" prerelease as a pipecleaning exercise and to provide a tarball to slangasek for doing packaging. Download: https://launchpad.net/qemu-linaro/+milestone/2011.02 Release process writeup: https://wiki.linaro.org/WorkingGroups/ToolChain/QemuReleaseProcess * merge-correctness-fixes + the usual upstream mailing list monitoring and code review + tested and sent meego VQ(R)DMULH.s16 fix upstream: http://patchwork.ozlabs.org/patch/80725/ + working on a patch to fix decoding of the preload and hint space Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: 17/18 March: QEMU Users Forum, Grenoble Holiday: 22 Apr - 2 May

14 years, 10 months

1
1
0 0

[ACTIVITY] 2011-01-28

by David Gilbert

SPEC Tried to track down what was going on with lbm; it doesn't seem to be repeatable on canis1; I'd previously seen it fail at O1 and work at O0 and tried to chop down the flags between the two; but after adding all the flags back in on top of -O0 it still worked and then I tried -O1 again and it worked. Going to try on another machine, but it might be uninitialised data somewhere. Panda Our panda arrived; it's now happily nestling near our Beagles and running the 0126 headless snapshot (with 0127 hwpack). It seems fine except for rather slow USB and SD IO. Tip: Panda's do absolutely nothing (no LEDs, no serial console activity) unless you put an SD card in with the firmware on. Libffi Wrote the changes for armhf. Tested on arm, armhf, i386, ppc and s390x - all happy. (Not too unsuspectingly variadic calls just work on everything other than armhf without the api change) Mailed Python CType list asking how much of a pain the API change will be and any hints on what might be affected. Awaiting sign off for submission of code. Optimised library routines Looked at benchmarking 'git'; I'd seen previous discussions where it had been pointed out that it spends a lot of time in library routines; and indeed it does spend useful amounts in memchr, memcpy and friends on a simple git diff v2.6.36 v.2.6.37 > /dev/null of the current kernel tree produces a useful ~25second run. One interesting observation is that the variation in the times reported by 'time' - i.e. user, system and real, the variation in user+system is much less than either user or system individually and is quite stable (within ~0.7% over 10 runs). I've just tried preloading my memchr routine in and it does get a consistent 1-1.2% improvement which does look above the nice. Also asked on libc-help list for suggestions as to other benchmarks people actually trust to reflect useful performance increases in core routines as opposed to totally artificial ones. Dave

14 years, 10 months

1
0
0 0

[ACTIVITY] Jan 24 - Jan 28

by Ulrich Weigand

== GCC == * Determined root cause of #Bug 598462 (corrupted profile info with -O[23] -fprofile-use), identified work-around (using -fprofile-correction), and verified on GCC 4.5 and 4.6 == GDB == * Worked on re-implementation of fix for #615978 (Failure to software single-step into signal handler) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 10 months

1
0
0 0

[Activity] Jan 24-28

by Ramana Radhakrishnan

== GCC == * Internal ARM tasks that kept me busy for some time this week. * Reworked the divmodsi4 patch based on comments. Still some test failures that need to be investigated. * Started working on the performance improvement plan for GCC 4.5. * Number of patch reviews upstream. * Looking at A9 memset issue. . * Got an internal bug report about the 4.4 tools from someone using it which had to do with a missing backport. This is now lp:709329. Backported and testing. * Backported a missing upstream patch into GCC 4.5 for bswap patterns. * Wrote up on how to cross-test with qemu and updated that on the Linaro wiki. Comments are welcome. Plans: * Find out the default number of iterations needed for steady state with EEMBC. * Finish testing fix for lp:709329 and get that committed. * Finish off divmodsi4 patch and get it's testing completed and finished. * Submit backport for bswapsi at Os fix (PR44392) for gcc-linaro * Finish the plan for GCC performance improvements based on what we discussed at the sprint. * Away 2-1/2 days next week for an internal engineering conference.

14 years, 10 months

1
0
0 0

[ACTIVITY] Status 2011-01-28

by Richard Sandiford

This week ========= - On other IBM duties until today. Now finished! - Looked at the neon failures that Peter reported. I'm testing patches for the ICE and the "must be a constant" error now. - In the background, I've been trying to pin down the chromium build failure. I can only reproduce it when running under dpkg-buildpackage: if I run the link line manually, it works. This is reminiscent of a problem that Dave saw elsewhere: the linker segfaulted only when run through the normal build system. Next week ========= - Bernd Schmidt has committed our combined patch for #695302. Will backport to our sources. - Submit the neon fixes above. - More on STT_GNU_IFUNC. There are some more tests I want to write. Richard

14 years, 10 months

1
0
0 0

neon intrinsics test cases from ST

by Peter Maydell

Some news from the qemu mailing list that I think might be of interest to gcc folks here: Christophe Lyon from ST has kindly released a large set of test cases of Neon intrinsics: http://gitorious.org/arm-neon-tests/arm-neon-tests (the tests themselves are more aimed at testing qemu, so they just produce output to be compared against a reference generated from running on hardware). However they don't currently compile with gcc (but are ok with armcc). From the README: # The tests currently fail to build with GCC/ARM: # - no support for Neon_Overflow/fpsrc register # - ICE when compiling ref_vldX.c, ref_vldX_lane.c, ref_vstX_lane.c # - fails to compile vst1_lane.c # - missing include files: dspfns.h, armdsp.h Maybe it's worth somebody having a look at this, at least enough to find out whether the ICEs are things we already know about or have perhaps already fixed in linaro gcc? thanks -- PMM

14 years, 10 months

5
4
0 0

[ACTIVITY] January 23-27

by Ira Rosen

Hi, I am working on implementation of interleave_high/low and extract_even/odd for NEON. The pairs of high/low (even/odd) are "magically" united into single vzip (vuzp) instruction in the back end, so there is no need in special support from the tree level. There are still some test failures that I need to solve. Ira

14 years, 10 months

2
2
0 0

Cross testing using qemu.

by Ramana Radhakrishnan

Hi, I've written up a wiki page finally on the cross-testing with qemu here. It's taken me slightly longer than expected as I was playing around with moin-moin syntax. These are based on qemu-0.13.0 which is what I tried when I wrote this up for some testing of a patch that I was playing with. https://wiki.linaro.org/WorkingGroups/ToolChain/CrossTestingQemu Comments are welcome . Ramana

14 years, 10 months

2
2
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, * I looked into the perf utility with regard to ARMv7 and raw event support * https://wiki.linaro.org/KenWerner/Sandbox/perf * testsuite fixes for the OpenCL GDB * started to setup the pandaboard (currently the headless snapshot hangs shortly after I got the bash prompt - I'm not sure what's going on here) * On Friday I'll attend a class. Regards Ken

14 years, 10 months

1
0
0 0

[ACTIVITY] January 23-27

by Revital1 Eres

Hello, * Submitted to mainline the patch to model Doloop for ARM (http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) . The ARM back-end part was reviews by Richard Earnshaw. * Looking into EEMBC/DENbench for opportunities applying Modulo-Scheduling. Based on partial profiling information there are SMSed hot loops. My next step is to generate complete profiling information (including gcov info) and execute the benchmarks on ARM machine. Thanks, Revital

14 years, 10 months

1
0
0 0

Re: Neon Support in kernel

by Dave Martin

Hi Vijay, On Sat, Jan 22, 2011 at 9:59 AM, Vijay Kilari <vijay.kilari(a)gmail.com> wrote: > Hello Dave, > > Thanks for this info. > > I have few more queries after looking at the results of memset on A9 & A8. > I agree that externel bus speed matters in comparision across platforms. > > 1) Why memset is performance is good on A8 than A9?. any justification? I've CC'd the linaro-toolchain list who have been working on this topic and may be able to provide you with more information. Cheers ---Dave

14 years, 10 months

3
2
0 0

2011.01 release failure writeup

by Michael Hope

Hi there. I've had a think and done a write-up on the causes behind the 2011.01 release failure and what should be changed. See: https://wiki.linaro.org/WorkingGroups/ToolChain/Incidents/2011.01-X86_64 The changes involve being more explicit in the release process document and changing the continuous build to give earlier warning. Comments are appreciated. -- Michael

14 years, 10 months

1
0
0 0

Testing a GCC patch for ARM

by Revital1 Eres

Hello, I have a patch for ARM that I want to test and I'm not sure what's the procedure of testing in Linaro nor to where it should be committed. (GCC trunk? it's currently under bug fixes mode only). I appreciate help with that. Thanks, Revital

14 years, 10 months

2
3
0 0

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

by Wolfgang Denk

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? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de The optimum committee has no members. - Norman Augustine

14 years, 10 months

4
3
0 0

toolchain calls moving to new call number?

by Peter Maydell

I assume we're moving the toolchain calls over to the new confcall numbers -- but just to check, are we doing so for this Wednesday's status call? The calendar entry still has the old numbers... -- PMM

14 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain