Bug#1066052: gcc-13: several acats tests raise ADA.CALENDAR.TIME_ERROR : a-calend.adb:601

[John David Anglin]

Source: gcc-12
Version: 12.3.0-15
Severity: normal

Dear Maintainer,

In test log, I see a number of tests with following error:

splitting /build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/test
s/a/a26007a.adt into:
   a26007a.adb
BUILD a26007a.adb
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatmake 
--GNATBIND=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatbind 
--GNATLINK=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatlink 
--GCC=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/ -gnatws -O2 -gnat95 
-I/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/../acats/support
 a26007a.adb -largs --GCC=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc -c 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/ -gnatws -O2 -gnat95 
-I/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/../acats/support
 a26007a.adb
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatbind 
-I/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/../acats/support
 -x a26007a.ali
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatlink a26007a.ali -O2 
--GCC=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/
RUN a26007a


raised ADA.CALENDAR.TIME_ERROR : a-calend.adb:601
FAIL:   a26007a

Regards,
Dave Anglin


-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.80+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#1057244: hppa: All tests fail - /bin/stty: 'standard input': unable to perform all requested operations

[John David Anglin]

Source: gcc-snapshot
Version: 1:20231130-1
Severity: normal

Dear Maintainer,

This is with qemu.  All tests fail.  For example,
Executing on host: /build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/xg
cc -B/build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/  /build/gcc-sna
pshot-qyFUuB/gcc-snapshot-20231130/src/gcc/testsuite/gcc.c-torture/execute/ieee/
pr29302-1.c-fdiagnostics-plain-output  -w  -O2  -fno-inline  -lm  -o 
/build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/testsuite/gcc/pr29302-1.x2
(timeout = 300)
spawn -ignore SIGHUP 
/build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/xgcc 
-B/build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/ 
/build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/src/gcc/testsuite/gcc.c-torture/execute/ieee/pr29302-1.c
 -fdiagnostics-plain-output -w -O2 -fno-inline -lm -o 
/build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/testsuite/gcc/pr29302-1.x2
/bin/stty: 'standard input': unable to perform all requested operations
FAIL: gcc.c-torture/execute/ieee/pr29302-1.c compilation,  -O2
UNRESOLVED: gcc.c-torture/execute/ieee/pr29302-1.c execution,  -O2

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.64+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1033130: Info received (gcc-snapshot: FTBFS on hppa - sys/mman.h: No such file or directory)

[John David Anglin]

On 2023-10-12 2:09 a.m., Matthias Klose wrote:

On 07.10.23 21:43, John David Anglin wrote:

This problem seems to have disappeared. Last build of gcc-13 and last couple of 
builds of gcc-snapshot
have been successful.


yes, that because of a local patch:

https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/hppa64-libgcov-fallback.diff

Thanks for adding the patch.

Technically, |_PA_RISC2_0 is not specific to hppa64. You also need __LP64__. 
But as long as the 32-bit
compiler is not built with a PA 2.0 option, _PA_RISC2_0 will work.

So,there's still an issue with the include directories for builds done using 
buildd. As I mentioned
previously, the error doesn't occur for builds done outside buildd using 
dpkg-buildpackage.
|

--
John David Anglin  dave.ang...@bell.net

Bug#1033130: Info received (gcc-snapshot: FTBFS on hppa - sys/mman.h: No such file or directory)

[John David Anglin]

This problem seems to have disappeared.  Last build of gcc-13 and last couple 
of builds of gcc-snapshot
have been successful.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1033130: gcc-snapshot: FTBFS on hppa - sys/mman.h: No such file or directory

[John David Anglin]

On 2023-06-14 2:31 p.m., John David Anglin wrote:

On 2023-06-14 1:00 p.m., Matthias Klose wrote:

wondering if configuring with --disable-libgcc would help?

I don't need to do this when building the hppa64 gcc target by itself.

Linux may need libgcc.


I think configure must be finding the header in 
/usr/include/hppa-linux-gnu/sys/mman.h.
We don't have any headers for hppa64 installed at this time.

Something seems to have changed in the build mechanism between gcc-12 and 
gcc-13.

I have a debian non-buildd build of gcc-13 going.  Maybe it will help to find 
issue.

Build was successful using dpkg-buildpackage outside chroot.

--
John David Anglin  dave.ang...@bell.net

Bug#1033130: gcc-snapshot: FTBFS on hppa - sys/mman.h: No such file or directory

[John David Anglin]

On 2023-06-14 1:00 p.m., Matthias Klose wrote:

wondering if configuring with --disable-libgcc would help?

I don't need to do this when building the hppa64 gcc target by itself.

I think configure must be finding the header in 
/usr/include/hppa-linux-gnu/sys/mman.h.
We don't have any headers for hppa64 installed at this time.

Something seems to have changed in the build mechanism between gcc-12 and 
gcc-13.

I have a debian non-buildd build of gcc-13 going.  Maybe it will help to find 
issue.

--
John David Anglin  dave.ang...@bell.net

Bug#1033130: gcc-snapshot: FTBFS on hppa - sys/mman.h: No such file or directory

[John David Anglin]

Source: gcc-snapshot
Version: 1:20230315-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

Build fails with following error:
/<>/build-hppa64/./gcc/xgcc -B/<>/build-hppa64/./gcc/ 
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/bin/ 
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/lib/ -isystem 
/usr/lib/gcc-snapshot/hppa64-linux-gnu/include -isystem 
/usr/lib/gcc-snapshot/hppa64-linux-gnu/sys-include-g -O2 -O2  -g -O2 
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include  -fPIC -Dpa64=1 -DELF=1 -DLINUX=1 -g -DIN_LIBGCC2 
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC -Dpa64=1 -DELF=1 
-DLINUX=1 -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. 
-I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -o 
_gcov_merge_add.o -MT _gcov_merge_add.o -MD -MP -MF _gcov_merge_add.dep 
-DL_gcov_merge_add -c ../../../src/libgcc/libgcov-merge.c
In file included from ../../../src/libgcc/libgcov-merge.c:26:
../../../src/libgcc/libgcov.h:49:10: fatal error: sys/mman.h: No such file or 
directory
   49 | #include 
  |  ^~~~
compilation terminated.
make[4]: *** [Makefile:924: _gcov_merge_add.o] Error 1

We have in libgcov.h:

#if HAVE_SYS_MMAN_H
#include 
#endif

Either configure is broken or there is a problem with the include paths:

checking for sys/auxv.h... yes
checking for sys/mman.h... yes

Regards,
Dave Anglin

-- System Information:
Debian Release: 12.0
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.20+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1024492: Acknowledgement (libffi: large structs need to be passed by value on hppa)

[John David Anglin]

Hi,

There are two additional updates for libffi on hppa. See:
https://github.com/libffi/libffi/issues/755
https://github.com/libffi/libffi/issues/756

The current installed version (+b2) has the patches for the above issues.

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net

Bug#1024492: libffi: large structs need to be passed by value on hppa

[John David Anglin]

Source: libffi
Version: 3.2.1-9
Severity: normal
Tags: patch

Dear Maintainer,

The following tests fail on hppa:
=== libffi tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../testsuite/config/default.exp as tool-and-target-specific interface 
file.
Running ../../testsuite/libffi.bhaible/bhaible.exp ...
Running ../../testsuite/libffi.call/call.exp ...
FAIL: libffi.call/struct_by_value_3.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct_by_value_3.c -W -Wall -Wno-psabi -O2 execution test
FAIL: libffi.call/struct_by_value_4.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct_by_value_4.c -W -Wall -Wno-psabi -O2 execution test
FAIL: libffi.call/struct_by_value_big.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct_by_value_big.c -W -Wall -Wno-psabi -O2 execution test
Running ../../testsuite/libffi.closures/closure.exp ...
Running ../../testsuite/libffi.complex/complex.exp ...
Running ../../testsuite/libffi.go/go.exp ...

=== libffi Summary ===

# of expected passes1482
# of unexpected failures6
# of unsupported tests  30
make[3]: *** [Makefile:466: check-DEJAGNU] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=hppa&ver=3.4.4-1&stamp=106326&raw=0

This is upstream issue #749:
https://github.com/libffi/libffi/issues/749

Attached is patch to fix the problem on hppa. It is similar to patch
applied to fix issue on sparc64.

Please apply until issue is fixed in upstream source.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.0.9 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/src/pa/ffi.c b/src/pa/ffi.c
index 95e6694..186bf69 100644
--- a/src/pa/ffi.c
+++ b/src/pa/ffi.c
@@ -376,10 +376,26 @@ extern void ffi_call_pa32(void (*)(UINT32 *, extended_cif 
*, unsigned),
 void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue, void **avalue)
 {
   extended_cif ecif;
+  size_t i, nargs = cif->nargs;
+  ffi_type **arg_types = cif->arg_types;
 
   ecif.cif = cif;
   ecif.avalue = avalue;
 
+  /* If we have any large structure arguments, make a copy so we are passing
+ by value.  */
+  for (i = 0; i < nargs; i++)
+{
+  ffi_type *at = arg_types[i];
+  int size = at->size;
+  if (at->type == FFI_TYPE_STRUCT && size > 8)
+   {
+ char *argcopy = alloca (size);
+ memcpy (argcopy, avalue[i], size);
+ avalue[i] = argcopy;
+   }
+}
+
   /* If the return value is a struct and we don't have a return
  value address then we need to make one.  */
 

Bug#1014098: gcc-12 ftbfs on hppa

[John David Anglin]

This bug is not a gcc-12 bug.  It is a kernel cache flush or mmap aliasing 
issue causing corruption
of anonymous pages.

Bug is random and only seen on PA8800/PA8900 machines.

Latest gcc-12 package is now installed.

--
John David Anglin  dave.ang...@bell.net

Bug#996643: gcc-11: FTBFS on hppa - Bootstrap comparison failure!

[John David Anglin]

Source: gcc-11
Version: 11.2.0-9
Severity: normal

Dear Maintainer,

Build fails here:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/m2/gm2-compiler-boot/M2Version.o differs
Bootstrap comparison failure!
gcc/SYSTEM.o differs

SYSTEM.o is probably a m2 file.  Not sure why it's in gcc directory.
It seems to be excluded when its in gcc/m2/gm2-compiler-boot:

# DP: ignore gm2version.o stage diff on some archtectures (m68k, riscv64)

--- a/src/configure.ac
+++ b/src/configure.ac
@@ -3678,6 +3678,7 @@ AC_SUBST(stage2_werror_flag)
 compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*"
 compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/M2Version*"
 compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/SYSTEM*"
+compare_exclusions="$compare_exclusions | *m2/gm2version\$(objext)"

Regards,
Dave

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.14.10+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#943796: gcc-9: FTBFS on hppa - ld cannot find -latomic

[John David Anglin]

Source: gcc-9
Version: 9.2.1-15
Severity: normal

Dear Maintainer,

The build failed with the following error:

make[6]: Entering directory '/<>/build/hppa-linux-gnu/libgnatvsn'
/bin/mkdir -p '/<>/debian/tmp/usr/lib/ada/adalib/gnatvsn'
/usr/bin/install -c -m 444 .libs/*.ali 
'/<>/debian/tmp/usr/lib/ada/adalib/gnatvsn'
 /bin/mkdir -p '/<>/debian/tmp/usr/lib'
 /bin/bash ./libtool   --mode=install /usr/bin/install -c   libgnatvsn.la 
'/<>/debian/tmp/usr/lib'
libtool: install: warning: relinking `libgnatvsn.la'
libtool: install: (cd /<>/build/hppa-linux-gnu/libgnatvsn; 
/bin/bash /<>/build/hppa-linux-gnu/libgnatvsn/libtool  --tag CC 
--mode=relink /<>/build/./gcc/xgcc -B/<>/build/./gcc/ 
-B/usr/hppa-linux-gnu/bin/ -B/usr/hppa-linux-gnu/lib/ -isystem 
/usr/hppa-linux-gnu/include -isystem /usr/hppa-linux-gnu/sys-include -isystem 
/<>/build/sys-include -fchecking=1 -mdisable-indexing -g -O2 
-version-info 9 -Wl,--no-allow-shlib-undefined -Wl,--no-copy-dt-needed-entries 
-Wl,--no-undefined -Wl,-z,relro -o libgnatvsn.la -rpath /usr/lib 
libgnatvsn_la-link.lo libgnatvsn_la-version.lo -L../libada/adalib -lgnat-9 
aspects.lo atree.lo binderr.lo butil.lo casing.lo csets.lo debug.lo einfo.lo 
elists.lo fname.lo get_scos.lo gnatvsn.lo krunch.lo lib.lo namet.lo nlists.lo 
opt.lo output.lo put_scos.lo repinfo.lo repinfo-input.lo scans.lo scos.lo 
sem_aux.lo sinfo.lo sinput.lo sinput-c.lo stand.lo stringt.lo table.lo 
tempdir.lo tree_in.lo tree_io.lo types.lo uintp.lo uname.lo urealp.lo 
widechar.lo xutil.lo snames.lo alloc.lo hostparm.lo rident.lo 
.././libatomic/libatomic.la -inst-prefix-dir /<>/debian/tmp)
libtool: relink: /<>/build/./gcc/xgcc 
-B/<>/build/./gcc/ -B/usr/hppa-linux-gnu/bin/ 
-B/usr/hppa-linux-gnu/lib/ -isystem /usr/hppa-linux-gnu/include -isystem 
/usr/hppa-linux-gnu/sys-include -isystem /<>/build/sys-include   
-fchecking=1 -shared  -fPIC -DPIC  .libs/libgnatvsn_la-link.o 
.libs/libgnatvsn_la-version.o .libs/aspects.o .libs/atree.o .libs/binderr.o 
.libs/butil.o .libs/casing.o .libs/csets.o .libs/debug.o .libs/einfo.o 
.libs/elists.o .libs/fname.o .libs/get_scos.o .libs/gnatvsn.o .libs/krunch.o 
.libs/lib.o .libs/namet.o .libs/nlists.o .libs/opt.o .libs/output.o 
.libs/put_scos.o .libs/repinfo.o .libs/repinfo-input.o .libs/scans.o 
.libs/scos.o .libs/sem_aux.o .libs/sinfo.o .libs/sinput.o .libs/sinput-c.o 
.libs/stand.o .libs/stringt.o .libs/table.o .libs/tempdir.o .libs/tree_in.o 
.libs/tree_io.o .libs/types.o .libs/uintp.o .libs/uname.o .libs/urealp.o 
.libs/widechar.o .libs/xutil.o .libs/snames.o .libs/alloc.o .libs/hostparm.o 
.libs/rident.o   -L/<>/build/hppa-linux-gnu/libada/adalib -lgnat-9 
-L/<>/debian/tmp/usr/lib -L/usr/lib -latomic  -mdisable-indexing 
-Wl,--no-allow-shlib-undefined -Wl,--no-copy-dt-needed-entries 
-Wl,--no-undefined -Wl,-z -Wl,relro   -pthread -Wl,-soname -Wl,libgnatvsn.so.9 
-o .libs/libgnatvsn.so.9.0.0
/usr/bin/hppa-linux-gnu-ld: cannot find -latomic
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libgnatvsn.la' with the above command before 
installing it
make[6]: *** [Makefile:552: install-libLTLIBRARIES] Error 1

The hppa architecture has a non empty libatomic that needs to be linked
against for atomic support.

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=gcc-9&arch=hppa&ver=9.2.1-15&stamp=1572353329&raw=0

Regards,
Dave Anglin


-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.150+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#935750: libgcc-9-dev: The futex facility returned an unexpected error code

[John David Anglin]

Package: libgcc-9-dev
Version: 9.2.1-4
Severity: normal

Dear Maintainer,

The following error occurs running "test-z3 -a" while building the z3 package:
PASS
(test hashtable :time 0.00 :before-memory 2630.62 :after-memory 2630.62)
The futex facility returned an unexpected error code.
make[1]: *** [debian/rules:130: override_dh_auto_test] Aborted
make[1]: Leaving directory '/<>'
make: *** [debian/rules:24: build-arch] Error 2

We have the following backtrace:
Breakpoint 3, futex_fatal_error () at ../sysdeps/nptl/futex-internal.h:200
200 ../sysdeps/nptl/futex-internal.h: No such file or directory.
(gdb) bt
#0  futex_fatal_error () at ../sysdeps/nptl/futex-internal.h:200
#1  futex_abstimed_wait_cancelable (private=1, abstime=0x0, expected=1,
futex_word=)
at ../sysdeps/unix/sysv/linux/futex-internal.h:223
#2  do_futex_wait (sem=, abstime=0x0) at sem_waitcommon.c:115
#3  0xf88048f4 in __new_sem_wait_slow (sem=0x1, abstime=0x0)
at sem_waitcommon.c:282
#4  0xf78c4fe4 in omp_set_nest_lock ()
   from /usr/lib/hppa-linux-gnu/libgomp.so.1
#5  0x0152b658 in mpn_manager::div (this=0x1b7f6ac, numer=0x1b7f96c, lnum=4,
denom=0x1b7f8cc, lden=1, quot=0x1b7f94c, rem=0x1b7f8ac)
at ../src/util/mpn.cpp:156
#6  0x01553da4 in mpz_manager::quot_rem_core<1> (this=0x1b7f49c, a=...,
b=..., q=..., r=...) at ../src/util/mpz.cpp:498
#7  0x01541c8c in mpz_manager::big_rem (this=0x1b7f49c, a=..., b=...,
c=...) at ../src/util/mpz.cpp:546
#8  0x0002e654 in mpz_manager::rem (this=0x1b7f49c, a=..., b=..., c=...)
at ../src/util/mpz.h:459
#9  0x01542cac in mpz_manager::gcd (this=0x1b7f49c, a=..., b=..., c=...)
at ../src/util/mpz.cpp:749
#10 0x0002d708 in mpq_manager::gcd (this=0x1b7f49c, a=..., b=..., c=...)
at ../src/util/mpq.h:594
#11 0x0002c814 in mpq_manager::normalize (this=0x1b7f49c, a=...)
--Type  for more, q to quit, c to continue without paging--
at ../src/util/mpq.h:58
#12 0x0155d5a8 in mpq_manager::set (this=0x1b7f49c, a=...,
val=0x157cce0 "1", '0' , "1") at ../src/util/mpq.cpp:278
#13 0x00029cc4 in rational::rational (this=0xf8f02e88,
v=0x157cce0 "1", '0' , "1") at ../src/util/rational.h:55
#14 0x0002962c in tst_rational () at ../src/test/rational.cpp:460
#15 0x00145398 in main (argc=2, argv=0xf8f02028) at ../src/test/main.cpp:138
(gdb) disass
Dump of assembler code for function do_futex_wait:
   0xf88046f0 <+0>: stw rp,-14(sp)
   0xf88046f4 <+4>: ldo 80(sp),sp
   0xf88046f8 <+8>: stw r5,-74(sp)
   0xf88046fc <+12>:stw r4,-70(sp)
   0xf8804700 <+16>:copy r19,r4
   0xf8804704 <+20>:stw r19,-20(sp)
   0xf8804708 <+24>:stw r3,-6c(sp)
   0xf880470c <+28>:ldw 4(r26),r3
   0xf8804710 <+32>:b,l 0xf88055a4 <__pthread_enable_asynccancel>,rp
   0xf8804714 <+36>:stw r26,-78(sp)
   0xf8804718 <+40>:ldw -78(sp),r26
   0xf880471c <+44>:copy r4,r19
   0xf8804720 <+48>:copy ret0,r5
   0xf8804724 <+52>:ldi -1,r21
   0xf8804728 <+56>:ldi 0,r22
   0xf880472c <+60>:ldi 0,r23
   0xf8804730 <+64>:ldi 1,r24
   0xf8804734 <+68>:ldi 189,r25
   0xf8804738 <+72>:xor r3,r25,r25
   0xf880473c <+76>:copy r19,r4
   0xf8804740 <+80>:be,l 100(sr2,r0),sr0,r31
   0xf8804744 <+84>:ldi d2,r20
--Type  for more, q to quit, c to continue without paging--
   0xf8804748 <+88>:copy r4,r19
   0xf880474c <+92>:ldi ffd,r20
   0xf8804750 <+96>:ldo ffe(ret0),r21
   0xf8804754 <+100>:   cmpb,>>= r20,r21,0xf8804780 
   0xf8804758 <+104>:   copy r5,r26
   0xf880475c <+108>:   b,l 0xf8805670 <__pthread_disable_asynccancel>,rp
   0xf8804760 <+112>:   nop
   0xf8804764 <+116>:   ldi 0,ret0
   0xf8804768 <+120>:   ldw -94(sp),rp
   0xf880476c <+124>:   ldw -74(sp),r5
   0xf8804770 <+128>:   ldw -70(sp),r4
   0xf8804774 <+132>:   ldw -6c(sp),r3
   0xf8804778 <+136>:   bv r0(rp)
   0xf880477c <+140>:   ldo -80(sp),sp
   0xf8804780 <+144>:   stw ret0,-78(sp)
   0xf8804784 <+148>:   b,l 0xf8805670 <__pthread_disable_asynccancel>,rp
   0xf8804788 <+152>:   copy r19,r4
   0xf880478c <+156>:   ldw -78(sp),ret0
   0xf8804790 <+160>:   cmpib,= -b,ret0,0xf88047b4 
   0xf8804794 <+164>:   copy r4,r19
   0xf8804798 <+168>:   cmpib,= -4,ret0,0xf88047b4 
   0xf880479c <+172>:   ldi -ee,r20
   0xf88047a0 <+176>:   cmpb,= r20,ret0,0xf88047b4 
--Type  for more, q to quit, c to continue without paging--
   0xf88047a4 <+180>:   addil L%0,r19,r1
=> 0xf88047a8 <+184>:   ldw 1f0(r1),r26
   0xf88047ac <+188>:   b,l 0xf87f6960,rp
   0xf88047b0 <+192>:   nop
   0xf88047b4 <+196>:   b,l 0xf8804768 ,r0
   0xf88047b8 <+200>:   sub r0,ret0,ret0
End of assembler dump.
Breakpoint 4, 0xf8804740 in ?? ()
(gdb) p/x $r26
$1 = 0x1b7f6ac
(gdb) p/x $r25
$2 = 0x188
(gdb) p/x $r24
$3 = 0x1
(gdb) p/x $r23
$4 = 0x0
(gdb) p/x $r22
$5 = 0x0
(gdb) p/x $r21
$6 = 0x

The xor changes the futex op from FUTEX_WAIT_BITSET to FUTEX_TRYLOCK_PI.
This causes the unexpected futex operation.  What has happened is
sem->private has been set to 1 and this modifies the futex operation

Bug#907586: Problem logging in to hppa debian porterbox panama.debian.net

[John David Anglin]

On 2018-09-14 7:55 PM, John David Anglin wrote:

With g++-8 8.2.0-6 and its fix for BTS #907586, I was able to build the
nordugrid-arc package in a schroot on the panama porterbox.

Great.

I have committed fix to trunk and gcc-8:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00801.html

Will patch gcc 6 and 7 if things look good.

I gave back nordugrid-arc package.
Unfortunately, the fix applied for BTS #907586 is not the final patch 
applied above.


Dave

--
John David Anglin  dave.ang...@bell.net

Bug#907586: Fwd: Bug#907586: g++ compiler problem on hppa

[John David Anglin]

Thanks for reporting this problem and generating a reduced testcase.

S.cpp is miscompiled at -O2.  The test passes if it is compiled at -O0.

The hppa architecture is unique in that function pointers point to 
function descriptors.
Function pointers need to be "canonicalized" before they can be 
compared.  This involves
calling _dl_fixup if a function descriptor hasn't been bound to its 
actual target.  Lazy binding
is the default and the test fails due to the fact that the function 
pointers in _ZNK2SR4findEv

are not canonicalized at -O2.

A minor issue is "-fPIC" should be added to the link command "g++ 
-shared -o libS.so S.o".


I created a gcc PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188

On 2018-08-29 10:01 PM, Matthias Klose wrote:



 Forwarded Message 
Subject: Bug#907586: g++ compiler problem on hppa
Resent-Date: Wed, 29 Aug 2018 19:09:01 +
Resent-From: Mattias Ellert 
Resent-To: debian-bugs-d...@lists.debian.org
Resent-CC: Debian GCC Maintainers 
Date: Wed, 29 Aug 2018 21:04:09 +0200
From: Mattias Ellert 
Reply-To: Mattias Ellert , 907...@bugs.debian.org
To: sub...@bugs.debian.org

Package: g++-8
Version: 8.2.0-4 Severity: important

One of the packages I maintain have been failing in its test suite on
hppa ever since it was first uploaded. I was never able to investigate
the reason for this because there until recently were no hppa porter
box.

I recently discovered that there is now an hppa porter box and I have
been able to reproduce the issue. I managed to take the failing part of
the code and reduce it to a small test case that is attached to this
bug report.

The issue only happens on hppa, and only when linking using a shared
library. If the test case is linked statically the issue does not
appear.

On all architectures except hppa the output of the test case is the
following:

$ make
g++ -O2 -g -c -o main.o main.cpp
g++ -O2 -g -fPIC -c -o S.o S.cpp
g++ -shared -o libS.so S.o
g++ -o main main.o -L. -lS
g++ -o altmain main.o S.o
-- Running using shared library
LD_LIBRARY_PATH=. ./main
OK
-- Running using static build
./altmain
OK

On hppa the output is as follows:

$ make
g++ -O2 -g -c -o main.o main.cpp
g++ -O2 -g -fPIC -c -o S.o S.cpp
g++ -shared -o libS.so S.o
g++ -o main main.o -L. -lS
g++ -o altmain main.o S.o
-- Running using shared library
LD_LIBRARY_PATH=. ./main
not OK
-- Running using static build
./altmain
OK

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#892848: closed by Matthias Klose (Bug#892848: fixed in gcc-7 7.3.0-12)

[John David Anglin]

On 2018-03-18 11:09 AM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the src:gcc-7 package:

#892848: gcc-7: OpenMP support is broken on hppa in gcc-7 and earlier

Oops, caller copies patch wasn't installed in gcc-6.  It's installed now.

--
John David Anglin  dave.ang...@bell.net

Bug#892848: gcc-7: OpenMP support is broken on hppa in gcc-7 and earlier

[John David Anglin]

Source: gcc-7
Severity: normal
Tags: patch

Dear Maintainer,

The 32-bit hppa architecture is one of a few callee-copies targets in gcc.
Objects larger than eight bytes are passed by invisible reference and the
callee is responsible to copy the object if necessary.

This results in a variety of differences in optimizing code from x86, etc.
In the case of OpenMP support, it is seriously broken handling objects
passed by invisible references and the problem is not easily fixed.
This is gcc PR middle-end/68733.

Helge Deller and I discussed the matter and decided the best way forward
was to switch the hppa ABI to caller copies as on x86.  This should also
help to eliminate various optimization bugs that are hidden due to limited
testing.

The attached patch has been installed in gcc-8.  We would appreciate your
installing this change in Debian gcc-6 and gcc-7 so others are not affected.

Regards,
Dave Anglin


-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.25+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information
2018-01-16  John David Anglin  

* config.gcc (hppa*-*-linux*): Change callee copies ABI to caller
copies.

Index: config.gcc
===
--- config.gcc  (revision 256716)
+++ config.gcc  (working copy)
@@ -1339,7 +1339,7 @@
gas=yes gnu_ld=yes
;;
 hppa*-*-linux*)
-   target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS"
+   target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS|MASK_CALLER_COPIES"
tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h 
pa/pa-linux.h \
 pa/pa32-regs.h pa/pa32-linux.h"
tmake_file="${tmake_file} pa/t-linux"

Bug#855095: gcc-6: [hppa] regression: trivial program segfaults

[John David Anglin]

On 2017-02-13, at 7:44 PM, Andreas Cadhalpun wrote:

> Package: gcc-6
> Version: 6.3.0-6
> Severity: important
> Control: affects -1 ffmpeg
> X-Debbugs-Cc: debian-h...@lists.debian.org
> 
> Dear Maintainer,
> 
> ffmpeg 7:3.2.4-1 failed to build on hppa, because configure's C compiler test 
> failed [1]:
> BEGIN /tmp/ffconf.JlfWXo0F.c
>1  int main(void){ return 0; }
> END /tmp/ffconf.JlfWXo0F.c
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
> -O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
> -fno-strict-overflow -fstack-protector-all -fPIE -c -o /tmp/ffconf.vzRvJxAo.o 
> /tmp/ffconf.JlfWXo0F.c
> cc1: warning: -fstack-protector not supported for this target
> gcc -Wl,-z,relro -Wl,-z,now -fPIE -pie -o /tmp/ffconf.lZtBYrZt 
> /tmp/ffconf.vzRvJxAo.o
> Segmentation fault
> 
> It looks like gcc miscompiles the most trivial program, so that it segfaults 
> when run,
> but gcc-6 6.3.0-3 worked fine three weeks ago [2].


Essentially, the problem is caused by the switch to using hardening options.  
The problem isn't gcc.  It's
binutils and possibly glibc.

https://sourceware.org/bugzilla/show_bug.cgi?id=21132
https://sourceware.org/bugzilla/show_bug.cgi?id=21000
https://sourceware.org/bugzilla/show_bug.cgi?id=21131

Until these issues are resolved, the hardening options aren't going to work on 
hppa.

Dave
--
John David Anglin   dave.ang...@bell.net

Bug#853023: gcc-snapshot: Incorrect build dependencies on hppa

[John David Anglin]

Package: gcc-snapshot
Version: 20170125-1
Severity: normal

Dear Maintainer,

Your package does not build on hppa:

gcc-snapshot build-depends on missing:
- binutils-hppa64:hppa

The dpendency should be on binutils-hppa64-linux-gnu:hppa.

Regards,
Dave Anglin

-- System Information:
Debian Release: 9.0
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.10.0-rc5+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#838111: closed by Matthias Klose (Bug#838111: fixed in gcc-6 6.2.0-5)

[John David Anglin]

On 2016-09-28, at 12:24 PM, Debian Bug Tracking System wrote:

> We believe that the bug you reported is fixed in the latest version of
> gcc-6, which is due to be installed in the Debian FTP archive.

There was a typo in the applied fix and build is not successful.  See:
https://buildd.debian.org/status/fetch.php?pkg=gcc-6&arch=hppa&ver=6.2.0-5&stamp=1475105779

I had a successful build using following ln commands in binary-java.mk:

  ifeq ($(unprefixed_names),yes)
ln -sf $(cmd_prefix)gij$(pkg_ver) \
$(d_jrehl)/$(PF)/bin/gij$(pkg_ver)
ln -sf $(cmd_prefix)gij$(pkg_ver).bin \
$(d_jrehl)/$(PF)/bin/gij$(pkg_ver).bin
  endif

Regards,
Dave Anglin
--
John David Anglin   dave.ang...@bell.net

Bug#838111: gcj-6-jre-headless: /usr/bin/gij-6.bin: not found

[John David Anglin]

Package: gcj-6-jre-headless
Version: 6.2.0-4
Severity: normal

Dear Maintainer,

The /usr/bin/gij-6.bin file/link is not installed on hppa.  This causes
vtk6 and libreoffice builds to fail.  See for example:
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=hppa&ver=1%3A5.2.1-3&stamp=1474103136

checking for posix_fallocate... yes
checking whether to add custom build version... yes, 1:5.2.1-3
/usr/lib/jvm/java-gcj/bin/java: 10: exec: /usr/bin/gij-6.bin: not found
checking the installed JDK... configure: error: JDK is too old, you need at 
least 1.5
Error running configure at ./autogen.sh line 281.
debian/rules:1979: recipe for target 'debian/stampdir/build-arch' failed
make: *** [debian/stampdir/build-arch] Error 25
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Build finished at 2016-09-17T09:03:54Z

Regards,
Dave

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.7.4+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcj-6-jre-headless depends on:
ii  gcc-6-base 6.2.0-4
ii  gcj-6-jre-lib  6.2.0-4
ii  libc6  2.24-2+b1
ii  libgcc41:6.2.0-4
ii  libgcj17   6.2.0-4
ii  prctl  1.6-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

gcj-6-jre-headless recommends no packages.

Versions of packages gcj-6-jre-headless suggests:
ii  fastjar   2:0.98-6
ii  gcj-6-jdk 6.2.0-4
ii  libgcj17-awt  6.2.0-4

-- no debconf information

Bug#805698: Info received (Bug#805698: Acknowledgement (gcc-4.8: FTBFS on hppa: Control dependency for binutils-hppa64 needs update for new package name))

[John David Anglin]

Sorry, ignore last message.

Dave
--
John David Anglin   dave.ang...@bell.net

Bug#805698: Acknowledgement (gcc-4.8: FTBFS on hppa: Control dependency for binutils-hppa64 needs update for new package name)

[John David Anglin]

Fixed by rebuild of shadow.

Dave
--
John David Anglin   dave.ang...@bell.net

Bug#805839: gcc-5: Dependency problem on hppa with debug packages

[John David Anglin]

Package: gcc-5
Version: 5.2.1-24
Severity: normal

Dear Maintainer,

I tried to install libstdc++6-5-dbg:

mx3210:/home/dave# apt-get install libstdc++6-5-dbg libgcc4-dbg
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libgcc4-dbg : Depends: libgcc4 (= 5.2.1-24) but 1:5.2.1-24 is to be installed

Regards,
Dave Anglin

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.18.24+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-5 depends on:
ii  binutils  2.25.51.20151113-2
ii  cpp-5 5.2.1-24
ii  gcc-5-base5.2.1-24
ii  libc6 2.19-22+b6
ii  libcc1-0  5.2.1-24
ii  libgcc-5-dev  5.2.1-24
ii  libgcc4   1:5.2.1-24
ii  libgmp10  2:6.1.0+dfsg-2
ii  libisl15  0.15-3
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.3-1
ii  libstdc++65.2.1-24
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.19-22+b6

Versions of packages gcc-5 suggests:
pn  gcc-5-doc
pn  gcc-5-locales
pn  libasan2-dbg 
ii  libatomic1-dbg   5.2.1-24
pn  libcilkrts5-dbg  
pn  libgcc4-dbg  
ii  libgomp1-dbg 5.2.1-24
pn  libitm1-dbg  
pn  liblsan0-dbg 
pn  libmpx0-dbg  
pn  libquadmath-dbg  
pn  libtsan0-dbg 
pn  libubsan0-dbg

-- no debconf information

Bug#805698: gcc-4.8: FTBFS on hppa: Control dependency for binutils-hppa64 needs update for new package name

[John David Anglin]

Package: src:gcc-4.8
Version: 4.8.5-2
Severity: normal

Dear Maintainer,

The debian control file for gcc-4.8 needs an update.  The binutils-hppa64
dependency needs to change to binutils-hppa64-linux-gnu.

Same for gnat-4.9.

Regards,
Dave Anglin

-- Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.18.24+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#800781: gcc-5: FTBFS on hppa and others: dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1

[John David Anglin]

Package: gcc-5
Version: 5.2.1-20
Severity: normal

Dear Maintainer,

5.2.1-20 fails to build.  Here is relevant part of log:

dh_shlibdeps -pgnat-5
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatfind-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatfind-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatfind-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatls-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatls-5 (ELF format: 'elf32-hppa-linux'; RPATH: 
'')dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatls-5 (ELF format: 'elf32-hppa-linux'; RPATH: 
'')dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatprep-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatprep-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatprep-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatmake-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatmake-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatmake-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatclean-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatclean-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatclean-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatname-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatname-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatname-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatbind-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatbind-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatbind-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnat-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnat-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnat-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatlink-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatlink-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatlink-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatchop-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatchop-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatchop-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by 
debian/gnat-5/usr/bin/gnatxref-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatvsn.so.5 needed by 
debian/gnat-5/usr/bin/gnatxref-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libgnatprj.so.5 needed by 
debian/gnat-5/usr/bin/gnatxref-5 (ELF

Bug#800563: gcc-5: FTBFS on hppa: Incorrect dependency on binutils-hppa64

[John David Anglin]

Package: gcc-5
Version: 5.2.1-17+b1
Severity: normal

Dear Maintainer,

The binutils-hppa64 package was renamed to binutils-hppa64-linux-gnu
but gcc-5 depends on the old name.  Probably, it should depend on both
at least for now.

Regards,
Dave

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.18.21+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-5 depends on:
ii  binutils  2.25.1-3
ii  cpp-5 5.2.1-17+b1
ii  gcc-5-base5.2.1-17+b1
ii  libc6 2.19-22+b1
ii  libcc1-0  5.2.1-17+b1
ii  libgcc-5-dev  5.2.1-17+b1
ii  libgcc4   5.2.1-17+b1
ii  libgmp10  2:6.0.0+dfsg-7
ii  libisl13  0.14-2
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.3-1
ii  libstdc++65.2.1-17+b1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.19-22+b1

Versions of packages gcc-5 suggests:
pn  gcc-5-doc
pn  gcc-5-locales
pn  libasan2-dbg 
ii  libatomic1-dbg   5.2.1-17+b1
pn  libcilkrts5-dbg  
ii  libgcc4-dbg  5.2.1-17+b1
ii  libgomp1-dbg 5.2.1-17+b1
pn  libitm1-dbg  
pn  liblsan0-dbg 
pn  libmpx0-dbg  
pn  libquadmath-dbg  
pn  libtsan0-dbg 
pn  libubsan0-dbg

-- no debconf information

Bug#786692: gcc-5: FTBFS on hppa: configure error for configure-target-libiberty building hppa64

[John David Anglin]

On 2015-06-01 9:24 AM, Matthias Klose wrote:

On 05/30/2015 10:59 PM, John David Anglin wrote:

On 2015-05-29, at 5:18 PM, Matthias Klose wrote:


Anyway, please check if this is the real cause. attaching a hack which should
work around that.

The hack didn't fix build.  Here is log:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-5&arch=hppa&ver=5.1.1-9&stamp=1433017924

yep, here is what I'm checking in. should be good enough for hppa64.

Index: b/src/configure.ac
===
--- a/src/configure.ac
+++ b/src/configure.ac
@@ -147,6 +147,11 @@ libgcj="target-libffi \
 target-zlib \
 target-libjava"

+case x"${target}" in

Do we need the x?


+  hppa64-*linux*) ;;
+  *) target_libiberty="target-libiberty";;
+esac
+
  # these libraries are built for the target environment, and are built after
  # the host libraries and the host tools (which may be a cross compiler)
  # Note that libiberty is not a target library.

It seems libiberty was explicitly omitted as a target library.

@@ -170,6 +175,7 @@ target_libraries="target-libgcc \
 ${libgcj} \
 target-libobjc \
 target-libada \
+   ${target_libiberty} \
 target-libgo"

  # these tools are built using the target libraries, and are intended to







--
John David Anglin  dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/blu436-smtp1125c095a9cf2ffb4805fe297...@phx.gbl

Bug#786692: gcc-5: FTBFS on hppa: configure error for configure-target-libiberty building hppa64

[John David Anglin]

On 2015-05-29, at 5:18 PM, Matthias Klose wrote:

> Anyway, please check if this is the real cause. attaching a hack which should
> work around that.

The hack didn't fix build.  Here is log:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-5&arch=hppa&ver=5.1.1-9&stamp=1433017924

We appear to have failed in second hunk:
...
touch stamps/04-configure-hppa64-stamp
make[1]: Leaving directory '/«PKGBUILDDIR»'
/usr/bin/make -f debian/rules2 stamps/05-build-hppa64-stamp
make[1]: Entering directory '/«PKGBUILDDIR»'
PATH=/«PKGBUILDDIR»/bin:/usr/lib/hppa-linux-gnu/gcc/bin:$PATH \
   \
  LOCPATH=/«PKGBUILDDIR»/locales \
  LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}/«PKGBUILDDIR»/build/gcc 
\
/usr/bin/make -C /«PKGBUILDDIR»/build-hppa64 -j 5 \
CC="" \
\

make[2]: Entering directory '/«PKGBUILDDIR»/build-hppa64'
make[3]: Entering directory '/«PKGBUILDDIR»/build-hppa64'
mkdir -p -- ./libiberty
mkdir -p -- ./fixincludes
mkdir -p -- ./intl
mkdir -p -- ./lto-plugin
mkdir -p -- build-hppa-linux-gnu/libiberty
Configuring in ./fixincludes
Configuring in build-hppa-linux-gnu/libiberty
Configuring in ./libiberty
Configuring in ./intl
Configuring in ./lto-plugin
---
configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[3]: *** [configure-target-libiberty] Error 1
checking for library containing strerror... Makefile:11736: recipe for target 
'configure-target-libiberty' failed
make[3]: Leaving directory '/«PKGBUILDDIR»/build-hppa64'
make[2]: *** [all] Error 2
Makefile:859: recipe for target 'all' failed
make[2]: Leaving directory '/«PKGBUILDDIR»/build-hppa64'
make[1]: *** [stamps/05-build-hppa64-stamp] Error 2
debian/rules2:1325: recipe for target 'stamps/05-build-hppa64-stamp' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [stamps/05-build-hppa64-stamp] Error 2
debian/rules:60: recipe for target 'stamps/05-build-hppa64-stamp' failed
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2



Dave

--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/blu436-smtp5912eb72b0f5b9ff77c7f497...@phx.gbl

Bug#786692: gcc-5: FTBFS on hppa: configure error for configure-target-libiberty building hppa64

[John David Anglin]

On 2015-05-29 2:25 PM, Matthias Klose wrote:

I don't think I have any packaging changes which could lead to this.

Okay.  I didn't see anything in changelog entries.


Looking at the build log, I see the CC is overridden in the build target,
can you check if removing the
   CC="$(CC_for_hppa64_cross)"
line helps? fixing this in the VCS, but I don't see how this could be related.
Yes, CC_for_hppa64_cross is not defined.  Should CC be set or just 
removed?  Looking down

at the neon hunk below, it might have same problem.


as a last resort, you could configure the hppa64 build with --disable-lto.


I did try this and various other permutations.  In some cases, the build 
got to the CC_for_hppa64_cross
hunk but always something wanted target libiberty.  I've wondered if the 
latter hunk is needed.


I need to look at the buildd results carefully.  I wasn't able to 
duplicate the issue with my own cross although

I didn't try with gcc-5.

Dave

--
John David Anglin  dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/blu436-smtp230f55b10e8532c1dbfd5c397...@phx.gbl

Bug#786692: gcc-5: FTBFS on hppa: configure error for configure-target-libiberty building hppa64

[John David Anglin]

Source: gcc-5
Version: 5.1.1-6
Severity: normal

A since 5.1.1-6, gcc-5 no longer builds on hppa:

checking size of long... 0
checking for long long... no
checking for a 64-bit type... unsigned long
checking for intptr_t... no
checking for uintptr_t... no
checking for ssize_t... no
checking for pid_t... no
configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[3]: *** [configure-target-libiberty] Error 1
checking for library containing strerror... Makefile:11736: recipe for target 
'configure-target-libiberty' failed
make[3]: Leaving directory '/«PKGBUILDDIR»/build-hppa64'
make[2]: *** [all] Error 2
make[1]: *** [stamps/05-build-hppa64-stamp] Error 2
Makefile:859: recipe for target 'all' failed
make[2]: Leaving directory '/«PKGBUILDDIR»/build-hppa64'
debian/rules2:1318: recipe for target 'stamps/05-build-hppa64-stamp' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [stamps/05-build-hppa64-stamp] Error 2
debian/rules:60: recipe for target 'stamps/05-build-hppa64-stamp' failed
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Full buildd log is here:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-5&arch=hppa&ver=5.1.1-6&stamp=1432360049

I tried adding --disable-libiberty to hppa64 configure command.  However,
this resulted in following error:

checking whether /«PKGBUILDDIR»/build/gcc/xgcc -B/«PKGBUILDDIR»/build/gcc/ 
supports -Wstrict-prototypes... checking for stdint.h... libtool: link: 
/«PKGBUILDDIR»/build/gcc/xgcc -B/«PKGBUILDDIR»/build/gcc/ -shared  -fPIC -DPIC  
.libs/lto-plugin.o-static-libgcc ../libiberty/libiberty.a -static-libstdc++ 
-static-libgcc   -Wl,-soname -Wl,liblto_plugin.so.0 -o 
.libs/liblto_plugin.so.0.0.0
xgcc: error: ../libiberty/libiberty.a: No such file or directory
make[5]: *** [liblto_plugin.la] Error 1
yes
Makefile:351: recipe for target 'liblto_plugin.la' failed
make[5]: Leaving directory '/«PKGBUILDDIR»/build-hppa64/lto-plugin'
make[4]: *** [all] Error 2
Makefile:264: recipe for target 'all' failed
make[4]: Leaving directory '/«PKGBUILDDIR»/build-hppa64/lto-plugin'
make[3]: *** [all-lto-plugin] Error 2
make[3]: *** Waiting for unfinished jobs
Makefile:8664: recipe for target 'all-lto-plugin' failed

Full log for this build is here:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-5&arch=hppa&ver=5.1.1-7&stamp=1432446476

It is a bit of a puzzle why lto plugin support needs a target version of 
libiberty.

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.17.8+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/blu436-smtp1828f3a5666e8f79f5a283a97...@phx.gbl

Bug#778658: Acknowledgement (gcc-snapshot: FTBFS on hppa -- switch to g++ breaks hppa64 cross)

[John David Anglin]

With the attached change to debian/rules2, gcc-snapshot builds successfully on 
hppa (native build).
DEBIAN_CROSS was not tested.

We now need both a c and c++ compiler to build hppa64.  libbacktrace only 
builds with c compiler.

Dave
--
John David Anglin   dave.ang...@bell.net




gcc-snapshot-rules2.diff
Description: Binary data

Bug#778658: gcc-snapshot: FTBFS on hppa -- switch to g++ breaks hppa64 cross

[John David Anglin]

Package: gcc-snapshot
Version: 20150211-1
Severity: normal

>From build log:

checking for libvtv support... no
checking for hppa-linux-gnu-gcc... 
/home/dave/debian/gcc-snapshot/gcc-snapshot-20150211/build/gcc/xg++ 
-B/home/dave/debian/gcc-snapshot/gcc-snapshot-20150211/build/gcc/
checking for C compiler default output file name... 
configure: error: in 
`/home/dave/debian/gcc-snapshot/gcc-snapshot-20150211/build-hppa64':
configure: error: C compiler cannot create executables
See `config.log' for more details.
debian/rules2:1283: recipe for target 'stamps/04-configure-hppa64-stamp' failed
make[1]: *** [stamps/04-configure-hppa64-stamp] Error 77
make[1]: Leaving directory 
'/home/dave/debian/gcc-snapshot/gcc-snapshot-20150211'
debian/rules:35: recipe for target 'stamps/04-configure-hppa64-stamp' failed
make: *** [stamps/04-configure-hppa64-stamp] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

>From config.log:

configure:4345: checking for C compiler default output file name
configure:4367: /home/dave/debian/gcc-snapshot/gcc-snapshot-20150211/build/gcc/x
g++ -B/home/dave/debian/gcc-snapshot/gcc-snapshot-20150211/build/gcc/conftes
t.c  >&5
/usr/bin/ld.bfd.real: cannot find -lstdc++
collect2: error: ld returned 1 exit status
configure:4371: $? = 1
configure:4408: result: 
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""| /* end confdefs.h.  */
| | int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:4414: error: in 
`/home/dave/debian/gcc-snapshot/gcc-snapshot-20150211/build-hppa64':
configure:4418: error: C compiler cannot create executables

-- System Information:
Debian Release: 8.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.17.8+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/blu437-smtp84fbdc18be738ad7ebba7c97...@phx.gbl

Bug#771974: gcc-4.9: FTBFS on hppa after r218208

[John David Anglin]

Package: gcc-4.9
Version: 4.9.2-5
Severity: normal

gcc-4.9 4.9.2-5 fails to build from source on hppa.  See:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=hppa&ver=4.9.2-5&stamp=1417599336

r218208 introduced a number of problems including this PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64167

-- System Information:
Debian Release: 8.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.17.4+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-4.9 depends on:
ii  binutils2.24.90.20141201-1
ii  cpp-4.9 4.9.2-4
ii  gcc-4.9-base4.9.2-4
ii  libc6   2.19-13
ii  libcloog-isl4   0.18.2-1
ii  libgcc-4.9-dev  4.9.2-4
ii  libgmp102:6.0.0+dfsg-6
ii  libisl100.12.2-2
ii  libmpc3 1.0.2-1
ii  libmpfr43.1.2-1+b2
ii  zlib1g  1:1.2.8.dfsg-2

Versions of packages gcc-4.9 recommends:
ii  libc6-dev  2.19-13

Versions of packages gcc-4.9 suggests:
pn  gcc-4.9-doc  
pn  gcc-4.9-locales  
pn  libasan1-dbg 
ii  libatomic1-dbg   4.9.2-4
pn  libcilkrts5-dbg  
ii  libgcc4-dbg  4.9.2-4
ii  libgomp1-dbg 4.9.2-4
pn  libitm1-dbg  
pn  liblsan0-dbg 
pn  libquadmath-dbg  
pn  libtsan0-dbg 
pn  libubsan0-dbg

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/blu436-smtp18831cfb85d3753bad07b1697...@phx.gbl

Bug#754721: gcc-4.8-hppa64_4.8.3-4: 3.15 and 3.16 Linux kernels fail to boot when built with GCC 4.8.3-4

[John David Anglin]

Package: gcc-4.8
Version: 4.8.3-3
Severity: normal

This problem is specific to GCC 4.8.3-4.  The kernel boot failure does
not occur with 4.8.3-3 and earlier.

The boot failure occurs both with the latest Debian 64-bit unstable kernel
and user 64-bit kernel builds:

Hierarchical RCU implementation.
[ cut here ]
WARNING: at kernel/rcu/tree.c:3148
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.5+ #1
task: 40798258 ti: 40704000 task.ti: 40704000

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW:  Not tainted
r00-03  00ff0804ff0e 40704330 4010c2f4 40704330
r04-07  4069b9a0 4079b900 40726d68 
r08-11  407043f0 40726c98 4079b9c0 0001
r12-15  406b01a0 406b01a0  406b01a0
r16-19  406c01a0 4172e670 40727080 4172e660
r20-23   003f  0001
r24-27   0020 4079b900 4069b9a0
r28-31  080e 407043f0 40704420 40766d09
sr00-03     
sr04-07     

IASQ:   IAOQ: 4010c35c 4010c360
IIR: 03ffe01fISR: 1034  IOR: 0005cbb2e728
CPU:0   CR30: 40704000 CR31: 
ORIG_R28: 0021
IAOQ[0]: rcu_init_one+0x39c/0x458
IAOQ[1]: rcu_init_one+0x3a0/0x458
RP(r2): rcu_init_one+0x334/0x458
Backtrace:
[<4010c77c>] rcu_init+0x244/0x320
[<40100e30>] start_kernel+0x3c0/0x840
[<4056dcf8>] cache_ioctl.isra.9+0xa8/0x100
[<405312bc>] ip_mroute_setsockopt+0x694/0x938
[<40506fd0>] raw_sendmsg+0x288/0x980
[<404e4658>] tcp_ioctl+0x100/0x250
[<404dd63c>] ip_getsockopt+0x134/0x148
[<404dd1f8>] do_ip_getsockopt+0x4b8/0x7c8
[<404c0660>] compat_SyS_setsockopt+0x238/0x2a8
[<404c0268>] scm_detach_fds_compat+0xd0/0x290
[<404bfb08>] get_compat_msghdr+0x150/0x180

---[ end trace b64f93fd77ce594e ]---
NR_IRQS:128
Console: colour dummy device 160x64
[...]
153 out of 253 testcases failed, as expected. |

Calibrating delay loop...

On 9-Jul-14, at 12:19 PM, Helge Deller wrote:

Hi Dave,

On a side-note:
The current 3.14-10 debian kernel (either plain or my +b1 build) doesn't boot 
on 64bit.
It just hangs in "Calibrating delay loop"...
I suspect a gcc-4.8 or binutils problem... Not sure yet. The warning at tree.c 
is strange too...

[17179568.536289] Hierarchical RCU implementation.
[17179568.536289]   CONFIG_RCU_FANOUT set to non-default value of 32
[17179568.536289] [ cut here ]
[17179568.536289] WARNING: at 
/build/linux-VzmjOd/linux-3.14.10/kernel/rcu/tree.c:3096
[17179568.536289] Modules linked in:
[17179568.536289] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14-1-parisc64-smp 
#1 Debian 3.14.10-1
[17179568.536289] task: 40929a18 ti: 40878000 task.ti: 
40878000
[17179568.536289]
[17179568.536289]  YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[17179568.536289] PSW:  Not tainted
[17179568.536289] r00-03  00ff0804ff0e 40878330 4010b0dc 
40878330
[17179568.536289] r04-07  407fbbf0 4092d4c0 4089bef0 

[17179568.536289] r08-11  408783f0 4092d4c0 0001 
408133f0
[17179568.536289] r12-15  408133f0  408133f0 
408273f0
[17179568.536289] r16-19  4290d668 4089c270 f174 

[17179568.536289] r20-23  4290d658 027b7000 4092d510 
0001
[17179568.536289] r24-27   0008 4092d4c0 
407fbbf0
[17179568.536289] r28-31  080e 408783f0 40878420 
408e0747
[17179568.536289] sr00-03     

[17179568.536289] sr04-07     

[17179568.536289]
[17179568.536289] IASQ:   IAOQ: 
4010b1b4 4010b1b8
[17179568.536289]  IIR: 03ffe01fISR: 1034  IOR: 000a4350d720
[17179568.536289]  CPU:0   CR30: 40878000 CR31: 
[17179568.536289]  ORIG_R28: 0044
[17179568.536289]  IAOQ[0]: rcu_init_one+0x304/0x398
[17179568.536289]  IAOQ[1]: rcu_init_one+0x308/0x398
[17179568.536289]  RP(r2): rcu_init_one+0x22c/0x398
[17179568.536289] Backtrace:
[17179568.536289]  [<4010b5c8>] rcu_init+0x260/0x340
[17179568.536289]  [<40100e64>] start_kernel+0x3f4/0x8d8
[

Bug#745906: gcc-snapshot: FTBFS on hppa: cp: cannot stat 'debian/gcc-ar.1'

[John David Anglin]

Package: gcc-snapshot
Version: 20140423-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

During install, the following error occurs:

for i in ar nm ranlib; do \
  cp debian/gcc-$i.1 
debian/tmp/usr/lib/gcc-snapshot/share/man/man1/gcc-$i.1; \
done
cp: cannot stat 'debian/gcc-ar.1': No such file or directory
make[1]: *** [stamps/07-install-snap-stamp] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'

Full log is here:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-snapshot&arch=hppa&ver=20140423-1&stamp=1398489847

-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.14.1+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/blu0-smtp933847b760595c0dd8da4297...@phx.gbl

Bug#745116: src:gcc-4.8: DEB_CROSS_NO_BIARCH=yes ignored for DEB_TARGET_ARCH=hppa

[John David Anglin]

On 18-Apr-14, at 10:43 PM, Matthias Klose wrote:


Control: tags -1 - patch

Am 18.04.2014 08:19, schrieb Helmut Grohne:

Package: src:gcc-4.8
Version: 4.8.2-19
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

I noticed that a DEB_TARGET_ARCH=hppa build with  
DEB_CROSS_NO_BIARCH=yes

would try to build for hppa64 as well. The attached patch flips the
default of with_hppa64 for this particular case.


this is not biarch, but a cross compiler. So what you need to do is  
to make sure
that you are able to build a canadian cross (cross-building the  
cross compiler).
Just omitting to build the hppa64 cross-compiler would leave you  
without a

compiler to build the kernel.



Is this a bug?

Matthias is correct.  The hppa64 applications from GCC and binutils  
are Canadian cross
compilers using the 32-bit Linux runtime.  This is not the case on HP- 
UX where 64-bit native

binutils applications are built.

The 32 and 64-bit code generation is not biarch in HP-UX.  This is  
because there are
significant differences between the SOM and ELF object formats in the  
two runtimes.  There
is no SOM linker in binutils.  Merging the GCC code would require  
significant changes
to some macro defines used throughout all of GCC (i.e., this would  
touch more than hppa).


The 64-bit compiler and binutils tools are required because certain PA- 
RISC machines

only support 64-bit kernel code.

For Linux, it might be possible to merge the 32 and 64-bit tools but  
it's a fair bit of work.
I did some work on binutils a few years ago to make the 32 and 64-bit  
code more similar.


There is currently no 64-bit glibc port or syscall interface.  James  
Bottomley has done
a bit of work on this but he hasn't made it publicly available.  I  
tend to think a 64-bit Linux

runtime would yield more benefit than tool chain integration.

Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/blu0-smtp40b29449dca4c26e8c3c6597...@phx.gbl

Bug#743833: gnat-4.6: no longer buildable on buildds

[John David Anglin]

Further, if one does a build outside buildd and then a +b1 inside  
buildd, the
results is no longer installable as it depends on a non existent +b1  
version

of gnat-4.6-base.

Cheers,
Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/blu0-smtp7539705df662ec2ac55e3097...@phx.gbl

Bug#739224: gcj-4.8: /usr/bin/gij-4.8 executes /usr/bin/gij-4.4.bin

[John David Anglin]

Package: gcj-4.8
Version: 4.8.2-15
Severity: normal

The /usr/bin/gij-4.8 incorrectly executes /usr/bin/gij-4.4.bin.
The script is also duplicated:

dave@mx3210:/usr/bin$ less gij-4.8
#! /bin/sh

prctl=

case "$(prctl --unaligned=)" in *signal)
echo >&2 "$(basename $0): ignore unaligned memory accesses"
prctl="prctl --unaligned=default"
esac

exec $prctl /usr/bin/gij-4.4.bin "$@"
#! /bin/sh

prctl=

case "$(prctl --unaligned=)" in *signal)
echo >&2 "$(basename $0): ignore unaligned memory accesses"
prctl="prctl --unaligned=default"
esac

exec $prctl /usr/bin/gij-4.4.bin "$@"


-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.14.0-rc1+ (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcj-4.8 depends on:
ii  dpkg   1.17.6
ii  ecj-gcj [libecj-java-gcj]  3.9.0-1
ii  gcc-4.84.8.2-15
ii  gcc-4.8-base   4.8.2-15
ii  install-info   5.2.0.dfsg.1-2+b1
ii  libc6  2.17-97
ii  libc6-dev  2.17-97
ii  libcloog-isl4  0.18.1-3
ii  libecj-java-gcj3.9.0-1
ii  libgmp10   2:5.1.3+dfsg-1
ii  libisl10   0.12.2-1
ii  libmpc31.0.1-1+b1
ii  libmpfr4   3.1.2-1+b2
ii  zlib1g 1:1.2.8.dfsg-1+b1

gcj-4.8 recommends no packages.

gcj-4.8 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp94675eb7112fc32770481b97...@phx.gbl

Bug#731069: gcc-defaults: Please resume considering to change using unified version of gcc

[John David Anglin]

I have no objection to moving to a unified version of gcc on hppa.   
gcc-4.8

would be my choice.

On 2-Dec-13, at 7:14 AM, Matthias Klose wrote:


Control: tags -1 + moreinfo

Afaics, the situation didn't change. There is nobody committing to  
work on the
toolchain for these architectures.  At least for release  
architectures the
alternative is to drop the port unless somebody wants to maintain  
the toolchain
for this port.  This is the current status, please correct me if I'm  
wrong.


- alpha, no feedback, CCing Michael Cree.
- hppa, no feedback, CCing John David Anglin
- ia64, no feedback, likely to be removed.
- powerpc, found some feedback from the porters, but unrelated to
  toolchain issues, see
  https://lists.debian.org/debian-powerpc/2013/11/msg00050.html
- powerpcspe, no feedback, CCing Roland Stigge.
- ppc64, no feedback
- s390x, pending upload
- sparc, no feedback
- sh4, no feedback, doesn't build, CCing Nobuhiro Iwamatsu

Am 01.12.2013 16:45, schrieb Hiroyuki Yamamoto:

Source: gcc-defaults
Version: 1.123
Severity: wishlist
Tags: patch

Please resume considering to change using unified version of gcc,
because FTBFS of many packages occur by e.g. c++11
on ports which stayed using gcc-4.6 and g++-4.6,
ia64, powerpc, s390x, sparc, alpha, powerpcspe, ppc64, sh4.

And using unified version of gcc must bring happiness
to many package maintainers.

On the other hand, I understand that this changing depends on
the correspondence status of gcc porting,
so I leave decision to you.


This is a decision for the porters.  If there are no active porters,  
there

shouldn't be a port.

Unfortunately, building gcc-4.8 source package on sh4 has not  
succeeded yet,

so here is a patch which changes gcc-4.8 using on ports except sh4.

Regards,



Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp159ef0af22e96a1af4006097...@phx.gbl

Bug#716736: gcc hppa64

[John David Anglin]

On 16-Jul-13, at 5:27 AM, Matthias Klose wrote:


Am 15.07.2013 03:26, schrieb John David Anglin:

On 12-Jul-13, at 6:52 AM, Matthias Klose wrote:


I'm not aware of any change in -6 which could have caused that.


It appears the change that exposed the bug was the installation of  
eglibc 2.17-7.


The stdc-predef.h header is now included automatically.  It includes
.

The hppa64 header search starts from /usr/hppa64-linux-gnu/include  
which is
linked to /usr/include.  There isn't multiarch support so the  
compiler doesn't find

bits/predefs.h in /usr/include/hppa-linux-gnu.

There is no glibc port for hppa64 linux.

I think the problem was introduced by the following change to gcc:

2012-10-23  Joseph Myers  

   * config.gcc (*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu |
   *-*-knetbsd*-gnu | *-*-gnu* | *-*-kopensolaris*-gnu): Use
   glibc-c.o in c_target_objs and cxx_target_objs.  Use t-glibc  
in

   tmake_file.  Set target_has_targetcm.
   (tilegx-*-linux*, tilepro-*-linux*): Append to c_target_objs  
and

   cxx_target_objs rather than overriding previous value.
   * config/glibc-c.c, config/t-glibc: New.
   * doc/tm.texi.in (TARGET_C_PREINCLUDE): New @hook.
   * doc/tm.texi: Regenerate.
   * hooks.c (hook_constcharptr_void_null): New.
   * hooks.h (hook_constcharptr_void_null): Declare.

It may be possible to disable this in config.gcc.


maybe. Or ship a symlink /usr/include/hppa64-linux-gnu -> hppa-linux- 
gnu. The
file just needs to be found, nothing else should use it.  However I  
didn't look
if the multiarch triplet for hppa64-linux-gnu is set, or correctly  
set.


Please close this bug.  The problem was resolved by a change to my  
build system

configuration.

/usr/hppa64-linux-gnu/include was a symlink to /usr/include.  This  
together
with the configure option --includedir=/usr/hppa64-linux-gnu/include  
and new predef
support caused the build error.  Simply changing /usr/hppa64-linux-gnu/ 
include to

a real directory avoids the problem.

Nothing is actually installed in /usr/hppa64-linux-gnu/include, so it  
probably doesn't need to exist.


The symbolic link on my system dates back to 2010.  I can't remember  
if it was an experiment

on my part or not.

I'm going to remove adding pa/t-linux to tmake_file in the hppa64  
config.gcc hunk in the near
future.  pa/t-linux defines MULTIARCH_DIRNAME to hppa-linux-gnu.   
Aside from probably being
wrong, I don't think the hppa64 compiler needs to be multiarch at this  
time.


The symlink /usr/include/hppa64-linux-gnu -> hppa-linux-gnu didn't help.

Thanks,
Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp376ad601b224fe75a638c597...@phx.gbl

Bug#716736: gcc hppa64

[John David Anglin]

On 7/16/2013 5:27 AM, Matthias Klose wrote:

Am 15.07.2013 03:26, schrieb John David Anglin:

On 12-Jul-13, at 6:52 AM, Matthias Klose wrote:


I'm not aware of any change in -6 which could have caused that.

It appears the change that exposed the bug was the installation of eglibc 
2.17-7.

The stdc-predef.h header is now included automatically.  It includes
.

The hppa64 header search starts from /usr/hppa64-linux-gnu/include which is
linked to /usr/include.  There isn't multiarch support so the compiler doesn't 
find
bits/predefs.h in /usr/include/hppa-linux-gnu.

There is no glibc port for hppa64 linux.

I think the problem was introduced by the following change to gcc:

2012-10-23  Joseph Myers  

 * config.gcc (*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu |
 *-*-knetbsd*-gnu | *-*-gnu* | *-*-kopensolaris*-gnu): Use
 glibc-c.o in c_target_objs and cxx_target_objs.  Use t-glibc in
 tmake_file.  Set target_has_targetcm.
 (tilegx-*-linux*, tilepro-*-linux*): Append to c_target_objs and
 cxx_target_objs rather than overriding previous value.
 * config/glibc-c.c, config/t-glibc: New.
 * doc/tm.texi.in (TARGET_C_PREINCLUDE): New @hook.
 * doc/tm.texi: Regenerate.
 * hooks.c (hook_constcharptr_void_null): New.
 * hooks.h (hook_constcharptr_void_null): Declare.

It may be possible to disable this in config.gcc.

maybe. Or ship a symlink /usr/include/hppa64-linux-gnu -> hppa-linux-gnu. The
file just needs to be found, nothing else should use it.  However I didn't look
if the multiarch triplet for hppa64-linux-gnu is set, or correctly set.
I have a patch that disables the predef support and it allows the hppa64 
package to build.
Without patch, build fails trying to build libgcc due to same predef 
error.  However, I don't think
header access really works because the multiarch directy isn't being 
accessed..


I tried to enable multiarch support last night but it didn't work. Don't 
know why.  Just added

the configure options to the hppa64 configure options in rules2.

In config.gcc, we add pa/t-linux to tmake_file for hppa*64*-*-linux*.  
pa/t-linux defines
MULTIARCH_DIRNAME = $(call if_multiarch,hppa-linux-gnu), so I thought 
cc1 should
search for hppa-linux-gnu instead of hppa64-linux-gnu.  Possibly, we 
should introduce
a t-linux64 and make the multiarch directory hppa64-linux-gnu, then add 
the link that you

suggest.

Somehow I think the multiarch stuff is not working because we have a 
cross.  Will try to debug

more tonight.

Dave


--
John David Anglindave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e56bb1.2070...@bell.net

Bug#716736: gcc hppa64

[John David Anglin]

On 12-Jul-13, at 6:52 AM, Matthias Klose wrote:


I'm not aware of any change in -6 which could have caused that.


It appears the change that exposed the bug was the installation of  
eglibc 2.17-7.


The stdc-predef.h header is now included automatically.  It includes  
.


The hppa64 header search starts from /usr/hppa64-linux-gnu/include  
which is
linked to /usr/include.  There isn't multiarch support so the compiler  
doesn't find

bits/predefs.h in /usr/include/hppa-linux-gnu.

There is no glibc port for hppa64 linux.

I think the problem was introduced by the following change to gcc:

2012-10-23  Joseph Myers  

* config.gcc (*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu |
*-*-knetbsd*-gnu | *-*-gnu* | *-*-kopensolaris*-gnu): Use
glibc-c.o in c_target_objs and cxx_target_objs.  Use t-glibc in
tmake_file.  Set target_has_targetcm.
(tilegx-*-linux*, tilepro-*-linux*): Append to c_target_objs  
and

cxx_target_objs rather than overriding previous value.
* config/glibc-c.c, config/t-glibc: New.
* doc/tm.texi.in (TARGET_C_PREINCLUDE): New @hook.
* doc/tm.texi: Regenerate.
* hooks.c (hook_constcharptr_void_null): New.
* hooks.h (hook_constcharptr_void_null): Declare.

It may be possible to disable this in config.gcc.

Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp10d064a519c1d881164b1a97...@phx.gbl

Bug#716736: gcc-4.8-hppa64: Multiarch support broken in upgrade to 4.8.1-6 -- breaks Linux kernel build

[John David Anglin]

On 12-Jul-13, at 1:27 AM, Andrei POPESCU wrote:


Control: reassign -1 src:gcc-4.8 4.8.1-6

On Jo, 11 iul 13, 22:27:55, John David Anglin wrote:

Package: gcc-4.8-hppa64
Version: 4.8.1-6
Severity: important


Hmm, the PTS does show such a binary for gcc-4.8, but p.d.o doesn't.
Reassigning to the source package instead, though my first impulse was
to just close it.


Yes, I noticed this as well but the package has been generated for  
years.


Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp187bc67e1e04b4ff1b714897...@phx.gbl

Bug#704020: gcc-4.8: FTBFS on hppa

[John David Anglin]

On 4/25/2013 10:11 AM, Domenico Andreoli wrote:

There are a thousand or so packages there.  Uploaded gcc-4.8 package
>set last night.

upgrading everything here. all the patches are then upstream now?

Regarding gcc-4.8, it is my understanding that the Debian build
problem is resolved (minor fix to the rules file).

There is a problem with PA 1.x code generation in gcc-4.8 that
I'm working on.  There's a reload problem handling auto increment/decrement
instructions.  I didn't discover this until after 4.8.0 was released.
Auto increment/decrement instructions are not profitable on PA 8000
and generation is disabled when PA 8000 scheduling is used (linux and
PA 2.0).  Normally, one won't see this on linux.

Dave

--
John David Anglindave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/517942c2.4010...@bell.net

Bug#704020: gcc-4.8: FTBFS on hppa

[John David Anglin]

On 28-Mar-13, at 1:25 AM, Matthias Klose wrote:


Am 26.03.2013 23:14, schrieb Dave Anglin:

Package: gcc-4.8
Version: 4.8.0-1
Severity: normal

There is a config problem building the hppa64 package:


David, I'm applying this patch, however I don't see much sense  
anymore in having
a current compiler without at least an unstable chroot.  Back in Jan/ 
Feb I did

ask about the state of it, asked Aurelian to re-send open issues about
ports.debian.org, but didn't get any reply.


Thanks for applying the patch and trying to query Aurelian.

Regarding ports, I also never got any replies.  Helge Deller and  
myself would still like
to get a hppa buildd going.  Had a couple of emails with Bdale on the  
subject.  It appears that
it may be possible to setup a wanna build server outside Debian  
although Helge favours

using the existing Debian setup.

Helge has setup a package upload system to parisc-linux.org.  So, to  
access the packages
that we have, one just has to add the following to /etc/apt/ 
sources.list:


deb ftp://ftp.de.debian.org/debian-ports unstable main
deb ftp://ftp.parisc-linux.org/debian-ports/unstable  unstable main

There are a thousand or so packages there.  Uploaded gcc-4.8 package  
set last night.


Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp7fd11a233444e6aa3311997...@phx.gbl

Bug#704020: gcc-4.8: FTBFS on hppa

[John David Anglin]

On 27-Mar-13, at 9:29 AM, John David Anglin wrote:


Although undocumented, adding "--disable-libatomic" to the
configure options in rules2 seems to avoid the error.



I also had the following install issues:

dpkg: error processing gcc-4.8-hppa64_4.8.0-1_hppa.deb (--install):
 trying to overwrite '/usr/bin/hppa64-linux-gnu-gcc-ar', which is  
also in package gcc-4.7-hppa64 4.7.2-5


dpkg: dependency problems prevent configuration of libobjc4-dbg:hppa:
 libobjc4-dbg:hppa depends on libgcc4-dbg (>= 1:4.8.0-1); however:
  Version of libgcc4-dbg:hppa on system is 4.8.0-1.

dpkg: dependency problems prevent configuration of libstdc++6-4.8- 
dbg:hppa:
 libstdc++6-4.8-dbg:hppa depends on libgcc4-dbg (>= 1:4.8.0-1);  
however:

  Version of libgcc4-dbg:hppa on system is 4.8.0-1.

mx3210:/home/dave/debian/gcc/gcc-4.8# gcc-4.8 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.8.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/hppa-linux-gnu/4.8/lto-wrapper
Target: hppa-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian  
4.8.0-1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs -- 
enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program- 
suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/ 
lib --without-included-gettext --enable-threads=posix --with-gxx- 
include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with- 
sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable- 
libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp -- 
disable-libitm --enable-plugin --with-system-zlib --enable-objc-gc -- 
enable-multiarch --disable-libstdcxx-pch --enable-checking=release -- 
build=hppa-linux-gnu --host=hppa-linux-gnu --target=hppa-linux-gnu

Thread model: posix
gcc version 4.8.0 (Debian 4.8.0-1)


Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp6125a85bd5d0d07ff7edbf97...@phx.gbl

Bug#704020: gcc-4.8: FTBFS on hppa

[John David Anglin]

Although undocumented, adding "--disable-libatomic" to the
configure options in rules2 seems to avoid the error.

Dave

--
John David Anglindave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5152f441.4070...@bell.net

Bug#666962: Acknowledgement (libgcj-bc: Incorrect install dependencies for libgcj-bc_4.7.0-3_hppa.deb)

[John David Anglin]

Seems to be fixed in 4.7.0-4.

--
John David Anglin   dave.ang...@bell.net






--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp945bdb49911896134e848497...@phx.gbl

Bug#666162: Acknowledgement (gcc-4.7: hppa build fails: error: bits/predefs.h: No such file or directory)

[John David Anglin]

On 30-Mar-12, at 10:02 AM, Matthias Klose wrote:


I'm not sure what happens.


It didn't happen with a clean source.  Testsuite running.

--
John David Anglin   dave.ang...@bell.net






--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp6178b72ed370cd8fb5fcde97...@phx.gbl

Bug#666162: Acknowledgement (gcc-4.7: hppa build fails: error: bits/predefs.h: No such file or directory)

[John David Anglin]

On 3/30/2012 10:02 AM, Matthias Klose wrote:

we can't ship the tm.texi files
I'm surprised.  From what I see, copying of the GCC manual components is 
covered by the GNU Free Documentation License,

Version 1.3.  It's not very good if the manual can't be shipped.

--
John David Anglindave.ang...@bell.net




--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f761a5e.40...@bell.net

Bug#666162: Acknowledgement (gcc-4.7: hppa build fails: error: bits/predefs.h: No such file or directory)

[John David Anglin]

On 30-Mar-12, at 5:09 AM, Matthias Klose wrote:


On 30.03.2012 04:08, John David Anglin wrote:

For some reason, auto-detect isn't working.

Trying to enable multiarch support with --enable-multiarch also  
fails.
The variable withval is not defined in the configure hunk for -- 
enable-multiarch.


fixed in svn. the hunk in config.gcc was missing.




Different fail now:

echo timestamp > s-c-target-hooks-def-h
build/genhooks "Common Target Hook" \
 > tmp-common-target- 
hooks-def.h

gawk -f ../../src/gcc/opt-functions.awk -f ../../src/gcc/opt-read.awk \
   -f ../../src/gcc/optc-gen.awk \
   -v header_name="config.h system.h coretypes.h tm.h" <  
optionlist

> options.c
/bin/bash ../../src/gcc/../move-if-change tmp-common-target-hooks- 
def.h \
 common/common-target- 
hooks-def.h

build/genhooks -d \
../../src/gcc/doc/tm.texi.in > tmp-tm.texi
(null): No place specified to document hook TARGET_ASM_OPEN_PAREN
make[5]: *** [s-tm-texi] Error 1

I'll look at it some more tonight.

--
John David Anglin   dave.ang...@bell.net






--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp34220d7147ad534ea968d497...@phx.gbl

Bug#666162: Acknowledgement (gcc-4.7: hppa build fails: error: bits/predefs.h: No such file or directory)

[John David Anglin]

For some reason, auto-detect isn't working.

Trying to enable multiarch support with --enable-multiarch also fails.
The variable withval is not defined in the configure hunk for --enable- 
multiarch.


--
John David Anglin   dave.ang...@bell.net






--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp49bf78f11cda68c48500d397...@phx.gbl

Bug#646805: gcc-4.6: 4.6.1-16 source build fails on hppa

[John David Anglin]

On 27-Oct-11, at 8:22 AM, Matthias Klose wrote:

fixed in the vcs. please could you check if that's all which needs  
fixing? I

currently don't have access to a hppa machine anymore.


Fixed worked.  I have built and installed 4.6.2-2 using default 4.6.2  
source.


Thanks,
Dave
--
John David Anglin   dave.ang...@bell.net






--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp2693f6385361d630c8382897...@phx.gbl

Re: GCC-4.5 as the default for (at least some) architectures

[John David Anglin]

> On Tue, Mar 1, 2011 at 8:34 PM, Matthias Klose  wrote:
> > I'll make gcc-4.5 the default for (at least some) architectures within th=
> e next
> > two weeks before more transitions start. =A0GCC-4.5 is already used as th=
> e default
> > compiler for almost any other distribution, so there shouldn't be many su=
> rprises
> > on at least the common architectures. =A0About 50% of the build failures =
> exposed
> > by GCC-4.5 are fixed [1]. =A0I didn't see issues on amd64 and i386, armel
> > (although optimized for a different processor) and powerpc (some object f=
> iles
> > linked into shared libs had to be built as pic).
> >
> > As the maintainer file for the ports in GCC is a bit outdated, I'd like t=
> o ask
> > which architectures should do the switch together with the four architect=
> ures
> > mentioned above, and which not, and which ones should be better delayed, =
> or dropped.
> 
> Dave,
> 
> What's your opinion on switching to GCC 4.5 for HPPA?

Do it!  I have built glibc with it and all my recent kernel have
been with 4.5.  I'm not aware of any new issues with 4.5 and a number
of things are fixed.

For kernel builds, the following patch must be included:

2010-12-18  John David Anglin  

PR target/46915
* config/pa/pa.c (branch_to_delay_slot_p): Use next_active_insn instead
of next_real_insn.  Search forward checking for both ASM_INPUT and
ASM_OPERANDS asms until exit condition is found.
(branch_needs_nop_p): Likewise.
(use_skip_p): New function.
(output_cbranch): Use use_skip_p.
(output_bb, output_bvb): Likewise.

There are some other bug fixes in 4.6 that might need back porting.

We also need this binutils change:

2011-02-18  John David Anglin  

PR ld/12376
emulparams/hppalinux.sh (DATA_ADDR): Define.
(SHLIB_DATA_ADDR): Likewise.

This should eliminate cache issues arising from non equivalent aliasing.

Hopefully, the above will help resolve some of the build and kernel issues
that blocked squeeze.  I personally don't know what the critical blockers
were.  If they involve GCC or binutils, I'm willing to take a look.  I'm
sure a number of things have been magically fixed by updates to the
middle-end.  The biggest issue is the callee copies args on HPPA and
this differs from most other targets.

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


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110307013751.74c8c5...@hiauly1.hia.nrc.ca

Bug#588391: gcc-4.4: please automatically use -ffunction-sections

[John David Anglin]

> On Fri, Aug 6, 2010 at 11:03 AM, Matthias Klose  wrote:
> > On 06.08.2010 00:58, brian m. carlson wrote:
> >>
> >> On Thu, Aug 05, 2010 at 10:59:18PM +0200, Matthias Klose wrote:
> >>>
> >>> On 08.07.2010 01:42, brian m. carlson wrote:
> 
>  Package: gcc-4.4
>  Version: 4.4.4-6
>  Severity: wishlist
> 
>  Because the ELF ABI for hppa requires relative jumps which are limited
>  to 17 bits[0], programs frequently require the use of
>  -ffunction-sections. =A0It would be preferable if (on hppa or otherwis=
> e)
>  -ffunction-sections were implied by -fPIC when otherwise gcc would
>  generate text sections that are too large. =A0After all, there's reall=
> y no
>  reason to generate .o files that are, for all practical purposes,
>  useless. =A0It would also make numerous package maintainers and hppa
>  porters very happy, I suspect.
> 
>  [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D558999#15
> >>>
> >>> as this specific example shows, -ffunction-sections isn't enough,
> >>> but -mlong-calls is needed.
> >>
> >> In that particular instance -mlong-calls is needed, but in the general
> >> case it appears not to be, judging from the numerous cases where only
> >> -ffunction-sections (and not -mlong-calls) is in use already in the
> >> archive. =A0For example, #160538.
> >>
> >> My wishlist request still stands.
> >
> > waiting for feedback form the HPPA porters.
> 
> To make this automatic would require a lot more intelligence in the
> linker. My suggestion is to change the specs such that -fPIC implies
> -ffunction-sections.

The linker suggestion to use -ffunction-sections is somewhat misleading.
I suspect that problems arise in C++ and computer generated code due to
massive inlining resulting in very large objects and overflow of the stub
table.  If the stub table overflows, -ffunction-sections isn't going to
help.  There are ways to limit inlining.

GCC automatically switches to long calls when the distance to the
stub table gets too large.  However, this fails if objects are combined
and relinked.

The 17-bit offset is a PA 1.X limitation and has nothing to do with
ELF.  The 17-bit branches provide the shortest calling sequence for
functions in most circumstances.  With PA 2.0, the offset for calls
changes to 21 bits.  However, there still could be problems with
thunks since they use an unconditional branch with a 17-bit offset.

The whole approach stems from the hpux runtime design.  Probably, it
would have been better under linux to allocate enough space for a long
call, and have the linker optimize the type of call.

I don't think -fPIC and -ffunction-sections have any relationship.
Possibly, -function-sections should be the default.  Another possibility
is to start a new unnamed .text section at the beginning of every
function when -ffunction-sections isn't specified.  Effectively, this
is what happens under hpux.  A new subspace is started at the beginning
of every function.  It does mean that it is not possible to switch sections
mid function.  So, hot and cold sections are not possible.  However,
we don't support hot and cold sections because it messes with branch
distance calculations.

The whole issue is quite complicated and I don't think any simple
change will resolve all the problems.

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



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100806225244.5e2ec4...@hiauly1.hia.nrc.ca

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

On Mon, 23 Nov 2009, Carlos O'Donell wrote:

> I can successfully run apt-get with the new libstdc++6 that I just built.
> 
> The testsuite result is cleaner:
> ~~~
> FAIL: 29_atomics/atomic_flag/clear/1.c execution test
> FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
> 
> === libstdc++ Summary ===
> 
> # of expected passes5880
> # of unexpected failures2
> # of expected failures  80
> # of unsupported tests  331

There are a couple of issues wrt running the libstdc++6 testsuite:

1) The locale tests require a certain minimal set of foreign locales
to run.  Simplest may be to install all locales.

2) In order to use the generic code using the the atomic builtins,
a patch is needed.  I have recently tested the attached two changes
provided by Matthias.  In addition, the undef and define for LIB_SPEC
in pa-linux.h should be removed.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)
# DP: Do link tests to check for the atomic builtins

2009-05-03  Paolo Carlini  

* acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): Do link tests when
possible.
* configure: Regenerate.

Index: acinclude.m4
===
--- a/src/libstdc++-v3/acinclude.m4 (revision 147071)
+++ b/src/libstdc++-v3/acinclude.m4 (working copy)
@@ -2429,8 +2429,7 @@
 dnl that are used should be checked.
 dnl
 dnl Note:
-dnl libgomp and libgfortran do this with a link test, instead of an asm test.
-dnl see: CHECK_SYNC_FETCH_AND_ADD
+dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD.
 dnl
 dnl Defines:
 dnl  _GLIBCXX_ATOMIC_BUILTINS_1 
@@ -2442,12 +2441,110 @@
   AC_LANG_SAVE
   AC_LANG_CPLUSPLUS
   old_CXXFLAGS="$CXXFLAGS"
-  
+
+  # Do link tests if possible, instead asm tests.
+  if test x$gcc_no_link != xyes; then  
+
+  # Can do link tests.
+
+  CXXFLAGS="$CXXFLAGS -fno-exceptions"
+
+  AC_MSG_CHECKING([for atomic builtins for bool])
+  AC_CACHE_VAL(glibcxx_cv_atomic_bool, [
+AC_TRY_LINK(
+  [ ],
+  [typedef bool atomic_type;
+   atomic_type c1;
+   atomic_type c2;
+   const atomic_type c3(0);
+   __sync_fetch_and_add(&c1, c2);
+   __sync_val_compare_and_swap(&c1, c3, c2);
+   __sync_lock_test_and_set(&c1, c3);
+   __sync_lock_release(&c1);
+   __sync_synchronize();],
+  [glibcxx_cv_atomic_bool=yes],
+  [glibcxx_cv_atomic_bool=no])
+  ])
+  if test $glibcxx_cv_atomic_bool = yes; then
+AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
+  [Define if builtin atomic operations for bool are supported on this 
host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_bool)
+
+  AC_MSG_CHECKING([for atomic builtins for short])
+  AC_CACHE_VAL(glibcxx_cv_atomic_short, [
+AC_TRY_LINK(
+  [ ],
+  [typedef short atomic_type;
+   atomic_type c1;
+   atomic_type c2;
+   const atomic_type c3(0);
+   __sync_fetch_and_add(&c1, c2);
+   __sync_val_compare_and_swap(&c1, c3, c2);
+   __sync_lock_test_and_set(&c1, c3);
+   __sync_lock_release(&c1);
+   __sync_synchronize();],
+  [glibcxx_cv_atomic_short=yes],
+  [glibcxx_cv_atomic_short=no])
+  ])
+  if test $glibcxx_cv_atomic_short = yes; then
+AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
+  [Define if builtin atomic operations for short are supported on this 
host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_short)
+
+  AC_MSG_CHECKING([for atomic builtins for int])
+  AC_CACHE_VAL(glibcxx_cv_atomic_int, [
+AC_TRY_LINK(
+  [ ],
+  [typedef int atomic_type;
+   atomic_type c1;
+   atomic_type c2;
+   const atomic_type c3(0);
+   __sync_fetch_and_add(&c1, c2);
+   __sync_val_compare_and_swap(&c1, c3, c2);
+   __sync_lock_test_and_set(&c1, c3);
+   __sync_lock_release(&c1);
+   __sync_synchronize();],
+  [glibcxx_cv_atomic_int=yes],
+  [glibcxx_cv_atomic_int=no])
+  ])
+  if test $glibcxx_cv_atomic_int = yes; then
+AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
+  [Define if builtin atomic operations for int are supported on this 
host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_int)
+
+  AC_MSG_CHECKING([for atomic builtins for long long])
+  AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [
+AC_TRY_LINK(
+  [ ],
+  [typedef long long atomic_type;
+   atomic_type c1;
+   atomic_type c2;
+   const atomic_type c3(0);
+   __sync_fetch_and_add(&c1, c2);
+   __sync_val_compare_and_swap(&c1, c3, c2);
+   __sync_lock_test_and_set(&c1, c3);
+   __sync_lock_release(&c1);
+   __sync_synchronize();],
+  [glibcxx_cv_atomic_long_long=yes],
+  [glibcxx_cv_atomic_long_long=no])
+  ])
+  if test $glibcxx_cv_atomic_long_long = yes; then
+AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
+  [Define if builtin atomic operations f

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

> 
> On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell
>  wrote:
> > This happens because the original locale object was created at address
> > 0xbff01c20. However, when apt-get calls "std::basic_ios > std::char_traits >::init" it passes in the address 0xbff01c18.
> > So we went from a constructor using this as 0xbff01c20, to eventually
> > passing this as 0xbff01c18 to a template. The pointer to the
> > std::ios_base object is now off by 8 bytes and this causes the crash.
> >
> > What happened here? Why does ReadConfigFile() think that the object is
> > in a different location?
> >
> > Any hints on how to track this down?

The ptype command might help to display the object and to see what's
changed.

> The problem is here, we read 0xa8 here from libstdc++6:
> 
> (gdb) x/16x $ret0 - 0xc
> 0x40437778 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>:
> 0x00a8  0x  0x40437b30  0x401b2b96
> 0x40437788 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16>:
>  0x401b2b9e  0xff58  0xff58  0x40437b30
> 0x40437798 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32>:
>  0x401b2ba6  0x401b2bae  0x  0x40437834
> 
> Then we add this offset to the base location of the object on the
> stack and we compute 0xbff01c18, instead of computing 0xbff01c20 as we
> would expect.
> 
> It looks like the layout of the object in libstdc++.so.6 has changed,
> my guess is that the changes I made to the locking types in glibc have
> caused the layout to be perturbed.
> 
> While I set out the glibc types exactly as before (binary compatible),
> the alignment restrictions were changed subtly.

Excellent debugging!

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



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

> > The problem appears to have gone away with head.  I don't see it with
> > hpux.
> > 
> 
> Note that latest version of gcc 4.4 in Debian is built with
> --disable-libstdcxx-pch, but the segfault is this present :(

Personally, I don't believe the segfault is related to the FAILs
seen in the libstdc++ testsuite.  As you showed, there is an ABI
change in the library depending on libc version.  Someone needs
to generate a backtrace so that we can get some idea what's happening.

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



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

> 
> On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno  wrote:
> >
> > I confirm, it's what I see in the testsuite log:
> >
> > | 77
> > | __signbitl
> > | version status: incompatible
> > | GLIBCXX_3.4
> > | type: function
> > | status: added
> 
> If __signbitl is the only failure in the abi_check, then that's easy
> to fix, the testsuite needs to be updated.

The fail is somewhat puzzling because the problem is supposed fixed
in the 4.4 branch.

> With cloog/ppl disabled I still get 7 testsuite failures, so I'll have
> to dig into each failure tommorow and see what's wrong.
> 
> ~~~
> Running target unix
> FAIL: abi_check
> FAIL: 26_numerics/complex/13450.cc (test for excess errors)
> UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce
> executable
> FAIL: 26_numerics/complex/pow.cc (test for excess errors)
> UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce 
> executable
> XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test
> for excess errors)
> FAIL: 29_atomics/atomic_flag/clear/1.c execution test
> FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
> FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess 
> errors)
> FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)
> UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation
> failed to produce executable

Try adding --disable-libstdcxx-pch as mentioned earlier in this thread.
This is PR 39355: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

Good luck in debugging this bug!  I was not able to determine the
actual cause.  It appears GCC's internal data are somewhat corrupt
when the pch header files are generated.  This causes various tests
to ICE when compiled with the pch headers.

The problem appears to have gone away with head.  I don't see it with
hpux.

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



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

> On 08.11.2009 21:38, John David Anglin wrote:
> >> test results for 4.4.2-1:
> >> http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
> >> for 4.4.2-2:
> >> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
> >>
> >> there are some differences, which are not seen in Dave's build:
> >> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html
> >
> > For a release, I wouldn't use cloog/ppl.  It seems to cause some
> > loop optimization bugs.
> 
> does this really hurt, unless the loop opts are used?

Compare above with
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00812.html

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



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

> On 08.11.2009 21:38, John David Anglin wrote:
> >> test results for 4.4.2-1:
> >> http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
> >> for 4.4.2-2:
> >> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
> >>
> >> there are some differences, which are not seen in Dave's build:
> >> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html
> >
> > For a release, I wouldn't use cloog/ppl.  It seems to cause some
> > loop optimization bugs.
> 
> does this really hurt, unless the loop opts are used?

The testsuite fails that seem related to this are:
FAIL: libgomp.c/omp-loop03.c execution test
FAIL: libgomp.c++/loop-3.C  -O  execution test
FAIL: 29_atomics/atomic_flag/clear/1.c execution test
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors)
FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)

and possibly

FAIL: abi_check

> > There's also an unresolved issue with
> > pch on the 4.4 branch.  I usually configure with --disable-libstdcxx-pch
> > on the 4.4 branch.  The problem seems to be fixed on head.
> 
> ok, I'll add this for hppa.

The testsuite fails related to the pch bug are:
FAIL: 26_numerics/complex/13450.cc (test for excess errors)
FAIL: 26_numerics/complex/pow.cc (test for excess errors)

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



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

> test results for 4.4.2-1:
>http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
> for 4.4.2-2:
>http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
> 
> there are some differences, which are not seen in Dave's build:
>http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html

For a release, I wouldn't use cloog/ppl.  It seems to cause some
loop optimization bugs.  There's also an unresolved issue with
pch on the 4.4 branch.  I usually configure with --disable-libstdcxx-pch
on the 4.4 branch.  The problem seems to be fixed on head.

> there are some parisc scpecific changes:
> 
> 2009-10-23  John David Anglin  
> 
>  Backport from mainline:
>  2009-08-19  John David Anglin  
> 
>  * pa.md (reload_inhi, reload_outhi, reload_inqi, reload_outqi): New
>  patterns.
>  * pa.c (emit_move_sequence): Check if address of operand1 is valid
>  for mode mode of operand0 when doing secondary reload for SAR.
> 
> 2009-10-20  John David Anglin  
> 
>  Backport from mainline:
>  2009-10-15  John David Anglin  
> 
>  PR target/41702
>  * pa.md (casesi): Use sign extended index in call to
>  gen_casesi64p.
>  (casesi64p): Update pattern to reflect above.

I doubt either of these is the problem.  The latter is specific to
hppa64.  The former is to fix an ICE compiling recent linux kernels.

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



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#541842: libcloog-ppl-dev: Missing development headers

[John David Anglin]

Package: libcloog-ppl-dev
Version: 0.15-2
Severity: normal

In config.log for GCC 4.5, I see the following:

configure:5356: checking for correct version of CLooG
configure:5378: gcc -c -g -O2  conftest.c >&5
In file included from conftest.c:12:
/usr/include/cloog/cloog.h:47:30: error: polylib/missing.h: No such file or dire
ctory
In file included from /usr/include/cloog/cloog.h:48,
 from conftest.c:12:
/usr/include/cloog/polylib_backend.h:57: error: expected specifier-qualifier-lis
t before 'Polyhedron'
In file included from /usr/include/cloog/cloog.h:91,
 from conftest.c:12:
/usr/include/cloog/options.h:118: error: expected ')' before '*' token
/usr/include/cloog/options.h:130: error: expected declaration specifiers or 
'...' before 'FILE'
...

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (650, 'testing')
Architecture: hppa (parisc64)

Kernel: Linux 2.6.30.4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages libcloog-ppl-dev depends on:
ii  libc6 2.9-23 GNU C Library: Shared libraries
ii  libcloog-ppl0 0.15-2 the Chunky Loop Generator (runtime
ii  libgmp3-dev   2:4.3.1+dfsg-3 Multiprecision arithmetic library 
ii  libgmp3c2 2:4.3.1+dfsg-3 Multiprecision arithmetic library
ii  libgmpxx4ldbl 2:4.3.1+dfsg-3 Multiprecision arithmetic library 
ii  libppl-c2 0.10.2-2   Parma Polyhedra Library (C interfa
ii  libppl0.10-dev0.10.2-2   Parma Polyhedra Library (developme
ii  libppl7   0.10.2-2   Parma Polyhedra Library (runtime l
ii  libstdc++64.4.1-1The GNU Standard C++ Library v3

libcloog-ppl-dev recommends no packages.

libcloog-ppl-dev suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#494962: Debian bug #494962: /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo ../../sinfo.h

[John David Anglin]

> Dave, now that 4.3.1-2 has been built on hppa, could you try to
> reproduce the problem?

Yes.  At the moment, the 4.4 tree is a mess with a number of issues
affecting hppa.  Have to get EH exception support working again.

Given the build history that you showed, I'm somewhat skeptical that
rebuilding will fix the problem.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#494962: /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo ../../sinfo.h

[John David Anglin]

> It would be nice if you could investigate the bug further. Does it happen on
> other architectures?

Investigation is difficult.  The problem only occurs under make.
It is possible to successfully run the program that segfaulted
under gdb.  So, there must be a problem with the environment
in the gnattools.  The backtrace in the core dump wasn't useful.
Increasing the stack limit for processes didn't help.

I recall a similar problem under hpux,
.  Do you know
which base compiler was used to build 4.3.1-1?

It may be that the issue is still latent even with a rebuild.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#494962: /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo ../../sinfo.h

[John David Anglin]

Package: gnat-4.3
Version: 4.3.1-1
Severity: important

The gnat-4.3 package (4.3.1-1) is miscompiled.  As a result, building
GCC 4.4.0 from current svn sources failes with a segmentation fault.
See  for more 
details.

The problem can be corrected by rebuilding GCC 4.3.1 with 4.3.1-1.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: hppa (parisc)

Kernel: Linux 2.6.22.19
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages gnat-4.3 depends on:
ii  gcc-4.3   4.3.1-2The GNU C compiler
ii  gnat-4.3-base 4.3.1-1The GNU Compiler Collection (gnat 
ii  libc6 2.7-13 GNU C Library: Shared libraries
ii  libc6-dev 2.7-13 GNU C Library: Development Librari
ii  libgcc4   4.3.1-2GCC support library
ii  libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library
ii  libgnat-4.3   4.3.1-1Runtime library for GNU Ada applic
ii  libgnatprj4.3 4.3.1-1GNU Ada Project Manager
ii  libgnatvsn4.3 4.3.1-1GNU Ada compiler version library
ii  libmpfr1ldbl  2.3.1.dfsg.1-2 multiple precision floating-point 

gnat-4.3 recommends no packages.

Versions of packages gnat-4.3 suggests:
pn  ada-reference-manual   (no description available)
pn  gnat-4.3-doc   (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [alpha, hppa] GCC-4.3 as the default compilers for lenny?

[John David Anglin]

> On Wed, Mar 26, 2008 at 10:20:35AM -0600, Grant Grundler wrote:
> > Another gcc problem report:
> > 
> > That past weekend I built the latest parisc-2.6-25-rc6 kernel from
> > Kyle's tree using gcc-4.1, gcc-4.2, and gcc-4.3. All three kernels
> > booted but the networking only worked for gcc-4.1 kernel.
> 
> Sorry, I just realized I didn't mention the gcc versions are whatever is
> currently in "Debian testing" for parisc.

I would look carefully to see if the newer compilers generate warnings
that need fixing.

I've been using 4.1 for my recent builds.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching

[John David Anglin]

> Ok, coming back to the question of the system compiler on hppa for
> etch. Assuming that hppa does want to do that:
> 
> - is glibc buildable with gcc-4.1 on hppa?

As far as I know, there's no new problems using 4.1 instead of 4.0.  See
http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028894.html
and test results for a gcc 4.2.0 build using this glibc build
http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028918.html

> - libstdc++6 would need to conflict with libgcc2, which seems to be
>   doable, but then rules out g++-3.4 and g++-4.0 as a fallback
>   solution, where g++-4.1 fails.

True.

> - is libffi hit by the ABI change as well?

No.  It's not affected because it doesn't support complex types.

I have one libffi fix that's not yet in 4.2.0 that fixes the remaining
Java testsuite failures.  I haven't tested a backport to 4.1.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching

[John David Anglin]

> Er, no; we're talking about official Debian packages here, and the
> libstdc++.so.6 in Debian is now from gcc-4.1.  The problem is precisely that
> GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting
> in the double libgcc_s problem.

Then, you must build *eveything* for hppa with gcc-4.1 or later.

Unfortunately, there's an ABI break.  Mixing libraries compiled with
4.0 or earlier with libraries compiled with 4.1 or later is just going
to cause unnecessary problems.   3.3 uses libstdc++.so.5, so you
avoid the double libgcc_s problem building GMP.  However, you still
have the ABI change affecting the passing and return of complex types.

At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any
other gcc libraries built with 4.1 or later need glibc built with 4.1
to function correctly because of the various complex functions in
the math library.

I think there's a dynamic loader bug here as well.  I'm just
guessing but I think the double libgcc_s problem causes a problem
with the handling of .eh_frame data.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA

[John David Anglin]

> Is this acutally decided?  Is it likely to happen soon, or should I
> build GMP with gcc 3.3 (which doesn't exhibit the problem) in the
> short term?

For now, I suggest that you remove gcc-4.1 from your build system.
Then, GMP should build fine with 4.0.  You might have to reinstall
4.0.

As far as I can tell, EH support breaks when two different versions
of libgcc_s are linked into an application.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA

[John David Anglin]

> Yes, we do, but
> 
> $ ls -l /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so
> lrwxr-xr-x 1 root root 23 Apr  6 02:08 
> /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so -> ../../../libstdc++.so.6

Oh, I was thinking there were separate libraries for each GCC version.
I've had to live with this for some time using hpux.

> we can only have one libstdc++.so.6 installed. that's currently the
> library from 4.1. So maybe we need to bump the soversion of libstdc++
> on hppa?

To me, that seems too complicated.  It's not just libstdc++.so.6 but
potentially every shared library built with 4.1 or later needs a bump.

The simplest approach is to make GCC 4.1 the default and remove 4.0
and earlier.  Then, gradually rebuild everthing with 4.1.  There have
been reports on the gcc list that this has been reasonably successful.

I imagine that some will complain about losing their favorite GCC
version.  The issues with C are less severe because of the libgcc_s
version bump.  Old versions will generate code that's incompatible
with the complex math routines in libc6 but they should otherwise
work.  I think for kernel building it's useful to keep old versions,
but not for much else.  Thus, the compromise may be to keep old
versions of C and drop all the other languages.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA

[John David Anglin]

> > [EMAIL PROTECTED]:~/gmp-4.2.dfsg/tests/cxx$ g++ -Wall test-throw.cc && 
> > ./a.out
> > /usr/bin/ld: warning: libgcc_s.so.4, needed by 
> > /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so, may conflict with 
> > libgcc_s.so.2

I'm puzzled about this.  It seems like libstdc++ for GCC 4.0.3 was
built using GCC 4.1 or latter.  In my 4.0.3 build, I see:

[EMAIL PROTECTED]:~/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src/.libs$ ldd 
libstdc++.so
libm.so.6 => /lib/libm.so.6 (0x40643000)
libgcc_s.so.2 => /lib/libgcc_s.so.2 (0x4034a000)
libc.so.6 => /lib/libc.so.6 (0x40a57000)
/lib/ld.so.1 (0x41252000)

But:

[EMAIL PROTECTED]:~/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src/.libs$ ldd 
/usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so
libm.so.6 => /lib/libm.so.6 (0x40243000)
libgcc_s.so.4 => /lib/libgcc_s.so.4 (0x40746000)
libc.so.6 => /lib/libc.so.6 (0x40a57000)
/lib/ld.so.1 (0x41252000)

You need to build 4.0.3 and associated libraries with 4.0.3.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA

[John David Anglin]

> On Sat, Apr 22, 2006 at 10:00:04AM +0200, Matthias Klose wrote:
> > $ ldd a.out
> > libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x40575000)
> > libm.so.6 =3D> /lib/libm.so.6 (0x4046e000)
> > libgcc_s.so.2 =3D> /lib/libgcc_s.so.2 (0x40068000)
> > libc.so.6 =3D> /lib/libc.so.6 (0x4074b000)
> > libgcc_s.so.4 =3D> /lib/libgcc_s.so.4 (0x40015000)
> > /lib/ld.so.1 (0x400e1000)
> 
> > We end up with both libgcc_s.so.2 and libgcc_s.so.4 linked.  Is there
> > a solution other than making gcc-4.1/g++-4.1 the default and
> > rebuilding the libstdc++6 dependent packages with binary NMU's?
> 
> I guess having gcc-4.0 link against libgcc4 is out of the question?

Doing so is not a good idea, but it's only going to break numeric
applications using complex numbers and possibly vectors.

The calling conventions for passing complex values was changed between
4.0 and 4.1 when it was discovered that it didn't conform to the runtime
documentation.  Support for complex and vector objects was added to GCC
some time ago.  However noone noticed that these values weren't being
passed correctly...

The change affects the routines __muldc3, __mulsc3, __divdc3 and __divsc3
in libgcc_s.  It also affects any package/library using complex numbers,
including glibc since the registers used for passing the first few
arguments and the return value have changed.  Particularly, complex
floats are no longer passed in the floating registers.

I think the approach suggested by Matthias is ultimately the only
viable solution but the impact is broader than the libstdc++6 dependent
packages.  The situation is similar to that when DWARF EH support was
introduced.  The only other option that I can see is to delay 4.1.
However, I would like 4.1 to become the default.

For the most part, the passing of complex values in 4.0 and earlier
is internally self-consistent (there's a minor incompatibility between
PA 1.0 code and PA 1.1 code due to the fact that the left and right
halves of floating-point registers are not independently accessible
when generating PA 1.0 code).

I recognized that this was going to cause pain, and brought the matter
up for discussion on the parisc-linux list a few months ago.  There
wasn't much in the way of comments for or against.  In the end, I
decided it was probably better to make the change in 4.1 and let time
smooth over the difficulties.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#352529: [hppa] internal compiler error: in reload_cse_simplify_operands,

[John David Anglin]

> >  While investigating gstreamer0.10-ffmpeg's build failure under hppa[1],
> >  I received the following error from gcc:
> > 
> >  gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libavutil -DHAVE_AV_CONFIG_H=1 -Wall 
> > -Wno-switch -g -O2 -MT mpegaudiodec.lo -MD -MP -MF .deps/mpegaudiodec.Tpo 
> > -c mpegaudiodec.c  -fPIC -DPIC -o .libs/mpegaudiodec.o
> > mpegaudiodec.c: In function 'mp_decode_frame':
> > mpegaudiodec.c:2445: warning: pointer targets in passing argument 4 of 
> > 'ff_mpa_synth_filter' differ in signedness
> > mpegaudiodec.c: In function 'ff_mpa_synth_filter':
> > mpegaudiodec.c:920: error: insn does not satisfy its constraints:
> > (insn 4924 2540 2542 4 mpegaudiodec.c:888 (set (reg:HI 70 %fr23 [1852])
> > (reg:HI 1 %r1)) 53 {*pa.md:2926} (nil)
> > (nil))
> > mpegaudiodec.c:920: internal compiler error: in 
> > reload_cse_simplify_operands, at postreload.c:391

Would you please file a PR?

The program compiles with gcc-3.4, but fails with 4.0 and 4.1 (didn't
try head).  At first glance, this seems like a reload bug.

The current define for HARD_REGNO_MODE_OK should stop reload from
trying to put a HImode value into a floating-point register.  We don't
support HImode moves between general and floating-point registers as
they are more expensive than using a stack temporary.  Looking at the
greg RTL output, I see that reload is just using %fr23 as temporary
storage (i.e., the value is copied back to a general register a few
instructions later).

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#352529: [hppa] internal compiler error: in reload_cse_simplify_operands,

[John David Anglin]

> >  While investigating gstreamer0.10-ffmpeg's build failure under hppa[1],
> >  I received the following error from gcc:
> > 
> >  gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libavutil -DHAVE_AV_CONFIG_H=1 -Wall 
> > -Wno-switch -g -O2 -MT mpegaudiodec.lo -MD -MP -MF .deps/mpegaudiodec.Tpo 
> > -c mpegaudiodec.c  -fPIC -DPIC -o .libs/mpegaudiodec.o
> > mpegaudiodec.c: In function 'mp_decode_frame':
> > mpegaudiodec.c:2445: warning: pointer targets in passing argument 4 of 
> > 'ff_mpa_synth_filter' differ in signedness
> > mpegaudiodec.c: In function 'ff_mpa_synth_filter':
> > mpegaudiodec.c:920: error: insn does not satisfy its constraints:
> > (insn 4924 2540 2542 4 mpegaudiodec.c:888 (set (reg:HI 70 %fr23 [1852])
> > (reg:HI 1 %r1)) 53 {*pa.md:2926} (nil)
> > (nil))
> > mpegaudiodec.c:920: internal compiler error: in 
> > reload_cse_simplify_operands, at postreload.c:391

Could someone send the preprocessed source for mpegaudiodec.c?

The problem might have been introduced by this change:

2006-01-10  John David Anglin  <[EMAIL PROTECTED]>

PR target/20754
* pa.md: Create separate 32 and 64-bit move patterns for SI, DI, SF
and DF modes.  Add alternatives to copy between general and floating
point registers to the 32-bit patterns.
* pa-64.h (SECONDARY_MEMORY_NEEDED_RTX): Delete undefine.
* pa.h (SECONDARY_MEMORY_NEEDED_RTX): Delete define.
(SECONDARY_MEMORY_NEEDED): Secondary memory is only needed when
generating 64-bit code.
* pa.c (output_move_double): Handle copies between general and
floating registers.

I need to understand if we need to support HImode and QImode moves between
the general and floating point registers.  You can't do anything with an
QImode or HImode value in a floating-point register, so it's not obvious
why this is needed.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#342545: [parisc-linux] Re: qt-x11-free build fails

[John David Anglin]

> There isn't a lot of info in #342545.  However, I suspect from the
> following comment
> 
> > It would be nice if somebody fluent with hppa assembly can tell us if 
> 
> >   fldw -10(,sp),fr23
> 
> that this is the same bug as reported here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754.

Changed my mind based on the discussion in
http://lists.debian.org/debian-hppa/2006/01/msg1.html.  The only
way that the above instruction can cause an invalid exception is

  The current instruction is a load of the destination register of
  a pending, trapping instruction (see page 10-5 of arch, delayed
  traps).

The instruction can cause the usual memory faults (i.e., check value
in sp).  In either case, the real problem is somewhere else.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#342545: [parisc-linux] Re: qt-x11-free build fails

[John David Anglin]

> On Sat, Jan 07, 2006 at 01:05:11AM -0800, Steve Langasek wrote:
> > Grant, thank you for your work to date on this bug.  (BTW, it would be
> > helpful if you would follow up to bug #342545 on libgcc2, instead of bug
> > #341675 which is filed against just one of the many packages affected by
> > it).

There isn't a lot of info in #342545.  However, I suspect from the
following comment

> It would be nice if somebody fluent with hppa assembly can tell us if 

>   fldw -10(,sp),fr23

that this is the same bug as reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#321785: fakeroot: segfaults on [hppa]

[John David Anglin]

> > no, it's not fakeroot, it's make segfaulting ...
> [...]
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 16384 (LWP 16911)]
> > 0x4091fd20 in __canonicalize_funcptr_for_compare () from 
> > /lib/libpthread.so.0
> > (gdb) bt
> > #0  0x4091fd20 in __canonicalize_funcptr_for_compare ()
> >from /lib/libpthread.so.0
> > #1  0x4091b424 in sigaction () from /lib/libpthread.so.0
> > #2  0x405cc950 in sigaction () from /lib/libc.so.6
> > #3  0x405cc748 in ssignal () from /lib/libc.so.6
> > #4  0x0001d690 in main ()
> > (gdb)
> 
> Confirmed. We are passing a function pointer with a value of -2 into
> __cffc, which should not happen...

I've posted a candidate gcc fix here:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00923.html

As I mentioned earlier today to Randolph, I think there should possibly
be a pa specific implementation of sigaction that avoids doing function
pointer canonicalization.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#200619: [parisc-linux] Re: Bug#200619: gcc: parisc: compiling dietlibc-dev with -Os caus

[John David Anglin]

> This doesn't appear to be a gcc problem.  The register %r3 is saved
> on the stack in __stdio_init_file_nothreads.  The stack location
> is clobbered by the fstat syscall.
> 
> > > +  {
> > > +struct stat st;
> > > +fstat(fd,&st);
> 
> At the fstat call we have the following values:
> 
> Breakpoint 11, 0x00010b10 in __stdio_init_file_nothreads ()

Carlos O'Donell and myself looked at this problem this afternoon.  This
is a dietlib problem.  Dietlib is not using the correct kernel_stat
mapping for parisc.  They appear to be using the i386 mapping.  They
need to look at /libc/sysdeps/unix/sysv/linux/xstatconv.c and the
hppa/kernel_stat.h header in glibc.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Bug#200619: gcc: parisc: compiling dietlibc-dev with -Os caus

[John David Anglin]

> [CC to jda]
> 
> Please can you recheck with a current gcc snapshot (from the
> gcc-snapshot package) and attach the preprocessed source?

This doesn't appear to be a gcc problem.  The register %r3 is saved
on the stack in __stdio_init_file_nothreads.  The stack location
is clobbered by the fstat syscall.

> > +  {
> > +struct stat st;
> > +fstat(fd,&st);

At the fstat call we have the following values:

Breakpoint 11, 0x00010b10 in __stdio_init_file_nothreads ()
(gdb) printf "0x%x\n",*0xfaf005a8
0xfaf004c0
(gdb) printf "0x%x\n",$r25
0xfaf00548
(gdb) printf "0x%x\n",$r26
0x5
(gdb) c
Continuing.

Breakpoint 12, 0x00010b18 in __stdio_init_file_nothreads ()
(gdb) printf "0x%x\n",*0xfaf005a8
0x0

0xfaf005a8 is the location where %r3 was saved.  The break is at the
fstat syscall.  Non of the user space code in the call patch affects
the above location, so the bug must be in the kernel.

I looked at this on a 64-bit kernel:

[EMAIL PROTECTED]:~/dietlibc-0.22.orig$ uname -a
Linux gsyprf11.external.hp.com 2.4.21-pa6 #23 Mon Jul 14 23:11:39 PDT 2003 
parisc64 GNU/Linux

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: [hppa] binutils will not build shared libraries with external deps?

[John David Anglin]

> On Mon, Jun 02, 2003 at 05:10:38PM -0400, John David Anglin wrote:
> > tmpdir/sh1p.o(.text+0x0): In function `shlib_mainvar':
> > /home/dave/binutils-2.14.90/src/ld/testsuite/ld-elfvsb/sh1.c:32: undefined 
> > refer
> > ence to `mainvar'
> > ...
> > FAIL: visibility (hidden)
> 
> Fixing this one probably requires porting some of the recent changes
> I made for x86 and ppc to hppa.  See SYMBOL_REFERENCES_LOCAL and
> SYMBOL_CALLS_LOCAL.

Nope.  This was caused by the previous bug and the change to using
gcc as the driver program to run the newly built linker.  Using `-B'
doesn't override the GCC configure option `--with-ld='.  The same
problem occurs with using gcc to run the newly build assembler
(`-B' doesn't override `--with-as=').  I think we need to revert
to the previous technique for running these tools in the ld
testsuite.

To work around this problem, I installed the newly built tools.
This fixed most of the ld FAILS but we are still left with the
following:

Running /home/dave/binutils-2.14.90/src/ld/testsuite/ld-elfvsb/elfvsb.exp ...
FAIL: visibility (hidden_undef_def)
FAIL: visibility (hidden_undef_def) (PIC main)
FAIL: visibility (hidden_weak)
FAIL: visibility (hidden_weak) (PIC main)
FAIL: visibility (protected_weak)
FAIL: visibility (protected_weak) (PIC main)
Running /home/dave/binutils-2.14.90/src/ld/testsuite/ld-elfweak/elfweak.exp ...
FAIL: ELF weak func first DSO
FAIL: ELF weak func last DSO
FAIL: ELF weak data first DSO
FAIL: ELF weak data last DSO
FAIL: ELF weak data first DSO common
FAIL: ELF weak data last DSO common

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: [hppa] binutils will not build shared libraries with external deps?

[John David Anglin]

> On Mon, May 26, 2003 at 10:22:51PM -0700, Randolph Chung wrote:
> > [EMAIL PROTECTED]:~$ gcc -shared -fPIC -o blah.so blah.c
> > /tmp/ccC3fZeH.o(.text+0x1c): In function `call_foo':
> > : undefined reference to `foo'
> 
> This should fix it.  Would someone mind applying it for me?  I'm in
> transit at the moment and internet access is slow and flaky.  2.14
> branch too, I guess.
> 
>   * elf32-hppa.c (elf32_hppa_relocate_section): Delete bogus
>   undefined_symbol call.

I'm not fully up to speed on this but there still appear to be problems
with undefined symbols in shared libraries:

gcc -L/home/dave/binutils-2.14.90/objdir/ld -g -g -O2  -DHIDDEN_TEST -fpic -B/ho
me/dave/binutils-2.14.90/objdir/ld/tmpdir/gas/ -I/home/dave/binutils-2.14.90/src
/ld/testsuite/ld-elfvsb -g -O2  -c /home/dave/binutils-2.14.90/src/ld/testsuite/
ld-elfvsb/sh1.c -o tmpdir/sh1p.o
gcc -L/home/dave/binutils-2.14.90/objdir/ld -g -g -O2  -DHIDDEN_TEST -fpic -B/ho
me/dave/binutils-2.14.90/objdir/ld/tmpdir/gas/ -I/home/dave/binutils-2.14.90/src
/ld/testsuite/ld-elfvsb -g -O2  -c /home/dave/binutils-2.14.90/src/ld/testsuite/
ld-elfvsb/sh2.c -o tmpdir/sh2p.o
gcc -L/home/dave/binutils-2.14.90/objdir/ld -B/home/dave/binutils-2.14.90/objdir
/ld/tmpdir/ld/ -L/home/dave/opt/gnu/hppa-linux/lib -L/home/dave/opt/gnu/lib -L/u
sr/local/lib -L/lib -L/usr/lib  -o tmpdir/vp.so -shared  tmpdir/sh1p.o tmpdir/sh
2p.o
tmpdir/sh1p.o(.text+0x0): In function `shlib_mainvar':
/home/dave/binutils-2.14.90/src/ld/testsuite/ld-elfvsb/sh1.c:32: undefined refer
ence to `mainvar'
...
FAIL: visibility (hidden)

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] gcc-3.3 configuration

[John David Anglin]

> On Mer, 2003-05-21 at 01:08, Matthew Wilcox wrote:
> > I'm not sure it's my call to make; I can see arguments on both sides.
> 
> Thats at least one of the reasons. Reputation capital is a wonderous
> thing. Accept reality, you are the Linus of parisc Linux like it or not
> 8)

I agree.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> Randolph Chung writes:
> > In reference to a message from Matthias Klose, dated Mar 01:
> > > Matthias Klose writes:
> > > > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > > > code due to the changed exception handling (now DWARF2 based). As
> > > > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
> > > > Currently 3.2 is in unstable only. Would you want to start the
> > > > recompilation before 3.2 based binaries go to testing?
> > > > 
> > > > The packaging for 3.3 can be found in the Debian CVS.
> > > 
> > > You can get test packages from
> > >   http://ftp-master.debian.org/~doko/gcc-3.3/
> > 
> > well this is not looking good. after installing these in a freshly
> > built sarge chroot, all c++ programs stop working (well, i've only tried
> > two -- apt and fakeroot)
> 
> You can find updated packages at
>   http://ftp-master.debian.org/~doko/gcc-3.3/hppa/
> checked building bash (fakeroot) and upgrading an unstable chroot (apt).
> 
> > (btw, small packaging detail, but the libstdc++*-dev package above
> > cannot be installed cleanly because it overwrites things in the current
> > 3.2 package)
> 
> There is still one conflict for libstdc++5-dev (<= 1:3.2.3-0pre3), so
> please install libstdc++5-dev (1:3.2.3-0pre4) first.

Did you configure 3.3 using "--enable-sjlj-exceptions=yes"?  That way
the 3.3 C++ library should be compatible with the previous 3.3 library.
The switch to dwarf2 can be delayed until the next debian release.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> Nice and is it also possible to produce a 64bits version of gcc?

