[U-Boot] compile errors with gcc-4.5.1
On the OXC & RMU boards I'm seeing the following build error:
powerpc-linux-gnu-gcc -g -Os -mrelocatable -ffunction-sections -fdata-sections -fPIC -meabi -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xFFF00000 -I/local/home/galak/git/u-boot-85xx/include -fno-builtin -ffreestanding -nostdinc -isystem /local/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/../lib/gcc/powerpc-linux-gnu/4.5.1/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC824X -ffixed-r2 -mstring -mcpu=603e -msoft-float -Wall -Wstrict-prototypes -fno-stack-protector \ -o board.o board.c -c board.c: In function 'board_init_r': board.c:761:35: error: token "[" is not valid in preprocessor expressions make[1]: *** [board.o] Error 1
Not sure what to be done about it, since OXC.h defines:
#define CONFIG_SYS_FLASH_BASE (0-flash_info[0].size)
- k
On Fri, 10 Dec 2010 12:14:43 -0600 Kumar Gala galak@kernel.crashing.org wrote:
On the OXC & RMU boards I'm seeing the following build error:
powerpc-linux-gnu-gcc -g -Os -mrelocatable -ffunction-sections -fdata-sections -fPIC -meabi -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xFFF00000 -I/local/home/galak/git/u-boot-85xx/include -fno-builtin -ffreestanding -nostdinc -isystem /local/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/../lib/gcc/powerpc-linux-gnu/4.5.1/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC824X -ffixed-r2 -mstring -mcpu=603e -msoft-float -Wall -Wstrict-prototypes -fno-stack-protector \ -o board.o board.c -c board.c: In function 'board_init_r': board.c:761:35: error: token "[" is not valid in preprocessor expressions make[1]: *** [board.o] Error 1
Not sure what to be done about it, since OXC.h defines:
#define CONFIG_SYS_FLASH_BASE (0-flash_info[0].size)
This:
# elif CONFIG_SYS_MONITOR_BASE == CONFIG_SYS_FLASH_BASE
requires that CONFIG_SYS_FLASH_BASE be a preprocessor-evaluatable constant. flash_info[0].size isn't any sort of constant. I don't see how it ever worked -- probably just got evaluated as zero, or a string compare, or something.
As for what's to be done, I'll start by getting the attention of anyone who cares about these boards by putting the board names in the subject. :-)
Maybe convert the #elif into a regular if-statement?
-Scott
Dear Scott Wood,
In message 20101210122714.24b2cbef@udp111988uds.am.freescale.net you wrote:
On Fri, 10 Dec 2010 12:14:43 -0600 Kumar Gala galak@kernel.crashing.org wrote:
On the OXC & RMU boards I'm seeing the following build error:
powerpc-linux-gnu-gcc -g -Os -mrelocatable -ffunction-sections -fdata-sections -fPIC -meabi -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xFFF00000 -I/local/home/galak/git/u-boot-85xx/include -fno-builtin -ffreestanding -nostdinc -isystem /local/opt/freesc
ale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/../lib/gcc/powerpc-linux-gnu/4.5.1/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC824X -ffixed-r2 -mstring -mcpu=603e -msoft-float -Wall -Wstrict-prototypes -fno-stack-protector \
-o board.o board.c -cboard.c: In function 'board_init_r': board.c:761:35: error: token "[" is not valid in preprocessor expressions make[1]: *** [board.o] Error 1
Not sure what to be done about it, since OXC.h defines:
#define CONFIG_SYS_FLASH_BASE (0-flash_info[0].size)
This:
# elif CONFIG_SYS_MONITOR_BASE == CONFIG_SYS_FLASH_BASE
requires that CONFIG_SYS_FLASH_BASE be a preprocessor-evaluatable constant. flash_info[0].size isn't any sort of constant. I don't see how it ever worked -- probably just got evaluated as zero, or a string compare, or something.
As for what's to be done, I'll start by getting the attention of anyone who cares about these boards by putting the board names in the subject. :-)
Maybe convert the #elif into a regular if-statement?
No, I think this is a bug in the tool chain.
The "#elif" above should never be evaluated because the corresponding
# if defined(CONFIG_OXC) || defined(CONFIG_RMU)
already catches the case for the OXC & RMU boards.
Or has the rule officially been dropped that the "#if" in the C prepro use the same shortcut logic as the "if" in C?
Best regards,
Wolfgang Denk
On Dec 12, 2010, at 3:49 PM, Wolfgang Denk wrote:
Dear Scott Wood,
In message 20101210122714.24b2cbef@udp111988uds.am.freescale.net you wrote:
On Fri, 10 Dec 2010 12:14:43 -0600 Kumar Gala galak@kernel.crashing.org wrote:
On the OXC & RMU boards I'm seeing the following build error:
powerpc-linux-gnu-gcc -g -Os -mrelocatable -ffunction-sections -fdata-sections -fPIC -meabi -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xFFF00000 -I/local/home/galak/git/u-boot-85xx/include -fno-builtin -ffreestanding -nostdinc -isystem /local/opt/freesc
ale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/../lib/gcc/powerpc-linux-gnu/4.5.1/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC824X -ffixed-r2 -mstring -mcpu=603e -msoft-float -Wall -Wstrict-prototypes -fno-stack-protector \
-o board.o board.c -cboard.c: In function 'board_init_r': board.c:761:35: error: token "[" is not valid in preprocessor expressions make[1]: *** [board.o] Error 1
Not sure what to be done about it, since OXC.h defines:
#define CONFIG_SYS_FLASH_BASE (0-flash_info[0].size)
This:
# elif CONFIG_SYS_MONITOR_BASE == CONFIG_SYS_FLASH_BASE
requires that CONFIG_SYS_FLASH_BASE be a preprocessor-evaluatable constant. flash_info[0].size isn't any sort of constant. I don't see how it ever worked -- probably just got evaluated as zero, or a string compare, or something.
As for what's to be done, I'll start by getting the attention of anyone who cares about these boards by putting the board names in the subject. :-)
Maybe convert the #elif into a regular if-statement?
No, I think this is a bug in the tool chain.
The "#elif" above should never be evaluated because the corresponding
# if defined(CONFIG_OXC) || defined(CONFIG_RMU)
already catches the case for the OXC & RMU boards.
Or has the rule officially been dropped that the "#if" in the C prepro use the same shortcut logic as the "if" in C?
I'm being told that not reporting this as an error is a bug in previous gcc's not the new one. There isn't anything in the C specs about early out handling from what I can tell.
- k
Dear Kumar Gala,
In message E7F59234-4A15-4B96-B2FB-0FB3EEDC58A5@kernel.crashing.org you wrote:
Or has the rule officially been dropped that the "#if" in the C prepro use the same shortcut logic as the "if" in C?
I'm being told that not reporting this as an error is a bug in previous gcc's not the new one. There isn't anything in the C specs about early out handling from what I can tell.
But there is nothing in the specs that states that always all conditions need to be evaluated or at least checked if they can be evaluated reasonably. To me, the new behaviour makes no sense - neither logically not performance-wise.
I am aware that common sense and gcc behaviour is not always in the same pot, but I consider this to be a change to the worse.
Can you point to some commit / bugzilla entry / posting that contains an explanation or rationale for this change?
Best regards,
Wolfgang Denk
On Dec 13, 2010, at 10:15 AM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message E7F59234-4A15-4B96-B2FB-0FB3EEDC58A5@kernel.crashing.org you wrote:
Or has the rule officially been dropped that the "#if" in the C prepro use the same shortcut logic as the "if" in C?
I'm being told that not reporting this as an error is a bug in previous gcc's not the new one. There isn't anything in the C specs about early out handling from what I can tell.
But there is nothing in the specs that states that always all conditions need to be evaluated or at least checked if they can be evaluated reasonably. To me, the new behaviour makes no sense - neither logically not performance-wise.
I am aware that common sense and gcc behaviour is not always in the same pot, but I consider this to be a change to the worse.
Can you point to some commit / bugzilla entry / posting that contains an explanation or rationale for this change?
Hopefully, Nathan can provide some input on this.
- k
On 12/13/10 18:47, Kumar Gala wrote:
Hopefully, Nathan can provide some input on this.
It is required by the C and C++ standards.
nathan
Dear Nathan,
In message 4D066E11.9000606@codesourcery.com you wrote:
Hopefully, Nathan can provide some input on this.
It is required by the C and C++ standards.
Could you please provide a link? Not that I don't believe you, but I'd like to understand the rationale, if there is any.
Best regards,
Wolfgang Denk
On 12/13/10 21:26, Wolfgang Denk wrote:
Dear Nathan,
In message4D066E11.9000606@codesourcery.com you wrote:
Hopefully, Nathan can provide some input on this.
It is required by the C and C++ standards.
Could you please provide a link? Not that I don't believe you, but I'd like to understand the rationale, if there is any.
C std 6.10.1 para 2
Please use the portal for all future defect reports.
nathan
Dear Nathan Sidwell,
In message 4D0718D5.2050307@codesourcery.com you wrote:
It is required by the C and C++ standards.
Could you please provide a link? Not that I don't believe you, but I'd like to understand the rationale, if there is any.
C std 6.10.1 para 2
Hm... which exact part requires this behaviour? Please quote, to make sure we're accessing the same text.
I'm asking because the "Rationale" has the following part (see http://www.lysator.liu.se/c/rat/c8.html#3-8-1) :
... " Processing of skipped material is defined such that an implementation need only examine a logical line for the # and then for a directive name. Thus, assuming that xxx is undefined, in this example:
# ifndef xxx # define xxx "abc" # elif xxx > 0 /* ... */ # endif
an implementation is not required to diagnose an error for the elif statement, even though if it were processed, a syntactic error would be detected. " ...
To me this looks like the situation we have here?
I understand that "is not required" still permits such behaviour, but you say it is _required_ which is yet another thing.
Thanks.
Best regards,
Wolfgang Denk
Dear Kumar Gala,
In message AF9E6B23-EB4E-4A1C-99CF-0F8980BD61FC@kernel.crashing.org you wrote:
On the OXC & RMU boards I'm seeing the following build error:
powerpc-linux-gnu-gcc -g -Os -mrelocatable -ffunction-sections -fdata-sections -fPIC -meabi -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xFFF00000 -I/local/home/galak/git/u-boot-85xx/include -fno-builtin -ffreestanding -nostdinc -isystem /local/opt/freescal e/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/../lib/gcc/powerpc-linux-gnu/4.5.1/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC824X -ffixed-r2 -mstring -mcpu=603e -msoft-float -Wall -Wstrict-prototypes -fno-stack-protector \ -o board.o board.c -c board.c: In function 'board_init_r': board.c:761:35: error: token "[" is not valid in preprocessor expressions make[1]: *** [board.o] Error 1
Not sure what to be done about it, since OXC.h defines:
#define CONFIG_SYS_FLASH_BASE (0-flash_info[0].size)
Looks like a serious bug in the tool chain.
Best regards,
Wolfgang Denk
participants (4)
-
Kumar Gala -
Nathan Sidwell -
Scott Wood -
Wolfgang Denk