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).
Richard.
> for (i = 0; (int) i < n_infiles; i++)
> {
>
