linaro-toolchain

linaro-toolchain@lists.linaro.org

8 participants
5647 discussions

by Singh, Ravi Kumar (Ravi)

All, In the below code, I tried few compiler options and got following observations: 1) arm-linux-gnueabi-gcc -O2 -mcpu=cortex-a15 -mfpu=neon -ftree-vectorizer-verbose=6 -ftree-vectorize Compiler throws following info messages: foo.c:16: note: not vectorized: unsupported use in stmt. foo.c:16: note: not vectorized: unsupported use in stmt. foo.c:18: note: not vectorized: unsupported use in stmt. foo.c:18: note: not vectorized: unsupported use in stmt. 2) -O2 -mcpu=cortex-a15 -mfpu=neon None of the generated code contains the NEON instructions. Code generated with case 1 is taking 3000 cycles, and code generated by option 2 is taking 2500 cycles. Even if vectorization failed in case1, it should not generate more inefficient code than case 2. My belief was that the executables from both would take same cycles, any thing done for doing unsuccessful vectorization must be reverted if it did not succeed. ################################################################### #define SIZE1 20 #define SIZE2 26 unsigned int array[SIZE1][SIZE2]; void foo() { unsigned int i,j; unsigned int max = 0; for(i = 0; i < SIZE1; i++) { for(j = 0; j < SIZE2; j++) { if (array[i][j] > max) { max = array[i][j]; index = j; } } } printf("Max value: %u Index: %u\n", max, index); } Regards RKS

13 years, 6 months

2012.04 release prep

by Michael Hope

Hi there. The 2012.04 toolchain release is this week. Ulrich, I see your fix for LP: #968766 has been approved upstream. In theory it's too late but I'm happy to land it if you are. Could you decide and let Andrew know by the middle of Tuesday? Andrew, if you don't hear from Ulrich then spin away. Andrew, could you run the release process on Tuesday please? There's one extra step this month: once you've uploaded and spawned the job, go to the scheduler screen and click on 'Release' beside each of the ursas. I reserved them to make sure they'd be idle and ready to pick up the release build when ready. Thiago, let us know if Ulrich or I can lend a hand with the GDB release. -- Michael

13 years, 6 months

Changing the time of the fortnightly performance call

by Ramana Radhakrishnan

Hi there, At the last call Michael asked if we could push this call back by 30 minutes given the changes due to daylight savings. Does anyone have any objections to a new time of 10 a.m. BST - 11 a.m. Central European - 9 p.m. New Zealand. ? cheers Ramana

13 years, 6 months

[ACTIVITY] 2nd - 5th April

by Andrew Stubbs

* GCC Identified the latent bug that's upset my NEON-shifts testing. It turns out the define-insn-and-shift patterns in arm/sync.md have no length attributes set. Now that the NEON 64-bit shifts appear to be not broken, I've relaunched the 64-bit extend testing. Identified the problem with my NEON-64-bit-negate patch: I already knew it works better (produces more optimal code) with my NEON-immediates patch, but it turns out that at -O0 the other patch is a hard requirement or else bad things happen in output_move_vfp. Backported Ramana's patch for ARM-mode testing of my recent Thumb 64-bit test cases. I've applied it to Linaro GCC directly, without a merge proposal, as it's a very low-risk patch. Caught up with some launchpad blueprint fiddling. Completed the merges from 4.6 and 4.7 FSF. The 4.7 merge was tricky as it required working around a BZR bug; I've posted the workaround to the toolchain list. * Other On leave on Tuesday Public holiday on Friday. Attached a copy of the ARM Linux ABI document to KBentry 39 so we're hosting it somewhere, at least. Posted an internal Mentor/CS question about getting its old home restored, and getting a relicensed edition to allow others to use it as the basis for a hard-float equivalent.

13 years, 6 months

[Activity] Week 14

by Ramana Radhakrishnan

