On 12/31/2010 01:07 PM, Jie Zhang wrote:
I just found a behavior change of driver on multiple input assembly
files. Previously (before r164357), for the command line
gcc -o t t1.s t2.s
, the driver will call assembler twice, once for t1.s and once for t2.s.
After r164357, the driver will only call assembler once for t1.s and
t2.s. Then if t1.s and t2.s have same symbol, assembler will report an
error, like:
t2.s: Assembler messages:
t2.s:1: Error: symbol `.L1' is already defined
I read the discussion on the mailing list starting by the patch email of
r164357.[1] It seems that this behavior change is not the intention of
that patch. And I think the previous behavior is more useful than the
current behavior. So it's good to restore the previous behavior, isn't?
For a minimal fix, I propose to change combinable fields of assembly
languages in default_compilers[] to 0. See the attached patch
"gcc-not-combine-assembly-inputs.diff". I don't know why the combinable
fields were set to 1 when --combine option was introduced. There is no
explanation about that in that patch email.[2] Does anyone still remember?
For an aggressive fix, how about removing the combinable field from
"struct compiler"? If we change combinable fields of assembly languages
in default_compilers[] to 0, only ".go" and "@cpp-output" set combinable
to 1. I don't see any reason for difference between "@cpp-output" and
".i". So if we can set combinable to 0 for ".go", we have 0 for all
compilers in default_compilers[], thus we can remove that field. Is
there a reason to set 1 for ".go"?
I also attached the aggressive patch "gcc-remove-combinable-field.diff".
Either patch is not tested. Which way should we go?
The minimal fix has no regressions. But the aggressive one has a lot of
regressions.
[1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html
[2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html
Regards,
--
Jie Zhang
