Discussion:
middle-end/6180: Infinite loop in cc1 during dbr pass
(too old to reply)
John David Anglin
2002-04-05 19:35:38 UTC
Permalink
Infinite loop occurs compiling nm.c (binutils 2.12.90
20020404). The final loop in dbr_sequence loops forever
because of a loop in the insn chain that occurs compiling
the function filter_symbols. The insn chain appears ok
when dbr_sequence is called.
This is what is causing the problem. There is a millicode call
insn in the function "return" just before the epilogue begin note.
dbr_schedule puts the first insn in the epilogue into the delay
slot of the call. This insn restores %r2 from the stack. It's
probably ok to put it into the delay slot of the millicode call
since it doesn't use %r2, but the start of the epilogue is now
in an indeterminate position. reposition_prologue_and_epilogue_notes
moves the epilogue begin note before the sequence. However, in
fixing the insn chain, it apparently doesn't check for a sequence
and the chain is left in a corrupt state. In particular, it doesn't
touch the numbering inside the sequence.

I probably can fix this by adding a blockage at the beginning
of the epilogue. However, this seems like overkill and simply
avoids the problem.

Suggestions?

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-04-05 19:54:08 UTC
Permalink
Post by John David Anglin
in an indeterminate position. reposition_prologue_and_epilogue_notes
moves the epilogue begin note before the sequence. However, in
fixing the insn chain, it apparently doesn't check for a sequence
and the chain is left in a corrupt state. In particular, it doesn't
touch the numbering inside the sequence.
reposition_prologue_and_epilogue_notes uses reorder_insns. The comments
for reorder_insns_nobb indicate that it doesn't know about sequences
and it looks like the same is true for reorder_insns. Thus, it can't
be used at this point.

Do we actually need to call reposition_prologue_and_epilogue_notes
at this point?

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Richard Henderson
2002-04-05 21:19:23 UTC
Permalink
Post by John David Anglin
Do we actually need to call reposition_prologue_and_epilogue_notes
at this point?
Dunno. Probably not.


r~
John David Anglin
2002-04-06 20:12:23 UTC
Permalink
Post by John David Anglin
Do we actually need to call reposition_prologue_and_epilogue_notes
at this point?
My conclusion is that we can't reposition prologue and epilogue notes
at this point in dbr_schedule because the above function can't handle
sequences. Further, the exact end and start of the prologue and
epilogue, respectively, is indeterminant. Thus, I propose that the
notes not be repositioned.

I have confirmed that the enclosed patch fixes the compilation problem
of nm.c under hppa-linux. I have bootstrapped and checked that there
are no regressions with this patch under hppa-linux and
hppa2.0w-hp-hpux11.11.

The compilation failure of nm.c is a regression from 3.0.x. OK for
trunk and 3.1 branch?

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)

2002-04-06 John David Anglin <***@hiauly1.hia.nrc.ca>

* reorg.c (dbr_schedule): Don't reposition prologue and epilogue notes.

Index: reorg.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/reorg.c,v
retrieving revision 1.70
diff -u -3 -p -r1.70 reorg.c
--- reorg.c 31 Mar 2002 18:45:21 -0000 1.70
+++ reorg.c 6 Apr 2002 02:18:27 -0000
@@ -3686,10 +3686,6 @@ dbr_schedule (first, file)
/* It is not clear why the line below is needed, but it does seem to be. */
unfilled_firstobj = (rtx *) obstack_alloc (&unfilled_slots_obstack, 0);

- /* Reposition the prologue and epilogue notes in case we moved the
- prologue/epilogue insns. */
- reposition_prologue_and_epilogue_notes (first);
-
if (file)
{
int i, j, need_comma;
Richard Henderson
2002-04-06 20:58:05 UTC
Permalink
Post by John David Anglin
* reorg.c (dbr_schedule): Don't reposition prologue and epilogue notes.
Ok.


r~
John David Anglin
2002-04-10 21:02:01 UTC
Permalink
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 ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-04-11 17:14:40 UTC
Permalink
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 ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
l***@redhat.com
2002-04-11 17:46:44 UTC
Permalink
Post by John David Anglin
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
H.Merijn Brand
2002-04-12 09:45:09 UTC
Permalink
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: ***@perl.org
http://archives.develooper.com/daily-***@perl.org/ perl-***@perl.org
send smoke reports to: smokers-***@perl.org, QA: http://qa.perl.org
H.Merijn Brand
2002-04-12 11:32:34 UTC
Permalink
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/
H.Merijn Brand
2002-04-12 11:38:48 UTC
Permalink
Post by H.Merijn Brand
The results from previous executions of configure are kept in
config.cache. So, at a minimum, all config.cache files need to be
--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/
John David Anglin
2002-04-12 16:23:22 UTC
Permalink
Post by H.Merijn Brand
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 ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-04-13 16:03:51 UTC
Permalink
Post by H.Merijn Brand
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 ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)

2002-04-13 John David Anglin <***@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"
l***@redhat.com
2002-04-15 15:36:32 UTC
Permalink
Post by John David Anglin
Post by H.Merijn Brand
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
John David Anglin
2002-04-15 16:46:14 UTC
Permalink
Post by l***@redhat.com
Post by John David Anglin
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 ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
l***@redhat.com
2002-04-15 16:56:18 UTC
Permalink
Post by John David Anglin
Post by l***@redhat.com
Post by John David Anglin
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.

[ ... ]
Post by John David Anglin
# gcc -O -mpa-risc-2-0 -fPIC -S gv.i
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
John David Anglin
2002-04-15 18:37:14 UTC
Permalink
Post by l***@redhat.com
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.
Post by l***@redhat.com
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 ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-04-15 20:27:21 UTC
Permalink
Post by John David Anglin
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 ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
l***@redhat.com
2002-04-16 20:18:29 UTC
Permalink
Post by John David Anglin
Post by John David Anglin
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]
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
John David Anglin
2002-04-16 22:23:46 UTC
Permalink
Post by l***@redhat.com
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.
Post by l***@redhat.com
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.
Post by l***@redhat.com
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 ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
H.Merijn Brand
2002-11-13 10:24:48 UTC
Permalink
2002-11-11 is broken for 64bit on HP-UX. 2002-11-04 still worked ...
FWIW 32bit version worked perfect

I'll try to rebuild gcc64 from scratch without using the 20021104 vs

a5:/pro/3gl/GNU/gcc 113 > ll -d src gcc-*
38813 drwxrwxrwx 17 merijn softwr 2048 Nov 12 18:38 gcc-20021111
33464 -rw-r--r-- 1 merijn softwr 20243290 Nov 12 13:24 gcc-20021111.tbz
33916 lrwxrwxrwx 1 merijn softwr 12 Nov 12 18:38 src -> gcc-20021111
a5:/pro/3gl/GNU/gcc 114 > cat 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,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

echo ""
echo "Now start 'Build-gcc64'"
a5:/pro/3gl/GNU/gcc 115 > gcc64 --version
gcc64 (GCC) 3.3 20021104 (experimental)
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 116 > sh -x Conf-gcc64
+ export CONFIG_SITE=
+ export CC=gcc64 -mpa-risc-2-0
+ export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
+ export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin:/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
+ export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin:/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin:/opt/imake/bin
+ rm -rf obj
+ mkdir obj
+ cd obj
+ ../src/configure --enable-languages=c,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
*** This configuration is not supported in the following subdirectories:
target-libffi target-boehm-gc target-zlib target-libjava target-libf2c zlib fastjar target-libobjc
(Any other directories should still work fine.)
Created "Makefile" in /pro/3gl/GNU/gcc/obj using "mh-frag"
ldd: "conftest" is not a shared executable.
collect2: /usr/ccs/bin/ldd returned 1 exit status
*** The command 'gcc64 -mpa-risc-2-0 -o conftest -g conftest.c' failed.
*** You must set the environment variable CC to a working compiler.
+ echo

+ echo Now start 'Build-gcc64'
Now start 'Build-gcc64'
a5:/pro/3gl/GNU/gcc 117 > gcc --version
gcc (GCC) 3.3 20021111 (experimental)
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 118 >
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: ***@perl.org
http://archives.develooper.com/daily-***@perl.org/ perl-***@perl.org
send smoke reports to: smokers-***@perl.org, QA: http://qa.perl.org
H.Merijn Brand
2002-11-13 13:21:11 UTC
Permalink
Post by H.Merijn Brand
2002-11-11 is broken for 64bit on HP-UX. 2002-11-04 still worked ...
FWIW 32bit version worked perfect
I'll try to rebuild gcc64 from scratch without using the 20021104 vs
That succeeded. Installed OK. Now use that to rebuild gcc64:

` if [ -f /pro/3gl/GNU/gcc/obj/gcc/../binutils/ranlib ] ; then echo /pro/3gl/GNU/gcc/obj/gcc/../binutils/ranlib ; else if [ "hppa64-hp-hpux11.00" = "hppa64-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa64-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi` stage1/libgcc_eh.a; \
else true; fi; fi
for f in .. ; do if [ x${f} != x.. ]; then \
cp stage1/${f} . ; \
else true; \
fi; done
mv cp/*.o stage1/cp
mv: cp/*.o: cannot access: No such file or directory
make[2]: [c++.stage1] Error 1 (ignored)
make[2]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
echo timestamp > stage1_copy
echo stage2_build > stage_last
(cd stage1 && rm -f `echo main.o libbackend.a alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o cfg.o cfganal.o cfgbuild.o cfgcleanup.o cfglayout.o cfgloop.o cfgrtl.o combine.o conflict.o convert.o cse.o cselib.o dbxout.o debug.o df.o diagnostic.o doloop.o dominance.o dwarf2asm.o dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o global.o graph.o gtype-desc.o haifa-sched.o hashtable.o hooks.o ifcvt.o insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o langhooks.o lcm.o lists.o local-alloc.o loop.o mbchar.o optabs.o params.o predict.o print-rtl.o print-tree.o profile.o ra.o ra-build.o ra-colorize.o ra-debug.o ra-rewrite.o real.o recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o rtl-error.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o sibcall.o simplify-rtx.o ssa.o ssa-ccp.o ssa-dce.o stmt.o stor-layout.o stringpool.o timevar.o toplev.o tracer.o tree.o tree-dump.o tree-inline.o unroll.o varasm.o varray.o version.o vmsdbgout.o xcoffout.o et-forest.o ggc-page.o pa.o c-parse.o c-lang.o c-pretty-print.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-objc-common.o c-dump.o libcpp.a cpplib.o cpplex.o cppmacro.o cppexp.o cppfiles.o cpptrad.o cpphash.o cpperror.o cppinit.o cppdefault.o cppmain.o hashtable.o line-map.o mkdeps.o prefix.o mbchar.o *.c *.h gen*`)
echo timestamp > clean_s1
make CC=" stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/" \
STAGE_PREFIX=stage1/ \
ADAC="\$(CC)" CFLAGS="-g -O2" LDFLAGS="" WARN_CFLAGS="\$(GCC_WARN_CFLAGS)" STRICT_WARN="-Wtraditional -pedantic -Wno-long-long" libdir=/usr/local/pa20_64/lib LANGUAGES="c gcov c++" MAKEOVERRIDES= OUTPUT_OPTION="-o \$@"
make[2]: Entering directory `/pro/3gl/GNU/gcc/obj/gcc'
stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include ../../src/gcc/gengenrtl.c -o gengenrtl.o
stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o gengenrtl \
gengenrtl.o ../libiberty/libiberty.a
ldd: "gengenrtl" is not a shared executable.
collect2: /usr/ccs/bin/ldd returned 1 exit status
make[2]: *** [gengenrtl] Error 1
make[2]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
make: *** [bootstrap-lean] Error 2
Exit 2
a5:/pro/3gl/GNU/gcc 131 > gcc64 --version
gcc64 (GCC) 3.3 20021111 (experimental)
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 132 >
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: ***@perl.org
http://archives.develooper.com/daily-***@perl.org/ perl-***@perl.org
send smoke reports to: smokers-***@perl.org, QA: http://qa.perl.org
John David Anglin
2002-11-13 16:09:47 UTC
Permalink
Post by H.Merijn Brand
ldd: "gengenrtl" is not a shared executable.
This is in fact a GNU ld bug. If you use chatr, you will see that gengenrtl
is an incomplete executable and has dependencies on shared libraries.
ldd should list the dependent shared libraries. It does if you build using
the HP linker.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-11-13 21:04:24 UTC
Permalink
Post by H.Merijn Brand
ldd: "gengenrtl" is not a shared executable.
collect2: /usr/ccs/bin/ldd returned 1 exit status
I have installed the patch below and it should fix the above problem.

However, we are back to the previous situation where global constructors
and destructors in dependent libraries are not executed. This causes
a variety of regressions when the HP linker was being used. For example,
objc is essentially unusable and g++ is compromised. This of course
is also the state with GNU ld.

If you use the HP linker, LD_INIT_SWITCH and LD_FINI_SWITCH can be
defined as shown below and this results in GCC testsuite results
fairly comparable to that of the 32-bit ports. You can even enable
the building of a shared libgcc in config.gcc.

Unfortunately, LD_INIT_SWITCH and LD_FINI_SWITCH can't be defined
with the GNU linker without other nasty things happening. As far
as I can tell, there is no way to define these symbols without
making the GCC code linker dependent. I don't think we want to
do this at this time, so I have disabled the above two macros.
Hopefully, the GNU ld bugs can be fixed in the near future and we
can use the above macros, or possibly .init and .fini sections.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)

2002-11-13 John David Anglin <***@hiauly1.hia.nrc.ca>

* pa64-hpux.h (LINK_SPEC): Move "+Accept TypeMismatch" switch to the
beginning of the spec.
(LDD_SUFFIX, PARSE_LDD_OUTPUT): Delete.
(LD_INIT_SWITCH, LD_FINI_SWITCH): Define but don't enable. Add comment
regarding problems with global constructors when using GNU ld.

Index: config/pa/pa64-hpux.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa64-hpux.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 pa64-hpux.h
--- config/pa/pa64-hpux.h 10 Nov 2002 01:14:47 -0000 1.18
+++ config/pa/pa64-hpux.h 13 Nov 2002 17:12:03 -0000
@@ -31,14 +31,16 @@ Boston, MA 02111-1307, USA. */
N_("Assume code will be linked by HP ld") },

