On 16 August 2014 22:33, Jan-Benedict Glaw <jbg...@lug-owl.de> wrote: > On Sat, 2014-08-16 22:01:40 +0200, Marc Glisse <marc.gli...@inria.fr> wrote: >> For your tests, I thought the sequence was: >> >> checkout some revision of gcc >> build a native gcc at this revision >> use it to build a bunch of cross-compilers at the same revision > > There are actually two different build strategies implemented. > > 1. Builds using GCC's ./contrib/config-list.mk; > 2. Something homegrown (also builds binutils). > > As you can see in the timeline, the homegrown stuff isn't affected (at > least not more than usual ;-) ) > > However, the builds done with ./contrib/config-list.mk fail since > (most probably) the commit I pointed out. We can quite start a > discusion about what config-list.mk actually does and whether or not > that's universally right. But we can also recognize that as a fact, > something (which is possibly not yet fully understood) changed along > that commit.
My understanding is that the build-bot is using -Werror to compile fortran/options.c with a compiler that is at least one revision older than my commit. Since my commit adds both the code to handle format codes in the Fortran FE and functions using the new format codes, you need at least that revision to not get Wformat warnings. In config-list.mk, it says "Make sure you have a recent enough gcc (with ada support) in your path so that --enable-werror-always will work" For this commit in particular, recent enough means "exactly the same revision". Otherwise, --enable-werror-always won't work. And you cannot build that compiler with --enable-werror-always. See also: https://gcc.gnu.org/ml/gcc/2014-01/msg00157.html I think that for a build-bot it would be better to bootstrap the compiler for the current target once (without --enable-werror-always), then use that compiler to build the rest minus the current target (with --enable-werror-always). This could be done within config-list.mk or from another script. Cheers, Manuel. > > From a quick view, config-list.mk tries to invoke the host compiler > ($CC/$CPP) and just builds "all-gcc" with it. There used to be some > spurious errors due to that for some targets (I can dig those out if > somebody is interested; it's usually a variable GCC thinks that's used > uninitialized, and some recently introduced fuzz with the m68k > target), but there are quite a number of functions using printf style > (with GCC extensions) format checking. That all used to work, except > for this new function introduced with the fortran change. I think that > there's something simple missing (maybe as easy as an undefined > macro), but I haven't checked that at all. > > MfG, JBG > > -- > Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 > Signature of: Wenn ich wach bin, träume ich. > the second :
