On Wed, 19 Aug 2020, Richard Earnshaw wrote: > > That said I'm of course happy to keep the ARM overrides if you consider > > them still necessary in the context of the generic change made. Let me > > know what you prefer, and if required, I will submit v3 with the ARM > > pieces removed. [...] > So you've made a change to the Arm target, but not tested it. And > what's more didn't even bother to mention that fact.
Well, I explicitly named the targets that have been tested, and it was clear ARM wasn't among them. I admit I forgot to cc ARM maintainers with v1, which I apologise for, and which mistake Richard B. has kindly corrected for me. Nobody's perfect. > If you make changes, you need to test them, particularly when there are > likely to be target-specific implications. If you can't test yourself > then you need to make that very clear in your submission. > > There are Arm targets in the testfarm, so it's not really an excuse for > not doing testing. I think it's the port maintainer's role to verify their pet target; that's what I have been doing on the binutils/GDB side when I was an active port maintainer. I did not require people to bend backwards and appreciated their effort to make the toolchain better. It takes a maintainer maybe a couple of seconds to pull a change and push it through their readily available automated verification system they surely have, while it may be a days' effort for someone who has to figure out all the details, choose all the configuration options required, avoid pitfalls, keep rebuilding until all is sound, etc. And then repeat that for every new target possibly affected. As the change was intended to address an issue observed with RISC-V targets the ARM pieces are not needed. I've sent v3 now, which keeps ARM-specific parts intact so that you won't have to be involved or otherwise spend your time on it. You're free to pick the parts removed of course and do whatever you want with them according to the GNU GPL and keeping in mind my copyright assignment with FSF. NB it is actually the case that when the original ARM fix/workaround was submitted that has introduced LIB2_DIVMOD_EXCEPTION_FLAGS, the failure, clearly not ARM-specific, should have been properly analysed and a general solution like mine proposed so as to fix all targets that use these libcalls, rather than taking care of your own business only, and making a local fix for ARM and letting other target developers rediscover the same issue. I regret now that I bothered touching the ARM part; I'll follow the example from the paragraph above and in the future I will only take care of my business, avoid going the extra mile in the future where it could only cause me trouble and give no benefit. Thank you for your review anyway, it has taught me something. Maciej