Last time I tried (couple of weeks ago), it was possible to build
a 64-bit cross starting with 3.3.  This still doesn't work with 3.2.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Re: gcc-3.2 -> gcc-3.3 transition on hppa

[John David Anglin]

> In reference to a message from Matthias Klose, dated Mar 01:
> > Matthias Klose writes:
> > > AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
> > > code due to the changed exception handling (now DWARF2 based). As
> > > libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?

Possibly, this issue should be broached with the libstdc++ maintainers.
In my testing, I have moved to installing each gcc version in its own
directory.

I should note again that 3.3 has a ABI change in the passing of small
structures.  It also contains a fix for function pointer comparison.
As glibc does function comparison in a number of routines, it needs
recompilation with 3.3 to work correctly.  Then, I believe gcc needs
to be rebuilt as libstdc++ depends on the thread implementation.  The
last glibc linuxthread code that I downloaded was still broken.  I know
Carlos has a patch in the works.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] possible gcc-3.2 bug?

[John David Anglin]

> well, it's doesn't seem to be very consistent about it then...
> 
> static rwlock_t x = (rwlock_t) { { 1 }, 0 };
> is ok
> 
> static rwlock_t x = { (spinlock_t) { 1 }, 0 };
> is also ok
> 
> only when you have both casts does it fail...

