This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CLA Compiler generating wrong code with __mmaxf32, __mminf32 (incorrect negative, zero flags)

Hi all,

I have a problem with the C2000 CLA Compiler 6.4.10 generating wrong code with __mmaxf32, __mminf32 (incorrect negative, zero flags).

{
  static float float_global_1;
  static float float_global_2;
  signed short int_global;

  {
    float float_local;

    float_local = float_global_1 + float_global_2;
    float_local = __mmaxf32(__mminf32(float_local, 1.0), -1.0);
    //float_local += 0.0;

    if( float_local > 0.0)
    {
      int_global = 1;
    }
    else
    {
      int_global = 0;
    }
  }
...
}

With -o2, the generated code is wrong - the ZF and NF flags are set based on the __mmaxf32 intrinsic, not based on float_local value.

The calling options are

cl2000 CLA_Tasks.cla -v28 --float_support=fpu32 --fp_mode=relaxed --cla_support=cla1 --define=_CLA_  --tmu_support=tmu0 --c_src_interlist     --aliased_variables --no_rpt --opt_for_speed=4 --large_memory_model --symdebug:coff -o2

The resulting asm code is

        MMOV32    MR3,@_float_global_1$1 
        MADDF32   MR3,MR2,MR3            
        MMINF32   MR3,#16256             
        MMAXF32   MR3,#49024             
        MNOP       
        MNOP       
        MNOP       
        MBCNDD    $C$L18,GT              

After some trials, I found a workaround - float_local += 0.0 (commented in code above).

This leads to correct asm code

        MMOV32    MR3,@_float_global_1$1  
        MMOV32    MR2,@_float_global_2$2  
        MADDF32   MR3,MR2,MR3            
        MMINF32   MR3,#16256             
        MMAXF32   MR3,#49024             
        MADDF32   MR3,MR3,#0             
        MCMPF32   MR3,#0.0               
        MNOP       
        MNOP       
        MNOP       
        MBCNDD    $C$L18,LEQ 

Is this CLA compiler error already known?

Can you reproduce it (and confirm the workaround)?

Can you please add it to the SDOWP?