[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-11-17 19:43 --- Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope --- Comment #3 from alanpae at ilkda dot com 2009-11-17 19:18 --- [...] Will try building it again with threads=none or the equivalent. Why are you building with --enable-threads=solaris in the first place? Just omit --enable-threads (defaulting to posix); the implementation of both on Solaris 2 is the same, anyway. It is beyond me why anyone would want to program to the old UI Threads interface. That said, I'm testing the obvious fix: Index: gcc/gthr-solaris.h === --- gcc/gthr-solaris.h (revision 154216) +++ gcc/gthr-solaris.h (working copy) @@ -37,7 +37,7 @@ #include errno.h #ifdef __cplusplus -#define UNUSED(x) +#define UNUSED(x) x #else #define UNUSED(x) x __attribute__((unused)) #endif I've now idea what other problems with --enable-threads=solaris might exist, though. This isn't regularly tested. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #11 from ro at techfak dot uni-bielefeld dot de 2009-11-12 16:46 --- Subject: Re: [4.5 regression] cc1 SEGV compiling maxval_r16.c Bootstrap finishes with your patch on alpha-dec-osf5.1b; the testsuite is still running. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-10-22 17:09 --- Subject: Re: Bootstrap with Sun Studio 12.1 fails --- Comment #5 from ghazi at gcc dot gnu dot org 2009-10-21 19:51 --- (In reply to comment #3) (Also, you don't mention what version of gmp you were using.) Right, sorry: I've tried this with the latest version, gmp 4.3.1. Okay I checked gmp source tarballs, and it looks like the SUNPRO clauses defining __GMP_EXTERN_INLINE were added specifically in gmp-4.3.1. I don't see them in gmp-4.2.4 or gmp-4.3.0. Could you please verify bootstrapping gcc with those two versions of gmp plus Sun's cc to see if they work? If it does we should offer it as a workaround for users until we figure out how we want to solve this long-term. I've only tried with gmp 4.3.0, but this works on i386-pc-solaris2.10. So for the moment, we have a workaround. Recommending other versions of gmp as a workaround is helpful even if we hack up a patch to GCC, because gcc-4.3 and 4.4 will not see these fixes until some months in the future when we do another release. Alternatively we may end up recommending to the gmp maintainer(s) that they fix the problem in their package since that's what's really broken IMHO. Either way, it would be helpful to know whether using other versions of gmp would help. I'm not sure we can claim there is GMP breakage at all: they could argue that anyone including gmp.h can be expected to link with -lgmp as well. I just don't know if it is correct to assume that a function defined as extern inline in a header will not be emitted in the object file. Even so, there is breakage in GCC as well: * ansidecl.h has a broken test for C99, and incorrectly assumes Sun cc doesn't support extern inline. The define from inline to nothing causes part of the problem. * Three files in the gcc directory declared extern inline call static functions, which causes Sun Studio cc to error out (cf. the attached diff). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2009-10-22 18:20 --- Subject: Re: Bootstrap with Sun Studio 12.1 fails Even so, there is breakage in GCC as well: * ansidecl.h has a broken test for C99, and incorrectly assumes Sun cc doesn't support extern inline. The define from inline to nothing causes part of the problem. * Three files in the gcc directory declared extern inline call static functions, which causes Sun Studio cc to error out (cf. the attached diff). I have no objection to these patches. However I think you said they don't actually solve the problem right? They are necessary if you fix ansidecl.h to properly handle non-GCC C99 compilers and Sun Studio cc. I have no idea if the Sun compiler is right to error out here, though: that's probably for the reviewer to decide. The other problem is if compilers are allowed to emit code for extern inline functions that are unused: if so, the patches above are not enough and we need to fix either GCC or GMP (unless they argue that it's wrong to include gmp.h, but not to link with -lgmp). So between link xgcc with -lgmp and don't include gmp.h, I prefer the latter approach. Let's not include gmp.h in gcc.c (and anywhere else it isn't necessary.) Fully agreed: linking with -lgmp is just a hack. Say I have a silly question, how is gmp.h getting pulled into gcc.c in the first place? It's supposed to come in via real.h which should only get included by middle-end files linking with real.o ... If we can't disentangle real.h from this then another approach would be to define GENERATOR_FILE (or likely some new macro name) and avoid including the problematic headers that way. Then -D this macro in the gcc.o rule in the Makefile. Seems like a good approach to me. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-10-21 10:54 --- Subject: Re: Bootstrap with Sun Studio 12.1 fails --- Comment #2 from ghazi at gcc dot gnu dot org 2009-10-21 01:48 --- I would prefer a solution that does not involve linking xgcc and cpp with libgmp since that links in unecessary code and/or yields a runtime penalty for loading the shared library. Indeed, even if I've been building gmp and mpfr with --disable-shared to avoid RPATH problems. One option might be to avoid including gmp.h in gcc.c in the first place, as I've already mentioned. I'm not sure how easy that would be, though. It's unusual that we've only just now received this report since gmp has been used since gcc-4.3 (released 1.5 years ago). So I'm curious if something more recently changed to trigger this issue. I.e. did it used to work, and some newer version of either gmp, sun cc, or solaris exposed the problem? Or did it always fail? I've never tried this before (I regularly build with GCC 3.4 as a bootstrap compiler since I want to include Ada support and that requires an Ada compiler), but only just received a report from a colleague who tried to build GCC 4.4 within pkgsrc, but failed in unexpected ways. (Also, you don't mention what version of gmp you were using.) Right, sorry: I've tried this with the latest version, gmp 4.3.1. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-10-21 13:37 --- Subject: Re: Bootstrap with Sun Studio 12.1 fails Just for reference: here's the corresponding pkgsrc problem report by my colleague: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=42109 So at least bootstrapping with Studio 12 exhibits the same problem. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #10 from ro at techfak dot uni-bielefeld dot de 2009-10-09 12:42 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #9 from espindola at google dot com 2009-10-08 18:20 --- [...] The only thing the compiler should need the plugin-api.h for is the enum ld_plugin_symbol_resolution. If we split plugin-api.h in two, we would be able to compile gcc itself without stdint.h. The problem with this approach is that the lto plugin would still fail to build in a system without stdint.h. Is it OK to have optional features like the gold plugin not supported in systems like Tru64 UNIX V4.0F? That would be no problem since AFAIK gold only supports ELF targets by design, and Tru64 UNIX uses ECOFF. Not even GNU ld supports that anymore (or the support has bitrotten to the point of being unusable). Yet another possibility would be to change the build system so that we always build the lto plugin with xgcc (in addition to the plugin-api.h split). No idea how hard this is. Why all those contortions if there seems to be an easy way out: just use the GCC_HEADER_STDINT macro from config/m4 and include the resulting (e.g.) gstdint.h instead of stdint.h? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #13 from ro at techfak dot uni-bielefeld dot de 2009-10-09 13:21 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #11 from espindola at google dot com 2009-10-09 12:58 --- Why all those contortions if there seems to be an easy way out: just use the GCC_HEADER_STDINT macro from config/m4 and include the resulting (e.g.) gstdint.h instead of stdint.h? Interesting. One problem is that this header is also used on gold. Maybe we could do #ifdef HAVE_STDINT_H #include stdint.h #elif HAVE_INTTYPES_H #include inttypes.h #else #include gstdint.h #endif That way gcc would build on anything thanks to GCC_HEADER_STDINT and gold would require something with stdint.h or inttypes.h. Why the complications? Just use GCC_HEADER_STDINT in both gcc and gold and be done with it. If the intention is for gold to support platforms beyond GNU/Linux with ELF, it will run into the need sooner or later anyway. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #14 from ro at techfak dot uni-bielefeld dot de 2009-10-09 13:24 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #12 from joseph at codesourcery dot com 2009-10-09 12:58 --- [...] That would be no problem since AFAIK gold only supports ELF targets by design, and Tru64 UNIX uses ECOFF. Not even GNU ld supports that anymore (or the support has bitrotten to the point of being unusable). gold supports non-ELF hosts (or will once Andrew Pinski's MinGW host patches are in), and in due course should support plugins on such hosts. Ok, but only as a cross-linker to ELF targets, I suppose? (I've no idea whether Tru64 has a dynamic loading interface making plugins on such a host possible at all, but if it has such an interface there is no reason in principle against someone adding support for plugins for a cross compiler and linker from Tru64 to an ELF target.) Tru64 UNIX supports dlopen(3), so you should be set. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-10-05 12:51 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-04 20:27 --- Rainer, I think the checks are in place to properly set HAVE_STDINT_H and HAVE_INTTYPES_H or provide defines for intptr_t and uintptr_t. Can you do actual verification if comment #2 fixes your issue? It works in IRIX 6.5 where the HAVE_STDINT_H check detects that the file, while present, doesn't work properly, and falls back to inttypes.h. It also works on Tru64 UNIX V5.1B, which lacks stdint.h, but has inttypes.h. I wouldn't have expected that lto-plugin.h is used on a non-ELF platform at all. It will break on Tru64 UNIX V4.0F which also lacks inttypes.h, since no replacement definitions of *intptr_t are present yet. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2009-10-05
12:56 ---
Subject: Re: lto-elf.c fails to compile on Solaris
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-03 22:12
---
Waiting for someone with access to that host to investigate.
I've finally understood what was going on: Solaris 2 is one of the few
STDC_0_IN_SYSTEM_HEADERS targets, thus the definition of __STDC__ in the
-g3 -save-temps output changes on where in the file one is (and no
definition is actually emitted, which caused massive confusion for me).
The actual fix is simple: just test for defined(__STDC__) in libelf gelf.h
and libelf.h, as the following fix does:
===
RCS file: RCS/gelf.h,v
retrieving revision 1.1
diff -up -r1.1 gelf.h
--- gelf.h 2009/09/28 17:51:38 1.1
+++ gelf.h 2009/09/28 18:54:27
@@ -39,7 +39,7 @@ extern C {
#endif /* __cplusplus */
#ifndef __P
-# if (__STDC__ + 0) || defined(__cplusplus) || defined(_WIN32)
+# if defined(__STDC__) || defined(__cplusplus) || defined(_WIN32)
# define __P(args) args
# else /* __STDC__ || defined(__cplusplus) */
# define __P(args) ()
===
RCS file: RCS/libelf.h,v
retrieving revision 1.1
diff -up -r1.1 libelf.h
--- libelf.h2009/09/28 17:51:38 1.1
+++ libelf.h2009/09/28 18:54:16
@@ -42,7 +42,7 @@ extern C {
#endif /* __cplusplus */
#ifndef __P
-# if (__STDC__ + 0) || defined(__cplusplus) || defined(_WIN32)
+# if defined(__STDC__) || defined(__cplusplus) || defined(_WIN32)
# define __P(args) args
# else /* __STDC__ || defined(__cplusplus) */
# define __P(args) ()
This allowed me too bootstrap on Solaris 11/SPARC and Solaris 10/x86.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-10-05 14:05 --- Subject: Re: lto-elf.c fails to compile on Solaris --- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-05 13:13 --- That's weird. So is this a libelf bug after all or can we somehow workaround it in gcc? I think it's a libelf bug. I'll report it upstream. In addition, I'll check if STDC_0_IN_SYSTEM_HEADERS is still necessary on Solaris 2. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug libobjc/40703] libobjc fails to configure on Solaris
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2009-09-30 15:41 --- Subject: Re: libobjc fails to configure on Solaris rguenth at gcc dot gnu dot org writes: Can you check if this still applies? It should be broken on trunk as well then. you're right: the problem is gone on both sparc-sun-solaris2.11 and i386-pc-solaris2.10 as of rev. 152243 (20090928). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40703
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-09-16 14:37 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 13:20 --- Does replacing the #include with #ifdef HAVE_STDINT_H #include stdint.h #endif #ifdef HAVE_INTTYPES_H #include inttypes.h #endif work for you? The first part won't help on IRIX 6.5, which has stdint.h, but it's unusable in non-C99 mode. This is fixed (via fixincludes) in recent versions of gcc, though, which one could require to bootstrap. But again, if one bootstraps e.g with MIPSpro cc, it would fail again. The second part should help for e.g. Tru64 UNIX V5.1B, which has inttypes.h, but not on V4.0F, which lacks it. What needs to happen, I think, is a check if some header provides the necessary types and provide them otherwise. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure
--- Comment #34 from ro at techfak dot uni-bielefeld dot de 2009-09-04 13:39 --- Subject: Re: [4.5 regression] bootstrap comparison failure --- Comment #28 from jakub at gcc dot gnu dot org 2009-09-04 12:13 --- In #c21/#c22 there are code generation differences. Rainer, can you please build it using stage1 and stage2 compiler with -da -fdump-noaddr -fdump-unnumbered and find out in which pass they start to diverge? The differences start at stage2-gcc/c-common.c.173r.regmove stage3-gcc/c-common.c.173r.regmove differ: char 5356790, line 108181 What do you need for further investigation? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-09-03 12:45 --- Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc --- Comment #1 from ubizjak at gmail dot com 2009-09-03 11:17 --- get_attr_* does not work with DEBUG_INSN instructions. Backtrace will tell you where to put NONDEBUG_INSN_P instead of INSN_P. Unfortunately, gdb 6.8 cannot cope with the debug information created by either gcc 3.4.5 (my current bootstrap compiler) or mainline as of 20090828 (pre-VTA): #0 fancy_abort (file=0x10fd1be0 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x10fd8590 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/diagnostic.c:728 #1 0x10aab0f4 in _fatal_insn (msgid=0x10fe9df8 unrecognizable insn:, insn=0x41b8c60, file=0x10fd1be0 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x10fd8590 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/rtl-error.c:112 #2 0x10aab158 in _fatal_insn_not_found (insn=0x41b8c60, file=0x10fd1be0 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x10fd8590 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/rtl-error.c:120 #3 0x10a06d9c in get_attr_got (insn=0x41b8c60) at /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md:455 #4 0x10232148 in ?? () #5 0x10232434 in ?? () #6 0x10232d78 in ?? () #7 0x10234098 in mips_initial_elimination_offset (from=77, to=29) at /vol/gcc/src/gcc-dist/gcc/config/mips/mips.c:9124 #8 0x101fdc54 in ?? () #9 0x101f3ce8 in reload (first=0x41b8600, global=1) at /vol/gcc/src/gcc-dist/gcc/reload1.c:971 #10 0x101d8c58 in ?? () #11 0x101d92a8 in ?? () #12 0x1070fd38 in ?? () #13 0x10710184 in execute_pass_list (pass=0x11067900) at /vol/gcc/src/gcc-dist/gcc/passes.c:1341 #14 0x107101b0 in execute_pass_list (pass=0x11069310) at /vol/gcc/src/gcc-dist/gcc/passes.c:1342 #15 0x10c15be8 in tree_rest_of_compilation (fndecl=0x412dd00) at /vol/gcc/src/gcc-dist/gcc/tree-optimize.c:390 #16 0x10acbcd8 in ?? () #17 0x10acbfc4 in ?? () #18 0x10acca44 in ?? () #19 0x10acb840 in cgraph_finalize_compilation_unit () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1042 #20 0x100b22a4 in c_write_global_declarations () at /vol/gcc/src/gcc-dist/gcc/c-decl.c:9378 #21 0x101c2e54 in ?? () #22 0x101c63c8 in ?? () #23 0x101c6528 in toplev_main (argc=5, argv=0x7ffb7ef4) at /vol/gcc/src/gcc-dist/gcc/toplev.c:2414 #24 0x101a5d40 in main (argc=5, argv=0x7ffb7ef4) at /vol/gcc/src/gcc-dist/gcc/main.c:35 The line number in mips.md is useless since it's inside a comment. The 4.5 backtrace is even less useful since gdb aborts at some point: #0 fancy_abort (file=0x11001a98 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x1100eaf0 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/diagnostic.c:728 #1 0x10aab1ac in _fatal_insn (msgid=0x11019cc0 unrecognizable insn:, insn=0x41b8c60, file=0x11001a98 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x1100eaf0 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/rtl-error.c:112 #2 0x10aab214 in _fatal_insn_not_found (insn=0x41b8c60, file=0x11001a98 /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md, line=455, function=0x1100eaf0 get_attr_got) at /vol/gcc/src/gcc-dist/gcc/rtl-error.c:120 #3 0x109fe898 in get_attr_got (insn=0x41b8c60) at /vol/gcc/src/gcc-dist/gcc/config/mips/mips.md:455 #4 0x102310b8 in ?? () warning: GDB can't find the start of the function at 0x102310b7. GDB is unable to find the start of the function at 0x102310b7 and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0x102310b7 for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. Backtrace stopped: previous frame inner to this frame (corrupt stack?) I'm sort of stuck now. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-09-03 13:09 --- Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc --- Comment #4 from jakub at gcc dot gnu dot org 2009-09-03 13:03 --- Just try latest CVS gdb, or apply the 2 fixes recently mentioned on gcc-patches ml (DW_CFA_restore_state gdb fix and DW_LNE_set_distriminator fix), or just recompile anything you see in the backtrace with -g -O0. gdb 6.8 should be able to cope with gcc 3.4.5 output, and since this is in stage1, everything was already built with -g only. I'll try the CVS gdb to see if this helps. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2009-09-03
13:53 ---
Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455
building stage1 N64 libgcc
--- Comment #5 from ubizjak at gmail dot com 2009-09-03 13:08 ---
(In reply to comment #3)
I'm sort of stuck now.
Add -save-temps to failing command on a native compiler, create a
crosscompiler
on i.e. x86_64 and debug ../gcc/cc1 from crosscompiler with -O2 -g
some_file.i in x86_64 host. You don't even need to create binutils cross to
create cc1, although the full build won't finish.
Good point: I routinely forget about cross compilers until I really have
to. This was really beneficial in this case, since the X4450 is a *much*
faster box. I did have to build cross binutils, though, since the bug is
only triggered when certain assembler features are present (I haven't
checked exactly which ones, but a cross compiler without a cross gas 2.19.1
didn't ICE).
I've come up with the following patch, similar to your's for the alpha:
2009-09-03 Rainer Orth r...@cecitec.uni-bielefeld.de
PR target/41240
* config/mips/mips.c (mips_function_has_gp_insn): Ignore debug insn.
Index: config/mips/mips.c
===
--- config/mips/mips.c (revision 151371)
+++ config/mips/mips.c (working copy)
@@ -8579,7 +8579,7 @@
push_topmost_sequence ();
for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
- if (USEFUL_INSN_P (insn)
+ if (USEFUL_INSN_P (insn) !DEBUG_INSN_P (insn)
(get_attr_got (insn) != GOT_UNSET
|| mips_small_data_pattern_p (PATTERN (insn
{
With it, my testcase passed and the cross-build ran until it hit missing
target headers. I'm now continuing the really bootstrap and will submit it
once that finishes.
Thanks alot.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41240
[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-09-02 15:25 --- Subject: Re: [4.5 regression] Solaris 10/x86 comparison failure after VTA merge jakub at gcc dot gnu dot org writes: bootstrap-debug intentionally compares (stripped) -g compiled objects with (stripped) -g0 compiled objects. Please provide info requested in: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224#c4 r...@zingana 192 /vol/gcc/src/gcc-dist/contrib/compare-debug --preserve stage[23]-gcc/plugin.o stage2-gcc/plugin.o.stripped. stage3-gcc/plugin.o.stripped. differ: char 33, line 1 preserving stage2-gcc/plugin.o.stripped. stage3-gcc/plugin.o.stripped. objdump -s output is identical, but e.g. objdump -h output differs considerably, though only in file offsets: --- stage2-gcc/plugin.o.stripped.objdump2009-09-02 17:23:20.999895800 +0200 +++ stage3-gcc/plugin.o.stripped.objdump2009-09-02 17:23:23.631184000 +0200 @@ -1,19 +1,19 @@ -stage2-gcc/plugin.o.stripped: file format elf32-i386 +stage3-gcc/plugin.o.stripped: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0ce9 0034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE - 1 .data 0078 0d20 2**5 + 1 .data 0078 12a0 2**5 CONTENTS, ALLOC, LOAD, RELOC, DATA - 2 .bss 003c 0da0 2**5 + 2 .bss 003c 13a0 2**5 ALLOC - 3 .rodata.str1.1 019e 0da0 2**0 + 3 .rodata.str1.1 019e 13a0 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA - 4 .rodata.str1.4 0338 0f40 2**2 + 4 .rodata.str1.4 0338 1540 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA - 5 .rodata 01b3 1280 2**5 + 5 .rodata 01b3 1880 2**5 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA - 6 .comment 0042 1433 2**0 + 6 .comment 0042 1b04 2**0 CONTENTS, READONLY Let me know what else you need from objdump. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228
[Bug bootstrap/41228] [4.5 regression] Solaris 10/x86 comparison failure after VTA merge
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2009-09-02
16:30 ---
Subject: Re: [4.5 regression] Solaris 10/x86 comparison failure after VTA
merge
aoliva at gcc dot gnu dot org writes:
Thanks, Rainer. Could I ask for your help in coming up with a minimal
testcase
that, compiled with both -g and -g0, fails the contrib/compare-debug test? I
see no other alternative than to test whether something like that stands a
chance of working before setting out to build stage2 with -gtoggle. Thanks in
advance,
Sure: I obviously care about Solaris (and IRIX and Tru64 UNIX :-), and even
a minimal hello.c fails the test:
r...@zingana 218 cat hello.c
int
main (void)
{
return 0;
}
r...@zingana 219 ./xgcc -B./ -g0 -c hello.c -o hello-g0.o
r...@zingana 220 ./xgcc -B./ -g -c hello.c -o hello-g.o
r...@zingana 221 /vol/gcc/src/gcc-dist/contrib/compare-debug --preserve
hello-g0.o hello-g.o
hello-g0.o.stripped. hello-g.o.stripped. differ: char 33, line 1
preserving hello-g0.o.stripped. hello-g.o.stripped.
r...@zingana 222 ls -l hello*.o*
-rw-r--r-- 1 ro gcc 1964 Sep 2 18:23 hello-g.o
-rw-r--r-- 1 ro gcc 884 Sep 2 18:21 hello-g.o.stripped
-rw-r--r-- 1 ro gcc 884 Sep 2 18:23 hello-g.o.stripped.
-rw-r--r-- 1 ro gcc 630 Sep 2 18:23 hello-g0.o
-rw-r--r-- 1 ro gcc 630 Sep 2 18:21 hello-g0.o.stripped
-rw-r--r-- 1 ro gcc 630 Sep 2 18:23 hello-g0.o.stripped.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228
[Bug libfortran/41169] [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-08-27 16:25 --- Subject: Re: [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared joseph at codesourcery dot com writes: There is no use in keeping definitions relating to imaginary types when GCC doesn't implement them, and the uses of imaginary types are extremely limited (as far as I can tell, they are only useful for building up complex values with exact control of infinities, NaNs and signed zeros in each component). Ok, thanks. So I'll implement my manual hack in fixincludes and submit that patch once I'm ready. I'll probably try to get a fix into OpenSolaris for CR 6549313 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6549313 so the fix will become unnecessary in the future. What I don't fully understand yet is whether imaginary support in GCC isn't/won't be there simply because it's been removed from C99 or nobody thinks the work to implement it is worthwile. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41169
[Bug libfortran/41169] [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-08-26 17:51 --- Subject: Re: [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared --- Comment #2 from dje at gcc dot gnu dot org 2009-08-25 21:32 --- Just follow the style that Steve Ellcey and I used for HPUX and AIX. You basically should be able to take either of our stanzas in inclhack.def and substitute the regex in the select line that matches Solaris (and another for Irix). Choose an appropriate hackname, set mach line for Solaris, and use the original text from the header file in test_text. I don't have access to either an HP-UX or AIX system, but there may be an additional complication on Solaris 2 and IRIX 6: unlike e.g. glibc and maybe HP-UX and/or AIX, both systems define both _Complex_I and _Imaginary_I and I in terms of the latter. I'm not certain if we can just throw the _Imaginary_I/imaginary definitions away and use #define _Complex_I (__extension__ 1.0iF) instead or we must/should maintain the imaginary related definitions. There seems to be some discussion around having removed imaginary/_Imaginary_I in C99 TC2, but I'm not sure what the resolution was. I've manually done the former by dropping a hacked complex.h into gcc/include-fixed and as expected the bootstrap finished. If this is the proper way to go, I can implement this via fixincludes. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41169
[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #11 from ro at techfak dot uni-bielefeld dot de 2009-07-29 08:20 --- Subject: Re: [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines htl10 at users dot sourceforge dot net writes: I have a slightly different message on alphaev68-dec-osf5.1a with gcc 4.4.1, but possibly the same problem: (I can bootstrap 4.3.3, but no luck with 4.4.0/4.4.1): [...] find: bad option -path [...] The 'find: bad option -path' message probably means the command was truncated, I believe. It looks pretty long to me :-). No, that's a different problem: -path is a GNU find extension which Tru64 UNIX find doesn't support (nor do e.g. Solaris 10 and IRIX 6.5 find). It's simply unportable code. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug bootstrap/39022] lto-plugin is built unconditionally
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-07-14 17:26 --- Subject: Re: lto-plugin is built unconditionally --- Comment #4 from bje at gcc dot gnu dot org 2009-07-14 04:39 --- Can this PR be closed now, Rainer? Yes, this works now. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39022
[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-07-09 19:17 --- Subject: Re: [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC rsandifo at gcc dot gnu dot org writes: Do you only see this for libjava? Yes, all other library tests are normal (no massive differences between 32 and 64 bit). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40699
[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-07-09
20:17 ---
Subject: Re: [4.5 Regression] All sparcv9 libjava execution tests fail on
Solaris 11/SPARC
rsandifo at gcc dot gnu dot org writes:
OK, I'm going to need some help debugging this one. First of all,
how are you running your tests? E.g.
(a) are you using --target_board unix/-m64,
(b) is -m64 the default, or
(c) something else?
I'm using --target_board 'unix{,-mabi=64}'.
Second, this:
[find_libgcc_s $GCJ_UNDER_TEST]
is supposed to return the directory of the 64-bit libgcc, but presumably
it isn't doing. Could you compare the result of that command with
something like:
[find_libgcc_s $GFORTRAN_UNDER_TEST]
which seems to work?
I've tried running runtest manually both in gcc/testsuite/gfortran like
this
runtest --tool gfortran --srcdir /vol/gcc/src/gcc-dist/gcc/tesuite
--target_board 'unix{-m64}' -v
which works correctly, and in sparc-sun-solaris2.11/libjava/testsuite like
so
runtest INTERPRETER=yes --tool libjava --srcdir
/vol/gcc/src/gcc-dist/libjava/testsuite --target_board 'unix{-m64}' -v
which fails horribly:
Expect binary is expect
Using /vol/gnu/share/dejagnu/runtest.exp as main test driver
Verbose level is 1
Login name is ro
Found
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/site.exp
Found
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/site.exp
Using test sources in /vol/gcc/src/gcc-dist/libjava/testsuite
Using test binaries in
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite
Tool root directory is
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11
Using /vol/gnu/share/dejagnu to find libraries
WARNING: Couldn't find the global config file.
Loading /vol/gnu/share/dejagnu/utils.exp
Loading /vol/gnu/share/dejagnu/framework.exp
Loading /vol/gnu/share/dejagnu/debugger.exp
Loading /vol/gnu/share/dejagnu/remote.exp
Loading /vol/gnu/share/dejagnu/mondfe.exp
Loading /vol/gnu/share/dejagnu/xsh.exp
Loading /vol/gnu/share/dejagnu/telnet.exp
Loading /vol/gnu/share/dejagnu/rlogin.exp
Loading /vol/gnu/share/dejagnu/kermit.exp
Loading /vol/gnu/share/dejagnu/tip.exp
Loading /vol/gnu/share/dejagnu/rsh.exp
Loading /vol/gnu/share/dejagnu/ftp.exp
Loading /vol/gnu/share/dejagnu/target.exp
Loading /vol/gnu/share/dejagnu/targetdb.exp
Loading /vol/gnu/share/dejagnu/libgloss.exp
Loading library file /vol/gcc/src/gcc-dist/libjava/testsuite/lib/libjava.exp
Found
/vol/gcc/src/gcc-dist/libjava/testsuite/../../gcc/testsuite/lib/target-libpath.exp
Testing libjava
Opening log files in .
Test Run By ro on Thu Jul 9 22:03:41 2009
Native configuration is sparc-sun-solaris2.11
=== libjava tests ===
setting trap for SIGTERM to terminated
setting trap for SIGINT to interrupted by user
setting trap for SIGQUIT to interrupted by user
setting trap for SIGSEGV to segmentation violation
dirlist is /vol/gnu/share/dejagnu/baseboards
pushing config for build, name is galeras
dirlist is /vol/gnu/share/dejagnu/baseboards
pushing config for host, name is galeras
target list is unix{-m64}
Schedule of variations:
unix/-m64
target is unix/-m64
Running target unix/-m64
dirlist is /vol/gnu/share/dejagnu/baseboards/galeras
/vol/gnu/share/dejagnu/baseboards
Using /vol/gnu/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /vol/gnu/share/dejagnu/config/unix.exp as generic interface file for
target.
Using /vol/gcc/src/gcc-dist/libjava/testsuite/config/default.exp as
tool-and-target-specific interface file.
Loading /vol/gnu/share/dejagnu/standard.exp
pushing config for target, name is unix/-m64
Running /vol/gcc/src/gcc-dist/libjava/testsuite/libjava.cni/cni.exp ...
version: 4.5.0
jar file is
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../libgcj-4.5.0.jar
gcj: libgcj.spec: No such file or directory
while executing
exec /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/gcc/gcj
-B/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/gcc/ --encoding=UTF-8 -m64
--print-multi-directory
(eval body line 1)
invoked from within
eval exec $compiler [board_info target multilib_flags]
--print-multi-directory
(procedure find_libgcc_s line 16)
invoked from within
find_libgcc_s $GCJ_UNDER_TEST
(procedure libjava_init line 71)
invoked from within
${tool}_init $test_file_name
invoked from within
if [info exists tool] {
if { [info procs ${tool}_init] != } {
${tool}_init $test_file_name
}
}
invoked from within
if [file exists $test_file_name] {
set timestart [timestamp]
if [info exists tool] {
if { [info procs ${tool}_init] != } {
${tool}_init...
(procedure runtest line 14)
invoked from within
runtest $test_name
(foreach body line 42)
invoked from within
foreach test_name [lsort [find ${dir} *.exp
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-05-13 13:02 --- Subject: Re: [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld jakub at gcc dot gnu dot org writes: Look for DEEP_BRANCH_PREDICTION in config/i386/*. On i386/i486/i586 doing call 1f; 1: is just fine, but on several newer CPUs it confuses return prediction logic (more calls than rets), so when optimizing for those CPUs gcc calls a separate pad which just reads the return address from the stack and immediately returns. This pad can be shared among all functions within the same binary or shared Ok, thanks for the explanation. library. If hidden linkonce doesn't work on some Solaris version, you should just make sure USE_HIDDEN_LINKONCE is 0 for that target. Indeed: that far easier than determining which version of Sun ld has all the necessary support. Proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00723.html Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-05-07
16:30 ---
Subject: Re: [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using
Sun ld
hjl dot tools at gmail dot com writes:
The difference is in how to get PC for -fPIC:
bash-3.2$ cat p.c
void
foo ()
{
bar ();
}
bash-3.2$ gcc -m32 -fPIC p.c -S -O3 -mtune=i386
[...]
bash-3.2$ gcc -m32 -fPIC p.c -S -O3 -mtune=i686
[...]
That's what I saw already when comparing crtbegin.s for i386 and i686.
What I still don't understand is why the code is different between those
two.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug middle-end/39927] [4.5 Regression]: build breakage for cris-elf building libstdc++-v3
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-04-27 13:35 --- Subject: Re: [4.5 Regression]: build breakage for cris-elf building libstdc++-v3 ebotcazou at gcc dot gnu dot org writes: The revision corresponding to the fix for the PR should bootstrap. Indeed it does. Starting from there (and the fact that insert_partition_copy_on_edge occurs in the cc1 stacktrace), I could identify this patch as the culprit: 2009-04-26 Michael Matz m...@suse.de Expand from SSA. The ICE occurs while building the sparcv9 libgcc: % cc1 libgcc2.i -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -m64 -auxbase-strip _absvsi2.o -O2 -fPIC __absvdi2 __absvsi2 Analyzing compilation unit Performing interprocedural optimizations visibility early_local_cleanups summary generate cp inline static-var pure-constAssembling functions: __absvsi2 /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__absvsi2': /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:240: internal compiler error: in emit_move_insn, at expr.c:3387 I get the following cc1 stacktrace: Breakpoint 1, fancy_abort (file=0xdf8758 /vol/gcc/src/gcc-dist/gcc/expr.c, line=3387, function=0xdf8af8 emit_move_insn) at /vol/gcc/src/gcc-dist/gcc/diagnostic.c:724 (gdb) where #0 fancy_abort (file=0xdf8758 /vol/gcc/src/gcc-dist/gcc/expr.c, line=3387, function=0xdf8af8 emit_move_insn) at /vol/gcc/src/gcc-dist/gcc/diagnostic.c:724 #1 0x003cbf18 in emit_move_insn (x=0xff0b3f80, y=0xff11a048) at /vol/gcc/src/gcc-dist/gcc/expr.c:3386 #2 0x00cfe0c4 in insert_partition_copy_on_edge (e=0xff1d09f0, dest=3, src=0) at /vol/gcc/src/gcc-dist/gcc/tree-outof-ssa.c:155 #3 0x00cfff0c in elim_create (g=0xf79ae0, T=3) at /vol/gcc/src/gcc-dist/gcc/tree-outof-ssa.c:542 #4 0x00d00434 in eliminate_phi (e=0xff1d09f0, g=0xf79ae0) at /vol/gcc/src/gcc-dist/gcc/tree-outof-ssa.c:583 #5 0x00d01480 in expand_phi_nodes (sa=0xf3bb5c) at /vol/gcc/src/gcc-dist/gcc/tree-outof-ssa.c:756 #6 0x00c129ac in gimple_expand_cfg () at /vol/gcc/src/gcc-dist/gcc/cfgexpand.c:2505 #7 0x00662284 in execute_one_pass (pass=0xe9c7f8) at /vol/gcc/src/gcc-dist/gcc/passes.c:1286 #8 0x00662638 in execute_pass_list (pass=0xe9c7f8) at /vol/gcc/src/gcc-dist/gcc/passes.c:1335 #9 0x00866fc4 in tree_rest_of_compilation (fndecl=0xff0dc180) at /vol/gcc/src/gcc-dist/gcc/tree-optimize.c:394 #10 0x00afe8a4 in cgraph_expand_function (node=0xfef8ea00) at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1051 #11 0x00afeb40 in cgraph_expand_all_functions () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1110 #12 0x00aff39c in cgraph_optimize () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1324 #13 0x001267a8 in c_write_global_declarations () at /vol/gcc/src/gcc-dist/gcc/c-decl.c:8306 #14 0x007c4750 in compile_file () at /vol/gcc/src/gcc-dist/gcc/toplev.c:988 #15 0x007c7a5c in do_compile () at /vol/gcc/src/gcc-dist/gcc/toplev.c:2248 #16 0x007c7b80 in toplev_main (argc=11, argv=0xffbff604) at /vol/gcc/src/gcc-dist/gcc/toplev.c:2293 #17 0x00213aa4 in main (argc=11, argv=0xffbff604) at /vol/gcc/src/gcc-dist/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39927
[Bug bootstrap/39645] genattrtab.c does not compile under sparc Linux
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-04-24 15:41 --- Subject: Re: genattrtab.c does not compile under sparc Linux michael dot a dot richmond at nasa dot gov writes: I have not investigated further Ok, thanks. The question was addressed more to Laurent, who had taken on the bug. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39645
[Bug libgomp/38086] [4.2/4.3 Regression] libgomp fails to build if assembler doesn't support .symver
--- Comment #13 from ro at techfak dot uni-bielefeld dot de 2009-01-08 17:31 --- Subject: Re: [4.2/4.3/4.4 Regression] libgomp fails to build if assembler doesn't support .symver bkoz at gcc dot gnu dot org writes: Any luck getting past the libgomp build failure? All that is needed is trying Jakub's patch and getting confirmation that it works. If it does then the libgomp/libstdc++ bits can go in at the same time without further delay. Sure: as I had already written in Comment #7 of PR libstdc++/38092, I wanted to let the make check run to completion. This has happened now and the results are more or less identical to what I got as of 20081110 with --disable-symvers. So from my perspective, all is fine (and the patches have already been checked in). Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38086
[Bug libstdc++/38092] [4.2/4.3/4.4 Regression] libstdc++ doesn't build with GNU ld 2.19 and Sun as: no .symver support
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-01-07 13:26 --- Subject: Re: [4.2/4.3/4.4 Regression] libstdc++ doesn't build with GNU ld 2.19 and Sun as: no .symver support jakub at gcc dot gnu dot org writes: Rainer, can you please test also this patch? Sure: I've applied it to the same source tree, moved the sparc-sun-solaris2.11/libstdc++-v3 and sparc-sun-solaris2.11/sparcv9/libstdc++-v3 directories asside and restarted the build/test. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38092
[Bug libstdc++/38092] [4.2/4.3/4.4 Regression] libstdc++ doesn't build with GNU ld 2.19 and Sun as: no .symver support
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-01-07 14:41 --- Subject: Re: [4.2/4.3/4.4 Regression] libstdc++ doesn't build with GNU ld 2.19 and Sun as: no .symver support ro at techfak dot uni-bielefeld dot de writes: Sure: I've applied it to the same source tree, moved the sparc-sun-solaris2.11/libstdc++-v3 and sparc-sun-solaris2.11/sparcv9/libstdc++-v3 directories asside and restarted the build/test. doesn't look good so far: while libstdc++-v3 now builds, e.g. all libgomp.c++ tests fail like so: FAIL: libgomp.c++/atomic-1.C -O0 (test for excess errors) Excess errors: /vol/gccsrc/obj/gcc-4.4.0-20090106/11-gcc-gld/sparc-sun-solaris2.11/./libgomp/../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `std::basic_istreamwchar_t, std::char_traitswchar_t ::ignoreXX()' /vol/gccsrc/obj/gcc-4.4.0-20090106/11-gcc-gld/sparc-sun-solaris2.11/./libgomp/../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `std::basic_istreamchar, std::char_traitschar ::ignore(int)' /vol/gccsrc/obj/gcc-4.4.0-20090106/11-gcc-gld/sparc-sun-solaris2.11/./libgomp/../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `std::basic_istreamwchar_t, std::char_traitswchar_t ::ignore(int)' /vol/gccsrc/obj/gcc-4.4.0-20090106/11-gcc-gld/sparc-sun-solaris2.11/./libgomp/../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `std::basic_istreamchar, std::char_traitschar ::ignoreXX()' Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38092
[Bug libstdc++/38092] [4.2/4.3/4.4 Regression] libstdc++ doesn't build with GNU ld 2.19 and Sun as: no .symver support
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2009-01-07 17:35 --- Subject: Re: [4.2/4.3/4.4 Regression] libstdc++ doesn't build with GNU ld 2.19 and Sun as: no .symver support jakub at gcc dot gnu dot org writes: I see, does this extra hunk (incremental patch) fix it? Looks good so far: the libgomp testsuite is mostly clean, and libstdc++-v3 testing suffers from another (unrelated) problem only: FAIL: 18_support/bad_typeid/cons_virtual_derivation.cc (test for excess errors) Excess errors: /vol/gcc/lib/gld-2.19: warning: section `.bss' type changed to PROGBITS This seems to be due to a Sun as bug (already reported). I'll let the make check run to completion, but it seems that both this PR and libgomp/38086 are fixed now. Thanks a lot. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38092
[Bug libgomp/38086] [4.2/4.3/4.4 Regression] libgomp fails to build if assembler doesn't support .symver
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-01-06 13:26 --- Subject: Re: [4.2/4.3/4.4 Regression] libgomp fails to build if assembler doesn't support .symver jakub at gcc dot gnu dot org writes: Patch I'm now testing on x86_64-linux, can you do the same on Solaris? Sure, a bootstrap is currently in progress on sparc-sun-solaris2.11 with Sun as and GNU ld 2.19. I'll have to work around PR libstdc++/38092, though. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38086
[Bug libgomp/38086] [4.2/4.3/4.4 Regression] libgomp fails to build if assembler doesn't support .symver
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2009-01-06 14:00 --- Subject: Re: [4.2/4.3/4.4 Regression] libgomp fails to build if assembler doesn't support .symver jakub at gcc dot gnu dot org writes: PR38092 would be fixed similarly, I've just started with libgomp. True, especially since the libgomp configure code started from the libstdc++-v3 version, IIRC. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38086
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #14 from ro at techfak dot uni-bielefeld dot de 2009-01-06 14:28 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX hubicka at gcc dot gnu dot org writes: sorry for delays, somehow non-tuplified alpha shot this off the todo list. No problem, at least I've found a workaround for the time being. I still can't build the target: ../../gcc/mips-tfile.c:672:24: error: mips/a.out.h: No such file or directory ../../gcc/mips-tfile.c:693: error: 'scNil' undeclared here (not in a function) [...] This shouldn't matter: mips-tfile is only used to postprocess the executable to introduce debugging information. While this is a known problem (PR target/3746), it doesn't matter since cross-gas doesn't work for ecoff targets for a long time, so you can't cross-compile to alpha-dec-osf anyway. Since the problem at hand is a SEGV in cc1plus, just build that one. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug bootstrap/26066] disable-threads causes undefined reference to pthread_kill and pthread_sigmask
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-01-06 14:39 --- Subject: Re: disable-threads causes undefined reference to pthread_kill and pthread_sigmask pinskia at gcc dot gnu dot org writes: libjava is not designed to run in single threads mode at all. But wouldn't it be better to reject --disable-threads in configure with an appropriate error message rather than getting link failures far into the build? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26066
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #12 from ro at techfak dot uni-bielefeld dot de 2009-01-05 18:34 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX pinskia at gcc dot gnu dot org writes: Does this happen still? I'm pretty sure it does, though I've got the workarounds from Comment #10 in my tree to be able to test on the platform at all. Unfortunately, Jan hasn't yet worked on this, although he introduced both parts of this regressions (and it can be reproduced in a cross compiler). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug libffi/26048] [4.2/4.3/4.4 Regression] libffi doesn't build on Solaris 10/x86 with native assembler
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-12-08 17:32 --- Subject: Re: [4.2/4.3/4.4 Regression] libffi doesn't build on Solaris 10/x86 with native assembler New patch here: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00481.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26048
[Bug ada/37799] SEGV compiling ada/ada.ads in stage2
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-12-03 14:31 --- Subject: Re: SEGV compiling ada/ada.ads in stage2 ebotcazou at gcc dot gnu dot org writes: But these are not 64-bit compilers, see the target triplet. You need to pass --build=sparc64-sun-solaris2.11 and start with a 64-bit compiler. I fear you're right: it occured to me that the GCC 3.4.3 I started with didn't have proper multilib support. I had started with gcc3.4.3 -m64 (which would have been a 64-bit compiler), but forgot to specify the correct target triplet, though I'm pretty sure I did so when I first reported the bug. I've now used a 32-bit gcc 4.4.0 with -m64 as bootstrap compiler and specified --build=sparcv9-sun-solaris2.10. This time, the bootstrap finished, so this has been pilot error ;-( Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37799
[Bug ada/37799] SEGV compiling ada/ada.ads in stage2
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2008-12-02 21:38 --- Subject: Re: SEGV compiling ada/ada.ads in stage2 ebotcazou at gcc dot gnu dot org writes: Works for me on Solaris 10 as well. I've just tried again on current mainline (trunk revision 142371) on Solaris 11 (snv_103), both with Sun as and GNU as 2.19, and get the same error in both cases. The compilers were configured as follows: Target: sparc-sun-solaris2.11 Configured with: /vol/gcc/src/gcc-dist/configure CC=/vol/gcc/obj/gcc-4.4.0-20081202/11-gcc-v9/gccv9 --with-gmp-include=/vol/gcc/obj/gmp-4.2.1-v9 --with-gmp-lib=/vol/gcc/obj/gmp-4.2.1-v9/.libs --with-mpfr-include=/vol/gcc/obj/mpfr-2.3.2-v9 --with-mpfr-lib=/vol/gcc/obj/mpfr-2.3.2-v9/.libs --with-gnu-as --with-as=/vol/gcc/lib/gas-2.19 --enable-languages=c,ada --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls Thread model: posix gcc version 4.4.0 20081202 (experimental) [trunk revision 142371] (GCC) resp. Target: sparc-sun-solaris2.11 Configured with: /vol/gcc/src/gcc-dist/configure CC=/vol/gcc/obj/gcc-4.4.0-20081202/11-gcc-v9/gccv9 --with-gmp-include=/vol/gcc/obj/gmp-4.2.1-v9 --with-gmp-lib=/vol/gcc/obj/gmp-4.2.1-v9/.libs --with-mpfr-include=/vol/gcc/obj/mpfr-2.3.2-v9 --with-mpfr-lib=/vol/gcc/obj/mpfr-2.3.2-v9/.libs --enable-languages=c,ada --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls Thread model: posix gcc version 4.4.0 20081202 (experimental) [trunk revision 142371] (GCC) I'm currently running bootstraps on Solaris 10 (both with Sun as and GNU as 2.19) to verify if this makes a difference. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37799
[Bug ada/37799] SEGV compiling ada/ada.ads in stage2
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2008-12-02 22:28 --- Subject: Re: SEGV compiling ada/ada.ads in stage2 ro at techfak dot uni-bielefeld dot de writes: I'm currently running bootstraps on Solaris 10 (both with Sun as and GNU as 2.19) to verify if this makes a difference. It doesn't: I get exactly the same error. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37799
[Bug libgcj/38251] [4.4 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-11-24 18:04 --- Subject: Re: [4.4 Regression] tools.zip doesn't build on systems with short command lines aph at gcc dot gnu dot org writes: Please try jar cf ../tools.zip `find . -name .svn -prune -o -type d -print` while this works, many files are added several times, e.g. % jar tf ../tools.zip |grep classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class If one wanted to go this path, one would need to prune all but the deepest directories. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug libgcj/38251] [4.4 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2008-11-24 18:37 --- Subject: Re: [4.4 Regression] tools.zip doesn't build on systems with short command lines aph at gcc dot gnu dot org writes: jar has an update mode that adds files, so I can use that. How long may an arglist be? % getconf ARG_MAX 38912 I'm astonished that it is so low; I thought only IRIX 6 had a limit this close to the old 20k default. Unfortunately, the version of jar I use reports % jar u /vol/gnu/bin/jar: `-u' mode unimplemented. % jar --version jar (fastjar) 0.92-gcc Copyright 1999, 2000, 2001 Bryan Burns Copyright 2002 Free Software Foundation This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Perhaps I should simply move it out of the way and use zip instead. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #34 from ro at techfak dot uni-bielefeld dot de 2008-11-20 17:14 --- Subject: Re: [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 Fixed for 4.3.3, 4.4.0: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00990.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug target/29987] libgomp.c++/ctor-9.C failure
--- Comment #9 from ro at techfak dot uni-bielefeld dot de 2008-11-19 18:05 --- Subject: Re: libgomp.c++/ctor-9.C failure ro at techfak dot uni-bielefeld dot de writes: jakub at gcc dot gnu dot org writes: Anyway, the following patch fixes this in a cross from x86_64-linux to sparc*-sun-solaris10. Can somebody please bootstrap/regtest it? will do, thanks. Bootstrap with the patch completed (unlike the situation without, where libgomp.so failed to link). Testresults are still hampered by the following gld 2.19 warning /vol/gcc/lib/gld-2.19: warning: section `.bss' type changed to PROGBITS which I'll investigate. There's something in http://sourceware.org/bugzilla/show_bug.cgi?id=7027 (Comments #18 - 24). It seems like Sun as doesn't mark .bss.* sections as NOBITS. Probably another bug to take up with Sun. Does i?86-sun-solaris* as have the same bug or not? I'll have to check this. Currently, one cannot use Sun as for x86_64, so the default config will use gas instead. I'll try the non-multilib config and see if it is affected as well. Apart from the problems reported in Comment #8, Sun as heavily chokes on the tls conftest_s in gcc/configure.ac: * as is invoked with the gas-only --fatal-warnings, which lets Sun as choke. * The test itself uses the gas .section syntax that Sun as doesn't understand. To properly handle this, one would need to have two sections as in the sparc-*-solaris2* case. Right now, it doesn't make much sense to pursue this. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug target/29987] libgomp.c++/ctor-9.C failure
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2008-11-18 13:16 --- Subject: Re: libgomp.c++/ctor-9.C failure jakub at gcc dot gnu dot org writes: Anyway, the following patch fixes this in a cross from x86_64-linux to sparc*-sun-solaris10. Can somebody please bootstrap/regtest it? will do, thanks. Does i?86-sun-solaris* as have the same bug or not? I'll have to check this. Currently, one cannot use Sun as for x86_64, so the default config will use gas instead. I'll try the non-multilib config and see if it is affected as well. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug target/29987] libgomp.c++/ctor-9.C failure
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-11-18 13:32 --- Subject: Re: libgomp.c++/ctor-9.C failure ro at techfak dot uni-bielefeld dot de writes: Does i?86-sun-solaris* as have the same bug or not? I'll have to check this. Currently, one cannot use Sun as for x86_64, so the default config will use gas instead. I'll try the non-multilib config and see if it is affected as well. Bootstrap on Solaris 10/x86 with Sun as already breaks when building the stage1 libgcc now: Assembler: libgcov.c /var/tmp//ccRimvP4.s, line 116 : Syntax error Near line: repnz scasb and many more. I have no idea what as complains about: a quick strings on the binary reveals that it seems to support the instruction, and the x86 Assembly Language Reference Manual at http://docs.sun.com/app/docs/doc/817-5477/enmzx?a=view suggests likewise in the `String Instructions' table (table 3-8). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug target/38118] gcc emits non-TLS data as TLS on Solaris 11/SPARC
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-11-17 14:25 --- Subject: Re: gcc emits non-TLS data as TLS on Solaris 11/SPARC I'm not completely sure this is a bug in Sun as. If you consider the assembler code for my testcase produced by gcc: .global tsd .section.tbss,#alloc,#write,#tls .align 4 .type tsd, #tls_object .size tsd, 4 tsd: .skip 4 .common non_tsd,4,4 versus what Studio 12 cc produces: .section.bss,#alloc,#write .common non_tsd,4,4 .section.tbss,#alloc,#write,#tls .common tsd,4,4 you see that gcc lacks the section switching between non_tsd and tsd. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38118
[Bug bootstrap/37422] [4.4 regression] IRA merge breaks Solaris/x86 bootstrap
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2008-11-13 14:13 --- Subject: Re: [4.4 regression] IRA merge breaks Solaris/x86 bootstrap jakub at gcc dot gnu dot org writes: I see gcc-testresults for this target posted in: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg00649.html Was this with -fno-ira or is this bug gone? The bug is gone for me; sorry for not closing the PR. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37422
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #31 from ro at techfak dot uni-bielefeld dot de 2008-11-06 15:45 --- Subject: Re: [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 Fixed for 4.2.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #35 from ro at techfak dot uni-bielefeld dot de 2008-11-05 13:40 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected jakub at gcc dot gnu dot org writes: This bug seems to be fixed then, if there are unrelated AIX or HPUX libjava testsuite failures, please file separate bugs for them. After rebuilding jc1 and rerunning the libjava testsuite on alpha-dec-osf5.1b, I'm back at the same set of testsuite failures that I had on 20080313. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #37 from ro at techfak dot uni-bielefeld dot de 2008-11-05 15:07 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected aph at redhat dot com writes: Feel free to CC me with any of these. Thanks. A considerable number of them was already reported as PR target/4. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #10 from ro at techfak dot uni-bielefeld dot de 2008-10-31 13:27 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX Since native reghunting was so slow, I've finally switched to trying with a cross compiler (from Solaris 10/x86), and could reproduce the problem. It even turned out that there are two separate breakages involved. The first is caused by this change: 2008-04-01 Jan Hubicka [EMAIL PROTECTED] * function.c (free_after_compilation): Free epilogue_delay_list. (prepare_function_start): Assert that previous compilation was freed. Since that change, the first gcc_assert() in prepare_function_start() triggers: Breakpoint 1, fancy_abort (file=0x8919114 /vol/gcc/src/gcc-reghunt/gcc/function.c, line=3940, function=0x89196cc prepare_function_start) at /vol/gcc/src/gcc-reghunt/gcc/diagnostic.c:654 (gdb) where #0 fancy_abort (file=0x8919114 /vol/gcc/src/gcc-reghunt/gcc/function.c, line=3940, function=0x89196cc prepare_function_start) at /vol/gcc/src/gcc-reghunt/gcc/diagnostic.c:654 #1 0x08424619 in prepare_function_start () at /vol/gcc/src/gcc-reghunt/gcc/function.c:3940 #2 0x08424746 in init_function_start (subr=0xfee57620) at /vol/gcc/src/gcc-reghunt/gcc/function.c:3988 #3 0x085c711e in tree_rest_of_compilation (fndecl=0xfee57620) at /vol/gcc/src/gcc-reghunt/gcc/tree-optimize.c:408 #4 0x08783ec9 in cgraph_expand_function (node=0xfedbef3c) at /vol/gcc/src/gcc-reghunt/gcc/cgraphunit.c:1157 #5 0x0878573a in cgraph_optimize () at /vol/gcc/src/gcc-reghunt/gcc/cgraphunit.c:1220 #6 0x0816255f in cp_write_global_declarations () at /vol/gcc/src/gcc-reghunt/gcc/cp/decl2.c:3471 #7 0x0855617e in compile_file () at /vol/gcc/src/gcc-reghunt/gcc/toplev.c:971 #8 0x08557b7c in do_compile () at /vol/gcc/src/gcc-reghunt/gcc/toplev.c:2161 #9 0x08557be2 in toplev_main (argc=2, argv=0x80476f8) at /vol/gcc/src/gcc-reghunt/gcc/toplev.c:2193 #10 0x0828565f in main (argc=2, argv=0x80476f8) at /vol/gcc/src/gcc-reghunt/gcc/main.c:35 Later, the following change 2008-04-03 Jan Hubicka [EMAIL PROTECTED] PR tree-optimization/35795 * alpha/alpha.c (alpha_output_mi_thunk_osf): Free after compilation. * sparc/sparc.c (sparc_output_mi_thunk): Likewise. * ia64/ia64.c (ia64_output_mi_thunk): Likewise. * m68k/m68k.c (m68k_output_mi_thunk): Likewise. * score/score3.c (score3_output_mi_thunk): Likewise. * score/score7.c (score7_output_mi_thunk): Likewise. * mips/mips.c (mips_output_mi_thunk): Likewise. broke it even more and introduced the SEGV described in the original PR. If I disable the gcc_assert() and remove the free_after_compilation() at the end of alpha_output_mi_thunk_osf(), I'm finally able to compile my minimized testcase and bootstrap mainline on alpha-dec-osf5.1b. Since your two changes introduced this breakage and it is easily reproducible in a cross compiler, could you please investigate and fix this? Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug testsuite/37703] Ada testsuites lack multilib support
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-10-31
01:24 ---
Subject: Ada testsuites lack multilib support
While testing the fix for PR ada/37681, I tried to test both multilibs
(default and amd64) on i386-pc-solaris2.10, and found that I had to make
the following changes:
* For ada/acats, the necessary changes are restricted to the run_acats
script:
--- run_acats.save Wed May 30 17:59:57 2007
+++ run_acats Thu Oct 9 17:55:35 2008
@@ -13,7 +13,7 @@
BASE=`cd $ROOT/../../..; ${PWDCMD-pwd}`
PATH=$BASE:$ROOT:$PATH
-ADA_INCLUDE_PATH=$BASE/ada/rts
+ADA_INCLUDE_PATH=$BASE/ada/rts_sparcv9
LD_LIBRARY_PATH=$ADA_INCLUDE_PATH:$BASE:$LD_LIBRARY_PATH
ADA_OBJECTS_PATH=$ADA_INCLUDE_PATH
@@ -33,7 +33,7 @@
fi
GCC_DRIVER=$BASE/xgcc
-GCC=$BASE/xgcc -B$BASE/
+GCC=$BASE/xgcc -B$BASE/ -m64
export PATH ADA_INCLUDE_PATH ADA_OBJECTS_PATH GCC_DRIVER GCC LD_LIBRARY_PATH
echo '#!/bin/sh' host_gnatchop
To properly handle this, the script needs to iterate over the available
multilibs and append _multilib dir to $ADA_INCLUDE_PATH and the
multilib flag to $GCC.
One problem here is that unlike the dejagnu based testsuite, where the
user can influence the multilibs to test via the RUNTESTFLAGS environment
variable, it seems to be unnecessarily complex to parse that
dejagnu-specific variable (which might look like
--target_board unix{,-m64}
in the present case), so instead the default should be to iterate over
all available multilibs.
* For gnat, the situation is similar with one twist:
--- gnat.exp.save Mon Sep 3 18:05:02 2007
+++ gnat.expThu Oct 9 17:54:58 2008
@@ -127,10 +127,10 @@
global ld_library_path
global gnat_libgcc_s_path
-setenv ADA_INCLUDE_PATH ${rootme}/ada/rts
+setenv ADA_INCLUDE_PATH ${rootme}/ada/rts_amd64
set ld_library_path .:${gnat_libgcc_s_path}
lappend options compiler=$GNAT_UNDER_TEST -q -f
-lappend options incdir=${rootme}/ada/rts
+lappend options incdir=${rootme}/ada/rts_amd64
if { [target_info needs_status_wrapper]!= [info exists gluefile] } {
lappend options libs=${gluefile}
@@ -244,7 +244,7 @@
}
if { $file != } {
set root [file dirname $file]
- set CC $file -I$root/ada/rts --GCC=$root/xgcc
--GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs
--GCC=$root/xgcc -B$root -margs;
+ set CC $file -I$root/ada/rts_amd64 --GCC=$root/xgcc
--GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs
--GCC=$root/xgcc -B$root -m64 -margs;
} else {
set CC [transform gnatmake]
}
Again, one needs to add _multilib dir to ADA_INCLUDE_PATH and friends.
The multilib flag is already appended to $CC by the dejagnu framework,
but one issue remains: unlike gnatmake, gnatlink doesn't pass unknown
flags (like -m64 in this case) to gcc, but ignores them. If invoking
gnatlink via the shell, it is possible to use
-largs --GCC=$root/xgcc -B$root -m64
and pass -B and -m64 through gnatlink. With the dejagnu/tcl framework,
I've found no way to achieve the same effect, i.e. to pass a single
argument which includes whitespace. Maybe some testsuite expert can help
here?
If this were not done, compilations performed by gnatlink `behind the
scenes' would produce objects for the default multilib, leading to link
failures in the final link step.
As a workaround, I've replaced xgcc by a script that always passes -m64:
#!/bin/sh
exec $0.bin -m64 $@
With those changes, I could at least manually test both multilibs on
sparc-sun-solaris2.11 and i386-pc-solaris2.10.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37703
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #29 from ro at techfak dot uni-bielefeld dot de 2008-10-10 14:41 --- Subject: Re: [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 I've just formally submitted my patch http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00441.html with some suggestions how a complete fix would look like if necessary. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug tree-optimization/33703] ../../gcc/libcpp/directives.c:1878: internal compiler error: Segmentation fault
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2008-10-10
15:11 ---
Subject: Ada testsuites lack multilib support
While testing the fix for PR ada/37681, I tried to test both multilibs
(default and amd64) on i386-pc-solaris2.10, and found that I had to make
the following changes:
* For ada/acats, the necessary changes are restricted to the run_acats
script:
--- run_acats.save Wed May 30 17:59:57 2007
+++ run_acats Thu Oct 9 17:55:35 2008
@@ -13,7 +13,7 @@
BASE=`cd $ROOT/../../..; ${PWDCMD-pwd}`
PATH=$BASE:$ROOT:$PATH
-ADA_INCLUDE_PATH=$BASE/ada/rts
+ADA_INCLUDE_PATH=$BASE/ada/rts_sparcv9
LD_LIBRARY_PATH=$ADA_INCLUDE_PATH:$BASE:$LD_LIBRARY_PATH
ADA_OBJECTS_PATH=$ADA_INCLUDE_PATH
@@ -33,7 +33,7 @@
fi
GCC_DRIVER=$BASE/xgcc
-GCC=$BASE/xgcc -B$BASE/
+GCC=$BASE/xgcc -B$BASE/ -m64
export PATH ADA_INCLUDE_PATH ADA_OBJECTS_PATH GCC_DRIVER GCC LD_LIBRARY_PATH
echo '#!/bin/sh' host_gnatchop
To properly handle this, the script needs to iterate over the available
multilibs and append _multilib dir to $ADA_INCLUDE_PATH and the
multilib flag to $GCC.
One problem here is that unlike the dejagnu based testsuite, where the
user can influence the multilibs to test via the RUNTESTFLAGS environment
variable, it seems to be unnecessarily complex to parse that
dejagnu-specific variable (which might look like
--target_board unix{,-m64}
in the present case), so instead the default should be to iterate over
all available multilibs.
* For gnat, the situation is similar with one twist:
--- gnat.exp.save Mon Sep 3 18:05:02 2007
+++ gnat.expThu Oct 9 17:54:58 2008
@@ -127,10 +127,10 @@
global ld_library_path
global gnat_libgcc_s_path
-setenv ADA_INCLUDE_PATH ${rootme}/ada/rts
+setenv ADA_INCLUDE_PATH ${rootme}/ada/rts_amd64
set ld_library_path .:${gnat_libgcc_s_path}
lappend options compiler=$GNAT_UNDER_TEST -q -f
-lappend options incdir=${rootme}/ada/rts
+lappend options incdir=${rootme}/ada/rts_amd64
if { [target_info needs_status_wrapper]!= [info exists gluefile] } {
lappend options libs=${gluefile}
@@ -244,7 +244,7 @@
}
if { $file != } {
set root [file dirname $file]
- set CC $file -I$root/ada/rts --GCC=$root/xgcc
--GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs
--GCC=$root/xgcc -B$root -margs;
+ set CC $file -I$root/ada/rts_amd64 --GCC=$root/xgcc
--GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs
--GCC=$root/xgcc -B$root -m64 -margs;
} else {
set CC [transform gnatmake]
}
Again, one needs to add _multilib dir to ADA_INCLUDE_PATH and friends.
The multilib flag is already appended to $CC by the dejagnu framework,
but one issue remains: unlike gnatmake, gnatlink doesn't pass unknown
flags (like -m64 in this case) to gcc, but ignores them. If invoking
gnatlink via the shell, it is possible to use
-largs --GCC=$root/xgcc -B$root -m64
and pass -B and -m64 through gnatlink. With the dejagnu/tcl framework,
I've found no way to achieve the same effect, i.e. to pass a single
argument which includes whitespace. Maybe some testsuite expert can help
here?
If this were not done, compilations performed by gnatlink `behind the
scenes' would produce objects for the default multilib, leading to link
failures in the final link step.
As a workaround, I've replaced xgcc by a script that always passes -m64:
#!/bin/sh
exec $0.bin -m64 $@
With those changes, I could at least manually test both multilibs on
sparc-sun-solaris2.11 and i386-pc-solaris2.10.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33703
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #21 from ro at techfak dot uni-bielefeld dot de 2008-10-08
17:20 ---
Subject: Re: [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad
cie version 0: offset 0x0
FTR: I've long been using this patch as a workaround until the neccessary
Sun ld patch is available:
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 140759)
+++ gcc/config.gcc (working copy)
@@ -1205,7 +1205,10 @@ i[34567]86-*-solaris2*)
*-*-solaris2.1[0-9]*)
tm_file=${tm_file} i386/x86-64.h i386/sol2-10.h
tm_defines=${tm_defines} TARGET_BI_ARCH=1
- tmake_file=$tmake_file i386/t-crtstuff i386/t-sol2-10
+ tmake_file=$tmake_file i386/t-sol2-10
+ if test x$gnu_ld = xyes; then
+ tmake_file=$tmake_file i386/t-crtstuff
+ fi
need_64bit_hwint=yes
case X${with_cpu} in
Xgeneric|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-10-07 16:04 --- Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail ebotcazou at gcc dot gnu dot org writes: I think that we should assemble some C code with CFI directives and see whether the resulting .eh_frame is read-only; if so, HAVE_GAS_CFI_DIRECTIVE must be set to 0 instead of 1. This should discriminate between 2.18 and upcoming 2.19. That's what I did in my patch at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00249.html I could just take the current test code for gcc_cv_as_cfi_directive as is and inspect the object file with objdump on Solaris. Using C code directly with gcc -fexceptions -fdwarf2-cfi-asm didn't work since it relies upon the bootstrap compiler being gcc and sufficiently recent to support -fdwarf2-cfi-asm, leading to comparions failures upon a mismatch. That the non-C compilers still emit .eh_frame directly is unexpected I'd think. I think I'll raise a separate PR for that and add rth to the Cc:. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error
--- Comment #9 from ro at techfak dot uni-bielefeld dot de 2008-10-01 17:17 --- Subject: Re: [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error bonzini at gnu dot org writes: No, there is not yet an extra configure switch for that, but I'll add it. You can create a PR and assign it to me. Done: PR bootstrap/37704. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2008-09-30 15:06 --- Subject: Re: [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error ebotcazou at gcc dot gnu dot org writes: Yes, it is, the hitch being that there is no port to x86_64/Solaris yet. I'm just testing the (almost) obvious patch to fix this. At least the amd64 libgnat-4.4.so builds now. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2008-09-30 18:09 --- Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail I've done some further debugging: contrary to what gdb suggested, the reason for the abort is the gcc_assert call in unwind-dw2.c (uw_init_context_1): code = uw_frame_state_for (context, fs); gcc_assert (code == _URC_NO_REASON); Single-stepping at the assembler level, I find that code is _URC_END_OF_STACK, i.e. _Unwind_Find_FDE () in uw_frame_state_for () returned NULL. Since this code is such a maze, I'm hard pressed to further debug this, so any guidance is appreciated. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2008-09-30 19:22 --- Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail ebotcazou at gcc dot gnu dot org writes: See http://sourceware.org/ml/binutils/2008-09/msg00195.html Thanks for the info. Now someone needs to write a configure test for the compiler. I'm a bit unsure how to test this right now: what I find is that C objects have read-only .eh_frame sections and use .cfi* directives, while C++, Java and Ada objects have read-write .eh_frame sections and still use .eh_frame sections directly emitted by the compiler. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2008-09-30 21:37 --- Subject: Re: [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01990.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-09-16 15:02 --- Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail jakub at gcc dot gnu dot org writes: gas 2.15 is helplessly outdated and buggy. Can you retry with -fno-dwarf2-cfi-asm ? Unfortunately, passing in BOOT_CFLAGS='-g -O2 -fno-dwarf2-cfi-asm' didn't help (the value wasn't picked up from the environment). Even if I manually set BOOT_CFLAGS like that in the toplevel Makefile, it isn't passed down to the libgcc and libstdc++-v3 builds, and manually compiling an individual testcase with -fno-... isn't enough. If I add -fno-... to i386-pc-solaris2.10/libgcc/Makefile, rebuild libgcc and a testcase with -fno-..., the test passes. On the other hand, I tried bootstrapping with the current binutils 2.18 release, which makes no difference, so this doesn't seem to be a gas problem. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug bootstrap/37441] [4.4 regression] dwarf2 unwind info patches produce undefined symbols
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2008-09-12 18:47 --- Subject: Re: [4.4 regression] dwarf2 unwind info patches produce undefined symbols Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00978.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37441
[Bug bootstrap/37441] [4.4 regression] dwarf2 unwind info patches produce undefined symbols
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2008-09-11 11:23 --- Subject: Re: [4.4 regression] dwarf2 unwind info patches produce undefined symbols jakub at gcc dot gnu dot org writes: references undefined label. I'm afraid at least until some support is added to gas to handle that, we should: #ifdef MIPS_DEBUGGING_INFO return false; #endif early in dwarf2out_do_cfi_asm. Wonder why alpha defines MIPS_DEBUGGING_INFO too and if e.g. alpha-linux needs to emit DW_AT_MIPS_fde attributes. The following patch Index: gcc/dwarf2out.c === --- gcc/dwarf2out.c (revision 140226) +++ gcc/dwarf2out.c (working copy) @@ -139,6 +139,9 @@ dwarf2out_do_cfi_asm (void) if (!flag_dwarf2_cfi_asm || !dwarf2out_do_frame ()) return false; +#ifdef MIPS_DEBUGGING_INFO + return false; +#endif if (!eh_personality_libfunc) return true; if (!HAVE_GAS_CFI_PERSONALITY_DIRECTIVE) allowed for the bootstrap to complete. The testsuite is still running; when it's done, I'll submit it to gcc-patches. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37441
[Bug bootstrap/37426] [4.4 regression] IRA merge breaks Tru64 UNIX bootstrap
--- Comment #1 from ro at techfak dot uni-bielefeld dot de 2008-09-09 15:43 --- Subject: Re: [4.4 regression] IRA merge breaks Tru64 UNIX bootstrap After applying the patch for PR rtl-optimization/37333 from http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00514.html and applying http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00705.html I'm now past stage3 and into building the target libs. So it seems that this PR can be closed once the patch is checked in. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37426
[Bug bootstrap/37422] [4.4 regression] IRA merge breaks Solaris/x86 bootstrap
--- Comment #1 from ro at techfak dot uni-bielefeld dot de 2008-09-09 16:22 --- Subject: Re: [4.4 regression] IRA merge breaks Solaris/x86 bootstrap Configuring for i686-pc-solaris2.10 instead of the default of i386-pc-solaris2.10 allows a C-only bootstrap to complete. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37422
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-09-09 16:45 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX jh at suse dot cz writes: Looks like Aplha is not tuplified yet? ../../gcc/config/alpha/alpha.c: In function 'va_list_skip_additions': ../../gcc/config/alpha/alpha.c:5815: warning: assignment from incompatible pointer type ../../gcc/config/alpha/alpha.c:5817: error: 'PHI_NODE' undeclared (first use in this function) ../../gcc/config/alpha/alpha.c:5817: error: (Each undeclared identifier is reported only once ../../gcc/config/alpha/alpha.c:5817: error: for each function it appears in.) With the two patches mentioned in Comment #1 of PR bootstrap/37426 (the second of which I've just checked in), an alpha-dec-osf5.1b bootstrap is currently building the runtime libs. As expected, it just failed again building strstream.o. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2008-08-01 16:24 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX rguenth at gcc dot gnu dot org writes: If you provide a preprocessed testcase maybe he can. Otherwise patches welcome I guess. Done. Unfortunately, I won't be available for testing until September 1st. If this cannot be resolved, I'll certainly need quite some guidance to fix it myself. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug target/32325] [4.3 Regression] cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B: SEGV in rtl_verify_flow_info
--- Comment #1 from ro at techfak dot uni-bielefeld dot de 2007-09-20 14:17 --- Subject: Re: [4.3 Regression] cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B: SEGV in rtl_verify_flow_info A reghunt revealed that this was caused by the following patch: 2007-03-02 Eric Botcazou [EMAIL PROTECTED] * config/alpha/alpha.c (alpha_gp_save_rtx): Insert the insns at the entry by means of emit_insn_at_entry. Since alpha_gp_save_rtx is only used with TARGET_LD_BUGGY_LDGP, which is only defined in osf5.h, alpha-dec-osf5.1b is affected while alpha-dec-osf4.0f is not. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32325
[Bug bootstrap/33100] [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #10 from ro at techfak dot uni-bielefeld dot de 2007-09-11 12:48 --- Subject: Re: [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 hjl at lucon dot org writes: Binutils 2.15 is very old. Can you try binutils 2.18? It doesn't make a difference: although the object files are not completely identical, the problematic .eh_frame section stays the same. I've uploaded the output with -save-temps before and after adding -fno-asynchronous-unwind-tables. The after version contains the empty .eh_frame section with cie version 0 which causes ld to complain. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug bootstrap/33100] [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2007-09-10 14:41 --- Subject: Re: [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 hjl at lucon dot org writes: It could be caused by bugs in assembler/linker on Solaris. The assembler in question is gas 2.15, and the linker check seems to be completely deliberate. The error is issued by libld, whose source can be browsed at opensolaris.org: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sgs/libld/common/unwind.amd.c around line 396. The old crtend.o had CIE version 1 as expected, the new one has version 0. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug bootstrap/33100] [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2007-09-06 13:25 --- Subject: Re: [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 brett dot albertson at stratech dot com writes: Something changed and it is now working for me, but this did exist on mainline for at least some period of time. Rainer, are you still seeing this behavior? I haven't tried a newer tree ( 20070903) yet. A difference might be that Art uses GNU ld (he doesn't state so, though) while Brett and I use Sun ld. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug bootstrap/33306] [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2007-09-05 14:54 --- Subject: Re: [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369 belyshev at depni dot sinp dot msu dot ru writes: Not specific to tru64 and can be reproduced with an alpha-unknown-linux-gnu cross compiler with --with-long-double-128. Worked at least with r127312. makes sense: that's the primary difference between alpha-dec-osf4.0f (which works) and alpha-dec-osf5.1b (which does not). I'm currently running a reghunt to identify the culprit patch. (small nitpick: please don't set or change bug's priority field: it is RM's prerogative) It is set by the gccbug which I use to submit PRs. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug bootstrap/33306] [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2007-09-05 18:09 --- Subject: Re: [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369 A reghunt revealed that this patch 2007-08-31 Richard Sandiford [EMAIL PROTECTED] * optabs.c (shift_optab_p, commutative_optab_p): New functions, split out from expand_binop. (avoid_expensive_constant): New function. (expand_binop_directly): Remove commutative_op argument and call cummutative_optab_p instead. Do not change op0 or op1 when swapping xop0 and xop1. Apply avoid_expensive_constant to each argument after potential swapping. Enforce the canonical order of commutative operands. (expand_binop): Use shift_optab_p and commutative_optab_p. Update the calls to expand_binop_directly. Only force constants into registers when widening an operation. Only swap operands once a direct expansion has been rejected. (expand_twoval_binop): Only force constants into registers when using a direct expansion. is the culprit. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2007-07-17 11:28 --- Subject: Re: [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes belyshev at depni dot sinp dot msu dot ru writes: You need the following patch to fix this bug (but bootstrap on alpha is still broken for other reasons, see bug 32747): Thanks. A C-only bootstrap (alpha-dec-osf5.1b and alpha-dec-osf4.0f) completes with this patch, but if I build with all languages, cc1 segfaults in malloc building the stage 2 libdecnumber: $ source='/vol/gcc/src/gcc-dist/libdecnumber/decNumber.c' object='decNumber.o' libtool=no /vol/gccsrc/obj/gcc-4.3.0-20070712/4.0f-gcc/./prev-gcc/xgcc -B/vol/gccsrc/obj/gcc-4.3.0-20070712/4.0f-gcc/./prev-gcc/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -I/vol/gcc/src/gcc-dist/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long -Werror -I/vol/gcc/src/gcc-dist/libdecnumber -I. -c /vol/gcc/src/gcc-dist/libdecnumber/decNumber.c /vol/gcc/src/gcc-dist/libdecnumber/decNumber.c: In function 'decNumberPower': /vol/gcc/src/gcc-dist/libdecnumber/decNumber.c:1242: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I cannot get a proper stack trace, though. The file compiles at -O. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #10 from ro at techfak dot uni-bielefeld dot de 2007-07-12
14:15 ---
Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
aph at gcc dot gnu dot org writes:
--- Comment #9 from aph at gcc dot gnu dot org 2007-07-12 10:49 ---
This is somewhat bewildering: if the visibility attribute is not supported,
who
does setting the visibility make any difference to the build?
I have no idea (and haven't really checked).
Nonetheless, I have no objection to something like
static void
hide (tree decl)
{
#ifdef __linux__
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
DECL_VISIBILITY_SPECIFIED (decl) = 1;
#endif
}
or whatever macro seems appropriate to you, in order to restrict this to
GNU/Linux systems.
I think the following variant should be ok. I added it to the previously
failing revision (with only c, c++, and java), and now both 32 and 64 bit
libgcj.so build.
2007-07-12 Andrew Haley [EMAIL PROTECTED]
Rainer Orth [EMAIL PROTECTED]
PR target/32462
PR libgcj/32465
* class.c (hide): Wrap in HAVE_GAS_HIDDEN.
diff -r e4a0b686f36f gcc/java/class.c
--- a/gcc/java/class.c Tue Apr 03 15:28:16 2007 +
+++ b/gcc/java/class.c Thu Jul 12 15:04:11 2007 +0200
@@ -691,10 +691,12 @@ build_java_method_type (tree fntype, tre
}
static void
-hide (tree decl)
-{
+hide (tree decl ATTRIBUTE_UNUSED)
+{
+#ifdef HAVE_GAS_HIDDEN
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
DECL_VISIBILITY_SPECIFIED (decl) = 1;
+#endif
}
tree
Is this enough for checkin or should I run a full mainline bootstrap? At
least it fixes two bootstrap failures.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #14 from ro at techfak dot uni-bielefeld dot de 2007-07-12 17:16 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 pinskia at gmail dot com writes: This is way too conservative, see PR 26989 for the reasons why? But how do you propose to handle this? In Comment #4 of this PR, you state that there's currently no way to check this. AFAICT, the only platform not handled by HAVE_GAS_HIDDEN is darwin, which I don't have access to. At worst, I could add #if defined(HAVE_GAS_HIDDEN) || (defined(__MACH__) defined(__APPLE__)) Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #16 from ro at techfak dot uni-bielefeld dot de 2007-07-12 17:30 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 aph at gcc dot gnu dot org writes: #ifdef HAVE_GAS_HIDDEN is fine. There is no real bad consequence to not hiding those symbols; it's just that the DSO exports a lot of unnecessary junk. Ok, thanks. The full bootstrap (all languages) is in progress, but the previous ones already confirmed that libgcj.so links which it didn't before. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug bootstrap/32744] [4.3 regression] ICE in build2_stat, at tree.c:3077 bootstrapping on Tru64 UNIX
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2007-07-12 21:18 --- Subject: Re: [4.3 regression] ICE in build2_stat, at tree.c:3077 bootstrapping on Tru64 UNIX pinskia at gcc dot gnu dot org writes: Almost a month after the patch broke alpha bootstrap, I guess that means nobody cares that much. Not really: it's rather too many platforms and too much breakage for me to handle ;-) Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32744
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2007-07-09 17:48 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 aph at gcc dot gnu dot org writes: So, the question is why the linker is complaining that a GOT relative relocation must reference a local symbol since it is defined locally and it should be possible to calculate its offset from the GOT. I've looked up the message in the OpenSolaris ld sources: they are from http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sgs/libld/common/relocate.c (ld_process_sym_reloc), l. 1187 - 1198 (the message is MSG_REL_BADGOTBASED). On l. 1116.. there's a description of which symbols are considered local. I must confess that I don't fully understand what is going on there ;-) Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug libstdc++/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2007-07-05 15:19 --- Subject: Re: libstdc++ testsuite fails on platforms without ranlib pcarlini at suse dot de writes: Let's add Hans-Peter in CC... I suspect adding an 'else if [info exists env(RANLIB)]...' could do the job... Hans-Peter? Unfortunately, this won't do: on IRIX 5, we have RANLIB=:, which is a shell builtin. When I tried a make check with RANLIB_FOR_TARGET=:, this failed with (I think) `command not found'. We'd have to make sure that RANLIB is set to e.g. true, i.e. an external command. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug libstdc++/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2007-07-05 15:42 --- Subject: Re: libstdc++ testsuite fails on platforms without ranlib hp at gcc dot gnu dot org writes: I'm not the one adding the ranlib invocation, just the one last touching it, Indeed: I found that Benjamin first introduced libtestc++.a and the ranlib invokation. see for example also PR30675. Don't check for RANLIB, it's for the host and we're testing for the target. I think this is wrong: the toplevel Makefile has, in BASE_TARGET_EXPORTS, RANLIB=$(RANLIB_FOR_TARGET), so it seems we should check for RANLIB instead of RANLIB_FOR_TARGET. The framework in this case the toplevel, is responsible for passing a RANLIB_FOR_TARGET. There's the bug, IMHO. The other problem is that the fallback of : for RANLIB_FOR_TARGET doesn't work with local_exec $ranlibcommand, while using true is ok. This should be fixed in the toplevel configure.ac (NCN_STRICT_CHECK_TOOLS, ACX_CHECK_INSTALLED_TARGET_TOOL). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug libstdc++/32499] libstdc++ testsuite fails on platforms without ranlib
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2007-07-05 17:31 --- Subject: Re: libstdc++ testsuite fails on platforms without ranlib hp at gcc dot gnu dot org writes: and you'll have to fix the : problem separately. Unless you prefer a 'set ranlib $env(SHELL) -c $env(RANLIB)' but that looks a little bit too gross. Indeed, setting RANLIB to true seems far simpler. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2007-07-03 17:57 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 I compared the assembler files corresponding to java/.libs/process-Posix.o and built with both gcj 4.2.1 20070611 and 4.3.0 20070618 and compared the results: the primary differences are like this: @@ -1886,9 +2012,8 @@ movl%eax, %esi movl%eax, (%esp) call[EMAIL PROTECTED] - movl[EMAIL PROTECTED](%ebx), %eax - movl%esi, (%eax) -.LBE57: + movl%esi, [EMAIL PROTECTED](%ebx) +.LBE60: movl4(%esp), %ebx movl8(%esp), %esi addl$12, %esp I've uploaded both files for further inspection. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug libgcj/32465] Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code despite -fPIC
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2007-06-25 17:38 --- Subject: Re: Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code despite -fPIC hjl at lucon dot org writes: --- Comment #2 from hjl at lucon dot org 2007-06-22 18:26 --- On Linux, I got 02e1b960 1 OBJECT LOCAL HIDDEN 25 gnu::gcj::runtime::FinalizerThread::finalizer_ready This is 221554: 03024d80 1 OBJECT GLOBAL DEFAULT 256 gnu::gcj::runtime::FinalizerThread::finalizer_ready on Solaris 10. It looks like assembler/linker on Solaris don't have proper visibility support. The assembler (gas 2.15 bundled with Solaris) does, but since I'm using the native linker, gcc/configure.ac disables hidden support. It should work in Solaris 10, though. Due to PR libgcj/32462 (which happens with GNU ld, too), I haven't tried gas and gld yet. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32465
[Bug tree-optimization/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
--- Comment #12 from ro at techfak dot uni-bielefeld dot de 2006-07-28 16:03 --- Subject: Re: [4.2 Regression] Ada bootstrap failure on Solaris 10/x86 rguenth at gcc dot gnu dot org writes: Is this now fixed on the mainline? A mainline bootstrap as of 20060724 was successful, so it seems so (although I haven't seen a specific fix addressing this issue). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #30 from ro at techfak dot uni-bielefeld dot de 2006-07-12 16:11 --- Subject: Re: GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked. multix at gmail dot com writes: I'm available for testing on my box. I Think I have access to a 6.5.4 box too... but am not sure. That would be fine, in case I get around to investigating this further. On many other platforms (like Tru64 UNIX), it used to be possible to fix or work around problems like this, provided the number of different cases/releases don't get out of hand. Before I start this, I'll probably have to invest some work to get mainline to fully bootstrap on 6.5.2x, though. SGI says that binaries compiled on different minor releases should be compatible each other, I wonder if a binary packager can safely build on = 6.5.18 and expect it to work on older boxes too or not... Certainly not: this only works the other way round: you can build on 6.5.x and run on 6.5.y, y x. There are new symbols introduced e.g. in libc, which are marked as OPTIONAL in nm output. It is possible (though I don't remember how this is done) to check for those functions as runtime and use them only if available. This is certainly far too much trouble in the GCC case, though. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #21 from ro at techfak dot uni-bielefeld dot de 2006-07-11 18:04 --- Subject: Re: GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked. martinol at nrlssc dot navy dot mil writes: this machine is: 6.5 6.5.17m This most likely explains the difference: this is before C99 support was introduced, and obviously most testers use relatively recent IRIX releases. I don't have an pre-6.5.18 machine myself, so the only chance is probably to run the failing tests through gcc -g3 -save-temps and find out why exactly they fail. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug bootstrap/28324] boostrapping with gcc fails with unrecognized linker option
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2006-07-11 18:50 --- Subject: Re: New: boostrapping with gcc fails with unrecognized linker option multix at gmail dot com [EMAIL PROTECTED] writes: I boostrapped using gcc 3.3 from sgi, usning as configure option ../gcc-4.1.1/configure --with-as=/usr/local/bin/as --enable-languages=c,c++,objc and as make command gmake CFLAGS='-O' LIBCFLAGS='-O2' LIBCXXFLAGS='-O2 -fno-implicit-templates' bootstrap bootstrapping fails with: [...] /usr/local/mips-sgi-irix6.5/bin/ld: unrecognized option '-_SYSTYPE_SVR4' /usr/local/mips-sgi-irix6.5/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status The problem is that you are have GNU ld installed in a place gcc searches by default, but didn't configure with --with-gnu-ld. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28324
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #23 from ro at techfak dot uni-bielefeld dot de 2006-07-11 20:06 --- Subject: Re: GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked. ebotcazou at gcc dot gnu dot org writes: Mine is 6.5 6.5.26m. I'm running 6.5 6.5.28f. Anything newer than 6.5.18 (or .19, I don't really remember) shouldn't exhibit this failure. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug libstdc++/28290] [4.2 Regression] error: 'iconv_t' does not name a type
--- Comment #14 from ro at techfak dot uni-bielefeld dot de 2006-07-10 20:17 --- Subject: Re: [4.2 Regression] error: 'iconv_t' does not name a type pcarlini at suse dot de writes: It seemd to me that the best thing to do is adding the include on top of codecvt_specializations.h itself and removing it from the other places where it does currently appear (because a grep reveals that the iconv facilities are *not* used anywhere else (besides the testsuite), I would appreciate of you could double check...). Can you try that? The compilation errors are gone with this change, but due to PR c++/28217, I still get an ICE: Index: codecvt_specializations.h === --- codecvt_specializations.h (revision 115313) +++ codecvt_specializations.h (working copy) @@ -38,6 +38,10 @@ * This file is a GNU extension to the Standard C++ Library. */ +#if _GLIBCXX_USE_ICONV +# include iconv.h +#endif + // XXX // Define this here so codecvt.cc can have _S_max_size definition. #define _GLIBCXX_USE_ENCODING_STATE 1 Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libgomp/28296] [4.2 Regression] libgomp fails to configure on Tru64 UNIX
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2006-07-10 20:27 --- Subject: Re: libgomp fails to configure on Tru64 UNIX echristo at apple dot com writes: Well, it shouldn't have mattered, but try re-adding the CFLAGS line that I think I accidentally deleted just after XPCFLAGS: CFLAGS=$CFLAGS -pthread which is also just plain wrong, but perhaps this too should be moved inside the case block. Restoring this in the original place works (at least make configure-target-libgomp completes successfully). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2006-07-06 20:10 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B Even if I add iconv.h directly to extc++.h (a complete hack), the compilation errors about iconv_t missing are gone, but the ICE remains, even at -O0. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2006-07-06 20:19 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B falk at debian dot org writes: Can you give the .ii for that? Sure, done. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2006-07-06 22:04 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B The same ICE happens on Solaris 10/x86 (i386-pc-solaris2.10). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug bootstrap/26066] disable-threads causes undefined reference to pthread_kill and pthread_sigmask
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2006-06-30 18:03 --- Subject: Re: disable-threads causes undefined reference to pthread_kill and pthread_sigmask I've noticed the same problem on IRIX 6.5 (which still uses THREADS=single), cf. PR libgcj/21935. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26066
