Compiler/TMS570LS0432: compilation error using macros

1138

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:

Fullscreen 6735.test.c Download

// 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

test.pp.c:

Fullscreen test.pp.c Download


int getVal(void) { return 0; }

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


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

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.

over 8 years ago

0 George Mock over 8 years ago

TI__Guru**** 251180 points

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

0 Archaeologist over 8 years ago

TI__Guru* 84285 points

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.

0 1138 over 8 years ago in reply to Archaeologist

Expert 1226 points

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

0 Archaeologist over 8 years ago in reply to 1138

TI__Guru* 84285 points

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.

0 1138 over 8 years ago in reply to Archaeologist

Expert 1226 points

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

0 Archaeologist over 8 years ago in reply to 1138

TI__Guru* 84285 points

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

Code Composer Studio™︎

Code Composer Studio forum

Compiler/TMS570LS0432: compilation error using macros