[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Bernd Edlinger changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #20 from Bernd Edlinger --- should be fixed now. Thanks!
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #19 from CVS Commits --- The master branch has been updated by Bernd Edlinger : https://gcc.gnu.org/g:6ebf79fcd4cfb43353e6a000f700b07295e78026 commit r11-6588-g6ebf79fcd4cfb43353e6a000f700b07295e78026 Author: Bernd Edlinger Date: Thu Jan 7 09:37:32 2021 +0100 testsuite: Fix test failures from outputs.exp [PR98225] The .ld1_args file is not created when HAVE_GNU_LD is false. The ltrans0.ltrans_arg file is not created when the make jobserver is available, so remove the MAKEFLAGS variable. Add an exception for *.gcc_args files similar to the exception for *.cdtor.* files. Limit both exceptions to targets that define EH_FRAME_THROUGH_COLLECT2. That means although the test case does not use C++ constructors or destructors it is still using dwarf2 frame info. 2021-01-11 Bernd Edlinger PR testsuite/98225 * gcc.misc-tests/outputs.exp: Unset MAKEFLAGS. Expect .ld1_args only when GNU LD is used. Add an exception for *.gcc_args files.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #18 from David Edelsohn --- PASS: outputs exe savetmp namedb: outputs-outputs-0.i PASS: outputs exe savetmp namedb: outputs-outputs-0.s PASS: outputs exe savetmp namedb: outputs-outputs-0.o PASS: outputs exe savetmp namedb: outputs.args.0 FAIL: outputs exe savetmp namedb: outputs.ld1_args PASS: outputs exe savetmp namedb: outputs.exe FAIL: outputs exe savetmp namedb: extra outputs.gcc_args PASS: outputs exe savetmp namedb: std out PASS: outputs exe savetmp named2: outputs-outputs-1.i PASS: outputs exe savetmp named2: outputs-outputs-1.s PASS: outputs exe savetmp named2: outputs-outputs-1.o PASS: outputs exe savetmp named2: outputs-outputs-2.i PASS: outputs exe savetmp named2: outputs-outputs-2.s PASS: outputs exe savetmp named2: outputs-outputs-2.o PASS: outputs exe savetmp named2: outputs.args.0 FAIL: outputs exe savetmp named2: outputs.ld1_args PASS: outputs exe savetmp named2: outputs.exe FAIL: outputs exe savetmp named2: extra outputs.gcc_args PASS: outputs exe savetmp named2: std out PASS: outputs exe savetmp named2: outputs-outputs-1.i PASS: outputs exe savetmp named2: outputs-outputs-1.s PASS: outputs exe savetmp named2: outputs-outputs-1.o PASS: outputs exe savetmp named2: outputs-outputs-2.i PASS: outputs exe savetmp named2: outputs-outputs-2.s PASS: outputs exe savetmp named2: outputs-outputs-2.o PASS: outputs exe savetmp named2: outputs-args.0 PASS: outputs exe savetmp named2: outputs-args.1 PASS: outputs exe savetmp named2: outputs.args.2 FAIL: outputs exe savetmp named2: outputs.ld1_args PASS: outputs exe savetmp named2: outputs.exe FAIL: outputs exe savetmp named2: extra outputs.gcc_args PASS: outputs exe savetmp named2: std out PASS: outputs exe savetmp named2: outputs-outputs-1.i PASS: outputs exe savetmp named2: outputs-outputs-1.s PASS: outputs exe savetmp named2: outputs-outputs-1.o PASS: outputs exe savetmp named2: outputs-outputs-2.i PASS: outputs exe savetmp named2: outputs-outputs-2.s PASS: outputs exe savetmp named2: outputs-outputs-2.o PASS: outputs exe savetmp named2: outputs-args.0 PASS: outputs exe savetmp named2: outputs-args.1 PASS: outputs exe savetmp named2: outputs.args.2 PASS: outputs exe savetmp named2: outputs.args.3 FAIL: outputs exe savetmp named2: outputs.ld1_args PASS: outputs exe savetmp named2: outputs.exe FAIL: outputs exe savetmp named2: extra outputs.gcc_args PASS: outputs exe savetmp named2: std out
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #17 from Bernd Edlinger --- (In reply to David Edelsohn from comment #15) > I'm seeing a number of new testsuite failures on AIX after the > collect2/testsuite change. Do you want a separate PR or use this as well? > > They are: > > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: extra the extra is maybe a different file that gets created. Can you look up in the log file, the line directly after the FAIL which files you see there?
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-January ||/562967.html --- Comment #16 from Rainer Orth --- (In reply to David Edelsohn from comment #15) > I'm seeing a number of new testsuite failures on AIX after the > collect2/testsuite change. Do you want a separate PR or use this as well? Given that we already identified two different issues here (parallel make check and linker support for response files), I suggest we keep everything together for now. > They are: > > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: outputs.ld1_args > FAIL: outputs exe savetmp named2: outputs.ld1_args > FAIL: outputs exe savetmp named2: outputs.ld1_args > FAIL: outputs exe savetmp namedb: extra > FAIL: outputs exe savetmp namedb: outputs.ld1_args > > I notice that Rainer mentions some ld1_args failures for these same > testcases in Comment #6. Right. I assume you're using the the native AIX linker and it doesn't support response files? In that case, the *.ld1_args failures are the same issue I'm seeing with Solaris ld (which is in the same boat in this respect).
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-01-07 --- Comment #15 from David Edelsohn --- I'm seeing a number of new testsuite failures on AIX after the collect2/testsuite change. Do you want a separate PR or use this as well? They are: FAIL: outputs exe savetmp named2: extra FAIL: outputs exe savetmp named2: extra FAIL: outputs exe savetmp named2: extra FAIL: outputs exe savetmp named2: outputs.ld1_args FAIL: outputs exe savetmp named2: outputs.ld1_args FAIL: outputs exe savetmp named2: outputs.ld1_args FAIL: outputs exe savetmp namedb: extra FAIL: outputs exe savetmp namedb: outputs.ld1_args I notice that Rainer mentions some ld1_args failures for these same testcases in Comment #6.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Bernd Edlinger --- > could someone try this for me? This worked fine for me, both with -j2 and without. Thanks.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #13 from Bernd Edlinger ---
could someone try this for me?
diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp
b/gcc/testsuite/gcc.misc-tests
index 80d4b61..7cd755c 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -67,6 +67,9 @@ if {[board_info $dest exists output_format]} {
append link_options " additional_flags=-Wl,-oformat,[board_info $dest
output_fo
}
+# avoid influence from jobserver
+unsetenv MAKEFLAGS
+
# For the test named TEST, run the compiler with SOURCES and OPTS, and
# look in DIRS for OUTPUTS. SOURCES is a list of suffixes for source
# files starting with $b in $srcdir/$subdir, OPTS is a string with
Thanks!
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #12 from Bernd Edlinger ---
Aah, now I see (lto-wrapper.c):
if (parallel)
{
fprintf (mstream, "%s:\n\t@%s ", output_name, new_argv[0]);
for (j = 1; new_argv[j] != NULL; ++j)
fprintf (mstream, " '%s'", new_argv[j]);
fprintf (mstream, "\n");
/* If we are not preserving the ltrans input files then
truncate them as soon as we have processed it. This
reduces temporary disk-space usage. */
if (! save_temps)
fprintf (mstream, "\t@-touch -r %s %s.tem > /dev/null 2>&1 "
"&& mv %s.tem %s\n",
input_name, input_name, input_name, input_name);
}
else
{
char argsuffix[sizeof (DUMPBASE_SUFFIX) + 1];
if (save_temps)
snprintf (argsuffix, sizeof (DUMPBASE_SUFFIX),
"ltrans%u.ltrans_args", i);
fork_execute (new_argv[0], CONST_CAST (char **, new_argv),
true, save_temps ? argsuffix : NULL);
maybe_unlink (input_name);
}
IF parallel is true, the "ltrans%u.ltrans_args and the "ltrans%u.ltrans_args.0
is obviously not taken.
AND on my system I use a gnu-make
that does not always pass the jobserver file ids to the sub-makes.
Only when "$(MAKE)" is used.
I already thought about adding something like "#$(MAKE)" somewhere
to un-break that
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Bernd Edlinger --- > I tried to bootstrap with > GNU ld (GNU Binutils for Ubuntu) 2.24 > > but still cannot reproduce the reported > failure ltrans0.ltrans_args / ltrans0.ltrans_args.0 > > I really wonder what makes the difference. I've tried on a x86_64-pc-linux-gnu build with a self-compiled GNU ld 2.35: no failure with or without -jN. It must be some sort of tool issue, but I don't have the slightest idea what it might be.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #10 from Bernd Edlinger --- I tried to bootstrap with GNU ld (GNU Binutils for Ubuntu) 2.24 but still cannot reproduce the reported failure ltrans0.ltrans_args / ltrans0.ltrans_args.0 I really wonder what makes the difference.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> The arguments are in a response-file: @outputs.ld1_args >> maybe that looks different for you? > > It certainly does (Solaris ld doesn't support -v, so no -Wl,-v here), as > I found in collect2.c (do_link): the @ files are only passed if > HAVE_GNU_LD and at_file_supplied. The former is certainly false for > Solaris ld, so we'll certainly see no outputs.ld1_args passed. I've now dug a bit further and found two things: In addition to the previous bootstraps with Solaris ld, I've run another one with GNU ld. As expected, the outputs.ld1_args FAILs are gone since, unlike Solaris ld, GNU ld *does* support response files. On a hunch, I've also run $ make -j2 check-gcc RUNTESTFLAGS=outputs.exp (with gld in use, but this doesn't make a difference as I mentioned) and lo, the previous FAILs now show up that didn't in a sequential make check-gcc.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Bernd Edlinger --- > when you leave just one of those tests, you can > get somewhat more verbose output by using something like that: > > make check-gcc-c RUNTESTFLAGS="--target_board=unix/-v/-Wl,-v outputs.exp" I've just run the corresponding xgcc invocation manually. > you should see where the collect-ld is invoked: > > collect2 version 11.0.0 20210105 (experimental)^M > /home/ed/gnu/gcc-build/gcc/collect-ld @outputs.ld1_args^M > GNU ld (GNU Binutils) 2.35.1^M > > The arguments are in a response-file: @outputs.ld1_args > maybe that looks different for you? It certainly does (Solaris ld doesn't support -v, so no -Wl,-v here), as I found in collect2.c (do_link): the @ files are only passed if HAVE_GNU_LD and at_file_supplied. The former is certainly false for Solaris ld, so we'll certainly see no outputs.ld1_args passed.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #7 from Bernd Edlinger --- when you leave just one of those tests, you can get somewhat more verbose output by using something like that: make check-gcc-c RUNTESTFLAGS="--target_board=unix/-v/-Wl,-v outputs.exp" you should see where the collect-ld is invoked: collect2 version 11.0.0 20210105 (experimental)^M /home/ed/gnu/gcc-build/gcc/collect-ld @outputs.ld1_args^M GNU ld (GNU Binutils) 2.35.1^M The arguments are in a response-file: @outputs.ld1_args maybe that looks different for you?
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Bernd Edlinger --- > It is interesting that some tests are reported failing > on the x86_64-pc-linux-gnu platform that I also use. Right: it's not the platform per se but something about it or the tools used. > I really wonder what prevents these failures for me. The weird thing is that I've just run runtest --tool gcc outputs.exp in one of yesterday's build directories (build are currently running) and the only failures from outputs.exp are FAIL: outputs exe savetmp namedb: outputs.ld1_args FAIL: outputs exe savetmp named2: outputs.ld1_args FAIL: outputs exe savetmp named2: outputs.ld1_args FAIL: outputs exe savetmp named2: outputs.ld1_args Every other failure has vanished. > Could you say if there the outputs.exp test case > produces additional temp files in the /tmp folder when it fails? No: the only things left in /tmp from previous builds are from libgo make check.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #5 from Tobias Burnus --- (In reply to Rainer Orth from comment #0) > * Despite -save-temps, the lto-wrapper input objects are removed at the end, > so I cannot manually rerun lto-wrapper to investigate. You could modify gcc/testsuite/gcc.misc-tests/outputs.exp to: * only run a single 'outest' which is failing (e.g. comment all 'outest' lines but 'outputs lto st mult dumpdir named') * Remove 'file delete' in 'proc outest' Run the test and check which files are under /tmp + test directory - and compare it with the failing while (which checks with 'file exists' or using 'glob').
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #4 from Bernd Edlinger --- It is interesting that some tests are reported failing on the x86_64-pc-linux-gnu platform that I also use. I really wonder what prevents these failures for me. Could you say if there the outputs.exp test case produces additional temp files in the /tmp folder when it fails?
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Bernd Edlinger --- > Unfortunately I cannot reproduce. > > I configured like this: > ../gcc-trunk/configure --prefix=/home/ed/gnu/install --enable-languages=all > > and use > GNU ld (GNU Binutils) 2.35.1 As I mentioned, it reliably FAILs on Solaris with both the native linker and GNU ld, and in some configurations on Linux, Darwin, and FreeBSD. I don't know where the common ground between those configs is, and THB have absolutely no idea what is happening here. This LTO stuff remains a mystery to me.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #2 from Bernd Edlinger --- Unfortunately I cannot reproduce. I configured like this: ../gcc-trunk/configure --prefix=/home/ed/gnu/install --enable-languages=all and use GNU ld (GNU Binutils) 2.35.1
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Rainer Orth changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||edlinger at gcc dot gnu.org --- Comment #1 from Rainer Orth --- After commit e9f8a554efe497dd46b8953e580d65e5c023e50c Author: Bernd Edlinger Date: Sun Dec 13 08:24:57 2020 +0100 Fix -save-temp leaking lto files in /tmp I see a massive increase of FAILs on i386-pc-solaris2.11 and sparc-sun-solaris2.11, although similar reports can be found on gcc-testresults for aarch64-suse-linux-gnu, i686-pc-linux-gnu, x86_64-pc-linux-gnu: +FAIL: outputs exe savetmp named2: outputs.ld1_args +FAIL: outputs exe savetmp named2: outputs.ld1_args +FAIL: outputs exe savetmp named2: outputs.ld1_args +FAIL: outputs exe savetmp namedb: outputs.ld1_args +FAIL: outputs lto st mult dumpdir empty dumpbase named: dir/outputs-1.ltrans0.ltrans.args.0 FAIL: outputs lto st mult dumpdir empty dumpbase named: dir/outputs-1.ltrans0.ltrans_args +FAIL: outputs lto st mult dumpdir named: dir/outputs-ltrans0.ltrans.args.0 FAIL: outputs lto st mult dumpdir named: dir/outputs-ltrans0.ltrans_args +FAIL: outputs lto st mult empty dumpbase namedb: dir/outputs.ltrans0.ltrans.args.0 +FAIL: outputs lto st mult empty dumpbase unnamed: a.ltrans0.ltrans.args.0 +FAIL: outputs lto st mult namedb: dir/outputs.ltrans0.ltrans.args.0 +FAIL: outputs lto st mult unnamed: a.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing dumpdir empty dumpbase named: dir/outputs-0.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing dumpdir named: dir/outputs-ltrans0.ltrans.args.0 +FAIL: outputs lto st sing empty dumpbase namedb: dir/outputs.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing empty dumpbase unnamed: a.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing namedb: dir/outputs.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing unnamed: a.ltrans0.ltrans.args.0
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