/* We can debug dynamically linked executables on hpux11; we also
- want dereferencing of a NULL pointer to cause a SEGV. */
+ want dereferencing of a NULL pointer to cause a SEGV. Do not move
+ the "+Accept TypeMismatch" switch. We check for it in collect2
+ to determine which init/fini is needed. */
#undef LINK_SPEC
#if ((TARGET_DEFAULT | TARGET_CPU_DEFAULT) & MASK_GNU_LD)
#define LINK_SPEC \
- "-E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mhp-ld:-b}%{!mhp-ld:-shared}} %{mhp-ld:+Accept TypeMismatch}"
+ "%{mhp-ld:+Accept TypeMismatch} -E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mhp-ld:-b}%{!mhp-ld:-shared}}"
#else
#define LINK_SPEC \
- "-E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mgnu-ld:-shared}%{!mgnu-ld:-b}} %{!mgnu-ld:+Accept TypeMismatch}"
+ "%{!mgnu-ld:+Accept TypeMismatch} -E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mgnu-ld:-shared}%{!mgnu-ld:-b}}"
#endif

/* Like the default, except no -lg. */
@@ -252,19 +254,26 @@ do { \

/* Since we are not yet using .init and .fini sections, we need to
explicitly arrange to run the global constructors and destructors.
- HPUX 11 has ldd and we use it to determine the dependencies of
- dynamic objects. It might be possible to use the ld options for
- running initializers and terminators and thereby avoid the necessity
- of running ldd, but unfortunately the options are different for
- the two linkers. */
-#define LDD_SUFFIX "/usr/ccs/bin/ldd"
-
-/* Skip to first '>' then advance to '/' at the beginning of the filename. */
-#define PARSE_LDD_OUTPUT(PTR) \
-do { \
- while (*PTR != '>') PTR++; \
- while (*PTR != '/') PTR++; \
-} while (0)
+ We could use ldd for this but it depends on LD_LIBRARY_PATH being
+ correctly set. So, we use the ld init and fini switches. However,
+ we need to support different switches for the GNU and HP linkers.
+ We can't check TARGET_GNU_LD in collect2, so we need a different
+ test. The +Accept switch is always the first switch when we are
+ using the HP linker (see define for LINK_SPEC). Checking for it
+ is a somewhat fragile as it depends on internal details of the
+ collect2 program but it is better than testing ld_file_name.
+
+ FIXME: The GNU linker is broken. The -init/-fini switches don't
+ work and ldd can't determine the dynamic dependences of executables
+ linked with GNU ld. The init and fini routines are not executed
+ although DT_INIT and DT_FINI appear ok. As a result, defining
+ LD_INIT_SWITCH and LD_FINI_SWITCH causes more harm than good when
+ using GNU ld. However, the definitions appear to work fine with
+ the HP linker. */
+#if 0
+#define LD_INIT_SWITCH (strcmp ("+Accept", ld2_argv[1]) ? "-init" : "+init")
+#define LD_FINI_SWITCH (strcmp ("+Accept", ld2_argv[1]) ? "-fini" : "+fini")
+#endif

/* If using HP ld do not call pxdb. Use size as a program that does nothing
and returns 0. /bin/true cannot be used because it is a script without
H.Merijn Brand
2002-11-15 16:22:52 UTC
Permalink
Post by John David Anglin
Post by H.Merijn Brand
ldd: "gengenrtl" is not a shared executable.
collect2: /usr/ccs/bin/ldd returned 1 exit status
I have installed the patch below and it should fix the above problem.
Confirm. Now works for gcc64.
Post by John David Anglin
However, we are back to the previous situation where global constructors
and destructors in dependent libraries are not executed. This causes
a variety of regressions when the HP linker was being used. For example,
objc is essentially unusable and g++ is compromised. This of course
is also the state with GNU ld.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: ***@perl.org
http://archives.develooper.com/daily-***@perl.org/ perl-***@perl.org
send smoke reports to: smokers-***@perl.org, QA: http://qa.perl.org
John David Anglin
2002-11-13 15:59:57 UTC
Permalink
Post by H.Merijn Brand
2002-11-11 is broken for 64bit on HP-UX. 2002-11-04 still worked ...
FWIW 32bit version worked perfect
Sigh, I know. I am testing a "fix". However, the problem is really
GNU ld is broken. Using HP ld should work fine.

I tried to fix the fact that constructors are not being collected
from dependent shared libraries. Unfortunately, I missed testing
with GNU ld as I was mainly concerned about assembler issues.
This is what ld reports for any executable (not shared libraries)

bash-2.05a$ ldd cc1
ldd: "cc1" is not a shared executable.

I must admit that I first noted a problem using ldd to find
dependencies when I tried a bootstrap with the HP linker and a shared
libgcc. The problem is LD_LIBRARY_PATH needs to be set correctly
for it to work and this is problematic when building packages
with shared libraries.

Basically, we have to back out from trying to search dependencies
for global constructors until GNU ld is fixed. This leaves using
shared libraries with constructors broken (various v3, g++ and objc
testsuite fails are caused by this).

I tested an alternative approach using the +init/+fini switches
with the HP linker. This works fine and I was sucessful building
gcc with a shared libgcc with no regressions. However, with
the GNU linker, we hit another bug. The init and fini routines are
not called although DT_INIT and DT_FINI look ok. The result of this
is worse than not doing the dependency search, so we are in dammed
if we do and dammed if we don't situation.

Anyhow, either use the HP linker or "--disable-shared" for the moment.
I will install a patch later today to restore the previous behavior.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-04-26 17:37:36 UTC
Permalink
/berman/migchain/install/native/bison-1.33/share/bison/bison.simple:521: `yyfree_stacks' undeclared (first use in this function)
It looks like this incompatibility was introduced by this patch:

2002-04-25 Richard Henderson <***@redhat.com>

PR c/2161
* c-parse.in (yyoverflow): New.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Michael Elizabeth Chastain
2002-04-26 18:46:04 UTC
Permalink
The red herring ...

I did build my bison 1.33 with --disable-nls. But I rebuilt bison 1.33
and the gcc build still fails.

I'm not an "intl" expert, but it looks like intl/plural.y is part of
the intl library that goes with the bison executable and is not part of
bison.hairy or bison.simple. It just happens to be a bison program so it
gets processed with bison. In bison-1.33.tar.gz, intl/plural.c was built
with bison 1.28. That is why we see the simple "yyfree_stacks" in it.

The bison story ...

"yyfree_stacks" in bison.simple disappeared between bison 1.30 and
bison 1.31. In the CVS version of bison, Paul Eggert removed it in
1.53.2.8 of src/bison.simple (this is on a branch and the file has
been moved to data/bison.simple since then, what fun). It looks
like part of a big memory-management cleanup. cvs log entry appended.

Here is the logic flow:

yyss, yyvs, yyls are initialized to point to auto arrays.
yyoverflow can change these pointers to point to heap arrays.
yyfree_stacks tracks whether yyss, yyvs, yyls point to auto or heap.
if yyfree_stacks is true, you may call realloc() to grow the stacks.
if yyfree_stacks is true, yyparse() must call free() before returning.

The old parser does:

yyacceptlab:
if (yyfree_stacks)
{
free (yyss);
free (yyvs);
#if YYLSP_NEEDED
free (yyls);
#endif
}
return 0;

But the new parser does:

yyreturn:
#ifndef yyoverflow
if (yyss != yyssa)
YYSTACK_FREE (yyss);
#endif
return yyresult;

It's hard to write a yyoverflow that works with both versions
of bison.simple. yyoverflow can have its own local version of
"yyfree_stacks" and ignore the one that belongs to yyparse. But this
produces a memory leak with old-style bison.simple that needs to see
"yyfree_stacks" set to 1.

What to do ...

gcc/configure already checks the version of bison.

Perhaps write yyoverflow for the new parser only (bison 1.31 or later)
and then require bison 1.31 in gcc/configure?

gcc/configure could also pass the bison version in a configuration
variable to c-parse.in, so that c-parse.in could have code for
both cases.

Right now, the code works only with old bison (bison 1.30 or earlier)
and there is no check.

Oy!

Michael C

===

# cvs log src/bison.simple
revision 1.53.2.8
date: 2001/11/30 02:47:56; author: eggert; state: Exp; lines: +93 -67
(YYSTACK_REALLOC): Remove.
(YYSTACK_ALLOC): Resurrect this macro, with its old meaning.
(YYSTACK_FREE, YYSTACK_GAP_MAX, YYSTACK_BYTES, YYSTACK_RELOCATE):
New macros.
(union yyalloc): New type.
(__yy_memcpy): Last arg is size_t, not unsigned int, to remove
an arbitrary restriction on hosts where size_t is wider than int.

(yyparse): Don't dump core if alloca or malloc fails; instead, report
a parser stack overflow. Allocate just one block of memory for all
three stacks, instead of allocating three blocks; this typically is
faster and reduces fragmentation.

Do not limit the number of items in the stack to a value that fits
in 'int', as this is an arbitrary limit on hosts with 64-bit
size_t and 32-bit int.
John David Anglin
2002-05-11 23:10:21 UTC
Permalink
FAIL: g++.dg/bprob/bprob-1.C compilation, -O2 -fprofile-arcs
This one a SIGSEGV:

(gdb) r -fprofile-arcs -O2 bprob-1.ii
...
Program received signal SIGSEGV, Segmentation fault.
0x0010c574 in ok_to_generate_alias_set_for_type (t=0x402dda10)
at ../../gcc/gcc/cp/cp-lang.c:214
214 if (! CLASSTYPE_NON_POD_P(t))

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Joe Buck
2002-06-02 00:08:46 UTC
Permalink
The single and double IEEE formats do indeed look similar to VAX F and
G formats respectively, but they do NOT match. There are three key
differences: the halfwords are in the opposite order (sign bit is bit
31 in each case for IEEE); the exponent bias is one less -- 127 and
1023 for IEEE vs. 128 and 1024 for VAX; and the hidden high order bit
is interpreted as the bit just to the left of the binary point (2**0)
in IEEE rather than just to the right (2**-1) as in VAX. (In
addition, IEEE has both Inf and NaN, while DEC format only has NaN.
And IEEE has denormals; DEC does not.)
There's a 4th difference: F-floating has the same exponent size as IEEE
single precision, but D-floating has the same number of exponent bits
as F-floating while IEEE doubles have more exponent bits. (Conversion
from Vax-D to Vax-F is a simple matter of rounding off the mantissa, while
for IEEE, overflow can occur because the double precision type has greater
range).
John David Anglin
2002-06-03 18:29:13 UTC
Permalink
It's possible the emulator is broken for the vax. Richard Henderson
changed vax.h on Jan. 9 to define REAL_ARITHMETIC. Previously, the
compiler didn't use the emulator (you were supposed to hack vax.h
to use the emulator if you were building a cross compiler).

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
l***@redhat.com
2002-06-04 19:26:44 UTC
Permalink
Post by John David Anglin
Infinite loop occurs compiling nm.c (binutils 2.12.90
20020404). The final loop in dbr_sequence loops forever
because of a loop in the insn chain that occurs compiling
the function filter_symbols. The insn chain appears ok
when dbr_sequence is called.
This is what is causing the problem. There is a millicode call
insn in the function "return" just before the epilogue begin note.
dbr_schedule puts the first insn in the epilogue into the delay
slot of the call. This insn restores %r2 from the stack. It's
probably ok to put it into the delay slot of the millicode call
since it doesn't use %r2, but the start of the epilogue is now
in an indeterminate position. reposition_prologue_and_epilogue_notes
moves the epilogue begin note before the sequence. However, in
fixing the insn chain, it apparently doesn't check for a sequence
and the chain is left in a corrupt state. In particular, it doesn't
touch the numbering inside the sequence.
I probably can fix this by adding a blockage at the beginning
of the epilogue. However, this seems like overkill and simply
avoids the problem.
Suggestions?
I think reposition_prologue_and_epilogue_notes really needs to understand
SEQUENCEs and deal with them properly.

jeff
John David Anglin
2002-06-04 19:34:07 UTC
Permalink
Post by l***@redhat.com
I think reposition_prologue_and_epilogue_notes really needs to understand
SEQUENCEs and deal with them properly.
This is what was done <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00354.html>.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
David S. Miller
2002-06-04 19:51:17 UTC
Permalink
From: ***@redhat.com
Date: Tue, 04 Jun 2002 13:26:44 -0600

I think reposition_prologue_and_epilogue_notes really needs to
understand SEQUENCEs and deal with them properly.

This reminds me, why do we really put the delay slot stuff
in SEQUENCES?

I think we could handle that problem (keeping the insn and it's delay
slots together and figuring out that an insn is "inside" a delay slot)
in some other clean way.

This could also, for example, make it much more easier to teach the
generic instruction scheduler how to do delay slotting so we can
obliterate reorg.
l***@redhat.com
2002-06-04 20:46:53 UTC
Permalink
Post by David S. Miller
Date: Tue, 04 Jun 2002 13:26:44 -0600
I think reposition_prologue_and_epilogue_notes really needs to
understand SEQUENCEs and deal with them properly.
This reminds me, why do we really put the delay slot stuff
in SEQUENCES?
Because that's the way someone wrote it back in 1988? :(
Post by David S. Miller
I think we could handle that problem (keeping the insn and it's delay
slots together and figuring out that an insn is "inside" a delay slot)
in some other clean way.
I don't think it'd be terribly hard to use a flag bit to tell us this.
Post by David S. Miller
This could also, for example, make it much more easier to teach the
generic instruction scheduler how to do delay slotting so we can
obliterate reorg.
Oh man. Zapping reorg is conceptually simple if you look at it from
the right angle (ie dependency graphs). It'd also be a hell of a lot
faster.

The whole trick is to use the dependency graph to give us the set of
potential instructions which can be used to fill any particular delay
slot. This avoids all the sillyness of resource tracking through entire
basic blocks as implemented in reorg right now.

When searching backwards from the delay slot, you look for leaves in the
graph, when searching forward, you look for roots in the graph. Those
are the only interesting insns.

[ OK, so that's over-simplified in the case of calls and normal insns
with delay slots -- you need to prune out all the instructions before
the call when you start searching for roots. ]

Anyway, with the candidate sets, you just call back into the insn-attrtab
routines to see which one actually works.

jeff
David S. Miller
2002-06-04 20:50:10 UTC
Permalink
From: ***@redhat.com
Date: Tue, 04 Jun 2002 14:46:53 -0600
Post by David S. Miller
This could also, for example, make it much more easier to teach the
generic instruction scheduler how to do delay slotting so we can
obliterate reorg.
Oh man. Zapping reorg is conceptually simple if you look at it from
the right angle (ie dependency graphs). It'd also be a hell of a lot
faster.

Pre-delay slots fall right out of that too :-)
John David Anglin
2002-07-11 04:26:56 UTC
Permalink
I am curious if anyone is currently bootstrapping the hppa64 GCC
compiler from the latest sources? I am running into a very curious cpp
problem. With the attached example, using the cc1 that I just built I
get two definitions of sigpause showing up because _SVID2 seems to be
considered defined and undefined at the same time. It doesn't happen on
the other platforms I have tried but it happens consistenly for me on
PA64.
I am currently bootstrapping the latest sources for 3.1.1 and 3.2.
3.2 is now in stage2 and doesn't exhibit the problem described, so I
expect that you have a problem with your tools.

There have been a fair number of changes to binutils affecting hppa64
in the last month or so. I suggest you rebuild them. The only unexpected
errors should be 7 in the ld suite. Then, I suggest that you build
3.1.1 starting with either the HP builtin or ANSI compiler. You should
be able to build 3.2 starting with the HP ANSI compiler. I'm using
3.1.1 as my default for hppa64 builds.

I will let you know if the problem that you describe appears later
in the build process.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-07-16 17:01:13 UTC
Permalink
These messages are coming from the assembler (remove "-pipe"). The
first is from "std %r4,44(%r3)". The offset "44" is not correct for
a store double. This is probably a problem with pointer arithmetic
in the source.
Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Randolph Chung
2002-07-16 17:22:55 UTC
Permalink
Post by John David Anglin
These messages are coming from the assembler (remove "-pipe"). The
first is from "std %r4,44(%r3)". The offset "44" is not correct for
a store double. This is probably a problem with pointer arithmetic
in the source.
Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.
ah, this is not it, but i see what it is now.

include/linux/tcp_diag.h defines:

struct tcpdiag_sockid
{
__u16 tcpdiag_sport;
__u16 tcpdiag_dport;
__u32 tcpdiag_src[4];
__u32 tcpdiag_dst[4];
__u32 tcpdiag_if;
__u32 tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};

the code goes on to do:
*((struct sock **)&r->id.tcpdiag_cookie) = sk;
and
sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

even tho tcpdiag_cookie looks like it can be 64-bit aligned in the
struct, it appears that it isn't....

the "vomit grade hack" alan mentioned in another post is that in our
tree, we have:

struct tcpdiag_sockid
{
__u16 tcpdiag_sport;
__u16 tcpdiag_dport;
__u32 tcpdiag_src[4];
__u32 tcpdiag_dst[4];
__u32 tcpdiag_if;
#if defined (__hppa__) && defined (__LP64__)
char * parisc_hack_to_align_tcpdiag_cookie;
#endif
__u32 tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};

why is the offset of tcpdiag_cookie[0] 44 and not 40?

randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
Matthew Wilcox
2002-07-16 17:24:08 UTC
Permalink
Post by Randolph Chung
struct tcpdiag_sockid
{
__u16 tcpdiag_sport;
__u16 tcpdiag_dport;
__u32 tcpdiag_src[4];
__u32 tcpdiag_dst[4];
__u32 tcpdiag_if;
__u32 tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};
why is the offset of tcpdiag_cookie[0] 44 and not 40?
0 tcpdiag_sport
2 tcpdiag_dport
4 tcpdiag_src
20 tcpdiag_dst
36 tcpdiag_if
40 tcpdiag_cookie

hmm.. worth checking that dport is at offset 2, not offset 4?
--
Revolutions do not require corporate support.
Randolph Chung
2002-07-17 03:19:57 UTC
Permalink
Post by Matthew Wilcox
Post by Randolph Chung
why is the offset of tcpdiag_cookie[0] 44 and not 40?
0 tcpdiag_sport
2 tcpdiag_dport
4 tcpdiag_src
20 tcpdiag_dst
36 tcpdiag_if
40 tcpdiag_cookie
hmm.. worth checking that dport is at offset 2, not offset 4?
oic, it's embedded inside another structure:

struct tcpdiagmsg
{
__u8 tcpdiag_family;
__u8 tcpdiag_state;
__u8 tcpdiag_timer;
__u8 tcpdiag_retrans;

struct tcpdiag_sockid id;

__u32 tcpdiag_expires;
__u32 tcpdiag_rqueue;
__u32 tcpdiag_wqueue;
__u32 tcpdiag_uid;
__u32 tcpdiag_inode;
};

that's why it's 44...

randolph
Richard Henderson
2002-07-16 20:21:08 UTC
Permalink
Post by Randolph Chung
__u32 tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};
*((struct sock **)&r->id.tcpdiag_cookie) = sk;
and
sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))
This is absolutely awful.
Post by Randolph Chung
the "vomit grade hack" alan mentioned in another post is that in our
struct tcpdiag_sockid
{
__u16 tcpdiag_sport;
__u16 tcpdiag_dport;
__u32 tcpdiag_src[4];
__u32 tcpdiag_dst[4];
__u32 tcpdiag_if;
#if defined (__hppa__) && defined (__LP64__)
char * parisc_hack_to_align_tcpdiag_cookie;
#endif
__u32 tcpdiag_cookie[2];
An only marginally better fix is

__u32 tcpdiag_cookie[2] __attribute__((aligned(sizeof(void*))));

Note that this should be unconditional so that the other
64-bit ports don't take an alignment trap here too.

A much nicer fix would be to, gasp, use a union.



r~
John David Anglin
2002-07-26 17:42:06 UTC
Permalink
stage2/xgcc -Bstage2/ -B/home/c/lucier/local/gcc-test/sparcv9-sun-solaris2.8/bin/ -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include ../../gcc/bitmap.c -o bitmap.o
In file included from ../../gcc/system.h:171,
../../gcc/hwint.h:39:9: warning: integer overflow in preprocessor expression
<http://gcc.gnu.org/ml/gcc/2002-07/msg01238.html>.
The following patch appears to be the origin of the bootstrap failure
under hppa-linux:

2002-07-25 Richard Henderson <***@redhat.com>

* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
in ARRAY_REF of DECL_P case.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Richard Henderson
2002-07-27 21:10:42 UTC
Permalink
Post by John David Anglin
<http://gcc.gnu.org/ml/gcc/2002-07/msg01238.html>.
The following patch appears to be the origin of the bootstrap failure
* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
in ARRAY_REF of DECL_P case.
Surprising, to say the least, since I can only imagine problems
_without_ that patch, as evidenced by the SH problems it fixed.

If this is a stage2 failure, can you help me out by finding what
bit of stage1 got miscompiled?


r~
Richard Henderson
2002-07-27 22:07:26 UTC
Permalink
Post by John David Anglin
The following patch appears to be the origin of the bootstrap failure
* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
in ARRAY_REF of DECL_P case.
Please try

http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01625.html


r~
John David Anglin
2002-07-27 23:15:41 UTC
Permalink
Post by Richard Henderson
Post by John David Anglin
* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
in ARRAY_REF of DECL_P case.
Please try
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01625.html
Looks promising. Bootstrap is now into stage3.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-07-28 02:29:26 UTC
Permalink
Post by Richard Henderson
Post by John David Anglin
The following patch appears to be the origin of the bootstrap failure
* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
in ARRAY_REF of DECL_P case.
Please try
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01625.html
Problem fixed.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-08-01 19:02:05 UTC
Permalink
Turning the warning off is not the correct solution, although there
may be some circumstances in which it is emitted when it shouldn't
be.
I think so... but I am probably wrong hehe...
You can display the include search order with "gcc -v -E". The situation
where gcc emits the message when it shouldn't is when a user include directory
is specified and it is the same as the first directory searched by gcc.
For example,

gcc -v -E main.c -I/opt/gnu/include
...
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/opt/gnu/hppa2.0w-hp-hpux11.00/include"
cpp0: warning: changing search order for system directory "/opt/gnu/include"
cpp0: warning: as it has already been specified as a non-system directory
ignoring duplicate directory "/opt/gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/gnu/include
/opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include
/usr/include
End of search list.

As can be seen, the search order hasn't really changed. If "-I/usr/include"
were added to the command, the search order would really have changed.

These are rules under which the macro lib-prefix.m4 used by configure
in textutils-2.1 adds include directories to CPPFLAGS:

dnl Potentially add $additional_includedir to $CPPFLAGS.
dnl But don't add it
dnl 1. if it's the standard /usr/include,
dnl 2. if it's already present in $CPPFLAGS,
dnl 3. if it's /usr/local/include and we are using GCC on Linux,
dnl 4. if it doesn't exist as a directory.

"/opt/gnu" is my standard prefix. As can be seen, the above macro
will add "-I/opt/gnu/include" to CPPFLAGS and cause a gcc warning
if something interesting is found there (e.g., libintl.h).

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Graeme Peterson
2002-10-08 21:39:21 UTC
Permalink
This got it working. I also had to add:

# Do not build libgcc1.
LIBGCC1 =
CROSS_LIBGCC1 =

Thanks, all.
GP
LIB2FUNCS_EXTRA = fp-bit.c dp-bit.c tramp.S
dp-bit.c: $(srcdir)/config/fp-bit.c
cat $(srcdir)/config/fp-bit.c > dp-bit.c
fp-bit.c: $(srcdir)/config/fp-bit.c
echo '#define FLOAT' > fp-bit.c
cat $(srcdir)/config/fp-bit.c >> fp-bit.c
I'm building it now, but the comment at the top of fp-bit.c
"/* This is a software floating point library which can be used instead of
the floating point routines in libgcc1.c for targets without hardware
floating point. */ "
Think that might be it? :-)
GP
Hi, all.
I have done some searching, and it seems that gcc (in this case
2.95.3 targetting ppc-QNX6) does not have support for statically
linked software emulated floating point instructions.
Can someone clarify for me what is required to get this going? Do
I need to implement the floating point emulation and tell gcc to
use it in place of the fadd in the __adddf3 call? If so, how do I
do that?
You need to specify the multilibs in your target file for qnx.
For example, in the current gcc source, gcc/config/rs6000/t-rs6000
contains
MULTILIB_OPTIONS = msoft-float
MULTILIB_DIRNAMES = soft-float
Andrew.
John David Anglin
2002-11-13 21:12:06 UTC
Permalink
Post by John David Anglin
Post by H.Merijn Brand
ldd: "gengenrtl" is not a shared executable.
collect2: /usr/ccs/bin/ldd returned 1 exit status
I have installed the patch below and it should fix the above problem.
I forgot to say it was tested with both HP and GNU ld on hppa64-hp-hpux11.11.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-11-22 23:13:16 UTC
Permalink
I am working on using the PARALLEL method for IA64 they way you did on
PA64 so we can get rid of FUNCTION_ARG_REG_LITTLE_ENDIAN and noticed
that on PA64 you use it in function_arg to handle arguments but there is
nothing to handle function return values and I think we need it there
too to handle returns of small structures.
You are correct, PA64 GCC incorrectly returns small structs. I will
try and see if I can detemine what is wrong with your patch.
There is a problem with using the PARALLEL method for function
values and sjlj exception handling. After a lot of C++ debugging, I
have determined why g++.robertl/eb21.C fails with the patch that
I have to return a PARALLEL.

The function _ZSt24__uninitialized_copy_auxIN9........ is miscompiled.
It returns a small structure in register %r28. The return value is output
by expand_value_return at insn 88 followed by a jump to label 162.
However, after code_label 162, we have a call to _Unwind_SjLj_Unregister
which clobbers the return value %r28. It would also clobber any
value in the other return register %r29.

The call to _Unwind_SjLj_Unregister obviously has to occur before
the return value is copied to the return registers but I am not sure
how to do this. I am not sure why this isn't a problem when we don't
use a PARALLEL. There is a bug in cfg.c that causes an ICE when
dumping rtl. The global max_regno is not always in sync with the
number of pseudos. I need to rebuild gcc with this fixed before
I can compare what happens without PARALLEL function values.

The rtl from the first jump pass is enclosed below.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)

begin 640 eb21.jump.gz
M'XL(")6PWCT``V5B,C$N:G5M<`#M7'MOW+@1_]^?@@AZ0'QU$I%Z44Y;-(^]
MJQ'#R7D=H&U@"/N0[;VNI3U)ZR17]+MWAI)V)2U%2NO5>7/G%#TD*W+F-^2\
M1>KE2_+#,***@D_@]1_'D43T_2("9).CT^]OUE.`MGZ6PTG_T:3/U)M/CJ
MCY9?GOHGX6*9XL`C4OE[B03\R[\:S9/`3[\***@D/RZ?,LO2F-)G^%`=?ATI]\
M^8*LPBB^'<W]&3P:I5'\ETD4AH%`YJ??'V6`[N"'VJ/\R6@^CR8;\_Y&X']5
M6+\9V\N#`VI0$@?7LP2()\\/#L[SOQ/'(<LDF!)*TMEMD)#1)(Z2A!AD%B9A
M\I(D09H_>TFF,***@P"^'A8CZ:!/#T[+U_/OAQ2**8A%$(0Q;1+`2R%0YNQH$I
M..3/6K"H4.;WP4[)^&NJX^#M<'7*A%VC[V5W:5_065^$S;X(6WT1MOLBO$NK
MK!#NS1C=>QFCBG!?-LAW:8,5PGV9'N_+]'A?IL>MOO2-W\OVK!;.G[N]<[B7
MS;3BX.UR_:6!QNO+C+Q=FI$<.NM+.[U=&I0<^RZ#FIS#+J.;G$/OR:?7NPU[
MNXQ[<AEV&0"E'*C15SI*(<L>);,)&4-U\I_DB%";!-/K`&N0U^L'Q#@F5[,X
M205#0AW[B,Q'\$_&***@B#N[(,WI$PN`+P(`G4;3PI\$"BCCCB$RB99CB7Z[B
MX!=B/#_X$`?3`(`E49P<$S(XNSC_%WD*!>`\O8F7AP?#Y63]E):?%`N2D/GL
M+B"C%$JK49P>DZ?A;"Y['(33XN%)>`>UZ90DRUL279%HF5[#*EP#^F@\&L_F
M4+O"NAG/C>^JDM.*Y";-!3>=7'`CEYMUE=N"'6J2FI6>$$Z>CL9'H_$$?CD*
M;AYF&5A-`=QB';Q\'8K]-[NN`VU<!;.\"M:#B&W6Q.:YV):1B\URL:VN8K-&
ML>T'D=2J2&JQ7%"WV%\S%]3N+&C-H!]$.KLB'2^DXX5T5BZ=TU4ZLR:=\2#B
M.54UY68N'Z6%@'8NH-M50%X5T-T[S^1697>M0G9FY[([N>R\J^Q.HXWNA>2\
M(CEC3A&45\')S27WNDKNUN3#I:C^0.LK4%D?KZPFSH.LCE?3BV)UJ%?X;EZD
M+$9GHVA2C'M)6LT[ZBE7X;.H8^7XO1S_L\ZYAUW=K<$_3RX>(L\Z.$CCKWZT
M@,1U]***@3ZZN2=9=QY<,].`@;\;C=$Q*"7OV-Y.D$;')***@V#Z;/#YZ&40J_
M0RH%.2DDNA<#_^1L>.:_'9P.+@9O84VS$?B4$6:Y,/+3>$R,R]+@UZ^&)V_\
MUZ?OW[S#"9DUP5"<9,($H_:'/,5\^VD<7!^_/2$N/3P@^9_B-^:2[V+F'AY"
M7IROBWB,?UNQ,`432\***@Q162<YP2B\5\F>"/Z\?,0V[>>HP8-XG")/4AT2?/
M'(M\,KY<5?Y,C,M#P$=MC_SW^\7H^>WTV.2V^[]&N!8`MIO!W@:W+VJX`#;P
MQ9<[J,=_-LB0DU>.=2E9+P<E<-3K90,$IPV`S14J+Z!***@3@N#X?UR."BF2G1
MVHC65J-U`*_;"UKJ(%QJK/#&0;*<JQ%;B-A2(W8!,]>JN^-*R)M(WE23Y\#`
MZT9^E-S,KE)P//GRU`?4%L86"V-RH=@*)!***@H88:RD_`B9>@9/OUTS;[Q83U
MT5R_<)LH>27^I<`(^#Q(WYI!_AK$D0_>/QY-LO5)EN-\B4H"$*-QM0JE;[&:
M&QON:%P;``<!*-/I_T[7LXHRD[\)9184&`)E!IKI.AK\\/'LS<7)>P@+@Q_7
MX0`&P7!FJ`TDP\^]!G==#@W59;^97=]DN_CU=AS-P:2O7BS%#T^^/_W3&V#"
MGAP>:O0:T2%09JCM3((2MR/C-X]\"-W5#>&>9$.68;(()OCXT\;#U2"E.-)I
MEZ"RPJ\5SDPCLI>)K;-GX.T9=8$SZ2IRMN<,'`5WE9$"EP8?CQ[35*JYRU#-
MK2(L-?IV#]>+4KX.XXR;S6$<\0KL*NLL2+-=*/)JWT^';U]1E[LM-!EM30#5
MYU\5D$UZ7!^XK1;+9-F%&H.<F<QMTD%/DG&"<'4.P9=%[,\A4S\^'_SH#W[Z
M^***@9O!(^*\>HS@"W5G9NH++;ADK95\)W4W<[0V^U\=R>V:#PC7*491`1
MU>8=\VI$EJ%4)+=KA$VQI0W"4N:H44<GAZ7.8*N\8?%T>^=UW#***@T);[9U=
M8CD?C8.5EC-)98$,UL9Q^NKUX!3';2H^SV&T":F>)95ZLU*0FN8&YF9K]#)@
M3!'TFJW1TYABN1A2;::FG$!T`BG;*D!J4-:*(`5.TT";,'1@:0:8J:-BCDU=
MCZN-L)2^=G(3@"Q#J0^)13DMVS5-D8WD,U9M(M%&YT&V&OGZ-W8GLJVL=B>N
M.G0GL`/IY^"M7`!YF%J,8A@;S&NQ7E#(='%83<'OLB#Y=_]C^'D63OWASZ<_
M^T7[ZTFN>A9Y9;)+I;9F#1C+N#RL+\,\&H^#.-LY8$YAK:AN$,-%KP]:)D&9
MHXBG%7Z7&B?T#WQ)#'6/C$K-$]7FY\SKO:_U),G(JO[49&FB7'2)-I<Z<Y!E
M-;8S;5#XGJ8\MM38TT3)G`VPX$C7!+T-1HXS#>I-C7JIU5OG1V/;B-DTFO&J
ML.F3N`UXDV6LZDHYK=,!4:Z;Z)Z)24NU^NG[]Q^*.GT230-?Q%`<8V)'V`%[
M<BAY\H1\$F>5DLM20]@1PQ@,P88PU36$<202]#C,:-[N;*U<0^D2Z]LLB[[J
***@J@0$">!V`***@W.@I?3HE(40CYL4V&DF<GFM*;41"!"<&8SL,+/;J-***@9@
M%?;KOK<D]2$>XBXT"PR5-L=61`O`34NYM9K(***@B*U`'/J:MYY&WER4\7$T:
M`]21C=-"1?<L=`-F7!K'E4)O"MR59>,H$)>ICS:\__O,6UWU"(.3#Y25+VD,
M4R>[UW$RI/YPA/\=P)_Q^;NSH4_=C9LA)Q?^A0%#AJ]]78Y06]!2GO!M)0I4
M>/Z]212*%S2;NM`YM5@+D^<7>?APA<JZZ!$A?#!M^'"S.5"UZ<Q_VWP$:`,7
MT]-R<-DF\<)ZFCC\O+Q=Y);J(2?J*"193$H,9E=^>A.$?C#']0Z#U9N*X4D9
M$;&4CG]33<6`5<U,K%IW#T%HVO\@`@AC&1!W<`]-Q1ZNQ;<,,=&"W*&5^&N$
M?+-%5^`9C^)X!H8+5($^BE+)9RR&3ZCCX1M0JR&?\7"8#02$,)9.(>V,H`VD
M.\>\>_6=VI>\MI#'-I4(]S*:`68$;TF1]Q7,7LS6X>S=.I[)`E2K`#<-!G=_
ME/CUS1:ZH&.H;+;>BK<-*T`;F3A:#J[9/:QD'!S!Q-W"$[7.OH$ZLN'?H"_A
M`KSWZ$M68QY]23^^Q$-E<XS^?`G0!B8.U?L2:TM?`K2!B;--5K-V8VH.3#!1
M9R6-=7PNG)J#*9C(LX>]]E6`&<'+HU'W[GO)"PU3:OAO$'.\G*0G-9\#U?;=
MAPO__!W4W8]M^=]3M9VIE2TTJT6"L(5C$N43T`8F+CJF6G?YS?NSB_4128HC
MW2V]2[M,!:@#&_<;K'H`,X)_N*IG!XG*8O&8J%3G[V&B`BJ&NM9CT0.TD8F^
MZ'***@A@0Y!JG[B?;L(5X.6EV*.;>'03C>.[***@DN=$U>.=_73:P[PL``.'%%
MV=30$#:;J1<-8:`*Y#E=)2H<7X_AAV9J:<K@[&VM:0QC8#"%7,+&<D+:-(:'
M.`SOJF#3V-8UC6&DF./"!$T!5ZY[>CU6T.5$(0`'$3C7PY<5AIH;/T`6Z7M:
MXAO^J\15KV[``#AY1C.;!G6CCOX%!)`%^I2;-66"7_`9LZ`NQ?14IDWX4(QS
M8`RJDZ-0)YSQ(L&Q8IH!B342W;C!EQ_-Q!,3JYLQ%*=1`Z%L6^/K[J\8&29J
MF$HF>QE?$70F@"4%W_?+=`BL(W\<7,]"?S)*)S>/<7+/XR0JBE`:VL*DMLVH
MD;***@1-4F)6AMWKQ[B/-R"%7`IG)#JD!N>\3O-XUWB!RE8"V<)3<DFZKIMB)=
MY,&$G]0<1"LKS>;)D8X'T1H.G)20F3DZNQG9;W(2S>UR$@WA,F&*SO;1C6M.
MB2%Q9$2IJ]<*R5TCU]/1=W,>7"]$4Y.<:_T)SQEYWV"(IEXF@-LM1+=LE7/_
M;9"D<?3U9.M:EXE:EXF#;H.["W_(_PB-=5-<>=Z;$-[_,3;7RG2109TI<G97
M5P+B4#&-63"EKV2!61DC9BN9[*=Q`^A,`%<*?OM;*"*SCH/T)HX^_R&ML3KI
M[/WYX.+CN3H)+RE^WV:<FU>IG$85H.*.B%,MJ*'TQ=N&^)Q9-GX;(^O0L(V:
M6DR&_[MX-0`,E&N_7)/39%##<4GF4Q4E2W0TUT9X3M23$JPH"))$-5+TMO);
MKUY.6$ZT:N'44%^H4'?85;:ME-O+8(+OT$.L0:AB[W3K5=QS0;94OG_BQKI_
M%\U'Z6P>;'B1YKL:>"==*3!P%-PAMU4)?"_7CL0S1J:4R2BY!?2+);!Z\D1'
MRLS)66J\X+6\,M0>\OX..3["S:#;VF5VZ["W+2HMX1A9_5YO-\6T<^R.%C>W
M=H5;7(@RZ_=\6^)>=TT1-`I`&ZQ*=VX]^$6J2A+$JX*V:I>E/BRONRK=476(
M%E28#+;?U7U2MY3;.6(6!57S1.CPM+D=7H02TRS\2!*N3'-A*+E$H&***@TK
MY`$;H:4O.4W*-0>GJ-A@;$>H\>]***@W*ZP<NX.?R)(K9Z_-"DGJULJAE;)>
M-#`AARM=^WMFO4$X;==-_AWDO1GLW[P*7:>O^8:Z8E.IR;7&NGVAAU>)!"-/
MR\25T%?<J<GI>QD/R]1[',F94]Z<&Q>.V3(%%V:@3U.Y9J]D[[:8QPR%O1?]
M0RXUTV=4XG>N.K=1F\@TMU6=##V^@GS0MBKOU%;E7$"GW%,O^+U>&HHWIQP_
M,*MDLD?1I^2^`;00P&-2\+OZ=$:RO`U^7RZ\51?B&***@5N.I9>"S3!L<HW2XT
MLM\=)OM2XL;A$_2+#LNF<7SOAX?R9?T-\=3!$L[%4>)+#/IO\^)@CI.R[WAJ
M+,WC:B-3]@ZV_5H/7O3%V\$8?^[SN1[="SB,/,@+KZ5^>]_KL8Q,`HO*T>_&
MZWP,X\=/]B@=Q#Z<0D`E$&KL6"U,9NN$T[$$)V$NE7PPL(P:=O5]H_\#OB3Y
%CA%U``!/
`
end
John David Anglin
2002-12-17 16:39:39 UTC
Permalink
The toplevel configure script sets "LD=ld". The ld used by the GCC check
in the opcodes directory has the line
test -z "$LD" && LD="$ac_prog"
The above line comes from libtool.m4. If we set LD="" in the toplevel
configure script, the libtool script then sets LD to ld program used by
GCC. However, this define for LD isn't a proper default. So, I am
wondering if the libtool script should also reset LD when LD=ld?

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2002-12-20 23:57:09 UTC
Permalink
Post by John David Anglin
The toplevel configure script sets "LD=ld". The ld used by the GCC check
in the opcodes directory has the line
test -z "$LD" && LD="$ac_prog"
The above line comes from libtool.m4. If we set LD="" in the toplevel
configure script, the libtool script then sets LD to ld program used by
GCC. However, this define for LD isn't a proper default. So, I am
wondering if the libtool script should also reset LD when LD=ld?
After some discussion of this matter on the libtool list, the conclusion
is that Cygnus configure shouldn't be setting LD and other similar defines
in native builds. PR 9031 has more details.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2003-01-02 17:48:23 UTC
Permalink
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
extern void weak_func (void *arg);
asm (".weak weak_func");
void
test (void *arg)
{
if (&weak_func != (void *)0)
weak_func (arg);
}
As GCC is not told in any way that weak_func is actually weak, I think
it is glibc's fault.
This is definitely a gcc problem. This is the code arising from
stw %r2,-20(%r30)
ldo 64(%r30),%r30
ldw -84(%r30),%r2
bl weak_func,%r0
ldo -64(%r30),%r30
We have completely lost the `if'. As a result, weak_func is always
called.
There is another problem. The call to weak_func has been turned into
a sibcall. It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
consulted as we don't allow indirect sibcalls on hppa-linux.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Jakub Jelinek
2003-01-02 17:53:32 UTC
Permalink
Post by John David Anglin
There is another problem. The call to weak_func has been turned into
a sibcall. It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
consulted as we don't allow indirect sibcalls on hppa-linux.
The call is not indirect, it is normal direct call
(even if weak_func is marked __attribute__((weak)) or #pragma weak).

Jakub
John David Anglin
2003-01-02 18:58:07 UTC
Permalink
Post by Jakub Jelinek
The call is not indirect, it is normal direct call
(even if weak_func is marked __attribute__((weak)) or #pragma weak).
Sorry, for the net garbage. My original analysis of the glibc problem
involved an indirect call.

Dave
--
J. David Anglin ***@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Daniel Jacobowitz
2003-01-02 17:57:18 UTC
Permalink
Post by John David Anglin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
extern void weak_func (void *arg);
asm (".weak weak_func");
void
test (void *arg)
{
if (&weak_func != (void *)0)
weak_func (arg);
}
As GCC is not told in any way that weak_func is actually weak, I think
it is glibc's fault.
This is definitely a gcc problem. This is the code arising from
stw %r2,-20(%r30)
ldo 64(%r30),%r30
ldw -84(%r30),%r2
bl weak_func,%r0
ldo -64(%r30),%r30
We have completely lost the `if'. As a result, weak_func is always
called.
There is another problem. The call to weak_func has been turned into
a sibcall. It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
consulted as we don't allow indirect sibcalls on hppa-linux.
This isn't an indirect call, though. weak_func is not a pointer...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
John David Anglin
2003-02-03 05:02:44 UTC
Permalink
I now have tests running on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.00
and hppa-unknown-linux-gnu including the patch set for the other PR from
Franz Sirl. I will post the results as soon as available.
The hppa2.0w-hp-hpux11.11 are complete and identical to the previous
run without Franz's patch:

<http://gcc.gnu.org/ml/gcc-testresults/2003-02/msg00130.html>.

I had to restart the hppa64-hp-hpux11.00 run. I used the HP linker
and it generates a warning on each link. This totally messes
up the testsuite results. I would like to apply the following patch
from Steve Ellcey to correct the problem. It has been on the main and
3.3 since early last October. The comment describes what it does. It
only affects hppa64-hp-hpux11* and doesn't affect code generation.

As you are doing preleases, I will wait for your OK.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)

2003-02-02 Steve Ellcey <***@cup.hp.com>

* config/pa/pa64-hpux.h (INIT_ENVIRONMENT): New.

Index: config/pa/pa64-hpux.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa64-hpux.h,v
retrieving revision 1.9
diff -u -3 -p -r1.9 pa64-hpux.h
--- config/pa/pa64-hpux.h 21 Jan 2002 21:22:19 -0000 1.9
+++ config/pa/pa64-hpux.h 3 Feb 2003 04:38:07 -0000
@@ -232,3 +232,8 @@ do { \
#ifndef ASM_DECLARE_RESULT
#define ASM_DECLARE_RESULT(FILE, RESULT)
#endif
+
+/* If using HP ld do not call pxdb. Use size as a program that does nothing
+ and returns 0. /bin/true cannot be used because it is a script without
+ an interpreter. */
+#define INIT_ENVIRONMENT "LD_PXDB=/usr/ccs/bin/size"
Gabriel Dos Reis
2003-02-03 11:03:02 UTC
Permalink
"John David Anglin" <***@hiauly1.hia.nrc.ca> writes:

[...]

| As you are doing preleases, I will wait for your OK.

It is OK.

Thanks,

-- Gaby
John David Anglin
2003-02-03 16:25:54 UTC
Permalink
Post by John David Anglin
I now have tests running on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.00
and hppa-unknown-linux-gnu including the patch set for the other PR from
Franz Sirl. I will post the results as soon as available.
The hppa2.0w-hp-hpux11.11 are complete and identical to the previous
All test runs are complete and posted. There are no regressions.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Gabriel Dos Reis
2003-02-03 16:54:20 UTC
Permalink
"John David Anglin" <***@hiauly1.hia.nrc.ca> writes:

| > > I now have tests running on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.00
| > > and hppa-unknown-linux-gnu including the patch set for the other PR from
| > > Franz Sirl. I will post the results as soon as available.
| >
| > The hppa2.0w-hp-hpux11.11 are complete and identical to the previous
| > run without Franz's patch:
|
| All test runs are complete and posted. There are no regressions.

Thanks for the report. Please commit the set of patches you tested.

This hopefully will be the last patch to commit.

-- Gaby
John David Anglin
2003-02-03 18:02:32 UTC
Permalink
Post by Gabriel Dos Reis
Thanks for the report. Please commit the set of patches you tested.
Done.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
John David Anglin
2003-02-11 19:37:10 UTC
Permalink
stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
../../gcc/gcc/bb-reorder.c -o bb-reorder.o
(insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
(reg:DI 74 %fr25))) -1 (nil)
(expr_list:REG_UNUSED (reg:SI 71 %fr23R)
(expr_list:REG_DEAD (reg:DI 74 %fr25)
(nil))))
../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
I have determined that it is the addition of this patch that results in
the above ICE:

2003-02-10 Josef Zlomek <***@suse.cz>

* Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
* bb-reorder.c (make_reorder_chain): Deleted.
(make_reorder_chain_1): Deleted.
(find_traces): New function.
(rotate_loop): New function.
(mark_bb_visited): New function.
(find_traces_1_round): New function.
(copy_bb): New function.
(bb_to_key): New function.
(better_edge_p): New function.
(connect_traces): New function.
(copy_bb_p): New function.
(get_uncond_jump_length): New function.
(reorder_basic_blocks): Use new functions (Software Trace Cache).
* cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
boundaries.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Josef Zlomek
2003-02-11 22:37:43 UTC
Permalink
Post by John David Anglin
stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
../../gcc/gcc/bb-reorder.c -o bb-reorder.o
(insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
(reg:DI 74 %fr25))) -1 (nil)
(expr_list:REG_UNUSED (reg:SI 71 %fr23R)
(expr_list:REG_DEAD (reg:DI 74 %fr25)
(nil))))
../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
I have determined that it is the addition of this patch that results in
* Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
* bb-reorder.c (make_reorder_chain): Deleted.
(make_reorder_chain_1): Deleted.
(find_traces): New function.
(rotate_loop): New function.
(mark_bb_visited): New function.
(find_traces_1_round): New function.
(copy_bb): New function.
(bb_to_key): New function.
(better_edge_p): New function.
(connect_traces): New function.
(copy_bb_p): New function.
(get_uncond_jump_length): New function.
(reorder_basic_blocks): Use new functions (Software Trace Cache).
* cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
boundaries.
I apologize for the breakage. It seems that new bb-reorder has uncovered
bugs in machine descriptions.
Honza Hubicka has checked in a patch
(http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00847.html)
which hopefully should enable gcc to bootstrap again.

Josef
John David Anglin
2003-02-11 22:51:10 UTC
Permalink
Post by Josef Zlomek
Post by John David Anglin
stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
../../gcc/gcc/bb-reorder.c -o bb-reorder.o
(insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
(reg:DI 74 %fr25))) -1 (nil)
(expr_list:REG_UNUSED (reg:SI 71 %fr23R)
(expr_list:REG_DEAD (reg:DI 74 %fr25)
(nil))))
../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
I have determined that it is the addition of this patch that results in
* Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
* bb-reorder.c (make_reorder_chain): Deleted.
(make_reorder_chain_1): Deleted.
(find_traces): New function.
(rotate_loop): New function.
(mark_bb_visited): New function.
(find_traces_1_round): New function.
(copy_bb): New function.
(bb_to_key): New function.
(better_edge_p): New function.
(connect_traces): New function.
(copy_bb_p): New function.
(get_uncond_jump_length): New function.
(reorder_basic_blocks): Use new functions (Software Trace Cache).
* cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
boundaries.
I apologize for the breakage. It seems that new bb-reorder has uncovered
bugs in machine descriptions.
Honza Hubicka has checked in a patch
(http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00847.html)
which hopefully should enable gcc to bootstrap again.
I have been looking at the patterns which use the xmpyu insn on the PA.
There are two patterns (32 and 64 bit) which have an uint32_operand
predicate and "f" constraint. The "f" constraint is inconsistent with
the predicate. The uint32_operand predicate is inconsistent with the
actual capability of the machine instruction. I had queried Jeff Law
Post by Josef Zlomek
I thought changing the operands of the pattern to register_operand is a more
accurate description of the machine insn although reloads still can
potentially occur.
It's certainly more accurate, but due to secondary effects of register
allocation
and reloading it's actually more profitable to be more general in the
operand predicates than what the instruction actually allows. That is
generally a bad thing to do, but from time to time it is helpful.

Basically, some games are being played with the predicate and constraint
to improve the generated code.

The 32-bit seems to be building again. However, the have been some
"strange" warning messages on hppa64-hp-hpux11.11:

g-yacc.29398.c: In function `yystrlen':
g-yacc.29398.c:708: warning: traditional C rejects ISO C style function definiti
ons
g-yacc.29398.c: In function `yystpcpy':
g-yacc.29398.c:733: warning: traditional C rejects ISO C style function definiti
ons
g-yacc.29398.c: In function `yydestruct':
g-yacc.29398.c:800: warning: traditional C rejects ISO C style function definiti
ons
g-yacc.29398.c: In function `yyparse':
g-yacc.29398.c:863: warning: traditional C rejects ISO C style function definiti
ons

and

c-p29635.c: In function `yy_stack_print':
c-p29635.c:2150: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yy_reduce_print':
c-p29635.c:2176: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yysymprint':
c-p29635.c:2297: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yydestruct':
c-p29635.c:2333: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yyparse':
c-p29635.c:2396: warning: traditional C rejects ISO C style function definitions

Possibly, this is a bison 1.875 problem. Yes, it seems to be.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Josef Zlomek
2003-03-05 22:00:29 UTC
Permalink
Post by John David Anglin
stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
../../gcc/gcc/bb-reorder.c -o bb-reorder.o
(insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
(reg:DI 74 %fr25))) -1 (nil)
(expr_list:REG_UNUSED (reg:SI 71 %fr23R)
(expr_list:REG_DEAD (reg:DI 74 %fr25)
(nil))))
../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
I have determined that it is the addition of this patch that results in
Maybe it is a similar problem in machine descriptions as alpha and sh did
have (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01295.html). But maybe I'm wrong.
The bb-reorder itself is pretty high level, it is a probably first use
of code duplication functions which went to mainline.
Anyway, I apologize for the breakage.

Josef
Post by John David Anglin
* Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
* bb-reorder.c (make_reorder_chain): Deleted.
(make_reorder_chain_1): Deleted.
(find_traces): New function.
(rotate_loop): New function.
(mark_bb_visited): New function.
(find_traces_1_round): New function.
(copy_bb): New function.
(bb_to_key): New function.
(better_edge_p): New function.
(connect_traces): New function.
(copy_bb_p): New function.
(get_uncond_jump_length): New function.
(reorder_basic_blocks): Use new functions (Software Trace Cache).
* cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
boundaries.
Josef Zlomek
2003-03-05 22:03:03 UTC
Permalink
Post by Josef Zlomek
Post by John David Anglin
stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
../../gcc/gcc/bb-reorder.c -o bb-reorder.o
(insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
(reg:DI 74 %fr25))) -1 (nil)
(expr_list:REG_UNUSED (reg:SI 71 %fr23R)
(expr_list:REG_DEAD (reg:DI 74 %fr25)
(nil))))
../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
I have determined that it is the addition of this patch that results in
Maybe it is a similar problem in machine descriptions as alpha and sh did
have (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01295.html). But maybe I'm wrong.
The bb-reorder itself is pretty high level, it is a probably first use
of code duplication functions which went to mainline.
Anyway, I apologize for the breakage.
Or there simply is some code in bb-reorder.c which uncovers another bug.

