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