From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 19 Apr 2012 13:54:54 +0200 Subject: [U-Boot] [ARM] [STATUS] **NO** Increasingly high build failures In-Reply-To: <4F8FE335.2050609@aribaud.net> References: <4F8FBB22.5000205@aribaud.net> <20120419095140.AA2BC202B35@gemini.denx.de> <4F8FE335.2050609@aribaud.net> Message-ID: <4F8FFD0E.60104@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 19/04/2012 12:04, Albert ARIBAUD a ?crit : > Hi Wolfgang, > > Le 19/04/2012 11:51, Wolfgang Denk a ?crit : >> Dear Albert ARIBAUD, >> >> In message<4F8FBB22.5000205@aribaud.net> you wrote: >>> 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. :( >> >> 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 > > Seems there was a misconfiguration in my toolchain and repo -- redoing > the mass build with correct settings, will update notice when done 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.