On Sun, Jan 2, 2011 at 6:52 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Sun, Jan 2, 2011 at 3:03 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>> On Sun, Jan 2, 2011 at 2:05 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Sun, Jan 2, 2011 at 1:18 PM, Ian Lance Taylor <i...@google.com> wrote:
>>>> Richard Guenther <richard.guent...@gmail.com> writes:
>>>>
>>>>> On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor <i...@google.com> wrote:
>>>>>> Richard Guenther <richard.guent...@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...@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...@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
--
H.J.