=== Progress === * Worked on VFP addressing patch and corrected the failures. * Got SPEC2k up and running with hot cold partitioning. Some SEGVs that need investigation. In general results appear to be better in quite a few cases. * Investigated an issue with a merge request for upstream 4.7 branch into our tree. There was a testsuite failure and I wasn't able to reproduce it with a local i386 rebuild of the toolchain. Therefore we'll have to let this go in. == Plans == * I will be away for 2 days this week attending the LLVM conference in London. * Pursue backporting gnu_unique_object upstream. * Finish off the VFP addressing modes patch upstream. * Look at some of the existing blueprints and start discussions around prioritizing this. * Investigate some of the SEGVs with h-c partitioning. Absences. * Apr 12-13 : Euro-LLVM London. * Linaro Connect Q2.12 - May 28 - June 1 -

13 years, 6 months

[Activity] Week 14

by Zhenqiang Chen

Summary: * Revise the patch for relocatable NLS support. * Code size benchmark analysis. Details: 1. Revise the patch for relocatable NLS support: lp:918926. * Read the gcc configure and makefile. * It seams hard to get the relative dir if the gcc is configured with --bindir=... --datadir/datarootdir. E.g. --bindir=/opt/bin --datarootdir=/tmp/data 2. Code size benchmark analysis with -Os * Investigate regression in small cases. 3. Try to build linaro gcc trunk with crosstool-ng. But it reports error when configuring libquadmath. * configure:9829: error: Link tests are not allowed after GCC_NO_EXECUTABLES. * Manual check or a simple case show libc.so can be linked. Plans: * Tuning optimization heuristics for -Os Planed leaves: * April 9 - 11: Vacations Best regards! -Zhenqiang

13 years, 6 months

[ACTIVITY] report week 14

by Peter Maydell

Current Milestones: || || Planned || Estimate || Actual || ||cp15-rework || 2012-01-06 || 2012-04-10 || || Historical Milestones: ||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 || ||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| 2012-02-01 || == other == * LP:970252 got a beagle board booting so I could read the UART version register; reviewed and applied to qemu-linaro the set of patches provided by Jan Vesely (thanks!) * sent a patchset cleaning up the GIC model so it is a self-contained sysbus device; this should make it easier to just drop in a functionally equivalent device which is a shim for an in-kernel GIC model that uses the hardware VGIC features * upstream review: save/load support for sd.c [patchset from Samsung] SPI bus [patchset from Petalogix] * put together qemu-linaro prerelease tarball and did some testing * performance evaluation finished and submitted

13 years, 6 months

[ACTIVITY] 26th - 30th March

by Andrew Stubbs

Continued work on neon 64-bit correctness. This is really dragging out now. I had hoped to have had it fixed by now, but subtle bugs are subtle. The 16-bit opcodes patch is now committed both upstream and in Linaro GCC 4.7, however, so that's some progress at least. Posted benchmark results for the the 64-bit shifts in core registers. The results are inconclusive: the benchmark runs are too noisy.

13 years, 6 months

Binary build release process

by Michael Hope

As part of closing out the Windows toolchain card, I've documented the binary build release process at: https://wiki.linaro.org/WorkingGroups/ToolChain/BinaryBuild/ReleaseProcess The interesting thing is a script that pulls builds from S3 and posts them to Launchpad. There's a curl command at the end that does the upload and might be useful. -- Michael

13 years, 6 months

Re: [Linaro-toolchain-builds] [cbuild] eglibc-2.16~svn17843 armv7l completed

by Michael Hope

On 1 April 2012 05:56, Ramana Radhakrishnan <ramana.radhakrishnan(a)linaro.org> wrote: > I find it a bit worrying that all the nptl tests are failing with a > common error message > > http://builds.linaro.org/toolchain/eglibc-2.16~svn17843 > > Aborted' > make[6]: *** [/scratch/cbuild/slave/slaves/tcpanda05/eglibc-2.16~svn17843/eglibc/default/build/nptl/tst-cond7.out] > Error 1 > libgcc_s.so.1 must be installed for pthread_cancel to work > Didn't expect signal from child: got `Aborted' > > Why don't we have libgcc_s.so.1 installed on the system - shouldn't > that be there if there was a gcc properly installed on the system ? This is a bug on my side. I believe EGLIBC likes to have libgcc_s.so in the top of the build directory - at least that's the impression I got from reading the cross-test documentation the other day. I've logged LP: #971064 and will look into it. -- Michael

13 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain