On Sun, Jan 2, 2011 at 10: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.
That was another proposed patch. I wondered if that would break gcc -o t -flto -flto-partition=none t1.c t2.c -save-temps -v (repeating the generation of t1.s, we overwrite this with lto1 output ...) gcc -o t -flto -flto-partition=none t1.s t2.s where t1.s and t2.s contain LTO bytecode from the -save-temps invocation (thus the driver is expected to assemble both files and then combine the resulting objects). flag_wpa is not set at any time for -flto-partition=none (only flag_lto is, but that is set a well at compile-time). trying the above it doesn't seem to work, we exit with xgcc: fatal error: cannot specify -o with -c, -S or -E with multiple files because flag_wpa isn't set now either. xgcc invoked with -xlto -c -B . -flto-partition=none -v -save-temps -mtune=generic -march=pentiumpro -dumpdir ./ -dumpbase t -o /tmp/ccZPZLA0.lto.o t1.o t2.o So that's sth to fix as well (HJs change is the cause for the appearant problem but before his patch we tried to combine the .s files resulting in assembler errors). So maybe the patch removing combinable .s is the better fix after all. >>> 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. Interesting. Do we have a testcase that is now broken? It seems to me that gcgo should force combining sources, even if no output file is given (and a.out is the default output). Thanks, Richard.
