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 9:04 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Jan 2, 2011 at 6:52 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Sun, Jan 2, 2011 at 3:03 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Sun, Jan 2, 2011 at 2:05 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Sun, Jan 2, 2011 at 1:18 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>>> Richard Guenther <richard.guenther@gmail.com> writes:
>>>>>
>>>>>> On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>>>>> Richard Guenther <richard.guenther@gmail.com> writes:
>>>>>>>
>>>>>>>> Your small patch removing have_o || is ok I guess.
>>>>>>>
>>>>>>> Wait. ?That will change the behaviour of
>>>>>>> ? ?gcc -o foo.o -c f1.c f2.c f3.c
>>>>>>> Is that what we want?
>>>>>>
>>>>>> Does it? ?I don't think so. ?Most of the combine handling was removed by
>>>>>> the patch that caused the regression, so -o and -c doesn't combine anymore
>>>>>> (with multiple sources).
>>>>>
>>>>> Sorry, you're right. ?The difference is that @c has 0 for the combinable
>>>>> field, and @assembler has 1. ?Before H.J.'s change, this worked
>>>>> ? ?gcc -c -o f.o f1.s f2.s
>>>>> After his change, it does not. ?That is probably not a big deal.
>>>>>
>>>>> I wonder why @assembler has 1 for combinable? ?It seems to have been set
>>>>> to 1 when the combinable field was added in 2004-04-05 with -combine.
>>>>> Now that -combine has been removed, if the combinable field for
>>>>> @assembler were 0, it seems to me that H.J.'s problem would also be
>>>>> fixed. ?And it seems to me that it should be 0.
>>>>>
>>>>>
>>>>>>> Also, right now the gccgo driver depends on the -o behaviour to combine
>>>>>>> inputs. ?If that changes, the driver will need to provide some other way
>>>>>>> to let the frontend force inputs to be combined.
>>>>>>
>>>>>> For go it isn't equivalent to do gcgo -c t1.go; gcgo -c t2.go; gcgo t1.o t2.o
>>>>>> compared to gcgo t1.go t2.go?
>>>>>
>>>>> No, it is not. ?All .go input files must be passed to go1 at once.
>>>>> H.J.'s patch has indeed broken gccgo.
>>>>>
>>>>
>>>> Can you try this patch?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> --
>>>> H.J.
>>>> ---
>>>> diff --git a/gcc/gcc.c b/gcc/gcc.c
>>>> index 0d633a4..d0b2c96 100644
>>>> --- a/gcc/gcc.c
>>>> +++ b/gcc/gcc.c
>>>> @@ -6582,7 +6582,20 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A P
>>>> ARTICULAR PURPOSE.\n\n"
>>>>
>>>> ? explicit_link_files = XCNEWVEC (char, n_infiles);
>>>>
>>>> + ?/* Check if we should combine inputs. ?*/
>>>> ? combine_inputs = flag_wpa;
>>>> + ?if (!combine_inputs)
>>>> + ? ?for (i = 1; i < decoded_options_count; i++)
>>>> + ? ? ?{
>>>> + ? ? ? if (decoded_options[i].opt_index == OPT_x)
>>>> + ? ? ? ? {
>>>> + ? ? ? ? ? struct compiler *compiler
>>>> + ? ? ? ? ? ? = lookup_compiler (NULL, 0, decoded_options[i].arg);
>>>> + ? ? ? ? ? if (compiler)
>>>> + ? ? ? ? ? ? combine_inputs = compiler->combinable;
>>>> + ? ? ? ? ? break;
>>>> + ? ? ? ? }
>>>> + ? ? ?}
>>>>
>>>> ? for (i = 0; (int) i < n_infiles; i++)
>>>> ? ? {
>>>>
>>>
>>> This doesn't work for go since -xgo isn't used with gccgo. Is there
>>> a way to tell what the default language is for a gcc driver?
>>>
>>
>> I am testing this patch with all languages on Linux/x86-64.
>>
>>
>> --
>> H.J.
>> ---
>> gcc/
>>
>> 2011-01-02 ?H.J. Lu ?<hongjiu.lu@intel.com>
>>
>> ? ? ? ?PR driver/47137
>> ? ? ? ?* gcc.c (default_language): New.
>> ? ? ? ?(main): Lookup compiler to check if we should combine inputs.
>>
>> ? ? ? ?* gcc.h (default_language): New.
>>
>> gcc/go/
>>
>> 2011-01-02 ?H.J. Lu ?<hongjiu.lu@intel.com>
>>
>> ? ? ? ?PR driver/47137
>> ? ? ? ?* gospec.c (lang_specific_driver): Set default_language if
>> ? ? ? ?needed.
>>
>
> Here is the result:
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00160.html
>

I reverted my patch for now.


-- 
H.J.