[Bug c++/28573] [4.0/4.1/4.2 Regression] incorrectly allowing non-constant expression to offsetof()
--- Comment #4 from bonzini at gnu dot org 2006-08-17 07:03 --- Subject: Bug 28573 Author: bonzini Date: Thu Aug 17 07:02:55 2006 New Revision: 116208 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116208 Log: 2006-08-17 Paolo Bonzini <[EMAIL PROTECTED]> PR c++/28573 * c-common.c (fold_offsetof_1): Add an argument and recurse down to it or the INTEGER_CST. Fail on a CALL_EXPR. (fold_offsetof): Pass new argument to fold_offsetof_1. * c-parser.c (c_parser_postfix_expression): Don't include a NULL operand into an INDIRECT_REF. * c-typeck.c (build_unary_op): Adjust call to fold_offsetof. cp: 2006-08-17 Paolo Bonzini <[EMAIL PROTECTED]> PR c++/28573 * semantics.c (finish_offsetof): Add new argument to fold_offsetof. testsuite: 2006-08-17 Paolo Bonzini <[EMAIL PROTECTED]> PR c++/28573 * g++.dg/parse/offsetof6.C: New test. * g++.dg/parse/offsetof7.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/offsetof6.C trunk/gcc/testsuite/g++.dg/parse/offsetof7.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-parser.c trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28573
[Bug rtl-optimization/21676] [4.0/4.1/4.2 Regression] Optimizer regression: SciMark sparse matrix benchmark
--- Comment #7 from uros at kss-loka dot si 2006-08-17 07:21 --- (In reply to comment #6) > I think that remaining time difference is due to strange loop above innermost: ... due to strange _header_ above innermost loop ... The problem is that we load zero in both arms of "if". This is what I get in .099t.optimized (using gcc-4.2 -O2 -fno-ivopts): :; r.0 = (unsigned int) r; D.1556 = r.0 * 4; rowR = *((int *) D.1556 + row); rowRp1 = *((int *) D.1556 + row + 4B); if (rowR < rowRp1) goto ; else goto ; :; sum = 0.0; goto (); :; i = rowR; sum = 0.0; Assignment to sum should be moved before if... SSE is able to somehow CSE zero load during RTL: .L8: movl 20(%ebp), %edx movapd %xmm2, %xmm1 movl (%edx,%ebx,4), %eax movl 4(%edx,%ebx,4), %ecx cmpl %ecx, %eax jge .L11 movl %eax, %edx .p2align 4,,7 .L12: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug rtl-optimization/21676] [4.0/4.1/4.2 Regression] Optimizer regression: SciMark sparse matrix benchmark
--- Comment #8 from uros at kss-loka dot si 2006-08-17 07:45 --- Also interesting is, that -march=pentium4 produces following "de-optimized" code, adding a couple more instructions and wasting %eax register: .L8: leal(%ebx,%ebx), %eax movl40(%esp), %edx movl(%edx,%eax,2), %edx movl%edx, (%esp) movl40(%esp), %edx movl4(%edx,%eax,2), %ecx movapd %xmm2, %xmm1 cmpl%ecx, (%esp) jge .L11 movl(%esp), %edx .L12: Some additiona timing can be shown (gcc-4.2 -O2 -fomit-frame-pointer): -march=pentium4: 0m2.756s -march=pentium4 -fno-ivopts: 0m2.500s -march=pentium4 -fno-ivopts -mfpmath=sse: 0m2.461s -msse2 -fno-ivopts -mfmpath=sse: 0m2.311s In the last case, the generated code is equal to gcc-3.2 generated one: .L8: movl36(%esp), %edx movapd %xmm2, %xmm1 movl(%edx,%ebx,4), %eax movl4(%edx,%ebx,4), %ecx cmpl%ecx, %eax jge .L11 movl%eax, %edx .p2align 4,,7 .L12: movl(%edi,%edx,4), %eax movsd (%esi,%eax,8), %xmm0 mulsd (%ebp,%edx,8), %xmm0 addl$1, %edx cmpl%edx, %ecx addsd %xmm0, %xmm1 jg .L12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug libgomp/28725] Case Sensitive OpenMP environment variables and patch
--- Comment #2 from jakub at gcc dot gnu dot org 2006-08-17 07:58 --- Subject: Bug 28725 Author: jakub Date: Thu Aug 17 07:58:02 2006 New Revision: 116209 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116209 Log: PR libgomp/28725 * env.c: Include ctype.h. (parse_schedule, parse_unsigned_long, parse_boolean): Allow leading and/or trailing whitespace and compare strings case insensitively. Modified: trunk/libgomp/ChangeLog trunk/libgomp/env.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28725
[Bug libgomp/28725] Case Sensitive OpenMP environment variables and patch
--- Comment #3 from jakub at gcc dot gnu dot org 2006-08-17 07:59 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28725
[Bug c++/28711] ICE on invalid initializer for multidimensional array
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-17 08:02 --- Subject: Bug 28711 Author: reichelt Date: Thu Aug 17 08:02:39 2006 New Revision: 116210 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116210 Log: PR c++/28711 * pt.c (tsubst_copy_and_build) : Robustify. * g++.dg/template/ctor8.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/ctor8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28711
[Bug c++/28710] [4.0/4.1/4.2 regression] ICE redeclaring template as non-template
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-17 08:06 --- Subject: Bug 28710 Author: reichelt Date: Thu Aug 17 08:06:27 2006 New Revision: 116211 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116211 Log: PR c++/28710 * decl.c (xref_tag): Improve error message. Return early on error. * g++.dg/template/redecl4.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/redecl4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28710
[Bug c++/28710] [4.0/4.1/4.2 regression] ICE redeclaring template as non-template
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-17 08:12 --- Subject: Bug 28710 Author: reichelt Date: Thu Aug 17 08:12:00 2006 New Revision: 116212 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116212 Log: PR c++/28710 * decl.c (xref_tag): Improve error message. Return early on error. * g++.dg/template/redecl4.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/redecl4.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28710
[Bug target/25500] [4.0/4.1/4.2 Regression]: SSE2 vectorized code is slower on 4.x.x than previous
--- Comment #21 from bonzini at gnu dot org 2006-08-17 08:16 --- I'll see if I can construct a case where my patch fails (actually a newer one) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug tree-optimization/27865] [4.2 Regression] tree check failure building FreePOOMA
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-08-17 08:22 ---
Subject: Bug 27865
Author: rakdver
Date: Thu Aug 17 08:22:05 2006
New Revision: 116213
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116213
Log:
PR tree-optimization/27865
* tree-vrp.c (adjust_range_with_scev): Do not use TYPE_{MIN,MAX}_VALUE
for pointer types.
* tree-scalar-evolution.c (fold_used_pointer_cast, pointer_offset_p,
fold_used_pointer, pointer_used_p): New functions.
(analyze_scalar_evolution_1): Use fold_used_pointer.
* tree-chrec.c (convert_affine_scev): Convert no-op casts correctly.
* tree-ssa-loop-ivopts.c (generic_type_for): Return integral type
for pointers.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-chrec.c
trunk/gcc/tree-scalar-evolution.c
trunk/gcc/tree-ssa-loop-ivopts.c
trunk/gcc/tree-vrp.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27865
[Bug c++/23794] C++ frontend passes invalid COND_EXPR to the middle-end
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-08-17 08:34 --- Appearantly fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23794
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2006-08-17 08:48 --- Subject: Bug 28489 Author: mkuvyrkov Date: Thu Aug 17 08:48:37 2006 New Revision: 116214 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116214 Log: 2006-08-17 Maxim Kuvyrkov <[EMAIL PROTECTED]> PR rtl-optimization/28489 * sched-ebb.c (begin_schedule_ready): Create basic block at the right place. (advance_target_bb): Skip empty blocks. * haifa-sched.c (bb_note): Make global. * sched-int.h (bb_note): Add prototype. 2006-08-17 Maxim Kuvyrkov <[EMAIL PROTECTED]> PR rtl-optimization/28489 * gcc.c-torture/compile/pr28489.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr28489.c Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/sched-ebb.c trunk/gcc/sched-int.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #14 from mkuvyrkov at gcc dot gnu dot org 2006-08-17 08:52 --- Fixed by the earlier attached patch. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608
--- Comment #7 from aoliva at gcc dot gnu dot org 2006-08-17 08:55 --- Subject: Bug 28146 Author: aoliva Date: Thu Aug 17 08:55:02 2006 New Revision: 116215 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116215 Log: PR target/28146 * reload.h (reg_equiv_alt_mem_list): New declaration. * reload1.c (reg_equiv_alt_mem_list): New definition. (reload): Initialize it and release it. (delete_output_reload): Use it. * reload.c (push_reg_equiv_alt_mem): New function. (find_reloads_toplev): Call it. (find_reloads_address, find_reloads_address_1): Likewise. (find_reloads_subreg_address): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/reload.h trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28146
[Bug c++/28710] [4.0/4.1/4.2 regression] ICE redeclaring template as non-template
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-08-17 08:55 --- Subject: Bug 28710 Author: reichelt Date: Thu Aug 17 08:55:17 2006 New Revision: 116216 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116216 Log: PR c++/28710 * decl.c (xref_tag): Improve error message. Return early on error. * g++.dg/template/redecl4.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/redecl4.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28710
[Bug c++/28710] [4.0/4.1/4.2 regression] ICE redeclaring template as non-template
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-08-17 08:57 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28710
[Bug c++/28711] ICE on invalid initializer for multidimensional array
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-17 08:58 --- Fixed on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28711
[Bug c++/28606] [4.0/4.1/4.2 regression] Destructor accepted as return-type of constructor
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-08-17 09:07 --- Subject: Bug 28606 Author: reichelt Date: Thu Aug 17 09:07:39 2006 New Revision: 116217 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116217 Log: PR c++/28606 * parser.c (cp_parser_diagnose_invalid_type_name): Handle BIT_NOT_EXPR. Fix formatting. (cp_parser_parse_and_diagnose_invalid_type_name): Tighten condition for valid type-names. (cp_parser_unqualified_id): Fix error handling for destructors. * g++.dg/parse/dtor11.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/dtor11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28606
[Bug c++/28606] [4.0/4.1/4.2 regression] Destructor accepted as return-type of constructor
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-17 09:13 --- Subject: Bug 28606 Author: reichelt Date: Thu Aug 17 09:13:13 2006 New Revision: 116218 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116218 Log: PR c++/28606 * parser.c (cp_parser_diagnose_invalid_type_name): Handle BIT_NOT_EXPR. Fix formatting. (cp_parser_parse_and_diagnose_invalid_type_name): Tighten condition for valid type-names. (cp_parser_unqualified_id): Fix error handling for destructors. * g++.dg/parse/dtor11.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor11.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28606
[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.
--- Comment #7 from dwmw2 at infradead dot org 2006-08-17 09:16 ---
The one with proc_mkdir was because the EXPORT_SYMBOL is in a different file to
the original function -- although my version was working correctly, I'm willing
to deal with that case.
The symbol 'proc_root' is also missing though. Simple test case:
$ cat foo.c
extern int foo;
int __attribute__((externally_visible)) *bar(void)
{
return &foo;
}
pmac /home/dwmw2 $ cat bar.c
int foo __attribute__((externally_visible)) = 42;
$ gcc -fwhole-program --combine -Os -c -ofoo.o foo.c bar.c
$ nm -a foo.o T bar b .bss
n .comment
d .data
d foo.1277
a foo.c
n .note.GNU-stack
t .text
Note 'd foo.1277' instead of the expected 'D foo'. Giving foo.c and bar.c in
the opposite order on the command line 'fixes' this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
[Bug c++/28606] [4.0/4.1/4.2 regression] Destructor accepted as return-type of constructor
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-17 09:19 --- Subject: Bug 28606 Author: reichelt Date: Thu Aug 17 09:19:27 2006 New Revision: 116219 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116219 Log: PR c++/28606 * parser.c (cp_parser_diagnose_invalid_type_name): Handle BIT_NOT_EXPR. Fix formatting. (cp_parser_parse_and_diagnose_invalid_type_name): Tighten condition for valid type-names. (cp_parser_unqualified_id): Fix error handling for destructors. * g++.dg/parse/dtor11.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor11.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28606
[Bug c++/28606] [4.0/4.1/4.2 regression] Destructor accepted as return-type of constructor
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-17 09:20 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28606
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #9 from tim at klingt dot org 2006-08-17 09:43 --- i have the same problem on my machine, using the latest snapshot. i'm not sure, if the following information is helpful, but gcc -v gives me: Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.2.0_alpha20060812/work/gcc-4.2-20060812/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.2.0-alpha20060812 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0-alpha20060812/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.0-alpha20060812 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.0-alpha20060812/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.0-alpha20060812/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0-alpha20060812/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.2.0-alpha20060812 (experimental) (Gentoo 4.2.0_alpha20060812) the cflags and cxxflags to build gcc were: -march=pentium-m -pipe -O2 would be great, to have this resolved, soon ... -- tim at klingt dot org changed: What|Removed |Added CC||tim at klingt dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug tree-optimization/27865] [4.2 Regression] tree check failure building FreePOOMA
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-08-17 09:44 --- Subject: Bug 27865 Author: hubicka Date: Thu Aug 17 09:44:12 2006 New Revision: 116220 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116220 Log: PR tree-optimization/27865 * reload1.c (forget_marked_reloads): New function. (forget_old_reloads_1): When data are passed, just mark the registers for later removal. (reload_as_needed): Use the new mechanizm. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27865
[Bug middle-end/28755] [4.0/4.1/4.2 Regression] duplicate members of arrays
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||08/msg00601.html Status|NEW |ASSIGNED Last reconfirmed|2006-08-16 17:37:29 |2006-08-17 11:17:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755
[Bug boehm-gc/28760] New: GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
Compiled java programs that are linked statically with gcj segfault on startup
(starting with GCC 4.1.x):
# gcj -g -static --main=test -Wl,--whole-archive -lnss_files_p -lnss_dns_p
-lresolv -lpthread -ldl -Wl,--no-whole-archive test.java
# ./a.out
Segmentation fault
with test.java being i.e.
public class test {
public static void main( String args[] ) {
System.err.println( "Hello" ); }}
GDB tells me the program is crashing in:
(gdb) bt
#0 0x in ?? ()
#1 0x081e89de in pthread_create (new_thread=0x86c733c, attr=0xba04,
start_routine=0x808fff0 , arg=0x74ff8) at
../.././boehm-gc/pthread_support.c:1289
#2 0x0808fee7 in _Jv_ThreadStart (thread=0x5cb18, data=0x86c7338,
meth=0x808cd30 <_Jv_ThreadRun(java::lang::Thread*)>) at
../.././libjava/posix-threads.cc:488
#3 0x0808c702 in java::lang::Thread::start (this=0x5cb18)
at ../.././libjava/java/lang/natThread.cc:328
#4 0x080620e4 in _Jv_CreateJavaVM (vm_args=0x0) at
../.././libjava/prims.cc:1334
#5 0x080622da in _Jv_RunMain (vm_args=0x0, klass=0x8441fc0, name=0x0,
argc=1, argv=0xbd84,
is_jar=false) at ../.././libjava/prims.cc:1355
#6 0x08062468 in _Jv_RunMain (klass=0x8441fc0, name=0x0, argc=1,
argv=0xbd84, is_jar=false)
at ../.././libjava/prims.cc:1401
#7 0x0806249b in JvRunMain (klass=0x8441fc0, argc=1, argv=0xbd84)
at ../.././libjava/prims.cc:1407
#8 0x0804824c in main (argc=Cannot access memory at address 0x1
) at /tmp/ccYuSF5L.i:11
Obviously, in line 1289 of pthread_support.c GC_PTHREAD_REAL_NAME is null due
to the fact that it is computed using dlvsym() in line 1218. Of course(?)
dlvsym() will return null if libpthread is statically linked.
My quick hack around the problem was to just disable the dlvsym() variation
(see attached patch). This seems to work for me.
Best regards,
Tom
--
Summary: GC_PTHREAD_CREATE_NAME segfaults in statically linked
binaries
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boehm-gc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aeby at graeff dot com
GCC build triplet: i386-pc-linux
GCC host triplet: i386-pc-linux
GCC target triplet: i386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #1 from aeby at graeff dot com 2006-08-17 11:50 --- Created an attachment (id=12087) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12087&action=view) Ugly workaround GC_PTHREAD_CREATE_NAME segfault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug c++/28761] New: Returning object ignores copy constructor
Sytem information: - LFS-based Linux, with kernel 2.6.15 (with some genpatches) GCC configuring --- ./gcc-3.4.3/configure --prefix=/usr \ --libexecdir=/usr/lib --enable-shared \ --enable-threads=posix --enable-__cxa_atexit \ --enable-clocale=gnu --enable-languages=c,c++ GCC Compiling: - make bug description: - We compiled the attached source code using the command: > g++ --save-temps build_and_destroy.cc -o bug Running ./bug produced the following output: A A copy A ~A A.m:1 ~A ~A As you can see, returning the object in the function F didn't call the copy constructor. We expect the following output: A A copy A A copy ~A ~A A.m:2 ~A ~A -- Summary: Returning object ignores copy constructor Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ist_alex at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.
--- Comment #8 from jakub at gcc dot gnu dot org 2006-08-17 11:52 --- Subject: Bug 28744 Author: jakub Date: Thu Aug 17 11:52:26 2006 New Revision: 116222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116222 Log: PR c/28744 * cgraph.h (struct cgraph_node): Remove externally_visible bitfield. * cgraphunit.c (process_function_and_variable_attributes): Set local.externally_visible rather than externally_visible. PR c/28744 * c-common.c (handle_externally_visible_attribute): First look at TREE_CODE and only if it is function or var decl, check for non-public objects. Don't warn for DECL_EXTERNAL. * cgraphunit.c (process_function_and_variable_attributes): Warn if externally_visible attribute is used on non-public object. * gcc.dg/attr-externally-visible-1.c: New test. * gcc.dg/attr-externally-visible-2.c: New test. * g++.dg/parse/attr-externally-visible-1.C: New test. * g++.dg/parse/attr-externally-visible-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/attr-externally-visible-1.C trunk/gcc/testsuite/g++.dg/parse/attr-externally-visible-2.C trunk/gcc/testsuite/gcc.dg/attr-externally-visible-1.c trunk/gcc/testsuite/gcc.dg/attr-externally-visible-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
[Bug c++/28761] Returning object ignores copy constructor
--- Comment #1 from ist_alex at yahoo dot com 2006-08-17 11:52 --- Created an attachment (id=12088) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12088&action=view) The original source code Bug related file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
[Bug c++/28761] Returning object ignores copy constructor
--- Comment #2 from ist_alex at yahoo dot com 2006-08-17 11:54 --- Created an attachment (id=12089) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12089&action=view) The preprocessed source (*.ii) file Bug related file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
[Bug c++/28761] Returning object ignores copy constructor
--- Comment #3 from pluto at agmk dot net 2006-08-17 12:18 --- this is not a bug. the c++ standard allows RVO optimization. see $12.8/15 for more details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.
--- Comment #9 from jakub at gcc dot gnu dot org 2006-08-17 12:20 ---
The problem mentioned in #7 is not specific to variables, foo.c:
extern int foo (void);
__attribute__((externally_visible)) void *bar(void)
{
return foo;
}
bar.c:
__attribute__((externally_visible)) int foo (void)
{
}
results in foo not being externally visible in the end.
The problem seems to be on the process_function_and_variable_attributes side,
it only analyzes newly added cgraph_nodes and cgraph_varpool_nodes. But, if a
prior TU already created such nodes (just DECL_EXTERNALs), then even if they
were defined in the current TU, process_function_and_variable_attributes won't
see them as new.
Always walking the whole pools might be too expensive on the other side.
Is there any reason why process_function_and_variable_attributes is called
at the end of each TU rather than when all TUs were already parsed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system
--- Comment #3 from jakub at gcc dot gnu dot org 2006-08-17 12:38 --- The is just the libstdc++ ABI check not being able to understand tanl@@GLIBCXX_3.4 -> [EMAIL PROTECTED] etc. changes (22 such symbols). Those are not ABI breakers, all that means is that newly linked programs won't resolve to these symbols in libstdc++.so (but to libm.so), old programs and libraries can still use those in libstdc++.so. But the original bug claims not just abicheck failure, but some other problem with libstlport. There are no details though, so those need to be provided - what exactly cannot be resolved, readelf -Ws dumps, etc. No ABI-checking utilities I'm using showed any problems after the transition to TFmode long double. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
[Bug c/27697] [4.0 Regression] incorrect warning about constness of pointer to an array in a const struct
--- Comment #9 from brett dot albertson at stratech dot com 2006-08-17 13:02 --- (In reply to comment #7) > Subject: Bug 27697 This fails on i386-pc-solaris2.10 on trunk with: Executing on host: /u01/var/tmp/gcc_trunk_svn/gcc_20060817/gcc/xgcc -B/u01/var/tmp/gcc_trunk_svn/gcc_20060817/gcc/ /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.dg/qual-component-1.c -fno-show-column -S -o qual-component-1.s(timeout = 300) /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.dg/qual-component-1.c: In function 'f':^M /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.dg/qual-component-1.c:45: error: assignment of read-only member 'd'^M /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.dg/qual-component-1.c:46: error: assignment of read-only location^M /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.dg/qual-component-1.c:47: error: assignment of read-only location^M etc. and /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.dg/qual-component-1.c: In function 'g':^M /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.dg/qual-component-1.c:113: warning: initialization from in compatible pointer type^M /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.dg/qual-component-1.c:118: warning: assignment from incompatible pointer type^M etc. Brett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27697
[Bug c++/20966] [DR 503] cv-qualified function references and overload resolution
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-17 13:06 --- The fix of PR 28385 changed the behavior on mainline so that the bug is now fixed on mainline (w.r.t. current version of the standard). I.e. only the 4.0 branch and the 4.1 branch (and everyting before 3.4.1) is affected. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28385 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20966
[Bug tree-optimization/25211] [4.1 Regression] verify_ssa ICE with -Os -ftree-loop-linear
--- Comment #9 from spop at gcc dot gnu dot org 2006-08-17 13:14 --- Subject: Bug 25211 Author: spop Date: Thu Aug 17 13:14:26 2006 New Revision: 116223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116223 Log: PR middle-end/25211 PR middle-end/20256 PR middle-end/26435 * tree-loop-linear.c (linear_transform_loops): Don't test perfect_nest_p. Call rewrite_into_loop_closed_ssa only when something changed. * lambda.h (gcc_loopnest_to_lambda_loopnest): Update declaration. * lambda-code.c (can_convert_to_perfect_nest): Declared. (gcc_loopnest_to_lambda_loopnest): Removed need_perfect_nest parameter. Test for perfect_nest_p here. Fix formating. (replace_uses_equiv_to_x_with_y): Fix formating. (stmt_uses_op): Removed. (can_convert_to_perfect_nest): Removed loopivs parameter. Complete the test by checking the scalar dependences. (perfect_nestify): Remove the test for can_convert_to_perfect_nest. Fix formating. Don't copy statements in the inner loop: move them to the inner loop header. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr20256.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr26435.c branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pr27745.f90 Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/lambda-code.c branches/gcc-4_1-branch/gcc/lambda.h branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/ltrans-1.c branches/gcc-4_1-branch/gcc/tree-loop-linear.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25211
[Bug tree-optimization/26435] [4.1 regression] ICE with -O1 -ftree-loop-linear and higher optimization
--- Comment #9 from spop at gcc dot gnu dot org 2006-08-17 13:14 --- Subject: Bug 26435 Author: spop Date: Thu Aug 17 13:14:26 2006 New Revision: 116223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116223 Log: PR middle-end/25211 PR middle-end/20256 PR middle-end/26435 * tree-loop-linear.c (linear_transform_loops): Don't test perfect_nest_p. Call rewrite_into_loop_closed_ssa only when something changed. * lambda.h (gcc_loopnest_to_lambda_loopnest): Update declaration. * lambda-code.c (can_convert_to_perfect_nest): Declared. (gcc_loopnest_to_lambda_loopnest): Removed need_perfect_nest parameter. Test for perfect_nest_p here. Fix formating. (replace_uses_equiv_to_x_with_y): Fix formating. (stmt_uses_op): Removed. (can_convert_to_perfect_nest): Removed loopivs parameter. Complete the test by checking the scalar dependences. (perfect_nestify): Remove the test for can_convert_to_perfect_nest. Fix formating. Don't copy statements in the inner loop: move them to the inner loop header. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr20256.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr26435.c branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pr27745.f90 Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/lambda-code.c branches/gcc-4_1-branch/gcc/lambda.h branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/ltrans-1.c branches/gcc-4_1-branch/gcc/tree-loop-linear.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26435
[Bug tree-optimization/20256] Perfect nest transformation not conservative enough
--- Comment #13 from spop at gcc dot gnu dot org 2006-08-17 13:14 --- Subject: Bug 20256 Author: spop Date: Thu Aug 17 13:14:26 2006 New Revision: 116223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116223 Log: PR middle-end/25211 PR middle-end/20256 PR middle-end/26435 * tree-loop-linear.c (linear_transform_loops): Don't test perfect_nest_p. Call rewrite_into_loop_closed_ssa only when something changed. * lambda.h (gcc_loopnest_to_lambda_loopnest): Update declaration. * lambda-code.c (can_convert_to_perfect_nest): Declared. (gcc_loopnest_to_lambda_loopnest): Removed need_perfect_nest parameter. Test for perfect_nest_p here. Fix formating. (replace_uses_equiv_to_x_with_y): Fix formating. (stmt_uses_op): Removed. (can_convert_to_perfect_nest): Removed loopivs parameter. Complete the test by checking the scalar dependences. (perfect_nestify): Remove the test for can_convert_to_perfect_nest. Fix formating. Don't copy statements in the inner loop: move them to the inner loop header. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr20256.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr26435.c branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pr27745.f90 Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/lambda-code.c branches/gcc-4_1-branch/gcc/lambda.h branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/ltrans-1.c branches/gcc-4_1-branch/gcc/tree-loop-linear.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20256
[Bug c/28289] composite_types called to do two different things
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-08-17 13:23 --- (In reply to comment #0) Note, this bug had caused a bootstrap failure, discussed here: http://gcc.gnu.org/ml/gcc/2006-07/msg00108.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28289
[Bug c++/28761] Returning object ignores copy constructor
--- Comment #4 from ist_alex at yahoo dot com 2006-08-17 13:57 --- Never thought the C++ standard allows ignoring the code written in a dtor. What if the dtor does something important (like in the example - it doesn't just copy the contents)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
[Bug c++/28761] Returning object ignores copy constructor
--- Comment #5 from ist_alex at yahoo dot com 2006-08-17 14:00 --- I meant the copy ctor, not the dtor. Anyhow, looking at it again, it makes some sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
[Bug c++/28761] Returning object ignores copy constructor
--- Comment #6 from pluto at agmk dot net 2006-08-17 14:11 --- (In reply to comment #5) > I meant the copy ctor, not the dtor. > Anyhow, looking at it again, it makes some sense. "When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy operation as simply two different ways of referring to the same object" ps). you can disable such optimization with -fno-elide-contructors -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition
--- Comment #2 from whaley at cs dot utsa dot edu 2006-08-17 14:17 --- Richard, Thanks for confirmation. There's no chance of this happening soon, I guess? I'm working on a release of ATLAS (fast linear algebra), and I can't enable gcc vectorization until its necessary flags are separated from the non-IEEE badness . . . Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition
--- Comment #3 from bonzini at gnu dot org 2006-08-17 14:28 --- It probably will not happen before 4.3 and, even if it happened for 4.2, it will never be backported to 4.1 since this one is in regression fixes-only mode. You could help by looking at the source code (there are only a few dozens places mentioning flag_unsafe_math_optimizations) and auditing which places would be more suited to a new flag_reassociate_fp variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor
--- Comment #17 from bjoern dot m dot haase at web dot de 2006-08-17 14:36
---
I have made a superficial analysis of the issue and would like to discuss at
the end of this post a possible approach for resolving PR4131.
The first observation is, that when one is having a code segment like
/* Start */
#include
using namespace std;
typedef complex ci;
ci fa [3] = {ci(1,2), ci(-1,-2), ci(-42,+42)};
/* End */
the gimple optimizers will yield a very simple code sequence like
/* Start of gimple code */
void __static_initialization_and_destruction_0(int, int) (__initialize_p,
__priority)
{
:
if (__initialize_p == 1) goto ; else goto ;
:;
if (__priority == 65535) goto ; else goto ;
:;
fa[0]._M_real = 1;
fa[0]._M_imag = 2;
fa[1]._M_real = -1;
fa[1]._M_imag = -2;
fa[2]._M_real = -42;
fa[2]._M_imag = 42;
:;
return;
}
/* End of gimple code */
for the constructor function. Namely, I think that there is hope that one would
grep the most important cases if one would try to replace
some_direct_address_in_data_member = const_immediate_integer;
expressions in the constructors by storing the value in the .data initializers.
Namely, one would be placing the values in the initialization memory region and
one would be deleting the assignment expressions.
If at the end of this process, the constructor function would no longer contain
references to the data structure, "const" qualified VAR_DECL could even be
placed in ".rodata".
Thus, for fixing PR4131 I'd like to suggest to
1.) change the definition of the VAR_DECL so that DECL_INITIAL always points
to a memory region holding initialization data. I.e. also for the case
that we are having constructor code. Initially the memory region would
be initialized to 0.
2.) In order to do this, one would need to replace the tests
"DECL_INITIAL(decl) == error_mark_node" by tests against one of the unused
flags in tree_decl_common that would be assigned a new meaning.
E.g., one might take "decl_flag_0" which seems to be unused so far
for VAR_DECL.?
3.) One would then add a new tree optimiation pass that is located somewhere
close to the end of tree optimization. There one would be looking for
expressions like "static_direct_address = const_immediate_value" like
in the sample gimple code above.
One wold be inserting the values in the DECL_INITIAL(decl) memory region
delete the corresponding expression statements in the constructor function.
After making all the possible replacements, one would be re-visiting the
code of the constructor function.
If within the constructor code more complex references to the VAR_DECL
remain, that could not be removed easily, one would set one second flag
in "tree_decl_common" that states that the VAR_DECL needs to reside in ram,
even if it's a const object.
4.) In "var_asm.c" one would be checking if DECL_INITIAL(decl) is completely
zero. In this case it would go into .bss. If the initialization memory
region is not zero altogether, one would place the object in .data .
If it's a const object without the flag
"needs_to_reside_in_ram_even_if_const" it would be placed into .rodata.
IMO, the most complicated part of it would be the new tree pass 3.).
Namely, one would need to find the approriate branch in
void __static_initialization_and_destruction_0(int, int) (__initialize_p,
__priority);
, look for "direct_address_expression = immediate_integer_value;" type
expression statements that are not residing inside loops or other complicated
structures and delete them if possible.
Then one would be looking if there is any reference to some VAR_DECL remaining
in the FUNCTION_DECL of the constructor function. If there is still a
reference,
one would be setting the "needs_to_reside_in_ram_even_if_const" flag.
Otherwise one would clear it.
I would be willing to start with implementing 1,2 and 4, but I am quite sure
that I would need help for 3.
Bjoern.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug java/28663] [4.2 regression] gcj fails to binary-compile eclipse's javac
--- Comment #3 from bero at arklinux dot org 2006-08-17 14:45 --- gcj -C miscompiles just org/eclipse/jdt/internal/compiler/lookup/Scope.java and org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java -- I can generate a perfectly working ecj using gcj -C for all files, then rebuilding the .class files for those 2 files with jikes, then using gcj on the results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
[Bug c++/28761] Returning object ignores copy constructor
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-17 14:48 --- This is not a bug as mentioned by comment #6. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
[Bug fortran/28735] Crash in resolve.c - related to contents of .mod
--- Comment #7 from pault at gcc dot gnu dot org 2006-08-17 14:57 ---
(In reply to comment #6)
OK I understand it now. The PRIVATE declaration prevents references to 'a' and
'b' from being resolved, when USEing dummybdy_comm, because it suppresses the
symtree. This is demonstrated by making 'a' and 'b' public in module
dummybdy_comm, or by inverting the order of the USE statements in 'sub' (yes,
they get USEd in inverted order!).
Your proposed patch is OK but the subsequent check on e->symtree is now
redundant and should be removed. I am just now regtesting the result and will
submit mit it and the testcase below tonight.
Thanks for the report.
Paul
! { dg-do compile }
! This tests the fix for PR28735 in which an ICE would be triggered in
resolve_ref
! because the references to 'a' and 'b' in the dummy arguments of mysub have
! no symtrees in module bar, being private there.
!
! Contributed by Andrew Sampson <[EMAIL PROTECTED]>
!
!-- foo.F ---
module foo
implicit none
public
integer, allocatable :: a(:), b(:)
end module foo
!-- bar.F -
module bar
use foo
implicit none
private! This triggered the ICE
public :: mysub! since a and b are not public
contains
subroutine mysub(n, parray1)
integer, intent(in) :: n
real, dimension(a(n):b(n)) :: parray1
if ((n == 1) .and. size(parray1, 1) /= 10) call abort ()
if ((n == 2) .and. size(parray1, 1) /= 42) call abort ()
end subroutine mysub
end module bar
!-- sub.F ---
subroutine sub()
use foo
use bar
real :: z(100)
allocate (a(2), b(2))
a = (/1, 6/)
b = (/10, 47/)
call mysub (1, z)
call mysub (2, z)
return
end
!-- MAIN --
use bar
call sub ()
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28735
[Bug tree-optimization/27865] [4.2 Regression] tree check failure building FreePOOMA
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-17 14:58 --- 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=27865
[Bug tree-optimization/26435] [4.1 regression] ICE with -O1 -ftree-loop-linear and higher optimization
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-17 15:01 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26435
[Bug tree-optimization/20256] Perfect nest transformation not conservative enough
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20256
[Bug fortran/28735] Crash in resolve.c - related to contents of .mod
--- Comment #8 from pault at gcc dot gnu dot org 2006-08-17 15:03 --- Sorry, meant to accept this on the last reply. Paul -- 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 Last reconfirmed|2006-08-15 23:01:22 |2006-08-17 15:03:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28735
[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-17 15:08 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28146
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 15:12 --- Why are you trying to static link java code? It will almost not work for other cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug other/28757] `make install` installs some strange binaries
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 15:28 --- These are not strange at all, this is normal, just your prefix == triplet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28757
[Bug bootstrap/28758] `make` fails because of bad ORIGINAL_LD_FOR_TARGET
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-17 15:32 --- Can you show the output of the orginal configure? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|other |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28758
[Bug web/28714] Bugzilla mail sent from invalid address
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-17 15:33 --- I will let Daniel Berlin comment on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #11 from hjl at lucon dot org 2006-08-17 15:53 --- This patch http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00521.html works for me on ia64: http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg00722.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #3 from daney at gcc dot gnu dot org 2006-08-17 16:18 --- (In reply to comment #2) > Why are you trying to static link java code? It will almost not work for > other > cases. > We have 7.5X10^6 lines of code in about 800 classes that run fine statically linked. So it does in fact work. As to why, the answer is startup time and code size. We probably should fix this at some point, but until we do, I guess either do not statically link libc or use your work around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug fortran/28762] New: program name 'write' causes compiler crash on if statements containing write commands.
The following program:
program write
implicit none
integer :: debuglevel = 1
if (0 < debuglevel) write (0, "('test == ', f0.3)") 0.75
end program write
produces the following error at compile time:
> gfortran foo.f90
In file foo.f90:5
if (0 < debuglevel) write (0, "('test == ', f0.3)") 0.75
1
Error: Expected VARIABLE at (1)
Changing any of:
* The program name
* The if statement into an if then block
* Removing the if statement leaving the write
removes the problem.
The problem was not exhibited on svn build 114142 but it is not known at which
intervening version the problem arose.
--
Summary: program name 'write' causes compiler crash on if
statements containing write commands.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: David at ham dot dropbear dot id dot au
GCC build triplet: Gcc 4.2.0 (svn 116183) of 20060816 on RHEL4 x86_64
GCC host triplet: Gcc 4.2.0 (svn 116183) of 20060816 on RHEL4 x86_64
GCC target triplet: RHEL4 x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28762
[Bug c++/28763] New: sizeof macro appears broken when bitfields are in structures
I have compiled a sample application that demonstrates my problem (see below
for the sample code).
Basically when I have two structures, one that contains a bitfield and one that
does not, the sizeof macro acts differently between the two structures.
These structures are identical as far as content (size allocated), yet sizeof
fails for the structure containing the bitfield.
Accoding to the standards sizeof should report the total number of bytes within
a structure (including pad bytes for alignment). However it appears as though
when the bitfield mechanism is used, this fails.
Here's a sample code specimen that duplicates the problem...
sample app
struct foo1 {
unsigned int bar1 : 10;
unsigned int bar2 : 16;
unsigned int bar3 : 6;
unsigned short bar4;
};
struct foo2 {
unsigned intbar1;
unsigned short bar2;
};
int main(void) {
static foo1 fubar1 = { 1, 2, 3, 4 };
static foo2 fubar2 = { 1, 2 };
static intsizeofFubar1 = sizeof(foo1);
static intsizeofFubar2 = sizeof(foo2);
return 0;
}
end sample app ---
Compile the application with:
c++ -gstabs+ -O2 -mno-bit-align -mcpu=603 -mtune=603 -mstrict-align -nostdlib
-fno-use-cxa-atexit -fcheck-new -fno-rtti -fno-exceptions -fsigned-char -c
sampleApp.cc -o sampleApp.o
if you run objdump -D -C -s -x -z sampleApp.o you will see that:
sizeof(foo1) reports 6
sizeof(foo2) reports 8
even though the two structures are identical in size and alignment
requirements.
We have 6600 occurrances of the sizeof macro in our software, so manually
padding or using the __attribute__((aligned(4))) isn't very tempting to
overcome this problem.
Thanks!
--
Summary: sizeof macro appears broken when bitfields are in
structures
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mcvick_e at iname dot com
GCC build triplet: powerpc-eabi
GCC host triplet: x86_64-redhat-linux
GCC target triplet: powerpc-unknown-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug c++/28763] sizeof macro appears broken when bitfields are in structures
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-17 18:01 --- Actually I don't think they have the same alignment requirement. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug target/28763] sizeof macro appears broken when bitfields are in structures
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 18:04 --- Can you quote the ABI document that says they have the same alignment? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target Keywords||ABI http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug ada/28682] --enable-languages=c,c++ for cross compiler builds Ada compiler
--- Comment #1 from hjl at lucon dot org 2006-08-17 18:16 --- Wrong target is used for cross compiler build. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28682
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #10 from pcarlini at suse dot de 2006-08-17 18:40 --- Don't worry, the problem will be *certainly* resolved in time for the release: the issue is clear, we know in detail what's going wrong and how to fix it. Benjamin will. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug middle-end/28734] gather stats vs PCH
--- Comment #8 from Vladislav dot Mikhailikov at paradox-neo dot uz 2006-08-17 18:51 --- It seems that gcc-4.2 has the same problem. At least all .pch tests fail with that option set -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28734
[Bug c++/28670] reject valid? conversion from `int' to non-scalar type `Y&' requested.
--- Comment #2 from pluto at agmk dot net 2006-08-17 19:18 --- the `Y y2 = 2` requires two impicit user-defined conversions (realized by conv-ctors) but standard allows at most one. -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28670
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #13 from pluto at agmk dot net 2006-08-17 19:22 --- (In reply to comment #12) > The patch is wrong, you need something like > > -CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > +CFLAGS_FOR_TARGET = -O2 $(LIBCFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > > and similarly for CXXFLAGS. > this patch works for me. will anybody commit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #14 from bonzini at gnu dot org 2006-08-17 19:24 --- Please post to GCC Patches -- I am not a maintainer so I can't approve it anyway. Also, you need a ChangeLog entry, and the CXXFLAGS_FOR_TARGET needs the same treatment. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-17 19:24:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #4 from aeby at graeff dot com 2006-08-17 19:43 --- A bug tracker is not the right place to discuss philosophy questions, so if you'd like to continue the discussion, we should move over to e-mail or the gcj mailing list (lookout for subject: "GCJ 4.1.1 and static linking - SEGV"). However, my answer to your (Andrew) question is: - for portability: The binary I am building statically is supposed to work out-of-the-box on as many machines as ever possible - for stability: Some systems out there are known to have deficiencies, i.e. Debian/woody came with a not completely thread-safe glibc, so linking glibc statically solves these issues, too - for reproducibility: ask users that complain about issues in your software to try out the statically built version and if the problem stops you know you've found another combination of library versions your software does not work well with (or you can confirm that your software, not the runtime environment has a bug in the other case) > It will almost not work for other cases. I cannot confirm this. The project I'm trying to build statically with 4.1.1 is built statically for years with earlier gcc versions with less problems than the dynamic builds had ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug target/27075] [4.1/4.2 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE
--- Comment #16 from mmitchel at gcc dot gnu dot org 2006-08-17 20:29 --- I think the patch in Comment #8 is OK, but that the right approach would be to stop using %y to denote two different things. I think we should add documentation saying that %y has dual meanings and check in this patch. Then, as a separate issue, I think we should split %y into two different operand letters so that each has consitent semantics. I've CC'd the PowerPC maintainers on this PR. If neither of them object within 24 hours, please check in this patch. Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||dje at watson dot ibm dot ||com, geoffk at apple dot ||com, joseph at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075
bug: unknown register name `es' in `asm'
% gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.4/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
Thread model: posix
gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
Linux 2.6.9-22.0.1.EL #1 Thu Oct 27 10:38:16 CDT 2005 i686 i686 i386 GNU/Linux
% cc -Wall es.c
es.c: In function `main':
es.c:8: error: unknown register name `es' in `asm'
% cat es.i
# 1 "es.c"
# 1 ""
# 1 ""
# 1 "es.c"
int main()
{
unsigned short int segment;
char buf[80];
segment = (unsigned short int) (((unsigned long int) buf >> 16) & 0x);
asm volatile ("movw %0,%%es" : : "a" (segment) : "es");
}
[Bug target/28763] sizeof macro appears broken when bitfields are in structures
--- Comment #3 from mcvick_e at iname dot com 2006-08-17 22:17 --- Are you telling me that if I put two of those structures side by side in memory that GNU will mis-align them even though I pass the flag -mstrict-align? That couldn't possibly be since the align flag states to use strict type alignment. The GNU documentation also states that it will align to the smallest base type of the bitfield. Thus an 8-bit bitfield has 8-bit alignment, a 16-bit has 16-bit alignment, and a 32-bit has 32-bit alignment. In the example I have shown, it clearly shows that a 32-bit bitfield is defaulting to byte alignment as far as size allocation is concerned. I've ran objdump on the file, and even though the size is reported as smaller, it ALLOCATES all 32-bits for alignment reasons. According to the C-Speficiation (which applies to C++ as well) ... The size of an object of a structure type is the amount of storage necessary to represent all components of that type, including any unused padding space between or after the components. The rule is that the structure will be padded out to the size the type would occupy as an element of array of such types. So if you had an array of foo1's and an array of foo2's you would see exactly the same alignment in memory. Just that sizeof reports something incorrect. Thus if you were wanting to walk the array by say a byte pointer, and then went to increment that byte pointer by the sizeof the structure, in one case you would get correct behavior, and in the other you would get undefined or incorrect behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug target/28763] sizeof macro appears broken when bitfields are in structures
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-17 22:19 --- -mstrict-align does not do what you think it does. What it does is say the alignment requirements for loads/stores cannot be violated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug target/28763] sizeof macro appears broken when bitfields are in structures
--- Comment #5 from mcvick_e at iname dot com 2006-08-17 22:28 --- Additional information, if you insist on having an ABI then please go to this link and look at pages 3-8 and 3-9. It states that bitfields have the same alignment restrictions as their base types (int for int) (short for short) etc. http://refspecs.freestandards.org/elf/elfspec_ppc.pdf#search=%22powerpc%20abi%22 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug target/27565] [4.1/4.2 Regression] ICE in assign_stack_temp_for_type for vectors with SPE
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-08-17 22:34 --- The original simd-3.c still fails on mainline (my test compiler is configured with --enable-e500_double but it still appears with -mfloat-gprs=single) though the reduced test doesn't. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1 Regression] ICE in |[4.1/4.2 Regression] ICE in |assign_stack_temp_for_type |assign_stack_temp_for_type |for vectors with SPE|for vectors with SPE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27565
[Bug target/28763] sizeof macro appears broken when bitfields are in structures
--- Comment #6 from mcvick_e at iname dot com 2006-08-17 22:35 --- The spec also has multiple examples of big versus little endian layouts and how they map in memory and what their alignment is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug libgcj/28698] [gcj] libgcj-bc only used when building shared libs, not executables
--- Comment #2 from doko at ubuntu dot com 2006-08-17 22:40 --- ecj.jar is from eclipse-3.2, copied the file to http://people.ubuntu.com/~doko/ecj.jar gcj-4.2 -v \ -O2 -g -Wl,-Bsymbolic -shared -fPIC -fjni -findirect-dispatch \ -o /tmp/ecj.jar.so /usr/share/java/ecj.jar Using built-in specs. Reading specs from /usr/lib/gcc/i486-linux-gnu/4.2.0/libgcj.spec [...] gcc version 4.2.0 20060817 (experimental) (Ubuntu 4.2-20060817-0ubuntu1) gcj-4.2 -v \ -O2 -g -Wl,-Bsymbolic -fPIC -fjni -findirect-dispatch \ --main=org.eclipse.jdt.internal.compiler.batch.Main \ -o /tmp/ecj /usr/share/java/ecj.jar Using built-in specs. Reading specs from /usr/lib/gcc/i486-linux-gnu/4.2.0/libgcj.spec [...] objdump -x /tmp/ecj.jar.so | grep NEEDED NEEDED libgcc_s.so.1 NEEDED libgcj_bc.so.1 NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED librt.so.1 NEEDED libz.so.1 NEEDED libdl.so.2 NEEDED libc.so.6 objdump -x /tmp/ecj | grep NEEDED NEEDED libgcc_s.so.1 NEEDED libgcj_bc.so.1 NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED librt.so.1 NEEDED libz.so.1 NEEDED libdl.so.2 NEEDED libc.so.6 NEEDED libgcj.so.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28698
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #15 from pluto at agmk dot net 2006-08-17 23:39 --- (In reply to comment #13) > (In reply to comment #12) > > The patch is wrong, you need something like > > > > -CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > > +CFLAGS_FOR_TARGET = -O2 $(LIBCFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > > > > and similarly for CXXFLAGS. > > > > this patch works for me. will anybody commit? > argh, i've tested wrong patch. yours version doesn't work because of LIBCFLAGS=$(CFLAGS) in Makefile.in:290. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug target/28763] sizeof macro appears broken when bitfields are in structures
--- Comment #7 from mcvick_e at iname dot com 2006-08-18 00:03 --- (In reply to comment #4) > -mstrict-align does not do what you think it does. What it does is say the > alignment requirements for loads/stores cannot be violated. That's fine for the -mstrict-align, however as I stated in my last two comments the ABI for the Power PC state that this is clearly incorrect behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug rtl-optimization/28764] New: libjava build failure on sh4
I'd like to add Joern to the list.
sh4-unknown-linux-gnu build fails during libjave build with:
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.java:
In class 'javax.swing.plaf.basic.BasicTextUI':
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.java:
In method
'javax.swing.plaf.basic.BasicTextUI.modelToView(javax.swing.text.JTextComponent,int,javax.swing.text.Position$Bias)':
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.java:1213:
error: missing REG_EH_REGION note in the end of bb 15
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.java:1213:
error: in basic block 15:
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.java:1213:
error: flow control insn inside a basic block
(insn 87 86 267 15
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.java:1201
(set (reg:SI 173 [ D.182312 ])
(mem/f:SI (plus:SI (reg/f:SI 210)
(const_int 8 [0x8])) [15 S4 A32])) 176 {movsi_ie}
(insn_list:REG_DEP_TRUE 86 (nil))
(expr_list:REG_DEAD (reg/f:SI 210)
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.java:1213:
internal compiler error: in rtl_verify_flow_info_1, at cfgrtl.c:1945
It looks this starts just after the merge from the classpath 0.92.
gdb shows that the above basic block 15 looks like:
(note 85 278 86 15 [bb 15] NOTE_INSN_BASIC_BLOCK)
(insn 86 85 87 15 ./BasicTextUI.java:1201 (set (reg/f:SI 210)
(plus:SI (reg:SI 174 [ D.10115 ])
(const_int 64 [0x40]))) 41 {*addsi3_compact} (nil)
(expr_list:REG_DEAD (reg:SI 174 [ D.10115 ])
(nil)))
(insn 87 86 267 15 ./BasicTextUI.java:1201 (set (reg:SI 173 [ D.10117 ])
(mem/f:SI (plus:SI (reg/f:SI 210)
(const_int 8 [0x8])) [80 S4 A32])) 176 {movsi_ie}
(insn_list:REG_DEP_TRUE 86 (nil))
(expr_list:REG_DEAD (reg/f:SI 210)
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil
(insn 267 87 268 15 ./BasicTextUI.java:1201 (set (reg:SI 253)
(const:SI (unspec [
(symbol_ref:SI ("__fpscr_values") [flags 0x40] )
] 7))) -1 (nil)
(nil))
(insn 268 267 269 15 ./BasicTextUI.java:1201 (set (reg:SI 254)
(plus:SI (reg:SI 253)
(reg:SI 12 r12))) -1 (nil)
(nil))
(insn 269 268 270 15 ./BasicTextUI.java:1201 (set (reg:SI 252)
(mem/u/c:SI (reg:SI 254) [0 S4 A32])) -1 (nil)
(expr_list:REG_EQUAL (symbol_ref:SI ("__fpscr_values") [flags 0x40]
)
(nil)))
(insn 270 269 271 15 ./BasicTextUI.java:1201 (set (reg:SI 255)
(plus:SI (reg:SI 252)
(const_int 4 [0x4]))) -1 (nil)
(nil))
(insn 271 270 272 15 ./BasicTextUI.java:1201 (set (reg/f:SI 251)
(reg:SI 255)) -1 (nil)
(expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI ("__fpscr_values")
[flags 0x40] )
(const_int 4 [0x4])))
(nil)))
(insn 272 271 88 15 ./BasicTextUI.java:1201 (set (reg/v:PSI 151 )
(mem/s/c:PSI (reg/f:SI 251) [125 __fpscr_values+4 S4 A32])) -1 (nil)
(nil))
and insn 267-272 are inserted with emit_insn_after at mode-switching.c:633.
--
Summary: libjava build failure on sh4
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh4-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
[Bug libstdc++/28765] New: __gnu_cxx::__vstring::clear() is slow
Compile this code with -O2:
#include
void foo(__gnu_cxx::__vstring s)
{
s.clear();
}
Look at the resulting assembler code. Do not show it to small children. It is
too scary.
With this simple patch:
--- include/ext/sso_string_base.h (revision 116231)
+++ include/ext/sso_string_base.h (working copy)
@@ -540,7 +540,7 @@ _GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx)
}
template
-void
+inline void
__sso_string_base<_CharT, _Traits, _Alloc>::
_M_erase(size_type __pos, size_type __n)
{
I get this code:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
movl8(%ebp), %eax
movl$0, 4(%eax)
movl(%eax), %eax
movb$0, (%eax)
popl%ebp
ret
Much nicer.
I think this would be an appropriate fix, as _M_erase is not large. Another
possible fix would be to change clear to call _M_set_length(0).
--
Summary: __gnu_cxx::__vstring::clear() is slow
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
[Bug libstdc++/28765] __gnu_cxx::__vstring::clear() is slow
--- Comment #1 from pcarlini at suse dot de 2006-08-18 02:13 --- Hi Ian. Please go ahead with the inlining: only, from a stylistical point of view, please move the entire body inline, do not mark inline the out of line code. Patch preapproved, thanks a lot! -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ian at airs dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-18 02:13:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
[Bug objc/28049] [4.1/4.2 regression] ICE on single + or -
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-18 02:23 --- Actually I am going to implement the fix better, we really should be even calling c_parser_objc_method_decl at the toplevel of parsing. I think it was implemented this way because the old bison based parser did that. Very much related to PR 23710. The only issue now is that the correct way of fixing this will almost certain require a copyright assignment .. which is a problem. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||23710 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28049
[Bug objc/28049] [4.1/4.2 regression] ICE on single + or -
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-18 02:28 --- Actually no I am not going to fix this. Because it means I have to do a partical rewrite on how c_parser_external_declaration is done for objc and I am not going to do it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28049
[Bug target/27880] [4.2 regression] undefined reference to `_Unwind_GetIPInfo'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |schwab at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug target/27880] [4.2 regression] undefined reference to `_Unwind_GetIPInfo'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug web/28714] Bugzilla mail sent from invalid address
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-08-18 02:41 --- Should be fixed now -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714
[Bug libstdc++/28759] stringbuf writes beyond external buffer given via pubsetbuf()
--- Comment #4 from ngiff at yahoo dot com 2006-08-18 02:52 --- i guess i'm supposed to verify/close this... -- ngiff at yahoo dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28759
[Bug c/28418] [4.0/4.1/4.2 regression] ICE incrementing compound literal expression
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-18 03:20 ---
Wait a minute the C front-end produces for this testcase:
<<< Unknown tree: compound_literal_expr
struct A D.1524 = {.i=0}; >>>
.i = <<< Unknown tree: compound_literal_expr
struct A D.1524 = {.i=0}; >>>
.i + 1;
so obviously we are going to gimplify the compound_literal_expr twice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28418
[Bug c++/28766] New: compound literal expression vs templates
The following should be able to compile but does not:
struct A { int i; };
template
void foo()
{
((struct A) { 0 }).i += 1;
}
void g(void)
{
foo<0>();
}
If we remove the template on foo, the statement with compund literal expression
is accepted.
--
Summary: compound literal expression vs templates
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
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=28766
[Bug c++/28766] compound literal expression vs templates
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 03:30 --- This is not a regression as far as I can tell. Note I found this while working on PR 28418. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||2.95.3 3.0.4 3.2.2 3.2.3 ||3.3.1 4.0.0 3.4.0 4.2.0 Summary| compound literal expression|compound literal expression |vs templates|vs templates http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28766
[Bug c/28418] [4.0/4.1/4.2 regression] ICE incrementing compound literal expression
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-18 03:42 --- for +=/-= we could use PREINCREMENT_EXPR/PREDECREMENT_EXPR trees but for *=, /=, |=, ^=, we cannot use any of the above. I wonder if a SAVE_EXPR make this work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28418
[Bug c++/28450] [4.0/4.1/4.2 regression] ICE with new and complex/vector types
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 03:54 ---
Here is a patch (though I have looked to see if it works with templates yet):
Index: init.c
===
--- init.c (revision 116236)
+++ init.c (working copy)
@@ -178,7 +178,8 @@ build_zero_init (tree type, tree nelts,
items with static storage duration that are not otherwise
initialized are initialized to zero. */
;
- else if (SCALAR_TYPE_P (type))
+ else if (SCALAR_TYPE_P (type)
+ || TREE_CODE (type) == COMPLEX_TYPE)
init = convert (type, integer_zero_node);
else if (CLASS_TYPE_P (type))
{
@@ -248,6 +249,8 @@ build_zero_init (tree type, tree nelts,
/* Build a constructor to contain the initializations. */
init = build_constructor (type, v);
}
+ else if (TREE_CODE (type) == VECTOR_TYPE)
+init = fold_convert (type, integer_zero_node);
else
gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
--
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-08-18 03:54:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28450
[Bug c++/28450] [4.0/4.1/4.2 regression] ICE with new and complex/vector types
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-18 04:02 --- Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28450
[Bug driver/28528] [4.0/4.1/4.2 regression] Trouble compiling header files with "-x c++" using g++
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 04:06 ---
Confirmed, it did not work in 3.4.0 which almost means this was caused by the
PCH changes.
Janis could you do a regression hunt on this one. The best way I guess to do
this is to put "int main(void){}" in a .h file.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||janis at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||3.4.0 4.0.0 4.1.0 4.2.0
Known to work||3.3.3
Last reconfirmed|-00-00 00:00:00 |2006-08-18 04:06:27
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug debug/28767] New: GCC should output DW_TAG_ptr_to_member for member functions
For this code:
class A {
int f(void);
};
int (A::*ptr) (void);
GCC will output debug information claiming that the type of PTR is:
struct {
void (*__pfn) (args, ...);
ptrdiff_t __delta;
};
At least for dwarf2, GCC should output DW_TAG_ptr_to_member, just like it does
for data members.
The definition in the spec of DW_AT_use_location is pretty meaningless for
function members (that's come up on the dwarf list before, but was never
resolved, as far as I know), so it should probably be omitted.
This does not affect GDB much. Versions up to 6.5 have poor pointer to member
support. The next release will be better, but will also recognize GCC's
current broken debug information.
--
Summary: GCC should output DW_TAG_ptr_to_member for member
functions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28767
[Bug c++/28558] [4.0/4.1/4.2 regression] Trouble with new and __attribute__
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:13 --- Confirmed, we add the new attribute but we cannot convert between the types for some reason. I bet there is a way to reproduce this without using new too but I cannot find it. -- 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-08-18 04:13:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
[Bug debug/28767] GCC should output DW_TAG_ptr_to_member for member functions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:15 --- Confirmed, I am adding the keyword wrong-debug which almost true. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28767
