[EXT_EP-9142] Loop with Cortex-R, -mf3, and DWARF debug leads to assembler error "defined differently in each pass" Created: 09/Nov/18 Updated: 19/Feb/20 Resolved: 09/Nov/18 |
|
| Status: | Fixed |
| Project: | Embedded Software & Tools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Medium |
| Reporter: | TI User | Assignee: | TI User |
| Resolution: | Fixed | Votes: | 0 |
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Product: | Code Generation Tools |
| Internal ID: | CODEGEN-5533 |
| Forum URL: | https://e2e.ti.com/support/tools/ccs/f/81/t/745219 |
| Found In Release: | C6000_8.2.0 C2000_18.1.0.LTS C6000_8.3.0 ARM_18.12.0.LTS PRU_2.3.0 ARM_18.1.0.LTS MSP430_18.1.0.LTS C2000_19.6.0.STS PRU_2.4.0* ARM_19.6.0.STS MSP430_18.12.0.LTS MSP430_19.6.0.STS C2000_18.12.0.LTS |
| Fix In Release: | C2000_18.1.7.LTS ARM_18.12.3.LTS ARM_18.1.7.LTS MSP430_18.12.3.LTS C2000_18.12.3.LTS C2000_19.6.0.STS PRU_2.3.3 PRU_2.4.0* ARM_19.6.0.STS C6000_8.3.4 MSP430_18.1.7.LTS C6000_8.2.7 MSP430_19.6.0.STS |
| Workaround: | 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. |
| Release Notes: | 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. |
| Description |
|
Loop with Cortex-R, -mf3, and DWARF debug leads to assembler error "defined differently in each pass" |