ICA: gcc compilers (c++, gcc, cc1, cc1plus, ...) differ between first and second build

[Bruce Dubbs]

Using objdump -d, it is found that the assembly code differ between first and second build (different use of register, use of different opcodes, ...). I suspect it has something to do with LTO, which would be applied on second pass and not on first, but its highly speculative.

Solution None yet... (any idea welcome!)

[Bruce Dubbs]

From pierre.labastie:

Possible solution

Do a 3-stage bootstrap for GCC. (removing --disable-bootstrap).

[Bruce Dubbs]

From pierre.labastie:

Or build BLFS GCC as soon as possible (with or without bootstrap). But I think we'd rather avoid bootstrapping. Building gcc three times is already rather time consuming.

Thinking more about this: if nothing else, try a 2-stage bootstrap. Maybe it is enough. Those are just random thoughts though. I'm building a 2-stage ICA saving build directories of gcc. Hopefully, something should emerge from the comparison of the build directories.

[Bruce Dubbs]

From pierre.labastie:

I've been able to set up an example for the gcc differences, using one of the affected files, which is spellcheck.o. On a finished lfs, cd /sources and unpack gcc, cd to the unpacked tree, then:

mkdir build1 && cd build1
CC=/tools/bin/gcc                     \
CXX=/tools/bin/g++                    \
../configure --prefix=/usr            \
             --enable-languages=c,c++ \
             --disable-multilib       \
             --disable-bootstrap      \
             --with-system-zlib
make -j4 all-build
make -j4 configure-host
cd gcc
make -j4 c-family/c-spellcheck.o
cd ../..
mkdir build2 && cd build2
../configure --prefix=/usr  
#... then the same thing again in build2 without setting CC and CXX

On my machine the produced .o files are different. As can be seen by diffing the output of objdump -d.

[Bruce Dubbs]

From pierre.labastie:

The problem is the following: the header files which are included, are not the same in each case.

The reason is that the search directory order is not the same, because for /tools/bin/g++, /usr/include is first, while for g++, it comes after /usr/include/c++/9.3.0. And somehow, with this different order, one file is included in the second case, which is not included in the first, containing a lot of use instructions. I guess this is the reason why the generated code is not the same (some different types used).

Solution Use -idirafter instead of -isystem in the specs file. That puts /usr/include at the end of the search. This solves the above problem, and headers for programs which are only in chapter 6 can be found in /usr/include. For those which are in chapter 5 too, /tools/include will be used instead. But this is not a problem, since those headers are the same.

[Bruce Dubbs]

From pierre.labastie:

The -idirafter solution is not totally satisfactory: I happen to have build on two different distros, and one of them generated gcc-pass2 with intl support from glibc, while the other not.

But with -idirafter, the glibc headers from /tools are used instead of those from /usr. Those in /usr do have intl support, but not those in /tools. So some programs are slightly different between first pass (using /tools) and second pass (using /usr).

[Pierre Labastie]

Replying to bdubbs:

From pierre.labastie:

Possible solution

Do a 3-stage bootstrap for GCC. (removing --disable-bootstrap).

This solution is proposed by xry111 (author lost when splitting the original ticket)

[Pierre Labastie]

Replying to bdubbs:

From pierre.labastie:

The -idirafter solution is not totally satisfactory: I happen to have build on two different distros, and one of them generated gcc-pass2 with intl support from glibc, while the other not.

But with -idirafter, the glibc headers from /tools are used instead of those from /usr. Those in /usr do have intl support, but not those in /tools. So some programs are slightly different between first pass (using /tools) and second pass (using /usr).

This diagnostic is wrong. There are differences in gcov, but they are the same whether using -idirafter or -isystem (I cannot edit/remove this comment since I do not own it)

[Bruce Dubbs]

In comment 3 above, I note that we build gcc differently in chapter 5 and chapter 6.

In Chapter 5 we build mpfr, gmp, and mpc as a part of gcc. In Chapter 6 they are separate external libraries.

In Chapter 5, /tools is embedded in the gcc executable. In Chapter 6, is is /usr.

It does not surprise me that files built with tools are slightly different from those build with Chapter 6 gcc. We do not have any instances of mis-compiliation that I know about.

Perhaps we should just leave this as wontfix.

[Pierre Labastie]

I have saved the "build" directory for each ICA build of gcc. With the -idirafter switch, there are no differences in the .o or .a files. So it is rather clean, and I think we should make the change in the book (*). But still there are differences in gcov...

Looking at the link command for gcov, it is found that it links with in-tree .a or .o files, but uses the -static-libgcc and -static-libstdc++ flags. So I suspect it links against the libstdc++.a and libgcc.a from /tools on first iteration, while it links afainst the ones in /usr on 2nd and 3rd.

Let's try a diff of those libraries.

(*) Bruce also thinks that it is educational to have -idirafter (private communication)

[Pierre Labastie]

Hmm, nothing useful found. I've committed the change to -idirafter at r11819. Will try once more. Leaving open for now.

[Pierre Labastie]

Closing. I do not know what to do more. gcov is not a critical part of the system anyway. If anybody wants to try, my host is debian 8 (purposedly old). And gettext is not installed... Closing as fixed, because only gcov is still affected, and not always.

[Bruce Dubbs]

Milestone renamed