[Bug tree-optimization/103226] New: [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[Bug tree-optimization/103226] New: [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[law at gcc dot gnu.org]

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

            Bug ID: 103226
           Summary: [12 Regression] Recent change to copy-headers causes
                    execution failure for gcc.dg/torture/pr80974
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: law at gcc dot gnu.org
  Target Milestone: ---

This change:
commit e82c382971664d6fd138cc36020db4b1a91885c6
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Nov 10 13:21:59 2021 +0100

    Allow loop header copying when first iteration condition is known.

Causes gcc.dg/torture/pr80974.c to fail with -O2 on bfin-elf

I haven't debugged it in any significant way other than bisection to the above
change and quickly looking at the before/after dumps.  Things diverge at the
.ch2 dump (no surprise there).  You may ultimately have to set up a cross
environment to debug this one.

The one other tidbit, before this change, the test finishes relatively fast,
afterwards it takes a LOT longer.  Maybe we're wrapping a loop or something
like that.  Dunno.  It may ultimately not be relevant.

Oh, if you end up doing a binutils, gcc & newlib build and want to test things
yourself using dejagnu you might need a suitable baseboards file.  Here's mine,
which was copied and edited from some other port...


# Copyright (C) 1997-2016 Free Software Foundation, Inc.
#
# This file is part of DejaGnu.
#
# DejaGnu is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# DejaGnu is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with DejaGnu; if not, write to the Free Software Foundation,
# Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.

# This is a list of toolchains that are supported on this board.
set_board_info target_install {bfin-elf}

# Load the generic configuration for this board. This will define a basic set
# of routines needed by the tool to communicate with the board.
load_generic_config "sim"

# basic-sim.exp is a basic description for the standard Cygnus simulator.
load_base_board_description "basic-sim"

# "fr30" is the name of the sim subdir.
setup_sim bfin

# No multilib options needed by default.
process_multilib_options ""

# We only support newlib on this target. We assume that all multilib
# options have been specified before we get here.

set_board_info compiler  "[find_gcc]"
set_board_info cflags    "[libgloss_include_flags] [newlib_include_flags]"
set_board_info ldflags   "-msim [libgloss_link_flags] [newlib_link_flags]"
# No linker script needed.
set_board_info ldscript ""

# The simulator doesn't return exit statuses and we need to indicate this;
# the standard GCC wrapper will work with this target.
set_board_info needs_status_wrapper  1
# Doesn't pass arguments or signals, can't return results, and doesn't
# do inferiorio.
set_board_info noargs 1
set_board_info gdb,nosignals 1
set_board_info gdb,noresults 1
set_board_info gdb,noinferiorio 1

set_board_info gcc,stack_size  4096

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I can't opine on the intricacies of the loopch pass, but the decision the path
solver took was correct:

./cc1 a.c -fdump-tree-all-details -quiet -I/tmp -O2 --param threader-debug=all

Then in the *.ch2 dump file I see:

==============================================
path_range_query: compute_ranges for path: 5->12
range_defined_in_block (BB12) for h_8 is int [0, 0]

=========== BB 5 ============
b.0_3   int [0, 0][5, +INF]
    <bb 5> [local count: 60236916]:
    e = 1;
    goto <bb 12>; [100.00%]


=========== BB 12 ============
Imports: h_8  
Exports: h_8  
b.0_3   int [0, 0][5, +INF]
    <bb 12> [local count: 602369155]:
    # h_8 = PHI <0(5), h_11(11)>
    if (h_8 != 9)
      goto <bb 19>; [90.00%]
    else
      goto <bb 13>; [10.00%]

etc.

The conditional in BB12 resolves to true:

   loopch static returned: _Bool [1, 1]

Which I got from a small tweak to the ch source:

diff --git a/gcc/tree-ssa-loop-ch.c b/gcc/tree-ssa-loop-ch.c
index 566cc275317..d5d80e33450 100644
--- a/gcc/tree-ssa-loop-ch.c
+++ b/gcc/tree-ssa-loop-ch.c
@@ -74,7 +74,14 @@ entry_loop_condition_is_static (class loop *l,
path_range_query *query)
   int_range<2> r;
   query->compute_ranges (e);
   query->range_of_stmt (r, last);
-  return r == int_range<2> (desired_static_value, desired_static_value);
+  bool ret = (r == int_range<2> (desired_static_value, desired_static_value));
+  if (ret && dump_file)
+    {
+    fprintf (dump_file, "loopch static returned: ");
+    r.dump(dump_file);
+    fprintf (dump_file, "\n");
+    }
+  return ret;
 }

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Target Milestone|---                         |12.0
             Target|                            |bfin-elf
           Priority|P3                          |P1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The CH change likely causes an issue downstream.  P1 until we nailed that down
(it might be target specific in which case it will be P4).

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Agreed on P1 until we understand.  If it's target specific P4 seems
appropriate.  I don't see this failure on any other target in the tester.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
It's been a LONG time since I had to do a sim build, so please bear with me.

I have combined tree with  gcc, binutils-gdb, dejagnu, newlib-cygwin:

~/src/combined/configure --target=bfin-elf --enable-languages=c,c++
--with-newlib --prefix=`pwd`/install

C++ won't build:
In file included from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bits/locale_facets.h:41,
                 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bits/basic_ios.h:37,
                 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/ios:44,
                 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/istream:38,
                 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/sstream:38,
                 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/complex:45,
                 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/ccomplex:39,
                 from
/home/aldyh/src/combined/libstdc++-v3/include/precompiled/stdc++.h:54:
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bfin-elf/bits/ctype_base.h:44:35:
error: ‘_U’ was not declared in this scope
   44 |     static const mask upper     = _U;
      |                                   ^~
...
...

So I tried --enable-languages=c which builds, but in-tree testing doesn't work:

(DEJAGNU is set to the provided baseboard file.)

make check-gcc RUNTESTFLAGS="--target_board=basic-sim dg.exp=pr80974.c"

bf532-none/mid-shared-library/mleaf-id-shared-library;@mcpu=bf532-none@mid-shared-library@mleaf-id-shared-library
Executing on host: /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/  -fdiagnostics-plain-output  -flto -c -o
lto3625067.o lto3625067.c    (timeout = 300)
spawn -ignore SIGHUP /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ -fdiagnostics-plain-output -flto -c -o
lto3625067.o lto3625067.c
Executing on host: /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ linker_plugin3625067.c 
-fdiagnostics-plain-output  -flto -fuse-linker-plugin  -lm  -o
linker_plugin3625067.exe    (timeout = 300)
spawn -ignore SIGHUP /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ linker_plugin3625067.c
-fdiagnostics-plain-output -flto -fuse-linker-plugin -lm -o
linker_plugin3625067.exe
xgcc: error: no processor type specified for linking
xgcc: fatal error: error in arguments to spec function 'pass-through-libs'
compilation terminated.
compiler exited with status 1
Executing on host: /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ offload_gcn3625067.c 
-fdiagnostics-plain-output  -foffload=amdgcn-amdhsa -S -o offload_gcn3625067.s 
  (timeout = 300)
spawn -ignore SIGHUP /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ offload_gcn3625067.c
-fdiagnostics-plain-output -foffload=amdgcn-amdhsa -S -o offload_gcn3625067.s
xgcc: error: GCC is not configured to support 'amdgcn-amdhsa' as offload target
xgcc: note: no offloading targets configured
compiler exited with status 1

I also tried --target_board=[bfin,bfin-elf,sim,bfin-sim], but those give:

ERROR: couldn't load description file for bfin-sim

With an installed toolchain, I get a similar linking problem:

$ ./bfin-elf-gcc hello.c -w
bfin-elf-gcc: error: no processor type specified for linking
bfin-elf-gcc: fatal error: error in arguments to spec function
‘pass-through-libs’
compilation terminated.

I tried a few random cpu's from config/bfin/elf.h:

 ./bfin-elf-gcc -mcpu=bf549 hello.c -w
/opt/notnfs/aldyh/bld/bfin-elf/install/bin/../lib/gcc/bfin-elf/12.0.0/../../../../bfin-elf/bin/ld:
/opt/notnfs/aldyh/bld/bfin-elf/install/bin/../lib/gcc/bfin-elf/12.0.0/../../../../bfin-elf/
lib/libc.a(lib_a-closer.o): in function `close_r':
/home/aldyh/src/combined/newlib/libc/reent/closer.c:47: warning: _close is not
implemented and will always fail
/opt/notnfs/aldyh/bld/bfin-elf/install/bin/../lib/gcc/bfin-elf/12.0.0/../../../../bfin-elf/bin/ld:
/opt/notnfs/aldyh/bld/bfin-elf/install/bin/../lib/gcc/bfin-elf/12.0.0/../../../../bfin-elf/
lib/libc.a(lib_a-fstatr.o): in function `fstat_r':
etc
etc.

Hmmm, maybe I should just look at the *.optimized dump and see what's up ;-).

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
FWIW, the *.ch2 dump on both x86-64 and bfin-elf are identical.

This is unlikely to help, but...

In *.ivopts we start seeing differences in the IL:

   <bb 5> [local count: 60236916]:
   e = 1;
+  ivtmp.29_7 = (unsigned int) &g;
   goto <bb 11>; [100.00%]

   <bb 6> [local count: 60236916]:
@@ -593,7 +590,8 @@
     goto <bb 9>; [50.00%]

   <bb 8> [local count: 1625827684]:
-  MEM[(int *)&g + ivtmp.26_25 * 4] = 4;
+  _8 = (void *) ivtmp.29_25;
+  MEM[(int *)_8] = 4;

   <bb 9> [local count: 3251655368]:
   ivtmp_15 = ivtmp_14 - 1;
@@ -603,8 +601,9 @@
     goto <bb 10>; [14.29%]

   <bb 10> [local count: 542132239]:
-  ivtmp.26_10 = ivtmp.26_25 + 1;
-  if (ivtmp.26_10 != 9)
+  h_11 = h_6 + 1;
+  ivtmp.29_10 = ivtmp.29_25 + 4;
+  if (h_11 != 9)
     goto <bb 19>; [90.00%]
   else
     goto <bb 12>; [10.00%]
@@ -612,7 +611,8 @@
   <bb 19> [local count: 487919014]:

   <bb 11> [local count: 542132239]:
-  # ivtmp.26_25 = PHI <ivtmp.26_10(19), 0(5)>
+  # h_6 = PHI <h_11(19), 0(5)>
+  # ivtmp.29_25 = PHI <ivtmp.29_10(19), ivtmp.29_7(5)>
   goto <bb 7>; [100.00%]

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org

--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #4)
> It's been a LONG time since I had to do a sim build, so please bear with me.
> 
> I have combined tree with  gcc, binutils-gdb, dejagnu, newlib-cygwin:
> 
> ~/src/combined/configure --target=bfin-elf --enable-languages=c,c++
> --with-newlib --prefix=`pwd`/install
> 
> C++ won't build:
> In file included from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bits/locale_facets.h:
> 41,
>                  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bits/basic_ios.h:37,
>                  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/ios:44,
>                  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/istream:38,
>                  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/sstream:38,
>                  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/complex:45,
>                  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/ccomplex:39,
>                  from
> /home/aldyh/src/combined/libstdc++-v3/include/precompiled/stdc++.h:54:
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bfin-elf/bits/
> ctype_base.h:44:35: error: ‘_U’ was not declared in this scope
>    44 |     static const mask upper     = _U;
>       |                                   ^~
> ...
> ...

I see the same failures on aarch64-none-elf cross builds which use newlib:

/build-agent/temp/buildTmp/gcc-2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf/bits/ctype_base.h:44:35:
error: '_U' was not declared in this scope
   44 |     static const mask upper     = _U;
      |                                   ^~
/build-agent/temp/buildTmp/gcc-2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf/bits/ctype_base.h:45:35:
error: '_L' was not declared in this scope
   45 |     static const mask lower     = _L;
      |                                   ^~
/build-agent/temp/buildTmp/gcc-2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf/bits/ctype_base.h:46:35:
error: '_U' was not declared in this scope
   46 |     static const mask alpha     = _U | _L;

and so on.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[tnfchris at gcc dot gnu.org]

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

--- Comment #7 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Just a note, in our case the error seems to cause stage2 build to fail.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #7)
> Just a note, in our case the error seems to cause stage2 build to fail.

Please file a PR for it and indicate the architecture.  This PR is for a
pr80974.c regression on bfin-elf.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[tnfchris at gcc dot gnu.org]

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

--- Comment #9 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Tamar Christina from comment #7)
> > Just a note, in our case the error seems to cause stage2 build to fail.
> 
> Please file a PR for it and indicate the architecture.  This PR is for a
> pr80974.c regression on bfin-elf.

Sure, I commented here because the error is the same and on the same file on
the same conditions, so it's likely the same bug. But here it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Aldy, the trick is to not build the C++ runtime ;-)

So instead of "make" use "make all-gcc && make all-target-libgcc" to build the
compiler and libgcc runtime.  Then use "make install-gcc install-target-libgcc"
to install the compiler and libgcc runtime.

Once that completes you can proceed to build & install newlib.

Make sure to use the same --prefix for each component (binutils-gdb, gcc,
newlib) and they should.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[law at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Aldy, I could also set up a cross toolchain, ready for debugging in an AWS
instance if that would be helpful.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #9)
> (In reply to Aldy Hernandez from comment #8)
> > (In reply to Tamar Christina from comment #7)
> > > Just a note, in our case the error seems to cause stage2 build to fail.
> > 
> > Please file a PR for it and indicate the architecture.  This PR is for a
> > pr80974.c regression on bfin-elf.
> 
> Sure, I commented here because the error is the same and on the same file on
> the same conditions, so it's likely the same bug. But here it is
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305

I mentioned the failure in comment #4 to indicate that I can't a build bfin-elf
cross with c++ enabled, but I wasn't implying it was due to the same commit
which is referenced in this PR (r12-5138).

For that matter, if I disable the code introduced by the above commit, C++
still fails to build, so it's not related to this bug at all.  This is why I
asked you to file another PR :).

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

--- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #11)
> Aldy, I could also set up a cross toolchain, ready for debugging in an AWS
> instance if that would be helpful.

Ok, I give up.

I configured and installed the following in order:

binutils
gcc (all-gcc, all-target-libgcc)
newlib

everything's living in install/ and yet I get:

tor:~/bld/bfin/install/bin$ ./bfin-elf-gcc a.c  -w
bfin-elf-gcc: error: no processor type specified for linking
bfin-elf-gcc: fatal error: error in arguments to spec function
‘pass-through-libs’
compilation terminated.

so yeah...set me up with an environment to connect to.  I'm a wuss :-).

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[tnfchris at gcc dot gnu.org]

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

--- Comment #14 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #12)
> (In reply to Tamar Christina from comment #9)
> > (In reply to Aldy Hernandez from comment #8)
> > > (In reply to Tamar Christina from comment #7)
> > > > Just a note, in our case the error seems to cause stage2 build to fail.
> > > 
> > > Please file a PR for it and indicate the architecture.  This PR is for a
> > > pr80974.c regression on bfin-elf.
> > 
> > Sure, I commented here because the error is the same and on the same file on
> > the same conditions, so it's likely the same bug. But here it is
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
> 
> I mentioned the failure in comment #4 to indicate that I can't a build
> bfin-elf cross with c++ enabled, but I wasn't implying it was due to the
> same commit which is referenced in this PR (r12-5138).
> 
> For that matter, if I disable the code introduced by the above commit, C++
> still fails to build, so it's not related to this bug at all.  This is why I
> asked you to file another PR :).

I see, sincere apologies, I misunderstood your comment!

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[law at gcc dot gnu.org]

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

--- Comment #15 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Re: c#13.  You were so close :-)  Add "-msim" to your command line.  THat's one
of the things the baseboards file does for you when you run things under
dejagnu on bfin-elf... 

I've sent Aldy instructions to access an AWS instance I've set up for
debugging.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

--- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #15)
> Re: c#13.  You were so close :-)  Add "-msim" to your command line.  THat's
> one of the things the baseboards file does for you when you run things under
> dejagnu on bfin-elf... 
> 
> I've sent Aldy instructions to access an AWS instance I've set up for
> debugging.

Oh, that's funny.  I just logged into the AWS instance only to notice that your
instructions contained -msim.

I can now run a hello world on my cross build, but still cannot reproduce the
problem:

tor:~/bld/bfin/install/bin$ cat a.c
main(){printf("hello world\n"); }
tor:~/bld/bfin/install/bin$ ./bfin-elf-gcc a.c  -w -msim -O2
tor:~/bld/bfin/install/bin$ ./bfin-elf-run ./a.out
hello world
tor:~/bld/bfin/install/bin$ cat j.c
/* { dg-do run } */

int a, b, c, d, e, f, g[4];

static int fn1 ()
{
  int h, i;
  if (b)
    goto L1;
L2:;
   int m = a;
   while (1)
     {
       int n = 2;
       e = !f && (n = 5);
       if (e)
         for (h = 0; h < 9; h++)
           for (i = 0; i < 6; i++)
             if (a)
               g[h] = 4;
       if (d)
         goto L2;
       a & n || b;
L1:
       if (a)
         L3:
             c = m;
       if (a)
         goto L3;
       if (b < 5)
         return 0;
     }
}

int main ()
{
  fn1 ();
  return 0; 
}
tor:~/bld/bfin/install/bin$ ./bfin-elf-gcc j.c  -w -msim -O2
tor:~/bld/bfin/install/bin$ ./bfin-elf-run ./a.out
tor:~/bld/bfin/install/bin$ 

However, I can reproduce on the AWS instance:

[root@ip-172 gcc]# bfin-elf-gcc -msim -O2 j.c
[root@ip-172 gcc]# bfin-elf-run a.out
[long wait]

Strange.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

--- Comment #17 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
The .s files on my cross versus the AWS instance or not even remotely the same:

--- j.s 2021-11-17 14:13:19.979883609 -0500
+++ j.s.bad     2021-11-17 14:13:12.083828127 -0500
@@ -5,79 +5,78 @@
 .global _main;
 .type _main, STT_FUNC;
 _main:
-       P2.H = _b;
-       [--sp] = ( r7:7, p5:3 );
+       [--sp] = ( p5:3 );

+       P2.H = _b;
+       [--SP] = FP;
        P2.L = _b;
-       R2 = [P2];
-       P1.H = _a;
-       cc =R2==0;
-       P1.L = _a;
+       R0 = [P2];
+       P0.H = _a;
+       cc =R0==0;
+       P0.L = _a;
        if !cc jump .L2;
-       P4.H = _f;
-       P3.H = _e;
-       P5.H = _d;
-       P4.L = _f;

etc
etc.

Except for the --with-newlib, the GCC configure lines look similar:

Configured with: /home/aldyh/src/gcc/configure --target=bfin-elf
--enable-languages=c --with-newlib --prefix=/home/aldyh/bld/bfin/install/
Configured with: /home/jenkins/gcc/configure --prefix=/home/jenkins/installed
--target=bfin-elf

Is there some sort of default -mcpu flag that is different?

Anywhoo...I'll continue working on this tomorrow since copying the AWS .s file
and compiling it on my cross also exhibits the broken behavior... so there's
clearly something there.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-11-17
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Got it!

Confirmed.  I had disabled the optimization while exploring Tamar's comment #7.
 Ugh..

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

--- Comment #19 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
This looks like a target or RTL problem.

The .optimized dumps between x86-64 and bfin-elf look the same for:

-O2 -fno-tree-vrp -fno-tree-vectorize -fno-thread-jumps -fno-ivopts
-fno-tree-pre -fdisable-tree-pre -fdisable-tree-cunrolli -fdisable-tree-cunroll
-fdisable-tree-ivcanon 

and yet bfin-elf hangs.

The problem is this loop:

       e = !f && (n = 5);
       if (e)
         for (h = 0; h < 9; h++)
           for (i = 0; i < 6; i++)
             if (a)
               g[h] = 4;

The register holding &g[h] overflows past the end and writes 4 to f, causing an
infinite loop.

Ultimately this boils down to:

        cc = (a == 0)
<snip>
<snip>
        R1 = 4 (X);
        P5 = 9 (X);
        LSETUP (.L5, .L25) LC1 = P5;
.L5:
        P2 = I0;                ;; p2 = &g
        P0 = P2 + (P4 << 2);    ;; p0 = &g[h]
        P2 = 6 (X);             ;; i = 6
.L7:
        if cc jump .L6 (bp);    ;; <<<< BOO HISS!!!!! <<<<<
        [P0] = R1;              ;; *(p0) = 4
.L6:
        P2 += -1;               ;; i--
        cc =P2==0;
        if !cc jump .L7;        ;; if (i==0) goto .L7
.L25:
        P4 += 1;

The first time we check CC, it's the a==0 gate skipping the write to g[h]. 
Then we overwrite CC with the inner loop latch (i==0) and jump back to L7 where
the check against CC is no longer related to "a", and false.  So we overrwrite
[P0] with 4.  This write is incorrect, but it's the eventual overflow of P0
into &f that causes a write to 4, and an infinite loop because if(e) will
always be false.

My RTL knowledge is very old and probably incorrect, but by *.alignments we
have:

;; THIS IS A CHECK FOR if(a)
(code_label 41 143 29 8 7 (nil) [1 uses])
(jump_insn 31 29 32 8 (set (pc)
        (if_then_else (ne (reg:BI 34 CC [89])
                (const_int 0 [0]))
            (label_ref:SI 38)
            (pc))) "j.c":19:10 124 {cbranchbi4}
     (int_list:REG_BR_PROB 536870916 (nil))
 -> 38)

<snip>
<snip>

;; HERE WE SET PC BUT DONT CLOBBER CC
(code_label 38 37 39 10 6 (nil) [1 uses])
(note 39 38 142 10 [bb 10] NOTE_INSN_BASIC_BLOCK)
(jump_insn 142 39 46 10 (parallel [
            (set (pc)
                (if_then_else (ne (reg:SI 10 P2 [98])
                        (const_int 1 [0x1]))
                    (label_ref:SI 41)
                    (pc)))
            (set (reg:SI 10 P2 [98])
                (plus:SI (reg:SI 10 P2 [98])
                    (const_int -1 [0xffffffffffffffff])))
            (unspec [
                    (const_int 0 [0])
                ] 10)
            (clobber (scratch:SI))
        ]) "j.c":18:19 96 {loop_end}
     (int_list:REG_BR_PROB 920304124 (nil))
 -> 41)

And in the *.reorg pass we clobber the CC and end up with the problematic
sequence:

(code_label 41 143 29 8 7 (nil) [1 uses])

(note 29 41 31 8 [bb 8] NOTE_INSN_BASIC_BLOCK)

(jump_insn:TI 31 29 32 8 (set (pc)
        (if_then_else (ne (reg:BI 34 CC [89])
                (const_int 0 [0]))
            (label_ref:SI 38)
            (pc))) "j.c":19:10 124 {cbranchbi4}
     (int_list:REG_BR_PROB 536870916 (nil))
 -> 38)

(note 32 31 37 9 [bb 9] NOTE_INSN_BASIC_BLOCK)

(insn:TI 37 32 38 9 (set (mem:SI (reg/f:SI 8 P0 [92]) [1 g[h_33]+0 S4 A32])
        (reg:SI 1 R1 [93])) "j.c":20:14 19 {*movsi_insn}
     (nil))

(code_label 38 37 39 10 6 (nil) [1 uses])

(note 39 38 218 10 [bb 10] NOTE_INSN_BASIC_BLOCK)

(insn 218 39 219 10 (set (reg:SI 10 P2 [98])
        (plus:SI (reg:SI 10 P2 [98])
            (const_int -1 [0xffffffffffffffff]))) "j.c":18:19 50 {addsi3}
     (nil))

(insn 219 218 220 10 (set (reg:BI 34 CC)
        (eq:BI (reg:SI 10 P2 [98])
            (const_int 0 [0]))) "j.c":18:19 118 {compare_eq}
     (nil))

(jump_insn 220 219 46 10 (set (pc)
        (if_then_else (eq (reg:BI 34 CC)
                (const_int 0 [0]))
            (label_ref 41)
            (pc))) "j.c":18:19 124 {cbranchbi4}
     (nil)
 -> 41)

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--- Comment #20 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Your c#19 was a bit hard to follow.  But you hit the key issue.  Namely that
the doloop pattern will set/clobber the condition codes if it gets split. 
Failure to show that clobber means that IRA/LRA have incorrect dataflow and
make incorrect decisions.

I'm testing the obvious fix of adding the clobber.  It may be possible to
improve on my patch, but I'll leave that to someone who really cares about the
port.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[aldyh at gcc dot gnu.org]

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

--- Comment #21 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #20)
> Your c#19 was a bit hard to follow.  But you hit the key issue.

Ughh sorry. I'm running on fumes here :-).

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:

https://gcc.gnu.org/g:7950c96ca667ddaab9d6e894da3958ebc2e2dccb

commit r12-5432-g7950c96ca667ddaab9d6e894da3958ebc2e2dccb
Author: Jeff Law <jeffreyalaw@gmail.com>
Date:   Sat Nov 20 11:20:07 2021 -0500

    Clobber the condition code in the bfin doloop patterns

    Per Aldy's excellent, but tough to follow analysis in PR 103226, this patch
    fixes the bfin-elf regression.

    In simplest terms the doloop patterns on this port may clobber the
condition
    code register, but they do not expose that until after register allocation.
    That would be fine, except that other patterns have exposed CC earlier.  As
    a result the dataflow, particularly for CC, is incorrect.

    This leads the register allocators to assume that a value in CC outside the
    loop is still valid inside the loop when in fact, the value has been
    clobbered.  This is what caused pr80974 to start failing.

    With this fix, not only do we fix the pr80974 regression, but we fix ~20
    other execution failures in the port.  It also reduces test time for the
    port from ~90 minutes to ~60 minutes.

            PR tree-optimization/103226
    gcc/
            * config/bfin/bfin.md (doloop pattern, splitter and expander):
Clobber
            CC.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #23 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Fixed on the trunk.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hp at gcc dot gnu.org

--- Comment #24 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #20)
> Your c#19 was a bit hard to follow.  But you hit the key issue.  Namely that
> the doloop pattern will set/clobber the condition codes if it gets split. 
> Failure to show that clobber means that IRA/LRA have incorrect dataflow and
> make incorrect decisions.
> 
> I'm testing the obvious fix of adding the clobber.  It may be possible to
> improve on my patch, but I'll leave that to someone who really cares about
> the port.

I'm chalking one up for the CC representation ("decc0ration method") where CC
clobbers are *always* present, not added midway "when splitting patterns after
reload".  (The SomeoneCaringForBfin would then also find that that the .md file
shrinks.)