Josef
John David Anglin
2003-02-11 19:59:33 UTC
Permalink
/* Ignore alignment we can't do with expected alignment of the
boundary. */
if (alignment * BITS_PER_UNIT > PREFERRED_STACK_BOUNDARY)
alignment = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
but really that's wrong, and at a minimum it should warn the user
that their requested alignment isn't going to happen (better would be
to just ensure the requested alignment). We occasionally get bug
reports about this, but so far no-one has invested the effort to
implement arbitrary stack alignment.
Now we have *yet another* macro involved in alignment!
Another issue is GCC's alignment attribute is silently ignored for stack
locals and the documentation doesn't say that.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Mike Stump
2003-02-11 21:00:15 UTC
Permalink
Post by John David Anglin
/* Ignore alignment we can't do with expected alignment of the
boundary. */
if (alignment * BITS_PER_UNIT > PREFERRED_STACK_BOUNDARY)
alignment = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
but really that's wrong, and at a minimum it should warn the user
that their requested alignment isn't going to happen (better would be
to just ensure the requested alignment). We occasionally get bug
reports about this, but so far no-one has invested the effort to
implement arbitrary stack alignment.
Now we have *yet another* macro involved in alignment!
Another issue is GCC's alignment attribute is silently ignored for stack
locals and the documentation doesn't say that.
Let us agree that this is just a bug, or at least a bug for CPUs that
have hard requirements of say 16 bytes (Altivec, SSE) and the user asks
for 16 byte alignment and we silently only do 8 byte alignment.
Fergus Henderson
2003-02-12 05:53:48 UTC
Permalink
Post by Mike Stump
Post by John David Anglin
Another issue is GCC's alignment attribute is silently ignored for
stack locals and the documentation doesn't say that.
Let us agree that this is just a bug, or at least a bug for CPUs that
have hard requirements of say 16 bytes (Altivec, SSE) and the user asks
for 16 byte alignment and we silently only do 8 byte alignment.
Please let us agree that this is just a bug, regardless of the CPU's
requirements. The alignment declaration might be used by the programmer
to ensure that the lower bits are available for use as tag bits.