Ok, I think I see what is going on.  "(rwlock_t) { { 1 }, 0 }" is
a compound literal (constructor expression).  GCC allows initialization
of static objects by compound literals.  This is not possible in ISO C99.

The initializer list of the compound literal must be constant.  Thus,
nesting of compound literals isn't possible.  So, when you have two
casts in the initializer you get the error.  For more info, look at
extend.texi.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] possible gcc-3.2 bug?

[John David Anglin]

> The following piece of code compiles with gcc-3.0 but not with
> gcc-3.2... is this a gcc bug? or is the code broken?

I would say the later.

> [EMAIL PROTECTED]:~$ gcc-3.2 -c t.c
> t.c: In function `foo':
> t.c:12: initializer element is not constant
> 
> (it's a simplified example of some code from the parisc-linux kernel)
> 
> -8<---
> /* compile with gcc -c foo.c */
> 
> typedef struct {
> volatile unsigned int lock;
> } spinlock_t;
> 
> typedef struct {
> spinlock_t lock;
> volatile int counter;
> } rwlock_t;
> 
> void foo(void)
> {
> static rwlock_t x = (rwlock_t) { (spinlock_t) { 1 }, 0 };
> }

Except for sizeof, cast operators in initializers for static variables
can only be used to convert arithmetic types.  GCC allows non-constant
initializers for automatic variables.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Re: libffi2 -> gcj = Java

[John David Anglin]

> Jean-Yves GUILLEVIC writes:
> > Hello All
> > 
> > does someone knows about libffi2 on Debian HPPA Linux ?
> > to get a gcj on this port ...
> 
> AFAIK nobody has started a port yet.

James Mc Parlane may be working on this.  There was a question re calling
conventions back on May 17.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [parisc-linux] Re: gcc-3.? compiler for hppa (3.1, 3.1+dwarf2, 3.2cvs20020429?)

[John David Anglin]

> > I still haven't figured out why libstdc++ needs to be installed prior
> > to running the testsuite.
> 
> That's weird... nothing immediately comes to mind.

LD_RUN_PATH in the environment is the culprit.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [parisc-linux] gcc-3.? compiler for hppa (3.1, 3.1+dwarf2, 3.2cvs20020429?)

[John David Anglin]

> this is a diff of the test results for b and c. g++ is worse, the

I think all the new g++ fails are in new tests.  So, I don't think
g++ is actually worse.

> regressions for g77 and gcc are new test cases in the trunk. One new
> gcc regression:

Yes, gcc.c-torture/compile/2504-1.c is a regression.  It's good
to see the g77 fails go away.

> Ada doesn't build:
> ../../xgcc -B../../ -c -g -O2 -g -O2 -W -Wall -gnatpg -I. 
> -I/home/packages/gcc/try/gcc-3.1-3.1ds90/src/gcc/ada s-taprop.adb
> s-taprop.adb:48:12: warning: no entities of "Os_Primitives" are referenced
> make[4]: *** [s-taprop.o] Error 1
> make[4]: Leaving directory 
> `/home/packages/gcc/try/gcc-3.1-3.1ds90/build/gcc/ada/rts'

