ml
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #3 from falk at debian dot org 2006-03-31 08:40 ---
Confirmed, also present in 4.2.0 20060218
Test case:
struct LongDouble {
char ld[16];
};
struct DynAny {
virtual void insert_longdouble(LongDouble value) = 0;
};
struct TAO_DynCommon : public virtual DynAny {
virtual void insert_longdouble (LongDouble value);
};
void TAO_DynCommon::insert_longdouble (LongDouble value) { }
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail|4.0.3 4.1.0 |4.0.3 4.1.0 4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #39 from ebotcazou at gcc dot gnu dot org 2006-03-31 09:53 --- > I've also been poking at MPFR. There are apparently 10 or more patches now > for > 2.2.0, that may resolve the issues, too. I'll look at that. I've rebuilt it, > and ran the "check" area for mpfr, and 115/117 tests fail. I cannot reproduce that: MPFR 2.2.0 is clean (117/117 tests OK ) if configured with './configure --build=sparc-sun-solaris2.8 --with-gmp=/opt/build/eric/local' against GMP 4.1.3 and built by GCC 4.0.2 with 'gmake' on the Solaris 8 box. GMP 4.1.3 was configured with './configure --build=sparc-sun-solaris2.8' and built by GCC 4.0.2 with 'gmake'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug c++/26959] New: GCC 4.1.0 Won't build on Mingw. Complainst about no % in format
Won't build on Mingw. You are probably aware of it. I started the build with GCC 4.0.2 on Mingw. [EMAIL PROTECTED] /mingw/gcc-4.1.0 $ make make[1]: Entering directory `/mingw/gcc-4.1.0' make[2]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/zlib' true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2 " "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2 " "CFLAGS_FOR_TARGET=-O2 -g -O2 " "INSTALL=/bin/install -c" "INSTALL_DATA=/bin/install -c -m 644" "INSTALL_PROGRAM=/bin/install -c" "INSTALL_SCRIPT=/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2 " "LIBCFLAGS_FOR_TARGET=-O2 -g -O2 " "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/info" "libdir=/usr/local/lib" "prefix=/usr/local" "tooldir=/usr/local/i686-pc-mingw32" "AR=ar" "AS=as" "CC=gcc" "CXX=c++" "LD=u:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.0.2/../../../../i686-pc-mingw32/bin/ld.exe" "LIBCFLAGS=-g -O2 " "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make make[2]: Leaving directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/zlib' make[2]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/libiberty' make[3]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/libiberty/testsuite' make[2]: Leaving directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/libiberty' make[2]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/fastjar' make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2 " "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2 " "CFLAGS_FOR_TARGET=-O2 -g -O2 " "INSTALL=/bin/install -c" "INSTALL_DATA=/bin/install -c -m 644" "INSTALL_PROGRAM=/bin/install -c" "INSTALL_SCRIPT=/bin/install -c" "JC1FLAGS=" "LDFLAGS=" "LIBCFLAGS=-g -O2 " "LIBCFLAGS_FOR_TARGET=-O2 -g -O2 " "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "exec_prefix=/usr/local" "infodir=/usr/local/info" "libdir=/usr/local/lib" "prefix=/usr/local" "AR=ar" "AS=as" "CC=gcc" "CXX=c++" "LD=u:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.0.2/../../../../i686-pc-mingw32/bin/ld.exe" "LIBCFLAGS=-g -O2 " "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" all-am make[3]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/fastjar' make[3]: Leaving directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/fastjar' make[2]: Leaving directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/fastjar' make[2]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/fixincludes' make[2]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/intl' rm -f stamp-h1 /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[2]: Leaving directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/intl' make[2]: Entering directory `/mingw/gcc-4.1.0/build-i686-pc-mingw32/libiberty' make[3]: Entering directory `/mingw/gcc-4.1.0/build-i686-pc-mingw32/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/mingw/gcc-4.1.0/build-i686-pc-mingw32/libiberty/testsuite' make[2]: Leaving directory `/mingw/gcc-4.1.0/build-i686-pc-mingw32/libiberty' make[2]: Entering directory `/mingw/gcc-4.1.0/build-i686-pc-mingw32/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/mingw/gcc-4.1.0/build-i686-pc-mingw32/fixincludes' make[2]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[2]: Leaving directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/libcpp' make[2]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/gcc' Makefile:1277: *** target pattern contains no `%'. Stop. make[2]: Leaving directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/mingw/gcc-4.1.0' make: *** [all] Error 2 [EMAIL PROTECTED] /mingw/gcc-4.1.0 -- Summary: GCC 4.1.0 Won't build on Mingw. Complainst about no % in format Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcorbit at connx dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26959
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #40 from ebotcazou at gcc dot gnu dot org 2006-03-31 10:54 --- This is the build with GMP 4.1.3 and MPFR 2.2.0: gax% gcc/xgcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: /home/eric/svn/gcc-4_0-branch/configure --prefix=/opt/build/eric/local/gcc-4_0-branch --with-gmp=/opt/build/eric/local2 --with-mpfr=/opt/build/eric/local2 --with-local-prefix=/opt/build/eric/local2 --enable-languages=c,f95 Thread model: posix gcc version 4.0.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug fortran/24993] LAPACK builds but dies in the testsuite
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-03-31 11:24 --- Could you retry this with gfortran 4.1 (now that it is out) ? Thanks. -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24993
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #6 from aph at gcc dot gnu dot org 2006-03-31 11:43 --- Subject: Bug 26858 Author: aph Date: Fri Mar 31 11:43:43 2006 New Revision: 112574 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112574 Log: 2006-03-30 Andrew Haley <[EMAIL PROTECTED]> PR java/26858 * lang.c (java_attribute_table): New. (LANG_HOOKS_ATTRIBUTE_TABLE): Define. * expr.c (build_field_ref): Add a null pointer check for all fields of offset > 4k. Don't do so for accesses via the this pointer, which we know can never be null. * class.c (build_java_method_type): Mark arg 1 of all nonstatic methods nonnull. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/class.c trunk/gcc/java/expr.c trunk/gcc/java/lang.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #7 from aph at gcc dot gnu dot org 2006-03-31 13:05 --- Subject: Bug 26858 Author: aph Date: Fri Mar 31 13:05:32 2006 New Revision: 112575 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112575 Log: 2006-03-30 Andrew Haley <[EMAIL PROTECTED]> PR java/26858 * lang.c (java_attribute_table): New. (LANG_HOOKS_ATTRIBUTE_TABLE): Define. * expr.c (build_field_ref): Add a null pointer check for all fields of offset > 4k. Don't do so for accesses via the this pointer, which we know can never be null. * class.c (build_java_method_type): Mark arg 1 of all nonstatic methods nonnull. Modified: branches/gcc-4_1-branch/gcc/java/ChangeLog branches/gcc-4_1-branch/gcc/java/class.c branches/gcc-4_1-branch/gcc/java/expr.c branches/gcc-4_1-branch/gcc/java/lang.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug other/23541] all error messages produce segfault
--- Comment #19 from ghazi at gcc dot gnu dot org 2006-03-31 13:51 --- Of the 3 workarounds in comment #17, bootstrap with Sun cc doesn't work because of PR 18058 (although there is a patch posted for that PR). Also bootstrap with GCC 2.x or 3.x isn't quite right since I tried 3.4.x and it still had the problems. Only by using --disable-nls was I able to get a successful bootstrap completed on sparc64-sun-solaris2.10. My hope is that this PR will get more attention. We can't IMHO release 4.2 with this problem still there, and it was filed in October. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug tree-optimization/26771] [4.2 regression] ICE with -fmudflap
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-31 13:55
---
The original testcase does not crash anymore, but changing the
inline bool f1(char* p, char* q, int) { return p ? p : q; }
to
inline bool f1(char* p, char* q, const int&) { return p ? p : q; }
makes the compiler crash again.
Btw, the ICE is:
bug.cc: In function 'void f2(E)':
bug.cc:51: error: definition in block 5 does not dominate use in block 20
for SSA_NAME: SMT.21_144 in statement:
SMT.21_78 = PHI ;
PHI argument
SMT.21_144
for PHI node
SMT.21_78 = PHI ;
bug.cc:51: internal compiler error: verify_ssa failed
Please submit a full bug report, [etc.]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26771
[Bug tree-optimization/26771] [4.2 regression] ICE with -fmudflap
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-03-31 13:57 --- Created an attachment (id=11173) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11173&action=view) testcase Testcase according to comment #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26771
[Bug fortran/26920] Cannot build using static libraries
--- Comment #2 from dir at lanl dot gov 2006-03-31 13:59 --- There was a discussion of how to do it on some websites. I thought that they just configured gfortran and gcc a liitle different, but I guess that I will have to go back and look at the details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26920
[Bug libstdc++/6702] requirements for wchar_t support are too restrictive for Solaris pre 10
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:05 --- > Confirmed on Solaris 7, 8 and 9, everything is fine on Solaris 10. Three functions are missing: conftest.cc:75: error: '::wcstold' has not been declared conftest.cc:76: error: '::wcstoll' has not been declared conftest.cc:78: error: '::wcstoull' has not been declared They'll need to be specialized like vfwscanf and the like. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
[Bug other/23541] all error messages produce segfault
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:09 --- > Of the 3 workarounds in comment #17, bootstrap with Sun cc doesn't work > because of PR 18058 (although there is a patch posted for that PR). Also > bootstrap with GCC 2.x or 3.x isn't quite right since I tried 3.4.x and > still had the problems. It's the wrong PR, this one is for pre-4.2, the 3 workarounds work. > My hope is that this PR will get more attention. We can't IMHO release 4.2 > with this problem still there, and it was filed in October. The problem is minor for pre-4.2. The blocker PR for 4.2 is PR other/26507. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug tree-optimization/26948] ICE: tree check: expected ssa_name, with -ftree-vectorize
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-03-31 14:24 --- Probably a duplicate of PR26197. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26948
[Bug other/23541] all error messages produce segfault
--- Comment #21 from ghazi at gcc dot gnu dot org 2006-03-31 14:29 --- (In reply to comment #20) > It's the wrong PR, this one is for pre-4.2, the 3 workarounds work. > The problem is minor for pre-4.2. The blocker PR for 4.2 is PR other/26507. Huh? The third comment in 26507 (by you I might add) agrees that PR 26507 and this one are the same problem. We should close one as a dup of the other. I also don't understand what you mean by pre-4.2. Is that a roundabout way of saying 4.1? I don't have any problems in 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug other/23541] all error messages produce segfault
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:36 --- > Huh? The third comment in 26507 (by you I might add) agrees that PR 26507 and > this one are the same problem. We should close one as a dup of the other. I precisely chose not to close either because of their different scope. > I also don't understand what you mean by pre-4.2. Is that a roundabout way of > saying 4.1? Yes, it is. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug other/23541] all error messages produce segfault
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:44 --- > My hope is that this PR will get more attention. We can't IMHO release 4.2 > with this problem still there, and it was filed in October. Oh, and feel free to take a stab at it. :-) Part of the problem is that the intl package in the src tree uses a stripped down build system that seems to disable the counter-measures present in the package again this kind of problems... The naive fix I've attached might be the safest approach in the end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug middle-end/26635] [4.1/4.2 Regression] Bogus Storage_Error warning
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-03-31 15:01 --- I'm about to post a fix. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kazu at gcc dot gnu dot org |ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26635
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #4 from danglin at gcc dot gnu dot org 2006-03-31 15:04 --- Breakpoint 1, make_decl_rtl (decl=0x40148880) at ../../gcc/gcc/varasm.c:968 968 gcc_assert (TREE_CODE (decl) != TYPE_DECL (gdb) list 963 || TREE_PUBLIC (decl) 964 || DECL_EXTERNAL (decl) 965 || DECL_REGISTER (decl)); 966 967 /* And that we were not given a type or a label. */ 968 gcc_assert (TREE_CODE (decl) != TYPE_DECL 969 && TREE_CODE (decl) != LABEL_DECL); 970 971 /* For a duplicate declaration, we can be called twice on the 972 same DECL node. Don't discard the RTL already made. */ (gdb) bt #0 make_decl_rtl (decl=0x40148880) at ../../gcc/gcc/varasm.c:968 #1 0x003a6adc in init_one_libfunc (name=) at ../../gcc/gcc/optabs.c:5131 #2 0x000f1768 in init_exception_processing () at ../../gcc/gcc/cp/except.c:80 #3 0x0003878c in cxx_init_decl_processing () at ../../gcc/gcc/cp/decl.c:3250 #4 0x000b3760 in cxx_init () at ../../gcc/gcc/cp/lex.c:386 #5 0x0041dad4 in toplev_main (argc=, argv=) at ../../gcc/gcc/toplev.c:1864 #6 0x403566d8 in __libc_start_main () from /lib/libc.so.6 #7 0x0001d190 in _start () at ../sysdeps/hppa/elf/start.S:84 (gdb) p debug_tree (decl) unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > SI size unit size align 32 symtab 0 alias set -1> public external SI file line 0> $1 = void -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug c++/26961] New: ICE simplify_subreg:3813
compile trivial program with
g++ -c -O1 ice.cxx
I'll append a machince-readable copy of the test case...
==
typedef unsigned long long U64;
typedef unsigned short U16;
typedef unsigned char U8;
U16 m_rh;
U8 m_gN_eQ;
void f()
{
U16 m_$localcse_rh_110_ ;
m_gN_eQ = ((m_rh) ? 0x1ULL
: static_cast(m_$localcse_rh_110_ != 0x3fff))
== 0xffULL;
}
--
Summary: ICE simplify_subreg:3813
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: apl at alum dot mit dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
[Bug c++/26961] ICE simplify_subreg:3813
--- Comment #1 from apl at alum dot mit dot edu 2006-03-31 15:32 --- Created an attachment (id=11174) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11174&action=view) test case causing ICE g++ -c -O1 ice.cxx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-31
15:34 ---
Subject: Re: [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
> --- Comment #4 from danglin at gcc dot gnu dot org 2006-03-31 15:04
> ---
> Breakpoint 1, make_decl_rtl (decl=0x40148880) at ../../gcc/gcc/varasm.c:968
> 968 gcc_assert (TREE_CODE (decl) != TYPE_DECL
> (gdb) list
> 963 || TREE_PUBLIC (decl)
> 964 || DECL_EXTERNAL (decl)
> 965 || DECL_REGISTER (decl));
> 966
> 967 /* And that we were not given a type or a label. */
> 968 gcc_assert (TREE_CODE (decl) != TYPE_DECL
> 969 && TREE_CODE (decl) != LABEL_DECL);
> 970
> 971 /* For a duplicate declaration, we can be called twice on the
> 972 same DECL node. Don't discard the RTL already made. */
> (gdb) bt
> #0 make_decl_rtl (decl=0x40148880) at ../../gcc/gcc/varasm.c:968
> #1 0x003a6adc in init_one_libfunc (name=)
> at ../../gcc/gcc/optabs.c:5131
> #2 0x000f1768 in init_exception_processing () at ../../gcc/gcc/cp/except.c:80
> #3 0x0003878c in cxx_init_decl_processing () at ../../gcc/gcc/cp/decl.c:3250
> #4 0x000b3760 in cxx_init () at ../../gcc/gcc/cp/lex.c:386
> #5 0x0041dad4 in toplev_main (argc=,
> argv=) at ../../gcc/gcc/toplev.c:1864
> #6 0x403566d8 in __libc_start_main () from /lib/libc.so.6
> #7 0x0001d190 in _start () at ../sysdeps/hppa/elf/start.S:84
> (gdb) p debug_tree (decl)
> type type size
> unit size
> align 32 symtab 0 alias set -1 precision 32 min 0x400c2270 -2147483648> max
> pointer_to_this >
> SI size unit size 4>
> align 32 symtab 0 alias set -1>
> public external SI file line 0>
> $1 = void
Oops, wrong call to ame_decl_rtl. The one causing the ICE is:
Assembling functions:
virtual void TAO_DynCommon::insert_longdouble(LongDouble) void
TAO_DynCommon::_ZTv0_n12_N13TAO_DynCommon17insert_longdoubleE10LongDouble(LongDouble)
Breakpoint 1, make_decl_rtl (decl=0x400cc4d0) at ../../gcc/gcc/varasm.c:957
957 gcc_assert (TREE_CODE (decl) != PARM_DECL
(gdb) bt
#0 make_decl_rtl (decl=0x400cc4d0) at ../../gcc/gcc/varasm.c:957
#1 0x00302dd4 in expand_expr_real_1 (exp=,
target=, tmode=,
modifier=EXPAND_NORMAL, alt_rtl=0xc0013208) at ../../gcc/gcc/expr.c:6730
#2 0x00308414 in expand_expr_real (exp=0x400cc4d0, target=0x40175460,
tmode=BLKmode, modifier=EXPAND_NORMAL, alt_rtl=0xc0013208)
at ../../gcc/gcc/expr.c:6576
#3 0x0030dd6c in store_expr (exp=0x400cc4d0, target=0x40175460,
call_param_p=0) at ../../gcc/gcc/expr.c:4275
#4 0x002fb3a4 in expand_assignment (to=0x400cc9a0, from=0x400cc4d0)
at ../../gcc/gcc/expr.c:4154
#5 0x002ffa9c in expand_expr_real_1 (exp=,
target=, tmode=,
modifier=, alt_rtl=0x0) at ../../gcc/gcc/expr.c:8467
#6 0x0030832c in expand_expr_real (exp=0x4014c550, target=0x40175460,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/gcc/expr.c:6570
#7 0x00410f08 in expand_expr_stmt (exp=0x400cc4d0) at expr.h:494
#8 0x00458d68 in expand_gimple_basic_block (bb=0x400cdf50)
at ../../gcc/gcc/cfgexpand.c:1368
#9 0x00459ec0 in tree_expand_cfg () at ../../gcc/gcc/cfgexpand.c:1627
#10 0x00454e68 in execute_one_pass (pass=0x64ec90)
at ../../gcc/gcc/passes.c:863
#11 0x00455008 in execute_pass_list (pass=0x64ec90)
at ../../gcc/gcc/passes.c:910
#12 0x001a3750 in tree_rest_of_compilation (fndecl=0x40148700)
at ../../gcc/gcc/tree-optimize.c:418
#13 0x0010753c in expand_body (fn=0x40148700)
at ../../gcc/gcc/cp/semantics.c:3012
#14 0x000fc2f4 in use_thunk (thunk_fndecl=0x40175460,
emit_p=) at ../../gcc/gcc/cp/method.c:520
#15 0x001074c4 in expand_body (fn=0x40172e00)
at ../../gcc/gcc/cp/semantics.c:2965
#16 0x00495cf0 in cgraph_expand_function (node=0x40172f00)
at ../../gcc/gcc/cgraphunit.c:1102
#17 0x00498994 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1167
#18 0x000a7390 in cp_finish_file () at ../../gcc/gcc/cp/decl2.c:3147
#19 0x00172284 in c_common_parse_file (set_yydebug=)
at ../../gcc/gcc/c-opts.c:1165
#20 0x0041dbdc in toplev_main (argc=,
argv=) at ../../gcc/gcc/toplev.c:999
#21 0x403566d8 in __libc_start_main () from /lib/libc.so.6
#22 0x0001d190 in _start () at ../sysdeps/hppa/elf/start.S:84
(gdb) p debug_tree (decl)
unit size
align 8 symtab 0 alias set -1
fields
nonlocal decl_3 BLK file TAO.cc line 2 size unit size
align 8 offset_align 64
offset
bit offset context
chain >
X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
pointer_to_this chain >
used BLK file TAO.cc line 13 size unit size
align 8 context >
(gdb) step
951 {
(gdb)
957 gcc_assert (TREE_CODE (decl) != PARM_DECL
(gdb)
961 gcc_assert (TREE_COD
[Bug c++/26962] New: program which crosses initialization compiles without error when it really should not
The following c++ program compiles without error even though it crosses an
initialization. I only noticed this problem on g++ 3.4.4, 3.4.5. Versions
before and after 3.4 appear to be okay.
int g()
{
return 0;
}
int main()
{
goto L1;
int i=g();
L1:;
}
--
Summary: program which crosses initialization compiles without
error when it really should not
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary dot lazer at yahoo dot com
GCC build triplet: g++ (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)
GCC host triplet: Linux version 2.6.9-34.ELsmp
GCC target triplet: CentOS release 4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26962
[Bug c++/26962] program which crosses initialization compiles without error when it really should not
--- Comment #1 from gary dot lazer at yahoo dot com 2006-03-31 16:10 --- more info: i686, intel dual xeon 2 GHz processors, dell precision 530 g++ output: Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26962
[Bug tree-optimization/26963] New: ICE with -fipa-pta and templates
The following testcase crashes the compiler when compiled with -fipa-pta:
==
struct A
{
int i, j;
};
A foo(A);
template A bar(A a) { return foo(a); }
void baz()
{
bar<0>(A());
}
==
bug.cc: In function 'void baz(B<0>&)':
bug.cc:12: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: ICE with -fipa-pta and templates
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26963
[Bug middle-end/26635] [4.1/4.2 Regression] Bogus Storage_Error warning
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-31 17:24:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26635
[Bug testsuite/25741] Gcc testsuite isn't parallel build safe
--- Comment #7 from hjl at gcc dot gnu dot org 2006-03-31 17:36 ---
Subject: Bug 25741
Author: hjl
Date: Fri Mar 31 17:36:00 2006
New Revision: 112583
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112583
Log:
contrib/regression/
2006-03-31 H.J. Lu <[EMAIL PROTECTED]>
Backport from mainline
2006-01-18 Andrew Pinski <[EMAIL PROTECTED]>
* btest-gcc.sh: gcc.sum has moved to gcc/testsuite/gcc/gcc.sum.
g++.sum has moved to gcc/testsuite/g++/g++.sum.
objc.sum has moved to gcc/testsuite/objc/objc.sum.
gcc/
2006-03-31 H.J. Lu <[EMAIL PROTECTED]>
PR testsuite/25741
Backport from mainline
2006-01-16 H.J. Lu <[EMAIL PROTECTED]>
* Makefile.in (check-%): Depend on site.exp instead of
$(TESTSUITEDIR)/site.exp. Run "runtest" in separate language
directories.
2006-01-17 Shantonu Sen <[EMAIL PROTECTED]>
* Makefile.in (check-%, check-consistency): Use $${srcdir}
instead of $(srcdir) and ${srcdir}.
gcc/testsuite/
2006-03-31 H.J. Lu <[EMAIL PROTECTED]>
PR testsuite/25741
Backport from mainline
2006-01-16 H.J. Lu <[EMAIL PROTECTED]>
* lib/g++.exp (g++_init): Use $base_dir/../../ instead of
$base_dir/../.
* lib/gfortran.exp (gfortran_init): Likewise.
* lib/obj-c++.exp (obj-c++_init): Likewise.
* lib/scanasm.exp (scan-assembler-dem): Likewise.
(scan-assembler-dem-not): Likewise.
* lib/scandump.exp (scan-dump-dem): Likewise.
(scan-dump-dem-not): Likewise.
Modified:
branches/gcc-4_1-branch/contrib/regression/ChangeLog
branches/gcc-4_1-branch/contrib/regression/btest-gcc.sh
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/Makefile.in
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/lib/g++.exp
branches/gcc-4_1-branch/gcc/testsuite/lib/gfortran.exp
branches/gcc-4_1-branch/gcc/testsuite/lib/obj-c++.exp
branches/gcc-4_1-branch/gcc/testsuite/lib/scanasm.exp
branches/gcc-4_1-branch/gcc/testsuite/lib/scandump.exp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25741
[Bug testsuite/25741] Gcc testsuite isn't parallel build safe
--- Comment #8 from hjl at gcc dot gnu dot org 2006-03-31 17:42 --- Subject: Bug 25741 Author: hjl Date: Fri Mar 31 17:42:06 2006 New Revision: 112584 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112584 Log: 2006-03-31 H.J. Lu <[EMAIL PROTECTED]> PR testsuite/25741 Backport from mainline 2006-01-16 H.J. Lu <[EMAIL PROTECTED]> * lib/g++.exp (g++_init): Use $base_dir/../../ instead of $base_dir/../. * lib/gfortran.exp (gfortran_init): Likewise. * lib/scanasm.exp (scan-assembler-dem): Likewise. (scan-assembler-dem-not): Likewise. Modified: branches/gcc-4_0-branch/contrib/regression/ChangeLog branches/gcc-4_0-branch/contrib/regression/btest-gcc.sh branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/Makefile.in branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/lib/g++.exp branches/gcc-4_0-branch/gcc/testsuite/lib/gfortran.exp branches/gcc-4_0-branch/gcc/testsuite/lib/scanasm.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25741
[Bug debug/26964] New: Duplicate debug info for enums in namespaces
gcc currently generates duplicate debug information for enums declared in
namespaces.
Compile this C++ code with -g:
namespace { enum x { i = 1 }; }
x y;
In the .s file, I see this:
.uleb128 0x3
.string "x"
.byte 0x4
.byte 0x1
.byte 0x1
.byte 0x4
.byte 0x1
.byte 0x1
.uleb128 0x4
.string "i"
.sleb128 1
.uleb128 0x4
.string "i"
.sleb128 1
Note the duplicate size/file/line info, and the duplication of information
about "i".
readelf --debug-dump shows this:
<2><57>: Abbrev Number: 3 (DW_TAG_enumeration_type)
DW_AT_name: x
DW_AT_byte_size : 4
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_byte_size : 4
DW_AT_decl_file : 1
DW_AT_decl_line : 1
<3><60>: Abbrev Number: 4 (DW_TAG_enumerator)
DW_AT_name: i
DW_AT_const_value : 1
<3><64>: Abbrev Number: 4 (DW_TAG_enumerator)
DW_AT_name: i
DW_AT_const_value : 1
where we see the same duplication.
This is not a visible problem when using the debugger, because the duplicate
information just tells it the same information it already has. But it probably
makes the debugger a bit slower. And it definitely makes object files larger
than they need to be, which wastes time creating them and space storing them.
I believe the problem arises like this:
gen_type_die calls
declare_in_namespace calls
gen_type_die
emits die via gen_enumeration_type_die
returns
returns
emits die via gen_enumeration_type_die
I don't have a patch for this. I want to record it before I forget about it.
--
Summary: Duplicate debug info for enums in namespaces
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26964
[Bug target/26879] LibJava not compile under alpha
--- Comment #12 from zerocool at modemsoft dot it 2006-03-31 18:14 ---
Finally i produce the information that you ask me with the your precious
indication and that is :
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "alpha-alphaslack-linux"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /gcc-8eea83c766efc28763a9d30e4baba897/gcc.build.lnx/gcc/jc1
/tmp/cctDRgBtjx -quiet -dumpbase cctDRgBtjx -auxbase-strip NONE -g1
-Wno-deprecated -ffilelist-file -fencoding=UTF-8 -fbootclasspath=
-fclasspath=..:/gcc-8eea83c766efc28763a9d30e4baba897/gcc-4.2-20060325/libjava:/gcc-8eea83c766efc28763a9d30e4baba897/gcc.build.lnx/alpha-alphaslack-linux/libjava:../../../../../gcc-4.2-20060325/libjava/classpath:../../../../../gcc-4.2-20060325/libjava/classpath/external/w3c_dom:../../../../../gcc-4.2-20060325/libjava/classpath/external/sax:../../../../../gcc-4.2-20060325/libjava/classpath/external/relaxngDatatype:.:
-foutput-class-dir=. -fsyntax-only -femit-class-files -o /dev/null -MD_ -MT
lists/gnu-CORBA-DynAn.stamp -MF lists/gnu-CORBA-DynAn.deps
Program received signal SIGSEGV, Segmentation fault.
0x0210d598 in readdir64 () from /lib/libc.so.6.1
(gdb) list
26 int main (int argc, char **argv);
27
28 /* We define main() to call toplev_main(), which is defined in
toplev.c.
29 We do this in a separate file in order to allow the language
front-end
30 to define a different main(), if it so desires. */
31
32 int
33 main (int argc, char **argv)
34 {
35return toplev_main (argc, (const char **) argv);
(gdb) backtrace
#0 0x0210d598 in readdir64 () from /lib/libc.so.6.1
#1 0x0210dcec in scandir () from /lib/libc.so.6.1
#2 0x00012005c3e8 in caching_stat (
filename=0x1206883b0
"/gcc-8eea83c766efc28763a9d30e4baba897/gcc-4.2-20060325/libjava/java/lang/reflect",
buf=0x11fd8ca48)
at ../../gcc-4.2-20060325/gcc/java/jcf-io.c:394
#3 0x00012005d5cc in find_class (classname=0x1205cf35e
"java.lang.reflect.Field", classname_length=23, jcf=0x11fd8cb50,
source_ok=1) at ../../gcc-4.2-20060325/gcc/java/jcf-io.c:522
#4 0x000120060c4c in read_class (name=) at
../../gcc-4.2-20060325/gcc/java/jcf-parse.c:544
#5 0x000120060e68 in load_class (class_or_name=0x22cfea0, verbose=0)
at ../../gcc-4.2-20060325/gcc/java/jcf-parse.c:689
#6 0x00012001a614 in java_complete_class () at parse.y:6942
#7 0x00012005def4 in parse_source_file_2 () at
../../gcc-4.2-20060325/gcc/java/jcf-parse.c:1019
#8 0x000120061e34 in java_parse_file (set_yydebug=)
at ../../gcc-4.2-20060325/gcc/java/jcf-parse.c:1287
#9 0x000120281fd8 in toplev_main (argc=, argv=)
at ../../gcc-4.2-20060325/gcc/toplev.c:999
#10 0x000120073c78 in main (argc=543721216, argv=0x12068874b) at
../../gcc-4.2-20060325/gcc/main.c:35
Now hope that this help you :-)
Waiting your news...
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug c++/26965] New: Unnecessary debug info for unused consts in C++
Compile this C++ code with -g
enum x { i = 1 };
class c {
static const x beg = i;
};
void bar () { }
Looking at the .s output and the readelf --debug-dump output will show that
there is no debug info for x or beg. This is as expected: they are not used by
any actual code, so there is no need to emit debug info for them.
Now compile this code, which adds an unused inline function:
enum x { i = 1 };
class c {
static const x beg = i;
int foo () { return (int) beg; }
};
void bar () { }
Now I see debug info for enum x and for the const beg. However, there is no
debug info for the unused inline function foo. There should not be any debug
info for the enum or the const either.
This matters particularly because these cases arise in ordinary C++ code, and
in particular in the libstdc++ headers. For example, when I compile this file
with -g:
#include
void bar () { }
I get over 27K of debug info. That's pretty bad.
This was better in gcc 4.0.1. For that, I get 9K of debug info for the
example--not great, but much better. It changed in gcc 4.0.2. I
believe the change was due to the patch for PR 23190, by RTH on 2005-09-08.
I don't have a patch for this. I'm recording it so that I don't forget it.
--
Summary: Unnecessary debug info for unused consts in C++
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug fortran/26779] Internal module procedure may not have private type dummy arguments
--- Comment #4 from pault at gcc dot gnu dot org 2006-03-31 18:58 --- The patch to 4.1 will be committed tomorrow. -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26779
[Bug rtl-optimization/26961] [4.0/4.1/4.2 Regression] ICE simplify_subreg:3813
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-31 19:11 ---
Confirmed, a litte more reduced testcase:
typedef unsigned long long U64;
typedef unsigned short U16;
typedef unsigned char U8;
U16 m_rh;
U8 m_gN_eQ;
void f()
{
U16 m_;
m_gN_eQ = ((m_rh) ? 0x1ULL
: (U64)(m_ != 0x3fff))
== 0xffULL;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c++ |rtl-optimization
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||3.4.0 4.1.0 4.0.0 4.0.3
||4.1.0
Known to work||3.3.3
Last reconfirmed|-00-00 00:00:00 |2006-03-31 19:11:29
date||
Summary|ICE simplify_subreg:3813|[4.0/4.1/4.2 Regression] ICE
||simplify_subreg:3813
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
[Bug c++/26962] [3.4 Regression] program which crosses initialization compiles without error when it really should not
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-31 19:13 --- *** This bug has been marked as a duplicate of 20721 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||accepts-invalid Known to fail||4.0.0 4.0.2 Known to work||3.4.0 4.1.0 4.0.3 Resolution||DUPLICATE Summary|program which crosses |[3.4 Regression] program |initialization compiles |which crosses initialization |without error when it really|compiles without error when |should not |it really should not http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26962
[Bug c++/20721] [3.4 Regression] crossing of a initialization left undetected on goto
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-31 19:13 --- *** Bug 26962 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gary dot lazer at yahoo dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20721
[Bug tree-optimization/26963] ICE with -fipa-pta and templates
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 19:59 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-31 19:59:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26963
[Bug c++/26965] Unnecessary debug info for unused consts in C++
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 20:05 --- This looks very related to PR 14167. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug rtl-optimization/26847] [4.2 Regression] Missed optimization in simplify_plus_minus
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26847
[Bug c++/26966] New: linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
Hello, I've compiled 4.2.0 GCC on OpenBSD 3.9-current. I've configured it with: /home/karel/svn/gcc/trunk/configure --prefix=/home/karel/usr/local/gcc-trunk-20060331 --enable-shared --enable-threads --enable-languages=c++ --disable-checking --disable-nls the problem is that resulting C++ compiler is not able to build simple hello world like application, since linking fails with: $ c++ hello.cc /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libstdc++.a(locale-misc-inst.o)(.gnu.linkonce.t._ZSt16__convert_from_vIeEiPciPKcT_RKPii+0x65): In function `int std::__convert_from_v(char*, int, char const*, long double, int* const&, int)': /home/karel/build/obj-gcc-trunk/i386-unknown-openbsd3.9/libstdc++-v3/include/i386-unknown-openbsd3.9/bits/c++locale.h:67: warning: strcpy() is almost always misused, please use strlcpy() /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libstdc++.a(locale-misc-inst.o)(.gnu.linkonce.t._ZSt16__convert_from_vIeEiPciPKcT_RKPii+0x8c):/home/karel/build/obj-gcc-trunk/i386-unknown-openbsd3.9/libstdc++-v3/include/i386-unknown-openbsd3.9/bits/c++locale.h:74: warning: sprintf() is often misused, please use snprintf() /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libstdc++.a(cp-demangle.o)(.text+0x3703): In function `d_demangle': : warning: strcat() is almost always misused, please use strlcat() /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libstdc++.a(locale_init.o)(.text._ZNSt6locale13_S_initializeEv+0x2a): In function `std::locale::_S_initialize()': /home/karel/svn/gcc/trunk/libstdc++-v3/src/locale_init.cc:145: undefined reference to `pthread_once' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libstdc++.a(eh_globals.o)(.text._Z41__static_initialization_and_destruction_0ii+0x4a): In function `__static_initialization_and_destruction_0(int, int)': /home/karel/svn/gcc/trunk/libstdc++-v3/libsupc++/eh_globals.cc:97: undefined reference to `pthread_key_create' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libstdc++.a(eh_globals.o)(.text.__cxa_get_globals_fast+0x71): In function `__cxa_get_globals_fast': /home/karel/svn/gcc/trunk/libstdc++-v3/libsupc++/eh_globals.cc:150: undefined reference to `pthread_getspecific' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libstdc++.a(eh_globals.o)(.text.__cxa_get_globals+0x71): In function `__cxa_get_globals': /home/karel/svn/gcc/trunk/libstdc++-v3/libsupc++/eh_globals.cc:150: undefined reference to `pthread_getspecific' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libstdc++.a(eh_globals.o)(.text.__cxa_get_globals+0xa9): In function `__cxa_get_globals': /home/karel/build/obj-gcc-trunk/i386-unknown-openbsd3.9/libstdc++-v3/include/i386-unknown-openbsd3.9/bits/gthr-default.h:542: undefined reference to `pthread_setspecific' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0xcf): In function `fc_key_init_once': /home/karel/svn/gcc/trunk/gcc/gthr-posix.h:516: undefined reference to `pthread_once' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0xfd): In function `fc_key_init': /home/karel/svn/gcc/trunk/gcc/gthr-posix.h:524: undefined reference to `pthread_key_create' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0x1ab): In function `_Unwind_SjLj_Unregister': /home/karel/svn/gcc/trunk/gcc/gthr-posix.h:542: undefined reference to `pthread_setspecific' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0x292): In function `uw_install_context': /home/karel/svn/gcc/trunk/gcc/gthr-posix.h:542: undefined reference to `pthread_setspecific' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0x2dc): In function `_Unwind_SjLj_RaiseException': /home/karel/svn/gcc/trunk/gcc/gthr-posix.h:536: undefined reference to `pthread_getspecific' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0x395): In function `_Unwind_SjLj_Register': /home/karel/svn/gcc/trunk/gcc/gthr-posix.h:536: undefined reference to `pthread_getspecific' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0x3a6):/home/karel/svn/gcc/trunk/gcc/gthr-posix.h:542: undefined reference to `pthread_setspecific' /home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbs
[Bug tree-optimization/26763] [4.1 Regression] wrong final value of induction variable calculated
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-31 21:12 --- I believe c-common.c:pointer_int_sum is wrong in relying on pointer overflow during conversion of the integer offset to an unsigned pointer. I'm sending a patch that fixes this for comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug libfortran/19303] [4.1 only] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #23 from tkoenig at gcc dot gnu dot org 2006-03-31 21:13 --- Subject: Bug 19303 Author: tkoenig Date: Fri Mar 31 21:13:46 2006 New Revision: 112590 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112590 Log: PR fortran/19303 Backport from mainline * libgfortran.h (compile_options_t): Add record_marker. * runtime/compile_options.c (set_record_marker): New function. * io/open.c: If we have four-byte record markers, use GFC_INTEGER_4_HUGE as default record length. * io/file_pos.c (unformatted_backspace): Handle different size record markers. * io/transfer.c (us_read): Likewise. (us_write): Likewise. (next_record_r): Likewise. (write_us_marker): Likewise. (next_record_w): Likewise. 2006-03-31 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/19303 Backport from mainline * gfortran.dg/record_marker_1.f90: New test case. * gfortran.dg/record_marker_2.f: New test case. * gfortran.dg/record_marker_3.f90: New test case. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/record_marker_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/record_marker_2.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/record_marker_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/invoke.texi branches/gcc-4_1-branch/gcc/fortran/lang.opt branches/gcc-4_1-branch/gcc/fortran/options.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/file_pos.c branches/gcc-4_1-branch/libgfortran/io/open.c branches/gcc-4_1-branch/libgfortran/io/transfer.c branches/gcc-4_1-branch/libgfortran/libgfortran.h branches/gcc-4_1-branch/libgfortran/runtime/compile_options.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] [4.1 only] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #24 from tkoenig at gcc dot gnu dot org 2006-03-31 21:24 --- Fixed on 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 21:38 --- Hmm, these functions should be weak and should not be visible. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |other GCC build triplet|i386-unknown-openbsd3.9 | GCC host triplet|i386-unknown-openbsd3.9 | GCC target triplet|i386-unknown-openbsd3.9 |i386--openbsd3.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug testsuite/25741] Gcc testsuite isn't parallel build safe
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.1 4.0.4 4.2.0 Target Milestone|4.2.0 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25741
[Bug bootstrap/26936] fix-header segfault with glibc-2.4 header
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26936
Re: [Bug tree-optimization/26944] [4.1/4.2 Regression] -ftree-ch generates worse code
> Compare pretmp.28_49 with pretmp.32_11, why are the arguments in a different > order? Is there something unstable in the PRE algorithm? > No, we just call fold on the expressions we build, and whatever it gives us, we use :)
[Bug tree-optimization/26944] [4.1/4.2 Regression] -ftree-ch generates worse code
--- Comment #3 from dberlin at gcc dot gnu dot org 2006-03-31 22:41 --- Subject: Re: [4.1/4.2 Regression] -ftree-ch generates worse code > Compare pretmp.28_49 with pretmp.32_11, why are the arguments in a different > order? Is there something unstable in the PRE algorithm? > No, we just call fold on the expressions we build, and whatever it gives us, we use :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
[Bug c/26968] New: HDF5 1.7.52 test segfaults with 4.1.0, fine with 4.0.2 (regression)
Still trying to get more info, but here is what I have. Trying to build HDF5 1.7.52 on Fedora Core 5 i386 with gcc-4.1.0-3 (also seem to see it with gcc-4.1.0-4 from rawhide). The Dataspaces (h5s) test segfaults. I've tracked it down to the following code in H5Dio.c:2263-2270 (in H5D_create_chunk_map) apparently not actually setting fm->chunk_dim: /* Decide the number of chunks in each dimension*/ for(u=0; uchunk_dim[u]=fm->layout->u.chunk.dim[u]; /* Round up to the next integer # of chunks, to accomodate partial chunks */ fm->chunks[u] = ((fm->f_dims[u]+dataset->shared->layout.u.chunk.dim[u])-1) / dataset->shared->layout.u.chunk.dim[u]; } /* end for */ Probably is getting optimized away for some reason. fm->chunk_dim is not reference again in H5D_create_chunk_map, but it is later on I have not been able to distill to a simple test case. Flags used to compile are the standard RPM_OPT_FLAGS for FC5: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables Flags used with 4.0.2 were: -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=penti um4 -fasynchronous-unwind-tables So there might be something there too -- Summary: HDF5 1.7.52 test segfaults with 4.1.0, fine with 4.0.2 (regression) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: orion at cora dot nwra dot com GCC host triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26968
[Bug middle-end/26968] HDF5 1.7.52 test segfaults with 4.1.0, fine with 4.0.2 (regression)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 23:14 --- Can you try first without -fstack-protector. If that does not work, try with -fno-strict-aliasing added to see if maybe there is an aliasing issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26968
[Bug libgcj/26624] make install too slow due to CNI header installation
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-31 23:26 --- I wrote a little script to print the amount of time taken for each line of 'make' output. This tends to confirm that installing the headers is very slow. One other difference from 'make install-exec' is that the ordinary install spends 24 seconds doing nothing in classpath/lib. This is the already known problem that 'make' gets very large and hits swap. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26624
[Bug java/25847] libjava build doesn't stop when there is a fatal error
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-31 23:30 --- Is there a reasonable way to detect good failures versus bad failures here? We definitely want to ignore cases where gcj-dbtool fails due to things like not having mmap available. Perhaps the thing to do is let it fail and then catch it during 'make check'. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25847
[Bug c/26968] HDF5 1.7.52 test segfaults with 4.1.0, fine with 4.0.2 (regression)
--- Comment #2 from orion at cora dot nwra dot com 2006-03-31 23:32 --- Compiled using 4.1.0 with the old 4.0.2 (FC4) flags (no -fstack-protector and --param=ssp-buffer-size=4) with no effect. Added -fno-strict-aliasing with no effect (at least for this, I've got a type conversion issue to track down next...). -- orion at cora dot nwra dot com changed: What|Removed |Added Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26968
[Bug middle-end/26968] HDF5 1.7.52 test segfaults with 4.1.0, fine with 4.0.2 (regression)
--- Comment #3 from orion at cora dot nwra dot com 2006-03-31 23:34 --- Sorry, my browser seems to have changed components... -- orion at cora dot nwra dot com changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26968
[Bug fortran/25358] vector assignment to assumed-size Cray Pointee error
--- Comment #5 from kargl at gcc dot gnu dot org 2006-04-01 00:04 --- Subject: Bug 25358 Author: kargl Date: Sat Apr 1 00:04:46 2006 New Revision: 112594 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112594 Log: 2006-03-31 Asher Langton <[EMAIL PROTECTED]> PR fortran/25358 *expr.c (gfc_check_assign): Allow cray pointee to be assumes-size. 2006-03-31 Asher Langton <[EMAIL PROTECTED]> PR fortran/25358 gfortran.dg/cray_pointers_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/cray_pointers_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25358
[Bug tree-optimization/26969] New: ICE with -O3 -ftree-vectorize
With the following code gcc-4.1 and 4.2 ICE when using "-O3 -ftree-vectorize".
The latest checkout I have of 4.0 worked just fine.
struct re_pattern_buffer
{
char *buffer;
char *fastmap;
long options;
};
void
ruby_re_compile_fastmap (struct re_pattern_buffer *bufp)
{
unsigned char *pattern = (unsigned char *) bufp->buffer;
register char *fastmap = bufp->fastmap;
register unsigned char *p = pattern;
register int j;
int options = bufp->options;
while (p)
{
switch (*p++)
{
case 0:
for (j = 0; j < (1 << 8); j++)
{
if (j != '\n' || (options & (((1L) << 1) << 1)))
fastmap[j] = 1;
}
}
}
}
gcc version 4.2.0 20060331 (experimental)
gcc -O3 -ftree-vectorize ruby.c -c
ruby.x.i: In function ruby_re_compile_fastmap:
ruby.x.i:9: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions
--
Summary: ICE with -O3 -ftree-vectorize
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: halcy0n at gentoo dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug c++/26970] New: -O3 -Wformat=2 complains about floats written to ostream
This short section of code when compiled with:
g++ -g -O3 -Wformat=2 bug.cpp
complains
{{{
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/c++locale.h:
In function `int std::__convert_from_v(char*, int, const char*, _Tv,
__locale_struct* const&, int) [with _Tv = double]':
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/locale_facets.tcc:1072:
instantiated from `_OutIter std::num_put<_CharT,
_OutIter>::_M_insert_float(_OutIter, std::ios_base&, _CharT, char, _ValueT)
const [with _ValueT = double, _CharT = char, _OutIter =
std::ostreambuf_iterator >]'
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/locale_facets.tcc:1216:
instantiated from `_OutIter std::num_put<_CharT, _OutIter>::do_put(_OutIter,
std::ios_base&, _CharT, double) const [with _CharT = char, _OutIter =
std::ostreambuf_iterator >]'
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/locale_facets.h:2353:
instantiated from `_OutIter std::num_put<_CharT, _OutIter>::put(_OutIter,
std::ios_base&, _CharT, double) const [with _CharT = char, _OutIter =
std::ostreambuf_iterator >]'
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/ostream.tcc:246:
instantiated from `std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(double) [with _CharT = char,
_Traits = std::char_traits]'
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/ostream:219:
instantiated from `std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(float) [with _CharT = char,
_Traits = std::char_traits]'
bug.cpp:16: instantiated from here
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/c++locale.h:84:
warning: format not a string literal, argument types not checked
}}}
Here is the code
{{{
#include
#include
int main(int argc, char* argv)
{
std::vector u(10,17);
for ( std::vector::const_iterator i=u.begin();
i!=u.end(); ++i ) {
const float& f = *i;
const size_t index = i-u.begin();
std::cerr << "values in my vector "
<< index
<< " "
<< f
<< std::endl;
}
return 0;
}
}}}
--
Summary: -O3 -Wformat=2 complains about floats written to ostream
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: myles at peakstreaminc dot com
GCC build triplet: gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
[Bug fortran/25358] vector assignment to assumed-size Cray Pointee error
--- Comment #6 from kargl at gcc dot gnu dot org 2006-04-01 00:07 --- Subject: Bug 25358 Author: kargl Date: Sat Apr 1 00:07:03 2006 New Revision: 112595 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112595 Log: 2006-03-31 Asher Langton <[EMAIL PROTECTED]> PR fortran/25358 *expr.c (gfc_check_assign): Allow cray pointee to be assumes-size. 2006-03-31 Asher Langton <[EMAIL PROTECTED]> PR fortran/25358 gfortran.dg/cray_pointers_6.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/cray_pointers_6.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25358
[Bug fortran/25358] vector assignment to assumed-size Cray Pointee error
--- Comment #7 from kargl at gcc dot gnu dot org 2006-04-01 00:12 --- Fixed on 4.1 and trunk. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25358
[Bug c++/26970] -O3 -Wformat=2 complains about floats written to ostream
--- Comment #1 from myles at peakstreaminc dot com 2006-04-01 00:14 --- Created an attachment (id=11177) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11177&action=view) code to reproduce the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
[Bug c++/26970] -O3 -Wformat=2 complains about floats written to ostream
--- Comment #2 from myles at peakstreaminc dot com 2006-04-01 00:19 --- g++ -O2 -Wformat=2 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
[Bug fortran/25358] vector assignment to assumed-size Cray Pointee error
--- Comment #8 from kargl at gcc dot gnu dot org 2006-04-01 00:26 --- Forgot to add the target milestone. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25358
[Bug libstdc++/26970] -O3 -Wformat=2 complains about floats written to ostream
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-01 00:40 --- The warning is a true warning in that libstdc++ code contains: const int __ret = std::snprintf(__out, __size, __fmt, __prec, __v); But I don't know if there is a way of fixing this unless making __convert_from_v out of line (which could slow down the compiler anyways). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|gcc version 3.4.3 20041212 | |(Red Hat 3.4.3-9.EL4) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
[Bug libstdc++/26970] -O3 -Wformat=2 complains about floats written to ostream
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-01 00:40 --- (In reply to comment #3) > __convert_from_v out of line (which could slow down the compiler anyways). s/compiler/program/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #3 from lucier at math dot purdue dot edu 2006-04-01 00:45 --- Subject: Re: Can't compile a 64-bit gcc OK, I'll try to give a bit more data and make a more intelligent comment. I tried to configure and build mainline with this command: /bin/rm -rf *; env CC='gcc -mcpu=970 -m64' ../configure --enable- checking=no --prefix=/pkgs/gcc-mainline --with-as=/usr/local/ odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ ld --enable-languages=c; make bootstrap BOOT_CFLAGS='-mcpu=970 -m64 - O2 -g' >& build.log and here are all the references to iconv in build.log: [lindv2:gcc/mainline/objdir64] lucier% grep iconv build.log checking for iconv... no, consider installing GNU libiconv checking for iconv.h... yes checking for iconv... no, consider installing GNU libiconv checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking for iconv... no, consider installing GNU libiconv checking for iconv... yes checking how to link with libiconv... -liconv checking for iconv declaration... extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for iconv.h... yes checking for iconv... yes checking how to link with libiconv... -liconv checking for iconv declaration... extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking for iconv... yes checking how to link with libiconv... -liconv checking for iconv declaration... extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); ./../intl/libintl.a -liconv -liconv ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture _libiconv, referenced from: _convert_using_iconv in libcpp.a(charset.o) _libiconv_close, referenced from: __cpp_destroy_iconv in libcpp.a(charset.o) _libiconv_open, referenced from: _init_iconv_desc in libcpp.a(charset.o) _libiconv_set_relocation_prefix, referenced from: and bootstrap fails with /Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc -B/Users/ lucier/programs/gcc/mainline/objdir64/./prev-gcc/ -B/pkgs/gcc- mainline/powerpc-apple-darwin8.5.0/bin/ -mcpu=970 -m64 -O2 -g -o makedepend \ makedepend.o libcpp.a ../libiberty/libiberty.a \ ./../intl/libintl.a -liconv -liconv ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture can't resolve symbols: When I configure and build 4.1.0 (release) with /bin/rm -rf *; env CC='gcc -mcpu=970 -m64' ../configure --prefix=/ pkgs/gcc-4.1.0 --with-as=/usr/local/odcctools-20060123/bin/as --with- ld=/usr/local/odcctools-20060123/bin/ld --enable-languages=c; make bootstrap BOOT_CFLAGS='-mcpu=970 -m64 -O2 -g' >& build.log I get the following references to iconv in build.log: [lindv2:gcc/gcc-4.1.0/objdir] lucier% !gr grep iconv build.log checking for iconv... no, consider installing GNU libiconv checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking for iconv... no, consider installing GNU libiconv checking for iconv.h... yes checking for iconv... no, consider installing GNU libiconv and no attempt is made to link libiconv into makedepend: gcc -mcpu=970 -m64 -I../../libcpp -I. -I../../libcpp/../include - I./../intl -I../../libcpp/include -g -O2 -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - Wmissing-format-attribute -pedantic -Wno-long-long -I../../libcpp - I. -I../../libcpp/../include -I./../intl -I../../libcpp/include -c - o makedepend.o -MT makedepend.o -MD -MP -MF .deps/makedepend.Po ../../ libcpp/makedepend.c gcc -mcpu=970 -m64 -g -O2 -o makedepend \ makedepend.o libcpp.a ../libiberty/libiberty.a \ ./../intl/libintl.a So it appears that configure in 4.1.0 realizes that the libiconv on powerpc-darwin-8.5.0 is not compatible with the gcc it's trying to build and doesn't try to link with it, while configure on mainline thinks libiconv is compatible (when it's not, since libiconv is 32 bit and we're trying to build a 64-bit gcc) and bootstrap fails when trying to link the 32-bit libiconv into the 32-bit makedepend. So I think that the configuration checks for iconv on mainline may be broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #4 from lucier at math dot purdue dot edu 2006-04-01 00:48 --- Subject: Re: Can't compile a 64-bit gcc On Mar 31, 2006, at 6:45 PM, lucier at math dot purdue dot edu wrote: > So it appears that configure in 4.1.0 realizes that the libiconv on > powerpc-darwin-8.5.0 is not compatible with the gcc it's trying to > build and doesn't try to link with it, while configure on mainline > thinks libiconv is compatible (when it's not, since libiconv is 32 > bit and we're trying to build a 64-bit gcc) and bootstrap fails when > trying to link the 32-bit libiconv into the 32-bit makedepend. Should be "64-bit makedepend" of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug tree-optimization/26969] [4.1/4.2 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-01 00:52 ---
Confirmed, reduced testcase:
void
ruby_re_compile_fastmap (char *fastmap, int options)
{
int j;
for (j = 0; j < (1 << 8); j++)
{
if (j != '\n' || (options & 4))
fastmap[j] = 1;
}
}
-
you can get the error with -O1 -funswitch-loops -ftree-vectorize
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|i686-pc-linux-gnu |
Last reconfirmed|-00-00 00:00:00 |2006-04-01 00:52:54
date||
Summary|ICE with -O3 -ftree-|[4.1/4.2 Regression] ICE
|vectorize |with -O1 -funswitch-loops -
||ftree-vectorize
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug target/26879] LibJava not compile under alpha
--- Comment #13 from rmathew at gcc dot gnu dot org 2006-04-01 07:57 --- As you can see from the backtrace, the problem is in "gcc/java/jcf-io.c" at line number 394 where we make a call to scandir(). I'm not an alpha-linux hacker, but I see that there's scandir64 and dirent64 and it could be that our assumptions about scandir/dirent in this code are not correct on alpha-linux. Unfortunately, this means that you'll have to wait for someone more familiar with alpha-linux to resolve this bug or try to resolve this problem yourself given the source code. I'm sorry that I cannot help you any further. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-01 07:57:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
