On 24/05/17 17:03, Jim Wilson wrote: > On Wed, May 24, 2017 at 8:17 AM, Richard Earnshaw (lists) > <richard.earns...@arm.com> wrote: >> On 24/05/17 15:18, Jim Wilson wrote: >>> On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists) >>> <richard.earns...@arm.com> wrote: >>>> OK. does this need to go in the gcc-8 changes file? >>> >>> Falkor hasn't shipped yet. I'm dropping features that only existed in >>> preproduction NDA hardware, so there isn't anything end user visible, >>> and hence I don't think that it needs to be in the release notes. >>> >>> Jim >>> >> >> Fair enough, so what about a minimal back-port to GCC-7 that just >> disables the CPU name for aarch32? > > Not sure how to do that. If I remove the arm-cpus.in entry, then 5 > files get automatically regenerated. That leaves us with a few minor > inconsistencies in specs handling and multilibs which are harmless but > we may as well fix anyways. The only part of the patch that is > optional if the part which moves the qdf24xx_extra_costs array from > the arm dir to the aarch64 dir. So the minimal patch ends up being > half the size of the original patch, changing 9 of the original 11 > files, which isn't very minimal. > > Another option might be to just remove the documentation and leave the > code in, i.e. only apply the doc/invoke.texi patch. That would be a > small and safe patch. > > Jim >
Certainly we should remove it from the documentation. That might be the best idea. I don't really regard the size of the changes to the auto-generated code as being relevant - if we put the generated code directly in the build directory and treated it like we do the output from gen*.c, then those changes would never be even noticed. R.