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.
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 :
signature.asc
Description: Digital signature