For example, the following program should result in either success
or a compile error (if the requested alignment is not supported).
But IMHO it should not result in an assertion failure.

#include <assert.h>
#define ALIGN 32
int main() {
char c __attribute__((aligned(ALIGN)));
assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
return 0;
}
--
Fergus Henderson <***@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
John David Anglin
2003-02-12 16:18:48 UTC
Permalink
Post by Fergus Henderson
Please let us agree that this is just a bug, regardless of the CPU's
requirements. The alignment declaration might be used by the programmer
to ensure that the lower bits are available for use as tag bits.
For example, the following program should result in either success
or a compile error (if the requested alignment is not supported).
But IMHO it should not result in an assertion failure.
#include <assert.h>
#define ALIGN 32
int main() {
char c __attribute__((aligned(ALIGN)));
assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
return 0;
}
You have my vote on the matter.

If we go back to Franz's original reply to my post regarding the
rs6000 port, he said "BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY
is 64 unless you give -mabi=altivec (in 3.2+)." If you look at
assign_stack_temp_for_type and assign_stack_local_1, you will see
that BLKmode objects are aligned to BIGGEST_ALIGNMENT. Thus, without
-mabi=altivec, you would randomly get an assertion failure, depending
on the stack alignment, if you checked the alignment of structs with
code similar to that above. In other words, you aren't getting the
alignment of BLKmode stack locals that you have specified in the
backend. Possibly, this doesn't matter, but it seems inconsistent
and I think would lead to problems if the compiler checked alignment
requests as suggested above.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Richard Kenner
2003-02-11 21:13:27 UTC
Permalink
Let us agree that this is just a bug, or at least a bug for CPUs that
have hard requirements of say 16 bytes (Altivec, SSE) and the user asks
for 16 byte alignment and we silently only do 8 byte alignment.

