This is the mail archive of the
mailing list for the GCC project.
Re: Chasing a potential wrong-code bug on trunk
- From: Richard Biener <rguenther at suse dot de>
- To: Martin Reinecke <martin at MPA-Garching dot MPG dot DE>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 17 Nov 2016 11:01:59 +0100 (CET)
- Subject: Re: Chasing a potential wrong-code bug on trunk
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
On Thu, 17 Nov 2016, Martin Reinecke wrote:
> At some point in May 2016 there was a patch to the gcc trunk which
> caused one of my numerical codes to give incorrect results when compiled
> with this gcc version. This may of course be caused by some undefined
> behavior I'm unknowingly invoking in the code, or it may be a code
> generation bug in gcc. I tried to isolate the exact gcc commit that
> caused the change, but I got stuck...
> Starting from SVN revision 236320:
> 2016-05-17 Richard Biener <firstname.lastname@example.org>
> PR tree-optimization/71132
> * tree-loop-distribution.c (create_rdg_cd_edges): Pass in loop.
> Only add control dependences for blocks in the loop.
> (build_rdg): Adjust.
> (generate_code_for_partition): Return whether loop should
> be destroyed and delay that.
> (distribute_loop): Likewise.
> (pass_loop_distribution::execute): Record loops to be destroyed
> and perform delayed destroying of loops.
> gcc crashes with an ICE when trying to compile the code.
> Compilation works again starting with revision 236361:
> 2016-05-18 Richard Biener <email@example.com>
> PR tree-optimization/71168
> * tree-loop-distribution.c (distribute_loop): Move *destroy_p
> initialization earlier.
> * gcc.dg/torture/pr71168.c: New testcase.
> but then the compiled code produces incorrect results.
> I can provide an unreduced test case, but it is several thousand lines
> long and I don't have a clue how to reduce it yet. Judging from the
> ChangeLog entries I strongly suspect that the tree-loop-distribution
> changes caused the different behavior.
> Could someone please give me a hint which sort of loops are most likely
> to be compiled differently after the changes, so that I have a better
> idea where to look for the problem?
You could compare -fopt-info-optimized output which for example says
testsuite/gcc.dg/tree-ssa/ldist-12.c:12:3: note: Loop 1 distributed: split
to 2 loops and 0 library calls.
note that if you do not explicitely enable -ftree-loop-distribution
then you only get (at -O3+) memcpy, memmove and memset recognition
Note the above changes should not have changed code generation so
likely the offending change was done between those revisions. You
could bisect further by either applying the second change or reverting
the earlier change inbetween those revisions.
Suspicious is maybe r236356 (transforming x+x+x+x+x to 5*x with