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
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_Ha
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
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
>
>>
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
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 insert
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
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() th
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/s
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, .
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.launchp
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
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-t
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 b
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 % sour
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 wi
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
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
#in
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 d
19 matches
Mail list logo
