.arch clobbers .cpu in assembler

[John Breitenbach <breiten at lexmark dot com>]

Hi,
  I'm trying to port some marvell-pj4 support that originated back in 
binutils-2.19.  My understanding is that this was done by CodeSourcery 
back in 2008 or 2009, and for whatever reason, wasn't ever mainlined in 
binutils.  I'm trying to make it work with binutils-2.31.1 + gcc-8.2 but 
am running into some problems because gcc-8 has begun to emit .arch and 
.arch_extension directives.

When compiling with gcc-8.2 and -mcpu=marvell-pj4, I see gcc adding the 
following to the generated assembly file (compiling with -save-temps)

   .cpu marvell-pj4
   .arch armv7-a
   .arch_extension div

The .arch and .arch_extension directives are new since trying to use 
gcc-8.2, (i.e. weren't in gcc-7.3 or any earlier versions that I've 
used)  And when configured for other cpus, I also now see a .arch and a 
.arch_extension directive.

My problem is that it appears that the processing of the .arch directive 
is completely clobbering everything that I recorded from the earlier 
.cpu directive.  Thus, when it comes to processing the unique 
instructions in the pj4 or encoding a divide instruction properly, 
there's no record than I'm assembling for a pj4 in the "cpu_variant" 
structure.

I see this code in s_arm_arch() which gets invoked when finding the 
matching architecture in arm_archs[]
    selected_ext = arm_arch_none;
    selected_cpu = selected_arch;
    strcpy (selected_cpu_name, opt->name);
    ARM_MERGE_FEATURE_SETS (cpu_variant, selected_cpu, selected_fpu);

These globals in tc-arm.c (selected_ext, selected_cpu and cpu_variant) 
appear to be the only artifacts from the .cpu directive.  cpu_variant's 
prior setting is completely clobbered.
Similarly, when processing ".arch_extension", we clobber both 
selected_cpu and cpu_variant, eliminating any evidence of the earlier 
.cpu directive.

It doesn't seem like the .arch or .arch_extension should clobber the 
.cpu ... as the .cpu should imply an arch and any extensions. From my 
naive perspective, I wonder why gcc would emit them, as .cpu contains 
everything that the assembler should need to know. I haven't explored 
any options for suppressing those directive from gcc's output.

I'd really like to make this work with the latest tools.  Its been an 
easy port for about 10 years and at least 5 compiler/binutils 
combinations and I'd like to keep it going for at least one more.  So 
thanks in advance for any suggestions. Also, I can provide more details 
as needed.

I do see that the -mcpu=marvell-pj4 command line option sets 
mcpu_cpu_opt and mcpu_ext_opt, but this doesn't make its way into 
cpu_variant.

Regards,
John Breitenbach