This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 8:37 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Sun, Jan 2, 2011 at 5:31 PM, 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?
>
> 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.