cc1 backtrace:
arraysum.c: In function 'test_entry':
arraysum.c:14:1: internal compiler error: in cfg_layout_initialize, at
cfgrtl.c:4233
}
^
0x6c096d cfg_layout_initialize(unsigned int)
../../trunk/gcc/cfgrtl.c:4233
0xeab763 reorder_loops
../../trunk/gcc/hw-doloop.c:500
0xeacd04 reorg_l
On 01/09/2014 05:20 AM, Jeff Law wrote:
On 01/07/14 09:07, Bernd Schmidt wrote:
If someone explicitly chooses that option we can turn off the reordering
in hw-doloop. That should happen sufficiently rarely that it isn't a
problem. That's what the patch below does - bootstraped on x86_64-linux,
Ping x1
Any suggestions on this?
The background is that we cannot call cfg_layout_initialize after the
bb-reorder pass
as indicated by the following code snippet:
/* Once bb reordering is complete, cfg layout mode should not be re-entered.
Entering cfg layout mode will perform optimizatio
On 01/01/2014 02:01 PM, Felix Yang wrote:
cc1 backtrace:
arraysum.c: In function 'test_entry':
arraysum.c:14:1: internal compiler error: in cfg_layout_initialize, at
cfgrtl.c:4233
Please include steps to reproduce bugs.
Attached please find the patch for this ICE.
Since c6x backend choose do
Hi Bernd,
It's easy to reproduce this error:
step1: Build gcc for c6x from gcc code of latest trunk, say
c6x-uclinux-gcc for example
step2: Using the newly built c6x gcc compiler to comiple this small case:
$c6x-unlinux-gcc -S -O2 arraysum.c
arraysum.c:
int array[1024];
int te
Ping?
Cheers,
Felix
On Thu, Jan 2, 2014 at 10:13 PM, Felix Yang wrote:
> Hi Bernd,
>
> It's easy to reproduce this error:
> step1: Build gcc for c6x from gcc code of latest trunk, say
> c6x-uclinux-gcc for example
> step2: Using the newly built c6x gcc compiler to comiple this small case:
On 01/05/2014 12:35 PM, Felix Yang wrote:
Ping?
Cheers,
I have a different patch which I'll submit next week after some more
testing. The assert in cfgrtl is unnecessarily broad and really only
needs to trigger if -freorder-blocks-and-partition; there's nothing
wrong with entering cfglayout
On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt wrote:
> On 01/05/2014 12:35 PM, Felix Yang wrote:
>>
>> Ping?
>> Cheers,
>
>
> I have a different patch which I'll submit next week after some more
> testing. The assert in cfgrtl is unnecessarily broad and really only needs
> to trigger if -freorder-
On 01/05/2014 05:10 PM, Teresa Johnson wrote:
On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt wrote:
I have a different patch which I'll submit next week after some more
testing. The assert in cfgrtl is unnecessarily broad and really only needs
to trigger if -freorder-blocks-and-partition; there'
Hi Bernd,
The patch is OK to me. But do we need reorder_loops for the c6x backend ?
I mean we can set the do_reorder parameter to FALSE to save compile
time, since c6x backend only choose hw-doloops whose body contains only one
basic block.
Cheers,
Felix
>
> On 01/05/2014 05:10 P
On Tue, Jan 7, 2014 at 8:07 AM, Bernd Schmidt wrote:
> On 01/05/2014 05:10 PM, Teresa Johnson wrote:
>>
>> On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt
>> wrote:
>>>
>>> I have a different patch which I'll submit next week after some more
>>> testing. The assert in cfgrtl is unnecessarily broad
On 01/07/14 09:07, Bernd Schmidt wrote:
On 01/05/2014 05:10 PM, Teresa Johnson wrote:
On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt
wrote:
I have a different patch which I'll submit next week after some more
testing. The assert in cfgrtl is unnecessarily broad and really only
needs
to trigger
12 matches
Mail list logo
