After getting the new keil5 MDK, i compiled the code developed in keil4. (the legacy package has to be installed to achieve the reverse-compatibility).
everything seems to be working fine, except two change:
#define MHZ *10000001 #define SYS_FREQ 60 MHZ #if SYS_FREQ == (120 MHZ) #define SDRAM_PERIOD 8.33 // 96MHz #elif SYS_FREQ == (96 MHZ) #define SDRAM_PERIOD 10.4 // 96MHz #elif SYS_FREQ == (72 MHZ) #define SDRAM_PERIOD 13.8 // 72MHz #elif SYS_FREQ == (60 MHZ) #define SDRAM_PERIOD 16.67 // 72MHz #elif SYS_FREQ == (57 MHZ) #define SDRAM_PERIOD 17.4 // 57.6MHz #elif SYS_FREQ == (48 MHZ) #define SDRAM_PERIOD 20.8 // 48MHz #elif SYS_FREQ == (36 MHZ) #define SDRAM_PERIOD 27.8 // 36MHz #elif SYS_FREQ == (24 MHZ) #define SDRAM_PERIOD 41.7 // 24MHz #elif SYS_FREQ == (12 MHZ) #define SDRAM_PERIOD 83.3 // 12MHz #else #error Frequency not defined #endif //The MHZ (in sdram.h) has to be separated by a white space from the number value, // unlike in keil4 where the white space was not necessary. #include <rtl.h> // Marks a red cross adjacent to this line in the FileConfig.h only (which is the new way of keil to highlight the warnings and error) // the error reads : RTL.H File not found with <angled> include; use "quotes" instead
not sure why this error is shown only in the 'file_config.h'. In all the other .c source files, this error is not displayed. also the project is build and i can download and debug the code (though i have not single stepped through whole code, but think that it may not be an issue of much concern)
//The MHZ (in sdram.h) has to be separated by a white space from the number value, // unlike in keil4 where the white space was not necessary.
In that case you've been the "victim" of a bugfix. The preprocessor phase of your previous toolchain should never have allowed that syntax in the first place: "120MHZ" is not a valid preprocessing expression, because it's a single pp-number token, but doesn't convert into a valid integer-constant. Nor are macro supposed to be expanded in the middle of an existing pp-token.
The new version of Keil apparently fixed that bug, which in turn exposed the bug in your source code.
#include <stdio.h> #define MHZ *10000001 #define SYS_FREQ 60MHZ int main(void) { printf("Hello!"); return 0; }
The above code was compiled without any error/warning. gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
The below code was compiled with some errors/warnings. gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
#include <stdio.h> #define MHZ *10000001 #define SYS_FREQ 60MHZ #if SYS_FREQ == (120MHZ) #define SDRAM_PERIOD 8.33 // 96MHz #elif SYS_FREQ == (96MHZ) #define SDRAM_PERIOD 10.4 // 96MHz #elif SYS_FREQ == (72MHZ) #define SDRAM_PERIOD 13.8 // 72MHz #elif SYS_FREQ == (60MHZ) #define SDRAM_PERIOD 16.67 // 72MHz #else #error Frequency not defined #endif int main(void) { printf("Hello!"); return 0; }
test.c:4:24: error: invalid suffix "MHZ" on integer constant #define SYS_FREQ 60MHZ ^ test.c:6:9: note: in expansion of macro ‘SYS_FREQ’ #if SYS_FREQ == (120MHZ) ^ test.c:6:22: error: invalid suffix "MHZ" on integer constant #if SYS_FREQ == (120MHZ) ^ test.c:4:24: error: invalid suffix "MHZ" on integer constant #define SYS_FREQ 60MHZ ^ test.c:8:9: note: in expansion of macro ‘SYS_FREQ’ #elif SYS_FREQ == (96MHZ) ^ test.c:8:22: error: invalid suffix "MHZ" on integer constant #elif SYS_FREQ == (96MHZ) ^ test.c:4:24: error: invalid suffix "MHZ" on integer constant #define SYS_FREQ 60MHZ ^ test.c:10:9: note: in expansion of macro ‘SYS_FREQ’ #elif SYS_FREQ == (72MHZ) ^ test.c:10:22: error: invalid suffix "MHZ" on integer constant #elif SYS_FREQ == (72MHZ) ^ test.c:4:24: error: invalid suffix "MHZ" on integer constant #define SYS_FREQ 60MHZ ^ test.c:12:9: note: in expansion of macro ‘SYS_FREQ’ #elif SYS_FREQ == (60MHZ) ^ test.c:12:22: error: invalid suffix "MHZ" on integer constant #elif SYS_FREQ == (60MHZ) ^
Does the first case indicate a bug in gcc?
Windows, Code::Blocks 12.11, some kind of gcc
#include <stdio.h> #define MHZ *10000001 #define SYS_FREQ 60MHZ #if SYS_FREQ == (120MHZ) #define SDRAM_PERIOD 8.33 #elif SYS_FREQ == (96MHZ) #define SDRAM_PERIOD 10.4 #elif SYS_FREQ == (72MHZ) #define SDRAM_PERIOD 13.8 #elif SYS_FREQ == (60MHZ) #define SDRAM_PERIOD 16.67 #else #error Frequency not defined #endif int main(void) { printf("Hello!"); return 0; }
TmpKeep\test.c|7|error: invalid suffix "MHZ" on integer constant| TmpKeep\test.c|7|error: invalid suffix "MHZ" on integer constant| TmpKeep\test.c|9|error: invalid suffix "MHZ" on integer constant| TmpKeep\test.c|9|error: invalid suffix "MHZ" on integer constant| TmpKeep\test.c|11|error: invalid suffix "MHZ" on integer constant| TmpKeep\test.c|11|error: invalid suffix "MHZ" on integer constant| TmpKeep\test.c|13|error: invalid suffix "MHZ" on integer constant| TmpKeep\test.c|13|error: invalid suffix "MHZ" on integer constant| ||=== Build finished: 8 errors, 0 warnings (0 minutes, 0 seconds) ===|
It skipped the error at [ #define SYS_FREQ 60MHZ ]
"Does the first case indicate a bug in gcc?"
Note that the first case doesn't make use of any defined symbol.
No. It indicates that it's allowed to define a macro to expand to nonsense, as long as you never refer to that macro. If the macro is never expanded, the expansion will never make it past that definition, so it doesn't matter what's in there.
In the case at hand "210MHZ" is a valid preprocessing token, but it cannot be converted into a non-preprocessing token. So every time the compiler tries to use it beyond the mere text-replacement aspects of the preprocessing phase, that's an error.
name[i] = *(pFpath+i); i++; the warning generated reads, Unsequenced modification and access to i. how is this unsequenced??
name[i++] = *(pFpath+i); as far as i know, this would be a real unsequenced modification.
name[i] = *(pFpath+i); i++;
Where did this suddenly come from?
This suddenly came from the compiler. this is a new catch. there are a lot more such things. like the example code of the nand flash file system now generates a hard-fault (escalated from bus fault).
i am unsure of which previous codes would successfully work in keil5. a lot of time would be wasted. had i known about such issues' existence, would have never opted for an update.
This suddenly came from the compiler.
Why didn't you mention that in the first place?
I, for one, don't have time to waste on what looks like random chatter.
You really do need to tighten up on the quality of your postings.
Why didn't you mention that in the first place? coz that came after posting the thread. there may be, not sure, other warnings and issues also (who knows). and with a view of not creating another thread related to the issues faced due to update to keil5, i didnt create another thread and continued here. sry if that bothers you.
sry if that bothers you.
No, you obviously misunderstand.
What bothers me is your lack of ability in explaining the problem(s) in a coherent manner.