[Bug target/29206] [4.6/4.7/4.8 regression] gcj-dbtool segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206 --- Comment #22 from dave.anglin at bell dot net 2012-11-10 01:28:52 UTC --- If possible, I think SJLJ support should go. I can't remember the exact status of SJLJ for HP-UX 10 but a comment in hpux-unwind.h suggests that I tested dwarf2 support. I can check but it will take time. Dave -- John David Anglindave.ang...@bell.net
[Bug target/55332] [4.8 Regression] libsanitizer breaks build on hpux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55332 --- Comment #2 from dave.anglin at bell dot net 2012-11-15 13:47:24 UTC --- On 15-Nov-12, at 5:38 AM, jakub at gcc dot gnu.org wrote: It doesn't break bootstrap any longer, configure.tgt should enable it solely on i?86/x86_64-linux right now. I have a patch which enables build on hppa-linux but it's unclear whether the library works. -- John David Anglindave.ang...@bell.net
[Bug target/55316] gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error Unsupported arch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55316 --- Comment #2 from dave.anglin at bell dot net 2012-11-18 17:18:20 UTC --- On 17-Nov-12, at 3:01 AM, hp at gcc dot gnu.org wrote: This should be fixed now by the general disabling of libsanitizer. In theory, it should be fairly easy to add the support. -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471 --- Comment #2 from dave.anglin at bell dot net 2012-11-21 02:26:56 UTC --- On 20-Nov-12, at 7:06 AM, jakub at gcc dot gnu.org wrote: Can't reproduce that with a cross. The tree optimizers definitely don't optimize it into abort, and neither the assembly looks like what you are mentioning above. I'll recheck. I definitely remember looking at the RTL from the expand pass. That's why I marked it as a tree optimizer bug. Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #15 from dave.anglin at bell dot net 2012-11-26 14:58:12 UTC --- On 11/26/2012 4:47 AM, gjl at gcc dot gnu.org wrote: A milestone of 3.0.x?? It seems I did this while updating the Last reconfirmed date. As I understand it, it's a Firefox feature that arises when the web page is inconsistent with cached browser page.
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 --- Comment #17 from dave.anglin at bell dot net 2012-11-26 16:43:18 UTC --- On 11/26/2012 11:36 AM, jakub at gcc dot gnu.org wrote: P1 for an error-recovery bug sounds way too high, those should be P4-ish. I just restored the previous setting. No objection to revising it downward.
[Bug libstdc++/55503] FAIL: 30_threads/condition_variable/members/53841.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55503
--- Comment #2 from dave.anglin at bell dot net 2012-11-28 01:13:14 UTC ---
On 27-Nov-12, at 7:46 PM, redi at gcc dot gnu.org wrote:
// { dg-options -std=gnu++11 { target hppa*-*-* } }
Trying:
Index: testsuite/30_threads/condition_variable/members/53841.cc
===
--- testsuite/30_threads/condition_variable/members/53841.cc(revision
193878)
+++ testsuite/30_threads/condition_variable/members/53841.cc(working
copy)
@@ -1,5 +1,5 @@
// { dg-do compile }
-// { dg-options -std=gnu++0x -pthread { target *-*-freebsd* *-*-
netbsd* *-*-linux* powerpc-ibm-aix* } }
+// { dg-options -std=gnu++0x -pthread { target *-*-freebsd* *-*-
netbsd* *-*-linux* powerpc-ibm-aix* hppa*-hp-hpux11* } }
// { dg-options -std=gnu++0x -pthreads { target *-*-solaris* } }
// { dg-options -std=gnu++0x { target *-*-cygwin *-*-darwin* } }
// { dg-require-cstdint }
Dave
--
John David Anglindave.ang...@bell.net
[Bug middle-end/55507] [4.8 Regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55507 --- Comment #3 from dave.anglin at bell dot net 2012-11-28 18:50:26 UTC --- On 11/28/2012 1:25 PM, rth at gcc dot gnu.org wrote: Since this is _powtf2, you probably need --enable-long-double-128 in the configure line when cross-compiling. Actually, it's 64 bits on hppa-linux. Has the long double default changed?
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 --- Comment #5 from dave.anglin at bell dot net 2012-12-03 16:06:22 UTC --- I have a patch to ignore the comparison failure and a couple changes to libbacktrace for hpux. The btest program now runs successfully on hpux. However, backtrace still doesn't work from within compiler.
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 --- Comment #6 from dave.anglin at bell dot net 2012-12-03 22:33:39 UTC --- On 12/3/2012 11:06 AM, John David Anglin wrote: However, backtrace still doesn't work from within compiler. Problem is with fileline_initialize. The techniques currently being used to obtain the full pathname of the executable don't work on HP-UX. http://www.cplusplus.com/forum/general/11104/ Dave
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 --- Comment #9 from dave.anglin at bell dot net 2012-12-07 13:33:16 UTC --- On 6-Dec-12, at 1:39 PM, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|WAITING CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-06 18:39:03 UTC --- For the bootstrap comparison failures, I'd guess libbacktrace should be built with -frandom-seed=$@ in CFLAGS similarly how libstdc++-v3 is built. In what way doesn't backtrace work in the compiler? Does it crash, or not print any backtrace? The former would be a regression, the latter would not. So, does: 2012-12-06 Jakub Jelinek ja...@redhat.com PR bootstrap/54926 * Makefile.am (AM_CFLAGS): Add -frandom-seed=$@. * Makefile.in: Regenerated. --- libbacktrace/Makefile.am.jj2012-10-02 15:36:21.0 +0200 +++ libbacktrace/Makefile.am2012-12-06 19:36:05.888001803 +0100 @@ -34,7 +34,7 @@ ACLOCAL_AMFLAGS = -I .. -I ../config AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \ -I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/ include -AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) +AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) -frandom-seed=$@ noinst_LTLIBRARIES = libbacktrace.la --- libbacktrace/Makefile.in.jj2012-10-02 15:36:21.0 +0200 +++ libbacktrace/Makefile.in2012-12-06 19:36:26.284875521 +0100 @@ -254,7 +254,7 @@ ACLOCAL_AMFLAGS = -I .. -I ../config AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \ -I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/ include -AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) +AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) -frandom-seed=$@ noinst_LTLIBRARIES = libbacktrace.la libbacktrace_la_SOURCES = \ backtrace.h \ patch fix all the regressions, turning this just into enhancement request to support libbacktrace better on HP-UX? The patch fixes the bootstrap comparison failure but I wouldn't say it fixes all the regressions. See attached patch. 1) The MAP_FAILED change to mmapio.c is needed to build successfully on HP-UX 10. 2) The HAVE_SYNC_FUNCTIONS change fixes an abort which regresses the handling of ICEs. The change to filename.c improves libbacktrace support on HP-UX systems using ELF binaries. With this change, I get a successful backtrace. For example, spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/ gnu/gcc/gc c/gcc/testsuite/gcc.c-torture/execute/pr51447.c -fno-diagnostics-show- caret -w - O2 -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/pr51447.x2/test/gnu/ gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr51447.c: In function 'main':/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr51447.c: 27:1: internal c ompiler error: in mark_jump_label_1, at jump.c:11340x405c98cf mark_jump_label_1../../gcc/gcc/jump.c:1134 0x405c95df mark_jump_label_1../../gcc/gcc/jump.c:1194 0x405c9347 mark_jump_label(rtx_def*, rtx_def*, int)../../gcc/gcc/jump.c:1061 0x405c9b87 mark_all_labels ../../gcc/gcc/jump.c:303 0x405c9b87 rebuild_jump_labels_1 ../../gcc/gcc/jump.c:83 0x405c9fb3 rebuild_jump_labels(rtx_def*) ../../gcc/gcc/jump.c:103 0x40370177 cfg_layout_finalize() ../../gcc/gcc/cfgrtl.c:3805 0x40a4d42f rest_of_handle_reorder_blocks ../../gcc/gcc/bb-reorder.c:2225 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 Possibly, the addresses could be truncated modulo 4. Adding libbacktrace support to 32-bit PA HP-UX (SOM) looks to be a much tougher. In addition, there is no equivalent to dlgetname. On HP-UX 11.11 and later, it is possible to get a path to the executable using the pstat interface. On earlier systems, a file system walk can be done but it is too slow. Think it would be better to use argv[0] with some additional checks. Dave -- John David Anglindave.ang...@bell.net
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 --- Comment #3 from dave.anglin at bell dot net 2012-12-10 13:31:31 UTC --- On 10-Dec-12, at 3:57 AM, burnus at gcc dot gnu.org wrote: Can you pin-point which version causes the regression? At this point, I onnly know the test didn't fail in early September. BIT_SIZE(m) is (correctly) 64 while ma is (wrongly) 0. And NOT returns the bitwise Boolean inverse of I. Can you run the following code? It matches the failing code but contains some debugging printout. Can you also try kind=4? That seems to work while kind=8 seems to fail. integer(kind=8) m, ma ma = 0 m = 0 print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma m = not(m) print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma do while ( (m.ne.0) .and. (ma.lt.127) ) ma = ma + 1 m = ishft(m,-1) print '(m =,i21,z17,, ma=,i2,z13)', m, m, ma, ma end do print *, BIT_SIZE(m), ma if (BIT_SIZE(m) /= ma) error stop end Here are the results from hppa-unknown-linux-gnu which also fails. kind=8: m =00 ma= 00 m = -1 ma= 00 m = 9223372036854775807 7FFF, ma= 11 m = 4611686018427387903 3FFF, ma= 22 m = 2305843009213693951 1FFF, ma= 33 m = 1152921504606846975 FFF, ma= 44 m = 576460752303423487 7FF, ma= 55 m = 288230376151711743 3FF, ma= 66 m = 144115188075855871 1FF, ma= 77 m =72057594037927935 FF, ma= 88 m =36028797018963967 7F, ma= 99 m =18014398509481983 3F, ma=10A m = 9007199254740991 1F, ma=11B m = 4503599627370495F, ma=12C m = 22517998136852477, ma=13D m = 11258999068426233, ma=14E m = 5629499534213111, ma=15F m = 281474976710655 , ma=16 10 m = 140737488355327 7FFF, ma=17 11 m = 70368744177663 3FFF, ma=18 12 m = 35184372088831 1FFF, ma=19 13 m = 17592186044415 FFF, ma=20 14 m =8796093022207 7FF, ma=21 15 m =4398046511103 3FF, ma=22 16 m =219902321 1FF, ma=23 17 m =1099511627775 FF, ma=24 18 m = 549755813887 7F, ma=25 19 m = 274877906943 3F, ma=26 1A m = 137438953471 1F, ma=27 1B m = 68719476735F, ma=28 1C m = 343597383677, ma=29 1D m = 171798691833, ma=30 1E m = 85899345911, ma=31 1F m = 4294967295 , ma=32 20 m = 2147483647 7FFF, ma=33 21 m = 1073741823 3FFF, ma=34 22 m =536870911 1FFF, ma=35 23 m =268435455 FFF, ma=36 24 m =134217727 7FF, ma=37 25 m = 67108863 3FF, ma=38 26 m = 33554431 1FF, ma=39 27 m = 16777215 FF, ma=40 28 m = 8388607 7F, ma=41 29 m = 4194303 3F, ma=42 2A m = 2097151 1F, ma=43 2B m = 1048575F, ma=44 2C m = 5242877, ma=45 2D m = 2621433, ma=46 2E m = 1310711, ma=47 2F m =65535 , ma=48 30 m =32767 7FFF, ma=49 31 m =16383 3FFF, ma=50 32 m = 8191 1FFF, ma=51 33 m = 4095 FFF, ma=52 34 m = 2047 7FF, ma=53 35 m = 1023 3FF, ma=54 36 m = 511 1FF, ma=55 37 m = 255 FF, ma=56 38 m = 127 7F, ma=57 39 m = 63 3F, ma=58 3A m = 31 1F, ma=59 3B m
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
--- Comment #5 from dave.anglin at bell dot net 2012-12-11 01:16:16 UTC ---
On 10-Dec-12, at 11:29 AM, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org
2012-12-10 16:29:10 UTC ---
The test is really large, I guess it would be useful if you could
try to reduce
the testcase as long as it still fails that BIT_SIZE(integer(8)) test.
Or can you step through the interesting part of the testcase and see
where
things go wrong? I've eyeballed the *.final assembly of the ma
computation and
it looks ok to me.
I'm seeing different code:
; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-
intrinsic-bit.f:48
.loc 1 48 0
ldi 0,%r28
ldi 0,%r29
.LBB19:
; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-
intrinsic-bit.f:55
.loc 1 55 0
ldo -240(%r30),%r25
.LBE19:
; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-
intrinsic-bit.f:48
.loc 1 48 0
stw %r28,-240(%r30)
stw %r29,-236(%r30)
.LBB20:
; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-
intrinsic-bit.f:55
.loc 1 55 0
ldi 20,%r23
ldil LR'.LC12,%r26
ldil LR'.LC13,%r24
ldo RR'.LC12(%r26),%r26
ldo RR'.LC13(%r24),%r24
bl c_i8_,%r2
ldil LR'.LC15,%r3
The second argument of the call is passed in r25 (pointer to ma). As
can be seen,
ma is 0.
In .expand, we have:
ma = 0;
c_i8 (C.920, ma, BIT_SIZE(integer(8))[1]{lb: 1 sz: 1}, 20);
So, I guess this is likely a tree optimization bug.
--
John David Anglindave.ang...@bell.net
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 --- Comment #4 from dave.anglin at bell dot net 2012-12-19 12:58:32 UTC --- On 19-Dec-12, at 5:54 AM, jakub at gcc dot gnu.org wrote: Or is it libgfortran itself that when built with r189365 works and when r189366 doesn't? If so, can you find where are the code differences? I'll try and debug this regression as soon as I can but it might not be until the weekend. -- John David Anglindave.ang...@bell.net
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884 --- Comment #4 from dave.anglin at bell dot net 2013-01-07 16:09:14 UTC --- On 1/7/2013 7:50 AM, jakub at gcc dot gnu.org wrote: Guess related to -fintrinsic-module-path. Have being doing a regression search and it seems to be pointing to this change. Seem to have to do a full bootstrap to test. Sometimes test is unresolved. Will try you your suggestion. Dave
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 --- Comment #13 from dave.anglin at bell dot net 2013-01-07 18:09:29 UTC --- On 1/7/2013 12:27 PM, jakub at gcc dot gnu.org wrote: I'd say after with r194800 or later you shouldn't get this failure. Yes, the failure is gone. So, PR can be closed when secondary issues are resolved. Thanks, Dave
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884
--- Comment #5 from dave.anglin at bell dot net 2013-01-08 03:34:15 UTC ---
With the patch, the tests are unresolved with r194997:
UNSUPPORTED: libgomp.fortran/omp_parse3.f90 -O0
UNSUPPORTED: libgomp.fortran/omp_parse3.f90 -O1
UNSUPPORTED: libgomp.fortran/omp_parse3.f90 -O2
UNSUPPORTED: libgomp.fortran/omp_parse3.f90 -O3 -fomit-frame-pointer
UNSUPPORTED: libgomp.fortran/omp_parse3.f90 -O3 -fomit-frame-pointer -
funroll-loops
UNSUPPORTED: libgomp.fortran/omp_parse3.f90 -O3 -fomit-frame-pointer -
funroll-all-loops -finline-functions
UNSUPPORTED: libgomp.fortran/omp_parse3.f90 -O3 -g
UNSUPPORTED: libgomp.fortran/omp_parse3.f90 -Os
I'm fairly certain that the tests passed before the -fintrinsic-
modules-path was added to fortran.exp.
On 7-Jan-13, at 7:50 AM, jakub at gcc dot gnu.org wrote:
Can you try perhaps:
--- libgomp/testsuite/libgomp.fortran/fortran.exp2012-12-20
11:38:48.663282599 +0100
+++ libgomp/testsuite/libgomp.fortran/fortran.exp2013-01-07
13:45:51.557361907 +0100
@@ -14,7 +14,7 @@ set quadmath_library_path ../libquadmat
dg-init
if { $blddir != } {
-lappend ALWAYS_CFLAGS additional_flags=-fintrinsic-modules-path
${blddir}
+lappend ALWAYS_CFLAGS additional_flags=-fintrinsic-modules-path
${blddir}
# Look for a static libgfortran first.
if [file exists ${blddir}/${lang_library_path}/libgfortran.a] {
set lang_test_file ${lang_library_path}/libgfortran.a
--
John David Anglindave.ang...@bell.net
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884
--- Comment #7 from dave.anglin at bell dot net 2013-01-08 15:29:49 UTC ---
On 1/8/2013 3:13 AM, jakub at gcc dot gnu.org wrote:
On HP-UX or Linux? The test is guarded with
! { dg-require-effective-target tls_runtime }
does the OS have assembly/linker and runtime TLS support?
HP-UX. HP-UX uses emutls. Ii looks to me as this should provide
runtime support but there are some regressions in TLS support at the
moment (PR 54908). Thought this was specific to C++ but maybe
it affects check_effective_target_tls_runtime.
Test is ok on Linux.
Can you attach libgomp.log ?
Have to do another build...
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884 --- Comment #8 from dave.anglin at bell dot net 2013-01-09 04:16:22 UTC --- On 8-Jan-13, at 10:29 AM, dave.anglin at bell dot net wrote: Can you attach libgomp.log ? Have to do another build... This time I ran the full libgomp testsuite and I'm back to the same driver error. I'm thinking the -fintrinsic-modules-path option needs and '=' and that the tls_runtime check fails when I just run the fortran tests. -- John David Anglindave.ang...@bell.net
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884 --- Comment #9 from dave.anglin at bell dot net 2013-01-09 04:46:36 UTC --- On 8-Jan-13, at 11:15 PM, John David Anglin wrote: I'm thinking the -fintrinsic-modules-path option needs and '=' and that the tls_runtime check fails when I just run the fortran tests. -- John David Anglindave.ang...@bell.net
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884
--- Comment #10 from dave.anglin at bell dot net 2013-01-13 21:27:19 UTC ---
Can you try perhaps:
--- libgomp/testsuite/libgomp.fortran/fortran.exp2012-12-20
11:38:48.663282599 +0100
+++ libgomp/testsuite/libgomp.fortran/fortran.exp2013-01-07
13:45:51.557361907 +0100
@@ -14,7 +14,7 @@ set quadmath_library_path ../libquadmat
dg-init
if { $blddir != } {
-lappend ALWAYS_CFLAGS additional_flags=-fintrinsic-modules-path
${blddir}
+lappend ALWAYS_CFLAGS additional_flags=-fintrinsic-modules-path
${blddir}
# Look for a static libgfortran first.
if [file exists ${blddir}/${lang_library_path}/libgfortran.a] {
set lang_test_file ${lang_library_path}/libgfortran.a
? Though, I'd say using Joined Separate for such named option is
just wrong,
it is fine for single letter options like -B, -A, -D, -U etc., but
for options
of this kind I think it would be much better if it was
fintrinsic-modules-path
Fortran RejectNegative Separate
Specify where to find the compiled intrinsic modules
fintrinsic-modules-path=
Fortran RejectNegative Joined
Specify where to find the compiled intrinsic modules
instead and handle OPT_fintrinsic_modules_path_ the same as
OPT_fintrinsic_modules_path. But given that the option has been
added already
back in 2007, it is probably too late for that.
With the attached change, the fortran libgomp testsuite runs without
errors.
Using a space to separate the option and its value still doesn't
work. Joining
option and value results in an unrecognizable option and all tests fail.
--
John David Anglindave.ang...@bell.net
[Bug middle-end/56000] [4.8 Regression] FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000 --- Comment #4 from dave.anglin at bell dot net 2013-01-16 16:24:47 UTC --- On 1/16/2013 3:08 AM, sch...@linux-m68k.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2013-01-16 08:08:33 UTC --- Does this help? http://sourceware.org/ml/libffi-discuss/2012/msg00279.html Yes, the two patches fix the libffi fails.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #14 from dave.anglin at bell dot net 2013-01-27 23:48:04 UTC --- I believe it would be possible to implement dwarf on 32-bit hppa-hpux... -- John David Anglindave.ang...@bell.net
[Bug testsuite/56194] FAIL: g++.dg/init/const9.C -std=c++98 scan-assembler-not rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56194 --- Comment #3 from dave.anglin at bell dot net 2013-02-04 16:03:08 UTC --- One thought I had is to add the -fpic option. This should push the function descriptor into .data.
[Bug regression/58603] [4.9 Regression] hash-table.h:962: error: anachronistic old-style base class initia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58603 --- Comment #5 from dave.anglin at bell dot net --- KDE added a trailing underscore to work around this issue.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #15 from dave.anglin at bell dot net --- As of revision 204772, there are still problems on hppa-linux. libtool: compile: /home/dave/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/home/dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/ objdir/hppa-linux-gnu/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/ hppa-linux-gnu/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir/hppa- linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/dave/opt/gnu/gcc/ gcc-4.9/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.9/hppa- linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/ include -isystem /home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/sys- include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS - D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc/ libsanitizer/sanitizer_common -I ../../../../gcc/libsanitizer/include - Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind- tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/ include -I../../libstdc++-v3/include/hppa-linux-gnu -I../../../../gcc/ libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -MT sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo - c ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_linux.cc -o sanitizer_linux.o /dev/null 21 In file included from ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_posix.cc:17:0: ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_internal_defs.h:247:72: error: size of array ‘assertion_failed__849’ is negative typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int) (pred)-1] ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_internal_defs.h:241:30: note: in expansion of macro ‘IMPL_COMPILER_ASSERT’ #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_posix.cc:849:1: note: in expansion of macro ‘COMPILER_CHECK’ COMPILER_CHECK(sizeof(__sanitizer_sigaction) == sizeof(struct sigaction)); ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_internal_defs.h:247:72: error: size of array ‘assertion_failed__852’ is negative typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int) (pred)-1] ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_internal_defs.h:241:30: note: in expansion of macro ‘IMPL_COMPILER_ASSERT’ #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_posix.cc:752:3: note: in expansion of macro ‘COMPILER_CHECK’ COMPILER_CHECK(offsetof(struct __sanitizer_##CLASS, MEMBER) == \ ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_posix.cc:852:1: note: in expansion of macro ‘CHECK_STRUCT_SIZE_AND_OFFSET’ CHECK_STRUCT_SIZE_AND_OFFSET(sigaction, sa_mask); ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_internal_defs.h:247:72: error: size of array ‘assertion_failed__853’ is negative typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int) (pred)-1] ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_internal_defs.h:241:30: note: in expansion of macro ‘IMPL_COMPILER_ASSERT’ #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_posix.cc:752:3: note: in expansion of macro ‘COMPILER_CHECK’ COMPILER_CHECK(offsetof(struct __sanitizer_##CLASS, MEMBER) == \ ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_posix.cc:853:1: note: in expansion of macro ‘CHECK_STRUCT_SIZE_AND_OFFSET’ CHECK_STRUCT_SIZE_AND_OFFSET(sigaction, sa_flags); ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_posix.cc:855:41: error: ‘struct sigaction’ has no member named ‘sa_restorer’ CHECK_STRUCT_SIZE_AND_OFFSET(sigaction, sa_restorer); ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_internal_defs.h:247:65: note: in definition of macro ‘IMPL_COMPILER_ASSERT’ typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int) (pred)-1] ^ ../../../../gcc/libsanitizer/sanitizer_common/ sanitizer_platform_limits_posix.cc:750:3: note: in expansion of macro ‘COMPILER_CHECK’ COMPILER_CHECK(sizeof(((struct __sanitizer_##CLASS *) NULL)- MEMBER) == \ ^ ../../../../gcc
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #18 from dave.anglin at bell dot net --- On 11/14/2013 12:26 PM, bergner at gcc dot gnu.org wrote: Dave, can you try this patch to see if it cleans up the errors you're seeing? I will try it later today when I get home. Dave
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #21 from dave.anglin at bell dot net --- On 14-Nov-13, at 12:26 PM, bergner at gcc dot gnu.org wrote: Dave, can you try this patch to see if it cleans up the errors you're seeing? Patch cleans up the errors. Dave -- John David Anglindave.ang...@bell.net
[Bug libfortran/35667] HP-UX 10 has broken strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35667 --- Comment #9 from dave.anglin at bell dot net --- On 12/9/2013 5:01 AM, fxcoudert at gcc dot gnu.org wrote: Was that fixed with John's commit? I think so. I believe this was left open because the patch wasn't back ported. I could confirm but that would take awhile. Dave
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #31 from dave.anglin at bell dot net --- On 12/10/2013 11:49 AM, jakub at gcc dot gnu.org wrote: For that a patch has been posted, just not reviewed: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00963.html Excellent. As for hppa, the change to enable it isn't in upstream GCC, so you as a maintainer need to make it working first and if changes are needed for compiler-rt maintained code, make sure it is accepted there first too. I'm fully aware that the change to enable isn't upstream. I'm still debating in my mind whether this should be done or not. At the moment, there are no additional changes to the compiler-rt code as far as I know. However, things seem fragile and possibly this library is unsuitable for an architecture that is only supported by Gentoo and Debian unstable Linux ports. I'm not sure what the issue is with the hppa kernel typedef for time_t. It seems defined by the generic linux type definitions. If this needs to be changed for libsanitizer, I would like to understand why. As far as I can tell, hppa isn't unique in using time_t in uapi/asm/stat.h although the majority of ports only use base types.
[Bug libfortran/58015] FAIL: gfortran.dg/round_4.f90: Unsatisfied symbol nextafterl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58015 --- Comment #7 from dave.anglin at bell dot net --- On 13-Dec-13, at 5:08 PM, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58015 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Why not just adapt the existing implementation of nextafterf to long double? This requires frexpl and scalbnl which also don't currently exist. They have further dependencies. What did work was a simple routine to call nextafterq in libquadmath. Quad and long double are equivalent on hppa. Then I thought I should create a long double port of libquadmath and integrate it into libgcc on hppa. However, I haven't had time to complete this approach but it would provide a complete set of c99 long double functions. Dave -- John David Anglindave.ang...@bell.net
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #39 from dave.anglin at bell dot net --- On 12/19/2013 5:36 PM, dominiq at lps dot ens.fr wrote: Is there anything else left in this bug? I don't think so for darwin, but AFAICT it may remain issues for hppa-linux (comment 22) and a fairly old arm box comments 28 and 29. Rechecking status on the arm box. I have been working on a linux and glibc update for it, but this is non trivial because of a variety of hardware not supported in the standard kernel. There is considerable code rot. I doubt the hppa-linux issue is fixed. It needs a kernel header update or the check disabled. Dave
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #40 from dave.anglin at bell dot net --- On 12/19/2013 5:53 PM, John David Anglin wrote: Rechecking status on the arm box. Problem is still there: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:58:30: fatal error: linux/perf_event.h: No such file or directory #include linux/perf_event.h
[Bug c++/41090] [4.7/4.8/4.9 Regression] Using static label reference in c++ class constructor produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #22 from dave.anglin at bell dot net --- On 26-Dec-13, at 7:28 AM, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test g++.dg/ext/label13.C XPASS after r20182 on darwin. Likewise on hppa2.0w-hp-hpux11.11. Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791 --- Comment #11 from dave.anglin at bell dot net --- On 3-Jan-14, at 7:46 AM, bernds at gcc dot gnu.org wrote: I guess this means you've tested it and it works? Yes, I have tested it and it works fine. Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/53420] [4.8 Regression] ICE in iterative_hash_expr, at tree.c:7039
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53420 --- Comment #4 from dave.anglin at bell dot net 2012-08-18 23:50:21 UTC --- On 15-Aug-12, at 4:16 AM, jakub at gcc dot gnu.org wrote: Can you still reproduce it? My HP-UX 11.00 box had a disk failure a couple of weeks ago, so I can't reproduce it at the moment. I only saw this problem with 11.00. Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/54317] [4.8 Regression] FAIL: c45532m c45532n c45532o c45532p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 --- Comment #2 from dave.anglin at bell dot net 2012-08-20 16:23:57 UTC --- On 8/20/2012 11:46 AM, glisse at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-08-20 15:46:58 UTC --- Wow, I didn't expect that patch to break a multiplication test... It sounds like you have before and after compilers. Do you have tree-vrp dumps from both? (I would ask if a stage1 compiler fails too, to rule out miscompilation of the compiler, but I have no idea how ada works...) At the moment, I have no idea as to which module is broken but I believe the problem is in the Ada runtime library. I compared the .o files for the first test of the four failing tests using before and after compilers and they were identical. The ada tests are not compiled with debugging enabled, so they are a bit difficult to debug. The tests invoke a lot of arithmetic operations... Is hwint 32 bits on this platform? I am looking for acats testresults from other such platforms in gcc-testresults but can't find them... Yes, hwint is 32 bits. I just fixed a couple of issues with expand_mult (PR middle-end/53823). The synth_mult code can't handle multiplication by negative coefficients when the mode is larger than a hwint. One possibility might be that this code is being invoked by another path.
[Bug debug/54460] FAIL: g++.dg/debug/dwarf2/nested-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54460 --- Comment #2 from dave.anglin at bell dot net 2012-09-02 23:41:30 UTC --- On 2-Sep-12, at 2:12 PM, sch...@linux-m68k.org wrote: This uses yet another comment character. Thanks. I'll see if adding it to the regexp helps. -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 = .* \+ -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251 --- Comment #12 from dave.anglin at bell dot net 2012-09-23 22:40:10 UTC --- Test hasn't been removed. I also don't see the fail anymore. -- John David Anglindave.ang...@bell.net
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #2 from dave.anglin at bell dot net 2012-09-30 00:50:17 UTC --- On 29-Sep-12, at 7:34 PM, paolo.carlini at oracle dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-29 23:34:20 UTC --- I suppose _GLIBCXX_USE_C99_MATH_TR1 remains undefined on hppa-hpux, right? Yes. In that case, I would pre-approve a patch changing each of the three uses of the C99 hypot in include/ext/random and include/ext/random.tcc with std::sqrt(x*x + y*y) as a fall back, like: #if _GLIBCXX_USE_C99_MATH_TR1 *__f++ = std::hypot(__x, __y); #else *__f++ = std::sqrt(__x * __x + __y * __y); #endif There is an implementation of hypot, so I'm wondering if we can't do better. Testing suggestion. Dave -- John David Anglindave.ang...@bell.net
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #12 from dave.anglin at bell dot net 2012-09-30 16:06:52 UTC --- On 30-Sep-12, at 10:19 AM, glisse at gcc dot gnu.org wrote: Dominique, it would be more useful if you could show your libstdc++ config.log, and in particular the error message you got for the test for ISO C99 support to TR1 in math.h, to know what functions are missing on darwin (or hppa or others), assuming there isn't already a PR somewhere about it. FWIW, the HP-UX 11.11 list is: configure:18907: checking for ISO C99 support to TR1 in math.h configure:19031: /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/ test/gnu/gcc /objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/ libstdc++ -v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/ src/.libs -B/o pt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.8/ hppa2.0w-hp -hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/ include -isy stem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include-c -g - O2 -std=c+ +98 conftest.cpp 5 conftest.cpp: In function 'int main()': conftest.cpp:67:16: error: 'acoshf' was not declared in this scope acoshf(0.0f); ^ conftest.cpp:68:16: error: 'acoshl' was not declared in this scope acoshl(0.0l); ^ conftest.cpp:70:16: error: 'asinhf' was not declared in this scope asinhf(0.0f); ^ conftest.cpp:71:16: error: 'asinhl' was not declared in this scope asinhl(0.0l); ^ conftest.cpp:73:16: error: 'atanhf' was not declared in this scope atanhf(0.0f); ^ conftest.cpp:74:16: error: 'atanhl' was not declared in this scope atanhl(0.0l); ^ conftest.cpp:77:15: error: 'cbrtl' was not declared in this scope cbrtl(0.0l); ^ conftest.cpp:80:25: error: 'copysignl' was not declared in this scope copysignl(0.0l, 0.0l); ^ conftest.cpp:82:14: error: 'erff' was not declared in this scope erff(0.0f); ^ conftest.cpp:83:14: error: 'erfl' was not declared in this scope erfl(0.0l); ^ conftest.cpp:85:15: error: 'erfcf' was not declared in this scope erfcf(0.0f); ^ conftest.cpp:86:15: error: 'erfcl' was not declared in this scope erfcl(0.0l); ^ conftest.cpp:88:15: error: 'exp2f' was not declared in this scope exp2f(0.0f); ^ conftest.cpp:89:15: error: 'exp2l' was not declared in this scope exp2l(0.0l); ^ conftest.cpp:91:16: error: 'expm1f' was not declared in this scope expm1f(0.0f); ^ conftest.cpp:92:16: error: 'expm1l' was not declared in this scope expm1l(0.0l); ^ conftest.cpp:94:21: error: 'fdimf' was not declared in this scope fdimf(0.0f, 0.0f); ^ conftest.cpp:95:21: error: 'fdiml' was not declared in this scope fdiml(0.0l, 0.0l); ^ conftest.cpp:96:22: error: 'fma' was not declared in this scope fma(0.0, 0.0, 0.0); ^ conftest.cpp:97:26: error: 'fmaf' was not declared in this scope fmaf(0.0f, 0.0f, 0.0f); ^ conftest.cpp:98:26: error: 'fmal' was not declared in this scope fmal(0.0l, 0.0l, 0.0l); ^ conftest.cpp:100:21: error: 'fmaxf' was not declared in this scope fmaxf(0.0f, 0.0f); ^ conftest.cpp:101:21: error: 'fmaxl' was not declared in this scope fmaxl(0.0l, 0.0l); ^ conftest.cpp:103:21: error: 'fminf' was not declared in this scope fminf(0.0f, 0.0f); ^ conftest.cpp:104:21: error: 'fminl' was not declared in this scope fminl(0.0l, 0.0l); ^ conftest.cpp:106:22: error: 'hypotf' was not declared in this scope hypotf(0.0f, 0.0f); ^ conftest.cpp:107:22: error: 'hypotl' was not declared in this scope hypotl(0.0l, 0.0l); ^ conftest.cpp:109:16: error: 'ilogbf' was not declared in this scope ilogbf(0.0f); ^ conftest.cpp:110:16: error: 'ilogbl' was not declared in this scope ilogbl(0.0l); ^ conftest.cpp:112:17: error: 'lgammaf' was not declared in this scope lgammaf(0.0f); ^ conftest.cpp:113:17: error: 'lgammal' was not declared in this scope lgammal(0.0l); ^ conftest.cpp:115:17: error: 'llrintf' was not declared in this scope llrintf(0.0f); ^ conftest.cpp:116:17: error: 'llrintl' was not declared in this scope llrintl(0.0l); ^ conftest.cpp:118:18: error: 'llroundf' was not declared in this scope
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #14 from dave.anglin at bell dot net 2012-09-30 17:15:24 UTC --- On 30-Sep-12, at 12:16 PM, paolo.carlini at oracle dot com wrote: Hopeless ;) Actually, the situation might not be completely hopeless as the libquadmath support works... I had planned to implement the long double aliases but haven't had time to get around to it. -- John David Anglindave.ang...@bell.net
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #16 from dave.anglin at bell dot net 2012-09-30 18:04:26 UTC --- I will commit the attached change if there are no objections. -- John David Anglindave.ang...@bell.net
[Bug rtl-optimization/54739] [4.8 regression] FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 Splitting reg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54739 --- Comment #4 from dave.anglin at bell dot net 2012-10-01 23:51:23 UTC --- Thanks Ulrich for your analysis. On parisc, I believe it would be best to remove iordi3, anddi3, etc, for 32-bit targets if they are successfully split. Testing a fix. -- John David Anglindave.ang...@bell.net
[Bug target/26472] Default path for libgcc_s.sl is build directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472 --- Comment #17 from dave.anglin at bell dot net 2012-10-03 22:39:46 UTC --- On 3-Oct-12, at 6:18 PM, anilkris at hotmail dot com wrote: I am getting the following error when I run a concurrent programs in Oracle R12.1.3, which calls a Pro *C executable. /usr/lib/dld.sl: Can't find path for shared library: libstdc++.sl.5 /usr/lib/dld.sl: No such file or directory /d701/oracle/cfo/bin/CFORPPL Program was terminated by signal 6 This issue isn't related to bug. Whether SHLIB_PATH is used or not depends on how applications and libraries are linked. The chatr program can be used to see how an application or library has been linked, and the library paths. It may be possible to use chatr to adjust the settings so the error doesn't occur. Library paths are hardcoded during linking. -- John David Anglindave.ang...@bell.net
[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #3 from dave.anglin at bell dot net 2012-10-08 14:45:48 UTC --- On 8-Oct-12, at 10:18 AM, bernds at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #2 from Bernd Schmidt bernds at gcc dot gnu.org 2012-10-08 14:18:58 UTC --- Could you attach both dumps? (and use -fsched-verbose=5) Done. Did your test include r191838? No but the bug is still present with r191838. Dumps are from r191493. -- John David Anglindave.ang...@bell.net
[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #4 from dave.anglin at bell dot net 2012-10-08 14:45:51 UTC --- Created attachment 28389 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28389 20041113-1.c.224r.sched2.txt
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 --- Comment #2 from dave.anglin at bell dot net 2012-10-15 11:55:29 UTC --- On 15-Oct-12, at 2:44 AM, ubizjak at gmail dot com wrote: The patch just introduces -funwind-tables to compile flags, so I really don't see how this can cause any difference. I hacked configure to turn -funwind-tables off on hpux. It is the cause of the comparison difference. The difference isn't caused by incorrect code. Think the compare needs to be ignored on hpux. Dave -- John David Anglindave.ang...@bell.net
[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #10 from dave.anglin at bell dot net 2012-10-19 18:33:27 UTC --- I'm not seeing the fail with the candidate patch.
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #2 from dave.anglin at bell dot net 2012-11-04 02:52:31 UTC --- On 3-Nov-12, at 4:45 PM, amylaar at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-03 20:45:10 UTC --- Could you attach preprocessed source and the exact options passsed to cc1 (from -v --save-temos compilation) so that I can look at this in a cross environment? Unfortunately, -v -save-temps doesn't save the java source from a list input. So far, I've only seen this with jc1. I imagine this is because the input is huge. This is compilation command: /home/dave/gnu/gcc/objdir/./gcc/jc1 ../../../gcc/libjava/classpath/lib/ gnu/javax/swing/text/html/parser/HTML_401F.class -fuse-divide- subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline- functions -quiet -dumpbase HTML_401F.class -auxbase-strip gnu/javax/ swing/text/html/parser/.libs/HTML_401F.o -g -O2 -Wno-deprecated - version -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/home/ dave/gnu/gcc/objdir/hppa-linux-gnu/libjava/classpath/lib/classes -fPIC -fbootclasspath=./:../../../gcc/libjava/classpath/lib/ -faux-classpath HTML_401F.zip -MD_ -MT gnu/javax/swing/text/html/parser/HTML_401F.lo - MF gnu/javax/swing/text/html/p arser/HTML_401F.deps -o HTML_401F.s Dave -- John David Anglindave.ang...@bell.net
[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #6 from dave.anglin at bell dot net 2012-11-04 22:23:04 UTC --- On 4-Nov-12, at 12:31 PM, amylaar at gcc dot gnu.org wrote: The instruction call_symref_pic_post_reload has the following length attribute setting: (set (attr length) (symbol_ref pa_attr_length_call (insn, 0))) Such a length attribute is not considered variable by shorten_branches. You need to include a clause that is directly in the attribute, e.g. (and (match_test 0) (eq (match_dup 0) (pc))) Thanks Jorn for debugging this. Dave -- John David Anglindave.ang...@bell.net
[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #7 from dave.anglin at bell dot net 2012-11-04 23:50:44 UTC --- On 4-Nov-12, at 12:31 PM, amylaar at gcc dot gnu.org wrote: Such a length attribute is not considered variable by shorten_branches. You need to include a clause that is directly in the attribute, e.g. (and (match_test 0) (eq (match_dup 0) (pc))) In some sense, this seems like a hack which might be optimized by an attribute processor. What about a way to mark length attributes as variable? Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 --- Comment #2 from dave.anglin at bell dot net 2012-11-05 00:20:16 UTC --- On 3-Nov-12, at 10:38 PM, pinskia at gcc dot gnu.org wrote: Exposed as this is a change in the library and the compiler is crashing with a valid input that the change introduced. The ICE occurs because we get a TF mode REG instead of a MEM. -- John David Anglindave.ang...@bell.net
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #10 from dave.anglin at bell dot net 2012-11-06 12:26:06 UTC ---
On 5-Nov-12, at 11:20 AM, amylaar at gcc dot gnu.org wrote:
I take back that statement about this being straightforward. We
need valid
minimum and maximum instruction lengths. The opaque dummy clause
automatically
provides a value to be included in these calculations.
This is failing at -O0:
(define_insn
[(set (reg:SI 29)
(div:SI (reg:SI 26) (match_operand:SI 0 div_operand )))
(clobber (match_operand:SI 1 register_operand =a))
(clobber (match_operand:SI 2 register_operand =r))
(clobber (reg:SI 26))
(clobber (reg:SI 25))
(clobber (reg:SI 31))]
!TARGET_64BIT
*
return pa_output_div_insn (operands, 0, insn);
[(set_attr type milli)
(set (attr length)
(cond [(and (match_test 0) (eq (const_int 0) (pc)))
(const_int 24)]
(symbol_ref pa_attr_length_millicode_call (insn])
The insn is actually a millicode call (branch) which needs to be able
to reach stub table. Different variants are generated depending on
pc. I modified the opaque clause a bit as I decided I didn't want to it
to depend on operand 0. Don't see how a negative length can arise.
spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/
gcc/ -fno-d
iagnostics-show-caret -O0 -w -c -o 2427-1.o /home/dave/gnu/gcc/gcc/
gcc/tests
uite/gcc.c-torture/compile/2427-1.c/home/dave/gnu/gcc/gcc/gcc/
testsuite/gcc.c-torture/compile/2427-1.c: In func
tion 'ConvertFor3dDriver':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
2427-1.c:9:1: err
or: negative insn length
(insn 47 46 48 (parallel [
(set (reg:SI 29 %r29)
(div:SI (reg:SI 26 %r26)
(reg:SI 25 %r25)))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 19 %r19 [125]))
(clobber (reg:SI 26 %r26))(clobber (reg:SI 25
%r25))
(clobber (reg:SI 31 %r31))
]) /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
2427-1.c:8 122 {*pa.md:5433}
(nil))
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
2427-1.c:9:1: int
ernal compiler error: in shorten_branches, at final.c:1162
0x537f7b _fatal_insn(char const*, rtx_def const*, char const*, int,
char const*)
../../gcc/gcc/rtl-error.c:110
0x308df7 shorten_branches(rtx_def*)
../../gcc/gcc/final.c:1162
0x3094e3 rest_of_handle_shorten_branches
../../gcc/gcc/final.c:4368
Dave
--
John David Anglindave.ang...@bell.net
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #13 from dave.anglin at bell dot net 2012-11-07 00:39:01 UTC --- On 6-Nov-12, at 10:40 AM, amylaar at gcc dot gnu.org wrote: I see now that you get INT_MAX substituted as the maximum length if the value is unknown. If you add anything to that, the value becomes negative. I suppose your only get-out-of-jail card with the current interface, if you can't/won't provide a full cond with constant values, is to let ADJUST_INSN_LENGTH obliterate the MAX_INT, and replace it with something sensible. It appears that I need to provide the min length instead of the max length in the opaque condition. Maybe if I just avoid incrementing the length in ADJUST_INSN_LENGTH when it is MAX_INT, then the error won't occur. For the call patterns, the number of permutations got out of hand and impossible to maintain. Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/54713] [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54713 --- Comment #11 from dave.anglin at bell dot net 2012-11-07 17:17:47 UTC --- On 11/7/2012 8:29 AM, jakub at gcc dot gnu.org wrote: Which test started failing? pr53410 was failing here http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg02016.html but the problem seems to have gone away in later runs. Dave
[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56242
--- Comment #4 from dave.anglin at bell dot net 2013-02-13 14:09:26 UTC ---
On 2013-02-12 6:03 PM, vries at gcc dot gnu.org wrote:
I've tried to reproduce this bug by building a cross compiler using the
hppa2.0w-unknown-linux-gnu target. I managed to build libjava, but I didn't
manage to reproduce the bug.
Yes. it doesn't reproduce on linux.
The thing I can see that's wrong is in NEXT_INSN (insn 11), which is note 152
but which should be note 153:
...
(insn 428 427 153 (sequence [
(jump_insn:TI 151 427 11 (set (pc)
(if_then_else (eq (reg:SI 28 %r28 [orig:123 D.12040+-2 ]
[123])
(const_int 10 [0xa]))
(label_ref:SI 165)
(pc)))
/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:162
28 {*pa.md:1439}
(expr_list:REG_DEAD (reg:SI 28 %r28 [orig:123 D.12040+-2 ]
[123])
(expr_list:REG_BR_PROB (const_int 2800 [0xaf0])
(nil)))
- 165)
(insn 11 151 152 (set (reg:SI 7 %r7 [orig:129 D.12038 ] [129])
(reg:SI 5 %r5 [orig:132 ivtmp.903 ] [132])) 40
{*pa.md:2211}
(nil))
])
/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:162
-1
(nil))
(note 153 428 152 [bb 19] NOTE_INSN_BASIC_BLOCK)
(note 152 153 276 19 (*L$Jpc=71164) NOTE_INSN_DELETED_LABEL 395)
...
I'll give your patch a try later today when my current build and check
finishes. I could give you
access to this test system if the change doesn't work out.
Thanks for looking at this bug.
[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56242 --- Comment #7 from dave.anglin at bell dot net 2013-02-14 13:56:13 UTC --- Patch fixes ICE on hppa2.0w-hp-hpux11.11. Testsuite running...
[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56346 --- Comment #2 from dave.anglin at bell dot net 2013-02-15 15:55:07 UTC --- On 2013-02-15 9:44 AM, jakub at gcc dot gnu.org wrote: Target doesn't use crtstuff.c. Why? That looks like the bug to me. It only supports ELF and COFF file formats, and not SOM.
[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra Created a debug-only replacement for s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56307
--- Comment #11 from dave.anglin at bell dot net 2013-03-12 18:27:01 UTC ---
On 3/12/2013 1:59 PM, jakub at gcc dot gnu.org wrote:
I think -fvar-tracking-assignments is disabled by default if selective
scheduler is enabled, but I doubt that is the case of pa. In any case, you
could try
to add -fvar-tracking-assignments explicitly to dg-options.
This does seem to make a difference:
;; Function foo (foo, funcdef_no=0, decl_uid=1351, cgraph_uid=0)
Created a debug-only replacement for s offset: 0, size: 32
Created a debug-only replacement for s offset: 32, size: 8
Created a debug-only replacement for s offset: 40, size: 8
Created a debug-only replacement for s offset: 48, size: 16
foo (int x)
{
char * p;
struct S s;
Dave
[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra Created a debug-only replacement for s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56307 --- Comment #12 from dave.anglin at bell dot net 2013-03-13 01:50:05 UTC --- On 12-Mar-13, at 1:48 PM, jamborm at gcc dot gnu.org wrote: I'm just guessing, but is it possible that MAY_HAVE_DEBUG_STMTS is 0 even with -g on hppa-hpux? Yes, your guess is correct. 1) In dbx_debug_hooks, var_location is debug_nothing_rtx. 2) This causes flag_var_tracking to be set to 0 at toplev.c:1412. 3) flag_selective_scheduling and flag_selective_scheduling2 are both 0, so flag_var_tracking_assignments is set to flag_var_tracking at toplev.c:1435. This only happens when flag_var_tracking_assignments initially has the AUTODETECT_VALUE. Explicitly passing the -fvar_tracking_assignments option overrides this. -- John David Anglindave.ang...@bell.net
[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56346 --- Comment #7 from dave.anglin at bell dot net 2013-03-13 15:23:11 UTC --- On 3/13/2013 10:42 AM, jason at gcc dot gnu.org wrote: That's odd, the change seems unlikely to have changed the flow analysis. But anyway, this patch always initializes addr. Better? I hacked the original patch to avoid the error. Change fixed the test failures, so approach looks good. Will test new patch.
[Bug libstdc++/56841] [4.9 Regression] ld: Unsatisfied symbol __atomic_exchange_8 in file /test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh_terminate.o]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56841 --- Comment #2 from dave.anglin at bell dot net 2013-04-04 15:57:16 UTC --- On 4-Apr-13, at 11:41 AM, redi at gcc dot gnu.org wrote: Drat, I completely forgot these still aren't available everywhere, sorry. There's some kind of implementation in libatomic but it hasn't been built when the error occurs. -- John David Anglindave.ang...@bell.net
[Bug libstdc++/56841] [4.9 Regression] ld: Unsatisfied symbol __atomic_exchange_8 in file /test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh_terminate.o]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56841 --- Comment #5 from dave.anglin at bell dot net 2013-04-06 15:18:44 UTC --- --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-05 10:14:42 UTC --- Dave, does it work after rev 197512 ? Two thumbs up! Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57027 --- Comment #6 from dave.anglin at bell dot net 2013-05-03 11:27:33 UTC --- On 3-May-13, at 6:11 AM, amylaar at gcc dot gnu.org wrote: The preprocessed testcase from the first attachment fails needs a different sanity check in convert_mult_to_fma, which I have added in this amended patch. Yes, I just found that build still fails with first patch at same place. Will try amended patch. -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57027 --- Comment #7 from dave.anglin at bell dot net 2013-05-04 23:03:36 UTC --- On 3-May-13, at 6:11 AM, amylaar at gcc dot gnu.org wrote: Created attachment 30016 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30016 amended patch Works for me. Thanks, Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52999 --- Comment #10 from dave.anglin at bell dot net 2012-04-24 18:18:07 UTC --- On 4/24/2012 5:35 AM, jakub at gcc dot gnu.org wrote: What happens on this testcase is default_elf_select_rtx_section and the PA specific part of that is just that PA needs any constants that need relocations pushed into the constant pool, other targets don't. So, it's probably the procedure labels which cause the problem.
[Bug other/53143] [4.8 Regression] ' in c_tree_printer, at c-objc-common.c:136
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53143 --- Comment #3 from dave.anglin at bell dot net 2012-04-27 19:24:24 UTC --- On 4/27/2012 3:18 PM, manu at gcc dot gnu.org wrote: Can you try with the latest revision? I think I fixed this already. Ok, I'll give it a try.
[Bug c++/53261] [4.8 Regression] ICE in tree_strip_nop_conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53261 --- Comment #4 from dave.anglin at bell dot net 2012-05-08 15:26:51 UTC --- On 5/7/2012 12:25 PM, manu at gcc dot gnu.org wrote: Could you test on hppa? The patch fixes the compilation error. Actually, I am not sure whether if (!tem || integer_zerop (tem)) is even better. Dave
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #11 from dave.anglin at bell dot net 2012-05-08 19:23:48 UTC --- On 5/8/2012 3:03 PM, steven at gcc dot gnu.org wrote: Is that old a glibc still supported? The following still works except for libitm: dave@selway:/lib /lib/libc.so.6 GNU C Library stable release version 2.6.1 (20070803), by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Configured for i686-suse-linux. Compiled by GNU CC version 4.2.1 (SUSE Linux). Compiled on a Linux 2.6.22 system on 2007-10-23. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson NoVersion patch for broken glibc 2.0 binaries Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. Note however that NPTL is being used instead of linuxthreads. I know parisc had switched to NPTL in Debian lenny. It's possible to update to unstable from lenny but it's a bit of work. Dave
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #15 from dave.anglin at bell dot net 2012-05-09 18:45:15 UTC --- On 5/9/2012 1:12 PM, redi at gcc dot gnu.org wrote: We might want to put something in config/os/gnu-linux/os_defines.h so that the macro is defined when using linuxthreads I'm thinking a test needs to be added to GLIBCXX_CHECK_GTHREADS in acinclude.m4. Dave
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #18 from dave.anglin at bell dot net 2012-05-10 00:55:14 UTC --- On 9-May-12, at 8:41 PM, jimis at gmx dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #16 from jimis jimis at gmx dot net 2012-05-10 00:41:04 UTC --- (In reply to comment #14) I'm pretty sure we've already dealt with this failure elsewhere, IIRC the linuxthreads pthread_mutex_t type has a volatile member causing the default assignment operator to be deleted. In the past we had faced a similar problem, I found the patch I think you had given me (attached). Could give a solution but doesn't apply cleanly now. I think gthr-posix.h in libgcc contains the overrides. Could you check if providing the suggested defines in the libstdc++ linux os_defines.h resolves the issue? If that works, it's just a matter of how to detect linuxthreads and provide the defines. Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381
--- Comment #3 from dave.anglin at bell dot net 2012-05-16 23:01:00 UTC ---
On 16-May-12, at 6:30 PM, bernds at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381
--- Comment #2 from Bernd Schmidt bernds at gcc dot gnu.org
2012-05-16 22:30:53 UTC ---
What's it actually trying to access, and failing? Is dest NULL or
something?
It's call_set that's NULL.
(gdb) p debug_rtx (insn)
(call_insn 563 562 565 41 (parallel [
(set (reg:SI 4 %r4)
(reg:SI 19 %r19))
(set (reg:SI 28 %r28)
(call (mem:SI (symbol_ref/v:SI (@memcpy) [flags
0x241] function_decl 0x4163e980 memcpy) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (reg:SI 4 %r4))
(use (reg:SI 19 %r19))
(use (const_int 0 [0]))
]) ../../../gcc/libgcc/unwind-dw2.c:1028 206
{call_val_symref_pic}
(expr_list:REG_RETURNED (reg/v/f:SI 20 %r20 [orig:99 new_rs ]
[99])
(expr_list:REG_DEAD (reg:SI 26 %r26)
(expr_list:REG_DEAD (reg:SI 25 %r25)
(expr_list:REG_DEAD (reg:SI 24 %r24)
(expr_list:REG_UNUSED (reg:SI 28 %r28)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:REG_CC_SETTER (set (reg:SI 28 %r28)
(reg:SI 26 %r26))
(expr_list:REG_CC_SETTER (use (reg:SI 24 %r24))
(expr_list:REG_CC_SETTER (use (reg:SI 25 %r25))
(expr_list:REG_CC_SETTER (use (reg:SI 26 %r26))
(nil))
--
John David Anglindave.ang...@bell.net
[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381 --- Comment #5 from dave.anglin at bell dot net 2012-05-17 00:18:46 UTC --- On 16-May-12, at 7:14 PM, bernds at gcc dot gnu.org wrote: Ok, seriously weird call insns. If you can fix that in the port, it'll benefit from the optimization. Otherwise, try the following which disables it for targets with strange call insns. Agreed. In PIC, the runtime architecture mandates that the PIC register is saved and restored across function calls. It's been quite a few years since the current scheme was worked out. There were previous implementations where the save wasn't part of the call but there were always occasional cases where the restore was lost resulting in wrong code. Part of the problem is not all uses of the PIC register are exposed prior to reload. There are splitters to optimize things a bit after reload. I'm reluctant to change the current implementation because the situation is quite tricky. Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381 --- Comment #6 from dave.anglin at bell dot net 2012-05-17 01:52:03 UTC --- On 16-May-12, at 7:14 PM, bernds at gcc dot gnu.org wrote: Ok, seriously weird call insns. If you can fix that in the port, it'll benefit from the optimization. Otherwise, try the following which disables it for targets with strange call insns. I'll try this on the weekend. It may be fairly easy. -- John David Anglindave.ang...@bell.net
[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381 --- Comment #9 from dave.anglin at bell dot net 2012-05-17 14:39:41 UTC --- On 5/17/2012 2:48 AM, jakub at gcc dot gnu.org wrote: Note that e.g. dse.c (scan_insn) handles the AVX mem* just fine, but won't handle this PA pattern because (set (reg) (call ...)) isn't the first thing in the parallel. Any reason for that? There is no reason other than the RTL was trying to reflect the save and restore of the PIC register. I hacked the call patterns to completely hide the handling of the PIC register until they are split after reload. So far, testing looks ok.
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 --- Comment #29 from dave.anglin at bell dot net 2012-05-20 14:18:39 UTC --- On 20-May-12, at 6:41 AM, jimis at gmx dot net wrote: init2.c:52: MPFR assertion failed: p = 2 p = ((mpfr_prec_t) ((mpfr_uprec_t) ~(mpfr_uprec_t)0)1)) built-in:0:0: internal compiler error: Aborted Probably, mpfr, gmp, binutils, etc need updating. Dave -- John David Anglindave.ang...@bell.net
[Bug rtl-optimization/53373] [4.8 regression] ICE on valid code with -march-native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373 --- Comment #8 from dave.anglin at bell dot net 2012-05-20 18:21:37 UTC --- On 20-May-12, at 1:10 PM, vincenzo.innocente at cern dot ch wrote: revision 187695 does not solve PR53393 I didn't say it did and I didn't merge the PRs. In particular, a PA issue was merged with a x86_64 issue. For PA, the patch avoids the problematic code in the middle-end and improves call optimization. There is a generic fix posted for PR53381 that might resolve the x86_64 ICE reported here. I assume the ICE occurs because the x86_64 call pattern contains an UNSPEC. See also comment 7 in PR53381. -- John David Anglindave.ang...@bell.net
[Bug middle-end/53813] [4.7 Regression] ICE in fold_convert_loc, at fold-const.c:2016
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53813 --- Comment #1 from dave.anglin at bell dot net 2012-06-29 23:17:13 UTC --- Attached preprocessed source. -- John David Anglindave.ang...@bell.net
[Bug debug/53820] [4.8 Regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8029
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53820 --- Comment #4 from dave.anglin at bell dot net 2012-07-03 12:46:16 UTC --- On 7/2/2012 11:20 AM, aoliva at gcc dot gnu.org wrote: This patchlet for var-tracking.c fixes the testcase. I'm now testing it on x86_64. John, would you be so kind as to try to bootstrap it on hppa64-hp-hpux11.11 to make sure no other such problem remains? TIA, Alex, the patch fixes bootstrap and I see no new issues. Thanks, Dave
[Bug testsuite/54007] lto15.adb fails: gnat1: error: LTO support has not been enabled in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54007
--- Comment #2 from dave.anglin at bell dot net 2012-07-18 22:11:24 UTC ---
On 18-Jul-12, at 4:37 AM, rguenth at gcc dot gnu.org wrote:
Supposedly also on trunk. Would need { dg-require-effective-target
lto }.
Can you check if that works for gnat.dg?
Yes, it works.
--
John David Anglindave.ang...@bell.net
[Bug target/53974] [4.8 Regression] Nearly all tests fail with ADA.CALENDAR.TIME_ERROR : a-calend.adb:603
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 --- Comment #3 from dave.anglin at bell dot net 2012-07-19 00:33:48 UTC --- On 18-Jul-12, at 6:15 AM, ebotcazou at gcc dot gnu.org wrote: I have seen the same error on SPARC. The fix is * config/sparc/sparc.md (adddi3_insn_sp32): Add earlyclobber. so you might want to try something similar on line 4923 of pa.md. Eric, thanks very much! Even if this doesn't fix the bug, this is obviously a bug. Dave -- John David Anglindave.ang...@bell.net
[Bug target/53974] [4.8 Regression] Nearly all tests fail with ADA.CALENDAR.TIME_ERROR : a-calend.adb:603
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 --- Comment #4 from dave.anglin at bell dot net 2012-07-20 12:16:37 UTC --- On 18-Jul-12, at 6:15 AM, ebotcazou at gcc dot gnu.org wrote: I have seen the same error on SPARC. The fix is * config/sparc/sparc.md (adddi3_insn_sp32): Add earlyclobber. so you might want to try something similar on line 4923 of pa.md. I don't think there is an earlyclobber problem in the insn at 4923. I reviewed pa.md for missing earlyclobbers and found a few. Some are likely not problems because of alternative ordering. In any case, fixing them didn't change the situation. I presume the problem was introduced with this change: 2012-05-15 Hristian Kirtchev kirtc...@adacore.com * a-calend.adb (Day_Of_Week): The routine once again treats The Month value extracted by __gnat_split is wrong and it fails this comparison: 0x000105bc +68:ldo -1(r21),r22 0x000105c0 +72:cmpib, b,r22,0x10618 ada__calendar__split+160 (gdb) p $r22 $15 = 12 Have to run, Dave -- John David Anglindave.ang...@bell.net
[Bug target/53974] [4.8 Regression] Nearly all tests fail with ADA.CALENDAR.TIME_ERROR : a-calend.adb:603
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 --- Comment #6 from dave.anglin at bell dot net 2012-07-20 13:28:47 UTC --- On 7/20/2012 8:26 AM, ebotcazou at gcc dot gnu.org wrote: SPARC has essentially the same pattern (it's a splitter though) and there was a missing early clobber because there is no guarantee that DImode registers all start on an even register in 32-bit mode: it's false for DImode arguments. I believe that the definition of HARD_REGNO_MODE_OK on PA prevents partially overlapping DImode registers. See comment comment for HARD_REGNO_MODE_OK . So, clobbering %R0 can't affect %1.
[Bug target/53974] [4.8 Regression] Nearly all tests fail with ADA.CALENDAR.TIME_ERROR : a-calend.adb:603
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 --- Comment #8 from dave.anglin at bell dot net 2012-07-20 17:20:29 UTC --- On 7/20/2012 11:01 AM, ebotcazou at gcc dot gnu.org wrote: Sure, just like on SPARC, but DImode arguments can nevertheless be unaligned. I've never seen this. In addition to HARD_REGNO_MODE_OK, the definition of CANNOT_CHANGE_MODE_CLASS prevents mode changes to larger modes when it is greater than UNITS_PER_WORD.
[Bug target/53974] [4.8 Regression] Nearly all tests fail with ADA.CALENDAR.TIME_ERROR : a-calend.adb:603
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 --- Comment #10 from dave.anglin at bell dot net 2012-07-20 18:48:25 UTC --- On 7/20/2012 1:42 PM, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-07-20 17:42:19 UTC --- I've never seen this. In addition to HARD_REGNO_MODE_OK, the definition of CANNOT_CHANGE_MODE_CLASS prevents mode changes to larger modes when it is greater than UNITS_PER_WORD. On SPARC, this is specified by the 32-bit ABI: if you have void foo(int32_t a, int64_t b) b will be loaded into DImode %o1, which is SImode %o1 SImode %o2. On PA, b will be loaded into the second DImode call argument register which is the r23/r24 register pair. HARD_REGNO_MODE_OK is defined in a manner that is consistent with the calling conventions.
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #12 from dave.anglin at bell dot net 2012-07-31 20:10:55 UTC --- Mine. Expected result for testcase is 112975202 (0x6bbdd62). Miscompiled result is 116077092194 (0x1b06bbdd62). -- John David Anglindave.ang...@bell.net
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823
--- Comment #14 from dave.anglin at bell dot net 2012-07-31 22:54:59 UTC ---
On 31-Jul-12, at 5:29 PM, rth at gcc dot gnu.org wrote:
How does this -O1 output compare with native?
There seems to an off by one error in various shifts, etc. For
example,
;(insn 8 4 10 (set (reg:SI 19 %r19 [104])
;(lshiftrt:SI (reg:SI 24 %r24 [orig:100 y+4 ] [100])
;(const_int 27 [0x1b]))) xxx.c:5 179 {lshrsi3}
; (nil))
extru %r24,4,5,%r19 ; 8 lshrsi3/2 [length = 4]
With 4.6, I see something similar to what you see:
;(insn 8 62 10 (set (reg:SI 20 %r20 [104])
;(lshiftrt:SI (reg:SI 24 %r24 [orig:136+4 ] [136])
;(const_int 28 [0x1c]))) xxx.c:5 178 {lshrsi3}
; (nil))
extru %r24,3,4,%r20 ; 8 lshrsi3/2 [length = 4]
--
John David Anglindave.ang...@bell.net
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #15 from dave.anglin at bell dot net 2012-07-31 22:55:54 UTC --- Created attachment 27916 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27916 zz.s.txt
[Bug plugins/54148] FAIL: gcc.dg/plugin/selfassign.c compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54148 --- Comment #2 from dave.anglin at bell dot net 2012-08-01 13:10:36 UTC --- On 1-Aug-12, at 3:47 AM, rguenth at gcc dot gnu.org wrote: I don't see any error in that? Test just fails with no message. -- John David Anglindave.ang...@bell.net
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #19 from dave.anglin at bell dot net 2012-08-01 14:20:49 UTC --- On 31-Jul-12, at 10:25 PM, rth at gcc dot gnu.org wrote: The cross-compile *ought* not to affect costs, which means that we ought to be making the same algorithm choices. Which suggests that -- if this is a fully bootstrapped pa compiler -- you're looking at some part of expand_mult itself being mis-compiled. I was afraid this might be the case. However, I built a non bootstrap compiler this morning with -g -O1. The testcase still fails at -O0 and O1, and works at -O2. The compiler was configured as follows: dave@mx3210:~/gnu/gcc/objdir/gcc$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa-linux-gnu Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable- shared --enable-multiarch --with-multiarch-defaults=hppa-linux-gnu -- enable-linker-build-id --build=hppa-linux-gnu --host=hppa-linux-gnu -- target=hppa-linux-gnu --prefix=/home/dave/opt/gnu/gcc/gcc-4.7.0 --with- local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable- __cxa_atexit --build=hppa-linux-gnu --enable-clocale=gnu --enable-java- gc=boehm --enable-languages=c --disable-bootstrap Thread model: posix gcc version 4.8.0 20120801 (experimental) [trunk revision 190037] (GCC) You probably would need to add --with-arch=1.1 to duplicate the default native settings with a cross. The difference in extracts and deposits may not be the problem. The - O2 code appears to have the same extracts as the -O1 code. I'll see if I can find where the real difference arises. -- John David Anglindave.ang...@bell.net
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #20 from dave.anglin at bell dot net 2012-08-01 14:27:30 UTC --- On 1-Aug-12, at 10:20 AM, dave.anglin at bell dot net wrote: The difference in extracts and deposits may not be the problem. The - O2 code appears to have the same extracts as the -O1 code. I'll see if I can find where the real difference arises. Doh, the correct result is inlined at -O2. foo is still mis-compiled. -- John David Anglindave.ang...@bell.net
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #8 from dave.anglin at bell dot net --- On 25-Jul-13, at 12:51 AM, jasonwucj at gmail dot com wrote: John, does your case happen on 32-bit only as well? Yes. -- John David Anglindave.ang...@bell.net
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #9 from dave.anglin at bell dot net --- On 25-Jul-13, at 6:56 AM, amylaar at gcc dot gnu.org wrote: hwint.h says that HOST_WIDE_INT should be 64 bit when targeting a machine with 64 bit size_t. You can insure that by setting need_64bit_hwint in gcc/config.gcc / libcpp/configure.ac . Although the former has a different description what it's for. So either the comment there is lacking, or the comment in hwint.h just says how to paper over bugs in various (?) places in the compiler that don't use the highpart of an INTEGER_CST for what it's for. The 32-bit linux and hpux targets have a 32-bit size_t and the error occurs with a native build. Dave -- John David Anglindave.ang...@bell.net
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #2 from dave.anglin at bell dot net ---
On 5-Sep-13, at 7:31 PM, hubicka at ucw dot cz wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #1 from Jan Hubicka hubicka at ucw dot cz ---
Symbol has type data which is wrong for procedure label:
Symbols from system_error.o:
ValueInfo Type Scope ck HQIRCDSKLN xl reloc Name
Data Unsat 0 .. 3 0
_ZNKSt14error_category23default_error_conditionEi.localalias.9
The code introduces the symbol as an static alias of function.
I.e. something like
void foo (void) { }
void foo.localalias (void) __attribute__ ((alias foo));
Can this be latent bug in HPPA backend not handling well aliases
like this?
(this was indeed an issue on AIX).
I wouldn't be surprised.
I don't have assembler output or preprocessed source yet. There is
some alias
support in gas for HP-UX but I believe it may not work when we have a
call using
a function descriptor (plabel).
Dave
--
John David Anglindave.ang...@bell.net
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #5 from dave.anglin at bell dot net --- On 6-Sep-13, at 3:54 AM, hubicka at ucw dot cz wrote: I hoped that the targets either do not have runtime interposition in dynamic libraries or they do have working notion of alias. The PA-RISC HP-UX linker interposes import and export stubs in dynamic libraries. Whether there is a working notion of alias is somewhat unclear and involves digging into the linker code. The HP assembler doesn't support aliases. There is some support in gas. I will try to look at the testcase assembler code tonight. Dave -- John David Anglindave.ang...@bell.net
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #9 from dave.anglin at bell dot net --- On 6-Sep-13, at 8:05 AM, hubicka at ucw dot cz wrote: perhaps we want to simply check for ASM_OUTPUT_DEF in symtab and refuse to use local aliases then? I think the other macros alow only weak aliases. The attached patch gets past the error. Testing. Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/58382] [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58382 --- Comment #3 from dave.anglin at bell dot net --- Agreed. Testing fix. Thanks, Dave
[Bug libfortran/58015] FAIL: gfortran.dg/round_4.f90: Unsatisfied symbol nextafterl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58015 --- Comment #3 from dave.anglin at bell dot net --- On 21-Sep-13, at 11:13 AM, dominiq at lps dot ens.fr wrote: Is this PR different from pr58113 beside the missing nextafterl on hppa64-hp-hpux11.11? Don't know. It looks like libquadmath has nextafter, so it may be possible to fix this. Dave -- John David Anglindave.ang...@bell.net
[Bug libfortran/58015] FAIL: gfortran.dg/round_4.f90: Unsatisfied symbol nextafterl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58015 --- Comment #4 from dave.anglin at bell dot net --- On 9/21/2013 11:13 AM, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58015 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is this PR different from pr58113 beside the missing nextafterl on hppa64-hp-hpux11.11? I hacked c99_functions.c to provide nextafterl using nextafterq from libquadmath. With this, I see the bug in pr58113. Regarding nextafterl, I'm thinking about an include hack to math.h for hppa*-*-hpux11*. On all HP-UX systems, the l and q long double and quad math functions are equivalent. Dave
