[Bug driver/47480] New: GCC driver names a resolution file after the last argument to the linker

[Bug driver/47480] New: GCC driver names a resolution file after the last argument to the linker

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47480

           Summary: GCC driver names a resolution file after the last
                    argument to the linker
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: trivial
          Priority: P3
         Component: driver
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: d.g.gorbachev@gmail.com


$ echo 'int main(void){}' > main.c
$ gcc -flto main.c -Wl,-s -save-temps
[...]
$ echo *.res
main.res
$ gcc -flto -c main.c
$ gcc -flto main.o -Wl,-s -save-temps
[...]
$ echo *.res
-s.res main.res

It looks ugly...

[Bug driver/47480] GCC driver names a resolution file after the last argument to the linker

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47480

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-27 11:11:43 UTC ---
I thought I improved the situation with

2010-11-30  Richard Guenther  <rguenther@suse.de>

        PR lto/44986
        * gcc.c (main): Use the first input with a compiler as infile
        for link spec processing.

the original intent was to name the resolution file after the linker
output file name (in case of -save-temps, of course), but that is not
readily available.  Nor is it possible to avoid the fancy name
assinging -save-temps does (a tmpfile would be ok as well).  All this
requires adding new spec modifiers - ugh.

Thus,

    -plugin-opt=-fresolution=%u.res \

the %u needs to be replaced with something that is a better fit
in the -save-temps case (which does not exist).

Btw, your testcase produces t.res for me, not -s.res, so I can't confirm
this bug (the 4.5 branch is probably still affected by the original bug).
t isn't the linker output (a.out is).

So, please double-check your GCC version and paste -v output.

[Bug driver/47480] GCC driver names a resolution file after the last argument to the linker

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47480

--- Comment #2 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-01-30 09:22:15 UTC ---
> So, please double-check your GCC version and paste -v output.

Checked recent weekly snapshot:

$ i686-pc-linux-gnu-gcc-4.6.0 -v
Using built-in specs.
COLLECT_GCC=i686-pc-linux-gnu-gcc-4.6.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.6/configure --enable-languages=c,c++
--enable-version-specific-runtime-libs --enable-checking=yes,fold --disable-nls
--disable-shared --disable-bootstrap
Thread model: posix
gcc version 4.6.0 20110129 (experimental) (GCC) 

The bug is still here.

> I thought I improved the situation with
> +	if (infiles[i].incompiler

In this case, there are no files to compile.

> maybe we should just disregard "infiles" with starting '-' here
> (same with -Xlinker).

For example, it will not work with

$ gcc -flto -Wl,--whole-archive,-lfoobar,--no-whole-archive -save-temps

But it's probably something uncommon.

[Bug driver/47480] GCC driver names a resolution file after the last argument to the linker when no input files are present

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47480

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-05-07
            Summary|GCC driver names a          |GCC driver names a
                   |resolution file after the   |resolution file after the
                   |last argument to the linker |last argument to the linker
                   |                            |when no input files are
                   |                            |present
     Ever Confirmed|0                           |1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-07 12:06:30 UTC ---
Hm.  Confirmed.