On 14/09/2020 20:04, Wilco Dijkstra wrote: > Hi Richard, > >> On 14/09/2020 15:19, Wilco Dijkstra wrote: >>> The --with-cpu/--with-arch configure option processing not only checks >>> valid arguments >>> but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This >>> isn't used >>> however since a --with-cpu is translated into a -mcpu option which is >>> processed as if >>> written on the command-line (so TARGET_CPU_DEFAULT is never accessed). >>> >>> So remove all the complex processing and bitmask, and just validate the >>> option. >>> Fix a bug that always reports valid architecture extensions as invalid. As >>> a result >>> the CPU processing in aarch64.c can be simplified. >> >> Doesn't this change the default behaviour if cc1 is run directly? I'm >> not saying this is the wrong thing to do (I think we rely on this in the >> arm port), but I just want to understand by what you mean when you say >> 'never used'. > > Yes it does change default behaviour of cc1, but I don't think it does matter. > I bootstrapped and passed regress with an assert to verify TARGET_CPU_DEFAULT > is never accessed if there is a --with-cpu configure option. So using cc1 > directly > is not standard practice (and I believe most other configuration options are > not > baked into cc1 either). >
Users generally don't (or at least, shouldn't). Developers, however, have traditionally been used to firing up cc1 under gdb and then expecting the key defaults to be unchanged if they weren't on the original command line (ie they could pretty much paste the options from the original gcc invocation into the back-end compiler and expect the same output). > How do we rely on it in the Arm port? That doesn't sound right... We don't, which is why I don't think this is vital, but I wanted to understand what you meant with your claim that this was never used. > > Cheers, > Wilco > R.