Well it's more complex than that because to *know* that we have these
hard requirement, we have to make STRICT_ALIGNMENT take an operand,
which is the mode.

Moreover, the criteria you cite isn't totally clear. Even if the
alignment isn't *required* and even if it isn't even preferred from an
efficiency standpoint, can we just ignore it? In Ada, for example,
you cannot since it imposes constraints on the permitted values of
the object's address. We also assume those constraints in combine.c.

We have to use all the attribues we have about alignmen to deduce two
things, which are the *default* and the *maximum* alignment we'll allow
for each object and type.
Richard Kenner
2003-02-12 13:57:20 UTC
Permalink
The alignment declaration might be used by the programmer to ensure
that the lower bits are available for use as tag bits.

Exactly.

For example, the following program should result in either success
or a compile error (if the requested alignment is not supported).
But IMHO it should not result in an assertion failure.

#include <assert.h>
#define ALIGN 32
int main() {
char c __attribute__((aligned(ALIGN)));
assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
return 0;
}

This is *desirable* in C, as you say, but the equivalent Ada program is
*required* to have the behavior you want and there are tests to ensure
that it does.
Ulrich Weigand
1970-01-01 00:00:00 UTC
Permalink
Interestingly, mainline works fine without any patch.
When your latest mainline patch to unwind-dw2.c is backported
to 3.3, it works again as well; the patch below does this.

(A full bootstrap/regtest is still running.)

Note that I really only need the first hunk, as the
rest only changes the return value from uw_install_context_1,
which is completely ignored on s390 anyway (as SP is
restored from its stack slot, where the correct new
value was already stored by uw_install_context_1).

What do you think?

Bye,
Ulrich

ChangeLog:

* unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
previous frame didn't save sp. Clear sp for next frame.
(uw_install_context_1): Honor saved sp from frame.


