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,
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
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
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 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'
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 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
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:
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
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
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
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
12 matches
Mail list logo