The enclosed patch fixes the compilation error.  However, Florian hasn't
installed it.  I'll try and get an update on its status.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)

>From [EMAIL PROTECTED] Sun Apr 28 16:44:10 EDT 2002
Received: from nrcmrddc1.imsb.nrc.ca (nrcmrddc1.imsb.nrc.ca [132.246.56.35])
by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id 
g3SKi9FN016414
for <[EMAIL PROTECTED]>; Sun, 28 Apr 2002 16:44:10 -0400 (EDT)
Received: by nrcmrddc1.imsb.nrc.ca with Internet Mail Service (5.5.2653.19)
id ; Sun, 28 Apr 2002 16:44:05 -0400
Received: from mail.enyo.de (cygnus-ext.enyo.de [212.9.189.162]) by 
nrcmrdbh1.imsb.nrc.ca with SMTP (Microsoft Exchange Internet Mail Service 
Version 5.5.2653.13)
id JT1Y1AT2; Sun, 28 Apr 2002 16:44:03 -0400
Received: from [212.9.189.171] (helo=deneb.enyo.de)
by mail.enyo.de with esmtp (Exim 3.34 #2)
id 171vWf-0001yK-00; Sun, 28 Apr 2002 22:44:05 +0200
Received: from fw by deneb.enyo.de with local (Exim 3.34 #4)
id 171vWc-0005rb-00; Sun, 28 Apr 2002 22:44:02 +0200
Message-ID: <[EMAIL PROTECTED]>
From: Florian Weimer <[EMAIL PROTECTED]>
To: John David Anglin <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: ada/6495: no entities of "Os_Primitives" are referenced
Date: Sun, 28 Apr 2002 16:44:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Status: RO

"John David Anglin" <[EMAIL PROTECTED]> writes:

>> [EMAIL PROTECTED] writes:
>> 
>> > s-taprop.adb:48:12: warning: no entities of "Os_Primitives" are
referenced
>> 
>> Could you please look at the file s-taprop.adb in the gcc/ada/rts and
>> check which version it is?  After the copyright string, there should
>> be a comment like this one:
>> 
>> --  This is a POSIX-like version of this package
>
> Says
>
> --  This is a no tasking version of this package

Thanks.  Could you try the following patch, please?

--- 5ntaprop.adb.~1.3.~ Sun Mar 17 09:08:21 2002
+++ 5ntaprop.adbSun Apr 28 22:42:59 2002
@@ -45,9 +45,6 @@
 --  used for Ada_Task_Control_Block
 --   Task_ID
 
-with System.OS_Primitives;
---  used for Delay_Modes
-
 with System.Error_Reporting;
 --  used for Shutdown
 
@@ -55,7 +52,6 @@
 
use System.Tasking;
use System.Parameters;
-   use System.OS_Primitives;
 
-
-- Stack_Guard --


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [parisc-linux] gcc-3.? compiler for hppa (3.1, 3.1+dwarf2, 3.2cvs20020429?)

[John David Anglin]

> While preparing gcc-3.1 packages I noticed many eh-related regressions
> fixed in the trunk, when dwarf2 support was added. With Dave's
> guidance I made a diff of the pa subdirectory from the trunk and
> applied it to the branch. Although many FAILS are gone, there are some
> new (diff below).

In general, option b has much better c++ results than a).  The c++
test results are essentially identical to those with 3.2.  However,
compared to the results that I have been posting for 3.2, we have
the following new failures:

gcc.c-torture/execute/ieee/rbug.c

g77.f-torture/execute/19990313-[0-3].f

20_util/allocator_members.cc execution test
22_locale/codecvt_members_char_char.cc execution test
22_locale/codecvt_members_wchar_t_char.cc execution test
22_locale/ctor_copy_dtor.cc execution test
22_locale/ctype_members_wchar_t.cc execution test
27_io/ostream_inserter_arith.cc execution test

It would probably be useful to compare test results for b and c.  It may
be that some of the above are glibc or system problems.  I am fairly
certain c will build on all platforms.  However, I know that there is
one c regression under hppa near the beginning of march.  There is another
at the beginning of May.

As a matter of release philosophy, I don't much like hybrids.  Option
b adds another permutation to maintain even if the new c++ capabilities
are very tempting.  My focus will be 3.2.  3.1 will only get small bug
fixes.  If we keep to the main releases, it much easier to verify and
resolve bugs.

So, I would say use a as the default.  This is the conservative choice
and well tested across a broad range of systems.  Option a can easily be
used to build c.  Maybe you could include c as well for experimental
development and building c++ packages that need the dw2 support under
parisc-linux.

> I would like to get feedback, on which alternative to base the gcc-3.1
> packages:
> 
> a) 3.1 as to be released (without dwarf2 support)
> b) 3.1 + dwarf2 support
> c) 3.2 CVS 20020429 plus/minus patches
> 
> Constraints: Make gcc-3.1 the default compiler for all Debian
> architectures in the near future, provided it builds on all of them.
> 
> a) is the default option to go with.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [parisc-linux] Re: gcc-3.? compiler for hppa (3.1, 3.1+dwarf2, 3.2cvs20020429?)

[John David Anglin]

> i am concerned that between gcc versions, there are often changes in the
> C++ (and maybe others) ABI, and moving all of our packages to the new 
> version is likely going to be a painful process. If the g++-3.2 ABI is
> already frozen (?) and we move directly to it then we may save ourselves
> some trouble with doing the repackaging multiple times.

I know that there are some small ABI changes between libstdc++ 3.1 and
3.2.  This got mentioned in discussion of a PR that I filed concerning
the library under hpux.  Under hpux, all applications that were linked
against the 3.0 library needed to be relinked when the 3.0.1 library
was installed :-(

I still haven't figured out why libstdc++ needs to be installed prior
to running the testsuite.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6605)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]