[U-Boot] compile errors with gcc-4.5.1

[U-Boot] compile errors with gcc-4.5.1

[Kumar Gala]

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

[U-Boot] compile errors with gcc-4.5.1 on OXC and RMU boards

[Scott Wood]

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

[U-Boot] compile errors with gcc-4.5.1 on OXC and RMU boards

[Wolfgang Denk]

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

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"And it should be the law: If you use  the  word  `paradigm'  without
knowing  what  the  dictionary  says  it  means,  you  go to jail. No
exceptions."                     - David Jones @ Megatest Corporation

[U-Boot] compile errors with gcc-4.5.1 on OXC and RMU boards

[Kumar Gala]

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

[U-Boot] compile errors with gcc-4.5.1 on OXC and RMU boards

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I may be synthetic, but I'm not stupid"  -  the  artificial  person,
from _Aliens_

[U-Boot] compile errors with gcc-4.5.1 on OXC and RMU boards

[Kumar Gala]

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

[U-Boot] compile errors with gcc-4.5.1 on OXC and RMU boards

[Nathan Sidwell]

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

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery

[U-Boot] compile errors with gcc-4.5.1 on OXC and RMU boards

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What about WRITING it first and rationalizing it afterwords?  :-)
                       - Larry Wall in <8162@jpl-devvax.JPL.NASA.GOV>

[U-Boot] compile errors with gcc-4.5.1 on OXC and RMU boards

[Nathan Sidwell]

On 12/13/10 21:26, Wolfgang Denk wrote:
> 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.

C std 6.10.1 para 2

Please use the portal for all future defect reports.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery

[U-Boot] compile errors with gcc-4.5.1 on OXC and RMU boards

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Either one of us, by himself, is expendable.  Both of us are not.
	-- Kirk, "The Devil in the Dark", stardate 3196.1

[U-Boot] compile errors with gcc-4.5.1

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Einstein argued that there must be simplified explanations of nature,
because God is not capricious or arbitrary. No  such  faith  comforts
the software engineer.                             - Fred Brooks, Jr.