This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/60533] [4.8/4.9 regression] Error introduced by cunrolli pass at -O3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533

--- Comment #10 from pinskia at gmail dot com <pinskia at gmail dot com> ---
> On Mar 15, 2014, at 7:59 PM, "wschmidt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533
> 
> --- Comment #7 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
> The problem is actually introduced much earlier, during the cunrolli (complete
> unroll inner) pass.  I'm attaching dumps from 055t.copyrename2 and
> 056t.cunrolli to show what happens.  Prior to unrolling, we have a loop formed
> by blocks 47,19,20,...,46, with the original call to makeUnion at the end of
> block 45.  The unroller decides that this loop will be executed exactly 3 times
> and unrolls it completely.  (It's not clear to me on what basis this decision
> is made in the first place; it doesn't seem justified on the surface.)

What is the type of bc?  That access to bc in bb 46 looks like to be the cause. 

What is the original code look like, do we have an out of bounds access here or
just a miscombining to create one?

Thanks,
Andrew


> 
> In any case, the third copy of the loop comprises blocks 74 through 101, with
> the call to makeUnion duplicated at the end of block 100.  The unroller then
> inserts a __builtin_unreachable at the end of block 101 for some reason.  This
> survives until the rewrite into RTL, at which point it is converted to the
> barrier that causes the bad block reordering.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]