[Bug c/42206] New: ipa-prop.c: use of uninitialised local data
I just had a look at the source code of gcc version 4.5 snapshot 20091126 and I notice the following problem ~/gcc/20091126/src/gcc-4.5-20091126/gcc fgrep note_count ipa-prop.c int note_count; note_count++; lto_output_uleb128_stream (ob-main_stream, note_count); Please note that * line 1 of the fgrep output is an *un* initialised declaration of local variable note_count. * line 2 increments it * line 3 uses it. At the shallow level, the code is broken and local variable note_count needs initialisation, but at a deeper level this problem got through the -Werror mechanism of bootstrap. For the shallow level problem, maybe initialisation to zero would be sufficient. For the deeper level problem, I cannot help. -- Summary: ipa-prop.c: use of uninitialised local data Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42206
[Bug tree-optimization/42205] [4.5 Regression] internal compiler error: verify_ssa failed with -ffast-math -floop-interchange
--- Comment #2 from hjl dot tools at gmail dot com 2009-11-28 08:50 --- It is caused by revision 154561: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00784.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||spop at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-28 08:50:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42205
[Bug c++/36408] [4.3/4.4/4.5 regression] ICE with statement expression in template
--- Comment #15 from dodji at gcc dot gnu dot org 2009-11-28 09:22 --- I didn't look at this issue in a while. I just posted another attempt at http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01564.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug c++/6259] Explicit instantiation of template constructor not allowed
--- Comment #9 from reichelt at gcc dot gnu dot org 2009-11-28 11:03 --- Just for further reference: This was fixed by the patch for PR 9050. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6259
[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #8 from jakub at gcc dot gnu dot org 2009-11-28 12:12 --- Subject: Bug 42156 Author: jakub Date: Sat Nov 28 12:12:32 2009 New Revision: 154721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154721 Log: PR obj-c++/42156 * objc-act.c (objc_build_struct): INIT_TYPE_OBJC_INFO for type variants that don't have it initialized yet. Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug middle-end/42196] ICE when SRAing partial assigments to complex number
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-28 12:37:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42196
why are filenames wrong
Hello I downloaded the gcc-4-4-1, and to my dismay it didn't build. I am on 0x86, slackware 4.10, gcc 3.3.x. I ran in to errors caused by incorrect filenames. There were some places on the web mentioning this phenomena dating 2002 and others. I want to know, is this a newbie thing on gcc? I checked the MD5 signatures, and they are correct. I've had to recompile several times and altered my configuration and now I ran into another problem, I don't know what caused it as my gcc configuration seems to be messed up. Why nobody does something about this problem? the files usually are missing a letter on the end, so *.h becomes *. etc tags gcc termination file names -- View this message in context: http://old.nabble.com/why-are-filenames-wrong-tp26549870p26549870.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #26 from rearnsha at gcc dot gnu dot org 2009-11-28 14:38 --- (In reply to comment #25) Further tests show that you're right about the non working kernel. You should not use -march=iwmmxt (or -mcpu=something equivalent) when building the linux kernel. The kernel does not know how to save user-space context for iwmmxt on entry (it only saves co-processor state on context switches) so you will end up corrupting internal state. It's the same situation as trying to use floating-point hardware in the kernel -- basically, you can't, because the kernel is not set up to deal with it. Should the iwmmxt arch be disabled by default on GCC 4.5? At least it would make it clear that this arch is untested/not supported. I can't reproduce the problem on trunk with the testcase provided. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug fortran/20923] gfortran slow for large array constructors
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-11-28 15:10 --- Created an attachment (id=19170) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19170action=view) Third time is a charm This patch resolves the last remaining regression. Removing the didn't reduce error allows things to proceed to the exceeds maximum size error message expected by initialization_20.f90. It also triggers at the correct limit. I reworked one of the test conditions to assure that both gfc_check_constructor_type and gfc_expand_constructor (expr) are executed. I was not sure that was strictly neccessary, but I was suspicious of that logic that could eliminate one of the two in the OR. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Attachment #19161|0 |1 is obsolete|| Attachment #19168|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
[Bug fortran/42131] Weird translation of DO loops
--- Comment #19 from tkoenig at gcc dot gnu dot org 2009-11-28 15:16 --- (In reply to comment #18) Well, in that case you can as well rely on twos-complement arithmetic and avoid all the overflow issues? This is difficult without if statements or MAX_EXPR and MIN_EXPR, because I need to cover both ab and ba. I think I will go for calculating the difference in a larger size, if any is available, and a special case for do loops using the largest integer size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/20923] gfortran slow for large array constructors
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-11-28 15:16 --- With this simply modified case: program sel implicit none integer,parameter :: n=10 integer:: i,j,k,l real,dimension(n*n*n*n) :: vect vect(:) = (/ ( (i+j+k+l+3)),i=1,n),j=1,n),k=1,n),l=1,n) /) print *, vect end Compilation time is reduced by 1/2 with the patch. Other more complex examples need to be tested of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
[Bug middle-end/42202] [4.5 regression] Revision 154688 caused many gfortran failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42202
[Bug tree-optimization/42205] [4.5 Regression] internal compiler error: verify_ssa failed with -ffast-math -floop-interchange
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42205
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #27 from rearnsha at gcc dot gnu dot org 2009-11-28 15:56 --- Created an attachment (id=19171) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19171action=view) Proposed patch I think the attached should be a better patch than the one previously proposed. I don't have any real way to test this beyond the posted testcase, though, so I would be grateful if you could give it a more thorough kicking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #9 from jakub at gcc dot gnu dot org 2009-11-28 16:27 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug fortran/20923] gfortran slow for large array constructors
--- Comment #17 from dominiq at lps dot ens dot fr 2009-11-28 16:30 --- With the patch in comment #15 (gfc, gfc_c without), I see the following for the test [macbook] f90/bug% cat pr19925_1_db.f90 INTEGER, PARAMETER :: N=10 INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/) INTEGER, PARAMETER :: M(N)=I(N:1:-1) print *, I(1), M(1), I(N), M(N) END without (pr19925_1.f90)/with (pr19925_1_db.f90) the print line: [macbook] f90/bug% time gfc_c pr19925_1.f90 pr19925_1.f90:3.36: INTEGER, PARAMETER :: M(N)=I(N:1:-1) 1 Error: Initialization expression didn't reduce (1) 368.554u 0.801s 6:09.49 99.9% 0+0k 0+5io 0pf+0w [macbook] f90/bug% time gfc pr19925_1.f90 369.495u 0.629s 6:10.22 99.9% 0+0k 0+19io 0pf+0w [macbook] f90/bug% a.out [macbook] f90/bug% time gfc_c pr19925_1_db.f90 pr19925_1_db.f90:3.36: INTEGER, PARAMETER :: M(N)=I(N:1:-1) 1 Error: Initialization expression didn't reduce (1) 367.576u 0.591s 6:08.25 99.9% 0+0k 0+5io 0pf+0w [macbook] f90/bug% time gfc pr19925_1_db.f90 pr19925_1_db.f90:2.27: INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/) 1 Error: The number of elements in the array constructor at (1) requires an increase of the allowed 65535 upper limit. See -fmax-array-constructor option pr19925_1_db.f90: In function 'MAIN__': pr19925_1_db.f90:4:0: internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:3710 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. 369.184u 0.620s 6:09.87 99.9% 0+0k 0+5io 0pf+0w -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
[Bug c/42206] ipa-prop.c: use of uninitialised local data
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-28 16:31 --- Confirmed analysis and fix (initialize it to zero). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-28 16:31:16 date|| Summary|ipa-prop.c: use of |ipa-prop.c: use of |uninitialised local data|uninitialised local data http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42206
[Bug middle-end/42183] [4.5 Regression] internal compiler error: verify_stmts failed
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-28 16:54 --- I have a patch, the issue is latent on the branches (the verification is new). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-11-27 10:22:39 |2009-11-28 16:54:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug middle-end/42193] [4.5 Regression] 454.calculix in SPEC CPU 2006 failed to compile at -O3
--- Comment #3 from rth at gcc dot gnu dot org 2009-11-28 16:58 --- CC'ing you, Ira, since this is an SLP problem simply exposed by enabling permutation support in the target. -- rth at gcc dot gnu dot org changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42193
[Bug fortran/20923] gfortran slow for large array constructors
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-11-28 17:14 --- Created an attachment (id=19172) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19172action=view) Slightly modified charm This version handles Dominique's test case in comment #17. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
[Bug fortran/20923] gfortran slow for large array constructors
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-11-28 17:52 --- The patch in comment #18 passes all regression tests as well. I hope we are honing in on this. It does make me wonder why at this point the BT type is unknown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
[Bug fortran/42207] New: Compile-time errors on typed allocation and pointer function result assignment
After a fresh fortran-dev checkout, configure, make, and make install, the first two modules below compile correctly, while the third produces the the compile-time errors shown. The two offending lines are the allocate statement and the subsequent pointer assignment, both in the new_bar function. Based on the error message, this is related to vtabs. Apparently the error is platform-dependent since Janus reports compiling similar code with no problem. Damian $ cat foo.f03 module foo_module implicit none type foo end type end module $ cat bar.f03 module bar_module use foo_module implicit none type ,extends(foo) :: bar end type contains function bar_() type(bar) ,pointer :: bar_ bar_ = null() end function end module $ cat bar_factory.f03 module bar_factory_module implicit none type bar_factory contains procedure :: new_bar end type contains function new_bar(this) use bar_module use foo_module class(bar_factory), intent(in) :: this class(foo) ,pointer :: new_bar allocate(bar :: new_bar) new_bar = bar_() end function end module $ gfortran -c foo.f03 $ gfortran -c bar.f03 $ gfortran -c bar_factory.f03 /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:37:non-relocatable subtraction expression, _vtab$bar.1525 minus L001$pb /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:37:symbol: _vtab$bar.1525 can't be undefined in a subtraction expression /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:35:non-relocatable subtraction expression, _vtab$bar.1525 minus L001$pb /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:35:symbol: _vtab$bar.1525 can't be undefined in a subtraction expression -- Summary: Compile-time errors on typed allocation and pointer function result assignment Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net GCC build triplet: Mac OS X 10.5.8 GCC host triplet: Mac OS X 10.5.8 GCC target triplet: Mac OS X 10.5.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug fortran/42207] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #1 from sfilippone at uniroma2 dot it 2009-11-28 18:25 --- (In reply to comment #0) After a fresh fortran-dev checkout, configure, make, and make install, the first two modules below compile correctly, while the third produces the the Well, for me it works under linux (fedora 11) on both i686 (32 bits) and x86_64, on a fresh checkout of fortran-dev. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #87 from dominiq at lps dot ens dot fr 2009-11-28 18:40 --- With the combined proposed patches from comment 85, I do not see anymore dsymutil failures on (powerpc|i686)-apple-darwin9 and x86_64-apple-darwin10. From the failures in comment #8, I have noticed that 'gcc -g *' calls dsymutil, while neither 'gcc -g * -lm', nor 'gfortran -g *' call it. Is it the intended behavior? Last remark, I have called dsymutil for ~2000 fortran test and a few of them gives: warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4 Any comment about this warning? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #88 from howarth at nitro dot med dot uc dot edu 2009-11-28 18:45 --- Do you see this in gcc 4.4.2 as well? I would suggest trying to find a minimal test case that produces the warning from dsymutil and then open a new radar with the preprocessed source and the assembly generated with -dA for Apple to review. It may be harmless noise from dsymutil but we should definitely get it removed for the next Xcode release. Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #89 from dominiq at lps dot ens dot fr 2009-11-28 19:04 --- Do you see this in gcc 4.4.2 as well? No. A test case is [ibook-dhum] f90/bug% cat pr34231.f90 MODULE test TYPE odbase ; INTEGER :: value ; END TYPE INTERFACE odfname MODULE PROCEDURE odfamilycname,odfamilycnames END INTERFACE CONTAINS SUBROUTINE odfamilycnames(base,nfam,cnames) TYPE(odbase),INTENT(in) :: base INTEGER ,INTENT(out) :: nfam CHARACTER(*),INTENT(out) :: cnames(*) nfam=0 cnames(1:nfam)=' ' write(*,*) 'odfamilycnames' END SUBROUTINE SUBROUTINE odfamilycname(base,pos,cname) TYPE(odbase),INTENT(in) :: base INTEGER ,INTENT(in) :: pos CHARACTER(*),INTENT(out) :: cname cname=' ' write(*,*) 'odfamilycname' END SUBROUTINE END MODULE PROGRAM main USE test TYPE(odbase) :: base INTEGER :: i=1 CHARACTER(8) :: cname CALL odfname(base,i,cname) END PROGRAM ibook-dhum] f90/bug% gfc -c -o pr34231.o -O3 -g pr34231.f90 [ibook-dhum] f90/bug% gfc pr34231.o [ibook-dhum] f90/bug% dsymutil a.out warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4 [ibook-dhum] f90/bug% gfc44 -c -o pr34231.o -O3 -g pr34231.f90 [ibook-dhum] f90/bug% gfc44 pr34231.o [ibook-dhum] f90/bug% dsymutil a.out [ibook-dhum] f90/bug% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/34272] ICE with invalid template specialization
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-28 19:05 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01568.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34272
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #90 from howarth at nitro dot med dot uc dot edu 2009-11-28 19:07 --- Since dsymutil isn't asserting, I wouldn't be so worried unless the test cases start to fail. Do file a radar though with at least assembly with -dA so that Apple can review what is happening. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug middle-end/42183] [4.5 Regression] internal compiler error: verify_stmts failed
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-28 19:11 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug middle-end/42183] [4.5 Regression] internal compiler error: verify_stmts failed
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-28 19:11 --- Subject: Bug 42183 Author: rguenth Date: Sat Nov 28 19:11:22 2009 New Revision: 154728 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154728 Log: 2009-11-28 Richard Guenther rguent...@suse.de PR tree-optimization/42183 * tree-nrv.c (tree_nrv): Bail out if the RESULT_DECL has its address taken. Merge the addressable state of the NRV variable and the result instead of copying it. * g++.dg/torture/pr42183.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr42183.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-nrv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug target/42208] New: gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib
While trying to walk through the unwinder under darwin9 in current gcc trunk, I discovered that we are now linking against multiple libgcc in all of the shared libraries... otool -L libffi.4.dylib libffi.4.dylib: /sw/lib/gcc4.5/lib/libffi.4.dylib (compatibility version 5.0.0, current version 5.1.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) except for /usr/lib/libgcc_s.1.dylib itself. This is very bad and breaks the ability to walk through the unwinder in darwin9 (which works in gcc 4.4.2 that doesn't show this problem). -- Summary: gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin* GCC host triplet: x86_64-apple-darwin* GCC target triplet: x86_64-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42208
[Bug target/42208] gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-11-28 19:53 --- /sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/ -B/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/sys-include -dynamiclib -o .libs/libssp.0.dylib .libs/ssp.o .libs/gets-chk.o .libs/memcpy-chk.o .libs/memmove-chk.o .libs/mempcpy-chk.o .libs/memset-chk.o .libs/snprintf-chk.o .libs/sprintf-chk.o .libs/stpcpy-chk.o .libs/strcat-chk.o .libs/strcpy-chk.o .libs/strncat-chk.o .libs/strncpy-chk.o .libs/vsnprintf-chk.o .libs/vsprintf-chk.o -v -install_name /sw/lib/gcc4.5/lib/libssp.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module Reading specs from /sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/specs COLLECT_GCC=/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/gcc/xgcc COLLECT_LTO_WRAPPER=/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/lto-wrapper Target: x86_64-apple-darwin9.8.0 Configured with: ../gcc-4.5-20091127/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib Thread model: posix gcc version 4.5.0 20091127 (experimental) (GCC) COMPILER_PATH=/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/ LIBRARY_PATH=/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-B/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/' '-B/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/bin/' '-B/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/lib/' '-isystem' '/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/include' '-isystem' '/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/sys-include' '-Zdynamiclib' '-o' '.libs/libssp.0.dylib' '-v' '-Zinstall_name' '/sw/lib/gcc4.5/lib/libssp.0.dylib' '-compatibility_version' '1' '-current_version' '1.0' '-mtune=generic' /sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/collect2 -dynamic -dylib -dylib_compatibility_version 1 -dylib_current_version 1.0 -arch x86_64 -dylib_install_name /sw/lib/gcc4.5/lib/libssp.0.dylib -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o .libs/libssp.0.dylib -ldylib1.10.5.o -L/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc .libs/ssp.o .libs/gets-chk.o .libs/memcpy-chk.o .libs/memmove-chk.o .libs/mempcpy-chk.o .libs/memset-chk.o .libs/snprintf-chk.o .libs/sprintf-chk.o .libs/stpcpy-chk.o .libs/strcat-chk.o .libs/strcpy-chk.o .libs/strncat-chk.o .libs/strncpy-chk.o .libs/vsnprintf-chk.o .libs/vsprintf-chk.o -single_module -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lSystem COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-B/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/' '-B/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/bin/' '-B/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/lib/' '-isystem' '/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/include' '-isystem' '/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/sys-include' '-Zdynamiclib' '-o' '.libs/libssp.0.dylib' '-v' '-Zinstall_name' '/sw/lib/gcc4.5/lib/libssp.0.dylib' '-compatibility_version' '1' '-current_version' '1.0' '-mtune=generic' /sw/src/fink.build/gcc44-4.4.2-1000/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc44-4.4.2-1000/darwin_objdir/./gcc/ -B/sw/lib/gcc4.4/x86_64-apple-darwin9/bin/ -B/sw/lib/gcc4.4/x86_64-apple-darwin9/lib/ -isystem /sw/lib/gcc4.4/x86_64-apple-darwin9/include -isystem /sw/lib/gcc4.4/x86_64-apple-darwin9/sys-include -dynamiclib -o .libs/libssp.0.dylib .libs/ssp.o .libs/gets-chk.o .libs/memcpy-chk.o .libs/memmove-chk.o .libs/mempcpy-chk.o .libs/memset-chk.o .libs/snprintf-chk.o .libs/sprintf-chk.o .libs/stpcpy-chk.o .libs/strcat-chk.o .libs/strcpy-chk.o .libs/strncat-chk.o .libs/strncpy-chk.o .libs/vsnprintf-chk.o .libs/vsprintf-chk.o -install_name /sw/lib/gcc4.4/lib/libssp.0.dylib -v -compatibility_version 1 -current_version 1.0 -Wl,-single_module Reading specs from /sw/src/fink.build/gcc44-4.4.2-1000/darwin_objdir/./gcc/specs Target: x86_64-apple-darwin9 Configured with: ../gcc-4.4.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=x86_64-apple-darwin9 --host=x86_64-apple-darwin9 --target=x86_64-apple-darwin9 Thread model: posix gcc version 4.4.2 (GCC) COMPILER_PATH=/sw/src/fink.build/gcc44-4.4.2-1000/darwin_objdir/./gcc/
[Bug target/42208] gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-11-28 20:04 --- A coarse regression check shows that this problem didn't exist on 20090928 but did on 20090930. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42208
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #20 from andreast at gcc dot gnu dot org 2009-11-28 20:14 --- Jack, can you point DYLD_LIBRARY_PATH to your installed libgcc_s.dylib and try to run a gcj -C testme.java? I did so with todays trunk and the patch from lxo (Alex), the one you sent me as well as mine from comment #3 [deuterium:~] andreast% setenv DYLD_LIBRARY_PATH /Volumes/development/gcc/head/testbin-x86_64/lib [deuterium:~] andreast% gcj -C hello.java [deuterium:~] andreast% gij hello Hello World Hello Andreas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug fortran/42207] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #2 from dominiq at lps dot ens dot fr 2009-11-28 20:18 --- On darwin, the errors appear only in 32 bit mode. I am sure that I have already seen such errors in the past, but I cannot remember where or when!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2009-11-28 20:25 --- Andreas, Actually we have another issue at the moment. See [Bug target/42208]. It appears that at some point in late Sept or earlier Oct, darwin starting linking both the system and the gcc built libgcc into its shared library. I am trying to puzzle out when it started to occur. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #22 from andreast at gcc dot gnu dot org 2009-11-28 20:27 --- I follow this one too, that is why I ask! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug target/42208] gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-11-28 20:28 --- This is weird. I tested r152433 and r152434 last week to pin down another regression and neither show the issue. Either I have some misdated builds or this issue has been latent at times. Will do a regression check for around Oct 3rd and 4th. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42208
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-11-28 20:32 --- No luck here with setting... setenv DYLD_LIBRARY_PATH /sw/lib/gcc4.5/lib I suspect this can randomly pass in some cases as you have seen before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug target/42208] gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-11-28 21:09 --- Doh! I bet this is caused by Iain's libgcc_ext patch. http://gcc.gnu.org/viewcvs/trunk/libgcc/config/t-slibgcc-darwin?r1=154282r2=154281pathrev=154282 Specifically the section... INSTALL_FILES=libgcc_s.10.4.dylib libgcc_s.10.5.dylib libgcc_s.1.dylib +# we're only going to build the stubs if the target slib is /usr/lib +# there is no other case in which they're useful in a live system. +ifeq (/usr/lib,$(shlib_slibdir)) +LGCC_STUBS = libgcc_s.10.4.dylib libgcc_s.10.5.dylib +else +LGCC_STUBS = +endif I don't think this was properly thought through. By not building the stubs, the ones in /usr/lib get used and we start linking in two different libgcc's. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42208
[Bug target/42208] gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-11-28 21:21 --- Testing... Index: libgcc/config/t-slibgcc-darwin === --- libgcc/config/t-slibgcc-darwin (revision 154730) +++ libgcc/config/t-slibgcc-darwin (working copy) @@ -26,13 +26,8 @@ SHLIB_MKMAP_OPTS = -v leading_underscore=1 SHLIB_MAPFILES += $(gcc_srcdir)/libgcc-std.ver -# we're only going to build the stubs if the target slib is /usr/lib -# there is no other case in which they're useful in a live system. -ifeq (/usr/lib,$(shlib_slibdir)) +# Must always build stubs so that FSF libgcc is used. LGCC_STUBS = libgcc_s.10.4.dylib libgcc_s.10.5.dylib -else -LGCC_STUBS = -endif LGCC_FILES = libgcc_s.$(SHLIB_SOVERSION)$(SHLIB_EXT) LGCC_FILES += $(LGCC_STUBS) against current gcc trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42208
[Bug target/42208] gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-11-28 21:41 --- Iain says this was intended behavior, but I'll rerun it past Mike Stump to make certain that he fully understood this would happen (as he doesn't actually build FSF gcc anymore). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42208
[Bug tree-optimization/42205] [4.5 Regression] internal compiler error: verify_ssa failed with -ffast-math -floop-interchange
--- Comment #3 from zsojka at seznam dot cz 2009-11-28 22:46 --- The problem appears with following flags as well: -O1 -floop-strip-mine -ffast-math -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42205
[Bug c++/36408] [4.3/4.4/4.5 regression] ICE with statement expression in template
--- Comment #16 from dodji at gcc dot gnu dot org 2009-11-28 22:56 --- Subject: Bug 36408 Author: dodji Date: Sat Nov 28 22:55:52 2009 New Revision: 154731 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154731 Log: Fix PR c++/36408 gcc/cp/ChangeLog: PR c++/36408 * cp-tree.h (empty_expr_stmt_p): Declare ... * semantics.c (empty_expr_stmt_p): ... this. * pt.c (tsubst_copy_and_build) STMT_EXPR: Use it. gcc/testsuite/ChangeLog: PR c++/36408 * g++.dg/template/stmtexpr2.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/stmtexpr2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug c++/36408] [4.3/4.4/4.5 regression] ICE with statement expression in template
--- Comment #17 from dodji at gcc dot gnu dot org 2009-11-28 22:58 --- Fixed in 4.5 I don't plan to fix it in the branches. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty
--- Comment #6 from jzwinck at gmail dot com 2009-11-28 22:59 --- The same bug has recently been raised in Boost's implementation of unordered containers: https://svn.boost.org/trac/boost/ticket/3693 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-11-28 23:01 --- I figured out for darwin9 that the dual linkage to the system libgcc and the FSF libgcc from... http://gcc.gnu.org/viewcvs?view=revisionrevision=154283 http://gcc.gnu.org/viewcvs?view=revisionrevision=154282 was causing the system libgcc to be used (which lacks debug code). I will have a complete walk soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #28 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-11-28 23:08 --- Created an attachment (id=19173) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19173action=view) arm-linux-gnueabi-gcc -march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt -std=gnu99 -c -O2 libc_fatal.i Patch generates inefficient code; e.g. it emits now 568: ee183110tmrcr3, wcgr0 56c: e1a0d003mov sp, r3 which could be written directly as tmrc sp, wcgr0 when allowing a ['rk','z'] constraint. The new ICE mentioned in comment #20 still happens with this patch. But this seems to be a dup of bug #37987 which exists for earlier gcc versions too. I attached a testcase for completeness. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug target/37987] iwmmxt: insn does not satisfy its constraints on (int64_t)
--- Comment #7 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-11-28 23:15 --- ICE has been verified with gcc 4.4.2. Some analysis have been done in bug #40836 (comments 20 + 21): the WLDRW operation which would be required for this insn allows only 10 (effective 8) bit but not 12 bit for the immediate offset. E.g. the '-3888' in WLDRW wcgr0, [fp, #-3888] is not possible. -- enrico dot scholz at informatik dot tu-chemnitz dot de changed: What|Removed |Added CC||enrico dot scholz at ||informatik dot tu-chemnitz ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37987
[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-28 23:16 --- An implementation is probably expected to shrink bucket_count when size shrinks, so the complexity should still be O(size). That would be good for memory use anyway, so why's that not done? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug c++/42209] New: missed optimization leads to several times slower code
This is not a correctness bug, this is a performance problem.
It appears constant propagation is inconsistent, causing a routine to be
inlined and simplified some places and not others. Code of the form
a(..., ~0x3)
for i=1..n
a(..., ~0)
a(..., 0x0fff)
inlines and simplifies the call with ~0 as an arg, but not the others.
Unfortunately, a() if inlined and simplified would reduce to about 4 machine
instructions, but the out-of-line call is about 80 static instructions with a
path length of about 20 instructions including an indirect branch. For small
values of 'n', the out-of-line call dominates execution time of this routine.
Following is complete source code (no headers) and the output of g++ -v. Note
that many small source changes cause the symptom to go away, such as manually
eliminating dead code (that otherwise GCC determines is dead and eliminates).
This smells like there is an optimization threshold and beyond some level of
source complexity the threshold is not reached.
#define CHAR_BIT (8)
templatetypename T, typename size_t
size_t bitsizeof() { return CHAR_BIT * sizeof(T); }
templatetypename T
unsigned bitsizeof() { return bitsizeofT, unsigned(); }
templatetypename word_t
word_t ALLONES() { return ~static_castword_t(0); }
templatetypename word_t, typename offset_t, typename bitlen_t
static bool is_ltoh(bool might_overlap,
const word_t *dst, offset_t doff,
const word_t *src, offset_t soff,
bitlen_t bitlen) {
if (!might_overlap)
return true;
if (dst = src) {
return true;
} else /* (dst src) */ {
const unsigned WORDSIZE = bitsizeofword_t();
const word_t *srclast = src + (soff + bitlen) / WORDSIZE;
return srclast dst;
}
}
typedef unsigned char op_t;
const op_t SRC = 0xC;
const op_t DST = 0xA;
const op_t SET = 0xF;
templatetypename word_t
static word_t switch_case(op_t op, word_t d, word_t s, word_t dst_mask) {
switch(op) {
case 0 0xF: d = ~dst_mask; break; // 0
case ~(DST|SRC) 0xF: d ^= ((~s | d) dst_mask); break; // 1
case DST~SRC0xF: d ^= (( s d) dst_mask); break; // 2
case ~SRC0xF: d ^= ((~s ^ d) dst_mask); break; // 3
case ~DSTSRC0xF: d ^= (( s | d) dst_mask); break; // 4
case ~DST0xF: d ^= dst_mask; break; // 5
case (DST^SRC) 0xF: d ^= ( s dst_mask); break; // 6
case ~(DSTSRC) 0xF: d ^= (( s | ~d) dst_mask);break; // 7
case DSTSRC 0xF: d ^= ((~s d) dst_mask);break; // 8
case ~(DST^SRC) 0xF: d ^= (~s dst_mask); break; // 9
case DST 0xF: break; // 10
case (DST|~SRC) 0xF: d |= (~s dst_mask); break; // 11
case SRC 0xF: d ^= (( s ^ d) dst_mask); break; // 12
case (~DST|SRC) 0xF: d ^= (~(s d) dst_mask); break; // 13
case (DST|SRC) 0xF: d |= (s dst_mask);break; // 14
case SET 0xF: d |= dst_mask; break; // 15
default:
; // NOT REACHED
}
return d;
}
templatetypename word_t, typename offset_t, typename bitlen_t
static void ltoh_MtoN_down(op_t op, word_t *di, const word_t *si, word_t
lo_mask, word_t hi_mask, unsigned ts, bitlen_t n1, bool more_src_words) {
unsigned bs = bitsizeofword_t() - ts;
word_t top = si[1];
word_t s = (top ts) | (si[0] bs);
di[0] = switch_case(op, di[0], s, lo_mask);
for (bitlen_t i=1; in1; ++i) {
word_t bot = top;
top = si[i+1];
s = top ts | bot bs;
di[i] = switch_case(op, di[i], s, ALLONESword_t());
}
s = top bs;
if (more_src_words)
s |= (si[n1+1] ts);
di[n1] = switch_case(op, di[n1], s, hi_mask);
}
templatetypename word_t, typename offset_t, typename bitlen_t
static void htol_MtoN_down(op_t op, word_t *di, const word_t *si, word_t
lo_mask, word_t hi_mask, unsigned ts, bitlen_t n1, bool one_more_src_word) {
unsigned bs = bitsizeofword_t() - ts;
word_t bot = si[n1];
word_t s = bot bs;
if (one_more_src_word)
s |= si[n1+1] ts;
di[n1] = switch_case(op, di[n1], s, hi_mask);
for (offset_t i=n1-1; i0; --i) {
word_t top = bot;
bot = si[i];
s = top ts | bot bs;
di[i] = switch_case(op, di[i], s, ALLONESword_t());
}
s = (bot ts) | (si[0] bs);
di[0] = switch_case(op, di[0], s, lo_mask);
}
templatetypename word_t, typename offset_t, typename bitlen_t
void mem(word_t *di, offset_t doff, const word_t *si, offset_t soff,
bitlen_t bitlen, op_t op, bool might_overlap=true) {
const offset_t WS = bitsizeofword_t,offset_t();
const word_t WORDMASK = WS - 1;
di += doff / WS;
doff %= WS;
si += soff / WS;
soff %= WS;
const word_t ONES = ALLONESword_t();
word_t lo_mask = ONES doff;
word_t hi_mask = ONES (WORDMASK - ((doff + bitlen - 1) WORDMASK));
bool one_word = doff + static_castoffset_t(bitlen) = WS;
if (soff == doff) {
} else if
[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty
--- Comment #8 from sjackman at gmail dot com 2009-11-29 00:44 --- I wouldn't depend on the number of buckets shrinking. Shrinking (and growing) a hash table is an expensive operation that requires rehashing all the elements in the hash table. Even if the implementation does provide the ability to shrink the hash table, a number of applications would disable it. Google sparsehash provides min_load_factor for this purpose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug c/42210] New: avr: optimizing assignment to a bit field
When assigning a bool to a single bit of a bitfield located in the
bit-addressable region of memory, better code is produced by
if (flag)
bitfield.bit = true;
else
bitfield.bit = false;
than
bitfield.bit = flag;
I've included a short test and the assembler output by both forms.
Should I file a bug suggesting a possible improvement here?
Cheers,
Shaun
#include stdbool.h
#include stdint.h
struct byte { uint8_t x0:1; uint8_t x1:1; uint8_t x2:1; uint8_t x3:1;
uint8_t x4:1; uint8_t x5:1; uint8_t x6:1; uint8_t x7:1; };
volatile struct byte *const porte = (void*)0x23;
void set_flag_good(bool flag)
{
if (flag)
porte-x6 = true;
else
porte-x6 = false;
}
void set_flag_bad(bool flag)
{
porte-x6 = flag;
}
set_flag_good:
0: 88 23 and r24, r24
2: 01 f4 brne.+0 ; 0x4 set_flag_good+0x4
2: R_AVR_7_PCREL.text+0x8
4: 1e 98 cbi 0x03, 6 ; 3
6: 08 95 ret
8: 1e 9a sbi 0x03, 6 ; 3
a: 08 95 ret
000c set_flag_bad:
c: 81 70 andir24, 0x01 ; 1
e: 82 95 swapr24
10: 88 0f add r24, r24
12: 88 0f add r24, r24
14: 80 7c andir24, 0xC0 ; 192
16: 93 b1 in r25, 0x03 ; 3
18: 9f 7b andir25, 0xBF ; 191
1a: 98 2b or r25, r24
1c: 93 b9 out 0x03, r25 ; 3
1e: 08 95 ret
--
Summary: avr: optimizing assignment to a bit field
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42210
[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty
--- Comment #9 from sstrasser at systemhaus-gruppe dot de 2009-11-29 02:29 --- (In reply to comment #7) An implementation is probably expected to shrink bucket_count when size shrinks, so the complexity should still be O(size). That would be good for memory use anyway, so why's that not done? shrinking invalidates iterators, doesn't it? erase() is specified not to invalidate iterators. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug fortran/42207] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #3 from damian at rouson dot net 2009-11-29 02:50 --- (In reply to comment #2) On darwin, the errors appear only in 32 bit mode. I am sure that I have already seen such errors in the past, but I cannot remember where or when!-( Thanks for all of your help. So how do I switch to 64-bit mode? Damian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug c++/36408] [4.3/4.4/4.5 regression] ICE with statement expression in template
--- Comment #18 from hjl dot tools at gmail dot com 2009-11-29 04:08 --- The testcase failed on Linux/ia32: FAIL: g++.dg/template/stmtexpr2.C (test for errors, line 10) FAIL: g++.dg/template/stmtexpr2.C (test for errors, line 17) -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2009-11-29 07:41 --- Created an attachment (id=19174) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174action=view) gdb walk through w_frame_state_for calls in unwinder -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2009-11-29 07:48 --- I finally managed to sort out the darwin build to get access to the unwinder debug symbols. Walking through the testme.java test case using the _Unwind_RaiseException 39 times, I then used a uw_frame_state_for to be able to sample the frames with 'x context.ra'. A full log of this is attached as walk_thru_breakpts.txt. The output for each instance of 'x context.ra' is listed below... 0x100013576 _Jv_Throw+70: 0x9816e9e8 0x1004357c5 _ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+1253: 0x00458b49 0x10040c8aa _ZN4java4lang11ClassLoader9loadClassEJPNS0_5ClassEPNS0_6StringEb+314: 0x75e9 0x10040c888 _ZN4java4lang11ClassLoader9loadClassEJPNS0_5ClassEPNS0_6StringEb+280: 0x89449feb 0x100013576 _Jv_Throw+70: 0x9816e9e8 0x1004357c5 _ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+1253: 0x00458b49 0x10040c8aa _ZN4java4lang11ClassLoader9loadClassEJPNS0_5ClassEPNS0_6StringEb+314: 0x75e9 0x103daa6fe _Unwind_Resume+61:0xc0958d48 0x10040c8c7 _ZN4java4lang11ClassLoader9loadClassEJPNS0_5ClassEPNS0_6StringEb+343: 0x01ea8348 0x10040c888 _ZN4java4lang11ClassLoader9loadClassEJPNS0_5ClassEPNS0_6StringEb+280: 0x89449feb (gdb) c Continuing. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x000103f05db0 0x000103f05db0 in ?? () at .././libjava/../gcc/unwind-pe.h:104 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
