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. Ian