[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-17 08:55 --- Subject: Re: [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC --- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-16 20:57 --- This is really strange case. The patch should at most introduce extra inlining that naturally should not introduce undefined symbols. It is used as: sethi %hi(_GLOBAL_OFFSET_TABLE_-(.LL363-.)), %o3 or %o3, %lo(_GLOBAL_OFFSET_TABLE_-(.LL363-.)), %o3 callgnat__debug_pools__put_line, 0 so it is passed to gnat__debug_pools__put_line. Any idea what should be there? It does not seem like variable, rather like code label. Can I have Unfortunately not; you'd have to ask one of the Ada maintainers. Eric is on the Cc:, he might know. -fdump-tree-optimized (or perhaps better -fdump-tree-all) dumps? Sure. I couldn't attach it to the PR (1.8 MB even compressed with bzip2), so I've put it at http://www.cebitec.uni-bielefeld.de/~ro/files/g-debpoo-dump-tree-all.tar.bz2 Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-15 15:34 --- Subject: Re: New: [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC A reghunt identified the responsible patch: 2010-09-10 Jan Hubicka j...@suse.cz * tree-ssa-ccp.c (fold_const_aggregate_ref): Do not check STATIC flag. Reghunting was a nightmare in this case since there was lots of intermediate breakage which left the tree unbuildable for unrelated reasons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45658
[Bug testsuite/45664] All ifunc tests fail on Solaris 2
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-14 11:40 --- Subject: Re: All ifunc tests fail on Solaris 2 --- Comment #3 from nathan at codesourcery dot com 2010-09-14 10:23 --- yes, I'm testing a patch that checks the glibc version number -- I'm reluctant to try a more dynamic test as the whole point of these tests is to make sure it actually works, and disabling them in the face of failure seems unwise :) If it requires support from GNU ld and/or the glibc ld.so, check for that and disable the support on other platforms. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45664
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada no Solaris 2/SPARC
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10 15:15 --- Subject: Re: [4.6 regression] Reference to undefined label building libada no Solaris 2/SPARC A reghunt identified that the regression was caused by this patch: 2010-09-07 Jan Hubicka j...@suse.cz * tree-inline.c (tree_inlinable_function_p): Do not test DECL_REPLACEABL E_P. * ipa-inline.c (cgraph_default_inline_p, update_caller_keys, update_call ee_keys, cgraph_decide_inlining): Test function availability. * cif-code.def (OVERWRITABLE): New code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
[Bug bootstrap/45611] [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10 15:48 --- Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC --- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-09 13:27 --- I don't have access to sparc-sun-solaris2*, so I can't bootstrap it (but at most build a cross cc1). Not even sparc-linux? I very much doubt the bug is Solaris-specific. So please attach a testcase (easiest is probably in a non-bootstrapped tree run make check and pick a simple one that fails from the C testsuite). Ok, I'll try to find one. Is sparc-sun-solaris2* a STRICT_ALIGNMENT target? What's the clr instruction? Is it a store or a load? Yes, cf. sparc.h. clr and clrx store 0 (4 or 8 bytes) at the target address, requiring natural alignment (which fails with your patch for the clrx case). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug bootstrap/45611] [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10 19:10 --- Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC So please attach a testcase (easiest is probably in a non-bootstrapped tree run make check and pick a simple one that fails from the C testsuite). Ok, I'll try to find one. I've found one (in fact, it seems to be the only C one): +FAIL: gcc.c-torture/execute/20100708-1.c execution, -O2 +FAIL: gcc.c-torture/execute/20100708-1.c execution, -Os +FAIL: gcc.c-torture/execute/20100708-1.c execution, -O2 -flto +FAIL: gcc.c-torture/execute/20100708-1.c execution, -O2 -fwhopr Without and with your patch, it shows the following difference, just like the change that causes xgcc to get a SIGBUS: --- /homes/ro/20100708-1.s 2010-09-10 20:53:11.730613000 +0200 +++ 20100708-1.s2010-09-10 20:51:09.161003200 +0200 @@ -7,8 +7,7 @@ f: mov 16, %g1 .LL2: - st %g0, [%o0+8] - st %g0, [%o0+12] + stx %g0, [%o0+8] st %g0, [%o0+16] addcc %g1, -1, %g1 bne,pt %icc, .LL2 clr and clrx are just synthetic instructions, the real thing can be seen above: st resp. stx are stores of 4 resp. 8 bytes, and the %g0 register always reads as 0. %o0 isn't 8-byte aligned in this case, so the testcase dies with SIGBUS. Compile with $ cc1 20100708-1.c -mcpu=v9 -O2 to reproduce. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug bootstrap/45611] [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-09 12:41 --- Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC --- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-09-09 10:38 --- Presumably 163997 then. Indeed: a C-only bootstrap on sparc-sun-solaris2.10 works as of rev 163996 and fails with 163997. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-06 16:20 --- Subject: Re: [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table Unfortunately, even with your patch the mips-sgi-irix6.5 Ada bootstrap is still broken. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45421
[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-03 17:23 --- Subject: Re: [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table I'm now running an mips-sgi-irix6.5 bootstrap with Ada included with this patch. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45421
[Bug bootstrap/45028] [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-23 08:59 --- Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand The sparc-sun-solaris2.10 bootstrap completed successfully with your patch and testsuite results are back to normal (i.e. a considerable number of unrelated failures and regressions, but nothing too bad ;-) Thanks a lot for your quick help. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
[Bug bootstrap/45028] [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22 10:35 --- Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand Here you go: Breakpoint 5, output_operand_lossage (cmsgid=0xfe940c60 ) at /var/gcc/reghunt/trunk/gcc/final.c:3080 (gdb) where #0 output_operand_lossage (cmsgid=0xfe940c60 ) at /var/gcc/reghunt/trunk/gcc/final.c:3080 #1 0x00318d9c in output_addr_const (file=0xf52958, x=0xfe2d8e60) at /var/gcc/reghunt/trunk/gcc/final.c:3635 #2 0x002388d0 in dw2_assemble_integer (size=8, x=0xfe2d8e60) at /var/gcc/reghunt/trunk/gcc/dwarf2asm.c:59 #3 0x00238fd8 in dw2_asm_output_addr_rtx (size=8, addr=0xfe2d8e60, comment=0x0) at /var/gcc/reghunt/trunk/gcc/dwarf2asm.c:282 #4 0x00249ec0 in output_loc_operands (loc=0xfe2f28c0) at /var/gcc/reghunt/trunk/gcc/dwarf2out.c:5126 #5 0x0024a1a4 in output_loc_sequence (loc=0xfe2f28c0) at /var/gcc/reghunt/trunk/gcc/dwarf2out.c:5151 #6 0x002591f0 in output_loc_list (list_head=0xfe2dd230) at /var/gcc/reghunt/trunk/gcc/dwarf2out.c:10839 #7 0x00257274 in output_location_lists (die=0xfe2f0ba0) at /var/gcc/reghunt/trunk/gcc/dwarf2out.c:10226 #8 0x00257304 in output_location_lists (die=0xfe2f0b40) at /var/gcc/reghunt/trunk/gcc/dwarf2out.c:10228 #9 0x00257304 in output_location_lists (die=0xfe2801b0) at /var/gcc/reghunt/trunk/gcc/dwarf2out.c:10228 #10 0x00257304 in output_location_lists (die=0xfe280180) at /var/gcc/reghunt/trunk/gcc/dwarf2out.c:10228 #11 0x00257304 in output_location_lists (die=0xfe9d00f0) at /var/gcc/reghunt/trunk/gcc/dwarf2out.c:10228 #12 0x00289b6c in dwarf2out_finish (filename=0xffbff3af error reading variable) at /var/gcc/reghunt/trunk/gcc/dwarf2out.c:22414 #13 0x006f6670 in compile_file () at /var/gcc/reghunt/trunk/gcc/toplev.c:1025 #14 0x006fa048 in do_compile () at /var/gcc/reghunt/trunk/gcc/toplev.c:2333 #15 0x006fa174 in toplev_main (argc=33, argv=0xffbff1c4) at /var/gcc/reghunt/trunk/gcc/toplev.c:2374 #16 0x0010af18 in main (argc=33, argv=0xffbff1c4) at /var/gcc/reghunt/trunk/gcc/main.c:36 (gdb) up #1 0x00318d9c in output_addr_const (file=0xf52958, x=0xfe2d8e60) at /var/gcc/reghunt/trunk/gcc/final.c:3635 (gdb) p x $1 = (rtx) 0xfe2d8e60 (gdb) pr (unspec:DI [ (symbol_ref:DI (_ZN3gnu5javax5print3ipp9attribute8defaults17FinishingsDefault15EDGE_STITCH_TOPE) [flags 0x2] var_decl fe7c0cc0 EDGE_STITCH_TOP) ] 7) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
[Bug bootstrap/45028] [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22 12:10 --- Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand --- Comment #3 from jakub at gcc dot gnu dot org 2010-07-22 10:46 --- This one actually shouldn't be IMHO delegimized, the setm44 value is just a temporary and thus it shouldn't hold any value interesting for debug info. Can you please attach -fdump-rtl-vartrack dump? Done. It took me some time because the files isn't created in the working directory, but in the depths of gnu/javax/print/ipp/attribute ;-( I had to run jc1 under truss to find it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
[Bug bootstrap/45028] [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22 13:50 --- Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand Can you compile with -da and find out in which dump D#71 has been introduced? Sure: it first appeared in sched2. Uploading that as we speak. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
[Bug bootstrap/45028] [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22 14:29 --- Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand in *.expand looks correct, that var_location is %o0 instead of %g1 though. So the bug is somewhere in between. Would it be too large if you tarred up all dumps in between expand and split4? Even compressed with bzip2, the file is 2.8 MB, way too big for Bugzilla. I've placed it at http://www.cebitec.uni-bielefeld.de/~ro/files/dumps146-206.tar.bz2 instead. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
[Bug bootstrap/45028] [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22 15:04 --- Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand --- Comment #18 from jakub at gcc dot gnu dot org 2010-07-22 14:58 --- Rainer, do you think you could run make check in gcc/ subdir (assuming libjava was the last unbuilt library and say libstdc++/libgfortran/libgomp are already built) to see if this can be reproduced even on some C or C++ testcase? Sure, otherwise I'll start a fresh bootstrap with java excluded, which I know finishes since I tried it with unrelated changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
[Bug bootstrap/45028] [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22 15:54 --- Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC: output_operand: invalid expression as operand --- Comment #20 from jakub at gcc dot gnu dot org 2010-07-22 15:32 --- Created an attachment (id=21288) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21288action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21288action=view) gcc46-pr45028.patch I wonder if the attached (untested) patch wouldn't fix this problem. It does :-) I'll fire off a full bootstrap to check. Thanks a lot. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #33 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-21 07:56 --- Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously --- Comment #32 from jvdelisle at gcc dot gnu dot org 2010-07-21 04:37 --- Rainer, this is OK to back port. Do you want me to do so? No need, I can easily do it myself. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-20 19:20 --- Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). --- Comment #16 from rob1weld at aol dot com 2010-07-20 19:02 --- (In reply to comment #15) (In reply to comment #13) OpenSolaris recently added support for the ARM Processor, so that adds a few more 'multi-lib modes' that need to be supported, along with the expanded line True, but irrelevant: each port only supports the multilibs it needs, and not several different configurations with each from the set of multilibs becoming the default. of SPARC Processors now being supported. The OpenSolaris Group also has a 'call for Ports', so in theory our mechanism _must_ be general enough to support any possible Processor ... The mechanism is, of course. Additional note for this RFE (which _might_ get re-opened, someday): OpenSolaris now runs on mips-sun-solaris2.11 http://hub.opensolaris.org/bin/view/Project+mips/Tools Far from it: there are minimal binutils and gcc patches yet, nothing more. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-13 10:16 --- Subject: Re: --enable-build-with-cxx plugin tests fail This patch should restore the use of the previous stage compiler for plugins. Indeed: with the exception of the $(ENABLE_BUILD_WITH_CXX) handling, that's what I've been using already. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug objc/44887] [4.6 regression] All Objective-C execution tests fail on Solaris 2/SPARC
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-09 16:34 --- Subject: Re: [4.6 regression] All Objective-C execution tests fail on Solaris 2/SPARC --- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-07-09 16:29 --- On Solaris 9: === objc Summary === # of expected passes767 # of unexpected failures34 # of expected failures 7 # of unsupported tests 28 I wonder if there isn't a miscompilation somewhere though. Seems so, yes. A tree one rev. before Nathan's patch fails the same way, so this isn't the culprit. Reghunt in progress, though I'm not sure if I can get it finished before leaving for the weekend. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44887
[Bug objc/44887] [4.6 regression] All Objective-C execution tests fail on Solaris 2/SPARC
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-09 18:30 --- Subject: Re: [4.6 regression] All Objective-C execution tests fail on Solaris 2/SPARC The reghunt revealed Richard's mem-ref2 patch as the culprit: 2010-07-01 Richard Guenther rguent...@suse.de PR middle-end/42834 PR middle-end/44468 * doc/gimple.texi (is_gimple_mem_ref_addr): Document. * doc/generic.texi (References to storage): Document MEM_REF. I'm now trying to find out where the miscompilation is. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44887
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-09 19:17 --- Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously May I backport the patch to the 4.4 and 4.5 branches, too? Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25 16:48 --- Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp It occured to me that this is only failing for me with 32-bit cc1, i.e. i386-pc-solaris2.11, sparc-sun-solaris2.11, mips-sgi-irix6.5, but not alpha-dec-osf5.1 (which is 64-bit). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
16:49 ---
Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-06-22 01:24
---
atan2_1.f90 has failed on other platforms before too. I think we just need:
! { dg-options -ffloat-store }
or maybe this
! { dg-options -O0 -ffloat-store }
in the test file. Can you try that and see if it clears your problem. Add it
right after the line that says ! { dg-do run }
The first variant works like a charm: this way, we still iterate over
several optimization levels, which would be defeated by the second one.
How should we proceed from here? Should I formally propose the patch
above?
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25 19:26 --- Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously Great, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25 20:34 --- Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously Jerry, Try this version of the test case and see what it does. If this fails, I will send one instrumented a bit more. this one works without problems, both 32 and 64-bit, at all optimization levels (tested with DEJAGNU=site.exp runtest --tool gfortran --srcdir $srcdir dg.exp=array_constructor_23.f Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25 20:43 --- Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously --- Comment #26 from jvdelisle at gcc dot gnu dot org 2010-06-25 20:41 --- I will commit the change Excellent: no remaining fortran testsuite failures :-) Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-24 12:20 --- Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp --- Comment #4 from jakub at gcc dot gnu dot org 2010-06-24 11:51 --- created. But, as this PR lacks a testcase (well, the testcase depends on a proprietary header file not included here), it is hard to guess what's going on. I could include the OpenSolaris header, which is licensed under CDDL, but I've just been able to construct a minimal testcase: $ cat include.c #include stdlib.h $ cat stdlib.h #pragma redefine_extnamemkstemp64 mkstemp $ ./cc1 -E -traditional-cpp ./include.c -o include.i -I . -m64 In file included from ./include.c:2:0: ./stdlib.h:1:0: internal compiler error: Abort This should make it easier to find what's going on. Unlike the original test case from the GCC testsuite, this one fails even without -m64. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-24 13:50 --- Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp --- Comment #6 from jakub at gcc dot gnu dot org 2010-06-24 12:56 --- Can't reproduce on x86_64-linux (and, #pragma redefine_extname seems to be handled on all targets, not just Solaris). This seems to be extremely sensitive to command line parameters. E.g. on mips-sgi-irix6.5 it works (no ICE) with $ cc1 -E -tditional-cpp include.c -o include.i -I . When I add either -mabi=n32 or -mabi=64, cc1 aborts. Similarly, on sparc-sun-solaris2.11: $ cc1 -E -traditional-cpp include.c -o include.i -I . ICEs $ cc1 -E -traditional-cpp `pwd`/include.c -o include.i -I . works. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug target/18788] -pthreads option with -shared does not cause libpthread.so to be linked in.
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-23 12:07 --- Subject: Re: -pthreads option with -shared does not cause libpthread.so to be linked in. I've found that the Sun Studio compiler behaves the same with its -mt option and asked the maintainers about it: http://mail.opensolaris.org/pipermail/tools-compilers/2010-June/001156.html The relevance of that behavior has gone with the unified process model in Solaris 10, and it's causing me trouble when implementing TLS support for Solaris 8 and 9, so I'm going to fix this for 4.6.0, together with that TLS patch. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18788
[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-22
15:42 ---
Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-06-22 01:24
---
atan2_1.f90 has failed on other platforms before too. I think we just need:
! { dg-options -ffloat-store }
or maybe this
! { dg-options -O0 -ffloat-store }
in the test file. Can you try that and see if it clears your problem. Add it
right after the line that says ! { dg-do run }
The first variant works like a charm: this way, we still iterate over
several optimization levels, which would be defeated by the second one.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-21 12:47 --- Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0 --- Comment #6 from kargl at gcc dot gnu dot org 2010-06-16 21:51 --- (In reply to comment #5) This makes no sense at all. Rainer, I'm really sorry if it seems that I'm shooting questions a bit at random, but I have a hard time imagining how to narrow it down. Can you try the following equivalent C code (at -O0): Sure: same differences as in the Fortran case: -4.35483e-08 -4.35483e-08 -1.08095e-16 -1.08095e-16 4.33013e-08 4.33013e-08 4.38018e-17 4.38018e-17 3.05453e-08 3.05453e-08 3.33934e-17 3.33934e-17 2.96684e-08 2.96684e-08 -5.76796e-17 -5.76796e-17 4.87235e-08 4.87235e-08 -9.40003e-17 -9.40003e-17 -1.70395e-08 -1.70395e-08 2.55872e-17 2.55872e-17 1.2215e-09 1.2215e-09 -3.88144e-17 -3.88144e-17 2.30691e-08 2.30691e-08 -2.1684e-18 -2.1684e-18 -1.41206e-08 -1.41206e-08 -8.18573e-18 -8.18573e-18 2.18557e-08 2.18557e-08 -3.06287e-17 -3.06287e-17 Right now, the only thing I can see make sense is numerically instability in the libm. Also, how are atan2f and atan2 defined in the system's math.h header? Do they have simple prototypes? Are they actually macros? The declarations are in iso/math_c99.h: iso/math_c99.h: extern float atanf __P((float)); extern float atan2f __P((float, float)); #if !defined(__cplusplus) #pragma does_not_read_global_data(acosf, asinf, atanf, atan2f) #pragma does_not_write_global_data(acosf, asinf, atanf, atan2f) #if defined(__MATHERR_ERRNO_DONTCARE) #pragma no_side_effect(acosf, asinf, atanf, atan2f) Does -ffloat-store change the outcome? This looks to possibly be an excess precision problem and the difference between something in a register and main memory. Indeed: with -ffloat-store, the test program only prints 0s. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-15 14:09 --- Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0 --- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:51 --- if(atan(1.0, i/10.0) -atan2(1.0, i/10.)/= 0.0) call abort() Try to change that into a print *, atan(1.0, i/10.0) -atan2(1.0, i/10.) and see what it outputs. Only changing the first line, I get -4.35482832E-08 Abort Changing the second line, too, gives -4.35482832E-08 -1.08094956596804792E-016 4.33012666E-08 4.38017677684143791E-017 3.05452623E-08 3.33934269125535366E-017 2.96684455E-08 -5.7679762288359E-017 4.87235496E-08 -9.40003283544932344E-017 -1.70394934E-08 2.55871712706579046E-017 1.22149613E-09 -3.88144377749810587E-017 2.30690667E-08 -2.16840434497100887E-018 -1.41206291E-08 -8.18572640226555848E-018 2.18556941E-08 -3.06287113727155003E-017 Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug libstdc++/44475] bunch of warnings of second definition on osf
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-09 19:19 --- Subject: Re: bunch of warnings of second definition on osf I've regularly seen those warnings, but ignored them since I've found no ill effect and the testsuite largely passes (which doesn't use the static libstdc++.a anyway). While I do have Tru64 UNIX sources, the compilation tools (including nm, ar, and ld) are missing, so I cannot use that source to shed some light on the warning, and binutils aren't an option yet since they don't allow a bootstrap to finish. Unless the reporter can provide evidence that this warning causes actual problems, I'd suggest to close this as INVALID. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44475
[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-07 14:03 --- Subject: Re: [4.6 regression] gmp multilib support broke bootstrap with static libgmp --- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-04 17:48 --- First off this is not a regression; I ran into this issue back a couple of years ago with libjava requiring libgmp. It sure is: you used to be able to bootstrap with a static, non-PIC libgmp until this change went in, and now bootstrap fails. If this is not a regression, what is? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-07 16:32 --- Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously I've now analysed this further: the test only fails at -O3. The failure is an abort in l.23: DDA1 = ATAN2 ((/(REAL(J1,KV),J1=1,10)/), $ REAL((/(J1,J1=nf10,nf1,mf1)/), KV)) !fails DDA2 = ATAN2 (DDA, DDA(10:1:-1)) if (any (DDA1 .ne. DDA2)) call abort () Investigating with gdb, I find that only the 10th array element differs: (gdb ) p dda1 $1 = (0.0996686518, 0.218668953, 0.358770669, 0.519146085, 0.694738269, 0.876058042, 1.05165017, 1.21202564, 1.35212743, 1.47112763) (gdb) p dda2 $2 = (0.0996686518, 0.218668953, 0.358770669, 0.519146085, 0.694738269, 0.876058042, 1.05165017, 1.21202564, 1.35212743, 8.40779079e-45) I've verified that atan2f is called with exactly the same input sequence in both cases. The problem is that at -O0 (and probably up to -O2), atan2f is called 2 x 10 times as expected, and atan2f only appears twice in the assembler output. On the other hand, at -O3 the second time through, atan2f(1.0) isn't called. Instead, the loop is unrolled, but incorrectly, it seems: there are now only19 calls to atan2f in the assembler output. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-04 15:21 --- Subject: Re: lto-elf.c fails to compile on Solaris --- Comment #11 from rguenth at gcc dot gnu dot org 2010-06-03 13:47 --- The problem seems to have vanished, so eventually the fix can be backported (together with the typo fix in the configure script obviously). Done: I've run toplevel configure and make configure-gcc on both i386-pc-solaris2.11 (which has the new elf_getshdrstrndx) and i386-pc-solaris2.10 (which only has the non-conformant version of elf_getshstrndx) and got the expected results (and no error in gcc/config.log), so I've check this in. Should we ever receive more information for bootstrap/44079, we can either fix the configure tests or document the required version of elfutils libelf. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-21 09:26 --- Subject: Re: [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries --- Comment #3 from rwild at gcc dot gnu dot org 2010-05-21 08:15 --- (In reply to comment #2) Ralf, maybe we want in Autoconf (and hence in override.m4) a mechanism to push/pop the AC_LANG_WERROR state? Isn't there such a mechanism already? If not, then there was at least a proposed patch (series) to add such a while ago, I don't recall whether/why that wasn't merged. At least not in Autoconf 2.64. I've found a single instance in the implementation of AC_PATH_XTRA. I'll give it a try. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44216
[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-20 10:32 --- Subject: Re: Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line --- Comment #13 from jakub at gcc dot gnu dot org 2010-05-20 10:30 --- Patching in configure pieces generated with autoconf 2.64 into autoconf 2.59 generated configure totally broke the branch, configure after a few errors kept printing y in an endless loop. Sorry about the mess, will be more careful next time. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44074
[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-19 14:03 --- Subject: Re: ICE in gcc/config/soft-fp/divtf3.c --- Comment #6 from zadeck at naturalbridge dot com 2010-05-19 13:41 --- I have a deadline and do not have time to play with this. The comparison function in df-scan.c, df_ref_compare, is not stable according to what has been discussed in pr42157. however, it does satisfy the definition of qsort in the linux manuals. I've no idea if the Solaris 8 (and IRIX 5) qsort violates ISO C90 here. if you need it to be that stable for those platforms, then change the last line of df_ref_compare from return 0; to be return (int)DF_REF_ORDER (ref1) - (int)DF_REF_ORDER (ref2); Thanks, that's all I needed: bootstrap is past the ICE in the stage1 libgcc now, I'll let if finish and submit the patch, attributed to you, once testing is complete. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43870
[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-19 14:07 --- Subject: Re: ICE in gcc/config/soft-fp/divtf3.c --- Comment #8 from zadeck at naturalbridge dot com 2010-05-19 14:06 --- df maintainers cannot approve their own patches. you should get bonzini or any other back end maintainer to approve it. Understood: all I meant was that the ChangeLog entry would name you as the patch author. thanks for doing the testing. Thanks for the blazingly fast response. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43870
[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-12 11:50 --- Subject: Re: Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line --- Comment #3 from jay dot krell at cornell dot edu 2010-05-12 10:50 --- Using something like TARGET_SOLARIS is wrong: this is just a bug in older Sun I don't completely agree. - I regularly do cross builds. What will you do for that? Assume the old version? I think so. Since the result works the same on all versions. So you might as well just do that for cross and native imho. No, I just test if rep insn works or if rep; insn is required instead and use the result of that test. It works in both native and cross environments. - I want to build a gcc on 2.10 that works on 2.9..er..well, that's not quite right. For that I'll build it on 2.9. But the cross build scenario is relevant. That's not going to work in the general case: the Solaris 10 gcc may well use features that just don't exist in the Solaris 9 assembler and/or linker, so you're out of luck. - Look at what Darwin/Macho does -- that is also only for older versions, but they just do it unconditionally. (Might be good to check for TARGET_64BIT though, since that probably implies a new enough assembler?) This hardcoding is wrong in the general case, even if the Mach-O guys did otherwise. Why follow a bad example? And why use implicit tests if you can explicitly test for the feature (or bug) you're looking for? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44074
[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-06 19:17 --- Subject: Re: Using --enable-threads=solaris breaks near end of build in boehm-gc configury --- Comment #6 from rob1weld at aol dot com 2010-05-04 07:00 --- This is now documented in install.texi to deter people who think they should use solaris on Solaris 2. Thanks for fixing the DOCs, can we pull the code too (or ifdef it out for OpenSolaris) to avoid having code in gcc that is no longer supported. This has nothing to do with OpenSolaris, just the fact that some target libraries don't work with --enable-threads=solaris, while others work just fine. No real reason to pull it out, though I could be persaded to do so given that there's no benefit in keeping it. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-06 19:27 --- Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). --- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 --- This is an Enhancement (EG: I wish (someday in the future) that we had this feature) and I would have preferred it remain open until the need for the feature exceeded the lack of available time to implement it (as Eric pointed out we may cross that line shortly). But what's the *point* of having such a configuration, except as a prove of `we can do that'? Any actual problem that would be solved this way? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-06
19:32 ---
Subject: Re: gcc 4.4.0 20090204 - Configury from GNU linker to Operating
System's Linker broke (reverse works OK)
--- Comment #8 from rob1weld at aol dot com 2010-05-04 07:05 ---
As I've said before: please file *clear individual bug reports* for each
single
issue you find. Dealing with reports like this, with dozens of issues and
non-
issues mixed, is close to impossible.
I'll stick with comment #1 describes the Bug.
The beef of your report seems to be: I get errors from Sun ld linking
libgnat-4.4.so. In my experience, this only happens when you re-run
make bootstrap in a completed build or re-start it after the build
failed at some point. For some reason, the libgnat objects seem to be
rebuild without -fPIC, leading to the observed error. Seems like a bug
in the Ada build system to me.
Further comments were workarounds and to report a Flag Day on the Sun
Linker.
I don't think there is any flag day involved, this error just depends
very much on the circumstances of the build.
I simply used to remove the gcc/ada/rts{, rts_amd64} directories and a
couple of stamp files when I encountered this, though I haven't in a
long time. Perhaps the build system error is gone now.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111
[Bug libgcj/39161] gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script.
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-04 08:53 --- Subject: Re: gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script. Could you please retry the bootstrap with current sources and absolute pathnames to $srcdir/configure, perhaps also with relative pathnames to see if there's a difference? Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39161
[Bug target/38924] gcc 4.4.0 20090117 - init_priority incorrect for GNU ld in gcc/config/sol2.h
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-04 08:55 --- Subject: Re: gcc 4.4.0 20090117 - init_priority incorrect for GNU ld in gcc/config/sol2.h I regularly build all three combinations on mainline now: Sun as/ld, GNU as/Sun ld, and GNU as/ld, to make sure they continue to work. There's still some feature disparity in some areas, but I'm working to fix that. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38924
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 11:16 --- Subject: Re: lto-elf.c fails to compile on Solaris --- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-23 14:34 --- What's the status of this bug? I haven't checked anything before Solaris 10 yet (still have to set up my test sustems), but mainline is fine since the native libelf can be used. I haven't pushed the libelf 0.8.12 patch upstream yet, but there isn't much use if the native library can be used. The 4.5 branch is still affected until the elf_getshdrstrndx has been backported. Btw., what's the status with Honza's problem with that? I haven't heard anything yet, but would like to have this sorted out before backporting. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 14:40 --- Subject: Re: lto-elf.c fails to compile on Solaris --- Comment #9 from hubicka at gcc dot gnu dot org 2010-04-28 13:01 --- Hmm, I am not at all sure what problem I should have with this? In http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01179.html Richard reported that you had a problem with the patch that introduced an elf_getshdrstrndx replacement for the benefit of older Solaris releases, but I wonder how the error reported can happen. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 17:51 --- Subject: Re: ICE in gcc/config/soft-fp/divtf3.c gcc-tgc at jupiterrise dot com gcc-bugzi...@gcc.gnu.org writes: Program received signal SIGSEGV, Segmentation fault. 0x084bd3c5 in df_ref_compare (r1=0xa3278a4, r2=0xa3278ac) at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:2357 2357 if (DF_REF_CLASS (ref1) != DF_REF_CLASS (ref2)) (gdb) bt #0 0x084bd3c5 in df_ref_compare (r1=0xa3278a4, r2=0xa3278ac) at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:2357 #1 0xdf89b889 in qsort () from /usr/lib/libc.so.1 This is most likely another instance of the qsort problem that has already bitten us in PR tree-optimization/42157. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43870
[Bug middle-end/39883] preprocessor fails with myassertion
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 18:00 --- Subject: Re: preprocessor fails with myassertion --- Comment #1 from steven at gcc dot gnu dot org 2010-04-23 22:43 --- This one appears to have fallen through the cracks. Reported exactly one year ago, and now accidentally shows up in my search because my brain believed we still live in 2009... Oh well. I'll try to go through the Solaris bugs in the near future, but have concentrated on getting the 4.5 release in shape until now. Rainer, could you see if you can confirm this one (with 4.4/4.5/trunk)? I don't have a 4.4 tree around at the moment, but the testcase works fine on both 4.5 and mainline *with a sparc-sun-solaris2.10* compiler. The problem might be related to the sparc64-sun-solaris2.8 configuration, but I refuse to test that because I simply don't have the manpower to double testing effort when a 32-bit default bi-arch compiler handles this just fine. I'd rather remove the sparcv9-sun-solaris2.* configuration than deal with this. Could the warning: GMP header version 4.3 differs from library version 4.3.0. have something to do with the segfault? I doubt that, actually, though I haven't checked GMP versioning in detail. Maybe Eric has a sparcv9 compiler around and can easily check this? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39883
[Bug middle-end/39883] preprocessor fails with myassertion
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 19:30 --- Subject: Re: preprocessor fails with myassertion Maybe Eric has a sparcv9 compiler around and can easily check this? I only have 4.3.5, 4.5.1 and 4.6.0 compilers for sparc64-sun-solaris2.x at the moment, I'll test if someone can attach the preprocessed source. The submitter said that the problem has disappeared so the PR can be closed though. Preprocessed source is embedded in the original submission. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39883
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28 22:17 --- Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). --- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-04-28 22:09 --- While the advantages of sparc64-sun-solaris2.* are limited, I don't think we should remove it now since it can handle more memory and 64-bit computing is becoming the norm. I have no actual intention of doing so, although it increases the complexity of the target headers. Similarly, I think adding a 64-bit compiler on x86 would be desirable. And it would be faster than the 32-bit one because of the 64-bit ABI. As a matter of fact, we already have the few required patches at AdaCore. Patches have been floating around, and I'm sure I could get them into shape. My problem (apart from the same complexity problem as on SPARC) isn't primarily cpu power of my testfarm, but rather the time it takes to analyze and fix problems. This is practically doubled if you have two different configurations to test, and I simply cannot afford that, given that this is a spare-time activity. That's why I'm even opposed to take patches, since than I'm forced to deal with issues as well. Since the Sun Studio compilers are still exclusively 32-bit as wall, I see no strong reason for GCC to be different. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug debug/39104] stabs debug info fails onIRIX 5.3
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-21 14:24 --- Subject: Re: stabs debug info fails onIRIX 5.3 I don't think this is a gcc bug. While the native IRIX 5 tools use ECOFF debugging info embedded in ELF (mdebug), they don't know about Stabs-in-ECOFF/mdebug which is a GCC extension which IRIX 5 gdb cannot handle. Therefore it seems to be more useful to use Stabs-in-ELF instead of Stabs-in-ECOFF/mdebug instead, like gas on IRIX 6 does. In fact, I've got a patch to gas to do so. It seems like gas cannot properly handle the case where ECOFF_DEBUGGING_INFO isn't a compile time constant, but can change at runtime based on the -mdebug/-no-mdebug switch. Once this is properly tested, I'll submit it to the gas maintainers and update this PR accordingly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39104
[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-03-09 18:38 --- Subject: Re: amd64 TLS IE code sequence on Solaris 2/x86 violates spec --- Comment #4 from hjl dot tools at gmail dot com 2010-03-09 18:11 --- Please also upload tie.o. Done. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43309
[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-03-09 18:43 --- Subject: Re: amd64 TLS IE code sequence on Solaris 2/x86 violates spec --- Comment #6 from hjl dot tools at gmail dot com 2010-03-09 18:30 --- Please also update tie executables generated by Sun and GNU linkers with the SAME relocatable input. What do you mean? I've compiled and linked tie.c in two separate trees, one configured with gas and Sun ld, the other with gas and gld, and used everything from the corresponding tree. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43309
[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-03-09 19:14 --- Subject: Re: amd64 TLS IE code sequence on Solaris 2/x86 violates spec --- Comment #11 from hjl dot tools at gmail dot com 2010-03-09 18:45 --- Sun linker changes 4: 64 48 8b 14 25 00 00 00 00 mov%fs:0x0,%rdx d: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 14 main+0x14 10: R_X86_64_GOTTPOFF cnt-0x4 to 400e0c: 64 48 8b 04 25 00 00 00 00 mov%fs:0x0,%rax 400e15: 48 8d 80 f0 ff ff fflea-0x10(%rax),%rax Nowhere in TLS spec allows the linker to change d: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 14 main+0x14 10: R_X86_64_GOTTPOFF cnt-0x4 to 400e15: 48 8d 80 f0 ff ff fflea-0x10(%rax),%rax It is Sun linker bug. Please report it to them. True, this is a bug, but the input sequence isn't valid according to the spec: 4: 64 48 8b 14 25 00 00 00 00 mov%fs:0x0,%rdx d: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 14 main+0x14 This should be mov%fs:0x0,%rax instead. As I said, garbage in, garbage out. If you disagree, point me at where the spec allows this. Even if so, we should either fix (if allowing other registers is a GNU extension to the base spec) or work around (if it is a misunderstanding on Sun's part) the problem if targetting Solaris: there are linkers in the field that behave as observed, and generating code that causes binaries to crash isn't a good option. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43309
[Bug fortran/42900] gfortran.dg/stat_[12].f90 may fail on NFS filesystems
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-02-01 09:21 --- Subject: Re: gfortran.dg/stat_[12].f90 may fail on NFS filesystems --- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-29 22:35 --- I'd say add a comment to the testcase and WONTFIX. I don't think this is a good idea: this part of the testcase tests a condition that doesn't necessarily hold, and is outside the control of the testsuite. I'd rather remove that part of the test than have this confusing noise in many reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42900
[Bug libgomp/29986] testsuite failures
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-26 16:38 --- Subject: Re: testsuite failures --- Comment #6 from ghazi at gcc dot gnu dot org 2010-01-26 16:31 --- (In reply to comment #5) I've found that the problem doesn't occur when assembler patch 118683-03 is installed. If this issue is fixed, perhaps you could add a note to: http://gcc.gnu.org/install/specific.html#x-x-solaris2 describe the bug and mention which patch fixes it, then close this PR? Sure, will do. It's on my list. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-21 17:11 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility with static common vars. --- Comment #30 from hubicka at ucw dot cz 2010-01-21 16:57 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility with static common vars. Indeed it does: with that chance, a full bootstrap on alpha-dec-osf4.0f and alpha-dec-osf5.1b succeeded. Thanks for confirmation! I would however like to proceed with rest of patch in order to fix the C testcase. Unfortunately I was not able to reproduce the ICE on my machine neither at cross or by bootstrapping at random architectures available to me. Do you think you can gather at least some data about the ICE? (i.e. function name or so). Looking through the patch I don't see any obvious mistakes. It might be side effect of moving RTL generation of assembling alias, but that is needed to avoid RTL from being produced too early before visibilities are set. Unfortunately, I've so far been unsuccessful in getting any debugger to work properly on the gnat1 binary. I've tried gdb mainline, but there's the same error, and indeed gnat1 cannot properly be processed by either objdump or stdump (a native Tru64 UNIX tool to dump symbolic debug information). This seems to partially be a problem with the bootstrap compiler (gcc 4.4.2 in my case), though: the gnat1 from my last successful bootstap can at least be processed by stdump, though gdb 7.0 still SEGVs on it ;-( I could try another mainline bootstrap, though: maybe I'll be more lucky this time or be able what causes gdb to crash. Which patch exactly would you like me to test? Are the ipa.c and varasm.c changes here http://gcc.gnu.org/bugzilla/attachment.cgi?id=19623action=view still up to date? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-20 16:37 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap --- Comment #20 from hubicka at ucw dot cz 2010-01-18 12:57 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap This is really messy: maybe I'll have some more luck with a cross compiler. Indeed it is. I will try, but I had problem building the cross because of missing a.out headers. Can you, please, try the change to ada directory itself? That alone should be enough to cure the bootstrap failure (not the C version of testcase). So I am testing it now and intend to commit it ahead of rest of changes. Indeed it does: with that chance, a full bootstrap on alpha-dec-osf4.0f and alpha-dec-osf5.1b succeeded. Thanks Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-18 12:20 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap --- Comment #16 from hubicka at gcc dot gnu dot org 2010-01-16 14:54 --- Created an attachment (id=19623) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19623action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19623action=view) patch I am testing Unfortunately, this (together with Eric's addition) fails in alpha-dec-osf testing: % /vol/gcc/obj/gcc-4.5.0-20100111/4.0f-gcc/./prev-gcc/xgcc -B/vol/gcc/obj/gcc-4.5.0-20100111/4.0f-gcc/./prev-gcc/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/lib/ -isystem /vol/gcc/alpha-dec-osf4.0f/include -isystem /vol/gcc/alpha-dec-osf4.0f/sys-include-c -g -O2 -gnatpg -gnata -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I/vol/gcc/src/hg/trunk/osf/gcc/ada -I/vol/gcc/src/hg/trunk/osf/gcc/ada/gcc-interface /vol/gcc/src/hg/trunk/osf/gcc/ada/a-except.adb -o ada/a-except.o raised CONSTRAINT_ERROR : SIGSEGV Both gdb 6.6 and 7.0 segv when loading gnat1 on Tru64 UNIX V4.0F, so it's hard to debug from here. On V5.1B, gdb doesn't work properly either: Reading symbols from /vol/gcc/obj/gcc-4.5.0-20100111/5.1b-gcc/gcc/gnat1...Error reading symbol table: Memory exhausted No symbol table is loaded. Use the file command. If I use ladebug instead, I miss the symbolic debug information (ladebug cannot deal with stabs-in-ecoff), but at least I get a stack trace: Thread received signal SEGV stopped at [void _GLOBAL__FD_gnat1(void) 0x121847f58] (ladebug) where 0 0x121847f58 in _GLOBAL__FD_gnat1() in ./gnat1 #1 0x121848b20 in _GLOBAL__FD_gnat1() in ./gnat1 #2 0x12184adfc in _GLOBAL__FD_gnat1() in ./gnat1 #3 0x12184ba6c in _GLOBAL__FD_gnat1() in ./gnat1 #4 0x120cf8a30 in _GLOBAL__FD_gnat1() in ./gnat1 #5 0x12184be88 in _GLOBAL__FD_gnat1() in ./gnat1 #6 0x120cf8a30 in _GLOBAL__FD_gnat1() in ./gnat1 #7 0x120daed08 in _GLOBAL__FD_gnat1() in ./gnat1 #8 0x120dafa98 in _GLOBAL__FD_gnat1() in ./gnat1 #9 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #10 0x120dafbc4 in _GLOBAL__FD_gnat1() in ./gnat1 #11 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #12 0x120dafb10 in _GLOBAL__FD_gnat1() in ./gnat1 #13 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #14 0x120dafb10 in _GLOBAL__FD_gnat1() in ./gnat1 #15 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #16 0x12184a090 in _GLOBAL__FD_gnat1() in ./gnat1 #17 0x12184a104 in _GLOBAL__FD_gnat1() in ./gnat1 #18 0x12184a6d8 in _GLOBAL__FD_gnat1() in ./gnat1 #19 0x1218556c0 in _GLOBAL__FD_gnat1() in ./gnat1 #20 0x12144f8a0 in _GLOBAL__FD_gnat1() in ./gnat1 #21 0x121450dc0 in _GLOBAL__FD_gnat1() in ./gnat1 #22 0x121451510 in _GLOBAL__FD_gnat1() in ./gnat1 More (n if no)? n #23 0x121451b34 in _GLOBAL__FD_gnat1() in ./gnat1 #24 0x1204e5e68 in _GLOBAL__FD_gnat1() in ./gnat1 #25 0x120f52a74 in _GLOBAL__FD_gnat1() in ./gnat1 #26 0x120f55fe8 in _GLOBAL__FD_gnat1() in ./gnat1 #27 0x120f56138 in _GLOBAL__FD_gnat1() in ./gnat1 #28 0x120c156c4 in _GLOBAL__FD_gnat1() in ./gnat1 #29 0x120382b98 in __start(...) in ./gnat1 This is really messy: maybe I'll have some more luck with a cross compiler. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-13
15:03 ---
Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks
Ada bootstrap
--- Comment #10 from simon at pushface dot org 2010-01-11 22:12 ---
I have (locally!) rolled back the change to ipa.c in r154121 as suggested and
successfully built a compiler which successfully compiles the test case in
p.txt. Will that be an adequate basis for a patch to resolve this PR for
4.5.0?
I think so: I've just rolled back the broken checkins, which allowed a
all,ada bootstrap to succeed on alpha-dec-osf{4.0f, 5.1b}. I've
submitted the patch at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00572.html
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug ada/41929] 64-bit null_pointer_deref1 gnat.dg test consumes all available memory
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-12 12:08 --- Subject: Re: 64-bit null_pointer_deref1 gnat.dg test consumes all available memory --- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-11-03 18:49 --- Somewhat expected, see the comment in the test. A patch to disable it on this platform (sparc*-*-solaris2.11) is pre-approved. I've just installed that since the bug hit me again and I've not yet succeeded in the investigation. The failure very likely means that the 64-bit pattern matching code of the fallback routine in config/sparc/sol2-unwind.h misbehaves for Solaris 11. Unfortunately, I don't have access to any Solaris 11 machine so I cannot fix. I've checked __sighndlr in the Solaris 11 64-bit libc.so.1 against sol2-unwind.h (sighndlr_pattern), and they are identical. To debug this, you need to recompile libgcc at -O0 -g and put a breakpoint on sparc64_fallback_frame_state from within the debugger; it will be hit once you resume execution after the SIGSEGV. What happens from that on? Unfortunately, it doesn't hit: (gdb) b sparc64_fallback_frame_state Breakpoint 1 at 0x100017c88: file /vol/gcc/src/hg/trunk/solaris/libgcc/../gcc/config/sparc/sol2-unwind.h, line 38. (gdb) run Starting program: /vol/gcc/obj/gcc-4.5.0-20100107/11-gcc/gcc/testsuite/gnat/null_pointer_deref1.exe [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x0001000141b0 in _ada_null_pointer_deref1 () (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x7fff7f8c81d0 in kill () from /lib/64/libc.so.1 (gdb) cont Continuing. procfs: couldn't find pid -1 in procinfo list. So I'm sort of stuck. dbx doesn't allow me to set a breakpoint in sparc64_fallback_frame_state at all. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41929
[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-11 19:05 --- Subject: Re: [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-06 11:55 --- [...] I'm now running a C-only bootstrap with that patch on mips-sgi-irix5.3. Your previous patch allowed a full bootstrap to finish without a replacement qsort in libiberty. That bootstrap finally completed, so the bug is definitely gone on IRIX 5.3, too. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42157
[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-06 11:55 --- Subject: Re: [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions --- Comment #12 from jamborm at gcc dot gnu dot org 2010-01-05 18:46 --- I posted a slightly simpler patch to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00229.html I'm now running a C-only bootstrap with that patch on mips-sgi-irix5.3. Your previous patch allowed a full bootstrap to finish without a replacement qsort in libiberty. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42157
[Bug libfortran/40344] O32 libgfortran.so fails to link on IRIX 6.5
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-06 12:24 --- Subject: Re: O32 libgfortran.so fails to link on IRIX 6.5 --- Comment #4 from pault at gcc dot gnu dot org 2009-12-18 14:48 --- I cannot see any point in retaining this PR against the gfortran target. I am marking it, especially in light of Rainer's remarks, as WONTFIX. Ok with me. I had meant for a long time to identify which changeset broke linking the O32 libgfortran.so. In the meantime, I've been testing IRIX 6.5 with the O32 multilibs disabled globally. But when I recently retried bootstrap with all three multilibs and gas 2.20, everything worked without problems. So obviously this is all very fragile, and I may decide to deprecate the IRIX 5 and O32 IRIX 6 ports in the future, should this problem come up again. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40344
[Bug bootstrap/42619] [4.5 regression] ICE building stage3 libiberty/regex.o on Tru64 UNIX: verify_ssa failed
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-05 11:30 --- Subject: Re: [4.5 regression] ICE building stage3 libiberty/regex.o on Tru64 UNIX: verify_ssa failed --- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-05 11:16 --- The testcase works on i?86. Same for a i386-pc-solaris2.10 - alpha-dec-osf4.0f cross compiler. This will make reghunting much slower. I've last successfully bootstrapped mainline on that platform on 20091217 (rev 155315). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42619
[Bug bootstrap/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Tru64 UNIX Ada bootstrap
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-12-11 17:25 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Tru64 UNIX Ada bootstrap --- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-27 11:20 --- Is this still an issue? Yes, the problem still exists on alpha-dec-osf4.0f as of 20091210. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-12-11 18:37 --- Subject: Re: Bootstrap with Sun Studio 12.1 fails Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00625.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-24 18:42 --- Subject: Re: [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions --- Comment #1 from jamborm at gcc dot gnu dot org 2009-11-24 18:16 --- Can you please add a check before the qsort call (tree-sra.c, line 1407) whether all pointers in the access_vec seem OK or whether it is SRA that passes the invalid pointer to qsort? Nothing fancy, something as stupid as the loop below should do: for (i =0; i access_count; i++) gcc_assert (((unsigned) VEC_index (access_p, access_vec, i)) 0x1000); If it passes I can't see any other explanation but a bad qsort. If it doesn't we'll need to figure out how the bad pointers get there. It seems that the qsort is broken (although I haven't found any report about qsort on IRIX 5.3 yet). Anyway, I've added a slightly modified qsort from glibc to libiberty (which won't work due to license differences, I suppose, but maybe newlib is an option), which allowed the bootstrap to continue. I'll later check (either with the code above or with gdb watchpoints) what is causing the corruption. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42157
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-20 17:10 --- Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope The #c4 patch looks wrong, instead of that you should IMHO just not use UNUSED macro on __gthread_mutex_destroy argument. It is perfectly fine on __gthread_key_delete. You're right, of course. I should have looked closer. Testing and comparison with pthread results found two other bugs, one of which I could already fix in gthr-solaris.h. I've tried to debug the other (objc) testcase, but gdb 6.6 cannot fully handle it, and I couldn't yet get a gdb 7.0 to debug a 64-bit binary. Given that this is a bootstrap failure, I'll submit and install the fix now and check the remainder later. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-19
11:25 ---
Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not
declared in this scope
--- Comment #7 from alanpae at ilkda dot com 2009-11-18 19:39 ---
changing to --disable-threads also works.
True, but why not omit any --{enable, disable}-threads option and use
the default?
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-18 11:17 --- Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope --- Comment #5 from YLitvinenko at astana dot oilfield dot slb dot com 2009-11-18 07:03 --- Is it better to let configure guess about thread model on OpenSolaris x86 32bit build = snv_126? Sure: the default should be fine unless you have specific reasons to prefer UI threads instead. This has nothing to do with OpenSolaris in any way, but is true for any recent Solaris 2 release. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug target/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-04 17:52 --- Subject: [4.5 regression] cc1 SEGV compiling maxval_r16.c Unfortunately, gdb 7.0 crashes as well, so I cannot investigate the problem this way. But I've been able to produce a minimized testcase, which I'll attach. I'll build a cross compiler from i386-pc-solaris2.10 and see if I can reproduce the problem there. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug target/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-04 18:15 --- Subject: Re: [4.5 regression] cc1 SEGV compiling maxval_r16.c I'll build a cross compiler from i386-pc-solaris2.10 and see if I can reproduce the problem there. Unfortunately, the problem does not reproduce in such a cross compiler, so I'll have to either start a native reghunt or find a way to debug the native compiler (maybe compiling with -g without -O2 or try the stage1 compiler if it is also affected). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug target/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-04 18:34 --- Subject: Re: [4.5 regression] cc1 SEGV compiling maxval_r16.c Unfortunately, the problem does not reproduce in such a cross compiler, so I'll have to either start a native reghunt or find a way to debug the native compiler (maybe compiling with -g without -O2 or try the stage1 compiler if it is also affected). I was misled by the fact that the hg mirror of trunk hasn't been updated in almost two months, so I've been testing the wrong sources. With svn trunk, I can reproduce the problem: run -std=gnu99 -O2 maxval_r16.i Starting program: /vol/gcc/obj/gcc-reghunt/153800/gcc/cc1 -std=gnu99 -O2 maxval_r16.i warning: Temporarily disabling breakpoints for unloaded shared library /usr/lib/ld.so.1 Breakpoint 3 at 0xfeef4b00 Breakpoint 4 at 0xfef01652 mmaxval_r16 Analyzing compilation unit Performing interprocedural optimizations visibility early_local_cleanups whole-program cp inline static-var pure-constAssembling functions: mmaxval_r16 Program received signal SIGSEGV, Segmentation fault. simplify_replace_fn_rtx (x=0x0, old_rtx=0xfee55df0, fn=0, data=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:364 (gdb) where #0 simplify_replace_fn_rtx (x=0x0, old_rtx=0xfee55df0, fn=0, data=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:364 #1 0x0836d367 in simplify_replace_fn_rtx (x=0xfee7f030, old_rtx=0xfee55df0, fn=0, data=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:492 #2 0x0836d367 in simplify_replace_fn_rtx (x=0xfee7f018, old_rtx=0xfee55df0, fn=0, data=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:492 #3 0x0836d367 in simplify_replace_fn_rtx (x=0xfee7f00c, old_rtx=0xfee55df0, fn=0, data=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:492 #4 0x0836d6e2 in simplify_replace_rtx (x=0xfee7f00c, old_rtx=0xfee55df0, new_rtx=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:510 #5 0x082507ef in try_replace_reg (from=0xfee55df0, to=0xfee5fc08, insn=0xfee5369c) at /vol/gcc/src/gcc-dist/gcc/gcse.c:2278 #6 0x08250c46 in constprop_register (insn=0xfee5369c, from=0xfee55df0, to=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/gcse.c:2511 #7 0x08251e14 in execute_rtl_cprop () at /vol/gcc/src/gcc-dist/gcc/gcse.c:2701 #8 0x082ea4b0 in execute_one_pass (pass=0x87a3240) at /vol/gcc/src/gcc-dist/gcc/passes.c:1518 #9 0x082ea577 in execute_pass_list (pass=0x87a3240) at /vol/gcc/src/gcc-dist/gcc/passes.c:1567 #10 0x082ea58b in execute_pass_list (pass=0x87a38a0) at /vol/gcc/src/gcc-dist/gcc/passes.c:1568 #11 0x083d6649 in tree_rest_of_compilation (fndecl=0xfee62000) at /vol/gcc/src/gcc-dist/gcc/tree-optimize.c:392 #12 0x0852436c in cgraph_expand_function (node=0xfee64000) at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1160 #13 0x0852609d in cgraph_optimize () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1219 #14 0x085263f2 in cgraph_finalize_compilation_unit () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1089 #15 0x080beb4f in c_write_global_declarations () at /vol/gcc/src/gcc-dist/gcc/c-decl.c:9489 #16 0x08381ed3 in toplev_main (argc=4, argv=0x80477bc) at /vol/gcc/src/gcc-dist/gcc/toplev.c:1061 #17 0x08126fdf in main (argc=4, argv=0x80477bc) at /vol/gcc/src/gcc-dist/gcc/main.c:35 simplify_replace_fn_rtx is called with x = NULL above, thus GET_MODE (x) segfaults. So it seems likely that the introduction of simplify_replace_fn_rtx is the culprit. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
