[Bug tree-optimization/102622] [12 Regression] Wrong code with -O3 for skylake-avx512 and icelake-server by r12-3903

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622

--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #6)
> (In reply to Aldy Hernandez from comment #4)
> > Can you try with -fno-thread-jumps to make sure its really the threader at
> > play?
> 
> -fno-thread-jumps fixes the bug.
> 
> > If so, you could try to narrow it down to the problematic threading path
> > with:
> > 
> > -fdbg-cnt=registered_jump_thread:N:N
> > 
> > where N is the number that causes the problem.
> 
> What N should I try? I got
> 
> [hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -S -O3 -march=native
> /export/project/git/gcc-bisect/pr102622.cc
> -fdbg-cnt=registered_jump_thread:10:10
> cc1plus: error: Interval overlap of ??-fdbg-cnt=registered_jump_thread??:
> [1, 10] and [1, 10]

What I usually do is start with say...10

-fdbg-cnt=registered_jump_thread:10

and keep reducing it until you find the problematic one.

Say it dies with 10, but does not with 9.  That usually means that the
combination of the first 10 jump threading paths caused the problem.  More
often than not, it means it's the 10th one.  But it could be a combination of
1-10.

You could then further reduce it to an individual jump threading path (if
you're lucky enough that's only one threading path that's causing the problem--
it's usually the case).

For instance:

-fdbg-cnt=registered_jump_thread:5-5

That will ONLY jump thread the 5th attempt.  If that fails, then you're
absolutely sure it's the 5th attempt that's causing the problem.