Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
2011/4/27 Michael Hope :
> On Tue, Apr 26, 2011 at 1:48 PM, Barry Song <21cn...@gmail.com> wrote:
>> 2011/4/26 Barry Song <21cn...@gmail.com>:
>>> Hi Michael,
>>>
>>> 2011/4/26 Michael Hope :
Hi Barry. I think the toolchain is operating correctly here. The
current version recognises a divide followed by a modulo and optimises
this into a call to the standard EABI function __aeabi__uldivmod().
Note the code:
do_div(Kpart, source);
K = Kpart & 0x;
/* Check if we need to round */
if ((K % 10) >= 5)
K += 5;
This function is provided by libgcc for normal applications. The
kernel provides it's own versions in arch/arm/lib/lib1funcs.s but is
missing __aeabi_uldivmod (note the 'l' for 64 bit).
>>> In fact the problem happen ealier:
>>>
>>> if (Ndiv < 6) {
>>> source /= 2;
>>> pll_div->pre_div = 1;
>>> Ndiv = target / source;
>>> } else
>>> pll_div->pre_div = 0;
>>>
>>> if ((Ndiv < 6) || (Ndiv > 12))
>>> printk(KERN_WARNING
>>> "WM8974 N value %u outwith recommended range!\n",
>>> Ndiv);
>>>
>>> pll_div->n = Ndiv;
>>> Nmod = target % source;
>>> Kpart = FIXED_PLL_SIZE * (long long)Nmod;
>>>
>>> do_div(Kpart, source);
>>>
>>> If commenting "source /= 2", the problem disappear.
>>>
>>>
>> Or if adding one line before do_div, all will be ok.
>> asm("" : "+r"(source));
>> do_div(Kpart, source);
>
> Hi Barry. I can reproduce the problem in Linaro GCC 4.5-2011.04 and
> GCC 4.5.2. It does not exist in GCC 4.6.0. wm8974_set_dai_pll()
> inlines the call to pll_factors() and leaves a .globl reference to
> __aeabi_uldivmod in the code. This function is never called.
>
> Marking pll_factors() as __attribute__((noinline)) also works around
> the problem.
>
> I've logged http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 upstream
> and recorded this as LP: #771551.
Thanks. I am totally thinking it is a gcc bug not an optimization
feature. in fact, __aeabi_uldivmod is never called as seen by objdump.
It only exists in symbol reference list.
>
> -- Michael
>
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
-O2 cause optimization issues while va parameters functions
Hi All,
As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the
following codes, if we compile it by -O2, it will crash with "segment
fault", if we just comment " if(unifi_debug >= level) {", all will be
ok.
If we don't compile it by -O2, all will be ok too.
#include
#include
#include
#define DEBUG_BUFFER_SIZE 80
int unifi_debug = 5;
void
unifi_trace(void* ospriv, int level, const char *fmt, ...)
{
static char s[DEBUG_BUFFER_SIZE];
va_list args;
unsigned int len;
if(unifi_debug >= level) {
va_start(args, fmt);
len = vsnprintf(&(s)[0],
(DEBUG_BUFFER_SIZE),
fmt, args);
va_end(args);
if (len >= DEBUG_BUFFER_SIZE) {
(s)[DEBUG_BUFFER_SIZE - 2] = '\n';
(s)[DEBUG_BUFFER_SIZE - 1] = 0;
}
printf("%s", s);
}
}
int main(void)
{
char *prog = "/usr/sbin/unififw";
unifi_trace(NULL, 1, "start %s\n", prog);
return 0;
}
Thanks
Barry
with-o2.asm
Description: Binary data
without-o2.asm
Description: Binary data
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
On 27/04/11 09:44, Barry Song wrote: Thanks. I am totally thinking it is a gcc bug not an optimization feature. in fact, __aeabi_uldivmod is never called as seen by objdump. It only exists in symbol reference list. Your code contains "Nmod = target % source" so the only reason divmod wouldn't get called is if it got optimized away somehow. If that were the case then it would be a compiler bug somehow, but when I build the test case in Michael's bug report it looks like __aeabi_uidivmod does get called, AFAICT. I don't see any reference to __aeabi_uldivmod so you must have different compiler or testcase? Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: -O2 cause optimization issues while va parameters functions
On 27/04/11 10:08, Barry Song wrote:
Hi All,
As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the
following codes, if we compile it by -O2, it will crash with "segment
fault", if we just comment " if(unifi_debug>= level) {", all will be
ok.
If we don't compile it by -O2, all will be ok too.
Sorry, are you saying that the compiler crashes, or are you saying that
the output binary crashes at runtime?
Andrew
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
2011/4/27 Andrew Stubbs : > On 27/04/11 09:44, Barry Song wrote: >> >> Thanks. I am totally thinking it is a gcc bug not an optimization >> feature. in fact, __aeabi_uldivmod is never called as seen by objdump. >> It only exists in symbol reference list. > > Your code contains "Nmod = target % source" so the only reason divmod > wouldn't get called is if it got optimized away somehow. > > If that were the case then it would be a compiler bug somehow, but when I > build the test case in Michael's bug report it looks like __aeabi_uidivmod > does get called, AFAICT. > > I don't see any reference to __aeabi_uldivmod so you must have different > compiler or testcase? __aeabi_u*i*divmod does get called in asm codes. I mean __aeabi_u*l*divmod has never existed in asm codes after objdump the target ko. __aeabi_u*l*divmod only exists in refrence list. the list means what symbols are depent by this module. So we got a link error. but in fact, the module doesn't need link this symbol since it never call __aeabi_u*l*divmod in asm level. > > Andrew > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: -O2 cause optimization issues while va parameters functions
2011/4/27 Andrew Stubbs :
> On 27/04/11 10:08, Barry Song wrote:
>>
>> Hi All,
>>
>> As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the
>> following codes, if we compile it by -O2, it will crash with "segment
>> fault", if we just comment " if(unifi_debug>= level) {", all will be
>> ok.
>> If we don't compile it by -O2, all will be ok too.
>
> Sorry, are you saying that the compiler crashes, or are you saying that the
> output binary crashes at runtime?
the target binary got crash while running on armv7 board, not gcc :-)
>
> Andrew
>
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: -O2 cause optimization issues while va parameters functions
On 27/04/11 10:23, Barry Song wrote: the target binary got crash while running on armv7 board, not gcc :-) I suspect I know what the problem is here. Can you try again with -fno-shrink-wrap, please? Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
On 27/04/11 10:22, Barry Song wrote: __aeabi_u*l*divmod has never existed in asm codes after objdump the target ko. __aeabi_u*l*divmod only exists in refrence list. the list means what symbols are depent by this module. So we got a link error. but in fact, the module doesn't need link this symbol since it never call __aeabi_u*l*divmod in asm level. Can you compile with --save-temps and look in the .s file. If it's never mentioned in there then it's not a compiler bug (at least, not with this testcase) - the reference is coming from elsewhere. We should be able to narrow things down, at least. Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: -O2 cause optimization issues while va parameters functions
2011/4/27 Andrew Stubbs : > On 27/04/11 10:23, Barry Song wrote: >> >> the target binary got crash while running on armv7 board, not gcc :-) > > I suspect I know what the problem is here. > > Can you try again with -fno-shrink-wrap, please? i guess it is related with this bug: https://bugs.launchpad.net/gcc-linaro/+bug/771675 > > Andrew > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
Hi Andrew. I uploaded the wrong preprocessed source to the GCC
bugzilla entry. It included the __attribute__((noinline)) workaround
which hides the problem.
I've fixed that and re-attached the correct version. The assembly
version contains the following:
.size wm8974_pcm_hw_params, .-wm8974_pcm_hw_params
.global __aeabi_uidiv
.global __aeabi_uidivmod
.global __aeabi_uldivmod
.align 2
.thumb
.thumb_func
.type wm8974_set_dai_pll, %function
wm8974_set_dai_pll:
@ args = 4, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, r4, r5, r6, r7, r8, r9, lr}
...
-- Michael
On Wed, Apr 27, 2011 at 9:33 PM, Andrew Stubbs wrote:
> On 27/04/11 10:22, Barry Song wrote:
>>
>> __aeabi_u*l*divmod has never existed in asm codes after objdump the
>> target ko.
>> __aeabi_u*l*divmod only exists in refrence list. the list means what
>> symbols are depent by this module. So we got a link error. but in
>> fact, the module doesn't need link this symbol since it never call
>> __aeabi_u*l*divmod in asm level.
>
> Can you compile with --save-temps and look in the .s file.
>
> If it's never mentioned in there then it's not a compiler bug (at least, not
> with this testcase) - the reference is coming from elsewhere.
>
> We should be able to narrow things down, at least.
>
> Andrew
>
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod
2011/4/27 Mark Brown
>
> On Wed, Apr 27, 2011 at 04:50:12PM +0800, Barry Song wrote:
>
> > Marking pll_factors() as noinline or putting asm("" : "+r"(source)); before
> > the
> > call to do_div() works around the problem.
>
> If we do have to do something in the callers rather than in do_div() the
> annotation seems substantially more taseful than inserting a random asm
> into the code.
I agree. for this patch which will not be applied, people can just get
information about how to workaround the gcc issue while they have the
same problem. google can find there are other people who failed to
compile wm8974 module too. eg.
http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt
Andrew Stubbs, Michael Hope in Linaro's toolchain team are working
hard on this gcc issue. there have been many update today:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod
2011/4/27 Mark Brown : > On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote: >> 2011/4/27 Mark Brown > >> > If we do have to do something in the callers rather than in do_div() the >> > annotation seems substantially more taseful than inserting a random asm >> > into the code. > >> I agree. for this patch which will not be applied, people can just get >> information about how to workaround the gcc issue while they have the >> same problem. google can find there are other people who failed to >> compile wm8974 module too. eg. >> http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt > >> Andrew Stubbs, Michael Hope in Linaro's toolchain team are working >> hard on this gcc issue. there have been many update today: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 > > Is this just some Linaro toolchain that has the issue rather than a > vanilla GCC release? If so and they fix the compiler bug it doesn't > seem terribly useful to bodge it in mainline. > i am guessing it is a generic gcc issue since Michael posted it at http://gcc.gnu.org/bugzilla not Linaro's Launchpad. not sure :-) ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod
2011/4/27 Barry Song <21cn...@gmail.com>: > 2011/4/27 Mark Brown : >> On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote: >>> 2011/4/27 Mark Brown >> >>> > If we do have to do something in the callers rather than in do_div() the >>> > annotation seems substantially more taseful than inserting a random asm >>> > into the code. >> >>> I agree. for this patch which will not be applied, people can just get >>> information about how to workaround the gcc issue while they have the >>> same problem. google can find there are other people who failed to >>> compile wm8974 module too. eg. >>> http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt >> >>> Andrew Stubbs, Michael Hope in Linaro's toolchain team are working >>> hard on this gcc issue. there have been many update today: >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 >> >> Is this just some Linaro toolchain that has the issue rather than a >> vanilla GCC release? If so and they fix the compiler bug it doesn't >> seem terribly useful to bodge it in mainline. >> > > i am guessing it is a generic gcc issue since Michael posted it at > http://gcc.gnu.org/bugzilla not Linaro's Launchpad. not sure :-) Linaro doesn't exist yet when the discussion happened at http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt discussion: " [19:03] I got this while compiling: "ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8974.ko] undefined!" [19:04] Now, I can disable the driver alltogether, but is this related to the CSL cross compiler? [19:04] nosse1: google should give answer - common problem it was [19:04] hehe - sorry, you're right " ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod
On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote: > 2011/4/27 Mark Brown > > If we do have to do something in the callers rather than in do_div() the > > annotation seems substantially more taseful than inserting a random asm > > into the code. > I agree. for this patch which will not be applied, people can just get > information about how to workaround the gcc issue while they have the > same problem. google can find there are other people who failed to > compile wm8974 module too. eg. > http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt > Andrew Stubbs, Michael Hope in Linaro's toolchain team are working > hard on this gcc issue. there have been many update today: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 Is this just some Linaro toolchain that has the issue rather than a vanilla GCC release? If so and they fix the compiler bug it doesn't seem terribly useful to bodge it in mainline. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod
Hi Mark. The fault exists in FSF GCC 4.5.2 and Linaro GCC 4.5-2011.04. The fault does not exist in FSF GCC 4.6.0 or Linaro GCC 4.6-2011.04. -- Michael On Thu, Apr 28, 2011 at 3:12 AM, Mark Brown wrote: > On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote: >> 2011/4/27 Mark Brown > >> > If we do have to do something in the callers rather than in do_div() the >> > annotation seems substantially more taseful than inserting a random asm >> > into the code. > >> I agree. for this patch which will not be applied, people can just get >> information about how to workaround the gcc issue while they have the >> same problem. google can find there are other people who failed to >> compile wm8974 module too. eg. >> http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt > >> Andrew Stubbs, Michael Hope in Linaro's toolchain team are working >> hard on this gcc issue. there have been many update today: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 > > Is this just some Linaro toolchain that has the issue rather than a > vanilla GCC release? If so and they fix the compiler bug it doesn't > seem terribly useful to bodge it in mainline. > > ___ > 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: -O2 cause optimization issues while va parameters functions
On Wed, Apr 27, 2011 at 9:52 PM, Barry Song <21cn...@gmail.com> wrote:
> 2011/4/27 Andrew Stubbs :
>> On 27/04/11 10:23, Barry Song wrote:
>>>
>>> the target binary got crash while running on armv7 board, not gcc :-)
>>
>> I suspect I know what the problem is here.
>>
>> Can you try again with -fno-shrink-wrap, please?
> i guess it is related with this bug:
>
> https://bugs.launchpad.net/gcc-linaro/+bug/771675
Hi Barry. Thank you for the bug report. I've confirmed this with
gcc-linaro-4.5-2011.04-0 on ARM and logged LP: #772085 at:
https://bugs.launchpad.net/gcc-linaro/+bug/772085
Please subscribe to the bug if you'd like to be updated with any progress.
As you say, the generated code is incorrect and clobbers r3 before use:
unifi_trace:
@ args = 4, pretend = 8, frame = 8
@ frame_needed = 0, uses_anonymous_args = 1
movw r3, #:lower16:.LANCHOR0
movt r3, #:upper16:.LANCHOR0
ldr r3, [r3, #0]
cmp r3, r1
bge .L6
bx lr
.L6:
push {r2, r3}
This only occurs if you add the -fshrink-wrap option. It does not
occur at -O1, -O2, or -O3. The fault does not occur in Linaro GCC 4.6,
gcc-4.5.2, or gcc-4.6.0. I suggest you update to Linaro GCC
4.5-2011.04 which fixes a number of other shrink wrap bugs and also
disables it by default.
I've set it to medium priority as while it is bad-code, the fault only
occurs if you add -fshrink-wrap. This fault will be fixed before
shrink wrapping is turned back on by default.
This is probably the same fault as LP: #736081 and LP: #771675.
-- Michael
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
"BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert
Hi All,
I found Jie has committed a patch
"http://sourceware.org/ml/binutils/2010-05/msg00083.html";.
I am using the newest binary utils(2.21) and encounted the following ASSERT in
arm_elf32.c:
+ if (out_attr[i].i == 0)
+ {
+ BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0);
My compiling options are as below,
ASM_FLAGS :=
\
-gdwarf-2 \
-mfpu=vfp \
-mfloat-abi=softfp\
-mthumb-interwork
C_FLAGS:=
\
$(ASM_FLAGS) \
-O3 -Wno-all \
-fno-optimize-sibling-calls \
-mlong-calls \
-ffunction-sections \
CPP_FLAGS :=
\
-fno-rtti \
-fno-exceptions \
LINK_FLAGS:=
\
--gc-sections -nostdlib \
-L ../stdlib \
-Wl,--as-needed \
-Wl,-no-enum-size-warning\
--cref \
ARFLAGS:=
\
rcs
Can anyone give me any tip about why the assert is triggered?
I have reported a bug here:
http://sourceware.org/bugzilla/show_bug.cgi?id=12700
But not sure whether it is a bug.
-barry
___
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
In the Tag_FP_arch case (i=Tag_FP_arch) of
elf32_arm_merge_eabi_attributes (bfd *ibfd, bfd *obfd) function, when
this ASSERT happen, i got some log:
in_attr[i].i = 2 in_attr[Tag_ABI_HardFP_use].i = 3
out_attr[i].i = 0 out_attr[Tag_ABI_HardFP_use].i = 3,
For in_attr[i].i = 2, it means "Use of the v2 FP ISA was permitted
(implies use of the v1 FP ISA) "
For in_attr[Tag_ABI_HardFP_use].i = 3, it means "The user permitted
this entity to use both SP and DP VFP instructions (Note: This is
effectively an explicit version of the default encoded by 0)"
For out_attr[i].i = 0, it means "The user did not permit this entity
to use instructions requiring FP hardware".
According to Jie's patch, when out_attr[i].i = 0,
out_attr[Tag_ABI_HardFP_use].i should be 0 too. But what i saw is
out_attr[Tag_ABI_HardFP_use].i is also 3, same with
in_attr[Tag_ABI_HardFP_use].i .
Which compiling option changes out_attr[Tag_ABI_HardFP_use].i to 3?
And which compiling options set out_attr[i].i to 0?
Thanks
Barry
2011/4/28 Barry Song <21cn...@gmail.com>:
> Hi All,
> I found Jie has committed a patch
> "http://sourceware.org/ml/binutils/2010-05/msg00083.html";.
> I am using the newest binary utils(2.21) and encounted the following ASSERT in
> arm_elf32.c:
> + if (out_attr[i].i == 0)
> + {
> + BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0);
>
> My compiling options are as below,
> ASM_FLAGS :=
> \
> -gdwarf-2 \
> -mfpu=vfp \
> -mfloat-abi=softfp \
> -mthumb-interwork
>
> C_FLAGS :=
> \
> $(ASM_FLAGS) \
> -O3 -Wno-all \
> -fno-optimize-sibling-calls \
> -mlong-calls \
> -ffunction-sections \
>
>
>
> CPP_FLAGS :=
> \
> -fno-rtti \
> -fno-exceptions \
>
>
> LINK_FLAGS :=
> \
> --gc-sections -nostdlib \
> -L ../stdlib \
> -Wl,--as-needed \
> -Wl,-no-enum-size-warning \
> --cref \
>
> ARFLAGS :=
> \
> rcs
>
> Can anyone give me any tip about why the assert is triggered?
>
> I have reported a bug here:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12700
>
> But not sure whether it is a bug.
>
> -barry
>
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
