• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 56 subscribers
  • Views 991 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C5500 v4.3.6 cannot a compile a rpt >32768

Wouter
Prodigy 140 points


given this code:

#include <string.h>

int large_size[32768+1]; //make it larger then 2^15

int main(void)
{
 memset(large_size, 0, sizeof(large_size));
}

compile using 4.3.6:

cl55 --memory_model=large -O -vcpu:1.0,cpu:2.2:main.c

It gives 4 assembler errors trying to do a RPT #-32768.

This bugs has been there since at least cgt v2.56 or so. Please fix it

 

 

 

 

 

  • 0
    TI__Guru**** 251230 points

    Thanks for letting us know about this problem.  I submitted an entry with record id SDSCM00035752 into our SDOWP system.  Feel free to track progress with the SDOWP link in my sig below.

    Thanks and regards,

    -George

     

  • 0 in reply to George Mock
    TI__Expert 6550 points

    I'm not sure the code is legal C.  INT_MAX is 32767 and sizeof returns an int type.  I'm not sure if you can create an array of size greater than INT_MAX and I think the behavior of trying to return a size greater than INT_MAX to the memset call could be undefined by the standard.

  • 0 in reply to ThomasS
    Prodigy 140 points

    You're wrong, sizeof returns a size_t. Which (for the c5500) is defined as unsigned int. Besides the compiler bug is still valid.

    memset also use size_t (I think it does, I am not sure, it does not complain when feeding > 32767).

    And yes you can create an array larger then 32767, even larger then 65535. The compiler will not complain, even worse sizeof(>65536) will "work" it just gives you the truncated value... However the linker cannot place such a large object and start complaining. 

    The compiler not complaining is that a bug as well?

     

     

  • 0 in reply to George Mock
    Prodigy 140 points

    Hi George and all others.

    I just read the SDOWP report and the discription misses my point. My point is about the assembler generator. It just does not allow you to create rpt loops with loop count > 32767. See the code below. According to spru374g it is possible to create a rpt with count up to 65536-1. So basically the error is the assembler generator generates a signed 16 bit instead of an unsigned 16 bit constant.

    An other disturbing point is the SDDOWP work around to use huge_model. That is not available on every platform. Personally I am stuck to a 5502 so that is a no go for me.

    volatile int test;
int main(void)
{
unsigned int i;
for(i=0;i<40000;i++)
{
    test = 0;
}

    This gives:

    ".\ti_bug_again.asm", ERROR!   at line 73: [E9999] Syntax Error
                RPT #-25537

".\ti_bug_again.asm", ERROR!   at line 73: [E9999] Invalid instructionsyntax,
                                                   CSR, Immediate: 8-bit
                                                   unsigned, Immediate: 16-bit
                                                   signed, Smem expected
                RPT #-25537

".\ti_bug_again.asm", ERROR!   at line 73: [E9999] Trailing operands or input
                                                   specified
                RPT #-25537

".\ti_bug_again.asm", ERROR!   at line 73: [E9999] Failed operand constraints
                RPT #-25537

4 Assembly Errors, No Assembly Warnings

Errors in Source - Assembler Aborted
  • 0 in reply to Wouter
    TI__Expert 4280 points

    There are larger language rule issues associated with using arrays of size greater than 32767 in the Large Memory Model, but ignoring that, the bug you have stumbled on is in the assembler when using mnemonic format.  This is in the database as SDSCM00008696.

    The workaround when using the compiler is to add the -mg option to force the intermediate assembly file to use algebraic format which does not have the bug.  The only complication in doing this would be if your C source includes any asm statements; these would have to use algebraic assembly format.

     

  • 0 in reply to Paul Knueven
    Prodigy 140 points

    Thanks for you quick and clear response.

    Paul Knueven said:
    The workaround when using the compiler is to add the -mg option to force the intermediate assembly file to use algebraic format which does not have the bug.  The only complication in doing this would be if your C source includes any asm statements; these would have to use algebraic assembly format

    It really is a good workaround. However I don't seem to be able to find the SDSCM8696 in the bug tracking software. Is it fixed already?

    The whole size larger >32767 is not a problem for us now.

  • 0 in reply to Wouter
    TI__Expert 4280 points

    SDSCM00008696 is definitely NOT fixed.

    I am not sure why it does not show up outside of TI (using SDOWP).  It does show up on the internal view of the database.