On Sun, Jan 2, 2011 at 8:31 AM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Sun, Jan 2, 2011 at 8:03 AM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>> On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang <j...@codesourcery.com> wrote: >>>> On 12/31/2010 01:07 PM, Jie Zhang wrote: >>>>> >>>>> I just found a behavior change of driver on multiple input assembly >>>>> files. Previously (before r164357), for the command line >>>>> >>>>> gcc -o t t1.s t2.s >>>>> >>>>> , the driver will call assembler twice, once for t1.s and once for t2.s. >>>>> After r164357, the driver will only call assembler once for t1.s and >>>>> t2.s. Then if t1.s and t2.s have same symbol, assembler will report an >>>>> error, like: >>>>> >>>>> t2.s: Assembler messages: >>>>> t2.s:1: Error: symbol `.L1' is already defined >>>>> >>>>> I read the discussion on the mailing list starting by the patch email of >>>>> r164357.[1] It seems that this behavior change is not the intention of >>>>> that patch. And I think the previous behavior is more useful than the >>>>> current behavior. So it's good to restore the previous behavior, isn't? >>>>> >>>>> For a minimal fix, I propose to change combinable fields of assembly >>>>> languages in default_compilers[] to 0. See the attached patch >>>>> "gcc-not-combine-assembly-inputs.diff". I don't know why the combinable >>>>> fields were set to 1 when --combine option was introduced. There is no >>>>> explanation about that in that patch email.[2] Does anyone still remember? >>>>> >>>>> For an aggressive fix, how about removing the combinable field from >>>>> "struct compiler"? If we change combinable fields of assembly languages >>>>> in default_compilers[] to 0, only ".go" and "@cpp-output" set combinable >>>>> to 1. I don't see any reason for difference between "@cpp-output" and >>>>> ".i". So if we can set combinable to 0 for ".go", we have 0 for all >>>>> compilers in default_compilers[], thus we can remove that field. Is >>>>> there a reason to set 1 for ".go"? >>>>> >>>>> I also attached the aggressive patch "gcc-remove-combinable-field.diff". >>>>> Either patch is not tested. Which way should we go? >>>>> >>>> The minimal fix has no regressions. But the aggressive one has a lot of >>>> regressions. >>>> >>>>> [1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html >>>>> [2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html >>>>> >>> >>> I opened: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 >>> >>> This simple patch also works for me. >>> >>> -- >>> H.J. >>> --- >>> diff --git a/gcc/gcc.c b/gcc/gcc.c >>> index 69bf033..0d633a4 100644 >>> --- a/gcc/gcc.c >>> +++ b/gcc/gcc.c >>> @@ -6582,7 +6582,7 @@ warranty; not even for MERCHANTABILITY or >>> FITNESS FOR A PARTICULAR PURPOSE.\n\n" >>> >>> explicit_link_files = XCNEWVEC (char, n_infiles); >>> >>> - combine_inputs = have_o || flag_wpa; >>> + combine_inputs = flag_wpa; >> >> That probably fails with -flto-partition=none (thus, old -flto mode). >> >> Combining .s files might be necessary when continuing a -save-temps >> LTO compile with the assembly output of the compiler (thus assembler >> files with LTO object code). >> > > Well, how does it work without "-o foo", i.e., with the default output, a.out? >
If you can show me a real usage for -save-temps and LTO, I can find a way to make it work. -- H.J.