Re: Behavior change of driver on multiple input assembly files

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sun, Jan 2, 2011 at 8:31 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Jan 2, 2011 at 8:03 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang <jie@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.