https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

Peter Bisroev <peter.bisroev at groundlabs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.bisroev at groundlabs 
dot co
                   |                            |m

--- Comment #113 from Peter Bisroev <peter.bisroev at groundlabs dot com> ---
Hi Dave,

I know this thread has been dormant for a while, but I have access to HP-UX on
IA64 architecture and might be able to assist with getting newer versions of
GCC running on that platform. Unfortunately I cannot provide you with direct
access to the machine, but can definitely be your eyes and ears on it :)

I have read through this entire thread here and on related bugs such as 64919,
and for the most part was able to reproduce everything that has been shown here
already. However as you have mentioned in your last comment, we need to get a
bootstrap compiler working first. So I have done some work to try and narrow
down which GCC release introduced the regression (at least as far as I can see
on the machine I have access to).

On my machine, I have HP's C/aC++ Compiler version is B3910B A.06.29 [Oct 18
2016] and HP's linker version is 92453-07 B.12.65. I am also using GNU Make
3.82 as the newer versions seem to have process control issues but that is
something separate. I just list that here so if anyone tries to reproduce my
steps they have the base to go from. Here I will include brief errors as to
limit the size of the message but I can of course provide more detailed errors
once we know what should be looked at next. I guess, this is more of an
introduction to what I have already done.

Besides trying what is mentioned here in this thread already, I first tried to
get a working GCC 4.7.4 using HP's C compiler as it is the last one that can be
bootstrapped by a C compiler. In order to do this I've compiled 32 bit versions
of the following using cc/aCC:
- Binutils 2.32 without GMP, MPC, MPFR. Some minor changes needed to be done to
not build info pages and to remove compilation flags not supported by aCC from
WARN_WRITE_STRINGS, GCC_WARN_CFLAGS, GCC_WARN_CFLAGS_FOR_BUILD.
- GMP 6.1.0 (Earlier versions fail to compile due to syntax errors.)
- MPFR 3.1.4 (Earlier versions fail to compile due to syntax errors. I also had
to use +O0 as otherwise some unit tests through 'make check' fail with the
default optimization level of +02. This is not needed when compiling with a
working GCC such as 4.1.2, please see below.)
- MPC 1.0.3

Unfortunately I was not able to compile exact versions of GMP, MPFR and MPC as
downloaded by contrib/download_prerequisites script due to compilation issues
mentioned above. But in my testing on other platforms, using newer versions
above (as used by GCC 8.3.0 and 9.2.0) did not cause any issues. So for this
test I decided to stick with those.

I then was able to get a clean compilation of GCC 4.7.4 using GNU assembler
without any issues using the following configure and make commands:
--------------------
$SRCDIR/configure \
    --prefix="$HOME/opt/aCC/32/$SRCBASENAME" \
    --with-gmp="$HOME/opt/aCC/32" \
    --with-mpfr="$HOME/opt/aCC/32" \
    --with-mpc="$HOME/opt/aCC/32" \
    --enable-languages='c,c++' \
    --enable-version-specific-runtime-libs \
    --disable-nls \
    --with-gnu-as \
    --with-as="$HOME/opt/aCC/32/bin/as" \
    --without-gnu-ld \
    --with-ld="/usr/bin/ld" \
    AWK="/usr/local/bin/awk" \
    M4="/usr/local/bin/m4" \
    CC='cc +DD32' CXX='aCC +DD32'
~/opt/aCC/32/bin/make -j8 bootstrap
~/opt/aCC/32/bin/make -j8 install
--------------------

