[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #28 from Jakub Jelinek --- Fixed.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #27 from Jakub Jelinek --- Author: jakub Date: Fri Feb 15 07:52:50 2019 New Revision: 268930 URL: https://gcc.gnu.org/viewcvs?rev=268930&root=gcc&view=rev Log: PR other/69006 PR testsuite/88920 * lib/gcc-dg.exp: If llvm_binutils effective target, set allow_blank_lines to 2 during initialization. (dg-allow-blank-lines-in-output): Set allow_blank_lines to 1 only if it was previously zero. (gcc-dg-prune): Don't check for llvm_binutils effective target here. Clear allow_blank_lines afterwards whenever it was 1. * gdc.test/gdc-test.exp (dmd2dg): Don't call dg-allow-blank-lines-in-output here. (gdc-do-test): Set allow_blank_lines to 3 if it is 0 before running the tests and restore it back at the end. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gdc.test/gdc-test.exp trunk/gcc/testsuite/lib/gcc-dg.exp
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #26 from Bill Schmidt --- Yes, that indeed helps! With that we see it once per directory prior to running the tests, like the other existing checks. Thanks!
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #25 from Jakub Jelinek --- Created attachment 45679 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45679&action=edit gcc9-pr88920.patch For that I agree it is annoying, does the following patch fix it? There is another issue, once any test uses dg-allow-blank-lines-in-output, empty lines are allowed in all following tests.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #24 from Bill Schmidt --- Why does this end up showing up after a test is run, rather than early like all the other target-supports checks? It would be less surprising if it acted like the others (and I would probably not have noticed to complain :).
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #23 from Andrew Stubbs --- It's caused by the llvm_binutils check, which is used by pretty much every test to determine whether to complain about blank lines in compile output, or not. Right now the easiest way to determine if it's using that toolchain is to check if the target is amdgcn (that being the only target that needs it). I suppose llvm could also be detected by inspecting the --version output from -as, or some such. Your configuration isn't to blame.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #22 from Bill Schmidt --- It also seems odd to me that all the other checks happen when reading powerpc.exp, prior to running my tests, but this one happens late: Running /home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.target/powerpc/powerpc.exp ... [Test for linker_plugin] [Test for vsx_hw_available] Run my test [Test for offload_gcn]
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #21 from Bill Schmidt --- Well, perhaps this is business as usual, but I'd still like to understand this a little better. What causes us to run the effective-target check for this thing in the first place? I've restricted my query with RUNTESTFLAGS to directories that contain powerpc.exp. To my knowledge, there's nothing in any such directory that cares about GPU offloading. So what causes the effective-target check? I'm okay with closing this, but would very much like to understand if we have an inefficiency here where we're running all sorts of checks that aren't needed for the tests being run. Or if we have something wrong in powerpc.exp that is causing this unnecessary effective-target check.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #20 from Jakub Jelinek --- Various effective targets are checked already in the initialization of various *.exp, etc. E.g. struct-layout-1.exp checks check_effective_target_short_enums, gomp.exp checks check_effective_target_fopenmp, dfp.exp checks dfp effective target, lto.exp lto, sso.exp int32, ubsan.exp that -fsanitize=undefined works, many others. That is again normal and happens a lot. I really don't understand why you care about this. The log file is indeed verbose and prints everything that has been executed. Are you upset that there is fatal error: in there, or even error: would upset you (as I said above, that happens e.g. with ilp32 or lp64 etc. if those fail).
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #19 from Bill Schmidt --- Specifially, I asked to compile only srad-modulo.c, but I end up with a compilation of offload_gcn7262.c in my log when I do not configure in any way to test for this.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #18 from Bill Schmidt --- (In reply to Jakub Jelinek from comment #16) > I don't see why this should be reopened. Many of the effective target > procedures leave some output in the log files, that is completely normal. > Why should this one be an exception? This is running a test that nobody asked for. I don't understand why the effective target is even being checked!!
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #17 from Andrew Stubbs --- If this is going to annoy a lot of people then I suppose I could add an additional message stating that the error can safely be ignored? Or, maybe there's a way to silence/hide the output from check_no_compiler_messages?
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #16 from Jakub Jelinek --- I don't see why this should be reopened. Many of the effective target procedures leave some output in the log files, that is completely normal. Why should this one be an exception? E.g. spawn -ignore SIGHUP /home/jakub/src/gcc/obj14/gcc/testsuite/g++3/../../xg++ -B/home/jakub/src/gcc/obj14/gcc/testsuite/g++3/../../ -fsanitize=address -g -I/home/jakub/src/gcc/gcc/testsuite/../../libsanitizer/include -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -nostdinc++ -I/home/jakub/src/gcc/obj14/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/jakub/src/gcc/obj14/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/jakub/src/gcc/libstdc++-v3/libsupc++ -I/home/jakub/src/gcc/libstdc++-v3/include/backward -I/home/jakub/src/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -c -o ilp3225692.o ilp3225692.c ilp3225692.c:4:35: error: narrowing conversion of '-1' from 'int' to 'long unsigned int' [-Wnarrowing] ilp3225692.c:4:27: error: size of array 'dummy' is negative compiler exited with status 1 from failed ilp32 test, many others.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 Bill Schmidt changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #15 from Bill Schmidt --- I don't consider this issue resolved. Yesterday I did a make-check for a single test case, using RUNTESTFLAGS="powerpc.exp=srad-modulo.c". It failed, so I looked in my log file and saw: spawn -ignore SIGHUP /home/wschmidt/gcc/build/gcc-mainline-test2/gcc/xgcc -B/home/wschmidt/gcc/build/gcc-mainline-test2/gcc/ /home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.target/powerpc/srad-modulo.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -mvsx -lm -o ./srad-modulo.exe^M ^[[01m^[[Kcc1:^[[m^[[K ^[[01;31m^[[Kerror: ^[[m^[[Kargument to '^[[01m^[[K-O^[[m^[[K' should be a non-negative integer, '^[[01m^[[Kg^[[m^[[K', '^[[01m^[[Ks^[[m^[[K' or '^[[01m^[[Kfast^[[m^[[K'^M compiler exited with status 1 Executing on host: /home/wschmidt/gcc/build/gcc-mainline-test2/gcc/xgcc -B/home/wschmidt/gcc/build/gcc-mainline-test2/gcc/ offload_gcn7262.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -foffload=amdgcn-unknown-amdhsa -S -o offload_gcn7262.s(timeout = 300) spawn -ignore SIGHUP /home/wschmidt/gcc/build/gcc-mainline-test2/gcc/xgcc -B/home/wschmidt/gcc/build/gcc-mainline-test2/gcc/ offload_gcn7262.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -foffload=amdgcn-unknown-amdhsa -S -o offload_gcn7262.s^M xgcc: fatal error: GCC is not configured to support amdgcn-unknown-amdhsa as offload target^M compilation terminated.^M compiler exited with status 1 FAIL: gcc.target/powerpc/srad-modulo.c (test for excess errors) Excess errors: ^[[01m^[[Kcc1:^[[m^[[K ^[[01;31m^[[Kerror: ^[[m^[[Kargument to '^[[01m^[[K-O^[[m^[[K' should be a non-negative integer, '^[[01m^[[Kg^[[m^[[K', '^[[01m^[[Ks^[[m^[[K' or '^[[01m^[[Kfast^[[m^[[K' I was really confused by this (granted, the embedded color codes didn't help), and if I hadn't already been aware of this bugzilla I wouldn't have known what to think. I was able to correct my error, but the existence of this bug wasted my time and would really have flummoxed anyone who hadn't seen the bug before. I don't think this should be closed until the problem is resolved when we don't configure offload targets. "Just once" is better than 420 times, but it's still wrong.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 Andrew Stubbs changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #14 from Andrew Stubbs --- *** Bug 89095 has been marked as a duplicate of this bug. ***
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 Andrew Stubbs changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Andrew Stubbs --- The patch is applied and the (harmless) error message should appear once per test run only.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #12 from Andrew Stubbs --- Author: ams Date: Wed Jan 30 11:26:31 2019 New Revision: 268384 URL: https://gcc.gnu.org/viewcvs?rev=268384&root=gcc&view=rev Log: Cache effective-target llvm_binutils result. 2019-01-30 Andrew Stubbs PR testsuite/88920 gcc/testsuite/ * lib/target-supports.exp: Cache result. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #11 from Andrew Stubbs --- Created attachment 45481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45481&action=edit Cache test This patch caches the result so that the (harmless) error message occurs only once. Is there a way to hide it in a higher verbosity level?
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #9 from Andrew Stubbs --- (In reply to Jakub Jelinek from comment #8) > First of all, I thought the current trunk amdgcn support is non-offloading > only, so you could at least for now always return 0 from > check_effective_target_offload_gcn, or am I wrong here? That's true, for now. > Does the llvm as or ld emit blank lines even when not emitting any useful > diagnostics, or only if it emits some errors/warnings? Only when it emits diagnostics. For example: .../amdgcn-unknown-amdhsa/bin/ld: error: undefined symbol: open >>> referenced by openr.c:50 (.../newlib/libc/reent/openr.c:50) >>> lib_a-openr.o:(_open_r) in archive >>> .../amdgcn-unknown-amdhsa/lib/libc.a .../amdgcn-unknown-amdhsa/bin/ld: error: undefined symbol: open >>> referenced by openr.c:50 (.../newlib/libc/reent/openr.c:50) >>> lib_a-openr.o:(_open_r) in archive >>> .../amdgcn-unknown-amdhsa/lib/libc.a .../amdgcn-unknown-amdhsa/bin/ld: error: undefined symbol: kill >>> referenced by signalr.c:53 (.../newlib/libc/reent/signalr.c:53) >>> lib_a-signalr.o:(_kill_r) in archive >>> .../amdgcn-unknown-amdhsa/lib/libc.a .../amdgcn-unknown-amdhsa/bin/ld: error: undefined symbol: kill >>> referenced by signalr.c:53 (.../newlib/libc/reent/signalr.c:53) >>> lib_a-signalr.o:(_kill_r) in archive >>> .../amdgcn-unknown-amdhsa/lib/libc.a
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #10 from Jakub Jelinek --- (In reply to Andrew Stubbs from comment #9) > > Does the llvm as or ld emit blank lines even when not emitting any useful > > diagnostics, or only if it emits some errors/warnings? > > Only when it emits diagnostics. For example: > > .../amdgcn-unknown-amdhsa/bin/ld: error: undefined symbol: open > >>> referenced by openr.c:50 (.../newlib/libc/reent/openr.c:50) > >>> lib_a-openr.o:(_open_r) in archive > >>> .../amdgcn-unknown-amdhsa/lib/libc.a > > .../amdgcn-unknown-amdhsa/bin/ld: error: undefined symbol: open > >>> referenced by openr.c:50 (.../newlib/libc/reent/openr.c:50) > >>> lib_a-openr.o:(_open_r) in archive > >>> .../amdgcn-unknown-amdhsa/lib/libc.a > > .../amdgcn-unknown-amdhsa/bin/ld: error: undefined symbol: kill > >>> referenced by signalr.c:53 (.../newlib/libc/reent/signalr.c:53) > >>> lib_a-signalr.o:(_kill_r) in archive > >>> .../amdgcn-unknown-amdhsa/lib/libc.a > > .../amdgcn-unknown-amdhsa/bin/ld: error: undefined symbol: kill > >>> referenced by signalr.c:53 (.../newlib/libc/reent/signalr.c:53) > >>> lib_a-signalr.o:(_kill_r) in archive > >>> .../amdgcn-unknown-amdhsa/lib/libc.a But then it should affect only testcases that FAIL already for other reasons. And when the issue is fixed, these extra errors would go away too.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #8 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #6) > Emit blanks where? On the stdout or stderr of the tool? > If so, wouldn't it be better to fix it, wrap them with a wrapper that would > remove that mess or change to a saner assembler/linker? First of all, I thought the current trunk amdgcn support is non-offloading only, so you could at least for now always return 0 from check_effective_target_offload_gcn, or am I wrong here? Does the llvm as or ld emit blank lines even when not emitting any useful diagnostics, or only if it emits some errors/warnings?
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #7 from Andrew Stubbs --- I'm not sure that an assembler or linker can be labelled "insane" for choosing to include some blank lines amongst its diagnostics. :-) In any case, there's no other tool available, and no time/money available to port Binutils at present, although I'd like to see that change. I suppose we could add a wrapper, but would that really improve the user experience?
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #6 from Jakub Jelinek --- Emit blanks where? On the stdout or stderr of the tool? If so, wouldn't it be better to fix it, wrap them with a wrapper that would remove that mess or change to a saner assembler/linker?
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 Andrew Stubbs changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ams at gcc dot gnu.org
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #5 from Andrew Stubbs --- The llvm_binutils check is needed because those tools emit blank lines all over the place, so we end up with hundreds of stupid failures. I'll look into caching it though.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-21 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Also just saw that on x86_64-linux.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Jakub Jelinek changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Ugh, it happens everywhere. I guess the problem is that unlike the other
effective targets like check_effective_target_offload_nvptx etc.,
check_effective_target_offload_gcn is used in
check_effective_target_llvm_binutils and that one is used on pretty much
everything:
# Complain about blank lines in the output (PR other/69006)
global allow_blank_lines
if { !$allow_blank_lines && ![check_effective_target_llvm_binutils]} {
set num_blank_lines [llength [regexp -all -inline "\n\n" $text]]
if { $num_blank_lines } {
global testname_with_flags
fail "$testname_with_flags $num_blank_lines blank line(s) in
output"
}
set allow_blank_lines 0
}
First of all, I fail to see why we care about offload to gcn here, we don't
really have any scan-assembler for offloading stuff, that is done only when
linking.
If the above is really needed for some reason (please explain), then it should
be at least cached, so that it is not invoked 420 times.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #2 from seurer at gcc dot gnu.org --- The configure is pretty simple: /home/seurer/gcc/gcc-test2/configure --prefix=/home/seurer/gcc/install/gcc-test2 --enable-languages=c,fortran,c++ --with-cpu=power8 --disable-bootstrap --with-as=/home/seurer/binutils/install/bin/as --with-ld=/home/seurer/binutils/install/bin/ld
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #1 from Jakub Jelinek --- Have you configured gcc with --enable-offload-targets= that includes amdgcn-unknown-amdhsa ?
