Hi there!
I need some help with how to handle this bug:
https://bugs.launchpad.net/gcc-linaro/+bug/873977
It looks like an improvement suggestion more than a bug.
Regards
Åsa
*Automatically save preprocessed source on ICE*In order to help with bug
reporting, gcc could save the preprocessed source of the unit that caused
the ICE, so one can just pick it up and attach it to bug reports instead of
trying to reproduce it manually.
Hi Peter. I've had a poke about in qemu-linaro, OpenStack, and
libvirt to get a feel for the KVM integration work. My scratch notes
are here:
https://wiki.linaro.org/MichaelHope/Sandbox/QEMUA15GuestNotes
I'm feeling happy about the integration. The parts that I've seen
have good separation, are architecture neutral, and have some ARM
support. We can prototype using virtual x86 based masters and QEMU
TCG based compute instances.
I've seen a few bugs and assumptions: OpenStack defaults to virtio,
boot=hda, and fixed kernel args; and libvirt can't parse the the
qemu-linaro version string. There will be more.
I'll feed this into the KVM 1.0 task list and share it.
-- Michael
Hi there. Starting next week we'll switch to the Zip conference line. See:
https://wiki.linaro.org/Resources/ZipConferenceLine
under 1-719-457-1414 for a list of numbers. A selected few are:
UK 0 808 101 1146
Germany 0 800 181 9019
Sweden 02 079 7556
Brazil, Sao Paulo Local +55 11 5582 6534
Australia 1 800 105 680
China +400 148 5400
NZ 0800 451 015
The code is 763 804 0680. I've updated the meeting calendar and will
update the wiki page once Monday comes around. The moderator code is
on the toolchain internal page.
Amber, could you update the public event please?
Ramana, could you update the performance call for two weeks time?
Maybe move it to linaro-events so I can edit it.
-- Michael
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
Hi Åsa. I've triaged a bug and written down my notes on the way. See:
https://wiki.linaro.org/MichaelHope/Sandbox/TriageRunThrough
This one turned out to be easy but at least you have the basics.
Could you triage the bug for real and see what I've missed?
I'm unsatisfied with the result on that bug. The fault is in the
Ubuntu Natty compiler which we've long since fixed in Linaro GCC. It
would be nice if we could point the bug reporter to an updated GCC.
Ask Marcin and Matthias what they think.
-- Michael
Summary:
* Enhance crosstool-ng build process.
Details:
1. crosstool-ng patches:
* Reproduce the build process by following the README and enhance
the document.
* Update .config to strip all toolchain executables
* Replace harded-coded VERSION by reading config file.
* Remove host libiberty.a
* Patch on how to strip debug sections is in discussion.
2. Update the crosstool-ng based embedded toolchain build scripts
according to the review comments. And replace most of hard-coded
config by reading them from .config.
3. Unexpected build fail for gcc 4.7/trunk from crosstool-ng due to
unsupported ENDIAN_LDFLAG "-EL", which is used in "LDFLAGS_FOR_TARGET"
to build libstdc++. (LDFLAGS_FOR_TARGET seams not used in gcc 4.6).
Need more investigation.
Plan:
* Fix the binary build related bugs.
* Ramp-up on gcc.
Planned Absence:
* Jan 21-29, 2012 Chinese Spring Festival
Best regards!
-Zhenqiang
Hi,
I use pre-built version of linaro toolchain (got from http://people.linaro.org/~michaelh/incoming/binaries/) to build a uImage.
The build succeeded, but the uImage couldn't start.
The console hangs at:
Using FEC0 device
TFTP from server 10.193.100.158; our IP address is 10.193.102.233
Filename 'uImage_linaro'.
Load address: 0x70800000
Loading: #################################################################
#################################################################
#################################################################
#######################
done
Bytes transferred = 3193292 (30b9cc hex)
## Booting kernel from Legacy Image at 70800000 ...
Image Name: Linux-2.6.38-01026-gc9c8ead
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3193228 Bytes = 3 MB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Does anyone meet this before?
How can I fix it?
Thanks~~
Yours
Terry
* Started with some day-to-day activities in the team. Looking after the
proposals and the cbuild scheduler. Will start
Created problem log for scheduler problems, there is a link to it from the
jobs page. https://wiki.linaro.org/WorkingGroups/ToolChain/SchedulerProblems
* Worked on producing graphs for benchmark results using matplotlib.
Michael: Would it be ok to put my script in
linaro-toolchain-benchmarks/scripts?
* Kicked off some benchmarks with gcc-linaro-4.6-2012.01. To start with
coremark, eembc, denbench, pybench and spec2000. We will see what's there
after the weekend.
Variants: os-neon, o2-neon, o3-neon-novect and o3-neon.
/Regards
Åsa
== GDB ==
* Implemented, tested, and posted for discussion yet another version
of remote support for "info proc" and core file generation, this
time via accessing /proc files via generic file I/O primitives.
== GCC ==
* Tested and merged Revital's fix for LP #879725.
* Tested Richard's patch to help code generation for NEON strided
loads by enabled forward-propagation of subreg expressions. This
caused optimization failures on x86_64; investigated the root
cause and engaged in discussion on mailing list on potential fixes.
* Helped Ramana look into PR 43808 and PR 50313.
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
Continued work on 64-bit shifts. I've tidied up most of the nastiness I
had in my first attempt at this work, unified the logic into fewer
places, and fixed the one logic error that I knew about. I had a
mysterious reload bug that just wouldn't go away, but having stared at
it for some time I've decided that what I was doing wasn't the best
option in any case, and the new way seems to work. I still have the
problem that register-allocation prefers to allocate the values in
core-registers, even when it would seem to me to work better in NEON.
This maybe because the shift amount must be negated in some cases, and
there isn't a neon instruction for that.
Continued trying to use LAVA to do builds. Unfortunately this seems to
have hit against a lava-test bug. Filed as lp:915915.
Hi,
* built linaro binary toolchain using Michaels crosstool-ng environment:
* disabled multiarch and pkg-config
* uses eglibc 2.13 (due to RPC headers)
* using Linux kernel version 2.6.32.48 (longterm)
* debugged why /sbin/init fails when using the linaro binary toolchain:
* the loader and libc of the binary toolchain is build for armv7
* the binaries (init, busybox, ...) are linked against this glibc and
using the libdl-2.13.so of the binary toolchain
* it causes the boot to fails due to illegal insn caused by the dl
* built the minimal image for armv7-a:
* use the vexpress_defconfig of linaro 3.1 tree linux-linaro-3.1.git
(instead of the OE vesatilebp kernel)
* boots fine using the vexpress-a9 QEMU system model
* sato image (X and gtk+ apps) for armv7-a:
* Tremor (vorbis): inline assembly only supports ARM mode
quick workaround: undefine _ARM_ASSEM_ to fall back to C
* pulseaudio/libatomics-ops: inline asm that only supports ARM mode
quick workaround: use the latest version from upstream
* gtk+_2.24.8 fails due to the libstdc++ libtool archive
easy fix: delete the *la files (just like most of the distributors)
the *la files prevent the the binary toolchain from being "relocatable"
* sato image boots and shows the gui but the X resolution is higher and
the X cursor behaves strange (probably not a miscompile but a
difference of the linaro kernel)
Regards,
Ken
RAG:
Red:
Amber:
Green: good progress on A15 vexpress system model
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-02-20 || ||
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| ||
(for blueprint definitions: https://wiki.linaro.org/PeterMaydell/QemuKVM)
Historical Milestones:
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-12-15 || 2011-12-12 ||
== cp15-rework ==
* estimate shifted back since it turns out we can do something useful
in initial-a15-system-model without this as a prerequisite, so that's
a better order to do things in
== initial-a15-system-model ==
* I now have a working vexpress-a15 board model, and enough of the a15
private peripheral region and CPU definition that we can boot a
kernel compiled for A15-without-LPAE
* patchseries mostly looks ok to upstream but there are some loose ends
to fix up involving SMP secondary boot CPU protocol and making sure
the right one of the two graphics controllers gets to display things;
also it depends on some patches in the Calxeda/Samsung patchseries
== other ==
* patch review: Calxeda now basically ready to commit, another round
with Samsung
* made qemu-linaro 2012.01 release
* usual round of meetings etc
==Progress===
* Backported one part of the partial-partial PRE patch . Still looking into it.
* Investigate PR48308 - a bug where combine was generating incorrect
transformations.
* Reopened PR50313 - a bug which I originally thought was a dup of PR48308.
* Looked at upstream bugzilla for sometime and triaged a few bugs.
* Linaro patch review.
=== Plans ===
* Continue looking at partial-partial PRE and try and understand it further.
* Look at PR50313 further
* Upstream patch review.
* Finish submitting PGO patch and ABI tests patch
* Look at Andrew's patches for neon shifts -
Absences.
* Feb 6-10 : Linaro Connect Q1.12.
* Feb 13- 18 : Holiday.
==Progress===
* Short week - 4 days only after the bank holiday monday.
* Investigated PR48308 for a bit.
* Caught up with emails after vacation.
* Looked at fate an automatic tester for libav to validate my fixed
to fp conversions . Need to finish that off.
* 1 more bug with output_move_double ICE looked at briefly. Appears
to be memory corruption but valgrinding didn't find the issue.
Prioritizing PR48308 above this.
=== Plans ===
* Look at PR48308 a bit more seriously.
* Finish my long standing patches.
Absences.
* Feb 6-10 : Linaro Connect Q1.12.
* Feb 13- 18 : Holiday.
Amber noticed this on her Twitter feed: a L4 microkernel based
para-virtualisation that runs on the A9:
http://l4dev.org/
They're currently running the 11.12 LEB on a Versatile Express. The
project overview:
http://l4dev.org/codezero_overview
talks about their 'hyperswitch' method to reduce the
para-virtualisation overhead and reduce the number of changes to the
Linux kernel.
-- Michael
The GCC release tested up just fine. The branch is now open for commits.
The next release is Thursday the 9th of February. Note that this is
in the middle of Connect.
-- Michael
The Linaro Toolchain Working Group is pleased to announce the 2012.01
release of Linaro GCC 4.6 and Linaro GCC 4.5.
No changes were made in Linaro GDB this month and, as such, no release
has been made.
Linaro GCC 4.6 2012.01 is the eleventh release in the 4.6 series.
Based off the latest GCC 4.6.2+svn182894 release, it contains a few
bug fixes from over the Christmas break.
Interesting changes include:
* Updates to 4.6.2+svn182894
Fixes:
* PR51301 ICE in vectorised widening multiplies
* LP: #897583 Code generation bug with -O2 (-foptimize-sibling-calls)
* LP: #736661 armel FTBFS due to compiler ICE
Linaro GCC 4.5 2012.01 is the seventeenth release in the 4.5 series.
Interesting changes include:
* Updates to 4.5.3+svn182893
Fixes:
* LP: #736661 armel FTBFS due to compiler ICE
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.6-2012.01https://launchpad.net/gcc-linaro/+milestone/4.5-2012.01
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 page:
https://launchpad.net/gcc-linaro/4.6/4.6-2012.01https://launchpad.net/gcc-linaro/4.5/4.5-2012.01
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 support(a)linaro.org
-- Michael
The Linaro Toolchain Working Group is pleased to announce the
release of Linaro QEMU 2012.01.
Linaro QEMU 2012.01 is the latest monthly release of
qemu-linaro. Based off upstream (trunk) QEMU, it includes a
number of ARM-focused bug fixes and enhancements.
New in this month's release:
- Several bug fixes which reinstate support for running on ARM hosts
- Support for previously missing *xattr syscalls in usermode emulation
- A (dummy) model of the L2x0/PL310 L2 cache contrnoller (thanks to
Rob Herring and Mark Langsdorf of Calxeda)
Known issues:
- Graphics do not work for OMAP3 based models (beagle, overo)
with 11.10 Linaro images.
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2012.01
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
Hi Åsa. Well, the first proposals have arrived. I've cc'ed this to
linaro-toolchain so we have a record.
First, visit:
http://ex.seabright.co.nz/helpers/proposals
and see there are new merge requests from Ulrich with new results.
Next, login:
http://ex.seabright.co.nz/helpers/login
Your login is your Launchpad OpenID login "https://launchpad.net/~asa-sandahl"
After logging in, go back to the proposals page.
See that the fwprop-subreg merge request has a i686 and x86_64 result.
The i686 one is fine so click 'Record' and follow your nose. The
x86_64 is interesting - the fault might be real. Click 'Record'.
Note the subject line has 'regressed' in it. Ulrich will have to
investigate.
The lp-879725 results look fine so record both of those. Scanning
down the page shows that everything else is recorded so you're done!
The tool is a bit slow so don't be surprised if an operation takes ~10
s. The tool is backed by a cache so you won't see the results for ~2
hours.
-- Michael
Hi Michael,
I can't remember if I told you before, but I shall be away at the
CodeSourcery (Ok, Mentor Graphics's ESD TOOLS) annual meeting most of
next week.
I ought to be back at work on Friday. In the meantime I shall be reading
email, but not spending much time on Linaro work.
I can probably still get the GCC release process done, but if you'd
prefer Ramana did it this month then that's fine with me.
Andrew
Hi there. Linaro is about what's next and, as part of this, we should
backport any reasonable Cortex-A15 changes to our 4.6 branch.
Richard and Matthew, could you let us know directly when new patches
from ARM land upstream?
We're already doing this but I thought I'd say it out loud.
-- Michael
Hello,
I'm trying to build the Linaro GCC from source on an x86_64 Fedora 16 box.
I'm using as a guide a wiki entry I found in linaro.org site [1] that
explains how to build a native version of the compiler. But instead of a
native version I want to be able to cross-compile ARM binaries for my
target machine.
This is what I tried:
[javier@munra src]$ wget -c
http://launchpadlibrarian.net/86993387/gcc-linaro-4.6-2011.12.tar.bz2
[javier@munra src]$ tar xaf gcc-linaro-4.6-2011.12.tar.bz2
[javier@munra src]$ mkdir build && cd build
[javier@munra build]$ ../gcc-linaro-4.6-2011.12/configure
--target=arm-linux --disable-bootstrap --enable-languages=c
--prefix=/home/javier/tools
[javier@munra build]$ make -j4 && make install
But got this error:
make[2]: Leaving directory `/home/javier/src/build/gcc'
Checking multilib configuration for libgcc...
mkdir -p -- arm-linux/libgcc
Configuring in arm-linux/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-unknown-linux-gnu
checking for arm-linux-ar... arm-linux-ar
checking for arm-linux-lipo... arm-linux-lipo
checking for arm-linux-nm... /home/javier/src/build/./gcc/nm
checking for arm-linux-ranlib... arm-linux-ranlib
checking for arm-linux-strip... arm-linux-strip
checking whether ln -s works... yes
checking for arm-linux-gcc... /home/javier/src/build/./gcc/xgcc
-B/home/javier/src/build/./gcc/ -B/home/javier/tools/arm-linux/bin/
-B/home/javier/tools/arm-linux/lib/ -isystem
/home/javier/tools/arm-linux/include -isystem
/home/javier/tools/arm-linux/sys-include
checking for suffix of object files... configure: error: in
`/home/javier/src/build/arm-linux/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/home/javier/src/build'
make: *** [all] Error 2
Before trying to compile I've installed the libgmp, libmpfr and arm cross
tool-chain [2] Fedora packages so I guess all gcc dependencies are met
(binutils, glibc, etc).
Could someone be so kind to point me out what am I doing wrong? I'm sending
as an attachment the config.log generated file.
Please let me know if you need any more information about my setup and
environment.
[1]: https://wiki.linaro.org/WorkingGroups/ToolChain/Using/GCCNative
[2]: http://fedoraproject.org/wiki/Architectures/ARM/CrossToolchain
Thanks a lot and best regards,
Javier