It seems a bug crept in CC ARM, may be not only ARM. Consider next code:
#ifdef IDENTIFIER IDENTIFIER(); #endif
and build output:
..\..\src\module\module.cpp(344): error: #20: identifier "IDENTIFIER" is undefined
GCC does not have such problem. Check <a href=coliru.stacked-crooked.com/.../7e6350bd2bfbc14a >here</a>
This worked fine in uV5.15, perhaps you need to use something more unique than LED, to ensure it's not defined someplace else, in an include, command line or something.
I'd be very surprised if it were a compiler/preprocessor bug as it would break a whole galaxy of stuff.
// Define test - led.cpp void led_test(void) { //#define LED PA7 #ifdef LED led_on(LED); // no errors here when above define commented #endif }
The preprocessor output tends to be a good way to solve lots of slightly muddy assumptions about what data the tools are actually operating on. The reason all C/C++ compilers has a "preprocess only" option is the huge number of "doh" moments when people have spent hours with a problem and then finally look at the actual expansion.
A compiler tool chain is normally run through a very large code base of tests as regression testing. This code base is not missing #define, #ifdef, #if defined, ... constructs.
So when something slips through, it's normally very very special cases that somehow, somewhere deep down affects a coding assumption in the code optimizer. Or an incorrect understanding of the syntax might make the tools do what they shouldn't - but then these errors tends to be there from day one. Until someone finally has a test case and reports back about the failure.
The standard #include files shipped with the compiler has lots of #define constructs, so it would most probably be impossible to build the MDK-ARM libraries if the preprocessor doesn't handle #define as expected.