* Re: gcc-64 on HP-UX 11.00 [not found] ` <200204112027.g3BKR6DK001129@hiauly1.hia.nrc.ca> @ 2002-04-12 3:19 ` H.Merijn Brand 2002-04-12 4:39 ` H.Merijn Brand 0 siblings, 1 reply; 32+ messages in thread From: H.Merijn Brand @ 2002-04-12 3:19 UTC (permalink / raw) To: John David Anglin; +Cc: gcc On Thu 11 Apr 2002 22:27, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > > The results from previous executions of configure are kept in > > > config.cache. So, at a minimum, all config.cache files need to be > > > > In which directory? In the src directory? Whoa, then I have to change my > > scripts. > > > > > removed before rerunning configure. > > They are all in the build directory. > > > > > Alternate solution. Temporary rename all GNU ld's so it cannot find them. > > Would that help? or will it stop stage1/stage2? > > You want to use HP ld for the entire first build. If > "--with-ld=/usr/ccs/bin/ld" is wrong, configure falls back to searching > for an appropriate linker. This could have been how you got the gnu > linker again. You should see the result of the selection in the > configure output. You can also see the DEFAULT_LINKER selected in > gcc/config.status. Renaming should work but it shouldn't be necessary. a5:/pro/3gl/GNU/gcc 127 > cat Conf-64a #!/usr/bin/sh export LD_PXDB=/usr/bin/true export CONFIG_SITE= export CC="cc -Ae +DA2.0W" export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/opt/imake/bin rm -rf obj mkdir obj cd obj ../src/configure \ --enable-languages=c \ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \ --with-gnu-as --with-as=/usr/local/pa20_64/bin/as \ --with-ld=/usr/ccs/bin/ld \ --disable-shared \ --disable-nls \ --host=hppa64-hp-hpux11.00 echo "" echo "Now start 'Build-64'" a5:/pro/3gl/GNU/gcc 128 > Conf-64a *** This configuration is not supported in the following subdirectories: target-libffi target-boehm-gc target-zlib target-libjava target-libchill target-libstdc++-v3 target-libf2c zlib fastjar target-libobjc (Any other directories should still work fine.) Created "Makefile" in /pro/3gl/GNU/gcc/obj using "mh-frag" ld: (Warning) Can't exec pxdb using path: /usr/bin/true Configuring libiberty... creating cache ../config.cache checking whether to enable maintainer-specific portions of Makefiles... no checking for makeinfo... makeinfo configure: warning: *** Makeinfo is too old. Info documentation will not be built. checking for perl... perl checking host system type... hppa64-hp-hpux11.00 checking build system type... hppa64-hp-hpux11.00 checking for ar... ar checking for ranlib... ranlib checking for gcc... cc -Ae +DA2.0W checking whether we are using GNU C... no checking for POSIXized ISC... no checking for working const... yes checking for inline... inline checking for a BSD compatible install... /opt/imake/bin/install -c checking how to run the C preprocessor... cc -Ae +DA2.0W -E checking for sys/file.h... yes checking for sys/param.h... yes checking for limits.h... yes checking for stdlib.h... yes checking for string.h... yes checking for unistd.h... yes checking for strings.h... yes checking for sys/time.h... yes checking for time.h... yes checking for sys/resource.h... yes checking for sys/stat.h... yes checking for sys/mman.h... yes checking for fcntl.h... yes checking for alloca.h... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking whether time.h and sys/time.h may both be included... yes checking whether errno must be declared... no checking for ANSI C header files... yes checking for uintptr_t... yes checking whether the C compiler (cc -Ae +DA2.0W -g ) works... yes checking whether the C compiler (cc -Ae +DA2.0W -g ) is a cross-compiler... no checking for asprintf... no checking for atexit... yes checking for basename... yes checking for bcmp... yes checking for bcopy... yes checking for bsearch... yes checking for bzero... yes checking for calloc... yes checking for clock... yes checking for ffs... yes checking for getcwd... yes checking for getpagesize... yes checking for index... yes checking for insque... yes checking for memchr... yes checking for memcmp... yes checking for memcpy... yes checking for memmove... yes checking for memset... yes checking for mkstemps... no checking for putenv... yes checking for random... yes checking for rename... yes checking for rindex... yes checking for setenv... no checking for sigsetmask... yes checking for strcasecmp... yes checking for strchr... yes checking for strdup... yes checking for strncasecmp... yes checking for strrchr... yes checking for strstr... yes checking for strtod... yes checking for strtol... yes checking for strtoul... yes checking for tmpnam... yes checking for vasprintf... no checking for vfprintf... yes checking for vprintf... yes checking for vsprintf... yes checking for waitpid... yes checking whether alloca needs Cray hooks... no checking stack direction for C alloca... 1 checking for pid_t... yes checking for vfork.h... no checking for working vfork... yes checking for _doprnt... yes checking for sys_errlist... yes checking for sys_nerr... yes checking for sys_siglist... no checking for getrusage... yes checking for on_exit... no checking for psignal... no checking for strerror... yes checking for strsignal... no checking for sysconf... yes checking for times... yes checking for sbrk... yes checking for gettimeofday... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/stat.h... (cached) yes checking for sys/types.h... yes checking for getpagesize... (cached) yes checking for working mmap... no checking for working strncmp... yes updating cache ../config.cache creating ./config.status creating Makefile creating testsuite/Makefile creating config.h Configuring gcc... loading cache ../config.cache checking LIBRARY_PATH variable... ok checking GCC_EXEC_PREFIX variable... ok checking host system type... hppa64-hp-hpux11.00 checking target system type... hppa64-hp-hpux11.00 checking build system type... hppa64-hp-hpux11.00 checking for gcc... (cached) cc -Ae +DA2.0W checking whether the C compiler (cc -Ae +DA2.0W -g ) works... yes checking whether the C compiler (cc -Ae +DA2.0W -g ) is a cross-compiler... no checking whether we are using GNU C... (cached) no checking whether cc -Ae +DA2.0W accepts -g... yes checking whether cc -Ae +DA2.0W and cc understand -c and -o together... yes checking whether cc -Ae +DA2.0W accepts -Wno-long-long... yes checking how to run the C preprocessor... (cached) cc -Ae +DA2.0W -E checking for inline... (cached) inline checking for volatile... yes checking for long double... yes checking for long long int... yes checking for __int64... no checking for built-in _Bool... yes checking size of short... 2 checking size of int... 4 checking size of long... 8 checking size of long long... 8 checking execution character set... ASCII checking whether make sets ${MAKE}... yes checking whether a default assembler was specified... yes (/usr/local/pa20_64/bin/as - GNU as) checking whether a default linker was specified... yes (/usr/ccs/bin/ld) checking for GNU C library... no checking for gawk... gawk checking whether ln works... yes checking whether ln -s works... yes checking for ranlib... (cached) ranlib checking for a BSD compatible install... (cached) /opt/imake/bin/install -c checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking for working stdbool.h... yes checking whether string.h and strings.h may both be included... yes checking for sys/wait.h that is POSIX.1 compatible... (cached) yes checking for limits.h... (cached) yes checking for stddef.h... yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for stdlib.h... (cached) yes checking for time.h... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/file.h... (cached) yes checking for sys/time.h... (cached) yes checking for sys/resource.h... (cached) yes checking for sys/param.h... (cached) yes checking for sys/times.h... yes checking for sys/stat.h... (cached) yes checking for direct.h... no checking for malloc.h... yes checking for langinfo.h... yes checking for thread.h... no checking for pthread.h... yes checking for CHAR_BIT... yes checking byte ordering... big-endian checking floating point format... IEEE (big-endian) checking for gnatbind... no checking for compiler driver that understands Ada... cc checking for mktemp... yes checking for makeinfo... (cached) makeinfo checking for modern makeinfo... no configure: warning: *** Makeinfo is missing or too old. *** Info documentation will not be built. checking for recent Pod::Man... yes checking for flex... flex checking for bison... bison checking for collect2 libraries... none required checking for library containing exc_resume... no checking for preprocessor stringizing operator... yes checking for inttypes.h... yes checking for times... (cached) yes checking for clock... (cached) yes checking for dup2... yes checking for kill... yes checking for getrlimit... yes checking for setrlimit... yes checking for atoll... no checking for atoq... no checking for sysconf... (cached) yes checking for strsignal... (cached) no checking for putc_unlocked... yes checking for fputc_unlocked... no checking for fputs_unlocked... no checking for fwrite_unlocked... no checking for fprintf_unlocked... no checking for getrusage... (cached) yes checking for nl_langinfo... yes checking for lstat... yes checking for ssize_t... yes checking for uid_t in sys/types.h... yes checking type of array argument to getgroups... gid_t checking whether the printf functions support %p... yes checking for pid_t... (cached) yes checking for vfork.h... (cached) no checking for working vfork... (cached) yes checking for getpagesize... (cached) yes checking for working mmap from /dev/zero... no checking for working mmap with MAP_ANON(YMOUS)... yes checking for working mmap of a file... yes checking for iconv... yes checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking whether getenv is declared... yes checking whether atol is declared... yes checking whether sbrk is declared... yes checking whether abort is declared... yes checking whether atof is declared... yes checking whether getcwd is declared... yes checking whether getwd is declared... yes checking whether strsignal is declared... yes checking whether putc_unlocked is declared... no checking whether fputs_unlocked is declared... no checking whether fwrite_unlocked is declared... no checking whether fprintf_unlocked is declared... no checking whether strstr is declared... yes checking whether errno is declared... yes checking whether malloc is declared... yes checking whether realloc is declared... yes checking whether calloc is declared... yes checking whether free is declared... yes checking whether basename is declared... no checking whether getopt is declared... yes checking whether clock is declared... yes checking whether getrlimit is declared... yes checking whether setrlimit is declared... yes checking whether getrusage is declared... yes checking whether times is declared... yes checking for struct tms... yes checking for clock_t... yes checking if mkdir takes one argument... no Using `../../src/gcc/config/pa/pa.c' for machine-specific logic. Using `../../src/gcc/config/pa/pa.md' as machine description file. Using the following target machine macro files: ../../src/gcc/config/pa/pa64-start.h ../../src/gcc/config/pa/pa.h ../../src/gcc/config/pa/pa64-regs.h ../../src/gcc/config/pa/long_double.h ../../src/gcc/config/pa/elf.h ../../src/gcc/config/pa/pa-hpux.h ../../src/gcc/config/pa/pa-hpux11.h ../../src/gcc/config/pa/pa-64.h ../../src/gcc/config/pa/pa64-hpux.h checking for library containing strerror... none required checking for working const... (cached) yes checking for off_t... yes checking for size_t... yes checking for working alloca.h... (cached) yes checking for alloca... yes checking whether we are using the GNU C Library 2.1 or newer... no checking for argz.h... no checking for limits.h... (cached) yes checking for locale.h... yes checking for nl_types.h... yes checking for malloc.h... (cached) yes checking for stddef.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/param.h... (cached) yes checking for feof_unlocked... no checking for fgets_unlocked... no checking for getcwd... (cached) yes checking for getegid... yes checking for geteuid... yes checking for getgid... yes checking for getuid... yes checking for mempcpy... no checking for munmap... yes checking for putenv... (cached) yes checking for setenv... (cached) no checking for setlocale... yes checking for stpcpy... no checking for strchr... (cached) yes checking for strcasecmp... (cached) yes checking for strdup... (cached) yes checking for strtoul... (cached) yes checking for tsearch... yes checking for __argz_count... no checking for __argz_stringify... no checking for __argz_next... no checking for iconv... (cached) yes checking for iconv declaration... (cached) extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for nl_langinfo and CODESET... yes checking for LC_MESSAGES... yes checking whether NLS is requested... no checking for bison... bison checking version of bison... 1.34, ok checking what assembler to use... /usr/local/pa20_64/bin/as checking what linker to use... /usr/ccs/bin/ld checking what nm to use... nm checking what objdump to use... objdump checking assembler alignment features... .p2align including maximum skip checking assembler subsection support... working .subsection -1 checking assembler weak support... yes checking assembler hidden support... yes checking assembler leb128 support... yes checking assembler eh_frame optimization... yes checking assembler section merging support... no checking assembler dwarf2 debug_line support... no checking assembler --gdwarf2 support... no checking assembler --gstabs support... no checking linker PT_GNU_EH_FRAME support... no Using ggc-page for garbage collection. checking whether to enable maintainer-specific portions of Makefiles... no Links are now set up to build a native compiler for hppa64-hp-hpux11.00 updating cache ../config.cache creating ./config.status creating Makefile creating intl/Makefile creating fixinc/Makefile creating gccbug creating mklibgcc creating auto-host.h Now start 'Build-64' a5:/pro/3gl/GNU/gcc 129 > grep DEFAULT_LINKER obj/gcc/config.status ${ac_dA}DEFAULT_LINKER${ac_dB}DEFAULT_LINKER${ac_dC}"/usr/ccs/bin/ld"${ac_dD} ${ac_uA}DEFAULT_LINKER${ac_uB}DEFAULT_LINKER${ac_uC}"/usr/ccs/bin/ld"${ac_uD} ${ac_eA}DEFAULT_LINKER${ac_eB}DEFAULT_LINKER${ac_eC}"/usr/ccs/bin/ld"${ac_eD} a5:/pro/3gl/GNU/gcc 130 > cat Build-64a #!/usr/bin/sh export LD_PXDB=/usr/bin/true export CONFIG_SITE= export CC="cc -Ae +DA2.0W" export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/opt/imake/bin cd obj make bootstrap-lean a5:/pro/3gl/GNU/gcc 131 > Build-64a : : make[3]: Entering directory `/pro/3gl/GNU/gcc/obj/gcc' for d in libgcc; do \ if [ -d $d ]; then true; else /bin/sh ../../src/gcc/mkinstalldirs $d; fi; \ done if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi make[3]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc' make[2]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc' make[1]: Leaving directory `/pro/3gl/GNU/gcc/obj' a5:/pro/3gl/GNU/gcc 132 > banner ':-)' ## ## # ## # ##### # # ## # ## ## a5:/pro/3gl/GNU/gcc 133 > cat Install-64a #!/usr/bin/sh export LD_PXDB=/usr/bin/true export CONFIG_SITE= export CC="cc -Ae +DA2.0W" export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/opt/imake/bin cd obj make install a5:/pro/3gl/GNU/gcc 134 > Install-64a : a5:/pro/3gl/GNU/gcc 135 > file /wrk/pa20_64/bin/gcc /wrk/pa20_64/bin/gcc: ELF-64 executable object file - PA-RISC 2.0 (LP64) a5:/pro/3gl/GNU/gcc 136 > ll /wrk/pa20_64/bin/gcc 558 -rwxr-xr-x 2 merijn softwr 606200 Apr 12 11:34 /wrk/pa20_64/bin/gcc a5:/pro/3gl/GNU/gcc 137 > /wrk/pa20_64/bin/gcc --version gcc (GCC) 3.1 20020408 (prerelease) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. a5:/pro/3gl/GNU/gcc 138 > -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-12 3:19 ` gcc-64 on HP-UX 11.00 H.Merijn Brand @ 2002-04-12 4:39 ` H.Merijn Brand 2002-04-12 5:08 ` H.Merijn Brand ` (2 more replies) 0 siblings, 3 replies; 32+ messages in thread From: H.Merijn Brand @ 2002-04-12 4:39 UTC (permalink / raw) To: John David Anglin; +Cc: gcc On Fri 12 Apr 2002 11:45, H.Merijn Brand <h.m.brand@hccnet.nl> wrote: > On Thu 11 Apr 2002 22:27, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > > > The results from previous executions of configure are kept in > > > > config.cache. So, at a minimum, all config.cache files need to be After that I used the newly installed gcc to build it again: --8<--- Conf-gcc64 #!/usr/bin/sh export CONFIG_SITE= export CC="gcc64 -mpa-risc-2-0" export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/opt/imake/bin rm -rf obj mkdir obj cd obj ../src/configure \ --enable-languages=c \ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \ --with-gnu-as --with-as=/usr/local/pa20_64/bin/as \ --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld \ --disable-shared \ --disable-nls \ --host=hppa64-hp-hpux11.00 -->8--- and --8<--- Build-gcc64 #!/usr/bin/sh export CONFIG_SITE= export CC="gcc64 -mpa-risc-2-0" export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/opt/imake/bin cd obj make bootstrap-lean -->8--- and --8<--- Install-gcc64 #!/usr/bin/sh export CONFIG_SITE= export CC="gcc64 -mpa-risc-2-0" export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/opt/imake/bin cd obj make install -->8--- And then I tried to use it to build bleadperl. I know it's pushing the limits, but somehow I just /had to/ try :)) CCCMD = gcc64 -DPERL_CORE -c -mpa-risc-2-0 -DDEBUGGING -D_HPUX_SOURCE -DDEBUGGING -fno-strict-aliasing -I/usr/local/pa20_64/include -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O -Wall cc1: warning: changing search order for system directory "/usr/local/pa20_64/include" cc1: warning: as it has already been specified as a non-system directory cc1: warning: changing search order for system directory "/usr/local/pa20_64/include" cc1: warning: as it has already been specified as a non-system directory gv.c: In function `Perl_gv_init': gv.c:126: warning: unused variable `Perl___notused' gv.c:130: warning: unused variable `Perl___notused' gv.c: In function `Perl_gv_autoload4': gv.c:521: warning: unused variable `Perl___notused' gv.c:528: warning: unused variable `Perl___notused' gv.c: In function `S_require_errno': gv.c:551: warning: unused variable `Perl___notused' gv.c:555: warning: unused variable `Perl___notused' gv.c: In function `Perl_amagic_call': gv.c:1707: warning: unused variable `Perl___notused' gv.c:1727: warning: unused variable `Perl___notused' gv.c:1772: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. make: *** [gv.o] Error 1 a5:/pro/3gl/CPAN/perl-current 125 > -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-12 4:39 ` H.Merijn Brand @ 2002-04-12 5:08 ` H.Merijn Brand 2002-04-12 9:34 ` John David Anglin 2002-04-13 10:40 ` John David Anglin 2 siblings, 0 replies; 32+ messages in thread From: H.Merijn Brand @ 2002-04-12 5:08 UTC (permalink / raw) To: John David Anglin; +Cc: gcc [-- Attachment #1: Type: text/plain, Size: 2055 bytes --] On Fri 12 Apr 2002 13:32, H.Merijn Brand <h.m.brand@hccnet.nl> wrote: > On Fri 12 Apr 2002 11:45, H.Merijn Brand <h.m.brand@hccnet.nl> wrote: > > On Thu 11 Apr 2002 22:27, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > > > > The results from previous executions of configure are kept in > > > > > config.cache. So, at a minimum, all config.cache files need to be > > After that I used the newly installed gcc to build it again: > > --8<--- Conf-gcc64 > #!/usr/bin/sh > > export CONFIG_SITE= > export CC="gcc64 -mpa-risc-2-0" > export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin > export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin > export PATH=$PATH"":/opt/imake/bin > > rm -rf obj > mkdir obj > cd obj > ../src/configure \ > --enable-languages=c \ > --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \ > --with-gnu-as --with-as=/usr/local/pa20_64/bin/as \ > --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld \ > --disable-shared \ > --disable-nls \ > --host=hppa64-hp-hpux11.00 > -->8--- > > and > > --8<--- Build-gcc64 > #!/usr/bin/sh > > export CONFIG_SITE= > export CC="gcc64 -mpa-risc-2-0" > export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin > export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin > export PATH=$PATH"":/opt/imake/bin > > cd obj > make bootstrap-lean > -->8--- > > and > > --8<--- Install-gcc64 > #!/usr/bin/sh > > export CONFIG_SITE= > export CC="gcc64 -mpa-risc-2-0" > export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin > export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin > export PATH=$PATH"":/opt/imake/bin > > cd obj > make install > -->8--- And the (cleaned from promped escapes) script log -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/ [-- Attachment #2: log2.bz2 --] [-- Type: application/octet-stream, Size: 20735 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-12 4:39 ` H.Merijn Brand 2002-04-12 5:08 ` H.Merijn Brand @ 2002-04-12 9:34 ` John David Anglin 2002-04-13 10:40 ` John David Anglin 2 siblings, 0 replies; 32+ messages in thread From: John David Anglin @ 2002-04-12 9:34 UTC (permalink / raw) To: H.Merijn Brand; +Cc: gcc > And then I tried to use it to build bleadperl. I know it's pushing the limits, > but somehow I just /had to/ try :)) Don't you know that you have to break a compiler in slowly :-) Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-12 4:39 ` H.Merijn Brand 2002-04-12 5:08 ` H.Merijn Brand 2002-04-12 9:34 ` John David Anglin @ 2002-04-13 10:40 ` John David Anglin 2002-04-15 8:45 ` law 2 siblings, 1 reply; 32+ messages in thread From: John David Anglin @ 2002-04-13 10:40 UTC (permalink / raw) To: H.Merijn Brand; +Cc: gcc > gv.c: In function `Perl_amagic_call': > gv.c:1707: warning: unused variable `Perl___notused' > gv.c:1727: warning: unused variable `Perl___notused' > gv.c:1772: output_operand: invalid expression as operand I believe that the enclosed patch fixes the above problem. However, it's not the end of the problems. In my build, miniperl seg faults when it first runs. Don't know if this is a gcc or perl problem. The patch has passed bootstrap and regression testing. However, I want to study the matter further as it possible this can happen on any PA2.0 machine, and not just TARGET_64BIT machines. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2002-04-13 John David Anglin <dave@hiauly1.hia.nrc.ca> * pa.md: Add new floating point load pattern. Index: pa.md =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa.md,v retrieving revision 1.101 diff -u -3 -p -r1.101 pa.md --- pa.md 4 Feb 2002 21:05:25 -0000 1.101 +++ pa.md 13 Apr 2002 05:00:52 -0000 @@ -3105,9 +3105,9 @@ (define_insn "" [(set (match_operand:DI 0 "reg_or_nonsymb_mem_operand" - "=r,r,r,r,r,r,Q,*q,!f,f,*TR") + "=r,r,r,r,r,r,Q,*q,!f,f,f,*TR") (match_operand:DI 1 "move_operand" - "A,r,J,N,K,RQ,rM,rM,!fM,*RT,f"))] + "A,r,J,N,K,RQ,rM,rM,!fM,A,*RT,f"))] "(register_operand (operands[0], DImode) || reg_or_0_operand (operands[1], DImode)) && ! TARGET_SOFT_FLOAT && TARGET_64BIT" @@ -3121,11 +3121,12 @@ std%M0 %r1,%0 mtsar %r1 fcpy,dbl %f1,%0 + fldd%F1 RT'%A1,%0 fldd%F1 %1,%0 fstd%F0 %1,%0" - [(set_attr "type" "load,move,move,move,shift,load,store,move,fpalu,fpload,fpstore") + [(set_attr "type" "load,move,move,move,shift,load,store,move,fpalu,fpload,fpload,fpstore") (set_attr "pa_combine_type" "addmove") - (set_attr "length" "4,4,4,4,4,4,4,4,4,4,4")]) + (set_attr "length" "4,4,4,4,4,4,4,4,4,4,4,4")]) (define_insn "" [(set (match_operand:DI 0 "reg_or_nonsymb_mem_operand" ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-13 10:40 ` John David Anglin @ 2002-04-15 8:45 ` law 2002-04-15 9:46 ` John David Anglin 0 siblings, 1 reply; 32+ messages in thread From: law @ 2002-04-15 8:45 UTC (permalink / raw) To: John David Anglin; +Cc: H.Merijn Brand, gcc In message <200204131603.g3DG3qut006131@hiauly1.hia.nrc.ca>, "John David Anglin " writes: > > gv.c: In function `Perl_amagic_call': > > gv.c:1707: warning: unused variable `Perl___notused' > > gv.c:1727: warning: unused variable `Perl___notused' > > gv.c:1772: output_operand: invalid expression as operand > > I believe that the enclosed patch fixes the above problem. However, it's > not the end of the problems. In my build, miniperl seg faults when it first > runs. Don't know if this is a gcc or perl problem. > > The patch has passed bootstrap and regression testing. However, I want > to study the matter further as it possible this can happen on any PA2.0 > machine, and not just TARGET_64BIT machines. Hmm, my question would be why didn't we use a general register as the destination? I guess it's technically possible to get into the situation you're trying to fix, but it may be happening due to problems elsewhere. jeff ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-15 8:45 ` law @ 2002-04-15 9:46 ` John David Anglin 2002-04-15 10:05 ` law 0 siblings, 1 reply; 32+ messages in thread From: John David Anglin @ 2002-04-15 9:46 UTC (permalink / raw) To: law; +Cc: h.m.brand, gcc > > The patch has passed bootstrap and regression testing. However, I want > > to study the matter further as it possible this can happen on any PA2.0 > > machine, and not just TARGET_64BIT machines. > Hmm, my question would be why didn't we use a general register as the > destination? I guess it's technically possible to get into the > situation you're trying to fix, but it may be happening due to problems > elsewhere. The error is caused by allowing symbolic LO_SUM addresses for PA2.0 (GO_IF_LEGITIMATE_ADDRESS), the T constraint which accepts LO_SUM addresses, and an output template that can't print these addresses. For hppa64, we have target_cpu_default="(MASK_PA_11|MASK_PA_20|MASK_GAS)" and for hppa2*-*-hpux11* we have target_cpu_default="MASK_PA_11" Thus, we don't generate PA2.0 on wide machines in 32bit mode by default. This explains why the problem hasn't been seen on 32bit machines. The same error occurs in 32bit mode with these options using gas: # gcc -O -mpa-risc-2-0 -fPIC -S gv.i gv.c: In function `Perl_amagic_call': gv.c:1774: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. As far as I can tell, the address form used in the patch is ok in PA2.0 code and it saves one instruction over forcing the address to a register. However, we need to fix the 32 bit pattern(s) as well. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-15 9:46 ` John David Anglin @ 2002-04-15 10:05 ` law 2002-04-15 11:42 ` John David Anglin 0 siblings, 1 reply; 32+ messages in thread From: law @ 2002-04-15 10:05 UTC (permalink / raw) To: John David Anglin; +Cc: h.m.brand, gcc In message <200204151646.g3FGkEtp008502@hiauly1.hia.nrc.ca>, "John David Anglin " writes: > > > The patch has passed bootstrap and regression testing. However, I want > > > to study the matter further as it possible this can happen on any PA2.0 > > > machine, and not just TARGET_64BIT machines. > > Hmm, my question would be why didn't we use a general register as the > > destination? I guess it's technically possible to get into the > > situation you're trying to fix, but it may be happening due to problems > > elsewhere. > > The error is caused by allowing symbolic LO_SUM addresses for PA2.0 > (GO_IF_LEGITIMATE_ADDRESS), the T constraint which accepts LO_SUM > addresses, and an output template that can't print these addresses. Yes, I know that. [ ... ] > The same error occurs in 32bit mode with these options using gas: > > # gcc -O -mpa-risc-2-0 -fPIC -S gv.i > gv.c: In function `Perl_amagic_call': > gv.c:1774: output_operand: invalid expression as operand > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. > > As far as I can tell, the address form used in the patch is ok > in PA2.0 code and it saves one instruction over forcing the address > to a register. However, we need to fix the 32 bit pattern(s) as > well. This isn't what I'm looking for. Based on the information I saw in the patch, you're loading something out of the DLT into a floating point register. That's an exceedingly bad thing to do, and while I don't doubt it can happen, I'd like to know more about why it happened. What caused us to do something that dumb. jeff ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-15 10:05 ` law @ 2002-04-15 11:42 ` John David Anglin 0 siblings, 0 replies; 32+ messages in thread From: John David Anglin @ 2002-04-15 11:42 UTC (permalink / raw) To: law; +Cc: h.m.brand, gcc > This isn't what I'm looking for. Thought so but thought I would supply the easy stuff first. My time for gcc is going to be limited in the next couple of weeks until I clear up a number of personal matters. Today, is about the last day. > Based on the information I saw in the patch, you're loading something out of > the DLT into a floating point register. That's an exceedingly bad thing to > do, and while I don't doubt it can happen, I'd like to know more about why > it happened. What caused us to do something that dumb. The pseudos for PL_sv_yes and PL_sv_no are assigned to floating point registers in the greg pass. In other identical rtl, the pseudos are allocated to general registers. The routine has quite a few pseudos (~667). The following little test program duplicates the code where we assign to floating point registers but in this case general register end up being used as expected. typedef struct sv SV; extern SV PL_sv_yes; extern SV PL_sv_no; struct sv { void * sv_any; unsigned int sv_refcnt; unsigned int sv_flags; }; SV * foo (ans) int ans; { return ((ans) ? &PL_sv_yes : &PL_sv_no); } This generates code like: cmpib,= 0,%r26,L$0002 addil LT'PL_sv_no,%r19 addil LT'PL_sv_yes,%r19 bve (%r2) ldw RT'PL_sv_yes(%r1),%r28 L$0002 bve (%r2) ldw RT'PL_sv_no(%r1),%r28 However, the code from the actual perl function looks like: cmpib,= 0,%r3,L$1012 addil LT'PL_sv_no,%r27 addil LT'PL_sv_yes,%r27 b L$1013 fldd RT'PL_sv_yes(%r1),%fr22 L$1012 fldd RT'PL_sv_no(%r1),%fr22 L$1013 fstd %fr22,-272(%r30) b L$0783 ldd -272(%r30),%r25 [...] L$1017 copy %r28,%r25 L$0783 copy %r25,%r28 [restore registers and return] Thus, it is clear that the compiler somehow failed to find that it could use %r28 instead of %fr22 and %r25. There are probably more paths to the return but it seems like something is wrong. I guess also the cost to free up a general register must have been greater than 16 in the perl code. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <no.id>]
* Re: gcc-64 on HP-UX 11.00 [not found] <no.id> @ 2002-04-10 15:30 ` John David Anglin 2002-04-11 10:25 ` John David Anglin 2002-04-15 13:39 ` John David Anglin 2 siblings, 0 replies; 32+ messages in thread From: John David Anglin @ 2002-04-10 15:30 UTC (permalink / raw) To: John David Anglin; +Cc: h.m.brand, gcc > > The latest 'snapshot' as in gcc-20020408.tar.bz2 > > I'll try the current cvs. I don't get the warnings or the seg fault. Have you got a recent header and libc patch installed on your system? I have PHCO_23963 and PHCO_25707. You will need to figure out where the warnings are coming from by looking at the cpp output. Some of the warnings seem to be from the macro definition for obstack_free in include/obstack.h. The cast to int might be a problem on hppa64 # if defined __STDC__ && __STDC__ # define obstack_free(h,obj) \ ( (h)->temp = (char *) (obj) - (char *) (h)->chunk, \ (((h)->temp > 0 && (h)->temp < (h)->chunk_limit - (char *) (h)->chunk)\ ? (int) ((h)->next_free = (h)->object_base \ = (h)->temp + (char *) (h)->chunk) \ : (((obstack_free) ((h), (h)->temp + (char *) (h)->chunk), 0), 0))) since pointers are 64bit and ints 32bit. This is probably not the problem since the function version of obstack_free returns void. What version of cc do you have? Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 [not found] <no.id> 2002-04-10 15:30 ` John David Anglin @ 2002-04-11 10:25 ` John David Anglin 2002-04-11 10:43 ` H.Merijn Brand 2002-04-11 11:04 ` law 2002-04-15 13:39 ` John David Anglin 2 siblings, 2 replies; 32+ messages in thread From: John David Anglin @ 2002-04-11 10:25 UTC (permalink / raw) To: John David Anglin; +Cc: h.m.brand, gcc, law > In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David Anglin > " writes: > > Gcc doesn't generate inline plabels on the PA. It would save one insn > > and one data location if we could use these selectors. However, there > > have been problems with them in 32bit land for years. I think the > > current assembler can handle them but the SOM linker still doesn't > > handle them. > Actually the SOM linker can handle them, but there are corner cases with > very large executables where it's impossible for the SOM linker to properly > fixup an inline plabel. For that reason we stopped using them based on > a recommendation from HP. Interesting. The problem might be in the dynamic loader. In the research I did for this patch <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00394.html>, I tried using inline plabels with both the HP and GNU assembler/linkers since this would have made the definition of ASM_OUTPUT_MI_THUNK considerably simpler. The HP assembler/linker compiled my little test PIC program with inline plabels. However, when I executed it, the address loaded was not the address of a function descriptor for the thunk target function. GAS didn't like the LTP/RTP selectors at all. Thus, I was forced to create a plabel in the data section. It was a bit tricky to do this in a manner that was compatible with both hpux and linux. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-11 10:25 ` John David Anglin @ 2002-04-11 10:43 ` H.Merijn Brand 2002-04-11 11:04 ` law 1 sibling, 0 replies; 32+ messages in thread From: H.Merijn Brand @ 2002-04-11 10:43 UTC (permalink / raw) To: John David Anglin; +Cc: gcc, law On Thu 11 Apr 2002 19:14, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David Anglin > > " writes: > > > Gcc doesn't generate inline plabels on the PA. It would save one insn > > > and one data location if we could use these selectors. However, there > > > have been problems with them in 32bit land for years. I think the > > > current assembler can handle them but the SOM linker still doesn't > > > handle them. > > Actually the SOM linker can handle them, but there are corner cases with > > very large executables where it's impossible for the SOM linker to properly > > fixup an inline plabel. For that reason we stopped using them based on > > a recommendation from HP. > > Interesting. The problem might be in the dynamic loader. In the research > I did for this patch <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00394.html>, > I tried using inline plabels with both the HP and GNU assembler/linkers > since this would have made the definition of ASM_OUTPUT_MI_THUNK considerably > simpler. The HP assembler/linker compiled my little test PIC program > with inline plabels. However, when I executed it, the address loaded was > not the address of a function descriptor for the thunk target function. > GAS didn't like the LTP/RTP selectors at all. Thus, I was forced to create > a plabel in the data section. It was a bit tricky to do this in a manner > that was compatible with both hpux and linux. I'm off now. If you want me to do more tests, please leave instructions on the door when you leave. No problems with downloading another source tree, as long as it is http https or ftp -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-11 10:25 ` John David Anglin 2002-04-11 10:43 ` H.Merijn Brand @ 2002-04-11 11:04 ` law 1 sibling, 0 replies; 32+ messages in thread From: law @ 2002-04-11 11:04 UTC (permalink / raw) To: John David Anglin; +Cc: h.m.brand, gcc In message <200204111714.g3BHEf2h000643@hiauly1.hia.nrc.ca>, "John David Anglin" writes: > Interesting. The problem might be in the dynamic loader. It was definitely the linker. If I recall correctly the problem was related to the need for the linker to rewrite the inline plabel sequence when the plabel was satisfied from a shared library with an insanely large PLT. jeff ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 [not found] <no.id> 2002-04-10 15:30 ` John David Anglin 2002-04-11 10:25 ` John David Anglin @ 2002-04-15 13:39 ` John David Anglin 2002-04-16 13:14 ` law 2 siblings, 1 reply; 32+ messages in thread From: John David Anglin @ 2002-04-15 13:39 UTC (permalink / raw) To: John David Anglin; +Cc: law, h.m.brand, gcc > However, the code from the actual perl function looks like: > > cmpib,= 0,%r3,L$1012 > addil LT'PL_sv_no,%r27 > addil LT'PL_sv_yes,%r27 > b L$1013 > fldd RT'PL_sv_yes(%r1),%fr22 > L$1012 > fldd RT'PL_sv_no(%r1),%fr22 > L$1013 > fstd %fr22,-272(%r30) > b L$0783 > ldd -272(%r30),%r25 > [...] > L$1017 > copy %r28,%r25 > L$0783 > copy %r25,%r28 > [restore registers and return] I tested this with gcc 3.0.3 -O -mpa-risc-2-0 -fPIC (32bit) and the code is: cmpib,= 0,%r28,L$0940 addil LT'PL_sv_yes,%r19 b L$0733 ldw RT'PL_sv_yes(%r1),%r28 L$0940 addil LT'PL_sv_no,%r19 b L$0733 ldw RT'PL_sv_no(%r1),%r28 So, this worked with 3.0.3 and we have a regression. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-15 13:39 ` John David Anglin @ 2002-04-16 13:14 ` law 2002-04-16 15:25 ` John David Anglin 0 siblings, 1 reply; 32+ messages in thread From: law @ 2002-04-16 13:14 UTC (permalink / raw) To: John David Anglin; +Cc: h.m.brand, gcc In message <200204152027.g3FKRLuZ009642@hiauly1.hia.nrc.ca>, "John David Anglin " writes: > > However, the code from the actual perl function looks like: > > > > cmpib,= 0,%r3,L$1012 > > addil LT'PL_sv_no,%r27 > > addil LT'PL_sv_yes,%r27 > > b L$1013 > > fldd RT'PL_sv_yes(%r1),%fr22 > > L$1012 > > fldd RT'PL_sv_no(%r1),%fr22 > > L$1013 > > fstd %fr22,-272(%r30) > > b L$0783 > > ldd -272(%r30),%r25 > > [...] > > L$1017 > > copy %r28,%r25 > > L$0783 > > copy %r25,%r28 > > [restore registers and return] > > I tested this with gcc 3.0.3 -O -mpa-risc-2-0 -fPIC (32bit) and the code is: > > cmpib,= 0,%r28,L$0940 > addil LT'PL_sv_yes,%r19 > b L$0733 > ldw RT'PL_sv_yes(%r1),%r28 > L$0940 > addil LT'PL_sv_no,%r19 > b L$0733 > ldw RT'PL_sv_no(%r1),%r28 > > So, this worked with 3.0.3 and we have a regression. I don't doubt that it worked in the past. My point is that selecting an FP register to hold an address like this is an exceedingly bad thing to do. In fact, not assigning the value to a register and instead leaving it in memory is actually cheaper than assigning it to an FP register. In fact, from the fragments, it looks like we did something insanely stupid, why don't we assign the value to %r28 or %r25? jeff ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-16 13:14 ` law @ 2002-04-16 15:25 ` John David Anglin 0 siblings, 0 replies; 32+ messages in thread From: John David Anglin @ 2002-04-16 15:25 UTC (permalink / raw) To: law; +Cc: h.m.brand, gcc > I don't doubt that it worked in the past. My point is that selecting an My point in looking at whether it worked in the past was simply to determine whether this was in fact a regression, and whether a fix could be applied to the 3.1 branch. > FP register to hold an address like this is an exceedingly bad thing to > do. In fact, not assigning the value to a register and instead leaving it > in memory is actually cheaper than assigning it to an FP register. I don't quite follow that logic. Two insns are needed to load the address and the result must end up in a register. You can't load the address directly to memory. It takes a couple of insns to copy the result from the FP register to a general register. Generally, I guess this must be weighed against the cost of freeing up a general general. > In fact, from the fragments, it looks like we did something insanely stupid, > why don't we assign the value to %r28 or %r25? I agree it seems very dumb. We have the following rtl at the end of function after lreg: (insn 3088 3494 3091 (set (reg/i:DI 28 %r28) (reg/f:DI 66)) 119 {*pa.md:3106} (nil) (expr_list:REG_DEAD (reg/f:DI 66) (nil))) DI 66 is set in multiple places. It seems the compiler doesn't recognize opportunities to replace DI 66 with DI 28, and so on. Jeff, I will send you gv.i offline so that you can look at the problem in more detail. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 @ 2002-04-04 12:02 John David Anglin 0 siblings, 0 replies; 32+ messages in thread From: John David Anglin @ 2002-04-04 12:02 UTC (permalink / raw) To: gcc > As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary > target site. I've got no trouble building gcc in 32 bit mode, but building a > 64bit gcc is still almost impossible. Can you be more specific? I think that once you get a good set of tools installed you won't have any trouble building 64bit gcc. This is not to say that that there aren't lots of issues with hppa64 but I am not having problems doing builds anymore. > I've got > > The latest HP-UX 11.00 with the latest patches > The latest C compiler (B.11.11.04 HP C/ANSI C Compiler) > Several ports of gcc > 3.0.4/32 > 3.0.1/64 > 3.0.2/64 > binutils-2.11.90/64 > binutils-2.12/64 Here are my suggestions. Use the latest binutils. It has fixes that affect hppa64. Don't use 2.11.90. Build it with the HP ANSI compiler (ie, use "-Ae +DA2.0W" in your CFLAGS). Gcc may miscompile the linker causing it to dump core linking shared libraries. Whether this is still a problem, I'm not sure. For gcc, use either the 3.1 branch or the unstable 3.2 trunk. You should be able to bootstrap it using CC="cc -Ae +DA2.0W" or with a working version of gcc for hppa64. Use the GNU binutils and specify the locations for as and ld using --with-as and --with-ld. Run the testsuite to see if things are working. There are some problems with shared libraries so it's probably better not to specify --enable-shared in your configure options. These are the gcc configure options that I use: --host=hppa64-hp-hpux11.11 --with-gnu-as --with-as=/opt/gnu64/bin/as --with-gnu-ld --with-ld=/opt/gnu64/bin/ld --disable-nls --prefix=/opt/gnu64 Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* gcc-64 on HP-UX 11.00
@ 2002-04-04 2:03 H.Merijn Brand
2002-04-04 8:22 ` law
[not found] ` <200204041958.g34JwTbA011272@hiauly1.hia.nrc.ca>
0 siblings, 2 replies; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-04 2:03 UTC (permalink / raw)
To: gcc
As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary
target site. I've got no trouble building gcc in 32 bit mode, but building a
64bit gcc is still almost impossible.
Is there a preferred way to build from the latest snapshot? Do you want more
specific messages about the problems?
I'm not into the gcc sources, but somehow I seem to be willing to function as
a compile farm.
I've got
The latest HP-UX 11.00 with the latest patches
The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
Several ports of gcc
3.0.4/32
3.0.1/64
3.0.2/64
binutils-2.11.90/64
binutils-2.12/64
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: gcc-64 on HP-UX 11.00 2002-04-04 2:03 H.Merijn Brand @ 2002-04-04 8:22 ` law [not found] ` <200204041958.g34JwTbA011272@hiauly1.hia.nrc.ca> 1 sibling, 0 replies; 32+ messages in thread From: law @ 2002-04-04 8:22 UTC (permalink / raw) To: H.Merijn Brand; +Cc: gcc In message <20020404113717.E7B3.H.M.BRAND@hccnet.nl>, "H.Merijn Brand" writes: > As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary > target site. I've got no trouble building gcc in 32 bit mode, but building a > 64bit gcc is still almost impossible. Correct. 32bit builds should go fine. 64bit builds are a pain. > Is there a preferred way to build from the latest snapshot? Do you want more > specific messages about the problems? The preferred way is to always have a previous 64bit compiler available -- building the 64bit PA tools is exceedingly hard using a 32bit GCC or the HP provided compilers. Even if you have 64bit PA tools, you're going to run into problems as that toolchain doesn't receive nearly the attention that the 32bit toolchain receives. jeff ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <200204041958.g34JwTbA011272@hiauly1.hia.nrc.ca>]
* Re: gcc-64 on HP-UX 11.00 [not found] ` <200204041958.g34JwTbA011272@hiauly1.hia.nrc.ca> @ 2002-04-05 4:51 ` H.Merijn Brand 2002-04-05 5:01 ` H.Merijn Brand 2002-04-05 9:19 ` John David Anglin 0 siblings, 2 replies; 32+ messages in thread From: H.Merijn Brand @ 2002-04-05 4:51 UTC (permalink / raw) To: John David Anglin; +Cc: gcc, bug-binutils [-- Attachment #1: Type: text/plain, Size: 11620 bytes --] On Thu 04 Apr 2002 21:58, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary > > target site. I've got no trouble building gcc in 32 bit mode, but building a > > 64bit gcc is still almost impossible. > > Can you be more specific? I think that once you get a good set of tools > installed you won't have any trouble building 64bit gcc. This is not to Then my tools are probably no good ;) > say that that there aren't lots of issues with hppa64 but I am not having > problems doing builds anymore. But you might have /more/ GNU stuff installed in default locations than I have. For example, in the configuration I'll show shortly, it barfs on unsatisfied symbol '__umoddi3', which can be found in libgcc.a, which I do not have installed in a default location, and since I'm building with HPc, it won't find it without hints. Now if I set LDFLAGS="-L/usr/local/pa20_64/lib -lgcc" where libgcc can be found in my situation, it is put *before* the libs, making the needed symbols unfindable, so I commented out LDFLAGS and put in LIBS=/usr/local/pa20_64/lib/libgcc.a FYI when reading on, /usr/local/pa20_64 is a symlink to /wrk/pa20_64 because that LV has more space to play with. > > I've got > > > > The latest HP-UX 11.00 with the latest patches > > The latest C compiler (B.11.11.04 HP C/ANSI C Compiler) > > Several ports of gcc > > 3.0.4/32 > > 3.0.1/64 > > 3.0.2/64 > > binutils-2.11.90/64 > > binutils-2.12/64 > > Here are my suggestions. Use the latest binutils. It has fixes that > affect hppa64. Don't use 2.11.90. Build it with the HP ANSI compiler > (ie, use "-Ae +DA2.0W" in your CFLAGS). Gcc may miscompile the > linker causing it to dump core linking shared libraries. Whether > this is still a problem, I'm not sure. I used --8<--- Conf-64 #!/usr/bin/sh export CONFIG_SITE= export CC=cc export CFLAGS="-Ae -O +DA2.0W" #export LDFLAGS="-L/usr/local/pa20_64/lib -lgcc" export LIBS=/usr/local/pa20_64/lib/libgcc.a export PATH=. export PATH=$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin export PATH=$PATH"":/pro/local/bin:/pro/bin export PATH=$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin export PATH=$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin configure \ --prefix=/wrk/pa20_64 --with-local-prefix=/wrk/pa20_64 \ --disable-shared \ --disable-nls \ --enable-multilib \ --enable-threads -->8--- But needed the followin patches: --8<--- binutils-2.12.diff --- binutils-2.12.org/configure.in 2002-03-08 20:45:10.000000000 +0100 +++ binutils-2.12/configure.in 2002-04-05 13:17:26.000000000 +0200 @@ -722,8 +722,10 @@ hppa*-*-*elf* | \ hppa*-*-linux-gnu* | \ hppa*-*-lites* | \ + hppa*2.0w*-*-* | \ hppa*64*-*-*) # Do configure ld/binutils/gas for this case. + echo " ############# 64bit ################### ($noconfigdirs)" >&2 ;; hppa*-*-*) # HP's C compiler doesn't handle Emacs correctly (but on BSD and Mach --- binutils-2.12.org/bfd/config.bfd 2002-02-13 21:45:46.000000000 +0100 +++ binutils-2.12/bfd/config.bfd 2002-04-05 13:10:23.000000000 +0200 @@ -292,6 +292,7 @@ targ_defvec=bfd_elf64_hppa_linux_vec targ_selvecs=bfd_elf64_hppa_vec ;; + hppa*2.0w*-*-hpux11* | \ hppa*64*-*-hpux11*) targ_defvec=bfd_elf64_hppa_vec targ_selvecs=bfd_elf64_hppa_linux_vec --- binutils-2.12.org/bfd/configure.host 2002-01-22 01:47:21.000000000 +0100 +++ binutils-2.12/bfd/configure.host 2002-04-05 13:10:41.000000000 +0200 @@ -21,6 +21,7 @@ alpha*-*-*) host64=true; HOST_64BIT_TYPE=long ;; +hppa*2.0w*-*-hpux* | \ hppa*64*-*-hpux*) HDEFINES=-DHOST_HPPAHPUX; host64=true; HOST_64BIT_TYPE=long ;; hppa*-*-hpux*) HDEFINES=-DHOST_HPPAHPUX ;; --- binutils-2.12.org/gas/configure 2002-02-26 11:35:27.000000000 +0100 +++ binutils-2.12/gas/configure 2002-04-05 13:11:01.000000000 +0200 @@ -2377,6 +2377,7 @@ hppa-*-osf*) fmt=som em=hppa ;; hppa-*-rtems*) fmt=elf em=hppa ;; hppa-*-hpux11*) case ${cpu} in + hppa*2.0w* | \ hppa*64*) fmt=elf em=hppa64 ;; hppa*) --- binutils-2.12.org/gas/configure.in 2002-02-26 11:35:27.000000000 +0100 +++ binutils-2.12/gas/configure.in 2002-04-05 13:11:17.000000000 +0200 @@ -227,6 +227,7 @@ hppa-*-osf*) fmt=som em=hppa ;; hppa-*-rtems*) fmt=elf em=hppa ;; hppa-*-hpux11*) case ${cpu} in + hppa*2.0w* | \ hppa*64*) fmt=elf em=hppa64 ;; hppa*) --- binutils-2.12.org/ld/configure.tgt 2002-02-20 06:26:22.000000000 +0100 +++ binutils-2.12/ld/configure.tgt 2002-04-05 13:07:56.000000000 +0200 @@ -309,6 +309,7 @@ m68*-*-rtemscoff*) targ_emul=m68kcoff ;; m68*-*-rtems*) targ_emul=m68kelf ;; hppa*64*-*-linux-gnu*) targ_emul=hppa64linux ;; +hppa*2.0w*-*) targ_emul=elf64hppa ;; hppa*64*-*) targ_emul=elf64hppa ;; hppa*-*-linux-gnu*) targ_emul=hppalinux ;; hppa*-*-*elf*) targ_emul=hppaelf ;; -->8--- Conf-64 now finishes to the end. Now I use --8<--- Build-64 #!/usr/bin/sh export CONFIG_SITE= export CC=cc export CFLAGS="-Ae -O +DA2.0W" #export LDFLAGS="-L/usr/local/pa20_64/lib -lgcc" export LIBS=/usr/local/pa20_64/lib/libgcc.a export PATH=. export PATH=$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin export PATH=$PATH"":/pro/local/bin:/pro/bin export PATH=$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin export PATH=$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin make -->8--- After the first run I changed 'make' to 'make -i' and reran the log is attached a5:/wrk/pa20_64/bin 189 > find * -newer ld.pl -type f | xargs file addr2line: ELF-64 executable object file - PA-RISC 2.0 (LP64) ar: ELF-64 executable object file - PA-RISC 2.0 (LP64) as: ELF-64 executable object file - PA-RISC 2.0 (LP64) c++filt: ELF-64 executable object file - PA-RISC 2.0 (LP64) gas: ELF-64 executable object file - PA-RISC 2.0 (LP64) gasp: ELF-64 executable object file - PA-RISC 2.0 (LP64) gprof: ELF-64 executable object file - PA-RISC 2.0 (LP64) ld: ELF-64 executable object file - PA-RISC 2.0 (LP64) nm: ELF-64 executable object file - PA-RISC 2.0 (LP64) objcopy: ELF-64 executable object file - PA-RISC 2.0 (LP64) objdump: ELF-64 executable object file - PA-RISC 2.0 (LP64) ranlib: ELF-64 executable object file - PA-RISC 2.0 (LP64) readelf: ELF-64 executable object file - PA-RISC 2.0 (LP64) size: ELF-64 executable object file - PA-RISC 2.0 (LP64) strings: ELF-64 executable object file - PA-RISC 2.0 (LP64) strip: ELF-64 executable object file - PA-RISC 2.0 (LP64) a5:/wrk/pa20_64/bin 190 > Now I should have a working set of binutils, I guess (FTR, I built my previous set with gcc-3.0.2/64) > For gcc, use either the 3.1 branch or the unstable 3.2 trunk. You I'll go for the gcc-20020401.tar.bz2 version I snatched from snapshot > should be able to bootstrap it using CC="cc -Ae +DA2.0W" or with > a working version of gcc for hppa64. Use the GNU binutils and specify > the locations for as and ld using --with-as and --with-ld. Run > the testsuite to see if things are working. There are some problems > with shared libraries so it's probably better not to specify > --enable-shared in your configure options. > > These are the gcc configure options that I use: > > --host=hppa64-hp-hpux11.11 --with-gnu-as --with-as=/opt/gnu64/bin/as That's a HP-UX 11i > --with-gnu-ld --with-ld=/opt/gnu64/bin/ld --disable-nls --prefix=/opt/gnu64 This is what I went for --8<--- Conf-64 #!/usr/bin/sh export CONFIG_SITE= export CC="cc -Ae +DA2.0W" export PATH=.:/u/usr/merijn/bin/private:/u/usr/merijn/bin export PATH=$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11 export PATH=$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin export PATH=$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin rm -rf obj mkdir obj cd obj ../src/configure \ --enable-languages=gcc \ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \ --with-gnu-as \ --with-gnu-ld \ --disable-shared \ --disable-nls \ --enable-multilib \ --enable-threads \ --with-system-zlib echo "" echo "Now start 'Build-64'" -->8--- Of course after patchin with --8<--- --- src/configure.in.org 2002-04-05 14:16:10.000000000 +0200 +++ src/configure.in 2002-04-05 14:16:31.000000000 +0200 @@ -284,6 +284,7 @@ # hpux11 in 64bit mode has libraries in a weird place. Arrange to find # them automatically. case "${host}" in + hppa*2.0w*-*-hpux11* | \ hppa*64*-*-hpux11*) withoptions="$withoptions -x-libraries=/usr/lib/pa20_64 -x-includes=/usr/X11R6/include" ;; @@ -567,6 +568,7 @@ noconfigdirs="" case "${host}" in + hppa*2.0w*-*-* |\ hppa*64*-*-*) noconfigdirs="$noconfigdirs byacc" ;; @@ -771,6 +773,7 @@ hppa*-*-*elf* | \ parisc*-*-linux* | hppa*-*-linux* | \ hppa*-*-lites* | \ + hppa*2.0w*-*-* | \ hppa*64*-*-*) noconfigdirs="$noconfigdirs ${libgcj}" # Do configure ld/binutils/gas for this case. --- src/gcc/config.gcc.org 2002-04-05 14:14:51.000000000 +0200 +++ src/gcc/config.gcc 2002-04-05 14:14:58.000000000 +0200 @@ -917,6 +917,7 @@ install_headers_dir=install-headers-cpio use_collect2=yes ;; +hppa*2.0w*-*-hpux11* | \ hppa*64*-*-hpux11*) xm_defines=POSIX tm_file="pa/pa64-start.h ${tm_file} pa/pa64-regs.h pa/long_double.h pa/elf.h pa/pa-hpux.h pa/pa-hpux11.h pa/pa-64.h pa/pa64-hpux.h" -->8--- Now I use --8<--- Build-64 #!/usr/bin/sh export CONFIG_SITE= export CC="cc -Ae +DA2.0W" export PATH=.:/u/usr/merijn/bin/private:/u/usr/merijn/bin export PATH=$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11 export PATH=$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin export PATH=$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin cd obj make bootstrap-lean -->8--- The build comes amazingly far, but core dumps like echo "int xxy_us_dummy;" >tmp-dum.c ./xgcc -B./ -B/usr/local/pa20_64/hppa2.0w-hp-hpux11.00/bin/ -isystem /usr/local/pa20_64/hppa2.0w-hp-hpux11.00/include -isystem /usr/local/pa20_64/hppa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c cc1: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. make[2]: *** [s-under] Error 1 make[2]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc' make: *** [bootstrap-lean] Error 2 No core dump. Should I go on? -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org [-- Attachment #2: binutils-2.12-Build-64.log.gz --] [-- Type: application/octet-stream, Size: 3865 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-05 4:51 ` H.Merijn Brand @ 2002-04-05 5:01 ` H.Merijn Brand 2002-04-05 9:19 ` John David Anglin 1 sibling, 0 replies; 32+ messages in thread From: H.Merijn Brand @ 2002-04-05 5:01 UTC (permalink / raw) To: John David Anglin; +Cc: gcc, bug-binutils [-- Attachment #1: Type: text/plain, Size: 385 bytes --] On Fri 05 Apr 2002 14:49, H.Merijn Brand <h.m.brand@hccnet.nl> wrote: Log for gcc was missing -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/ [-- Attachment #2: gcc-Build-64.log.gz --] [-- Type: application/octet-stream, Size: 17282 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-05 4:51 ` H.Merijn Brand 2002-04-05 5:01 ` H.Merijn Brand @ 2002-04-05 9:19 ` John David Anglin 2002-04-07 7:26 ` H.Merijn Brand 2002-04-10 3:39 ` H.Merijn Brand 1 sibling, 2 replies; 32+ messages in thread From: John David Anglin @ 2002-04-05 9:19 UTC (permalink / raw) To: H.Merijn Brand; +Cc: gcc, bug-binutils > > Can you be more specific? I think that once you get a good set of tools > > installed you won't have any trouble building 64bit gcc. This is not to > > Then my tools are probably no good ;) From your comments below, I would say they are incorrectly installed. > > > say that that there aren't lots of issues with hppa64 but I am not having > > problems doing builds anymore. > > But you might have /more/ GNU stuff installed in default locations than I h= > ave. > For example, in the configuration I'll show shortly, it barfs on unsatisfie= > d > symbol '__umoddi3', which can be found in libgcc.a, which I do not have > installed in a default location, and since I'm building with HPc, it won't > find it without hints. Now if I set LDFLAGS=3D"-L/usr/local/pa20_64/lib -lg= > cc" If you use HP cc, libgcc.a should not be needed. It gets built in stage1 by ./xgcc and then installed with the compiler. You need to select a prefix to install your 64-bit tools in (e.g., /opt/gnu64). The prefix can be anywhere but I keep the 64-bit stuff separate from 32-bit som stuff. I build and install my 64-bit binutils tools to the same directory and have /opt/gnu64/bin as the first component in PATH to ensure that 64-bit tools are used when I do a 64-bit build. You should not have to play with LDFLAGS to bootstrap the compiler. Regarding tools, suggest using GNU make. You should install a 64-bit versions of binutils. It may also be useful to build bash, bison, gawk, texinfo, perl, sed, and possibly autoconf (2.13). You can build these with either the HP compiler or 32-bit gcc. > where libgcc can be found in my situation, it is put *before* the libs, mak= > ing > the needed symbols unfindable, so I commented out LDFLAGS and put in > LIBS=3D/usr/local/pa20_64/lib/libgcc.a > > FYI when reading on, /usr/local/pa20_64 is a symlink to /wrk/pa20_64 becaus= > e > that LV has more space to play with. > > > > I've got > > >=20 > > > The latest HP-UX 11.00 with the latest patches > > > The latest C compiler (B.11.11.04 HP C/ANSI C Compiler) > > > Several ports of gcc > > > 3.0.4/32 > > > 3.0.1/64 > > > 3.0.2/64 > > > binutils-2.11.90/64 > > > binutils-2.12/64 > >=20 > > Here are my suggestions. Use the latest binutils. It has fixes that > > affect hppa64. Don't use 2.11.90. Build it with the HP ANSI compiler > > (ie, use "-Ae +DA2.0W" in your CFLAGS). Gcc may miscompile the > > linker causing it to dump core linking shared libraries. Whether > > this is still a problem, I'm not sure. > > I used > --8<--- Conf-64 > #!/usr/bin/sh > > export CONFIG_SITE=3D > export CC=3Dcc Change this to export CC="cc -Ae +DA2.0W" > export CFLAGS=3D"-Ae -O +DA2.0W" > #export LDFLAGS=3D"-L/usr/local/pa20_64/lib -lgcc" > export LIBS=3D/usr/local/pa20_64/lib/libgcc.a Delete these. > export PATH=3D. > export PATH=3D$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin > export PATH=3D$PATH"":/pro/local/bin:/pro/bin > export PATH=3D$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin > export PATH=3D$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langt= > ools/bin > export PATH=3D$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin > > configure \ > --prefix=3D/wrk/pa20_64 --with-local-prefix=3D/wrk/pa20_64 \ > --disable-shared \ > --disable-nls \ > --enable-multilib \ > --enable-threads Use a modification of what I sent. --with-local-prefix probably isn't needed. You don't need --enable-multilib or --enable-threads. There isn't any thread support yet and no multilibs. > -->8--- > The patch below is incorrect. The hppa2.0w-hp-hpux11* target is actually the 32-bit som target on a 2.0w machine. It shouldn't be changed to 64-bit. Same for gcc config. You want to configure binutils with something like --host=hppa64-hp-hpux11.11 --prefix=/opt/gnu64 --disable-nls If you are using a 11.00 system --host should be hppa64-hp-hpux11.00. You need to specify --host, or a complete set of --host, --build and --target to do a 64-bit build. The default guess is for 32-bit tools. > But needed the followin patches: > --8<--- binutils-2.12.diff > --- binutils-2.12.org/configure.in 2002-03-08 20:45:10.000000000 +0100 > +++ binutils-2.12/configure.in 2002-04-05 13:17:26.000000000 +0200 > @@ -722,8 +722,10 @@ > hppa*-*-*elf* | \ > hppa*-*-linux-gnu* | \ > hppa*-*-lites* | \ > + hppa*2.0w*-*-* | \ > hppa*64*-*-*) [...] > > These are the gcc configure options that I use: > >=20 > > --host=3Dhppa64-hp-hpux11.11 --with-gnu-as --with-as=3D/opt/gnu64/bin/as > =20 > That's a HP-UX 11i Yes. It works identically to 11.00. > =20 > > --with-gnu-ld --with-ld=3D/opt/gnu64/bin/ld --disable-nls --prefix=3D/opt= > /gnu64 > > This is what I went for > --8<--- Conf-64 > #!/usr/bin/sh > > export CONFIG_SITE=3D > export CC=3D"cc -Ae +DA2.0W" > export PATH=3D.:/u/usr/merijn/bin/private:/u/usr/merijn/bin > export PATH=3D$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11 > export PATH=3D$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin > export PATH=3D$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/i= > make/bin > export PATH=3D$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin When you do a 64-bit build, make sure that the 64-bit tools are before the 32-bit and HP tools. Some have the same name so you want to be sure that your using the correct tools. The HP compiler knows how to find its tools. > > rm -rf obj > mkdir obj > cd obj > =2E./src/configure \ > --enable-languages=3Dgcc \ > --prefix=3D/usr/local/pa20_64 --with-local-prefix=3D/usr/local/pa20_64 = > \ > --with-gnu-as \ > --with-gnu-ld \ > --disable-shared \ > --disable-nls \ > --enable-multilib \ > --enable-threads \ > --with-system-zlib > > echo "" > echo "Now start 'Build-64'" > -->8--- > Again, the patch below is wrong and unnecessary. You need to specify --host properly. I suggest removing --enable-multilib, --enable-threads and --with-system-zlib. The system zlib probably has the security bug. > > Of course after patchin with > --8<--- > --- src/configure.in.org 2002-04-05 14:16:10.000000000 +0200 > +++ src/configure.in 2002-04-05 14:16:31.000000000 +0200 > @@ -284,6 +284,7 @@ > # hpux11 in 64bit mode has libraries in a weird place. Arrange to find > # them automatically. > case "${host}" in > + hppa*2.0w*-*-hpux11* | \ > hppa*64*-*-hpux11*)=09 [...] > The build comes amazingly far, but core dumps like > > echo "int xxy_us_dummy;" >tmp-dum.c > =2E/xgcc -B./ -B/usr/local/pa20_64/hppa2.0w-hp-hpux11.00/bin/ -isystem /usr= > /local/pa20_64/hppa2.0w-hp-hpux11.00/include -isystem /usr/local/pa20_64/hp= > pa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c > cc1: internal error: Segmentation fault > No core dump. > > Should I go on? Retry following my suggestions. The important points are: 1) Use a common prefix for your tools (e.g., /usr/local/pa20_64). 2) Use --host=hppa64-hp-hpux11.00. 3) Export CC="cc -Ae +DA2.0W" for your initial builds of binutils and gcc. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-05 9:19 ` John David Anglin @ 2002-04-07 7:26 ` H.Merijn Brand 2002-04-07 12:17 ` John David Anglin 2002-04-10 3:39 ` H.Merijn Brand 1 sibling, 1 reply; 32+ messages in thread From: H.Merijn Brand @ 2002-04-07 7:26 UTC (permalink / raw) To: John David Anglin; +Cc: gcc, bug-binutils On Fri 05 Apr 2002 18:06, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > > Can you be more specific? I think that once you get a good set of tools > > > installed you won't have any trouble building 64bit gcc. This is not to > > > > Then my tools are probably no good ;) > > >From your comments below, I would say they are incorrectly installed. > > > > > > say that that there aren't lots of issues with hppa64 but I am not having > > > problems doing builds anymore. > > > > But you might have /more/ GNU stuff installed in default locations than I h= > > ave. > > For example, in the configuration I'll show shortly, it barfs on unsatisfie= > > d > > symbol '__umoddi3', which can be found in libgcc.a, which I do not have > > installed in a default location, and since I'm building with HPc, it won't > > find it without hints. Now if I set LDFLAGS=3D"-L/usr/local/pa20_64/lib -lg= > > cc" > > If you use HP cc, libgcc.a should not be needed. It gets built in stage1 > by ./xgcc and then installed with the compiler. was baffled too. > You need to select a prefix to install your 64-bit tools in (e.g., /opt/gnu64). I use /wrk/pa20_64 and have /usr/local/pa20_64 symlinked to it > The prefix can be anywhere but I keep the 64-bit stuff separate from 32-bit So do I > som stuff. I build and install my 64-bit binutils tools to the same > directory and have /opt/gnu64/bin as the first component in PATH to ensure > that 64-bit tools are used when I do a 64-bit build. Same here > You should not have to play with LDFLAGS to bootstrap the compiler. Found that out too. > Regarding tools, suggest using GNU make. You should install a 64-bit GNU make installed as basic make on *ALL* our systems. Native make's just won't do :) > versions of binutils. It may also be useful to build bash, bison, gawk, > texinfo, perl, sed, and possibly autoconf (2.13). You can build these > with either the HP compiler or 32-bit gcc. bash only on cywgin (I'm a tcsh addict) bison 1.34 all over. I'm helping the bison guys with testing on HP-UX and AIX, so I guess I must be up to date gawk same as make texinfo nowhere. I *HATE* the info style of documenting, so I don't care if installing info stuff fails. I'd even prefer it to fail. I'd love to see it fallback to the good ol' man pages. perl hell, I'm a perl5-porter, so I've got several versions up and running, and the bleading edge version is smoke tested on all systems every day sed same as make autoconf I *try* to get a recent version installed, but HPUX and AIX are not the most wonderfull systems for this package. I /do/ have these installed, for gcc only. > > where libgcc can be found in my situation, it is put *before* the libs, mak= > > ing > > the needed symbols unfindable, so I commented out LDFLAGS and put in > > LIBS=3D/usr/local/pa20_64/lib/libgcc.a > > > > FYI when reading on, /usr/local/pa20_64 is a symlink to /wrk/pa20_64 becaus= > > e > > that LV has more space to play with. > > > > > > I've got > > > >=20 > > > > The latest HP-UX 11.00 with the latest patches > > > > The latest C compiler (B.11.11.04 HP C/ANSI C Compiler) > > > > Several ports of gcc > > > > 3.0.4/32 > > > > 3.0.1/64 > > > > 3.0.2/64 > > > > binutils-2.11.90/64 > > > > binutils-2.12/64 > > >=20 > > > Here are my suggestions. Use the latest binutils. It has fixes that > > > affect hppa64. Don't use 2.11.90. Build it with the HP ANSI compiler > > > (ie, use "-Ae +DA2.0W" in your CFLAGS). Gcc may miscompile the > > > linker causing it to dump core linking shared libraries. Whether > > > this is still a problem, I'm not sure. > > > > I used > > --8<-- Conf-64 > > #!/usr/bin/sh > > > > export CONFIG_SITE=3D > > export CC=3Dcc > > Change this to > export CC="cc -Ae +DA2.0W" I will > > export CFLAGS=3D"-Ae -O +DA2.0W" > > #export LDFLAGS=3D"-L/usr/local/pa20_64/lib -lgcc" > > export LIBS=3D/usr/local/pa20_64/lib/libgcc.a > > Delete these. Consider it done > > export PATH=3D. > > export PATH=3D$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin > > export PATH=3D$PATH"":/pro/local/bin:/pro/bin > > export PATH=3D$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin > > export PATH=3D$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langt= > > ools/bin > > export PATH=3D$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin > > > > configure \ > > --prefix=3D/wrk/pa20_64 --with-local-prefix=3D/wrk/pa20_64 \ > > --disable-shared \ > > --disable-nls \ > > --enable-multilib \ > > --enable-threads > > Use a modification of what I sent. --with-local-prefix probably isn't > needed. You don't need --enable-multilib or --enable-threads. There > isn't any thread support yet and no multilibs. Grrr, but at least it proves I read /beyond/ the surface. > > -->8--- > > > > The patch below is incorrect. The hppa2.0w-hp-hpux11* target is actually > the 32-bit som target on a 2.0w machine. It shouldn't be changed to > 64-bit. Same for gcc config. An auto-detect, or configure help would be nice then. I /did/ try with specifying the host like that, but also got stuck somewhere, so I thought this would be a more clean way to go. > You want to configure binutils with something like > > --host=hppa64-hp-hpux11.11 --prefix=/opt/gnu64 --disable-nls > > If you are using a 11.00 system --host should be hppa64-hp-hpux11.00. You > need to specify --host, or a complete set of --host, --build and --target > to do a 64-bit build. The default guess is for 32-bit tools. Systems are down now, expect some positive message early this week. > > But needed the followin patches: > > --8<-- binutils-2.12.diff > > --- binutils-2.12.org/configure.in 2002-03-08 20:45:10.000000000 +0100 > > +++ binutils-2.12/configure.in 2002-04-05 13:17:26.000000000 +0200 > > @@ -722,8 +722,10 @@ > > hppa*-*-*elf* | \ > > hppa*-*-linux-gnu* | \ > > hppa*-*-lites* | \ > > + hppa*2.0w*-*-* | \ > > hppa*64*-*-*) > > [...] > > > > These are the gcc configure options that I use: > > >=20 > > > --host=3Dhppa64-hp-hpux11.11 --with-gnu-as --with-as=3D/opt/gnu64/bin/as > > =20 > > That's a HP-UX 11i > > Yes. It works identically to 11.00. > > > =20 > > > --with-gnu-ld --with-ld=3D/opt/gnu64/bin/ld --disable-nls --prefix=3D/opt= > > /gnu64 > > > > This is what I went for > > --8<-- Conf-64 > > #!/usr/bin/sh > > > > export CONFIG_SITE=3D > > export CC=3D"cc -Ae +DA2.0W" > > export PATH=3D.:/u/usr/merijn/bin/private:/u/usr/merijn/bin > > export PATH=3D$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11 > > export PATH=3D$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin > > export PATH=3D$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/i= > > make/bin > > export PATH=3D$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin > > When you do a 64-bit build, make sure that the 64-bit tools are before They are. > the 32-bit and HP tools. Some have the same name so you want to be sure > that your using the correct tools. The HP compiler knows how to find > its tools. As a side track, how much of what I specify during build is inherited in the compiler? Can the /wrk/pa20_64 be ported independent of the way I built it? Does the user that receives the dist need the same as and the same ld or can it use a different one? > > > > rm -rf obj > > mkdir obj > > cd obj > > =2E./src/configure \ > > --enable-languages=3Dgcc \ > > --prefix=3D/usr/local/pa20_64 --with-local-prefix=3D/usr/local/pa20_64 = > > \ > > --with-gnu-as \ > > --with-gnu-ld \ > > --disable-shared \ > > --disable-nls \ > > --enable-multilib \ > > --enable-threads \ > > --with-system-zlib > > > > echo "" > > echo "Now start 'Build-64'" > > -->8--- > > > > Again, the patch below is wrong and unnecessary. You need to specify > --host properly. I suggest removing --enable-multilib, --enable-threads > and --with-system-zlib. The system zlib probably has the security bug. No, all my zlib's are up to date. The security bug made me choose for this option in the first place. > > > > Of course after patchin with > > --8<-- > > --- src/configure.in.org 2002-04-05 14:16:10.000000000 +0200 > > +++ src/configure.in 2002-04-05 14:16:31.000000000 +0200 > > @@ -284,6 +284,7 @@ > > # hpux11 in 64bit mode has libraries in a weird place. Arrange to find > > # them automatically. > > case "${host}" in > > + hppa*2.0w*-*-hpux11* | \ > > hppa*64*-*-hpux11*)=09 > > [...] > > > The build comes amazingly far, but core dumps like > > > > echo "int xxy_us_dummy;" >tmp-dum.c > > =2E/xgcc -B./ -B/usr/local/pa20_64/hppa2.0w-hp-hpux11.00/bin/ -isystem /usr= > > /local/pa20_64/hppa2.0w-hp-hpux11.00/include -isystem /usr/local/pa20_64/hp= > > pa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c > > cc1: internal error: Segmentation fault > > > No core dump. > > > > Should I go on? > > Retry following my suggestions. The important points are: > > 1) Use a common prefix for your tools (e.g., /usr/local/pa20_64). > 2) Use --host=hppa64-hp-hpux11.00. > 3) Export CC="cc -Ae +DA2.0W" for your initial builds of binutils and gcc. Thanks so far. I'll keep you posted. -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-07 7:26 ` H.Merijn Brand @ 2002-04-07 12:17 ` John David Anglin 0 siblings, 0 replies; 32+ messages in thread From: John David Anglin @ 2002-04-07 12:17 UTC (permalink / raw) To: H.Merijn Brand; +Cc: gcc, bug-binutils > autoconf I *try* to get a recent version installed, but HPUX and AIX > are not the most wonderfull systems for this package. I /do/ > have these installed, for gcc only. Install 2.13 for gcc development. It's only needed if you need to update configure. It shouldn't be needed for normal builds if you start from a snapshot or use contrib/gcc_update. > As a side track, how much of what I specify during build is inherited in the > compiler? Can the /wrk/pa20_64 be ported independent of the way I built it? > Does the user that receives the dist need the same as and the same ld or can > it use a different one? They need to be feature compatible. There are various assembler and linker checks done by configure. If you are trying to build with --prefix=/wrk/pa20_64 and install the final dist to a different directory, there may be problems. The gcc driver has a builtin dependency on the specified installation directory and it uses this to locate library and header files. If you specify --with-as, then it expects to find the assembly in the specified location. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-05 9:19 ` John David Anglin 2002-04-07 7:26 ` H.Merijn Brand @ 2002-04-10 3:39 ` H.Merijn Brand 2002-04-10 11:21 ` John David Anglin 1 sibling, 1 reply; 32+ messages in thread From: H.Merijn Brand @ 2002-04-10 3:39 UTC (permalink / raw) To: John David Anglin; +Cc: gcc, bug-binutils [-- Attachment #1: Type: text/plain, Size: 4095 bytes --] On Fri 05 Apr 2002 18:06, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > Retry following my suggestions. The important points are: > > 1) Use a common prefix for your tools (e.g., /usr/local/pa20_64). [v] Done > 2) Use --host=hppa64-hp-hpux11.00. [v] Done > 3) Export CC="cc -Ae +DA2.0W" for your initial builds of binutils and gcc. [v] Done [v] Rebuilt and installed binutils-2.12 again [v] gcc still problematic - build log attached (it requests to be sent to the gcc people :) a5:/pro/3gl/GNU/gcc-3.0.4 129 > cat Conf-64 #!/usr/bin/sh export CONFIG_SITE= export CC="cc -Ae +DA2.0W" export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/opt/imake/bin rm -rf obj mkdir obj cd obj ../src/configure \ --enable-languages=gcc \ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \ --with-gnu-as --with-as=/usr/local/pa20_64/bin/as \ --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld \ --disable-shared \ --disable-nls \ --host=hppa64-hp-hpux11.00 echo "" echo "Now start 'Build-64'" a5:/pro/3gl/GNU/gcc-3.0.4 130 > cat Build-64 #!/usr/bin/sh export CONFIG_SITE= export CC="cc -Ae +DA2.0W" export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin export PATH=$PATH"":/opt/imake/bin cd obj make bootstrap-lean a5:/pro/3gl/GNU/gcc-3.0.4 131 > a5:/wrk/pa20_64/bin 135 > as --version GNU assembler 2.12 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `hppa64-hp-hpux11.00'. a5:/wrk/pa20_64/bin 136 > ar --version GNU ar 2.12 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. a5:/wrk/pa20_64/bin 137 > file * addr2line: ELF-64 executable object file - PA-RISC 2.0 (LP64) ar: ELF-64 executable object file - PA-RISC 2.0 (LP64) as: ELF-64 executable object file - PA-RISC 2.0 (LP64) c++: ELF-64 executable object file - PA-RISC 2.0 (LP64) c++filt: ELF-64 executable object file - PA-RISC 2.0 (LP64) cpp: ELF-64 executable object file - PA-RISC 2.0 (LP64) g++: ELF-64 executable object file - PA-RISC 2.0 (LP64) gas: ELF-64 executable object file - PA-RISC 2.0 (LP64) gasp: ELF-64 executable object file - PA-RISC 2.0 (LP64) gcc: ELF-64 executable object file - PA-RISC 2.0 (LP64) gcc64: ELF-64 executable object file - PA-RISC 2.0 (LP64) gccbug: commands text gcov: ELF-64 executable object file - PA-RISC 2.0 (LP64) gprof: ELF-64 executable object file - PA-RISC 2.0 (LP64) ld: ELF-64 executable object file - PA-RISC 2.0 (LP64) nm: ELF-64 executable object file - PA-RISC 2.0 (LP64) objcopy: ELF-64 executable object file - PA-RISC 2.0 (LP64) objdump: ELF-64 executable object file - PA-RISC 2.0 (LP64) ranlib: ELF-64 executable object file - PA-RISC 2.0 (LP64) readelf: ELF-64 executable object file - PA-RISC 2.0 (LP64) size: ELF-64 executable object file - PA-RISC 2.0 (LP64) strings: ELF-64 executable object file - PA-RISC 2.0 (LP64) strip: ELF-64 executable object file - PA-RISC 2.0 (LP64) a5:/wrk/pa20_64/bin 138 > -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org [-- Attachment #2: gcc-20020408-hpux64.tgz --] [-- Type: application/octet-stream, Size: 18321 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-10 3:39 ` H.Merijn Brand @ 2002-04-10 11:21 ` John David Anglin 2002-04-10 11:56 ` H.Merijn Brand 0 siblings, 1 reply; 32+ messages in thread From: John David Anglin @ 2002-04-10 11:21 UTC (permalink / raw) To: H.Merijn Brand; +Cc: gcc, bug-binutils > [v] gcc still problematic - build log attached (it requests to be sen= > t > to the gcc people :) > > a5:/pro/3gl/GNU/gcc-3.0.4 129 > cat Conf-64 It's not totally clear which version your trying to build. It looks like 3.0.4 but the files in the log file don't appear to be 3.0.4. In any event, there are a various warnings in the log file that are not normal: cc -Ae +DA2.0W -c -DIN_GCC -g -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl ude ../../src/gcc/read-rtl.c -o read-rtl.o cc: "../../src/gcc/read-rtl.c", line 671: warning 727: Cast truncates pointer in to 32 bit integer. cc -Ae +DA2.0W -c -DIN_GCC -g -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl ude ../../src/gcc/bitmap.c -o bitmap.o cc: "../../src/gcc/bitmap.c", line 144: warning 727: Cast truncates pointer into 32 bit integer. [...] c-parse.y:1951: warning: previous rule lacks an ending `;' c-parse.y:2017: warning: previous rule lacks an ending `;' c-parse.y:2048: warning: previous rule lacks an ending `;' I have tested the suggested procedure with 3.1 (prerelease) from todays cvs and it doesn't have a bootstrap failure in stage 1. However, the procedure doesn't work with 3.0.4: ./gencodes ../../gcc/gcc/config/pa/pa.md > tmp-codes.h /bin/sh: 1969 Memory fault(coredump) This looks like a problem with alloca. Suggest trying 3.1. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-10 11:21 ` John David Anglin @ 2002-04-10 11:56 ` H.Merijn Brand 2002-04-10 12:50 ` John David Anglin 0 siblings, 1 reply; 32+ messages in thread From: H.Merijn Brand @ 2002-04-10 11:56 UTC (permalink / raw) To: John David Anglin; +Cc: H.Merijn Brand, gcc Stripped the binutils from the Cc, cause I think we're on a gcc-only track now. On Wed 10 Apr 2002 20:14, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > [v] gcc still problematic - build log attached (it requests to be sen= > > t > > to the gcc people :) > > > > a5:/pro/3gl/GNU/gcc-3.0.4 129 > cat Conf-64 > > It's not totally clear which version your trying to build. It looks like > 3.0.4 but the files in the log file don't appear to be 3.0.4. In any event, > there are a various warnings in the log file that are not normal: The latest 'snapshot' as in gcc-20020408.tar.bz2 The prompt is indeed misleading, but I started this queeste on 3.0.4, so the structure was already set up. But rest assured: no 3.0.4 code in here. > cc -Ae +DA2.0W -c -DIN_GCC -g -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. > -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl > ude ../../src/gcc/read-rtl.c -o read-rtl.o > cc: "../../src/gcc/read-rtl.c", line 671: warning 727: Cast truncates pointer in > to 32 bit integer. > cc -Ae +DA2.0W -c -DIN_GCC -g -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. > -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl > ude ../../src/gcc/bitmap.c -o bitmap.o > cc: "../../src/gcc/bitmap.c", line 144: warning 727: Cast truncates pointer into > 32 bit integer. > > [...] > > c-parse.y:1951: warning: previous rule lacks an ending `;' > c-parse.y:2017: warning: previous rule lacks an ending `;' > c-parse.y:2048: warning: previous rule lacks an ending `;' > > I have tested the suggested procedure with 3.1 (prerelease) from > todays cvs and it doesn't have a bootstrap failure in stage 1. > However, the procedure doesn't work with 3.0.4: > > ./gencodes ../../gcc/gcc/config/pa/pa.md > tmp-codes.h > /bin/sh: 1969 Memory fault(coredump) > > This looks like a problem with alloca. Suggest trying 3.1. What URL? (I've got no (working) cvs) -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-10 11:56 ` H.Merijn Brand @ 2002-04-10 12:50 ` John David Anglin 2002-04-11 2:19 ` H.Merijn Brand 0 siblings, 1 reply; 32+ messages in thread From: John David Anglin @ 2002-04-10 12:50 UTC (permalink / raw) To: H.Merijn Brand; +Cc: h.m.brand, gcc > The latest 'snapshot' as in gcc-20020408.tar.bz2 I'll try the current cvs. > > This looks like a problem with alloca. Suggest trying 3.1. > > What URL? (I've got no (working) cvs) There don't seem to be any 3.1 snaps at ftp://gcc.gnu.org. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-10 12:50 ` John David Anglin @ 2002-04-11 2:19 ` H.Merijn Brand 2002-04-11 8:59 ` John David Anglin 0 siblings, 1 reply; 32+ messages in thread From: H.Merijn Brand @ 2002-04-11 2:19 UTC (permalink / raw) To: John David Anglin; +Cc: gcc On Wed 10 Apr 2002 21:44, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > The latest 'snapshot' as in gcc-20020408.tar.bz2 > > I'll try the current cvs. > > > > This looks like a problem with alloca. Suggest trying 3.1. > > > > What URL? (I've got no (working) cvs) > > There don't seem to be any 3.1 snaps at ftp://gcc.gnu.org. Can you make an (anonymous) ftp version available to me? Do you think I'm /helping/, or just bothering? Do you think it's worth the trouble? If I manage - with your help - to build a working HP-UX gcc/64, I'll post the Conf-64 and Build-64 scripts on the HP-UX forum, because I know there are more people fighting with exactly the same problem, and none of those has reached success C-environment info: a5:/u/usr/merijn 107 > ll /usr/lib/cpp /usr/ccs/lbin/cpp /opt/langtools/lbin/cpp /wrk/*64/bin/cpp 1114 -r-xr-xr-x 1 bin bin 548864 Sep 20 2001 /opt/langtools/lbin/cpp 194 -r-xr-xr-x 1 bin bin 258048 Nov 7 1997 /usr/ccs/lbin/cpp 1170 lr-xr-xr-t 1 root sys 23 Oct 9 2001 /usr/lib/cpp -> /opt/langtools/lbin/cpp 355 -rwxr-xr-x 1 merijn softwr 151384 Aug 27 2001 /wrk/gcc-3.0.1-64/bin/cpp 556 -rwxr-xr-x 1 merijn bin 666248 Oct 30 21:05 /wrk/pa20_64/bin/cpp a5:/u/usr/merijn 108 > what !* what /usr/lib/cpp /usr/ccs/lbin/cpp /opt/langtools/lbin/cpp /wrk/*64/bin/cpp /usr/lib/cpp: HP92453-01 B.11.11.04 HP C Preprocessor $ Sep 8 2000 23:13:51 $ /usr/ccs/lbin/cpp: HP92453-01 A.11.00.00 HP C (Bundled) Preprocessor CUPROS_IC23B //1 /ux/core/libs/libc/archive_pa1/libc.a_ID Oct 21 1997 13:07:38 /opt/langtools/lbin/cpp: HP92453-01 B.11.11.04 HP C Preprocessor $ Sep 8 2000 23:13:51 $ /wrk/gcc-3.0.1-64/bin/cpp: /wrk/pa20_64/bin/cpp: HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O LP64) $Revision: 75.03 $ a5:/u/usr/merijn 109 > path -w cc /usr/bin/cc: LINT B.11.11.04 CXREF B.11.11.04 HP92453-01 B.11.11.25985.GP HP C Compiler $ Sep 8 2000 23:13:51 $ /usr/bin/cc: $Revision: 92453-07 linker linker crt0.o B.11.25 010530 $ a5:/u/usr/merijn 110 > swlist -l product | grep -e libc -e header -e ANSI C-ANSI-C B.11.11.04 HP C/ANSI C Compiler PHCO_13349 1.0 XCurses header patch. PHCO_18228 1.0 libc man page cumulative patch PHCO_23706 1.0 cumulative 10.20 libc compatibility support PHCO_23770 1.0 libc cumulative patch PHCO_23963 1.0 libc cumulative header file patch PHCO_24723 1.0 libc cumulative patch PHCO_25707 1.0 libc cumulative patch PHSS_25985 1.0 ANSI C compiler General patch a5:/u/usr/merijn 111 > This should reflect the December-2001 QPK patch level. My other hp-11.00 is already on March-2002, but users prevented me from updating this system so far. -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-11 2:19 ` H.Merijn Brand @ 2002-04-11 8:59 ` John David Anglin 2002-04-11 9:15 ` H.Merijn Brand 2002-04-11 9:19 ` law 0 siblings, 2 replies; 32+ messages in thread From: John David Anglin @ 2002-04-11 8:59 UTC (permalink / raw) To: H.Merijn Brand; +Cc: gcc > On Wed 10 Apr 2002 21:44, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > > The latest 'snapshot' as in gcc-20020408.tar.bz2 > > > > I'll try the current cvs. I've duplicated the problem that you found. It's a bug in the GNU linker. It's not handling the relocations required for inline plabels correctly. The function splay_tree_new_with_allocator seg-faults when it is passed a pointer to the function splay_tree_xmalloc_allocate rather than a pointer to a function descriptor for splay_tree_xmalloc_allocate. The problem is present in both 3.1 and the trunk. This problem was introduced on 2002-02-22 when splay-tree.c was changed to use the above indirect call. The function splay-tree.c is in libiberty. Libiberty gets built just in stage1 with the HP compiler. The HP compiler now uses inline plabels (LTP and RTP selectors). The HP assembler and linker can handle these relocation selectors, but unfortunately not the GNU linker. Gcc doesn't generate inline plabels on the PA. It would save one insn and one data location if we could use these selectors. However, there have been problems with them in 32bit land for years. I think the current assembler can handle them but the SOM linker still doesn't handle them. The work around is to use the HP linker for the initial bootstrap. I recommend just building C, install it, then do another full bootstrap using gcc and the GNU linker. You have to use the GNU assembler for both builds. Could you try another build? Just remove "--with-gnu-ld" from your script and specify "--with-ld=/usr/ccs/bin/ld". You may want to export LD_PXDB=/usr/bin/true to defer invocation of pxdb. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-11 8:59 ` John David Anglin @ 2002-04-11 9:15 ` H.Merijn Brand 2002-04-11 9:19 ` law 1 sibling, 0 replies; 32+ messages in thread From: H.Merijn Brand @ 2002-04-11 9:15 UTC (permalink / raw) To: John David Anglin; +Cc: gcc [-- Attachment #1: Type: text/plain, Size: 2468 bytes --] On Thu 11 Apr 2002 17:18, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > On Wed 10 Apr 2002 21:44, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote: > > > > The latest 'snapshot' as in gcc-20020408.tar.bz2 > > > > > > I'll try the current cvs. > > I've duplicated the problem that you found. It's a bug in the GNU linker. > It's not handling the relocations required for inline plabels correctly. > The function splay_tree_new_with_allocator seg-faults when it is passed > a pointer to the function splay_tree_xmalloc_allocate rather than a pointer > to a function descriptor for splay_tree_xmalloc_allocate. The problem > is present in both 3.1 and the trunk. > > : > > The work around is to use the HP linker for the initial bootstrap. I > recommend just building C, install it, then do another full bootstrap > using gcc and the GNU linker. You have to use the GNU assembler for > both builds. > > Could you try another build? Just remove "--with-gnu-ld" from your > script and specify "--with-ld=/usr/ccs/bin/ld". You may want to > export LD_PXDB=/usr/bin/true to defer invocation of pxdb. echo "int xxy_us_dummy;" >tmp-dum.c ./xgcc -B./ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/ -isystem /usr/local/pa20_64/hppa64-hp-hpux11.00/include -isystem /usr/local/pa20_64/hppa64-hp-hpux11.00/sys-include -S tmp-dum.c cc1: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. make[2]: *** [s-under] Error 1 make[2]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc' make: *** [bootstrap-lean] Error 2 I've used Conf-64a and Build-64a and prepared Conf-gcc64 and Build-gcc64 Complete log of Build-64a included in the tgz 105 17:28 Conf-64 106 17:32 Build-64a |& tee gcc-20020408-hpux64 107 17:54 tgz c gcc-20020408-hpux64.tgz Conf-64a Build-64a Conf-gcc64 Build-gcc64 gcc-20020408-hpux64 -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org [-- Attachment #2: gcc-20020408-hpux64.tgz --] [-- Type: application/octet-stream, Size: 17829 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00 2002-04-11 8:59 ` John David Anglin 2002-04-11 9:15 ` H.Merijn Brand @ 2002-04-11 9:19 ` law 1 sibling, 0 replies; 32+ messages in thread From: law @ 2002-04-11 9:19 UTC (permalink / raw) To: John David Anglin; +Cc: H.Merijn Brand, gcc In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David Anglin " writes: > Gcc doesn't generate inline plabels on the PA. It would save one insn > and one data location if we could use these selectors. However, there > have been problems with them in 32bit land for years. I think the > current assembler can handle them but the SOM linker still doesn't > handle them. Actually the SOM linker can handle them, but there are corner cases with very large executables where it's impossible for the SOM linker to properly fixup an inline plabel. For that reason we stopped using them based on a recommendation from HP. jeff ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2002-04-16 22:23 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20020411221308.416D.H.M.BRAND@hccnet.nl>
[not found] ` <200204112027.g3BKR6DK001129@hiauly1.hia.nrc.ca>
2002-04-12 3:19 ` gcc-64 on HP-UX 11.00 H.Merijn Brand
2002-04-12 4:39 ` H.Merijn Brand
2002-04-12 5:08 ` H.Merijn Brand
2002-04-12 9:34 ` John David Anglin
2002-04-13 10:40 ` John David Anglin
2002-04-15 8:45 ` law
2002-04-15 9:46 ` John David Anglin
2002-04-15 10:05 ` law
2002-04-15 11:42 ` John David Anglin
[not found] <no.id>
2002-04-10 15:30 ` John David Anglin
2002-04-11 10:25 ` John David Anglin
2002-04-11 10:43 ` H.Merijn Brand
2002-04-11 11:04 ` law
2002-04-15 13:39 ` John David Anglin
2002-04-16 13:14 ` law
2002-04-16 15:25 ` John David Anglin
2002-04-04 12:02 John David Anglin
-- strict thread matches above, loose matches on Subject: below --
2002-04-04 2:03 H.Merijn Brand
2002-04-04 8:22 ` law
[not found] ` <200204041958.g34JwTbA011272@hiauly1.hia.nrc.ca>
2002-04-05 4:51 ` H.Merijn Brand
2002-04-05 5:01 ` H.Merijn Brand
2002-04-05 9:19 ` John David Anglin
2002-04-07 7:26 ` H.Merijn Brand
2002-04-07 12:17 ` John David Anglin
2002-04-10 3:39 ` H.Merijn Brand
2002-04-10 11:21 ` John David Anglin
2002-04-10 11:56 ` H.Merijn Brand
2002-04-10 12:50 ` John David Anglin
2002-04-11 2:19 ` H.Merijn Brand
2002-04-11 8:59 ` John David Anglin
2002-04-11 9:15 ` H.Merijn Brand
2002-04-11 9:19 ` law
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).