[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #24 from Hans-Peter Nilsson ---
(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.)
[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Jeffrey A. Law --- Fixed on the trunk.
[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #22 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:7950c96ca667ddaab9d6e894da3958ebc2e2dccb commit r12-5432-g7950c96ca667ddaab9d6e894da3958ebc2e2dccb Author: Jeff Law 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #21 from Aldy Hernandez --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 Jeffrey A. Law changed: What|Removed |Added Priority|P1 |P4 --- Comment #20 from Jeffrey A. Law --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #19 from Aldy Hernandez ---
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 [h] overflows past the end and writes 4 to f, causing an
infinite loop.
Ultimately this boils down to:
cc = (a == 0)
R1 = 4 (X);
P5 = 9 (X);
LSETUP (.L5, .L25) LC1 = P5;
.L5:
P2 = I0;;; p2 =
P0 = P2 + (P4 << 2);;; p0 = [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 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)
;; 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 [0x])))
(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 [0x]))) "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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 Aldy Hernandez changed: What|Removed |Added Last reconfirmed||2021-11-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #18 from Aldy Hernandez --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #17 from Aldy Hernandez --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #16 from Aldy Hernandez ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #15 from Jeffrey A. Law --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #14 from Tamar Christina --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #13 from Aldy Hernandez --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #12 from Aldy Hernandez --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #11 from Jeffrey A. Law --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #10 from Jeffrey A. Law --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #9 from Tamar Christina --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #8 from Aldy Hernandez --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #7 from Tamar Christina --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #6 from Tamar Christina --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #5 from Aldy Hernandez --- 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: [local count: 60236916]: e = 1; + ivtmp.29_7 = (unsigned int) goto ; [100.00%] [local count: 60236916]: @@ -593,7 +590,8 @@ goto ; [50.00%] [local count: 1625827684]: - MEM[(int *) + ivtmp.26_25 * 4] = 4; + _8 = (void *) ivtmp.29_25; + MEM[(int *)_8] = 4; [local count: 3251655368]: ivtmp_15 = ivtmp_14 - 1; @@ -603,8 +601,9 @@ goto ; [14.29%] [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 ; [90.00%] else goto ; [10.00%] @@ -612,7 +611,8 @@ [local count: 487919014]: [local count: 542132239]: - # ivtmp.26_25 = PHI + # h_6 = PHI + # ivtmp.29_25 = PHI goto ; [100.00%]
[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #4 from Aldy Hernandez --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #3 from Jeffrey A. Law --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |12.0 Target||bfin-elf Priority|P3 |P1 --- Comment #2 from Richard Biener --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Aldy Hernandez ---
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]
[local count: 60236916]:
e = 1;
goto ; [100.00%]
=== BB 12
Imports: h_8
Exports: h_8
b.0_3 int [0, 0][5, +INF]
[local count: 602369155]:
# h_8 = PHI <0(5), h_11(11)>
if (h_8 != 9)
goto ; [90.00%]
else
goto ; [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;
}
