On 07/20/2018 09:39 AM, Tamar Christina wrote: >> >> On 07/20/2018 05:03 AM, Tamar Christina wrote: >>>> Understood. Thanks for verifying. I wonder if we could just bury >>>> this entirely in the aarch64 config files and not expose the default into >> params.def? >>>> >>> >>> Burying it in config.gcc isn't ideal because if your C runtime is >>> configurable (like uClibc) it means you have to go and modify this >>> file every time you change something. If the argument is against >>> having these defines in the params and not the configure flag itself then I >> can just have an aarch64 specific configure flag and just use the created >> define directly in the AArch64 back-end. >> Not config.gcc, but in a .h/.c file for the target. >> >> If we leave the generic option, but override the default in the target files. >> Would that work? > > So leaving the generic configure option? Yes that would work too. The only > downside is > that if we have want to do any validation on the value at configure time it > would need to > be manually kept in sync with those in params.def. Or we'd just have to not > do any checking > at configure time. This would mean you can get to the end of your build and > only when you > try to use the compiler would it complain. > > Both aren't a real deal breaker to me. > > Shall I then just leave the configure flag but remove the params plumbing? Yea, I think any sanity check essentially has to move to when the compiler runs. We can always return to param removal at a later point.
Can you post an updated patch? Note I'm on PTO starting Wed for a week. If you post it tomorrow I'll try to take a look before I disappear. jeff