*** unwind-dw2.c.orig Wed May 7 02:52:49 2003
--- unwind-dw2.c Wed May 7 03:00:45 2003
*************** uw_update_context_1 (struct _Unwind_Cont
*** 1059,1069 ****
In very special situations (such as unwind info for signal return),
there may be location expressions that use the stack pointer as well.

! Given that other unwind mechanisms generally won't work if you try
! to represent stack pointer saves and restores directly, we don't
! bother conditionalizing this at all. */
! tmp_sp = (_Unwind_Ptr) context->cfa;
! orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;

/* Compute this frame's CFA. */
switch (fs->cfa_how)
--- 1059,1075 ----
In very special situations (such as unwind info for signal return),
there may be location expressions that use the stack pointer as well.

! Do this conditionally for one frame. This allows the unwind info
! for one frame to save a copy of the stack pointer from the previous
! frame, and be able to use much easier CFA mechanisms to do it.
! Always zap the saved stack pointer value for the next frame; carrying
! the value over from one frame to another doesn't make sense. */
! if (!orig_context.reg[__builtin_dwarf_sp_column ()])
! {
! tmp_sp = (_Unwind_Ptr) context->cfa;
! orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
! }
! context->reg[__builtin_dwarf_sp_column ()] = NULL;

/* Compute this frame's CFA. */
switch (fs->cfa_how)
*************** uw_install_context_1 (struct _Unwind_Con
*** 1201,1206 ****
--- 1207,1213 ----
struct _Unwind_Context *target)
{
long i;
+ void *target_cfa;

#if __GTHREADS
{
*************** uw_install_context_1 (struct _Unwind_Con
*** 1222,1232 ****
memcpy (c, t, dwarf_reg_size_table[i]);
}

/* We adjust SP by the difference between CURRENT and TARGET's CFA. */
if (STACK_GROWS_DOWNWARD)
! return target->cfa - current->cfa + target->args_size;
else
! return current->cfa - target->cfa - target->args_size;
}

static inline _Unwind_Ptr
--- 1229,1246 ----
memcpy (c, t, dwarf_reg_size_table[i]);
}

+ /* If the last frame records a saved stack pointer, use it. */
+ if (target->reg[__builtin_dwarf_sp_column ()])
+ target_cfa = (void *)(_Unwind_Ptr)
+ _Unwind_GetGR (target, __builtin_dwarf_sp_column ());
+ else
+ target_cfa = target->cfa;
+
/* We adjust SP by the difference between CURRENT and TARGET's CFA. */
if (STACK_GROWS_DOWNWARD)
! return target_cfa - current->cfa + target->args_size;
else
! return current->cfa - target_cfa - target->args_size;
}

static inline _Unwind_Ptr
--
Dr. Ulrich Weigand
***@informatik.uni-erlangen.de
Richard Henderson
2003-05-07 01:25:08 UTC
Permalink
... which is completely ignored on s390 anyway (as SP is
restored from its stack slot, where the correct new
value was already stored by uw_install_context_1).
Ah, now I get it. This was the piece I couldn't understand.
And if *this* is the case, it means that it doesn't matter
where you place the CFA relative to the stack frame, just so
long as the stack pointer itself is computed properly.
What do you think?
* unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
previous frame didn't save sp. Clear sp for next frame.
(uw_install_context_1): Honor saved sp from frame.
If this works, great.


r~
Mark Mitchell
2003-05-07 05:53:28 UTC
Permalink
Post by Richard Henderson
Post by Ulrich Weigand
What do you think?
* unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
previous frame didn't save sp. Clear sp for next frame.
(uw_install_context_1): Honor saved sp from frame.
If this works, great.
Ulrich --

Take that as approval from Richard; if it fixes your problem, please
check it in and close the PR.

Thanks,
--
Mark Mitchell <***@codesourcery.com>
CodeSourcery, LLC
Ulrich Weigand
1970-01-01 00:00:00 UTC
Permalink
Post by Richard Henderson
Ah, now I get it. This was the piece I couldn't understand.
And if *this* is the case, it means that it doesn't matter
where you place the CFA relative to the stack frame, just so
long as the stack pointer itself is computed properly.
This is what I was thinking, yes.
Post by Richard Henderson
Post by Ulrich Weigand
* unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
previous frame didn't save sp. Clear sp for next frame.
(uw_install_context_1): Honor saved sp from frame.
If this works, great.
Unfortunately, while it fixes most of the problems, it is not a
complete solution:
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00418.html
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00419.html

The Java test case PR218 is still failing. This is because
this test case throws an exception from a signal handler
through a *leaf* function that was interrupted by the
signal.

When unwinding through the leaf function, there is no CFA code
to restore the stack pointer, because the *correct* behaviour
would have been to reuse the stack pointer from the frame below
(the signal return stub frame) unchanged -- the leaf function
really did not allocate any stack space.

However, this now triggers again the new code that sets the
stack pointer to the cfa, incorrect on s390.

Would you suggest to check the above patch in anyway to make 3.3
more similar to head (apparently the patch is already in 3.2 ...),
and because it fixes at least C++?

Or should we go back to a RUNTIME_SP_CFA_OFFSET solution
on top of the current 3.3 implementation?

What about an alternate target macro that says that this target
handles SP by itself via FDE records, and doesn't need any
other SP fiddling? This would then allow us to remove the
unnecessary EH_RETURN_STACKADJ_RTX handling completely.
Maybe this behaviour could actually be triggered by the target
leaving EH_RETURN_STACKADJ_RTX undefined?

If no other solution works for 3.3, we could always fix it
ad-hoc with #ifdef __s390__ ...

Bye,
Ulrich
--
Dr. Ulrich Weigand
***@informatik.uni-erlangen.de
Mark Mitchell
2003-05-07 15:53:40 UTC
Permalink
Post by Ulrich Weigand
Unfortunately, while it fixes most of the problems, it is not a
Bummer.
Post by Ulrich Weigand
Would you suggest to check the above patch in anyway to make 3.3
more similar to head (apparently the patch is already in 3.2 ...),
and because it fixes at least C++?
No, that doesn't seem worth it.
Post by Ulrich Weigand
Or should we go back to a RUNTIME_SP_CFA_OFFSET solution
on top of the current 3.3 implementation?
That seems fine, if it will work. The key criteria are:

(1) You can do it in such a way that it's obvious it doesn't affect
other platforms.

(2) You can do it quickly.

Engineering beauty is not a consideration at all, in this case.

#ifdef __s390__ is fine, for example; if you can just do

#ifdef __s390__
cfa += 196;
#endif

that is absolutely fine by me.

If we can't meet those criteria, we may be forced to punt; s390 is not a
primary evaluation platform.

Please see if you can get this fixed in the next twenty-four hours or
so.

Thanks,
--
Mark Mitchell <***@codesourcery.com>
CodeSourcery, LLC
Joe Buck
2003-05-07 16:01:13 UTC
Permalink
Post by Mark Mitchell
Engineering beauty is not a consideration at all, in this case.
#ifdef __s390__ is fine, for example; if you can just do
#ifdef __s390__
cfa += 196;
#endif
that is absolutely fine by me.
If we go for such a solution, I think that it should be a one-release-only
emergency fix, to be replaced ASAP with a better one; seas of #ifdef's
tend to grow if not whacked back.
Mark Mitchell
2003-05-07 16:13:24 UTC
Permalink
Post by Joe Buck
Post by Mark Mitchell
Engineering beauty is not a consideration at all, in this case.
#ifdef __s390__ is fine, for example; if you can just do
#ifdef __s390__
cfa += 196;
#endif
that is absolutely fine by me.
If we go for such a solution, I think that it should be a one-release-only
emergency fix, to be replaced ASAP with a better one; seas of #ifdef's
tend to grow if not whacked back.
There's no way something like this will go on the mainline.

If we had to live with this through the 3.3 series, that would be OK;
that is bounded.
--
Mark Mitchell <***@codesourcery.com>
CodeSourcery, LLC
Ulrich Weigand
1970-01-01 00:00:00 UTC
Permalink
Post by Mark Mitchell
(1) You can do it in such a way that it's obvious it doesn't affect
other platforms.
(2) You can do it quickly.
Engineering beauty is not a consideration at all, in this case.
I can offer the following patch, which passes bootstrap/regtest
on s390-ibm-linux and s390x-ibm-linux and restores both targets
to their previous behaviour in all cases, including that Java
leaf-function test case. See:
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00428.html
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00429.html


It should be obvious that it does not affect other platforms;
the hunk in uw_update_context_1 is under #ifdef, and the hunk
in uw_init_context_1 does not affect non-s390 platforms because
for them uw_update_context_1 will immediately undo that change
(never mind that even if it didn't, the change would in fact
be correct for other platforms as well).

