llvm dev - Oct 2016 - unable to compile llvm with gcc 4.7.4

On Wed, Oct 12, 2016 at 04:15:44PM +0100, Renato Golin
wrote:
> On 12 October 2016 at 14:34, Teresa Johnson via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> 
> > So I'd first like to understand whether we still want to keep gcc
4.7 as a
> > supported version, or move to 4.8 as was suggested. What is the
process for
> > making that change?
> >
> 
> Same as usual: propose on the list, and hope that no one has any blocking
> issues. Going to 4.9 failed because many people had reservations, but IIRC,
> none of those people had reservations against 4.8.
> 
> 
> 
> > If we stick with 4.7 we should have a bot otherwise it will likely
stop
> > working again pretty quickly.
> >
> 
> Yes, same for Clang. I suggest we also move to Clang 3.4 as the minimum and
> install a quick bot with that.
Suggestion is not clear answer. How such a decision taken? Is there a board of
people which have to vote to valid the choice of minimal gcc (and clang) version
effective?
Because, currently, the LTO lib caching code (and certainly more as Teresa
Johnson pointed out) should be patched.

If gcc 4.7 (last 1-step C boostrap-able c++-ish compiler) is phased out, then,
to bootstrap llvm from a C compiler/runtime, gcc(4.7.4) + gcc(version>=4.8)
will have to be setup first.

-- 
Sylvain

On 12 October 2016 at 18:37,  <sylvain.bertrand at gmail.com>
wrote:
> Suggestion is not clear answer. How such a decision taken? Is there a board
of
> people which have to vote to valid the choice of minimal gcc (and clang)
version
> effective?
We don't have such process, unfortunately. :)

> If gcc 4.7 (last 1-step C boostrap-able c++-ish compiler) is phased out,
then,
> to bootstrap llvm from a C compiler/runtime, gcc(4.7.4) +
gcc(version>=4.8)
> will have to be setup first.
I want to understand your constraints, as I think this is a unique
case that I wasn't considering.

I normally worry about what's available on systems, so that users can
"just compile" using the system compiler and libraries. That's why
I
only worry about 4.8+, because that's what's available on most old,
stable systems.

But you seem to need a C compiler and bootstrap GCC 4.7. Is this a
full bootstrap? Including glibc and binutils? If so, how do you
control their versions?

More importantly, why can't you just use the GCC that comes with
distros, or why can't you just compile your toolchain once and use
everywhere?

After all, GCC has moved on from plain C because it wasn't that
important to most of them either.

So, this trend is not LLVM-specific, but it's aggravated in LLVM
because we like more shiny toys than the GCC devs. :)

cheers,
--renato

On Wed, Oct 12, 2016 at 07:15:39PM +0100, Renato Golin
wrote:
> On 12 October 2016 at 18:37,  <sylvain.bertrand at gmail.com> wrote:
> > Suggestion is not clear answer. How such a decision taken? Is there a
board of
> > people which have to vote to valid the choice of minimal gcc (and
clang) version
> > effective?
> 
> We don't have such process, unfortunately. :)
> 
> 
> > If gcc 4.7 (last 1-step C boostrap-able c++-ish compiler) is phased
out, then,
> > to bootstrap llvm from a C compiler/runtime, gcc(4.7.4) +
gcc(version>=4.8)
> > will have to be setup first.
> 
> I want to understand your constraints, as I think this is a unique
> case that I wasn't considering.
It's my custom distro. My goal is to make it boostrap-able with tinycc (or
any
little C compiler alternative) as a one-man reasonable job. With the removal of
gcc 4.7 support now official, I would need to have a 3 step bootstrap, adding a
modern gcc (which is guaranted to compile with iso c++98-ish gcc 4.7.4, feature
that clang cannot guaranted anymore).

I'm targetting llvm only for its AMDGPU backend (AMD southern island GPU
architecture). Hacking the build system made me manage to compile llvm libs
with gcc 4.7.4:
	- I removed libLTO, all tools except llvm-config.
	- all tools except llvm-config.
Till mesa compiles and runs fine, I don't care about the rest of llvm.

----

BTW, the llvm build system is kind of weird. libLTO and tools are llvmbuild.txt
components, I though I could deal only with llvmbuild.txt files to disable them,
but
I had to deal with CMakefile.txt files too. Expected?

-- 
Sylvain