Increasingly high build failures

Folks,

I just did another round of ./MAKEALL arm with MG/CS 2011.09-69, and the failure rate is rising to say the least, with 277 boards failing out of
278. :(

Basically, the issues are, in order of impact:

- Now 264 'uses variable-size enums yet the output is to use 32-bit enums' errors. That's a raise! Probably caused by some commonly included .h, but as the issue is at link stage and only refers to library intrinsics, tracing the culprit may take time. However, I cannot keep on ignoring this warning now, and thus I will look for a general solution, probably along the lines of enabling variable-size enums throughout the U-Boot codebase at least for toolchains that complain about it.

- 6 warnings are 'ap20.c:44:18: warning: array subscript is above array bounds'. Last changed was in commit 03c609f6. Simon Glass, as you are listed as author of the commit, please have a look.

- netspace_v2 board causing the only error case: Undefined or unsupported LaCie KW board variant. Simon Guinot, as you are listed as the board maintainer, can you have a look?

This pretty much covers the immediate actions, but extrapolating from the situation, I would advise any and all contributors whose first name is Simon and last name initial is G to watch out for issues. :)

Amicalement,

Albert.

Dear Albert ARIBAUD,

Which version of GCC is this?

Recent tests with ELDK 5.2 (which is based on gcc version 4.6.4 20120303) show no such problems.

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
The complexity of software is an essential property, not an  acciden-
tal  one. Hence, descriptions of a software entity that abstract away
its complexity often abstract away its essence.    - Fred Brooks, Jr.

Hi Wolfgang,

Le 19/04/2012 11:51, Wolfgang Denk a ?crit :

Seems there was a misconfiguration in my toolchain and repo -- redoing the mass build with correct settings, will update notice when done

Amicalement,

Albert.

Le 19/04/2012 12:04, Albert ARIBAUD a ?crit :

After triple-checking the I was using the right commit (my current master) and the right toolchain ("gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-69)"), ./MAKEALL arm shows the following:

--------------------- SUMMARY ---------------------------- Boards compiled: 277
Boards with warnings or errors: 28 ( VCMA9 smdk2410 nhk8815 nhk8815_onenand apollon igep0020 igep0030 omap4_panda omap4_sdp4430 omap5_evm s5p_goni smdkc100 s5pc210_universal seaboard ventana balloon3 lubbock palmld palmtc polaris pxa255_idp trizepsiv vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2 colibri_pxa270 )
----------------------------------------------------------

... with still 3 build errors, for omap4_panda, omap4_sdp4430 and
omap5_evm: 'internal compiler error: in decode_addr_const, at varasm.c:2635', and 57 warnings of which 48 are 'uses variable-size enums yet the output is to use 32-bit enums' and 9 are 'variable [...] set but not used [-Wunused-but-set-variable]'

So the only 'issue' is the enums, for which I'll seek a solution.

Apologies -- especially to Simon G.* -- for the noise.

Amicalement,

Albert.

Dear Albert,

Note: you should run out-of-tree builds; this usually catches a bunch of additional problems.

ARM (with the 3 patches I just posted) builds cleanly for me, both with ELDK v5.1 (gcc version 4.6.1 20110627) and with ELDK 5.2 (gcc version 4.6.4 20120303):

--------------------- SUMMARY ---------------------------- Boards compiled: 277
----------------------------------------------------------

Guess I will stick with ELDK :-)

Note 2: there are a number of boards that trigger removal warnigns:

warning: Please migrate to boards.cfg. Failure to do so will
mean removal of your board in the next release.

Configuring for smdk6400 board...

These are _not_ automatically listed under "warnings or errors"!

Hi Albert,

I don't get this warning, but this is indeed a latent bug. It currently has no effect since no one is using CLOCK_ID_EPCI, CLOCK_ID_SFROM32KHZ. I will submit a patch, which should be fairly safe to commit even at this late stage.

Regards,
Simon