I will continue to work on a cleaner solution, but I cannot
guarantee that this will succeed within 24 hours (and I'd
also like to ask for Richard's opinion).

Do you think we should use the patch below for 3.3?

Bye,
Ulrich


PR other/10650
* unwind-dw2.c (uw_update_context_1): Don't set sp as cfa on s390.
(uw_init_context_1): Set initial sp to outer cfa.

Index: gcc/unwind-dw2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/unwind-dw2.c,v
retrieving revision 1.22.2.4
diff -c -p -r1.22.2.4 unwind-dw2.c
*** gcc/unwind-dw2.c 5 May 2003 16:59:21 -0000 1.22.2.4
--- gcc/unwind-dw2.c 7 May 2003 14:54:10 -0000
*************** uw_update_context_1 (struct _Unwind_Cont
*** 1062,1069 ****
--- 1062,1071 ----
Given that other unwind mechanisms generally won't work if you try
to represent stack pointer saves and restores directly, we don't
bother conditionalizing this at all. */
+ #ifndef __s390__
tmp_sp = (_Unwind_Ptr) context->cfa;
orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
+ #endif

/* Compute this frame's CFA. */
switch (fs->cfa_how)
*************** uw_init_context_1 (struct _Unwind_Contex
*** 1164,1169 ****
--- 1166,1172 ----

/* Force the frame state to use the known cfa value. */
context->cfa = outer_cfa;
+ context->reg[__builtin_dwarf_sp_column ()] = &outer_cfa;
fs.cfa_how = CFA_REG_OFFSET;
fs.cfa_reg = __builtin_dwarf_sp_column ();
fs.cfa_offset = 0;
--
Dr. Ulrich Weigand
***@informatik.uni-erlangen.de
Mark Mitchell
2003-05-07 17:11:46 UTC
Permalink
Post by Ulrich Weigand
I will continue to work on a cleaner solution, but I cannot
guarantee that this will succeed within 24 hours (and I'd
also like to ask for Richard's opinion).
Do you think we should use the patch below for 3.3?
Yes -- but please enclose the second hunk in #ifdef as well. If we're
going to be ugly, let's not try to be smart while we're being ugly.

Please check this in, and close the PR.

Thanks,
--
Mark Mitchell <***@codesourcery.com>
CodeSourcery, LLC
Ulrich Weigand
1970-01-01 00:00:00 UTC
Permalink
Post by Mark Mitchell
Yes -- but please enclose the second hunk in #ifdef as well. If we're
going to be ugly, let's not try to be smart while we're being ugly.
Fine with me.
Post by Mark Mitchell
Please check this in, and close the PR.
For the record, I've checked in the patch below and closed the PR.

Bye,
Ulrich


Index: gcc/ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
retrieving revision 1.16114.2.511
diff -c -p -r1.16114.2.511 ChangeLog
*** gcc/ChangeLog 7 May 2003 06:02:01 -0000 1.16114.2.511
--- gcc/ChangeLog 7 May 2003 19:26:21 -0000
***************
*** 1,3 ****
--- 1,9 ----
+ 2003-05-06 Ulrich Weigand <***@de.ibm.com>
+
+ PR other/10650
+ * unwind-dw2.c (uw_update_context_1): Don't set sp as cfa on s390.
+ (uw_init_context_1): Set initial sp to outer cfa on s390.
+
2003-05-06 Mark Mitchell <***@codesourcery.com>

PR other/10658
Index: gcc/unwind-dw2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/unwind-dw2.c,v
retrieving revision 1.22.2.4
diff -c -p -r1.22.2.4 unwind-dw2.c
*** gcc/unwind-dw2.c 5 May 2003 16:59:21 -0000 1.22.2.4
--- gcc/unwind-dw2.c 7 May 2003 19:26:21 -0000
*************** uw_update_context_1 (struct _Unwind_Cont
*** 1062,1069 ****
--- 1062,1071 ----
Given that other unwind mechanisms generally won't work if you try
to represent stack pointer saves and restores directly, we don't
bother conditionalizing this at all. */
+ #ifndef __s390__
tmp_sp = (_Unwind_Ptr) context->cfa;
orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
+ #endif

/* Compute this frame's CFA. */
switch (fs->cfa_how)
*************** uw_init_context_1 (struct _Unwind_Contex
*** 1164,1169 ****
--- 1166,1174 ----

/* Force the frame state to use the known cfa value. */
context->cfa = outer_cfa;
+ #ifdef __s390__
+ context->reg[__builtin_dwarf_sp_column ()] = &outer_cfa;
+ #endif
fs.cfa_how = CFA_REG_OFFSET;
fs.cfa_reg = __builtin_dwarf_sp_column ();
fs.cfa_offset = 0;
--
Dr. Ulrich Weigand
***@informatik.uni-erlangen.de
Mark Mitchell
2003-05-07 19:45:47 UTC
Permalink
Post by Ulrich Weigand
Post by Mark Mitchell
Yes -- but please enclose the second hunk in #ifdef as well. If we're
going to be ugly, let's not try to be smart while we're being ugly.
Fine with me.
Post by Mark Mitchell
Please check this in, and close the PR.
For the record, I've checked in the patch below and closed the PR.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
Joe Buck
2003-05-07 17:07:30 UTC
Permalink
Post by Ulrich Weigand
It should be obvious that it does not affect other platforms;
the hunk in uw_update_context_1 is under #ifdef, and the hunk
in uw_init_context_1 does not affect non-s390 platforms because
for them uw_update_context_1 will immediately undo that change
(never mind that even if it didn't, the change would in fact
be correct for other platforms as well).
Given the very short time remaining for testing, if you're ifdef'ing
one hunk, you might as well ifdef them both. The patch would then
have zero risk for other platforms.
Jonathan Lennox
2003-05-07 18:19:10 UTC
Permalink
Post by Ulrich Weigand
+ #ifndef __s390__
tmp_sp = (_Unwind_Ptr) context->cfa;
orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
+ #endif
Doesn't __s390__ indicate the build system, not the target?
--
Jonathan Lennox
***@cs.columbia.edu
Mark Mitchell
2003-05-07 18:27:47 UTC
Permalink
Post by Jonathan Lennox
Post by Ulrich Weigand
+ #ifndef __s390__
tmp_sp = (_Unwind_Ptr) context->cfa;
orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
+ #endif
Doesn't __s390__ indicate the build system, not the target?
Yes, but this code is built with the new GCC, so I think that will work
our correctly.
--
Mark Mitchell <***@codesourcery.com>
CodeSourcery, LLC
Jonathan Lennox
2003-05-07 18:30:23 UTC
Permalink
Post by Mark Mitchell
Post by Jonathan Lennox
Doesn't __s390__ indicate the build system, not the target?
Yes, but this code is built with the new GCC, so I think that will work
our correctly.
What about cross-compilers to s390, or built on it?

("They don't work" is a fine answer.)
--
Jonathan Lennox
***@cs.columbia.edu
Mark Mitchell
2003-05-07 18:36:15 UTC
Permalink
Post by Jonathan Lennox
Post by Mark Mitchell
Post by Jonathan Lennox
Doesn't __s390__ indicate the build system, not the target?
Yes, but this code is built with the new GCC, so I think that will work
our correctly.
What about cross-compilers to s390, or built on it?
They will set __s390__ if they are cross compilers to __s390__, and will
not set it if they are not, so all will be well.

And, in fact, even were this broken it would not be too bad -- it's not
like s390 is one of our most-used platforms. The goal here is to get a
minimally intrusive patch that makes it possible for s390 people to use
GCC 3.3.
--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
Daniel Jacobowitz
2003-05-07 18:44:53 UTC
Permalink
Post by Jonathan Lennox
Post by Mark Mitchell
Post by Jonathan Lennox
Doesn't __s390__ indicate the build system, not the target?
Yes, but this code is built with the new GCC, so I think that will work
our correctly.
What about cross-compilers to s390, or built on it?
("They don't work" is a fine answer.)
This code is built for the target, not for the build machine. Checking
__s390__ should be correct. (It's part of libgcc)
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Richard Henderson
2003-05-07 17:48:31 UTC
Permalink
Post by Ulrich Weigand
However, this now triggers again the new code that sets the
stack pointer to the cfa, incorrect on s390.
If I understand correctly, then this would be fixed by

+ #ifndef __s390__
_Unwind_SetGRPtr (context, __builtin_dwarf_sp_column (), NULL);
+ #endif

correct?
Post by Ulrich Weigand
Would you suggest to check the above patch in anyway to make 3.3
more similar to head (apparently the patch is already in 3.2 ...),
and because it fixes at least C++?
Well, not to make it more similar to head, but because it gets
more cases demonstrably correct. On s390 and elsewhere.


r~
Ulrich Weigand
1970-01-01 00:00:00 UTC
Permalink
Post by Richard Henderson
If I understand correctly, then this would be fixed by
+ #ifndef __s390__
_Unwind_SetGRPtr (context, __builtin_dwarf_sp_column (), NULL);
+ #endif
correct?
Basically yes, except that then the initial cfa is no longer
found when called from uw_init_context_1. This is fixed by the
second hunk of the patch I just committed ...
Post by Richard Henderson
Post by Ulrich Weigand
Would you suggest to check the above patch in anyway to make 3.3
more similar to head (apparently the patch is already in 3.2 ...),
and because it fixes at least C++?
Well, not to make it more similar to head, but because it gets
more cases demonstrably correct. On s390 and elsewhere.
We should certainly fix it properly on the head and for 3.3.1.
Whether this is something for 3.3 I have no strong opinion on
-- that's Mark's call ...

Bye,
Ulrich
--
Dr. Ulrich Weigand
***@informatik.uni-erlangen.de
Mark Mitchell
2003-05-07 19:46:29 UTC
Permalink
Post by Ulrich Weigand
We should certainly fix it properly on the head and for 3.3.1.
Whether this is something for 3.3 I have no strong opinion on
-- that's Mark's call ...
For 3.3, we certainly don't want anything we don't absolutely need.

Thanks,
--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
John David Anglin
2003-07-05 16:56:45 UTC
Permalink
stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -gstabs -O2 -DIN
_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedant
ic -Wno-long-long -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I.
-I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../
include -I../intl ../../gcc/gcc/genautomata.c -o genautomata.o
../../gcc/gcc/genautomata.c:4463: error: head insn 90 for block 0 not found in t
he insn stream
../../gcc/gcc/genautomata.c:4463: internal compiler error: Segmentation fault
Zdenek's patch

http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00457.html

fixed the above failure. However, there are still a bunch of new segmentation
faults in the testsuite. For example,

Executing on host: /home/dave/gcc-3.4/objdir/gcc/xgcc -B/home/dave/gcc-3.4/objdi
r/gcc/ -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -w -c
-o 20000728-1.o /home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000
728-1.c (timeout = 300)
/home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000728-1.c: In func
tion `foo':
/home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000728-1.c:15: inte
rnal compiler error: Segmentation fault

The stack backtrace is:

#0 0x000ec654 in verify_dominators (dom=0x486f58)
at ../../gcc/gcc/dominance.c:695
#1 0x002f4bcc in unroll_and_peel_loops (loops=0x486e48, flags=4739680)
at ../../gcc/gcc/loop-unroll.c:145
#2 0x0029b614 in rest_of_handle_loop2 (decl=0x486e48, insns=0x401d1ba0)
at ../../gcc/gcc/toplev.c:3303
#3 0x0029bda4 in rest_of_compilation (decl=0x401d0a80)
at ../../gcc/gcc/toplev.c:3576
#4 0x0003e438 in c_expand_body_1 (fndecl=0x401d0a80, nested_p=0)
at ../../gcc/gcc/c-decl.c:6379
#5 0x002d4500 in cgraph_expand_function (node=0x40017340)
at ../../gcc/gcc/cgraphunit.c:282
#6 0x002d46c8 in cgraph_expand_functions () at ../../gcc/gcc/cgraphunit.c:372
#7 0x002d49d0 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:462
#8 0x0007dfe0 in c_objc_common_finish_file ()
at ../../gcc/gcc/c-objc-common.c:363
#9 0x00019d3c in yyparse () at c-parse.y:339
#10 0x0006f398 in c_common_parse_file (set_yydebug=4732136)
at ../../gcc/gcc/c-opts.c:1188
#11 0x00298e20 in compile_file () at ../../gcc/gcc/toplev.c:2069
#12 0x0029e3d0 in do_compile () at ../../gcc/gcc/toplev.c:4959
#13 0x0029e44c in toplev_main (argc=18, argv=0xfaf005b0)
at ../../gcc/gcc/toplev.c:4990

It appears dom_bb is 0x0.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
John David Anglin
2003-10-08 03:11:07 UTC
Permalink
There are also a bunch of testsuite regressions on hppa64-hp-hpux11.11.
See <http://gcc.gnu.org/ml/gcc-testresults/2003-10/msg00324.html>.

The gcc.log has messages similar to the following for the new regressions:

/xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/compat/scalar-by-value-1_x.c:154: inte
rnal compiler error: in copy_rtx, at rtl.c:377
Please submit a full bug report,

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Eric Christopher
2003-10-08 07:25:48 UTC
Permalink
Post by John David Anglin
There are also a bunch of testsuite regressions on hppa64-hp-hpux11.11.
See <http://gcc.gnu.org/ml/gcc-testresults/2003-10/msg00324.html>.
/xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/compat/scalar-by-value-1_x.c:154: inte
rnal compiler error: in copy_rtx, at rtl.c:377
Please submit a full bug report,
I'm seeing this on frv too. I blame Zack (at least in the little bit of
looking I did...), but that's ok. I'm sure he'll fix it.

-eric
--
Eric Christopher <***@redhat.com>
John David Anglin
2003-10-08 17:26:26 UTC
Permalink
Post by Eric Christopher
I'm seeing this on frv too. I blame Zack (at least in the little bit of
looking I did...), but that's ok. I'm sure he'll fix it.
Yes, it looks as if this is caused by one of Zack's recent changes.
We have:

#0 0x400000000035ee3c in copy_rtx (orig=0x0) at ../../gcc/gcc/rtl.c:377
#1 0x40000000002f869c in emit_libcall_block (insns=0x800003fffed1f550,
target=0x800003fffed20600, result=0x800003fffed1f2d0, equiv=0x0)
at ../../gcc/gcc/optabs.c:3397
#2 0x40000000002f9430 in emit_cmp_and_jump_insns (x=0x800003fffed3bfa0,
y=0x800003fffeff2768, comparison=NE, size=0x72, mode=TFmode, unsignedp=0,
label=0x800003fffed3bf50) at ../../gcc/gcc/optabs.c:3946

emit_libcall_block is called with equiv=0 when optimize is 0. We end
up trying to copy a NULL_RTX at optabs.c:3397.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Roger Sayle
2003-10-09 02:23:28 UTC
Permalink
Hi David and Eric,
Post by John David Anglin
Post by Eric Christopher
I'm seeing this on frv too. I blame Zack (at least in the little
bit of looking I did...), but that's ok. I'm sure he'll fix it.
Yes, it looks as if this is caused by one of Zack's recent changes.
Mea culpa. Zack is completely innocent, the testsuite regressions
are my fault. Zack asked that I modify my patch to optabs.c's
prepare_float_lib_cmp to call emit_libcall_block directly, but I
screwed up the reorganization, not realizing that "equiv" mustn't
be a NULL_RTX, otherwise very bad things happen...

I've already posted a fix at:
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00635.html
Hopefully, it will be reviewed in the very near future.

The problem shouldn't affect bootstrap as it only shows up with
-O0 when using software floating point, but it is likely to be
the cause of FRV's/HPPA64's regressions.

Sorry again for any inconvenience. The problem doesn't show up
on x86, and even the -msoft-float tests are never run at -O0,
so it wasn't found during my retesting. The original patch to
prepare_float_lib_cmp was more widely tested without any problems,
but I underestimated the "obvious" tidy-up.

Roger
--
John David Anglin
2004-01-06 00:43:14 UTC
Permalink
So how, precisely is config.cache "not found"? Is it deleted between line
489 and line 491? Or is your shell busted?
The PATH environment variable isn't set correctly.
Possibly, I should add that /bin/sh under hpux 11 is the POSIX shell
and supposedly conforms to the POSIX standards in effect at the time
hpux 11 was introduced. This means that the source command doesn't
search the current directory. If I add `.' to PATH, then config.cache
is found.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
John David Anglin
2007-04-15 16:35:44 UTC
Permalink
* hppa64-hp-hpux11.11: many failures
Most of these are "Type/rank mismatch in argument":

FAIL: gfortran.dg/assumed_charlen_function_5.f90 -O (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:22: E
rror: Type/rank mismatch in argument 'charr' at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:23: E
rror: Type/rank mismatch in argument 'charr' at (1)

In gfortran.dg/entry_1.f90:

Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:15: Error: Type/rank mis
match in argument 'p' at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:16: Error: Type/rank mis
match in argument 'p' at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:40: Fatal Error: Can't o
pen module file 'm.mod' for reading at (1): No such file or directory

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Loading...