[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49511
--- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-06-28 18:46:19 UTC ---
On Tue, 28 Jun 2011, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49511
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-06-28 17:58:01 UTC ---
505 (hiauly1)dave /bin/sh
$ type -p gnatmake 2/dev/null
gnatmake is /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
$ echo $?
0
Drats, sh silently ignores -p. The following (untested) patch should
cope with this:
Could you give it a try?
The following revised patch works. There was a missing quote and
the problem also affects HP-UX 11. I just never hit it since I always
build with bash.
Index: ada/acats/run_acats
===
--- ada/acats/run_acats(revision 175188)
+++ ada/acats/run_acats(working copy)
@@ -10,11 +10,11 @@
# type -p is missing from Solaris 2 /bin/sh and /bin/ksh (ksh88), but both
# ksh93 and bash have it.
# type output format differs between ksh88 and ksh93, so avoid it if
-# type -p is present.
+# type -p is present. Unfortunately, HP-UX /bin/sh ignores -p with type.
# Fall back to whence which ksh88 and ksh93 provide, but bash does not.
which () {
-path=`type -p $* 2/dev/null` { echo $path; return 0; }
+path=`type -p $* 2/dev/null | awk '{print $NF}'` { echo $path; return
0; }
path=`type $* 2/dev/null | awk '{print $NF}'` { echo $path; return 0;
}
path=`whence $* 2/dev/null` { echo $path; return 0; }
return 1
Thanks,
Dave
[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49511 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-06-27 17:15:23 UTC --- could you please run the exact commands used in the run_acats which function and report the results: type -p gnatmake 2/dev/null echo $? type gnatmake 2/dev/null echo $? whence gnatmake 2/dev/null echo $? 505 (hiauly1)dave /bin/sh $ type -p gnatmake 2/dev/null gnatmake is /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake $ echo $? 0 $ $ type gnatmake 2/dev/null gnatmake is /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake $ echo $? 0 $ $ whence gnatmake 2/dev/null /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake $ echo $? 0 522 (hiauly1)dave echo $SHELL /usr/local/bin/bash 523 (hiauly1)dave type -p gnatmake 2/dev/null /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake 524 (hiauly1)dave echo $? 0 525 (hiauly1)dave type gnatmake 2/dev/null gnatmake is hashed (/opt/gnu/gcc/gcc-3.3.4/bin/gnatmake) 526 (hiauly1)dave echo $? 0 527 (hiauly1)dave whence gnatmake 2/dev/null 528 (hiauly1)dave echo $? 127 `which' is available on HP-UX in both standard POSIX shell and bash: 529 (hiauly1)dave /bin/sh $ which gnatmake 2/dev/null /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake $ echo $? 0 $ 530 (hiauly1)dave echo $SHELL /usr/local/bin/bash 531 (hiauly1)dave which gnatmake 2/dev/null /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake 532 (hiauly1)dave echo $? 0 Dave
[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49500 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2011-06-23 21:36:05 UTC --- On Thu, 23 Jun 2011, hubicka at gcc dot gnu.org wrote: Hi, the problem is that emultls introduces aliases later and it does not understand the new representation of them. Does the attached patch help? There is a warning which may not be new: ../../gcc/gcc/tree-emutls.c: In function 'ipa_lower_emutls': ../../gcc/gcc/tree-emutls.c:776: warning: 'cvar' may be used uninitialized in this function Dave
[Bug ada/46350] s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46350 --- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2011-06-21 13:38:12 UTC --- Try to remove the cast to System.Interrupt_Management.Interrupt_ID in the call. It fixes the compile error. Testing in progress... Dave
[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-06-21 17:23:27 UTC --- I should have mentioned in comment #2 that the build and test I did included the proposed patch in comment #11 pf PR 49429. I assumed so. Richard's comments regarding the patch indicated that it was unlikely to fix all the problems on hppa (a callee copies target). Dave
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191
--- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2011-06-08 17:59:18 UTC ---
Perhaps something like:
union { int i; char c[8]; } u;
int
main ()
{
int *p;
asm volatile ( : =r (p) : 0 (u.c[1]));
*p++;
return 0;
}
compile+run and check for zero exit code? Perhaps __ia64__ should be
explicitly listed as strict alignment in addition to that, because I believe
it
will
succeed there, just with annoying messages in dmesg.
Same on hppa-linux. Kernel will fixup unaligned access.
Dave
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 --- Comment #18 from dave at hiauly1 dot hia.nrc.ca 2011-05-31 00:03:14 UTC --- Bootstrap restored on i686-apple-darwin9. Dave
[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 --- Comment #20 from dave at hiauly1 dot hia.nrc.ca 2011-05-23 18:52:27 UTC --- On Mon, 23 May 2011, ebotcazou at gcc dot gnu.org wrote: This code fails to handle the case where there already is a use. This should have been fixed in 4.5 and above: PR rtl-optimization/40086 * reorg.c (relax_delay_slots): When looking for redundant insn at the branch target, use next_real_insn, not next_active_insn. Yes, looks like the fix. This appears to be a regression given the comment about using next_real_insn in fill_simple_delay_slots. Ok to backport this fix after testing to 4.3 and 4.4? I would also like to backport this fix PR rtl-optimization/42775 * cfgrtl.c (rest_of_pass_free_cfg): Recompute notes if delay slot scheduling is enabled. Hopefully, this will fix delay branch handling on these branches. Dave
[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 --- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2011-05-21 14:57:02 UTC --- Could this have been fixed by PR 42775 which does not change reorg but rather free_cfg? No. I have tried it on hppa2.0w-hp-hpux11.11 and just tried it with darwin cross. Eric had mentioned it when I backported the fix for PR 45593. I'm not sure why the ldo instruction at the branch target isn't deleted when it is added to the delay slot. Dave
[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-05-16 16:22:28 UTC --- On Mon, 16 May 2011, danglin at gcc dot gnu.org wrote: By trial and error, it appears tree-cfgcleanup.c is miscompiled at -O1 without -fno-delayed-branch. Attached .i file. Dave
[Bug middle-end/48932] ICE in check_dep, at sched-deps.c:4097
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48932 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-05-09 13:44:04 UTC --- On Sun, 08 May 2011, danglin at gcc dot gnu.org wrote: Appears to be fixed in 4.5 and 4.6. Actually, bug is in 4.5.1 but not 4.5.3. The only relevant fix that I see is: 2010-09-15 Eric Botcazou ebotca...@adacore.com PR rtl-optimization/45593 * reorg.c (relax_delay_slots): Use emit_copy_of_insn_after to re-emit insns that were in delay slots as stand-alone insns. Dave
[Bug middle-end/48932] ICE in check_dep, at sched-deps.c:4097
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48932 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-05-08 22:47:52 UTC --- Attached sched-deps.i.gz. The branch has been incorrectly placed in the delay slot. The ldil instruction is needed when the branch is taken but not when the branch is not taken. cc1 args: -iprefix /test/gnu/gcc/objdir/gcc/../lib/gcc/hppa2.0w-hp-hpux11.11/4.7.0/ -isys tem gcc/include -isystem gcc/include-fixed xxx.c -quiet -dumpbase xxx.c -auxbase xxx -O2 -version -o xxx.s Dave
[Bug middle-end/48905] [4.7 Regression] STORAGE_ERROR : stack overflow (or erroneous memory access) compiling namet.adb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48905 --- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2011-05-07 14:46:56 UTC --- On Sat, 07 May 2011, danglin at gcc dot gnu.org wrote: Introduced in revision 173428. Testing cris-elf fix. The attached patch fixes this PR. It was derived from the change posted here and Eric's subsequent comment: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00491.html Dave
[Bug middle-end/48893] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:477
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48893 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2011-05-05 23:33:46 UTC --- Attached .i. cc1 compile args are: -fpreprocessed pex-unix.i -quiet -dumpbase pex-unix.c -auxbase-strip pic/pex-unix.o -g -O2 -Wextra -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -version -fPIC -o pex-unix.s Dave
[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48752 --- Comment #14 from dave at hiauly1 dot hia.nrc.ca 2011-04-27 15:20:32 UTC --- I still can't reproduce the testcase but I guess I can make one myself just by forcing global constructor. Will try to have patch before lunch. I realized last night that I could probably find a simpler testcase by running the C testsuite. Dave
[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48752 --- Comment #16 from dave at hiauly1 dot hia.nrc.ca 2011-04-27 21:08:26 UTC --- On Wed, 27 Apr 2011, hubicka at ucw dot cz wrote: I hope the problem is now fixed at mainline tree. Could you please give it a try? Bug is still present in revision 173047. Running C testsuite. Dave
[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48752 --- Comment #11 from dave at hiauly1 dot hia.nrc.ca 2011-04-26 18:11:43 UTC --- Any clue what is wrong? After dinner I will try to look into the add_new_function path and figure out why summaries are not computed as they should. These are the args I used in debugging cc1plus with the testcase: -fpreprocessed stdc++.ii -quiet -dumpbase stdc++.h -auxbase stdc++ -g -g -O2 -O2 -std=gnu++0x -version -o stdc++.s --output-pch= hppa2.0w-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch Does that help? Dave
[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48752 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2011-04-24 13:49:30 UTC --- Attached .ii file. Dave
[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48752 --- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2011-04-24 19:13:22 UTC --- --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-24 18:27:20 UTC --- evaulate?!? I believe it must be Czech... Dave
[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48752 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2011-04-24 20:24:00 UTC --- I've comitted patch for bug with similar symptoms today. Does it still reproduce for you? I noticed that and started a couple of new builds. Should know in a couple of hours.
[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48752 --- Comment #6 from dave at hiauly1 dot hia.nrc.ca 2011-04-25 01:27:59 UTC --- On Sun, 24 Apr 2011, John David Anglin wrote: I've comitted patch for bug with similar symptoms today. Does it still reproduce for you? I noticed that and started a couple of new builds. Should know in a couple of hours. The bug is still there.
[Bug middle-end/48441] [4.7 Regression] ICE in mark_oprs_set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48441 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2011-04-04 22:30:50 UTC --- On Mon, 04 Apr 2011, danglin at gcc dot gnu.org wrote: Attached .i. Dave
[Bug target/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48366 --- Comment #7 from dave at hiauly1 dot hia.nrc.ca 2011-04-03 18:37:07 UTC --- I guess that the last patch (for pr48380) I sent should solve the problem too. Unfortunately, I did not get an approval for the patch yet. I'll try it if it isn't install by the time I get to a retest. But the real reason of the problem is in wrong IRA directions. The wrong IRA directions have exposed backend problems in handling reloads for the shift amount register. I think I have a patch to correct these issues. Testing the change now. Thanks, Dave
[Bug target/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48366 --- Comment #8 from dave at hiauly1 dot hia.nrc.ca 2011-04-04 00:34:48 UTC --- On Sun, 03 Apr 2011, John David Anglin wrote: I guess that the last patch (for pr48380) I sent should solve the problem too. Unfortunately, I did not get an approval for the patch yet. I'll try it if it isn't install by the time I get to a retest. ../../gcc/gcc/ira-emit.c: In function `emit_move_list': ../../gcc/gcc/ira-emit.c:938:8: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] Dave
[Bug middle-end/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48366 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2011-03-30 23:30:54 UTC --- Attached .i and relevant rtl dumps.
[Bug debug/48315] ICE in mem_loc_descriptor, at dwarf2out.c:13899
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48315 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-03-29 17:26:17 UTC --- On Tue, 29 Mar 2011, ramana at gcc dot gnu.org wrote: Could you post a pre-processed file here ? Attached.
[Bug target/48288] [4.7 Regression] ld: Unsatisfied symbol __iordi3 in file /test/gnu/gcc/objdir/./gcc/libgcc_eh.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48288 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-03-25 15:52:22 UTC --- I'd say PA64 should handle iordi3 w/o libgcc, no? It does. My initial guess is the breakage was introduced by the fix for PR 48263. Dave
[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48209 --- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2011-03-22 19:01:21 UTC --- On Tue, 22 Mar 2011, sje at cup dot hp.com wrote: In running this test on IA64 and x86, the first call is the only one that I see getting inlined on both platforms at all optimization levels. Interesting, the revised test below passes on hppa64-hp-hpux11.11. So, there is some variation in optimization from target to target. Steve, could you xfail of the hpux targets where this fails. Dave
[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48209 --- Comment #11 from dave at hiauly1 dot hia.nrc.ca 2011-03-22 21:05:32 UTC --- Yes, I can do that. Do you know how the test fails on HP-UX 10.*? Does it fail to compile or does it compile and then fail during execution like it does on HP-UX 11.*? It will fail to compile because all four cases are not optimized. So, test should be skipped. Dave
[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48209 --- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2011-03-21 23:03:11 UTC --- It looks like this is broken for HP-UX 11.11 and 11.23. On 11.31 there is a object that can be linked in (unix2003.o) to fix this. Just like we currently link in unix95.0 or unix98.o for UNIX 1995 or UNIX 1998 standards, if you link in unix2003.o then you will get the UNIX 2003 standard and the correct C99 handling of snprintf. That's good to know. We should add 11.31 support and make lonking with unix2003.o the default. So, we have: HP-UX 10.*: no snprintf HP-UX 11.[0-2]*: non standard snprintf HP-UX 11.31: C99 snprintf with unix2003.o In my opinion, the testcase should be testing the GCC implementation of snprintf. If any of the four cases are not optimized by GCC, they should be removed. The HP-UX issues with snprintf aren't unique from what I see on the net. Dave
[Bug bootstrap/48161] [4.6 regression] hppa*-*-* will not bootstrap on 4.6 branch with release checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48161 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2011-03-17 13:51:03 UTC --- On Thu, 17 Mar 2011, jakub at gcc dot gnu.org wrote: Can you please attach preprocessed source and gcc options used to compile it? I'd look with a cross compiler... Attached. Thanks, Dave
[Bug bootstrap/48161] [4.6 regression] hppa*-*-* will not bootstrap on 4.6 branch with release checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48161 --- Comment #6 from dave at hiauly1 dot hia.nrc.ca 2011-03-17 14:25:36 UTC --- /home2/dave/gcc-4.6/objdir/./prev-gcc/xgcc -B/home2/dave/gcc-4.6/objdir/./prev-g cc/ -B/home2/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/bin/ -B/home2/dave/opt/gnu/gc c/gcc-4.6.0/hppa-linux/bin/ -B/home2/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/lib/ -isystem /home2/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/include -isystem /home2/da ve/opt/gnu/gcc/gcc-4.6.0/hppa-linux/sys-include-c -g -O2 -DIN_GCC -W -Wa ll -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissin g-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength -strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I../../g cc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/in clude -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../ libdecnumber../../gcc/gcc/haifa-sched.c -o haifa-sched.o Dave
[Bug bootstrap/48161] [4.6 regression] hppa*-*-* will not bootstrap on 4.6 branch with release checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48161 --- Comment #12 from dave at hiauly1 dot hia.nrc.ca 2011-03-17 18:37:51 UTC --- On Thu, 17 Mar 2011, jakub at gcc dot gnu.org wrote: Untested fix. The reason it uses gen_rtx_PLUS directly is to make sure it doesn't generate code in that case I believe, otherwise expand_binop would have taken care of the swapping of arguments. Patch fixes build failure. Doing full test on hppa-linux. Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #38 from dave at hiauly1 dot hia.nrc.ca 2011-03-10 16:58:38 UTC --- While the latter is fixed, I think the _REENTRANT issue isn't. Or is it? If it it not fixed, I think we should have (a different) PR open to track that issue. Dave, you wrote you were testing a patch for _REENTRANT ... Correct, I have a patch which I have been testing. While it seems to work, there is one issue that I don't particularly like. `-threads' is a multilib option handled completely by the gcc driver. It is not passed to the standard option processing, so I wasn't able to find a way to check for `-threads' in TARGET_OS_CPP_BUILTINS. Currently, I define _REENTRANT whenever we define _HPUX_SOURCE in TARGET_OS_CPP_BUILTINS. It is also defined by CPP_SPEC when -threads is specified. As a result, there are some situations where _REENTRANT is effectively defined twice. This could be avoided if _REENTRANT was only defined in CPP_SPEC but it is difficult to duplicate the option handling in TARGET_OS_CPP_BUILTINS. Since I haven't seen any actual problems with the current patch, I think I will commit it tonight. Dave
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #30 from dave at hiauly1 dot hia.nrc.ca 2011-03-09 00:10:22 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #29 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-08
22:38:49 UTC ---
(In reply to comment #28)
(In reply to comment #26)
Tru64 UNIX doesn't support weak undefined symbols, which seems to be
what weakrefs are.
Hmm, I think it is going to be difficult. What we want to have:
a) If libc has clock_gettime, use it unconditionally
b) If librt has clock_gettime and weak refs are supported, use it if
available
c) If librt has it, but no weak refs are supported, don't use it.
d) If it not available at all, don't use it.
Yes, sounds like a good plan.
(b) and (d) work; also (a) works - albeit with a warning. Now one needs to
support (c).
Indeed; the patch was developed based on the understanding that only Linux has
clock_gettime in librt, and Linux supports weakrefs, so (c) does not need to
be
considered. Oh well.
I think the best would be to set (effectively) HAVE_CLOCK_GETTIME
to false.
One possibility would be to replace:
#ifdef HAVE_CLOCK_GETTIME
# ifdef SUPPORTS_WEAK
...
# else
by
#if define(HAVE_CLOCK_GETTIME) define(SUPPORTS_WEAK)
That would exclude platforms, where libc supports clock_gettime but which do
not have weak refs. Another possibility is a link-time check which does not
work well for some cross-compilations.
What do you think?
I think the easiest way would be to change the test in configure.ac where we
check for clock_gettime in librt, so that we set, say,
HAVE_CLOCK_GETTIME_LIBRT
instead of HAVE_CLOCK_GETTIME, thus allowing us to distinguish whether the
function a) exists at all b) is in libc or librt.
I think it is unnecessary to check whether clock_gettime is in librt
as we don't want libgfortran to depend on librt in general. This reduces
the accuracy when weak references are not supported and clock_gettime
is only in librt. The case where weak references are supported and
clock_gettime isn't available at all seems remote.
If weak references are supported, always define weak_gettime as
__attribute__((__weakref__(clock_gettime))). Probably, the extra
overhead of the runtime check is acceptable.
If weak references are not supported and clock_gettime is in libc,
define weak_gettime as we currently do:
static inline int weak_gettime (clockid_t clk_id, struct timespec *res)
{
return clock_gettime (clk_id, res);
}
Condition the code that uses weak_gettime on either having clock_gettime
in libc or weak references. This could be tweaked to eliminate the `if'
when clock_gettime is in libc.
Dave
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #27 from dave at hiauly1 dot hia.nrc.ca 2011-03-07 17:59:27 UTC --- All fortran testing is broken on Tru64 UNIX, where libgfortran.so has an undefined reference to clock_gettime: The function is defined in librt only. Also with GLIBC Linux one only gets it via librt; on Linux and on HPUX it works via a weakref; seemingly it does not work on Tru64. Does it have weakrefs? Does The function clock_gettime is available in both libc and librt on PA-RISC HP-UX. I see a compilation warning on 32-bit HP-UX that `if (clock_gettime)' will always evaluate to true. Since libc is always linked in, there isn't a problem on PA HP-UX. Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #35 from dave at hiauly1 dot hia.nrc.ca 2011-03-05 17:06:23 UTC --- In testing fix for above, I see: ../../../gcc/libgfortran/intrinsics/ctime.c: In function 'strctime': ../../../gcc/libgfortran/intrinsics/ctime.c:43:20: warning: initialization makes pointer from integer without a cast [enabled by default] Unfortunately, localtime_r has a different proto: int localtime_r(const time_t *timer, struct tm *result); Dave Thanks to some __builtin tricks by Jakub, handling the different return types should now work. However, one more possible issue: In http://docs.hp.com/en/947/d8.html it says the old DCE threads prototype is int localtime_r ( struct tm *result, time_t *clock ); I believe the above document is wrong. Both the HP-UX 10.20 manpage and header show the definition that I quoted. Same for the _PTHREADS_DRAFT4 definition in HP-UX 11.X Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #30 from dave at hiauly1 dot hia.nrc.ca 2011-03-03 13:56:25 UTC --- On Fri, 25 Feb 2011, burnus at gcc dot gnu.org wrote: Please shout loudly if there you still encounter a build failure! TO BE DONE: The HP-UX (et al.?) compile warning regarding the _r functions and _REENTRANT, cf. comment 20 and comment 23. In testing fix for above, I see: ../../../gcc/libgfortran/intrinsics/ctime.c: In function 'strctime': ../../../gcc/libgfortran/intrinsics/ctime.c:43:20: warning: initialization makes pointer from integer without a cast [enabled by default] Unfortunately, localtime_r has a different proto: int localtime_r(const time_t *timer, struct tm *result); Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #26 from dave at hiauly1 dot hia.nrc.ca 2011-02-26 13:59:50 UTC --- On Fri, 25 Feb 2011, burnus at gcc dot gnu.org wrote: I think the build bug is now FIXED; thus: Please shout loudly if there you still encounter a build failure! Building... Should know today but I'm on vacation in Costa Rica. TO BE DONE: The HP-UX (et al.?) compile warning regarding the _r functions and _REENTRANT, cf. comment 20 and comment 23. Testing a fix. I'm 95% certain that _REENTRANT should be defined on HP-UX 10 even when not linking with -lcma (dce thread library). This should provide a build environment closer to HP-UX 11 POSIX environment. We should also always link threaded applications with -lc as libc was enhanced to add reentrant support in HP-UX 10. -lc_r remained for HP-UX 9 compatibility. What is unclear is what happens to the locking needed for some reentrant routines. I'm thinking it should just work as it does on HP-UX 11 when not linking with -lpthread (single thread). There is code in libc to do this locking (_p_mutex_lock/_p_mutex_unlock) but it is hard to tell what it does because it makes a couple of indirect calls. Couldn't find any documentation on this. Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #23 from dave at hiauly1 dot hia.nrc.ca 2011-02-24 14:55:52 UTC --- On Thu, 24 Feb 2011, jb at gcc dot gnu.org wrote: libgfortran.sl is built twice on HP-UX 10, once for the single thread model and once for the dce thread model. It's the single thread build that's the problem. Why is this necessary? Isn't it possible to use the dce thread library from a single threaded application? I believe that it's primarily a performance issue. Threaded applications are linked with -lcma -lc_r. Non threaded applications are linked with -lc. If only the dce thread model was used, there probably would be issues with the GTHREADS interface due to the lack of weak symbols. libc.sl doesn't have dce thread stubs. So, all applications would have to be linked as threaded applications. I suppose one way to fix this would be to somehow make the autoconf checks for the _r functions fail if the prototypes are not found? I'm wondering if the backend should always define _REENTRANT on HP-UX 10. I'd have to check that all the *_r functions are in libc. For libraries that don't explicitly need thread support, it would be good if they could be linked into both threaded and non threaded applications. Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #17 from dave at hiauly1 dot hia.nrc.ca 2011-02-23 14:28:38 UTC --- On Tue, 22 Feb 2011, jb at gcc dot gnu.org wrote: Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01453.html Patch resolves ctime.c build. However, _REENTRANT is not defined, so there are various warnings regarding the declaration of reentrant functions such as localtime_r: libtool: compile: /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/include -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io -I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../../../gcc/libgfortran/../libquadmath -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT ctime.lo -MD -MP -MF .deps/ctime.Tpo -c ../../../gcc/libgfortran/intrinsics/ctime.c -fPIC -DPIC -o .libs/ctime.o ../../../gcc/libgfortran/intrinsics/ctime.c: In function 'fctime': ../../../gcc/libgfortran/intrinsics/ctime.c:43:10: warning: implicit declaration of function 'localtime_r' [-Wimplicit-function-declaration] ../../../gcc/libgfortran/intrinsics/ctime.c:43:20: warning: initialization makes pointer from integer without a cast [enabled by default] Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #18 from dave at hiauly1 dot hia.nrc.ca 2011-02-23 14:30:15 UTC --- On Tue, 22 Feb 2011, jb at gcc dot gnu.org wrote: Patch which should hopefully fix the getpwuid_r issue on HP-UX 10.2: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01478.html Patch fixes the getpwuid_r build issue on HP-UX 10.2. Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #20 from dave at hiauly1 dot hia.nrc.ca 2011-02-23 20:15:34 UTC --- As there localtime_r is also used in intrinsics/date_and_time.c, I would assume that one sees the same message there. Yes. I see them for all _r uses. I am also not quite sure that _REENTRANT is the correct solution. At least for Solaris, one should use _POSIX_C_SOURCE and not _REENTRANT to get the POSIX version, cf. http://download.oracle.com/docs/cd/E19455-01/806-5257/compile-4/ I looked at the headers. On HP-UX 11, _REENTRANT is defined by sys/stdsyms.h if _POSIX_C_SOURCE is defined and _REENTRANT is not defined. However, this does not occur on HP-UX 10. The system headers never define _REENTRANT. The default _HPUX_SOURCE is equivalent to -D_POSIX_C_SOURCE=199506L on HP-UX 11. Defining _REENTRANT also includes the same POSIX sources. The PA backend defines _REENTRANT if -threads is specified on HP-UX 10 and if -pthread is specified on HP-UX 11. -threads also defines _DCE_THREADS which we may not want for the single thread model. libgfortran.sl is built twice on HP-UX 10, once for the single thread model and once for the dce thread model. It's the single thread build that's the problem. For HP-UX, I could not find anything (cf. also http://docs.hp.com/en/B2355-90683/ctime.3C.html). However, IBM has a statement regarding HP-UX, which is similar to Solaris's above: http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/ad/t0007651.htm All the reentrant functions are in libc. Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #12 from dave at hiauly1 dot hia.nrc.ca 2011-02-21 19:38:33 UTC --- On Mon, 21 Feb 2011, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-21 18:58:27 UTC --- In libgfortran it is not the user, but libgfortran implementation, so it makes sure it always passes buffer of at least 26 bytes. If there are OSes where we can't trust ctime_r, we could either blacklist them (or whitelist the known good ones), or on some of them try to supply larger buffer (is there any implementation that would overflow say 256 or 1024 bytes)? The gnulib thread that led to the autoconf recommendation suggests using strftime. localtime_r is thread safe. Besides the buffer overflow issues, asctime_r and ctime_r do not honor i18n, and incorrect values are produced for some input values. For example, some Solaris versions silently generate incorrect values for timestamps before 1900. See: http://www.mail-archive.com/bug-gnulib@gnu.org/msg02248.html Dave
[Bug libgomp/47804] libgomp LD_LIBRARY_PATH doesn't include path to libgfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47804 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-02-18 18:54:59 UTC --- On Fri, 18 Feb 2011, jakub at gcc dot gnu.org wrote: Created attachment 23397 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23397 gcc46-pr47804.patch Works for me. Dave
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-02-18 20:56:54 UTC --- Is there no way to get a posix compliant ctime? Alternatively, we'll need autoconf magic to detect the extra arg. I know at one time it was relatively common, so autoconf magic might be around somewhere. Assuming it is you just have to do something like #if defined (oddballctime) *date = ctime_r (now, cbuf, CSZ); #else *date = ctime_r (now, cbuf); #endif Using ctime_r is a bit of a can of worms. The GNU autoconf manual recommends not using ctime_r unless the inputs are known to be within certain limits. It seems HP-UX and Solaris have both forms. In the HP-UX 11 case, which form is used at compilation time depends on _PTHREADS_DRAFT4: # ifndef _PTHREADS_DRAFT4 extern char *ctime_r(const __time_t *, char *); # else /* _PTHREADS_DRAFT4 */ extern int ctime_r(const __time_t *, char *, int); # endif /* _PTHREADS_DRAFT4 */ Potential autoconf test: # ctime_r -- # # There are two versions of ctime_r, one of which takes a buffer length as a # third argument, and one which only takes two arguments. (There is also a # difference in return values, but we handle that in the code itself.) AC_CHECK_FUNCS(ctime_r) if test $ac_cv_func_ctime_r = yes; then AC_CACHE_CHECK([for 2 or 3 argument version of ctime_r], db_cv_ctime_r_3arg, [ AC_TRY_LINK([ #include time.h], [ ctime_r(NULL, NULL, 100); ], [db_cv_ctime_r_3arg=3-argument], [db_cv_ctime_r_3arg=2-argument])]) fi if test $db_cv_ctime_r_3arg = 3-argument; then AC_DEFINE(HAVE_CTIME_R_3ARG) AH_TEMPLATE(HAVE_CTIME_R_3ARG, [Define to 1 if ctime_r takes a buffer length as a third argument.]) fi Dave
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2011-02-18 00:38:54 UTC --- Aha! :) There's a typo in gthr-dce.h __gthread_mutx_destroy (__gthread_mutex_t *__mutex) s/mutx/mutex/ Good catch! I wonder how many years it has been there? Dave
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 --- Comment #7 from dave at hiauly1 dot hia.nrc.ca 2011-02-18 01:00:35 UTC --- On Fri, 18 Feb 2011, redi at gcc dot gnu.org wrote: I suppose the safe thing to would be add the right signature and leave that there, but I can't imagine anyone's using it with that name I agree. Further, the name isn't present in other thread models. Dave
[Bug debug/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web Web oldreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47622 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2011-02-06 16:05:29 UTC --- Attached dumps.
[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 --- Comment #8 from dave at hiauly1 dot hia.nrc.ca 2011-02-05 17:09:48 UTC --- Can't reproduce that with a cross to hppa64-hp-hpux11.11, I get the expected error instantly. Sorry, this is my fault. I misapplied your patch. Dave
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #21 from dave at hiauly1 dot hia.nrc.ca 2011-02-04 14:42:39 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html This is my previous janitorial patch, + a kludge which I believe should fix the issue on HP-UX and other targets that support weak references but not weak undefined references. Fixes build error on HP-UX. Dave
[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-02-04 20:28:03 UTC --- On Fri, 04 Feb 2011, jakub at gcc dot gnu.org wrote: Please provide preprocessed source, so I can try to reproduce it with a cross compiler. Attached.
[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2011-02-05 01:03:51 UTC --- On Fri, 04 Feb 2011, jakub at gcc dot gnu.org wrote: --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-04 23:08:21 UTC --- Created attachment 23249 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23249 gcc46-pr47610.patch Patch fixes build error. Doing full test. Thanks, Dave
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #20 from dave at hiauly1 dot hia.nrc.ca 2011-02-03 15:33:37 UTC --- on hppa2.0w-hp-hpux11.11. Weak references don't work on this target and probably others. If weak symbols do not work, why is then SUPPORTS_WEAK set? (Or, if it isn't set, why does it fail?) The situation is messy and difficult: 1) The backend defines TARGET_SUPPORTS_WEAK. This is needed for C++. The support varies based on assembler, etc. The target has COMDAT and secondary symbol symbol support when GAS is used. This allows for multiple definitions of functions and data. However, undefined weak symbols are not supported. It is not possible to check whether a function is defined or not using a `if'. A function pointer is actually a pointer to a function descriptor (plabel). 2) Libgfortran defines SUPPORTS_WEAK based on #pragma weak. This is probably wrong for PA HP-UX. There is a similar situation in gthr-posix.h where there is a mechanism to override SUPPORTS_WEAK. 3) I think the actual error was caused by the lack of a declaration for clock_gettime as a function. The default symbol type is data. Was time.h included? 4) Because of 1, the `if' will always evaluate to true. HP-UX has clock_gettime, so this shouldn't be a problem. Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #24 from dave at hiauly1 dot hia.nrc.ca 2011-01-31 19:35:15 UTC --- What endian-ness are the ppc and hppa targets? hppa is big. I believe ppc is also big. Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #26 from dave at hiauly1 dot hia.nrc.ca 2011-02-01 00:27:21 UTC --- On Mon, 31 Jan 2011, davek at gcc dot gnu.org wrote: If one of you could try the whole thing with --save-temps -v -Wl,-v -Wl,--verbose, and attach the various .o and @ arg files (some of which still get left in /tmp) and the log of the build output, I may be able to run far enough through the link with just a cross binutils to get to the symbol resolution stage and debug it. Attached. Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #27 from dave at hiauly1 dot hia.nrc.ca 2011-02-01 00:37:22 UTC --- On Mon, 31 Jan 2011, davek at gcc dot gnu.org wrote: If one of you could try the whole thing with --save-temps -v -Wl,-v -Wl,--verbose, and attach the various .o and @ arg files (some of which still get left in /tmp) and the log of the build output, I may be able to run far enough through the link with just a cross binutils to get to the symbol resolution stage and debug it. Oh, I just remembered that ld/12402 was probably introduced by the change that introduced plugin support for ld. Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #18 from dave at hiauly1 dot hia.nrc.ca 2011-01-27 17:07:34 UTC --- On Thu, 27 Jan 2011, hubicka at gcc dot gnu.org wrote: I need to see the dump from merging, too. They gets name of one of the .o files when -save-temps is used. I.e. ./xgcc -B ./ -O2 abs-1-lib.c abs-1.c m.c -fdump-ipa-cgraph -save-temps -flto gets me the dump in abs-1-lib.o.000i.cgraph It seems the ICE occurs before the merge files are generated: Reading specs from /home2/dave/gcc-4.6/objdir/gcc/specs COLLECT_GCC=/home2/dave/gcc-4.6/objdir/gcc/xgcc COLLECT_LTO_WRAPPER=/home2/dave/gcc-4.6/objdir/gcc/lto-wrapper Target: hppa-linux Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --enable-nls --prefix=/home2/dave/opt/gnu/gcc/gcc-4.6.0 --with-local-prefix=/home2/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada Thread model: posix gcc version 4.6.0 20110126 (experimental) [trunk revision 169296] (GCC) COLLECT_GCC_OPTIONS='-B' '/home2/dave/gcc-4.6/objdir/gcc/' '-w' '-O2' '-flto' '-fno-builtin-abs' '-o' '/home2/dave/gcc-4.6/objdir/gcc/testsuite/gcc/abs-1.x7' '-fdump-ipa-cgraph' '-save-temps' '-v' /home2/dave/gcc-4.6/objdir/gcc/cc1 -E -quiet -v -iprefix /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/ -isystem /home2/dave/gcc-4.6/objdir/gcc/include -isystem /home2/dave/gcc-4.6/objdir/gcc/include-fixed /home2/dave/gcc-4.6/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1.c -w -flto -fno-builtin-abs -fdump-ipa-cgraph -O2 -fpch-preprocess -o abs-1.i ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/include ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/include-fixed ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/../../../../hppa-linux/include ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/../../lib/gcc/hppa-linux/4.6.0/include ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/../../include ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/../../lib/gcc/hppa-linux/4.6.0/include-fixed ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/../../lib/gcc/hppa-linux/4.6.0/../../../../hppa-linux/include #include ... search starts here: #include ... search starts here: /home2/dave/gcc-4.6/objdir/gcc/include /home2/dave/gcc-4.6/objdir/gcc/include-fixed /home2/dave/opt/gnu/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-B' '/home2/dave/gcc-4.6/objdir/gcc/' '-w' '-O2' '-flto' '-fno-builtin-abs' '-o' '/home2/dave/gcc-4.6/objdir/gcc/testsuite/gcc/abs-1.x7' '-fdump-ipa-cgraph' '-save-temps' '-v' /home2/dave/gcc-4.6/objdir/gcc/cc1 -fpreprocessed abs-1.i -quiet -dumpbase abs-1.c -auxbase abs-1 -O2 -w -version -flto -fno-builtin-abs -fdump-ipa-cgraph -o abs-1.s GNU C (GCC) version 4.6.0 20110126 (experimental) [trunk revision 169296] (hppa-linux) compiled by GNU C version 4.6.0 20110126 (experimental) [trunk revision 169296], GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.6.0 20110126 (experimental) [trunk revision 169296] (hppa-linux) compiled by GNU C version 4.6.0 20110126 (experimental) [trunk revision 169296], GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 394c56f917a1cdcda6b767bcbf6fcebb COLLECT_GCC_OPTIONS='-B' '/home2/dave/gcc-4.6/objdir/gcc/' '-w' '-O2' '-flto' '-fno-builtin-abs' '-o' '/home2/dave/gcc-4.6/objdir/gcc/testsuite/gcc/abs-1.x7' '-fdump-ipa-cgraph' '-save-temps' '-v' /home2/dave/gcc-4.6/objdir/gcc/as -v -W -o abs-1.o abs-1.s GNU assembler version 2.21.51 (hppa-unknown-linux-gnu) using BFD version (GNU Binutils) 2.21.51.20110116 COLLECT_GCC_OPTIONS='-B' '/home2/dave/gcc-4.6/objdir/gcc/' '-w' '-O2' '-flto' '-fno-builtin-abs' '-o' '/home2/dave/gcc-4.6/objdir/gcc/testsuite/gcc/abs-1.x7' '-fdump-ipa-cgraph' '-save-temps' '-v' /home2/dave/gcc-4.6/objdir/gcc/cc1 -E -quiet -v -iprefix /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/ -isystem /home2/dave/gcc-4.6/objdir/gcc/include -isystem /home2/dave/gcc-4.6/objdir/gcc/include-fixed /home2/dave/gcc-4.6/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1-lib.c -w -flto -fno-builtin-abs -fdump-ipa-cgraph -O2 -fpch-preprocess -o abs-1-lib.i ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/include ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/include-fixed ignoring nonexistent directory /home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/../../../../hppa-linux/include ignoring
[Bug libfortran/47493] FAIL: gfortran.fortran-torture/execute/csqrt_1.f90 compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47493 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-01-27 17:27:40 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47493 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-27 17:04:51 UTC --- (.rodata+0x68): undefined reference to `_gfortran_specific__sqrt_r8' Can you run: nm libgfortran.a |grep _gfortran_specific__sqrt_ on my system that gives: dave@mx3210:~/gnu/gcc/objdir/hppa-linux-gnu/libgfortran/.libs$ nm libgfortran.a |grep _gfortran_specific__sqrt_ T _gfortran_specific__sqrt_r4 T _gfortran_specific__sqrt_c4 T _gfortran_specific__sqrt_c8 I don't fully trust the kernel on this system. I see in config.h: /* libm includes sqrt */ /* #undef HAVE_SQRT */ I think the configure test probably failed due to a cache management problem, although I didn't see anything the the system log. Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #20 from dave at hiauly1 dot hia.nrc.ca 2011-01-27 18:06:02 UTC --- On Thu, 27 Jan 2011, hubicka at ucw dot cz wrote: Merging should happen after unmerged files are dumped. Perhaps they go to some funny place, like /tmp? They are not in /tmp. There is one other cgraph file which I attach. Dave
[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-01-27 20:24:02 UTC --- With r163461 backported (compiler only built with --enable-languages=c this time) we ran the libgomp testsuite 3 times, failed 11/248 tests, 0/248 tests and 9/248 tests. So, still not fantastic, but the 0/248 was nice to see. I believe that libgomp.sl is incorrectly linked: # chatr libgomp.sl libgomp.sl: shared library shared library dynamic path search: SHLIB_PATH disabled second embedded path enabled first /opt/gnu/gcc/gcc-4.5/lib internal name: libgomp.sl.1 shared library list: dynamic /usr/lib/librt.2 dynamic /usr/lib/libc.2 dynamic /mnt/gnu/gcc/objdir/./gcc/libgcc_s.4 dynamic /opt/langtools/lib/libpthread.1 As can be seen, libgomp is linked against libc, and libc.2 comes before libpthread.1 in the shared library list. libc contains non functional pthread functions, so it is likely pthread support is not functional. From the discussion, it appears there is a difference in the behavior of the dynamic loader in 11.31 and other hpux 11 releases. HP recommends not linking shared libraries against libc. libtool adds -lc to the link command. It doesn't come directly from the libgomp configuration. So, libtool needs to be fixed first. Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #16 from dave at hiauly1 dot hia.nrc.ca 2011-01-20 00:13:36 UTC --- On Tue, 18 Jan 2011, dave at hiauly1 dot hia.nrc.ca wrote: Here is abs-1.c.000i.cgraph: The above call graph indicates main_test is not called. Here is main.c.000i.cgraph. It also seems wrong...
[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-01-17 15:12:38 UTC --- I suppose you are using GNU ld, right? Yes (gold has not been ported). On trunk x86_64 with stock binutils 2.21 I get cat 20010124-1.res 3 20010124-1.o 3 79 2651d4ed PREVAILING_DEF_IRONLY main_test 85 2651d4ed RESOLVED_IR g 110 2651d4ed RESOLVED_IR f 20010124-1-lib.o 3 113 f6a75653 PREVAILING_DEF_IRONLY f 127 f6a75653 PREVAILING_DEF_IRONLY g 153 f6a75653 RESOLVED_IR inside_main main.o 3 79 2cccb08f PREVAILING_DEF main 85 2cccb08f RESOLVED_IR main_test 88 2cccb08f PREVAILING_DEF_IRONLY inside_main thus, memcpy is also missing but at least main_test is correctly used from 20010124-1.o. Thus - can you tell us your exact GNU ld version and maybe debug what is the lto_symtab contents we generate (there is a lto-plugin/lto-symtab.c program, not sure if it still works ...) It has been rebuilt a number of times recently. Last night's test run still shows the bug and it used: dave@gsyprf11:~/gcc-4.6/objdir$ ld --version GNU ld (GNU Binutils) 2.21.51.20110116 I tried to do a build without plugin support, but it seems there is a ld configure bug and plugin support can't be disabled. With older versions, I think plugin support had to be explicitly enabled (default was no). I'll try to debug the lto_symtab contents tonight. Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #12 from dave at hiauly1 dot hia.nrc.ca 2011-01-17 18:32:22 UTC --- On Mon, 17 Jan 2011, hubicka at ucw dot cz wrote: It seems that we get wrong already when streaming abs-1-lib.o file. Would be possible to attach cgraph dump from WPA? Is this what you wanted? Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #13 from dave at hiauly1 dot hia.nrc.ca 2011-01-17 18:39:14 UTC --- Last graph.
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #14 from dave at hiauly1 dot hia.nrc.ca 2011-01-18 00:10:55 UTC --- This is it! Dave
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #15 from dave at hiauly1 dot hia.nrc.ca 2011-01-18 00:21:42 UTC --- Here is abs-1.c.000i.cgraph:
[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287 --- Comment #8 from dave at hiauly1 dot hia.nrc.ca 2011-01-18 01:36:53 UTC --- Attached .cgraph files.
[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287 --- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2011-01-18 01:36:54 UTC --- Created attachment 23011 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23011 20010124-1.c.000i.cgraph --- Comment #10 from dave at hiauly1 dot hia.nrc.ca 2011-01-18 01:36:54 UTC --- Created attachment 23012 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23012 20010124-1-lib.c.000i.cgraph --- Comment #11 from dave at hiauly1 dot hia.nrc.ca 2011-01-18 01:36:54 UTC --- Created attachment 23013 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23013 20010124-1.x7.ltrans0.000i.cgraph
[Bug target/46950] Stage 3 ada bootstrap error on i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46950 --- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2010-12-20 00:36:28 UTC --- On Sun, 19 Dec 2010, dominiq at lps dot ens.fr wrote: The same revision caused pr46916. Could you try the patch in http://gcc.gnu.org/bugzilla/attachment.cgi?id=22787 ? It resolves the ada build error. Dave
[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46869 --- Comment #13 from dave at hiauly1 dot hia.nrc.ca 2010-12-18 21:25:30 UTC --- On Thu, 16 Dec 2010, bkoz at gcc dot gnu.org wrote: Does this still happen if -g is removed? (Via -g0) No. Attached change fixes fails on hppa2.0w-hp-hpux11.11. Dave
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #13 from dave at hiauly1 dot hia.nrc.ca 2010-12-18 22:42:13 UTC --- Any chance this gets backported? It's not a regression, but I think it should be backported since it breaks Linux in a somewhat random manner. I'm currently testing the change on the 4.5 branch. Dave
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2010-12-13 12:44:21 UTC --- Yeah, the insn count for asm is just a guess. You should never put inline asm into a delay slot, you really don't know how big it is or if it is suitable for the delay slot. I guess the bug is in checking just for ASM_INPUT, that should be also testing extract_asm_operands () != NULL_RTX. Thanks, I'll look at that. However, I think branch_to_delay_slot_p can be improved. It probably should also check for asms and return FALSE if it finds one. Dave
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #10 from dave at hiauly1 dot hia.nrc.ca 2010-12-13 12:51:51 UTC --- Thanks, I'll look at that. However, I think branch_to_delay_slot_p can be improved. It probably should also check for asms and return FALSE if it finds one. Another related issue is the useskip check. It also needs to check for asms. Dave
[Bug testsuite/46913] send_log $first != $second\n in gdb-test fails when $first starts with '-'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46913 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2010-12-12 20:10:51 UTC --- So post a patch to gcc-patches? Will do when I complete testing on the system where I see the problem. It currently doing a full check that I don't want to mess up. There is some expect/tcl version dependency. Dave
[Bug testsuite/46913] send_log $first != $second\n in gdb-test fails when $first starts with '-'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46913 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2010-12-12 21:14:37 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46913 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-12 20:18:59 UTC --- If it doesn't work on some expect or tcl or dejagnu versions, the alternative would be send_log actual $first != expected $second\n Which do you prefer? It's not easy to test multiple versions. What I know is the error only occurs with certain versions. Dave
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2010-12-13 02:45:37 UTC --- Reduced testcase attached.
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2010-12-13 02:45:38 UTC --- Created attachment 22731 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22731 xxx.c
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2010-12-13 02:49:57 UTC --- Reduced testcase attached.
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2010-12-13 03:59:08 UTC --- Testing attached change. branch_to_delay_slot_p didn't correctly handle asms, etc. When it is fixed, branch_needs_nop_p isn't needed. It also didn't handle all cases. Dave
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #6 from dave at hiauly1 dot hia.nrc.ca 2010-12-13 03:59:09 UTC --- Created attachment 22734 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22734 pa.c.d
[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46869 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2010-12-09 16:46:50 UTC --- Attached .ii.
[Bug tree-optimization/46801] [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized gnat_rcheck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46801 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2010-12-04 18:01:04 UTC --- Attached tree dump.
[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671 --- Comment #6 from dave at hiauly1 dot hia.nrc.ca 2010-12-03 17:22:07 UTC --- On Fri, 03 Dec 2010, ro at CeBiTec dot Uni-Bielefeld.DE wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2010-12-03 15:21:51 UTC --- Jan, your patch has broken bootstrap on two platforms for a week now, and there's not even an indication that you're looking at the problem. Please fix or revert ASAP. The implementation of default_function_section in the change is elf specific. As a result, all targets that don't use elf sections are broken by the change. Even if I define TARGET_ASM_FUNCTION_SECTION, this will still leave the other targets that don't use elf sections broken. Elf sections were never the default before. The change was applied during stage3 and it wasn't a bug fix. So, the commit was questionable. Dave
[Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685 --- Comment #8 from dave at hiauly1 dot hia.nrc.ca 2010-11-30 21:52:57 UTC --- On the other side, the above is still broken with -freorder-blocks-and-partition and I guess even before Honza's change it has been broken. flag_reorder_blocks_and_partition is disabled on pa because we don't support hot and cold partitioning. Testing you first suggestion. Dave
[Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685 --- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2010-11-30 22:22:22 UTC --- On Tue, 30 Nov 2010, John David Anglin wrote: On the other side, the above is still broken with -freorder-blocks-and-partition and I guess even before Honza's change it has been broken. flag_reorder_blocks_and_partition is disabled on pa because we don't support hot and cold partitioning. Testing you first suggestion. This fixes nested-6.c on hppa-unknown-linux-gnu. Probably fixes the others. Dave
[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46584 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2010-11-26 19:04:56 UTC --- On Fri, 26 Nov 2010, burnus at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46584 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-26 08:04:50 UTC --- The test case quad_1.f90 does not always use quad precision (despite its name) but it uses the highest available floating point type. Depending on the system that can be the real kind 8 (64 bits), 10 (80 bits) or 16 (128 bits). The FE does the following matching for a REAL type matching sizeof(float) - sinf, for double - sin, for long double - sinl, and for __float128 - sinq. Thus, on HPPA there seems to be a floating point type which is larger than double and which matches long double while __float128 does not seem to be available. Hence, the issue seems to rather that we have found a C99 math function which is no implemented in HPUX: A long-double complex cosine (ccosl). There are some fall-back C99 functions implemented in libgfortran but seemingly none of the complex trigonometric ones; cf. http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/intrinsics/c99_functions.c The muddle over solution is to change the ccosl function to some other - possibly complex - long double function which is implemented - maybe csqrtl is? I have a patch that adds the hooks to build libquadmath on PA HP_UX targets. However, I'm not sure what's the best way to map the 'l' C99 builtins like those below to the corresponding 'q' functions in the new library. It is not completely clear what your patch is supposed to do. Seemingly PA has a hardware (8 bytes)/double data type. I do not know whether long double is 80 bits long or 128 bits. If it is not 80 bits, you could consider adding __float128 - but if long double is already 128 bits, I do not see why one should do so. If there is no 128 bit type, adding __float128 will automatically make a REAL(16) available, which will use libquadmath. PA has hardware float and double. The architecture has provision for long double but this was never implemented in hardware. HP-UX has a software support for for basic arithmetic and compares using long doubles. However, there are now math routines of any kind. The original testcase failure occured with the existing long double support because of the lack of long double math routines (cosl, etc). Given the recent addition of libquadmath, I thought it might be useful to try and enable it. Current patch to enable building libquadmath is attached. libquadmath appears to have built successfully on hppa64-hp-hpux11.11 with this change. I needed to add __float128 type and some builtins. To do this, I essentially copied stuff from ia64. As things stand now, it seems the fortran front end uses the 'l' math functions in preference to the 'q' functions in libquadmath. It appears the configure for libgfortran checks for the presence of all the 'l' math functions. However, it might be better to map 'l' to 'q' in a quadmath header, so libquadmath doesn't depend on libgfortran (i.e., make it usable from C, etc). Does this make sense? Dave
[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46040 --- Comment #7 from dave at hiauly1 dot hia.nrc.ca 2010-11-23 18:45:14 UTC --- Any reason why this patch isn't submitted/commited? No. I was traveling and forgot about it. Access to the arm box on my desk is unreliable. Dave
[Bug testsuite/46595] [4.6 Regression] libquadmath.0.dylib image not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46595 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2010-11-22 14:35:17 UTC --- Have you tried with http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02121.html applied? No, but it looks like it would fix the failures. Dave
[Bug testsuite/46595] [4.6 Regression] libquadmath.0.dylib image not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46595 --- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2010-11-23 02:18:42 UTC --- On Mon, 22 Nov 2010, howarth at nitro dot med.uc.edu wrote: Have you tried with http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02121.html applied? I had some difficulty in applying the change as there seems to have been other changes to the .exp file. However, when applied, it fixes all the libgomp failures. Attached is the change that I tested. Dave
[Bug testsuite/46529] guality_check times out, so guality tests are not run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46529 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2010-11-18 14:05:39 UTC --- --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-18 10:11:00 UTC --- Huh. But after all it correctly detects the tests won't work ... Actually, that's not true. See for example http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg01408.html This testsuite run used an old build of gdb from cvs: 502 (hiauly1)dave gdb --version GNU gdb 2004-01-08-cvs The situation on hppa1.1-hp-hpux10.20 is not any worse than on hppa-unknown-linux-gnu where in theory things should work ... In fact, the majority of failing tests are the same. Dave
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #13 from dave at hiauly1 dot hia.nrc.ca 2010-11-18 23:37:15 UTC --- On Thu, 18 Nov 2010, dominiq at lps dot ens.fr wrote: What happens if you remove the gcc_assert at line 338 of varpool.c (see comment #8)? hppa2.0w-hp-hpux11.11 bootstraps successfully with the assert removed. Dave
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #15 from dave at hiauly1 dot hia.nrc.ca 2010-11-18 23:53:19 UTC --- powerpc-apple-darwin9 is currently regtesting without anything obvious so far (at obj-c++). My MacPro is darwin9, and I'm only setup to do 32-bit builds at the moment. Dave
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #99 from dave at hiauly1 dot hia.nrc.ca 2010-11-14 23:12:25 UTC ---
On Sun, 14 Nov 2010, bonzini at gnu dot org wrote:
Minimized testcase:
int f (unsigned long arg, int *cr)
{
int *p = (int *) arg;
int x = *cr;
long pu_err = 0;
if (x)
asm volatile (stw %2,0(%1): =r (pu_err): r (p), r (x));
asm volatile (stw %2,0(%%sr3,%1): =r (pu_err): r (p), r (x));
return pu_err;
}
Fails at -O2.
Cool! The reduced code no longer makes any sense but it should compile.
I'm sure this was a fair bit of work.
Dave
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #95 from dave at hiauly1 dot hia.nrc.ca 2010-11-08 17:00:41 UTC --- CC fs/ioctl.o fs/ioctl.c: In function 'do_vfs_ioctl': fs/ioctl.c:601:1: internal compiler error: in update_df, at fwprop.c:877 Please submit a full bug report, Here is full compile command: hppa64-linux-gnu-gcc -Wp,-MD,fs/.ioctl.o.d -nostdinc -isystem /home/dave/opt/gnu/gcc64/lib/gcc/hppa64-linux-gnu/4.6.0/include -I/home/dave/linux/linux-2.6.36.y/arch/parisc/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -pipe -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000 -Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(ioctl) -DKBUILD_MODNAME=KBUILD_STR(ioctl) -c -o fs/ioctl.o fs/ioctl.c Attached preprocessed source.
[Bug fortran/45636] Failed to fold simple Fortran string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636 --- Comment #25 from dave at hiauly1 dot hia.nrc.ca 2010-11-07 19:44:07 UTC --- The change was r166378 and if the test failures are the only reason to keep this bug report open then it we should be able to close it now. Closing would be ok if there is a reason the call to mempcpy shouldn't be eliminated. On darwin, it was eliminated. Dave
[Bug middle-end/46292] FAIL: gcc.c-torture/execute/vector-shift2.c compilation, -O3 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46292 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2010-11-03 18:19:59 UTC --- What happens if you just remove the assert? Testing. Dave
[Bug middle-end/46292] FAIL: gcc.c-torture/execute/vector-shift2.c compilation, -O3 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46292 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2010-11-03 19:32:50 UTC --- Dave, can you please regression test this patch? Sorry, I'm just about to run out the door for a flight. Possibly, tomorrow. Dave
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #90 from dave at hiauly1 dot hia.nrc.ca 2010-10-20 14:39:26 UTC --- The armv5 failure is a stage2 miscompilation. Is it caused by Bernd's patch too? Or by fwprop? Actually, the ICE I saw this morning was in stage3. This box is only accessible at my contractor's site, so my access to it is limited. Dave
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169 --- Comment #19 from dave at hiauly1 dot hia.nrc.ca 2010-10-18 17:27:04 UTC --- It looks like this was fixed (for hppa at least) in r163190. 2010-08-12 Richard Guenther rguent...@suse.de PR tree-optimization/45232 * tree-ssa-reassoc.c (can_reassociate_p): Disable re-association for types with undefined overflow. (reassociate_bb): Allow re-associating of bit and min/max operations for types with undefined overflow. * tree-ssa-forwprop.c (associate_plusminus): New function. (tree_ssa_forward_propagate_single_use_vars): Call it. Is it easy to backport? Dave
