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? -- H.J.
