Loop with Cortex-R, -mf3, and DWARF debug leads to assembler error "defined differently in each pass"

Several pieces have to come together for this problem to happen. --opt_for_speed needs to be 3 or greater; thus a workaround is to reduce optimization to --opt_for_speed=1. The source code has to have one or more IFs, followed by a nested scope that isn't part of a compound statement and defines local variables, followed by a loop. Another workaround is thus to move the local variable definitions to the enclosing scope. (Another that works for the given test case but isn't necessarily general is to initialise all those local variables, where they're defined in the nested scope.) Normal debug info must be present; a final workaround is therefore to use --symdebug:none to suppress debug info. Of course, that makes debugging difficult.

The assembler will become confused when presented with the sequence of a .align, an instruction that is smaller than the specified alignment, a label, and the DWARF DW_AT_low_pc directive. Because of the way it processes alignments and labels in different passes, it will conclude that the label was defined with two different values, and report an error. This sequence is not something a human asm programmer would write. It arises from compiling a particular shape of statements in a loop, with a particular set of compilation options, to position the label and the .align and the directive. See the Workaround, which also indicates how to modify the code or compiler options to avoid this bug.