Compiler/ARM-CGT: Code Composer Studio™ forum

I am working with the compiler development team to get more details on these issues.  These details are likely to come out one issue at a time, over the next few days.

Thanks and regards,

-George

Paulo,

I've updated the entry for below:

CODEGEN-4084 assembler errors with bogus .iendfunc asm directive when using --c_src_interlist

With this additional information:

Description:

The codegen emits a .iendfunc assembly directive without position (psn) info when option --c_src_interlist is used.

Reproduce with below options for 18.12.0.LTS (and -ooff -o0,1,2,3,4):
armcl -mv7M4 -ss

>> WARNING: Cannot open source file 'NO_PSN_FILE': No such file or directory
"t236.asm", ERROR! at line 154934: [E0002] Illegal mnemonic specified
                .iendfunc
"t236.asm", ERROR! at line 155034: [E0002] Illegal mnemonic specified
                .iendfunc
"t236.asm", ERROR! at line 155134: [E0002] Illegal mnemonic specified
                .iendfunc
3 Assembly Errors, No Assembly Warnings
Errors in Source - Assembler Aborted

Workaround (if you see above assembly errors):

Do not use option --c_src_interlist (-ss)

Regards,
Greg

Greg,

One further question:

Is a possible workaround to use the --src_interlist (-s) option instead?

Regards,

Paulo.

Paulo,

Excellent question. Yes I just tested and using --src_interlist avoids the assembler 

I'll update the bug entry.

Thanks
Greg

With regards to SDSCM00052849 Compiler and assembler disagree on format for IT instruction, the content of the test case causing this error is below and it occurs when compiled with the compiler options: -mv7R4 --code_state=16.  

void testfunction (void)
{
    unsigned int saved_cpsr;

    /* save and disable IRQs locally */
    saved_cpsr = (unsigned int)_disable_IRQ();
  
    /* do some critical section handling here */
    
    /* restore IRQs */
    if ((saved_cpsr & 0x00000080UL) == 0U)
    {
        (void)_enable_IRQ();
    }
}

Anna, thanks for your reply,

As you can see from my original question, in order to fully understand any limitation/s that relate to this defect, I would appreciate if you can provide me with additional information/context to that currently documented in the related thread: e2e.ti.com/support/development_tools/compiler/f/343/t/503292.

I was able to observe the defect using the test case you have repeated above.

However,  I only observed the defect when the following specific options were selected:

--opt_level=2

--opt_for_speed=3

--code_state=16

Questions:

1) Can you document in the defect report the specific option or combination of options that result in this defect?

For instance do you know whether the defect will only occur when --code_state=16 ?

2) Is optimisation a contributory factor?

3) Will this defect only occur when combined with the compiler intrinsics: _disable_IRQ &/or _enable_IRQ?

Any additional information will be very much appreciated.

Regards,

Paulo.

Sorry, Paulo, I listed the minimal set of options with which I reproduced the bug but forgot about the default optimization level being set to 2.  So I can confirm that I only see this error when the optimization level is 2 or higher.  I only see it when --code_state=16 is used.  I do not see that --opt_for_speed is relevant, any value for that does not alter the presence of the bug.  The silicon version/thumb mode also matters because the intrinsics have to be available.

This appears to be a bug related to the use of the intrinsics when optimization is enabled at O2 or higher.  I cannot guarantee that without analyzing the bug fully, but as we dispositioned this as low priority, I have no plans to do so.  Perhaps you could explain your concern in this issue further.

Thanks,

Anna

Anna, thanks for the additional information.

To explain my concern:

For any safety critical software development, open defects relating to the compiler are the subject of an impact assessment in order that any limitation/s are fully understand and documented.

In this case my opinion was that the defect report was lacking sufficient information to make a judgement.

The report itself contained little information other than a title which on its own sounds quite serious: "Compiler and assembler disagree on format for IT instruction".

The related E2E thread did provide a test case but contained no detail as to whether the defect could ONLY occur with a specific combination of options.

This left me in need of additional information.

Regards,

Paulo.

Ok, I spent a little more time investigating this issue and updated the external record.  It may take a while to sync to the external bug database.

There is an error in the generated assembly as the CPSIE instruction is not allowed inside an IT block.  Therefore the assembler warning is incorrect as the problem is not a missing condition code.  The test case compiled at --opt_level=2 and with --codeg-state=16 generates the following assembly:

IT CC ; 
CPSIE i

This is definitely coming from the use of the enable/disable IRQ intrinsics combined with optimization.  The branch should not be optimized away into an IT block because the CPSIE instruction is not allowed inside one.  The optimization of the branch into an IT block, and the generation of the CPSIE instruction from the intrinsic, are happening separately without knowledge of each other.

Anna, thanks for spending a little more of your time on this,

The level of detail that you have now provided is exactly the kind of description that I was looking for.

Regards,

Paulo.

George,

I am still awaiting a response regarding one of the three defects where I require additional information/context:

CODEGEN-4105 cannot find definition of ">=" operator

I am working on a safety critical software development, therefore all open defects relating to the compiler are the subject of an impact assessment in order that any limitation/s are fully understand and documented.

In this case my opinion is that the defect report lacks sufficient information for me to make this judgement.

Please could you chase this up with the compiler development team.

I have received sufficient information/context regarding the other two defects thanks to Greg and Anna.

Regards,

Paulo.