On Sun, Jan 02, 2011 at 09:04:06PM -0800, H.J. Lu wrote:
> On Sun, Jan 2, 2...@6:52 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> > On Sun, Jan 2, 2...@3:03 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> >> On Sun, Jan 2, 2...@2:05 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> >>> On Sun, Jan 2, 2...@1:18 PM, Ian Lance Taylor <i...@google.com> wrote:
> >>>> Richard Guenther <richard.guent...@gmail.com> writes:
> >>>>
> >>>>> On Sun, Jan 2, 2...@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 g...@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
No regressions on x86_64-apple-darwin10...
http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00181.html
>
>
> --
> H.J.