Unfortunately after that the compiler fails to bootstrap itself with the error
shown below with build/stage_current set to "stage1":
--------------------
checking for ia64-hp-hpux11.31-gcc... <srcpath>/build/./gcc/xgcc
-B<srcpath>/build/./gcc/
-B<srcpath>/opt/aCC/32/gcc-4.7.4-self-bootstrapped/ia64-hp-hpux11.31/bin/
-B<dstpath>/opt/aCC/32/gcc-4.7.4-self-bootstrapped/ia64-hp-hpux11.31/lib/
-isystem
<dstpath>/opt/aCC/32/gcc-4.7.4-self-bootstrapped/ia64-hp-hpux11.31/include
-isystem
<dstpath>/opt/aCC/32/gcc-4.7.4-self-bootstrapped/ia64-hp-hpux11.31/sys-include
exec(2): text exceeds limits
checking for suffix of object files... exec(2): text exceeds limits
configure: error: in `<srcpath>/build/ia64-hp-hpux11.31/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
--------------------

Looking through the ia64-hp-hpux11.31/libgcc/config.log I can see that the
original error is:
--------------------
xgcc: error trying to exec '<srcpath>/build/./gcc/cc1': execv: Not enough space
--------------------

I then noticed that the size of that executable is 336194708 bytes, while the
one that is used to bootstrap this compiler,
<dstpath>/opt/aCC/32/gcc-4.7.4/libexec/gcc/ia64-hp-hpux11.31/4.7.4/cc1 is only
86758824 bytes. So that error message makes sense as new cc1 is too big to load
as limited by maxtsiz kernel tunable parameter. On my machine maxtsiz is set to
the default value of 100663296 bytes. So I guess the question is why did the
compiler blow up in size? I have tried compiling with STAGE1_CFLAGS set to -O0
and -O1 as recommended in the previous comments here, but that just segfaults
at later stages as has already been shown previously.

At this point I have tried to find a GCC version that could be properly
bootstrapped using HP's compiler and still be able to bootstrap itself. After a
bunch of trial and error, I was able to cleanly build a C compiler from GCC
3.3.6 which was then able to properly bootstrap itself. I was then able to use
self bootstrapped GCC 3.3.6 C compiler to successfully build both C and C++
compilers with GCC 4.1.2. I have then used the new GCC 4.1.2 to bootstrap
itself without any issues.

For brevity, this process is short on details, but for every stage the
following was done to more or less be comfortable that the built compilers are
working:
- Everything is 32bit and uses original source code without any patches.
- Build GNU Make 3.82 using the latest available compiler, staring with aCC,
and use that for all compilation steps.
- Build Binutils 2.32 using the latest available compiler, staring with aCC.
- Build the GCC compiler version used in previous phase again but using
Binutils from the last step. (This step does not apply for initial aCC
bootstrap).
- Build the next GCC version using the compiler from the step above and using
assembler from Binutils compiled in this stage.
- Self bootstrap the same GCC version built in the previous step.
- Build GMP, MPFR, MPC using the self bootstrapped compiler from the previous
step (even if they are not needed by the current GCC version) and make sure
'make check' passes.

If all the steps above complete successfully move to the next version of GCC by
repeating the same steps. When I have reached GCC 4.1.2, I have tried compiling
various C/C++ code bases in addition to the ones mentioned above. It all seemed
to work without issues. In addition, between GCC 3.3.6 and 4.1.2, I have tried
3.4.6, 4.0.0 and 4.1.0. All worked perfectly fine with the steps above.

At this point I tried bootstrapping next GCC after 4.1.2, which is GCC 4.2.0.
That failed to build using the self bootstrapped GCC 4.1.2 with the following
error:
--------------------
<srcpath>/build/./gcc/xgcc -B<srcpath>/build/./gcc/
-B<dstpath>/opt/gcc-4.1.2/32/gcc-4.2.0/ia64-hp-hpux11.31/bin/
-B<dstpath>/opt/gcc-4.1.2/32/gcc-4.2.0/ia64-hp-hpux11.31/lib/ -isystem
<dstpath>/opt/gcc-4.1.2/32/gcc-4.2.0/ia64-hp-hpux11.31/include -isystem
<dstpath>/opt/gcc-4.1.2/32/gcc-4.2.0/ia64-hp-hpux11.31/sys-include -O2  -O2 -g
-O2  -DIN_GCC    -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I.
-I<srcpath>/gcc-4.2.0/gcc -I<srcpath>/gcc-4.2.0/gcc/.
-I<srcpath>/gcc-4.2.0/gcc/../include
-I<srcpath>/gcc-4.2.0/gcc/../libcpp/include
-I<dstpath>/opt/gcc-4.1.2/32/include -I<dstpath>/opt/gcc-4.1.2/32/include
-I<srcpath>/gcc-4.2.0/gcc/../libdecnumber -I../libdecnumber -DSHARED -mlp64
-DL__divxf3 -xassembler-with-cpp -c
<srcpath>/gcc-4.2.0/gcc/config/ia64/lib1funcs.asm -o libgcc/hpux64/__divxf3_s.o


Pid 26447 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxrsessiz
or stack size limit is set too small.
--------------------

Looking at the backtrace in the generated core dump I can see the same frame
blowing through the stack.
--------------------
#0  cancel_option (opt_idx=0, next_opt_idx=0, orig_next_opt_idx=0)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:116
#1  0x4050480:0 in cancel_option (opt_idx=30, next_opt_idx=0,
    orig_next_opt_idx=555)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:123
#2  0x4050480:0 in cancel_option (opt_idx=30, next_opt_idx=0,
    orig_next_opt_idx=555)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:123
#3  0x4050480:0 in cancel_option (opt_idx=30, next_opt_idx=0,
    orig_next_opt_idx=555)
...
#9998 0x4050480:0 in cancel_option (opt_idx=30, next_opt_idx=0,
    orig_next_opt_idx=555)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:123
#9999 0x4050480:0 in cancel_option (opt_idx=30, next_opt_idx=0,
    orig_next_opt_idx=555)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:123
#10000 0x4050480:0 in cancel_option (opt_idx=30, next_opt_idx=0,
    orig_next_opt_idx=555)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:123
...
#147455 0x4050480:0 in cancel_option (opt_idx=30, next_opt_idx=0,
    orig_next_opt_idx=555)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:123
#147456 0x4050480:0 in cancel_option (opt_idx=30, next_opt_idx=555,
    orig_next_opt_idx=555)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:123
#147457 0x4050f40:0 in prune_options (argcp=0x200000007fffcea0,
    argvp=0x200000007fffcea4)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:208
#147458 0x4040b60:0 in main (argc=43, argv=0x200000007fffd2f4)
    at <srcpath>/gcc-4.2.0/gcc/gcc.c:6099
--------------------

And the oldest 3 frames are:
--------------------
(gdb) bt full -3
#147456 0x4050480:0 in cancel_option (opt_idx=30, next_opt_idx=555,
    orig_next_opt_idx=555)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:123
No locals.
#147457 0x4050f40:0 in prune_options (argcp=0x200000007fffec80,
    argvp=0x200000007fffec84)
    at <srcpath>/gcc-4.2.0/gcc/opts-common.c:208
        next_opt_idx = 555
        j = 36
        opt_idx = 30
        argc = 43
        options = (int *) 0x200000004001e590
        argv = (char **) 0x200000004001e640
        i = 14
        arg_count = 14
        need_prune = 767
        option = (const struct cl_option *) 0x200000004001569c
        opt_index = 612
#147458 0x4040b60:0 in main (argc=43, argv=0x200000007ffff0d8)
    at <srcpath>/gcc-4.2.0/gcc/gcc.c:6099
        i = 536870912
        value = 0
        linker_was_run = 0
        lang_n_infiles = 0
        num_linker_inputs = 0
        explicit_link_files = 0x0
        specs_file = 0x0
        p = 0x200000007ffff20c "xgcc"
        uptr = (struct user_specs *) 0x0
--------------------

So xgcc segfaults before even getting to the compilation during argument
parsing. What is also interesting, if I compile the same exact source file with
exactly the same arguments as above with the previous 4.1.2 compiler used for
bootstrapping, everything works without issues.

Unfortunately I do not have more time to dig into this issue right now and it
would be good to get your idea on which direction to proceed from here.

>From what I can see in my other tests, we need C++ compiler built with GCC
4.7.4 to bootstrap GCC 6.1.0 and above. This is due to the fact that using C++
compiler from 4.1.2 generates errors due to poisoned functions errors such as
this one:
--------------------
<dstpath>/opt/gcc-4.1.2/32/gcc-4.1.2/lib/gcc/ia64-hp-hpux11.31/4.1.2/include/stdlib.h:233:
error: attempt to use poisoned "calloc"
--------------------

I specifically pointed version 6.1.0 out as it was the first version where
C++14 standard was enabled by default. So to get GCC 4.7.4 working we can
either try and figure out how to bootstrap it with HP's compiler or to work
from GCC 4.1.2 and figure out what broke with 4.2.0 and go from there.

What are your thoughts?

Thank you for your help!

Regards,
--peter

Reply via email to