Compiler/TMS570LS0432: compilation error using macros

Part Number: TMS570LS0432

Tool/software: TI C/C++ Compiler

The following code does not compile using TI ARM compiler v17.3.0.STS or TI v5.2.8.  I have not tried other versions.

// test.c

int getVal(void) { return 0; }

int will_compile(void) { ; int retVal = getVal(); return 0; }

#define MAKE_FUNC( funcName )  int funcName(void) { ; int retVal = getVal(); return 0; }

MAKE_FUNC(wont_compile)

// TI ARM compiler has the following complaints:
//
// >> Compilation failure
// source/subdir_rules.mk:21: recipe for target 'source/test.obj' failed
// "../source/test.c", line 9: warning #994-D: missing return statement at end of non-void function "wont_compile"
// "../source/test.c", line 9: error #68: expected a "}"
// "../source/test.c", line 9: error #60: function call is not allowed in a constant expression
// "../source/test.c", line 9: error #171: expected a declaration
// "../source/test.c", line 9: error #171: expected a declaration
// At end of source: warning #12-D: parsing restarts here after previous syntax error
// 4 errors detected in the compilation of "../source/test.c".
// gmake: *** [source/test.obj] Error 1

Here is the pre-processed output:

int getVal(void) { return 0; }

int will_compile(void) { ; int retVal = getVal(); return 0; }


int wont_compile(void) { ; int retVal = getVal(); return 0; }

The pre-processed output compiles just file if saving it as a .c file.

--thx

test.c:

6735.test.c

test.pp.c:

test.pp.c

Note that the forum interface will not let me upload a ".pp" file, so I have renamed it to a ".pp.c" file, but, other than renaming, that file is exactly as the pre-processor created it.

6 Replies

  • Thank you for notifying us about this problem.  I can reproduce it.  I filed CODEGEN-2259 in the SDOWP system to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George


    TI C/C++ Compiler Forum Moderator
    Please click This Resolved My Issue on the best reply to your question
    The CCS Youtube Channel
     has short how-to videos
    The 
    Compiler Wiki answers most common questions
    Track an issue with SDOWP. Enter your bug id in the Search box.

  • I believe this is known issue CODEGEN-1979. If your source code has a statement (";") before a declaration ("int retVal = getVal();"), and the declaration does not have white space in front of it, the parser will emit an incorrect error ("error: expected a "}""). When you put code like that into the preprocessor, it strips all whitespace, so even though there actually is a space in the macro, there is no space when the parser gets to work. You'll need to rearrange your macro so that there are no statements before any of the declarations.
  • In reply to Archaeologist:

    I get "Record 'CODEGEN-1979' was not found" when I try to use the search box from the SDOWP link in George's signature. What is the status of this issue and timeline to be fixed?

    Note that the .pp output file does have a space between the ";" and the int declaration, as I showed above. This implies that the .pp output does not accurately reflect what the compiler is doing internally; do you concur?

    --thx
  • In reply to 1138:

    I've updated CODEGEN-1979 to be public. SDOWP should refresh shortly.

    Well, it's true that the .pp output is not bug-for-bug identical to normal compilation. However, it is generated by the same parser, so it is extremely close. Aside from this particular bug, I don't recall another case where there is a practical, non-pathological difference.
  • In reply to Archaeologist:

    Fair enough--it just seemed worthwhile pointing out that there might be two different bugs here, one where the parser isn't doing the internal equivalent of adding a space when processing a macro, separate from CODEGEN-1979's issue about whitespace next to declarations.

    Or maybe under the hood they're really the same bug after all.


    One comment about the impact of this issue on us:

    I appreciate the information that we have a lever to work around the issue by re-ordering our declarations. This is certainly valuable, but isn't cost-free as far as our process goes, as we have coding standards relating to variable declarations. It particularly impacts variables that we want to declare as const.

    (Imagine "const int retVal = getVal();" in the toy code above.)


    SDOWP doesn't show a "Target Release" for CODEGEN-1979. What is the time frame for addressing this issue?

    --thx
  • In reply to 1138:

    Frankly, no time frame has been determined. We're still debating what we're going to do about it.