On 08/23/2011 12:35 PM, Tom Rini wrote:
On Tue, Aug 23, 2011 at 1:36 PM, Saul Wold<s...@linux.intel.com> wrote:
[YOCTO #1381]
lttng-ust generates an ICE when building for armv7, so change it to armv5
| vfprintf.c:956:1: error: unrecognizable insn:
| (insn 3968 3967 3969 145 (set (subreg:SI (reg/v:DI 160 [ _umax ]) 0)
| (sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 166 [ nextarg
])
| (const_int 8 [0x8]))
| (reg/f:SI 370 [ argtable.7 ])) [0 *D.6937_569+0 S1
A32]))) vfprintf.c:555 -1
| (nil))
| vfprintf.c:956:1: internal compiler error: in extract_insn, at
recog.c:2109
Which version of lttng-ust is this exactly? In addition to what
Darren is saying about how this should be papered-over at the recipe
level until gcc itself is fixed...
Sorry, this was my mis-understanding of Darren's comment.
Version of lttng-ust is 0.15.
Initially I tried to do something with tcmode-default, setting lttng-ust
similar to meta-xlib which also had a ICE issue.
TARGET_CC_ARCH_arm_pn-mesa-xlib :=
"${@'${TARGET_CC_ARCH}'.replace('armv7-a','armv5')}"
That caused the compiler to complain about a mode issue, probably due to
mixing of tune parameters:
| arm-poky-linux-gnueabi-libtool: compile: ccache
arm-poky-linux-gnueabi-gcc
-march=armv5 -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp
-mfpu=neon -mtune=cortex-a8
--sysroot=/vol/1/sgw/autobuilder/yab/yocto-slave/external/build/build/tmp/sysroots/beagleboard
-DHAVE_CONFIG_H -I. -I.. -I../include/ust -I../include -I../libustcomm
-DUST_COMPONENT=libust -fno-strict-aliasing -Wall -pipe -g
-feliminate-unused-debug-types -MT libust_la-marker-control.lo -MD -MP -MF
.deps/libust_la-marker-control.Tpo -c marker-control.c -o
libust_la-marker-control.o >/dev/null 2>&1
| mv -f .deps/libust_la-tracercore.Tpo .deps/libust_la-tracercore.Plo
| {standard input}: Assembler messages:
| {standard input}:190: Error: selected processor does not support ARM
mode `dmb'
Yes, we are trying to solve Compiler issue, when I first started working
on the last week there was not a compiler bug filed, but now there seems
to be one!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43137
Which looks like it is resolved also!
I will move this to Nitin to see if he can incorporate the patch into gcc.
Sau!
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
