On Sun, Jan 2, 2011 at 5:41 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Sun, Jan 2, 2011 at 8:37 AM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> On Sun, Jan 2, 2011 at 5:31 PM, 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? >> >> I don't know. The driver is quite a mess. (but it does work, and I didn't >> try your patch, it just looks that the above is incomplete - maybe have_o >> is set to a.out?) >> > > No, it doesn't. See: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 > > That is how I found the problem.
Hm, well. I left the combine_inputs thing in as LTO re-uses it. Your small patch removing have_o || is ok I guess. Thanks, Richard. > > -- > H.J. >
