[Bug testsuite/98225] New: gcc.misc-tests/outputs.exp ltrans_args tests FAIL

[Bug testsuite/98225] New: gcc.misc-tests/outputs.exp ltrans_args tests FAIL

[ro at gcc dot gnu.org]

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

            Bug ID: 98225
           Summary: gcc.misc-tests/outputs.exp ltrans_args tests FAIL
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

Between 20201020 (5d53ec27015b916640171e891870adf2c6fdfd4c) and 20201021
(c8f795cac6a1325bc6bcba3f47b7d04cb790400c),
a couple of gcc.misc-tests/outputs.exp tests began to FAIL:

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
FAIL: outputs lto st mult empty dumpbase unnamed: a.ltrans0.ltrans_args
FAIL: outputs lto st mult namedb: dir/outputs.ltrans0.ltrans_args
FAIL: outputs lto st mult unnamed: a.ltrans0.ltrans_args
FAIL: outputs lto st sing dumpdir empty dumpbase named:
dir/outputs-0.ltrans0.ltrans_args
FAIL: outputs lto st sing dumpdir named: dir/outputs-ltrans0.ltrans_args
FAIL: outputs lto st sing empty dumpbase namedb:
dir/outputs.ltrans0.ltrans_args
FAIL: outputs lto st sing empty dumpbase unnamed: a.ltrans0.ltrans_args
FAIL: outputs lto st sing namedb: dir/outputs.ltrans0.ltrans

I'm seeing this on both Solaris/sparc and x86, 32 and 64-bit, both with the
native
linker and with GNU ld (thus without and with the lto-plugin).  There are also
gcc-testresults reports for all sorts of targets: i686-pc-linux-gnu,
aarch64-suse-linux-gnu, riscv64-suse-linux-gnu, x86_64-pc-linux-gnu,
x86_64-unknown-freebsd11.4, x86_64-apple-darwin16.

I've tried to have a look, but failed for all sorts of reasons:

* When running the corresponding compilation with -v, -v isn't passed on to
  lto-wrapper.
* Despite -save-temps, the lto-wrapper input objects are removed at the end,
  so I cannot manually rerun lto-wrapper to investigate.

I guess this would be way easier for someone familiar with the code to
investigate.

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |edlinger at gcc dot gnu.org

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> ---
After

commit e9f8a554efe497dd46b8953e580d65e5c023e50c
Author: Bernd Edlinger <bernd.edlinger@hotmail.de>
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

[edlinger at gcc dot gnu.org]

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

--- Comment #2 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #2 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
> 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

[edlinger at gcc dot gnu.org]

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

--- Comment #4 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
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

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #4 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
> 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

[edlinger at gcc dot gnu.org]

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

--- Comment #7 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #7 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
> 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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> 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

[edlinger at gcc dot gnu.org]

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

--- Comment #10 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #10 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
> 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

[edlinger at gcc dot gnu.org]

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

--- Comment #12 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
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

[edlinger at gcc dot gnu.org]

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

--- Comment #13 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #13 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
> 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

[dje at gcc dot gnu.org]

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

David Edelsohn <dje at gcc dot gnu.org> 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 <dje at gcc dot gnu.org> ---
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

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2021-January
                   |                            |/562967.html

--- Comment #16 from Rainer Orth <ro at gcc dot gnu.org> ---
(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

[edlinger at gcc dot gnu.org]

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

--- Comment #17 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
(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

[dje at gcc dot gnu.org]

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

--- Comment #18 from David Edelsohn <dje at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Bernd Edlinger <edlinger@gcc.gnu.org>:

https://gcc.gnu.org/g:6ebf79fcd4cfb43353e6a000f700b07295e78026

commit r11-6588-g6ebf79fcd4cfb43353e6a000f700b07295e78026
Author: Bernd Edlinger <bernd.edlinger@hotmail.de>
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  <bernd.edlinger@hotmail.de>

            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

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger <edlinger at gcc dot gnu.org> changed:

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

--- Comment #20 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
should be fixed now.

Thanks!