On Mon, 14 Nov 2016, Matthew Fortune wrote: > At some point in the future we may therefore have to consider backports > of this work to pre-existing GCC releases or a configure time check in > binutils to relax the new checks if GCC does not have the .insn fix. I > don't know how reliable the latter will but it may be possible.
I'm leaning towards adding `-mrelax-branch-checks' or similar GAS and LD options for upcoming binutils 2.28 so that people who need to run a mixed combination of tools or have legacy handcoded assembly code they fear to touch have a way to get away. That will be some burden for some people I'm afraid, but the benefit is potentially problematic code will be identified in the default toolchain configuration right away. Ideally we'd optimise away branches which lead to orphan labels, as obviously there's as little point in executing them as there was in retaining the code path which has been removed from the label on. There is still at least one case though where we cannot just remove the branch by itself as it stands as it's a part of a larger monolithic assembly block, i.e. the MIPS16 `casesi_internal_mips16_<mode>' insn which as I noted in the other submission cannot be split into smaller pieces without a further investigation as to why it causes too much code to be removed. And then there are examples like the assembly gotos I included as test cases where the label has to be retained by definition. I'd expect such cases to be extremely rare in real code though. Maciej
