Behavior change of driver on multiple input assembly files

[Jie Zhang]

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