[Bug rtl-optimization/23567] [3.4/4.0/4.1 regression] if-conversion causes wrong code
--- Comment #9 from jakub at gcc dot gnu dot org 2005-11-07 08:02 --- Subject: Bug 23567 Author: jakub Date: Mon Nov 7 08:01:54 2005 New Revision: 106585 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106585 Log: PR rtl-optimization/23567 * ifcvt.c (noce_mem_write_may_trap_or_fault_p): New function. (noce_process_if_block): Don't do any optimizations except if (cond) x = x; if !set_b and write into orig_x may trap or fault. Remove the MEM_READONLY_P check. * gcc.c-torture/execute/20051104-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20051104-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
[Bug rtl-optimization/23567] [3.4/4.0/4.1 regression] if-conversion causes wrong code
--- Comment #10 from jakub at gcc dot gnu dot org 2005-11-07 08:28 --- Subject: Bug 23567 Author: jakub Date: Mon Nov 7 08:28:01 2005 New Revision: 106586 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106586 Log: PR rtl-optimization/23567 * ifcvt.c (noce_mem_write_may_trap_or_fault_p): New function. (noce_process_if_block): Don't do any optimizations except if (cond) x = x; if !set_b and write into orig_x may trap or fault. * gcc.c-torture/execute/20051104-1.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/20051104-1.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/ifcvt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
[Bug other/24692] Atomic builtins for v3
--- Comment #7 from rth at gcc dot gnu dot org 2005-11-07 08:48 --- I stand by my statement. This cannot go in libgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug other/24692] Atomic builtins for v3
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-07 10:16 --- Paolo, the only viable way to get these inlined looks like a libstdc++ configure-time choice to say --disable-i386-support or sth like that. You then build libstdc++ against the atomic builtin primitives and at application build-time either try falling back with preprocessor stuff rth suggested, or don't do it and fail either at compile-time or later (maybe) at runtime with some SIGILL or whatever you'll get. Supporting different architectures and inlining at the same time is not possible (well, apart from fixup by binary-patching at program startup, like the kernel does (or did?), of course ;)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug other/24692] Atomic builtins for v3
--- Comment #9 from pcarlini at suse dot de 2005-11-07 10:23 --- (In reply to comment #8) Paolo, the only viable way to get these inlined looks like a libstdc++ configure-time choice to say --disable-i386-support or sth like that. You then build libstdc++ against the atomic builtin primitives and at application build-time either try falling back with preprocessor stuff rth suggested, or don't do it and fail either at compile-time or later (maybe) at runtime with some SIGILL or whatever you'll get. I would certainly be in favor of something like that, it's a real pity that the vetust i386 blocks us in using the new builtins and inlining the atomic operations. I'm still convinced that something more general would be better, but I can (rather easily) implement Rth idea too, otherwise. Of course it's still open the task of preparing inline assembly implementing the various atomic operations for arches which don't have (for one reason or another) the builtins... Supporting different architectures and inlining at the same time is not possible (well, apart from fixup by binary-patching at program startup, like the kernel does (or did?), of course ;)) Please provide a detailed scenario, again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #7 from thebohemian at gmx dot net 2005-11-07 10:34 --- Created an attachment (id=10161) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10161action=view) preliminary patch - just for review As andrew suggested I tried preparing a closure that is stored in the atable and will be called when the static method of the missing class is invoked. Unfortunately gcj crashes when entering ffi_call in link.cc:743. I assume that this has something to do with the way I am allocating memory for the ffi structures cif and closure. I just learned about ffi and tried what I am doing in gcj in a tutorial app where it works fine. Can somebody help me what and tell me what I am doing wrong here? -- thebohemian at gmx dot net changed: What|Removed |Added Attachment #10153|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #27 from bonzini at gcc dot gnu dot org 2005-11-07 10:39 --- Subject: Bug 24230 Author: bonzini Date: Mon Nov 7 10:39:36 2005 New Revision: 106588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106588 Log: 2005-11-07 Paolo Bonzini [EMAIL PROTECTED] PR target/24230 * config/rs6000/rs6000.c (easy_vector_splat_const, easy_vector_same, gen_easy_vector_constant_add_self): Delete. (vspltis_constant, easy_altivec_constant, gen_easy_altivec_constant): New. (output_vec_const_move): Use gen_easy_altivec_constant. (rs6000_expand_vector_init): Do not emit a set of a VEC_DUPLICATE. * config/rs6000/predicates.md (easy_vector_constant): Reorganize tests. (easy_vector_constant_add_self): Rewritten. * config/rs6000/rs6000-protos.h (easy_vector_splat_const, easy_vector_same, gen_easy_vector_constant_add_self): Remove prototype. (easy_altivec_constant, gen_easy_altivec_constant): Add prototype. testsuite: 2005-11-07 Paolo Bonzini [EMAIL PROTECTED] PR target/24230 * gcc.target/powerpc/altivec-consts.c, gcc.target/powerpc/altivec-splat.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/powerpc/altivec-consts.c trunk/gcc/testsuite/gcc.target/powerpc/altivec-splat.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/altivec.md trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #8 from aph at gcc dot gnu dot org 2005-11-07 10:40 --- It's not possibe from this description to tell when this problem occurs, nor which kind of error it is. What does crash mean? When does it occur? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #28 from bonzini at gcc dot gnu dot org 2005-11-07 10:41 --- patch committed -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug libgomp/24703] New: Unable to compile OpenMP program with omp parallel for schedule(dynamic) directive
Error while compiling an OpenMP code that uses schedule(dynamic) clause:
$ gcc -fopenmp -c -lgomp ompparfor.c
ompparfor.c: In function â:
ompparfor.c:6: error: â undeclared (first use in this function)
ompparfor.c:6: error: (Each undeclared identifier is reported only once
ompparfor.c:6: error: for each function it appears in.)
ompparfor.c:6: error: â undeclared (first use in this function)
ompparfor.c:7: error: â undeclared (first use in this function)
ompparfor.c:8: internal compiler error: tree check: expected class â, have â
(error_mark) in
c_finish_omp_for, at c-omp.c:199
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
The source code (snippet, reproducible and compilable):
void work(int);
int work_param;
int sphinx_omp_thread_count;
int schedule_loop_cap;
int measure_omp_parallel_for_dynamic (void)
{
int j;
#pragma omp parallel for schedule(dynamic)
for(j=0; j sphinx_omp_thread_count * schedule_loop_cap; j++) {
work(work_param);
}
return 0;
}
--
Summary: Unable to compile OpenMP program with omp parallel for
schedule(dynamic) directive
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laksono at cs dot uh dot edu
GCC build triplet: Linux 2.6.9-22.EL #1 SMP Wed Oct 5 15:20:11 EEST 2005
ia64 ia64
GCC host triplet: Linux 2.6.9-22.EL #1 SMP Wed Oct 5 15:20:11 EEST 2005
ia64 ia64
GCC target triplet: Linux 2.6.9-22.EL #1 SMP Wed Oct 5 15:20:11 EEST 2005
ia64 ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24703
[Bug libstdc++/24704] New: __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
__gnu_cxx::__exchange_and_add shows up in profiles of the PowerDNS recursor, which is single threaded. I'm somewhat amazed this is an out-of-line function (there are 40 cycles to be gained by inlining it, and this function gets called a lot), but I'm worried more about the 1000 cycle overhead even in a single-threaded program! I think it would be good to teach std::string to use a non-atomic exchange_and_add (or even just 'add') for non-REENTRANT applications, plus it would be good to be able to inline the function, but I understand this is of far smaller importance. The code exhibiting prominent profiled use of __gnu_cxx::__exchange_and_add can be found via the repository described on http://wiki.powerdn.somc. Thanks! -- Summary: __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ahu at ds9a dot nl GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug c/24599] [4.0 regression] Overflow for true value
--- Comment #7 from bonzini at gcc dot gnu dot org 2005-11-07 12:14 --- patch committed to trunk, it's a bit different for 4.0 branch so it'll take a while to test it. -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.3 4.1.0 |4.0.3 Known to work|3.4.0 |3.4.0 4.1.0 Summary|[4.0/4.1 regression]|[4.0 regression] Overflow |Overflow for true value |for true value http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #1 from ahu at ds9a dot nl 2005-11-07 12:39 --- that would be http://wiki.powerdns.com - not sure how I mistyped that. Also, the application in question is rather string-happy, which is probably why the exchange_and_add thing shows up so much. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #9 from thebohemian at gmx dot net 2005-11-07 12:51 --- Ok, more details: With my patch applied I run the test application in lazylinker.tar.bz2. Set up the variable CLASSPATH to point to lib/java/lazylinker.jar, start gdb with gij, set a breakpoint at link.cc:743 and run the interpreter with -Dgnu.gcj.precompiled.db.path=lazylinker.gcjdb test.linker.LazyLinker invokeStaticMethod. Then step into ffi_call. When it reaches the first 'call' instruction in the assembler code (SysV.S:55) it crashes. Here is a backtrace: #0 0xb6d2f4dc in memcpy () from /lib/tls/libc.so.6 #1 0xb79d788c in ffi_prep_args (stack=0xbff41224 \200x\016, ecif=0xbff41258) at ../../../gcc/libffi/src/x86/ffi.c:108 #2 0xb79d7921 in ffi_call_SYSV () at ../../../gcc/libffi/src/x86/sysv.S:55 #3 0x00028f00 in ?? () #4 0x in ?? () #5 0x0001 in ?? () #6 0x0001 in ?? () #7 0xb7f45fb4 in ?? () from /lib/ld-linux.so.2 #8 0x06f9 in ?? () #9 0x08057320 in ?? () #10 0xbff41300 in ?? () #11 0xbff412a0 in ?? () #12 0x08059e50 in ?? () #13 0x08059ec8 in ?? () #14 0xb6e1874e in test::linker::LazyLinker::main () from /home/rob/devel/test/lazy-linker/lib/bc/lazylinker.so #15 0xbff41488 in ?? () #16 0xb6e1826a in test.linker.LazyLinker.main(java.lang.String[]) () from /home/rob/devel/test/lazy-linker/lib/bc/lazylinker.so Previous frame inner to this frame (corrupt stack?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug fortran/24549] ICE with invalid pseudo-declaration statement
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-07 12:58 --- I'm marking this ice-on-invalid-code, as it is not valid Fortran 95 and the bug is unrelated to the use of IMPORT, the following ICEs the same way: module gfcbug29_import interface subroutine foo (x) something :: dp real (kind=dp) :: x end subroutine foo end interface end module gfcbug29_import -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Keywords||ice-on-invalid-code Summary|gfortran: IMPORT of f2003 |ICE with invalid pseudo- |not yet implemented, ICE|declaration statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24549
[Bug fortran/24409] ICE on module name vs dummy argument name
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-07 13:07 --- (In reply to comment #3) Thank you Salvatore and Andrew. The proposed patch is about to be posted on the fortran and gcc-patches list. I just have a couple more minutes of testing other, completely off-the-wall cases before submitting. Did this patch ever get posted? -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org, ||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24409
[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe
--- Comment #1 from tobi at gcc dot gnu dot org 2005-11-07 13:09 --- Is this still the case? No other platform seems to be affected. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24342
[Bug fortran/24705] New: ICE on asterisk char-len-param-value on result
character (6) :: c c = f1 () if (c .ne. 'abcdef') call abort contains function f1 () character (*) :: f1 f1 = 'abcdef' end function f1 end causes ICE, while it should be diagnosed as error. -- Summary: ICE on asterisk char-len-param-value on result Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24705
[Bug rtl-optimization/23567] [3.4/4.0/4.1 regression] if-conversion causes wrong code
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-07 13:17 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
[Bug fortran/24706] New: Accepts non-constant length arrays in derived types
subroutine foo (n) integer :: n type bar integer :: x (n) end type bar type (bar) :: q q%x = 6 end subroutine foo should be rejected. If an array in derived type doesn't have POINTER attribute, it shall be explicit shape with constant bounds, if it has POINTER attribute, it must be deferred shape array. -- Summary: Accepts non-constant length arrays in derived types Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24706
[Bug c++/17256] [3.4/4.0 Regression] undefined but used static or inline functions should be diagnosed
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-07 13:17 --- Fixed at least on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.3.4 3.4.0 4.0.0 4.1.0 |3.3.4 3.4.0 4.0.0 Known to work|2.95.3 |2.95.3 4.1.0 Summary|[3.4/4.0/4.1 Regression]|[3.4/4.0 Regression] |undefined but used static or|undefined but used static or |inline functions should be |inline functions should be |diagnosed |diagnosed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
[Bug target/19340] Compilation SEGFAULTs with -O1 -fschedule-insns2 -fsched2-use-traces on an x86 architecture.
--- Comment #4 from uros at kss-loka dot si 2005-11-07 13:20 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00438.html -- uros at kss-loka dot si changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00438.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-11-04 15:32:10 |2005-11-07 13:20:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19340
[Bug fortran/24705] ICE on assumed length charactor result
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 13:25 --- Confirmed. Blocks PR 15809 because a related testcase is referenced in comment #13. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||15809 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-07 13:25:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24705
[Bug fortran/24706] Accepts non-constant length arrays in derived types
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 13:27 --- 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 |2005-11-07 13:27:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24706
[Bug c++/24702] Koenig found functoid ref, but cannot be used as a function
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 13:36 --- Actually IIRC Koenig lookup only finds functions and not variables. If that is the case we have two issues here. One is we accept invalid and another is that error message is wrong. Note ICC rejects this: t.cc(26): error: identifier dummyFunct is undefined std::coutdummyFunct(d) = dummyFunct(d)std::endl; // fails with 3.4 ^ t.cc(28): error: identifier myDummyFunct is undefined std::coutmyDummyFunct(d) = myDummyFunct(d)std::endl; ^ t.cc(29): error: identifier mymyDummyFunct is undefined std::coutmymyDummyFunct(d) = mymyDummyFunct(d)std::endl; // fails ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24702
[Bug c++/24707] New: tradcpp0: output filename specified twice
This problem occured when compiling linux-2.6.14-mm1 tree on a Red Hat Linux release 9 with a gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5). The compilation of a linux-2.6.14 tree is ok. Here is the message (I added -v option in arch/i386/kernel/Makefile): $ make O=/home/guill/build/k2614-mm1 bzImage Using /home/guill/src/linux-2.6.14-mm1 as source for kernel GEN/home/guill/build/k2614-mm1/Makefile CHK include/linux/version.h SPLIT include/linux/autoconf.h - include/config/* CHK include/linux/compile.h CHK usr/initramfs_list AS arch/i386/kernel/entry.o Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/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 --host=i386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/tradcpp0 -lang-asm -nostdinc -v -Iinclude -Iinclude2 -I/home/guill/src/linux-2.6.14-mm1/include -I/home/guill/src/linux-2.6.14-mm1/include/asm-i386/mach-default -Iinclude/asm-i386/mach-default -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ -D__KERNEL__ -D__ASSEMBLY__ -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -imacros include/linux/autoconf.h -MD arch/i386/kernel/.entry.o.d /home/guill/src/linux-2.6.14-mm1/arch/i386/kernel/entry.S -o /tmp/ccnBxfhG.s GNU traditional CPP version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/tradcpp0: output filename specified twice make[2]: *** [arch/i386/kernel/entry.o] Error 1 make[1]: *** [arch/i386/kernel] Error 2 make: *** [bzImage] Error 2 I have another computer with gcc installed (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) and the problem doesn't occur. -- Summary: tradcpp0: output filename specified twice Product: gcc Version: 3.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: guillaume dot thouvenin at polymtl dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24707
[Bug regression/24709] New: 4.1.0 HEAD crashes with enable-checking on huge switch statement
When running g++ -O1 -c t3.cc on the attached preprocessed C++ source file with 4.1.0 HEAD as of 2005-11-07 with enable-checking I get the error message as attached. The problem does neither happen with diable-checking nor with -O0. It does happen with enable-checking and all optimization levels greater or equal -O1. Switching all optimizations manually on that are mentioned within the info page as -O1 optimizations doesn't trigger the problem as well but running with -O1 and then switching all optimizations off that are mentioned for -O1 in the info page does still trigger the problem thus the cause of the problem must be something that -O1 switches on but not the things mentioned in the info page. -- Summary: 4.1.0 HEAD crashes with enable-checking on huge switch statement Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rschiele at uni-mannheim dot de GCC build triplet: i586-suse-linux GCC host triplet: i586-suse-linux GCC target triplet: i586-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug regression/24709] 4.1.0 HEAD crashes with enable-checking on huge switch statement
--- Comment #1 from rschiele at uni-mannheim dot de 2005-11-07 14:24 --- Created an attachment (id=10162) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10162action=view) gzipped preprocessed source code the preprocessed source code that triggers the problem --- yes, it is large and ugly code because it is generated automatically :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug regression/24709] 4.1.0 HEAD crashes with enable-checking on huge switch statement
--- Comment #2 from rschiele at uni-mannheim dot de 2005-11-07 14:25 --- Created an attachment (id=10163) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10163action=view) gzipped error message the gzipped error message when building with -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #10 from green at redhat dot com 2005-11-07 14:47 --- This patch seems overly complicated to me. I don't think we need the trampoline function and the ffi_call. Since we're just planning on throwing an exception, it seems like you should just be able to pass the class name in as a closure argument (cast as a ffi_cif?) and throw the exception directly, dispensing entirely with the ffi_cif and all the other interpreter-native call support. Let me know if I'm not describing this clearly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug fortran/18197] bus error on returning from a function
--- Comment #5 from tobi at gcc dot gnu dot org 2005-11-07 14:49 --- While the original problem seems to have been fixed, we have a regression here: if we comment out the line marked as this works everything compiles fine and we get an executable that works (doesn't segfault), if we comment out the line this doesn't instead, the compiler triggers the assertion Andrew pointed to. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18197
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #11 from aph at gcc dot gnu dot org 2005-11-07 14:52 --- You're not describing this clearly. :-) We need to point the execution vector at a piece of code that throws an exception with the appropriate args. Now, how should we do that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug c++/24711] New: Misleading names for template parameters in diagnostics
The following code snippet produces an incorrect error message (since gcc 3.0):
==
templatetypename T struct A {};
templatetypename U void foo(AU);
templatetypename T AT bar() { x; }
template Aint barint();
==
The error message reads:
bug.cc: In function 'AU bar()':
bug.cc:5: error: 'x' was not declared in this scope
The U in 'AU bar()' is wrong here.
This is related to PR23293.
--
Summary: Misleading names for template parameters in diagnostics
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 23293
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24711
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #12 from green at redhat dot com 2005-11-07 15:06 --- (In reply to comment #11) You're not describing this clearly. :-) We need to point the execution vector at a piece of code that throws an exception with the appropriate args. Now, how should we do that? The closure mechanism was specifically designed for when you want to call interpreted code. We don't want to do this here; we just want to throw an exception with the right argument (stored in the closure object). The current patch uses the closure mechanism to call the trampoline, which in turn uses the ffi_call mechanism to call the exception throwing function. But we don't need to use ffi_call here, we can just call the exception throwing function directly. Then you'll realize that these functions don't need to be separate at all. Then you'll realize that you don't need to bother setting up the ffi_cif - all you need is the exception argument. Does this help explain? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug driver/24707] tradcpp0: output filename specified twice
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 15:09 --- All I can say for this one is that was fixed in 3.3.6 as 3.2.x is no longer being updated (even 3.3.6 was the last release of 3.3.x). If you need support for 3.2.x with the compiler version you have, you should write to RedHat as it is their version. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |driver Resolution||FIXED Target Milestone|--- |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24707
[Bug fortran/24710] New: gfortran - fails to build on Mac OSX -10.4.3
I did a fresh down of gfortran this morning and the build fails at - make \ CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -fno-common \ CONFIG_H=tconfig.h auto-host.h ../.././gcc/../include/ansidecl.h TM_H=tm.h options.h ../.././gcc/config/rs6000/rs6000.h ../.././gcc/config/darwin.h ../.././gcc/config/rs6000/darwin.h ../.././gcc/config/rs6000/darwin8.h ../.././gcc/defaults.h insn-constants.h insn-flags.h options.h \ INCLUDES=-I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I./../intl -I../.././gcc/../libcpp/include \ MAKEOVERRIDES= \ -f libgcc.mk all /Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.2.0/gcc/xgcc -B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.2.0/gcc/ -B/Users/dir/gfortran/powerpc-apple-darwin8.2.0/bin/ -B/Users/dir/gfortran/powerpc-apple-darwin8.2.0/lib/ -isystem /Users/dir/gfortran/powerpc-apple-darwin8.2.0/include -isystem /Users/dir/gfortran/powerpc-apple-darwin8.2.0/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Wa,-force_cpusubtype_ALL -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib -nodefaultlibs -Wl,-install_name,/Users/dir/gfortran/lib/libgcc_s`if test . != . ; then echo _. ; fi`.1.dylib -Wl,-flat_namespace -o libgcc_s`if test . != . ; then echo _. ; fi`.1.dylib.tmp -Wl,-exported_symbols_list,libgcc/./libgcc.map -compatibility_version 1 -current_version 1.0 libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./darwin-tramp_s.o libgcc/./darwin-ldouble_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde-darwin_s.o libgcc/./unwind-sjlj_s.o libgcc/./unwind-c_s.o libgcc/./darwin-fallback_s.o -lc if [ -f libgcc_s`if test . != . ; then echo _. ; fi`.1.dylib ]; then mv -f libgcc_s`if test . != . ; then echo _. ; fi`.1.dylib libgcc_s`if test . != . ; then echo _. ; fi`.1.dylib.backup; else true; fi mv libgcc_s`if test . != . ; then echo _. ; fi`.1.dylib.tmp libgcc_s`if test . != . ; then echo _. ; fi`.1.dylib /Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.2.0/gcc/xgcc -B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.2.0/gcc/ -B/Users/dir/gfortran/powerpc-apple-darwin8.2.0/bin/ -B/Users/dir/gfortran/powerpc-apple-darwin8.2.0/lib/ -isystem /Users/dir/gfortran/powerpc-apple-darwin8.2.0/include -isystem /Users/dir/gfortran/powerpc-apple-darwin8.2.0/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Wa,-force_cpusubtype_ALL -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib -nodefaultlibs -Wl,-install_name,/Users/dir/gfortran/lib/libgcc_s`if test ppc64 != . ; then echo _ppc64 ; fi`.1.dylib -Wl,-flat_namespace -o libgcc_s`if test ppc64 != . ; then echo _ppc64 ; fi`.1.dylib.tmp -Wl,-exported_symbols_list,libgcc/ppc64/libgcc.map -compatibility_version 1 -current_version 1.0 -m64 libgcc/ppc64/_muldi3_s.o libgcc/ppc64/_negdi2_s.o libgcc/ppc64/_lshrdi3_s.o libgcc/ppc64/_ashldi3_s.o libgcc/ppc64/_ashrdi3_s.o libgcc/ppc64/_cmpdi2_s.o libgcc/ppc64/_ucmpdi2_s.o libgcc/ppc64/_floatdidf_s.o libgcc/ppc64/_floatdisf_s.o libgcc/ppc64/_fixunsdfsi_s.o libgcc/ppc64/_fixunssfsi_s.o libgcc/ppc64/_fixunsdfdi_s.o libgcc/ppc64/_fixdfdi_s.o libgcc/ppc64/_fixunssfdi_s.o libgcc/ppc64/_fixsfdi_s.o libgcc/ppc64/_fixxfdi_s.o
[Bug tree-optimization/24709] [4.1 Regresssion] 4.1.0 HEAD crashes with enable-checking on huge switch statement
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Component|regression |tree-optimization Keywords||ice-on-valid-code Summary|4.1.0 HEAD crashes with |[4.1 Regresssion] 4.1.0 HEAD |enable-checking on huge |crashes with enable-checking |switch statement|on huge switch statement Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug c++/24711] Misleading names for template parameters in diagnostics
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 15:13 --- Isn't this really PR 99? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24711
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #2 from neroden at gcc dot gnu dot org 2005-11-07 15:15 --- True, enhancement request. -- neroden at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-07 15:15:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 15:16 --- Are you building in a clean object directory? If not can you try that as from the looks of it, you configured for 10.4.2 and not 10.4.3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug tree-optimization/24709] [4.1 Regresssion] 4.1.0 HEAD crashes with enable-checking on huge switch statement
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-07 15:26 --- Reducing (which means I can reproduce it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug libstdc++/24712] New: Accidental ABI change between 4.0.1 and 4.0.2?
This is Debian bug #336114: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336114 I don't claim to be able to understand it all, but apparently (for example) kdebase built with 4.0.2 doesn't work with arts built with 4.0.1. Symbol changes in arts between building with 4.0.1 and pre-4.0.2 look like the following: --- old +++ new @@ -42,7 +42,7 @@ T lt_dlsetsearchpath T lt_dlsym T arts_strdup_printf(char const*, ...) -V guard variable for __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true::_S_get_pool()::_S_pool +V guard variable for __gnu_cxx::__common_pool__gnu_cxx::__pool, true::_S_get_pool()::_S_pool T Arts::AuthAccept::readType(Arts::Buffer) T Arts::AuthAccept::operator=(Arts::AuthAccept const) T Arts::AuthAccept::AuthAccept(Arts::AuthAccept const) @@ -1215,10 +1215,9 @@ W __gnu_cxx::__mt_allocstd::_Rb_tree_nodestd::pairstd::string const, std::string , __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::allocate(unsigned int, void const*) W __gnu_cxx::__mt_allocstd::_Rb_tree_nodestd::pairstd::string const, std::vectorstd::string, std::allocatorstd::string , __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::deallocate(std::_Rb_tree_nodestd::pairstd::string const, std::vectorstd::string, std::allocatorstd::string *, unsigned int) W __gnu_cxx::__mt_allocstd::_Rb_tree_nodestd::pairstd::string const, std::vectorstd::string, std::allocatorstd::string , __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::allocate(unsigned int, void const*) -W __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true::_S_get_pool() -W __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true::_S_initialize() -W __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true::_S_initialize_once() -W __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true::_S_destroy_thread_key(void*) +W __gnu_cxx::__common_pool__gnu_cxx::__pool, true::_S_get_pool() +W __gnu_cxx::__common_pool_base__gnu_cxx::__pool, true::_S_initialize() +W __gnu_cxx::__common_pool_base__gnu_cxx::__pool, true::_S_initialize_once() T Arts::AnyRefBase::type() const T Arts::AnyRefBase::_read(Arts::Buffer*) const T Arts::AnyRefBase::_write(Arts::Buffer*) const @@ -1317,7 +1316,6 @@ W std::_Deque_baseArts::IOWatchFD*, std::allocatorArts::IOWatchFD* ::_M_destroy_nodes(Arts::IOWatchFD***, Arts::IOWatchFD***) W std::_Deque_baseArts::IOWatchFD*, std::allocatorArts::IOWatchFD* ::_M_initialize_map(unsigned int) W std::_Deque_baseArts::IOWatchFD*, std::allocatorArts::IOWatchFD* ::~_Deque_base() -W std::_Deque_iteratorArts::Notification, Arts::Notification const, Arts::Notification const*::operator+=(int) W std::_Deque_iteratorArts::Notification, Arts::Notification, Arts::Notification*::operator+=(int) W std::mapstd::string, Arts::TypeIdentification, std::lessstd::string, std::allocatorstd::pairstd::string const, Arts::TypeIdentification ::operator[](std::string const) W std::listArts::NamedStoreArts::Object::Element, std::allocatorArts::NamedStoreArts::Object::Element ::erase(std::_List_iteratorArts::NamedStoreArts::Object::Element) @@ -1461,49 +1459,6 @@ W void std::__uninitialized_fill_n_aux__gnu_cxx::__normal_iteratorArts::ParamDef*, std::vectorArts::ParamDef, std::allocatorArts::ParamDef , unsigned int, Arts::ParamDef(__gnu_cxx::__normal_iteratorArts::ParamDef*, std::vectorArts::ParamDef, std::allocatorArts::ParamDef , unsigned int, Arts::ParamDef const, __false_type) W void std::__uninitialized_fill_n_auxArts::ParamDef*, unsigned int, Arts::ParamDef(Arts::ParamDef*, unsigned int, Arts::ParamDef const, __false_type) W void std::fill__gnu_cxx::__normal_iteratorArts::ParamDef*, std::vectorArts::ParamDef, std::allocatorArts::ParamDef , Arts::ParamDef(__gnu_cxx::__normal_iteratorArts::ParamDef*, std::vectorArts::ParamDef, std::allocatorArts::ParamDef , __gnu_cxx::__normal_iteratorArts::ParamDef*, std::vectorArts::ParamDef, std::allocatorArts::ParamDef , Arts::ParamDef const) -W void std::_Destroy__gnu_cxx::__normal_iteratorfloat*, std::vectorfloat, std::allocatorfloat , std::allocatorfloat (__gnu_cxx::__normal_iteratorfloat*, std::vectorfloat, std::allocatorfloat , __gnu_cxx::__normal_iteratorfloat*, std::vectorfloat, std::allocatorfloat , std::allocatorfloat) -W void std::_Destroy__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , std::allocatorunsigned char) -W void std::_Destroy__gnu_cxx::__normal_iteratorlong*, std::vectorlong, std::allocatorlong , std::allocatorlong (__gnu_cxx::__normal_iteratorlong*, std::vectorlong, std::allocatorlong , __gnu_cxx::__normal_iteratorlong*, std::vectorlong, std::allocatorlong , std::allocatorlong) -W void std::_Destroy__gnu_cxx::__normal_iteratorArts::TraderEntry*, std::vectorArts::TraderEntry,
[Bug libstdc++/24712] [4.0 Regression] Accidental ABI change between 4.0.1 and 4.0.2?
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 15:35 --- This looks like it was caused by the patches to fix the following PRs: PR libstdc++/19265 PR libstdc++/22309 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |critical Keywords||ABI, wrong-code Summary|Accidental ABI change |[4.0 Regression] Accidental |between 4.0.1 and 4.0.2?|ABI change between 4.0.1 and ||4.0.2? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24712
[Bug c++/24711] Misleading names for template parameters in diagnostics
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-11-07 15:38 --- You're probably right, Andrew. This looks like a duplicate of PR99. *** This bug has been marked as a duplicate of 99 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24711
[Bug c++/99] Bug in template type in error message.
--- Comment #13 from reichelt at gcc dot gnu dot org 2005-11-07 15:38 --- *** Bug 24711 has been marked as a duplicate of this bug. *** -- 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=99
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #2 from dir at lanl dot gov 2005-11-07 16:11 --- It failed under 10.4.2 from a completely new down load - then I upgraded to 10.4.3 to see if that would help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug driver/20425] -print-search-dirs doesn't honor mutil-os/multilib settings
--- Comment #3 from olh at suse dot de 2005-11-07 16:17 --- ping -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[Bug rtl-optimization/24713] New: objc/execute/exceptions/foward-1.m fails on sh-elf with -O3
See: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00320.html -- Summary: objc/execute/exceptions/foward-1.m fails on sh-elf with -O3 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code, EH Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24713
[Bug target/24714] New: objc/execute/bf-10.m and others fail on sh64-elf
See: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00317.html This looks like libobjc and objc not agreeing on the layout of a class. -- Summary: objc/execute/bf-10.m and others fail on sh64-elf Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: sh64-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24714
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #17 from r dot emrich at de dot tecosim dot com 2005-11-07 16:25 --- Sorry, for the delay. I had a machine fault on the weekend. So, I'm trying the snapshot from 5th of november now! Look's good so far, already in stage 2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #3 from dir at lanl dot gov 2005-11-07 16:47 ---
Here is another try from another complete download under 10.4.3 -
# When builting multilibbed target libraries, all the required
# When builting multilibbed target libraries, all the required
# libraries are expected to exist in the multilib directory.
# libraries are expected to exist in the multilib directory.
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d'` ; \
for mlib in $MLIBS ; do \
rm -f ${mlib}/libgcc_s.10.4.dylib || exit 1 ; \
ln -s ../libgcc_s.10.4.dylib ${mlib}/libgcc_s.10.4.dylib || exit 1 ; \
done
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d'` ; \
for mlib in $MLIBS ; do \
rm -f ${mlib}/libgcc_s.10.5.dylib || exit 1 ; \
ln -s ../libgcc_s.10.5.dylib ${mlib}/libgcc_s.10.5.dylib || exit 1 ; \
done
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d' -e 's/^/_/'` ; \
for mlib in '' $MLIBS ; do \
strip -o libgcc_s.10.4.dylib_T${mlib} \
-s ../.././gcc/config/rs6000/darwin-libgcc.10.4.ver -c -u \
libgcc_s${mlib}.1.dylib || exit 1 ; \
done
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d' -e 's/^/_/'` ; \
for mlib in '' $MLIBS ; do \
strip -o libgcc_s.10.5.dylib_T${mlib} \
-s ../.././gcc/config/rs6000/darwin-libgcc.10.5.ver -c -u \
libgcc_s${mlib}.1.dylib || exit 1 ; \
done
Could Not Open (-o) To Read
Could Not Open (-o) To Read
make[2]: *** [libgcc_s.10.5.dylib] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [libgcc_s.10.4.dylib] Error 1
rm cpp.pod gfortran.pod fsf-funding.pod gpl.pod gcc.pod gcov.pod gfdl.pod
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #4 from andreast at gcc dot gnu dot org 2005-11-07 16:54 --- On which target do you build? G4/5? What are the config options you use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug libstdc++/24712] [4.0 Regression] Accidental ABI change between 4.0.1 and 4.0.2?
--- Comment #2 from pcarlini at suse dot de 2005-11-07 16:59 --- I have to add a comment: all those crashing KDE applications (I looked at the KDE PRs) are evidently using mt_allocator. Now, mt_allocator is not the alloc which FSF gcc4.0.x uses by default, the only one for which ABI guarantees are provided, also about compatibility with gcc3.4.x. I gather therefore that Debian is building GCC passing --enable-libstdcxx-allocator=mt, something absolutely not obvious and not trivial in its consequences. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24712
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #3 from ahu at ds9a dot nl 2005-11-07 17:00 --- I've now verified that even when the entire compiler is compiled with --enable-threads=single, the resulting libstdc++ does the full 'lock; xadd' thing in __exchange_and_add, which I consider a bug (and more importantly, so does pinskia). -- ahu at ds9a dot nl changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-07 17:05 --- Linking to the orginal thread: http://gcc.gnu.org/ml/libstdc++/2004-02/msg00372.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] [4.0/4.1 Regression] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-07 17:06 --- This is a regression too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|__gnu_cxx::__exchange_and_ad|[4.0/4.1 Regression] |d is out of line and called |__gnu_cxx::__exchange_and_ad |even for single threaded|d is out of line and called |applications using |even for single threaded |std::string |applications using ||std::string Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug c/24703] [GOMP] Unable to compile OpenMP program with omp parallel for schedule(dynamic) directive
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Severity|blocker |normal Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-07 17:06:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24703
[Bug libstdc++/24704] [3.4/4.0/4.1 Regression] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #6 from pcarlini at suse dot de 2005-11-07 17:07 --- (In reply to comment #3) I've now verified that even when the entire compiler is compiled with --enable-threads=single, the resulting libstdc++ does the full 'lock; xadd' thing in __exchange_and_add, This is well known, if you only cared to ask (sorry ;) If you look at the sources it's clear that nothing about threads changes the choice of the atomicity.h. I agree however, that it's a very good idea to have that configuration option influencing also the atomicity things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #14 from steven at gcc dot gnu dot org 2005-11-07 17:19 --- As an interesting data point: Intel's ICC 8.0 does what GCC 3.3 and earlier do, but it seems that ICC 9.0 follow GCC 3.4 and later... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug libstdc++/24704] [3.4/4.0/4.1 Regression] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-07 17:32 --- Actually the real issue is not even here and there is no performance problems with the out of line/non threaded calls but the real issue is that we are just calling them too much. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24715] New: __exchange_and_add is called too much
__gnu_cxx::__exchange_and_add shows up in profiles of the PowerDNS recursor. http://wiki.powerdns.com The issue here is that __exchange_and_add is called too much and not it is inlined. Now someone should go and figure out why this is called too much (I don't have a profile). -- Summary: __exchange_and_add is called too much Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24715
[Bug libstdc++/24704] [3.4/4.0/4.1 Regression] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #8 from pcarlini at suse dot de 2005-11-07 17:36 --- (In reply to comment #7) Actually the real issue is not even here and there is no performance problems with the out of line/non threaded calls but the real issue is that we are just calling them too much. Andrew, in some sense you are right, given the current reference-counted nature of std::string. However, let's not close this PR: submitter has a point that the user should be enabled to disable the use of atomics when configuring for single thread. I leave to you the exact categorization... Thanks. -- pcarlini at suse dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] [3.4/4.0/4.1 Regression] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-07 17:38 --- (In reply to comment #8) Andrew, in some sense you are right, given the current reference-counted nature of std::string. However, let's not close this PR: submitter has a point that the user should be enabled to disable the use of atomics when configuring for single thread. I leave to you the exact categorization... Thanks. I should note I closed this based on a conversation with the submitter. I also filed PR 24715 for the real issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24715] __exchange_and_add is called too much
--- Comment #1 from pcarlini at suse dot de 2005-11-07 17:38 --- .. on the other hand, I think we should close this one, sorry ;) As long as we have a reference counted string and the user cannot disable the use of atomic operations when single threaded, there isn't much we can do. Agreed? -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24715
[Bug c++/24680] Invalid template code accepted
--- Comment #17 from rnewman at compubrite dot com 2005-11-07 17:39 --- I concede the argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24680
[Bug libstdc++/24715] __exchange_and_add is called too much
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-07 17:39 --- I actually disagree with that. We really need more info (I don't have the profiles to see why we are calling this too much but we really need to figure it out). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24715
[Bug libstdc++/24715] __exchange_and_add is called too much
--- Comment #3 from pcarlini at suse dot de 2005-11-07 17:41 --- (In reply to comment #2) I actually disagree with that. We really need more info (I don't have the profiles to see why we are calling this too much but we really need to figure it out). Whatever... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24715
[Bug bootstrap/24631] SIGBUS during bootstrap
--- Comment #2 from rwcrocombe at raytheon dot com 2005-11-07 17:59 --- Bootstrapping 4.0.2 via older 3.4.4 appears to work. I'll give the test suite a whirl if I get the chance. Thanks for the suggestion (I was a little leery of trying older gccs after my problems with a different machine). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24631
[Bug target/24621] [4.1 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:393
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-11-07 18:03 --- Alternatively, the PR is also fixed by rth's patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00424.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24621
[Bug c++/21123] [4.0/4.1 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-04-29 13:12:21 |2005-11-07 18:10:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug c/24599] [4.0 regression] Overflow for true value
--- Comment #8 from bonzini at gcc dot gnu dot org 2005-11-07 18:17 --- Subject: Bug 24599 Author: bonzini Date: Mon Nov 7 18:17:35 2005 New Revision: 106600 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106600 Log: 2005-11-07 Paolo Bonzini [EMAIL PROTECTED] PR c/24599 * c-typeck.c (build_c_cast): Try using a shared constant, and see if TREE_OVERFLOW or TREE_CONSTANT_OVERFLOW really changed. (readonly_error): Fix formatting error. testsuite: 2005-11-07 Paolo Bonzini [EMAIL PROTECTED] PR c/24599 * gcc.dg/overflow-2.c: New testcase. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/overflow-2.c - copied unchanged from r106587, trunk/gcc/testsuite/gcc.dg/overflow-2.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/c-typeck.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug c/24599] [4.0 regression] Overflow for true value
--- Comment #9 from bonzini at gcc dot gnu dot org 2005-11-07 18:18 --- fixed on 4.0 branch too -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.3 |4.0.2 Known to work|3.4.0 4.1.0 |3.4.0 4.0.3 4.1.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug bootstrap/17269] make install doesn't work after --enable-bootstrap enabled bootstrap
--- Comment #3 from bonzini at gcc dot gnu dot org 2005-11-07 18:19 --- it works now -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17269
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #21 from bonzini at gcc dot gnu dot org 2005-11-07 18:22 --- Is this a 4.0 regression too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug bootstrap/24688] sco_math fixincl breaks math.h
--- Comment #3 from sje at cup dot hp dot com 2005-11-07 18:26 --- It looks like this is fixed on the mainline and on the 4.0 branch by the addition of bypass = __GNUG__; This patch was done in revision 90550 by jsm28. We should do this for the 3.4 branch as well. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-07 18:26:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
[Bug bootstrap/24688] [3.4 Regression] sco_math fixincl breaks math.h
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|sco_math fixincl breaks |[3.4 Regression] sco_math |math.h |fixincl breaks math.h Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
[Bug c/24716] New: Wrong code generated when optimising
In a large application, a certain routine from the UMFPACK library is miscompiled when -O is specified. Without optimisation, the routine works fine. This triggers an assertion failure in the code. I use gcc (GCC) 4.1.0 20051030 (experimental). The problem can be reproduced with the attached source files. To see the error, compile them with /gcc/bin/gcc -g -O -o umfpack-bug umfpack-call.c umf_analyze.i umf_apply_order.i umf_order_front_tree.i umf_dump.i When run, the executable aborts with an assertion failure: /Users/eschnett/Calpha/arrangements/AEIThorns/AHFinderDirect/src/sparse-matrix/umfpack/umf_analyze.c:500: failed assertion `parent == j+1' Abort trap (core dumped) To make the error go away, omit the -O option. In this case, the executable runs without producing any output. The error seems to be the following. The routine UMF_analyze contains a large loop in which the local variable pdest is changed. In the next iteration, pdest is reset to the value it had before the loop. This happens only for local variables, not for static or global variables. The error seems to be specific to powerpc; it does not happen on i386. gcc 3.3 does not have this problem. -- Summary: Wrong code generated when optimising Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: powerpc-apple-darwin8.2.0 GCC host triplet: powerpc-apple-darwin8.2.0 GCC target triplet: powerpc-apple-darwin8.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug bootstrap/24688] [3.4 Regression] sco_math fixincl breaks math.h
--- Comment #4 from sje at cup dot hp dot com 2005-11-07 18:40 --- Original patch submittal is at http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html I will apply this to the 3.4 branch and test it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #20 from ian at airs dot com 2005-11-07 18:41 ---
By the way, Richard, I just want to note that while this is obviously a
compiler bug, it is only being triggered for the original test case because of
the uninitialized variable i in sha1_update:
void sha1_update(SHA1_CONTEXT* context, unsigned char* data, Q_UINT32
len) {
Q_UINT32 i, j;
if((j + len) 63) {
for ( ;
i + 63 len;
i += 64) { transform(context-state, data[i]); }
}
}
I don't know if that was a consequence of your test case reduction or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|Wrong code generated when |[4.1 Regression] Wrong code |optimising |generated when optimising Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-07 18:42 --- Created an attachment (id=10165) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10165action=view) Tarball with source code demonstrating the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #21 from mueller at kde dot org 2005-11-07 18:45 ---
its an error in the testcase, the original code initializes i:
if((j + len) 63) {
562 memcpy(context-buffer[j], data, (i = 64-j));
563 transform(context-state, context-buffer);
564 for ( ; i + 63 len; i += 64) {
565 transform(context-state, data[i]);
566 }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-07 18:49 --- (In reply to comment #0) The error seems to be specific to powerpc; it does not happen on i386. It does fail for me on i686 with 4.1.0 20051026. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #22 from ian at gcc dot gnu dot org 2005-11-07 18:52 --- Subject: Bug 24683 Author: ian Date: Mon Nov 7 18:52:24 2005 New Revision: 106601 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106601 Log: ./: PR rtl-optimization/24683 * config/i386/i386.c (legitimize_pic_address): If constant operand to PLUS is too large, put it in a register. testsuite/: PR rtl-optimization/24683 * gcc.dg/pr24683.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr24683.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #23 from ian at gcc dot gnu dot org 2005-11-07 18:55 --- Subject: Bug 24683 Author: ian Date: Mon Nov 7 18:55:03 2005 New Revision: 106602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106602 Log: ./: PR rtl-optimization/24683 * config/i386/i386.c (legitimize_pic_address): If constant operand to PLUS is too large, put it in a register. testsuite/: PR rtl-optimization/24683 * gcc.dg/pr24683.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr24683.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/i386/i386.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #24 from ian at airs dot com 2005-11-07 18:58 --- Fixed on 4.0 branch and on mainline. The 3.4 branch breaks in a slightly different way. I'm not going to worry about it since you can only create this problem by building implausible addresses that include offsets of more than 2GB. -- ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug c++/24717] New: spurious error
enum A{a,b,c};
templatetypename T, int i, A x, typename U void f(const U, int) {}
templatetypename T, int i, typename U void f(const U, int) {}
templatetypename U void f(const U, int) {}
templatetypename T, A x, typename U void f(const U, int, int) {}
templatetypename T, typename U void f(const U, int, int) {}
templatetypename U void f(const U, int, int) {}
int main() {
bool b;
fint, 1, a(b, 5);
fint, 1(b, 5);
f(b, 5);
fint, a(b, 5, 10);
fint(b, 5, 10);
f(b, 5, 10);
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:11: error: invalid conversion from `int' to `A'
foo.cc:12: error: invalid conversion from `int' to `A'
Ivan
--
Summary: spurious error
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24717
[Bug driver/24684] No flag documentation for gomp (openmp)
--- Comment #2 from dnovillo at gcc dot gnu dot org 2005-11-07 19:06 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00458.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24684
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #5 from dir at lanl dot gov 2005-11-07 19:17 --- I do the get with - [dranta:~/utlib] dir% cat gfortranGet cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc I do the configure with - [dranta:~/utlib] dir% cat gfortranConfig configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #6 from dir at lanl dot gov 2005-11-07 19:19 --- I have a dual 2.5 GHZ PowerPC G5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug driver/24718] New: Shared libgcc not used for linking by default
I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled
gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit
the same problem. While trying to build Perl 5.8.6:
$ gmake
...
gcc -v -o libperl.so -shared -fPIC perl.o gv.o toke.o perly.o op.o
pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o
sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o
taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o
numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl -lnm -ldl -ldld -lm
-lsec -lpthread -lc
...
/opt/TWWfsw/gcc343/libexec/gcc/ia64-hp-hpux11.23/3.4.3/collect2
+Accept TypeMismatch -b -o libperl.so -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc -lgcc
^^^
Notice the -lgcc -lgcc at the end of the collect2 command-line, not -lgcc_s
-lgcc_s.
On HP-UX 11.23/PA-RISC, I get:
/opt/TWWfsw/gcc343/libexec/gcc/hppa2.0-hp-hpux11.23/3.4.3/collect2
-z -b -o libperl.sl -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/hppa2.0-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib -L/opt/langtools/lib -L/opt/TWWfsw/gcc343/lib perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lgcc_s -lgcc_s
Using the HP pre-compiled binary of gcc-4.0.2, I get:
/opt/hp-gcc/4.0.2/bin/../libexec/gcc/ia64-hp-hpux11.23/4.0.2/collect2
-z +Accept TypeMismatch -b -o libperl.so
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2/../../..
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc_s -lunwind -lgcc_s
-lunwind
The *libgcc line from the 3.4.3/3.4.4 specs file:
*libgcc:
%{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64}
%{static|static-libgcc:-lgcc -lgcc_eh
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh
-lunwind}%{shared-libgcc:-lgcc_s%M -lunwind -lgcc}}%{shared:-lgcc_s%M
-lunwind%{!shared-libgcc:-lgcc}
The *libgcc line from the 4.0.2 specs file (via -dumpspecs):
*libgcc:
%{static|static-libgcc:-lgcc -lgcc_eh
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh
-lunwind}%{shared-libgcc:-lgcc_s -lunwind -lgcc}}%{shared:-lgcc_s -lunwind}}}
Is the problem in the *libgcc entry? It seems !shared-libgcc is true, though
I don't know why.
$ /opt/TWWfsw/gcc343/bin/gcc -v
Reading specs from
/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/specs
Configured with: /opt/build/gcc-3.4.3/configure --with-gnu-as
--with-as=/opt/TWWfsw/gcc343/ia64-hp-hpux11.23/bin/as
--with-included-gettext --enable-shared
--datadir=/opt/TWWfsw/gcc343/share --enable-languages=c,c++,f77
--with-local-prefix=/opt/TWWfsw/gcc343 --prefix=/opt/TWWfsw/gcc343
Thread model: single
gcc version 3.4.3 (TWW)
--
Summary: Shared libgcc not used for linking by default
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
GCC build triplet: ia64-hp-hpux11.23
GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug c++/21123] [4.0/4.1 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #24 from jason at gcc dot gnu dot org 2005-11-07 19:35 --- This is a bug in the generic thunk support; it doesn't show up on x86 because it uses asm thunks. Continuing to investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug preprocessor/15220] [3.4 regression] gcc -E -MM -MG reports missing system headers in source directory
--- Comment #17 from wilson at gcc dot gnu dot org 2005-11-07 19:49 --- Subject: Bug 15220 Author: wilson Date: Mon Nov 7 19:49:04 2005 New Revision: 106608 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106608 Log: Fix problem with -MM -MG and missing system header files. PR preprocessor/15220 * cppfiles.c (_cpp_find_file): New parameter angle_brackets. Fix all callers. Pass to open_file_failed. (open_file_failed): New parameter angle_brackets. Fix all callers. use in print_dep assignment. * cpphash.h (_cpp_find_file): Add new parm to declaration. * cppinit.c (cpp_read_main_file): Pass another arg to _cpp_find_file. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/cppfiles.c branches/gcc-3_4-branch/gcc/cpphash.h branches/gcc-3_4-branch/gcc/cppinit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug preprocessor/15220] [3.4 regression] gcc -E -MM -MG reports missing system headers in source directory
--- Comment #18 from wilson at gcc dot gnu dot org 2005-11-07 19:51 --- Mine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2004-04-30 12:53:54 |2005-11-07 19:51:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug preprocessor/15220] [3.4 regression] gcc -E -MM -MG reports missing system headers in source directory
--- Comment #19 from wilson at gcc dot gnu dot org 2005-11-07 19:52 --- Fixed on gcc-3.4.x branch, gcc-4.0.x branch, and mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.3 4.1.0 |4.0.3 4.1.0 3.4.5 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug libstdc++/21072] base allocator change shared object issues
--- Comment #7 from matz at suse dot de 2005-11-07 19:59 --- Of course not. But unaware people trying trunk currently on distros which provided 3.4 or 4.0 will get non-obvious problems, and I'm not sure if that's a good idea (ignoring this problem 4.0 and trunk are nearly compatible, and 4.0 compiled programs work with the trunk libstc++, which has the same SOname like the 4.0 one). I think the only way to switch to the 'mt' allocator by default for the future without API issues would be to rename it to 'new', and not via some configure arguments. Another reason is that this switching back of the default allocator is not forgotten when 4.1 branches, which I think is necessary anyway, so that 4.1 libs are compatible with 4.0 programs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-07 20:03 --- Can you try first by not building in the source directory? Second that CVS repro is no longer being updated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #13 from thebohemian at gmx dot net 2005-11-07 20:03 --- anthony you're right. It should work without ffi_call invocation. Thanks for the review. I try to find out whether this fixes my segfault too, tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug fortran/24409] ICE on module name vs dummy argument name
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-07 20:14 --- Did this patch ever get posted? Tobi, that's a coincidence; I just found it whilst working on dot_product! I'll submit in the next 24 hours. I've found another patch that I just forgot about too -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24409
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-07 20:39 --- A little more info, umf_analyze.i is being miscompiled. I don't know which one yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
