[Bug rtl-optimization/42258] [4.5 Regression] redundant register move around mul instruction
--- Comment #2 from steven at gcc dot gnu dot org 2009-12-31 09:32 --- http://gcc.gnu.org/viewcvs?view=revision&revision=152533 -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||22072 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
[Bug target/42564] New: ICE on sparc - unrecognizable insn
seen with current branches and trunk when building libcap-ng on sparc/sparc64.
the file builds without -fPIC or with -O0.
Matthias
$ gcc-4.4 -c -O2 -fPIC cap-ng.i
cap-ng.c: In function 'init':
cap-ng.c:154: error: unrecognizable insn:
(insn 18 17 19 4 cap-ng.c:139 (set (reg:SI 117)
(lo_sum:SI (reg:SI 117)
(unspec:SI [
(symbol_ref:SI ("m") [flags 0x1a] )
] 0))) -1 (nil))
cap-ng.c:154: internal compiler error: in extract_insn, at recog.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: ICE on sparc - unrecognizable insn
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
[Bug target/42564] ICE on sparc - unrecognizable insn
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-31 10:20 --- Created an attachment (id=19429) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19429&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #39 from krebbel at gcc dot gnu dot org 2009-12-31 10:31 --- Ok. That looks good. I think the S/390 problem from comment #33 got fixed with that patch: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01392.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug c++/41779] Spurious integral promotion
--- Comment #2 from zweije at xs4all dot nl 2009-12-31 11:01 --- I beg to differ. I cannot find where the standard says that unsigned short *always* promotes to int in rvalue contexts. My reading in more detail is: 1. The value of y is an lvalue of type unsigned short (5.1/7). 2. 13.3.1.2/7 mentions (effectively) promoting the operands (because built-in candidates (13.6/12) have promoted arguments), but it applies only when the built-in multiplication has been selected by overload resolution. This is not the case, because there are no class or enum arguments. 3. Therefore, clause 5 applies directly (13.3.1.2/1). 4. Clause 5 in itself does not require promoted operands (5.6/2), and does not distinguish lvalues from rvalues. Therefore the value of y is promoted directly to an lvalue of type float, through the usual arithmetic conversion (5/9). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41779
[Bug middle-end/42559] [4.5 Regression] ice in emit_block_move_hints with -O2
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 11:05 --- Needs similar fix for LABEL_DECL. Mine. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-31 11:05:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42559
[Bug middle-end/42559] [4.5 Regression] ice in emit_block_move_hints with -O2
-- 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=42559
[Bug rtl-optimization/42258] [4.5 Regression] redundant register move around mul instruction
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 11:11 --- But the patch was backported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
[Bug tree-optimization/41956] Segfault in vectorizer
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2009-12-31 11:21 --- Confirmed as fixed on x86_64-apple-darwin10 at rev. 155523. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41956
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-31 11:39 --- I am now seeing... FAIL: gfortran.dg/gomp/recursion1.f90 -Os execution test at r155534 that wasn't present at r155526 so the proposed fix appears to have caused a gfortran regression on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug c++/27102] [4.1 regression] ICE with invalid class name in function template
--- Comment #20 from paolo dot carlini at oracle dot com 2009-12-31 11:57 --- *** Bug 42563 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||thomasd57 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/42563] internal compiler error in is_ancestor, at cp/name-lookup.c
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-31 11:57 --- A very old issue. In general, before filing in Bugzilla, do a search, and in any case never file issues vs old unmaintained release branches, thanks. *** This bug has been marked as a duplicate of 27102 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42563
[Bug c/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #9 from nospamname at web dot de 2009-12-31 13:35 --- I compile now with a m68k-elf Compiler and do the small testcode i post above.The Problem is same on m68k-elf Compiler too. other CPU as -m68000 fail with -O3 or -O2 So can this Report Reopen and maybe another can check please ? Andreas have not write with what CPU Setting he get the WORKSFORME Result. Here is the Output m68k-elf-gcc.exe -c wb2.c -o "Default Profile/wb2.o" -I"E:/amiga/AmiDevCpp/bernd/clib2/" -m68020-60 -v -S -O3 Using built-in specs. COLLECT_GCC=/usr/local/amiga/bin/m68k-elf-gcc COLLECT_LTO_WRAPPER=/usr/local/amiga/bin/../libexec/gcc/m68k-elf/4.5.0/lto-wrapper.exe Target: m68k-elf Configured with: /bernd/gcc4/configure --target=m68k-elf Thread model: single gcc version 4.5.0 20091224 (experimental) (GCC) COLLECT_GCC_OPTIONS='-c' '-o' 'Default Profile/wb2.o' '-IE:/amiga/AmiDevCpp/bernd/clib2/' '-m68020-60' '-v' '-S' '-O3' ... GNU C (GCC) version 4.5.0 20091224 (experimental) (m68k-elf) compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version 4.2.3, MPFR and teh Result of -S is this #NO_APP .file "wb2.c" .section.rodata .LC0: .string "%ld\n" .text .align 2 .globl main .type main, @function main: move.l %fp,-(%sp) move.l %sp,%fp clr.l 12(%fp) move.l #.LC0,8(%fp) unlk %fp jra printf .size main, .-main .ident "GCC: (GNU) 4.5.0 20091224 (experimental)" --- COLLECT_GCC_OPTIONS='-c' '-o' 'Default Profile/wb2.o' '-IE:/amiga/AmiDevCpp/bernd/clib2/' '-m68000' '-v' '-S' '-O3' with CPU m68000 or -O1 or -O0 this work ok. #NO_APP .file "wb2.c" .section.rodata .LC0: .string "%ld\n" .text .align 2 .globl main .type main, @function main: link.w %fp,#0 move.l 8(%fp),%a0 move.l 4(%a0),%a0 cmp.b #70,(%a0) jeq .L10 .L7: moveq #0,%d0 move.l %d0,12(%fp) move.l #.LC0,8(%fp) unlk %fp jra printf .L10: cmp.b #76,1(%a0) jne .L7 cmp.b #86,2(%a0) jne .L7 cmp.b #4,3(%a0) jhi .L7 tst.b 5(%a0) jne .L7 moveq #0,%d1 move.b 6(%a0),%d1 swap %d1 clr.w %d1 moveq #0,%d0 move.b 7(%a0),%d0 lsl.l #8,%d0 or.l %d1,%d0 or.b 8(%a0),%d0 moveq #8,%d1 cmp.l %d0,%d1 jcc .L7 moveq #100,%d0 move.l %d0,12(%fp) move.l #.LC0,8(%fp) unlk %fp jra printf .size main, .-main .ident "GCC: (GNU) 4.5.0 20091224 (experimental)" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug debug/42565] New: Huge compilation time with -O1 -g
I tried to compile KDE 4.3.4 with gcc-r155523. The compilation stalled at file globalsettings_base.cpp, which took more than 40 minutes to compile (actually, it could have taken more, because I've simply aborted it). In the attachement you will find the preprocessed version of this file. Sorry to have included such a huge file, but it seems impossible to comment out some parts of it because doing so greatly reduces the compilation time. To reproduce, do $ gcc -x c++ -c -O1 -g -o bug.o bug.i It seems this problem has something to do with debug info generation for optimized binaries, because omitting -O1 or -g makes the problem disappear. -- Summary: Huge compilation time with -O1 -g Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: i686-slackware-linux GCC host triplet: i686-slackware-linux GCC target triplet: i686-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42565
[Bug debug/42565] Huge compilation time with -O1 -g
--- Comment #1 from aanisimov at inbox dot ru 2009-12-31 13:40 --- Created an attachment (id=19430) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19430&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42565
[Bug lto/42528] ICE with -flto and -fsigned-char
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:08 --- Confirmed on i?86-linux with -funsigned-char instead. I'll have a looksee. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2009-12-31 15:08:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42528
[Bug tree-optimization/42521] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c:2844
-- 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=42521
[Bug lto/42531] FAIL: gcc.c-torture/compile/20011119-1.c
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-31 15:12 --- Revision 155528 caused: FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link, (internal compiler error) One error is c_lto_20081222_0.wpa.ltrans.o: In function `main': c_lto_20081222_0.wpa.o:(.text+0x7): undefined reference to `x' collect2: ld returned 1 exit status The difference in o. files is - [ 4] .gnu.lto_*INT_x PROGBITS 40 e3 00 0 0 1 + [ 4] .gnu.lto_INT_xPROGBITS 40 e3 00 0 0 1 Either "*" is expected or the fix is incomplete. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42531
[Bug driver/42520] lto1 does not see -march and -mtune options
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:14 --- It works with GCC built w/o --with-arch/--with-tune. Can you paste the complete output of -v? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42520
[Bug bootstrap/42511] boostrap error in stage3 on alpha-linux-gnu
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:19 --- Works on i?86-linux. I guess stage2 is miscompiled? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42511
[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:21 --- Primary target fails to bootstrap. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Priority|P3 |P1 Summary|bootstrap failure in stage3 |[4.5 Regression] bootstrap |(integer overflow in|failure in stage3 (integer |preprocessor expression)|overflow in preprocessor ||expression) Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[Bug c++/42507] internal compiler error: verify_stmts failed
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 15:25 --- I fixed sth like this a while ago, please try with current trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42507
[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42503
[Bug rtl-optimization/42502] Bad register allocation in a very simple code
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:28 --- Please try with trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization, ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
[Bug middle-end/42501] [4.4 only] Code bloating on operations with bit fields
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:28 --- Fixed in 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42501
[Bug rtl-optimization/42499] Bad register allocation in multiplication code by constant
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:29 --- Please try with trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization, ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42499
[Bug target/42498] GCC can't use smull to compute int * int --> long long
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 15:30 --- This is because widening multiplication is not detected if there are more-than-once used sub-expressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42498
[Bug rtl-optimization/42497] Generate conditional tail calls .
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:33 --- What do you expect with -fno-optimize-sibling-calls ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42497
[Bug bootstrap/42566] New: Bootstrap fails in stage3 building the libstdc++ PCH
The bootstrap fails building the libstdc++ PCH file. The system compiler is used to attempt the build and fails because it doesn't undetstand -std=gnu++0x because it's an old compiler. MacOSX:~/obj ed$ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) I think the stage3 g++ should be used. I think this is a build system mistake. I tried to hand edit the makefile with a stage3 compiler (I think) and add -B but I couldn't get g++ to find cc1plus. I think you'd want the stage3 compiler even if the system compiler understood C++0X for consistency. Also, you can't bootstrap with any g++-3* or even g++-4.0.*. At least not with extra flags maybe. I was able to bootstrap on this platform as late as October 15, 2009. My configure is ../gcc/configure --prefix=/Users/ed/bin --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --enable-decimal-float --enable-languages=c,c++,fortran,objc,obj-c++ Thank you, Ed Here is the end of the build output. I don't know if the ignored fails are probative or not. MacOSX:~/obj ed$ cat err.txt make[4]: Entering directory `/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/include' cd .. && /bin/sh ./config.status include/Makefile config.status: creating include/Makefile Adding multilib support to include/Makefile in ../../../gcc/libstdc++-v3 multidirs= with_multisubdir= make[4]: Leaving directory `/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/include' make[4]: Entering directory `/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/include' make[4]: [stamp-std] Error 1 (ignored) make[4]: [stamp-bits] Error 1 (ignored) make[4]: [stamp-c_compatibility] Error 1 (ignored) make[4]: [stamp-ext] Error 1 (ignored) make[4]: [stamp-debug] Error 1 (ignored) make[4]: [stamp-profile] Error 1 (ignored) echo timestamp > stamp-host mkdir -p ./powerpc-apple-darwin7.9.0/bits/stdc++.h.gch g++ -x c++-header -g -O2 -I/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/include/powerpc-apple-darwin7.9.0 -I/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/include -I/Users/ed/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /Users/ed/gcc/libstdc++-v3/include/precompiled/stdc++.h \ -o powerpc-apple-darwin7.9.0/bits/stdc++.h.gch/O2ggnu++0x.gch cc1plus: error: unrecognized option `-std=gnu++0x' make[4]: *** [powerpc-apple-darwin7.9.0/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 make[4]: Leaving directory `/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/Users/ed/obj' make: *** [all] Error 2 MacOSX:~/obj ed$ cat stage_current stage3 MacOSX:~/obj ed$ -- Summary: Bootstrap fails in stage3 building the libstdc++ PCH Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: 3dw4rd at verizon dot net GCC build triplet: powerpc-apple-darwin7.9.0 GCC host triplet: powerpc-apple-darwin7.9.0 GCC target triplet: powerpc-apple-darwin7.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42566
[Bug target/42495] redundant memory load
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug tree-optimization/42494] [4.4 Regression] Missed dead-code-elimination
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-31 15:36 --- Btw, in 4.4 there is one DOM pass removed for compile-time. We won't fix this for 4.4, the particular testcase is fixed in 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.4.3 Known to work|4.2.1 |4.2.1 4.5.0 Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
[Bug tree-optimization/42492] cannot take address of bit-field
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-31 15:37 --- It was. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42492
[Bug driver/42485] [4.4/4.5 Regression] -V switch broken
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-31 15:41 --- I'm fine with deprecating -V - anyone care to send a patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
[Bug middle-end/42482] [4.5 Regression] Many graphite test 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=42482
[Bug middle-end/42476] "warning: will never be executed" about code which is executed with "-Wunreachable-code"
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:44 --- -Wunreachable-code is broken and has been removed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42476
[Bug bootstrap/42474] SIGSEGV in linemap_lookup
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:45 --- Try a snapshot from the 4.4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42474
[Bug c++/42466] Multiple instantiations of template constructor fail
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-31 15:48 --- Looks like this was fixed for 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|3.3 4.0.1 4.5.0 |3.3 4.0.1 Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42466
[Bug tree-optimization/42462] [4.5 Regression] wrong-code with computed-goto
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 15:57 ---
-O1 -fipa-sra shows the problem as well. We can see wrong (or rather missing)
cloning of static initializers:
;; Function void Foo< >::exec2() [with
= int] (_ZN3FooIiE5exec2Ev)
void Foo< >::exec2() [with =
int] (struct FooD.1756 * const thisD.1781)
{
voidD.35 * gotovar.1D.1832;
boolD.1631 D.1831;
static voidD.35 * tableD.1795[2] = {&beginL.0, &endL.4};
:
gotovar.1D.1832_1 = tableD.1795[0];
goto gotovar.1D.1832_1;
beginL.0:
endL.4:
return;
}
;; Function void Foo< >::execute() [with
= int] (_ZN3FooIiE7executeEv)
void Foo< >::execute() [with
= int] (struct FooD.1756 * const thisD.1783)
{
static voidD.35 * tableD.1795[2] = {&beginL.0, &endL.4};
voidD.35 * gotovar.1D.1845;
static voidD.35 * tableD.1795[2] = {&beginL.0, &endL.4};
:
gotovar.1D.1845_5 = tableD.1795[0];
goto gotovar.1D.1845_5;
beginL.1:
endL.2:
goto ;
}
Hm. Honza? This looks like an issue with non-localized vars?
--
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
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2009-12-31 15:57:11
date||
Summary|wrong-code with computed- |[4.5 Regression] wrong-code
|goto|with computed-goto
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42462
[Bug rtl-optimization/42461] [4.5 Regression] Missed optimisation for pure functions with __builtin_unreachable
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 16:01 --- It isn't particularly easy to DCE predicates in a general fashion. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Component|c |rtl-optimization Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461
[Bug lto/42453] Assertion `syms' failed in lto-plugin
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 16:04 --- Hm, yeah - there's also PR41584 - another empty TU bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42453
[Bug other/42449] Error in dwarf2out.c when compiling tango for D with gdc
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 16:07 --- GDC is not part of the FSF GCC compiler, please report to GDC upstream. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42449
[Bug debug/42565] [4.5 Regression] Huge compilation time with -O1 -g
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 16:14 --- var-tracking I suppose. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Keywords||compile-time-hog Summary|Huge compilation time with -|[4.5 Regression] Huge |O1 -g |compilation time with -O1 -g Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42565
[Bug c/42562] attribute((warning(""))) should work for variables
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42562
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #12 from simon at pushface dot org 2009-12-31 16:25 --- I have tried gcc-4_4-branch and indeed it correctly identifies the triplet without any help (I have been having some trouble with exactly what compiler I am configuring with). The problem turns out to be in gcc/ada/gcc-interface/Makefile.in, and was fixed at SVN-145837 by set...@adacore.com (checked in by charlet). Should this change be rolled into gcc-4_4-branch? (may not be so simple, eg s-osprim-darwin.adb doesn't exist in gcc-4_4-branch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug middle-end/42558] [4.5 Regression] miscompilation related to -floop-block
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558
[Bug c/42544] Bad codegen with signed short cast to unsigned int, then promoted to unsigned long long
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 16:50 ---
Hum. Looks like the C FE somehow munges the uLL constant.
c_parser_cast_expression (parser=0xb77b0b44, after=0x0)
at /home/richard/src/trunk/gcc/c-parser.c:5000
(gdb) call c_parser_peek_token (parser)
$8 = (c_token *) 0xb77b0b44
(gdb) p *$8
$9 = {type = CPP_NUMBER, id_kind = C_ID_NONE, keyword = RID_MAX,
pragma_kind = PRAGMA_NONE, value = 0xb77a3750, location = 479}
(gdb) p $8->value
$10 = (tree) 0xb77a3750
(gdb) call debug_tree ($10)
constant 0x1>
thus ok from the lexer, but
Run till exit from #0 c_parser_binary_expression (parser=0xb77b0b44,
after=0x0) at /home/richard/src/trunk/gcc/c-parser.c:4984
0x0818a327 in c_parser_conditional_expression (parser=0xb77b0b44, after=0x0)
at /home/richard/src/trunk/gcc/c-parser.c:4645
4645 cond = c_parser_binary_expression (parser, after);
Value returned is $16 =
{value = 0xb7740740, original_code = GE_EXPR, original_type = 0x0}
(gdb) call debug_tree ($16->value)
unit size
align 32 symtab 0 alias set -1 canonical type 0xb77422a0 precision 32
min max
pointer_to_this >
arg 0 unit size
align 32 symtab 0 alias set -1 canonical type 0xb7742300 precision
32 min max
pointer_to_this >
arg 1
arg 0 >>
arg 1
constant 2147483648>
t.c:4:18>
here the constant is alrady munged and thus the promotion doesn't happen.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2009-12-31 16:50:18
date||
Version|unknown |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42544
[Bug middle-end/42543] ICE when using va_arg
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|ice-on-valid-code |ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2009-12-31 16:52:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
[Bug target/42536] [4.4/4.5 regression] ICE in spill_failure, at reload1.c:2141
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ra Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
[Bug c/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #10 from mikpe at it dot uu dot se 2009-12-31 17:01 --- Created an attachment (id=19431) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19431&action=view) simpler test case I'm attaching a reduced test case that triggers wrong-code for m68k-elf with gcc-4.5-20091224, every 4.x release, and 3.4.6 (didn't check older releases). To trigger, compile with -O2 (or higher) and -m68020 (or higher), and observe how bar() skips all tests and just returns zero. Any of the following actions mask the bug: 1. reduce optimization level to -O1 2. reduce target cpu type to -m68010 or -m68000 3. remove the "__attribute__((packed))" from "union foo" 4. in bar(), replace "p->d[0]" with "p->d[1]" so that the first and second memory accesses don't have the same base address -fno-strict-aliasing makes no difference -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug lto/42534] ICE with -flto when using __attribute__((__aligned__(X)))
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 17:02 --- Works on i?68-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42534
[Bug c/42544] Bad codegen with signed short cast to unsigned int, then promoted to unsigned long long
--- Comment #2 from joseph at codesourcery dot com 2009-12-31 17:03 --- Subject: Re: Bad codegen with signed short cast to unsigned int, then promoted to unsigned long long The first place to look for a problem would be shorten_compare. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42544
[Bug target/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #11 from jsm28 at gcc dot gnu dot org 2009-12-31 17:06 --- Reopening for now. Please leave the Component as "target"; that is a much more likely place for the bug than the C front end. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|c |target Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #10 from developer at sandoe-acoustics dot co dot uk 2009-12-31 17:07 --- (In reply to comment #9) > FAIL: gfortran.dg/gomp/recursion1.f90 -Os execution test There are two problems: 1) there is a problem with specifying -fopenmp twice on the CL gfortran.dg/gomp/gomp.exp specifies it and so does the testcase (but I guess we should be robust to this)? 2) there needs to be a -B for libgomp in the gfortran.dg/gomp section of the testsuite. === I don't think there's any problem with the actual code generated by the patch, it seems to be substituting as required. I'll look into making sure that there's only one -fopenmp on the CL ... and supplying the missing -B /path/to/libgomp gfortran.dg/gomp/recursion1.f9 is a new test - (29th of Dec) and thrown up a problem not seen before you can regress the patch if you like - but I'd prefer to fix the testsuite problems... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug c/42544] Bad codegen with signed short cast to unsigned int, then promoted to unsigned long long
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 17:21 --- It's indeed at fault. But instead of trying to fix it I'd ditch it completely as premature optimization. I consider c-common.c C frontend specific anyway ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42544
[Bug target/42564] ICE on sparc - unrecognizable insn
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-12-31 17:36 --- I cannot reproduce with a cross, neither on mainline nor 4.4 branch. Could you post the command line passed to cc1? Do you have relevant local patches? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
[Bug target/42159] [4.4 only] app compiled with 4.4.2 SIGABRTs after a trivial nested throw/stack unwinding
--- Comment #15 from simon at pushface dot org 2009-12-31 17:41 --- This bug affects Ada as well. It happens with gcc-4_4-branch HEAD as of 31 Dec 2009, and with earlier releases too (specifically, 4.3.4+AdaCore modifications; this compiler is AdaCore's Leopard release with one added RTS function to replace sigreturn()). -- simon at pushface dot org changed: What|Removed |Added CC||simon at pushface dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
[Bug lto/42531] FAIL: gcc.c-torture/compile/20011119-1.c
--- Comment #5 from hjl dot tools at gmail dot com 2009-12-31 17:56 --- A different patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01253.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||12/msg01253.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42531
[Bug target/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #12 from nospamname at web dot de 2009-12-31 18:04 --- >3.4.6 (didn't check older releases). I test now 3.4.0 for m68k-amigaos.The Problem is here too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug c++/42567] New: internal compiler error: in type_unification_real, at cp/pt.c:13310
/*To start off, I apologize if this bug already was reported (I didn't find it
mentioned anywhere...). Also, what exactly is meant by 'host triplet', 'target
triplet', and 'build triplet'? (I just sort of guessed at them - I'm assuming
they're the host system and the target system and the system on which the
compiler was built...??) */
/* Simplified test case code (located in main.cpp): */
template
class A {
public:
template
void fn(C c) {
auto&& key = *c; /* same bug results if 'auto&&' is replaced
with 'auto&' */
}
};
int main(int argc, char* argv[]) {}
/* Errors produced:
main.cpp: In member function void A::fn(C):
main.cpp:6:17: internal compiler error: in type_unification_real, at
cp/pt.c:13310
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
*/
/* The following is the command used to compile the code:
g++ -std=c++0x main.cpp
*/
/* System specs:
Ubuntu 9.10 32-bit, Intel P9500,
--> GCC 4.5.0 (built from source, revision 155485) <--
*/
/* Comments: Buh whuh? */
--
Summary: internal compiler error: in type_unification_real, at
cp/pt.c:13310
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smm2rc at Virginia dot EDU
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42567
[Bug c++/42567] internal compiler error: in type_unification_real, at cp/pt.c:13310
--- Comment #1 from smm2rc at Virginia dot EDU 2009-12-31 19:22 --- Oh, and replacing the 'auto&& key = *b' line with 'auto&& key = b.member_function()' results in a no-error compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42567
[Bug middle-end/41925] ICE in get_alias_set, at alias.c:710
--- Comment #3 from regehr at cs dot utah dot edu 2009-12-31 19:48 --- See below an extremely small testcase triggering this crash in r155538. reg...@john-home:~/volatile/bugs/tmp250$ current-gcc -Os -c small.c small.c:2:1: internal compiler error: in get_alias_set, at alias.c:710 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. reg...@john-home:~/volatile/bugs/tmp250$ current-gcc -v Using built-in specs. COLLECT_GCC=current-gcc COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r155538-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --with-libelf=/usr/local --enable-lto --prefix=/home/regehr/z/tmp/gcc-r155538-install --program-prefix=r155538- --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20091231 (experimental) (GCC) reg...@john-home:~/volatile/bugs/tmp250$ cat small.c typedef unsigned char uint8_t; uint8_t foo[1000][0]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41925
[Bug middle-end/42561] missing uninitialized variable warning on simple arrays
--- Comment #3 from matt at use dot net 2009-12-31 19:49 --- Created an attachment (id=19432) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19432&action=view) slightly different example that eliminates heap dependency to reproduce: g++ -O3 -Wall gcc-missing-uninit.cpp result: gives 1 warning expected result: should give 3 warnings, as noted in comments -- matt at use dot net changed: What|Removed |Added Attachment #19428|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42561
[Bug middle-end/42561] missing uninitialized variable warning on simple arrays
--- Comment #4 from matt at use dot net 2009-12-31 19:53 --- It seems like this analysis would succeed if the intrinsic memcpy for copying the [2] and [4] were inlined before this analysis. Is there a reason that the intrinsic version of memcpy isn't substituted in before this analysis is done? Am I missing something else? What would be the implementation steps to fix this issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42561
[Bug c++/42567] [C++0x] internal compiler error: in type_unification_real, at cp/pt.c:13310
-- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2009-12-31 20:20:55 date|| Summary|internal compiler error: in |[C++0x] internal compiler |type_unification_real, at |error: in |cp/pt.c:13310 |type_unification_real, at ||cp/pt.c:13310 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42567
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-31 20:42 --- dg-do run gomp testcases don't belong into gcc/testsuite/*.dg/gomp/, but to libgomp/testsuite/libgomp.*/ Please move recursion1.f90 there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug target/42564] ICE on sparc - unrecognizable insn
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-31 20:43 --- I couldn't reproduce this either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
[Bug debug/42565] [4.5 Regression] Huge compilation time with -O1 -g
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-31 21:25 --- And most likely a dup of the other bug ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42565
[Bug driver/41564] -fdump-tree-all for lto does not work as expected
--- Comment #12 from hjl dot tools at gmail dot com 2009-12-31 21:55 --- Created an attachment (id=19433) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19433&action=view) A patch That is what I have in mind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
[Bug driver/41564] -fdump-tree-all for lto does not work as expected
--- Comment #13 from hjl dot tools at gmail dot com 2009-12-31 21:57 --- (In reply to comment #12) > Created an attachment (id=19433) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19433&action=view) [edit] > A patch > > That is what I have in mind. > My patch adds -fdump-lto-tree-XXX, which will be converted to -fdump-tree-XXX in LTO1. We can issue an error or ignore it if we aren't in LTO1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
[Bug fortran/42568] New: BLOCKDATA referenced in EXTERNAL not loading from library
Even though the BLOCKDATA is referenced with an EXTERNAL statement, it is not initializing the COMMON; this worked in previous versions of gfortran, and g95, g77, ifort, and vendor compilers (Cray, HP-UX, IRIX64, SunOS, Solaris, ...) as long as the EXTERNAL statement was present. #!/bin/sh echo trouble loading a blockdata from a library set -x cat >missingBlockData.f <<\EOF program missingBlockData external juinit2 character chars(5)*(20) common /qindex2/chars save /qindex2/ write(*,*)'chars=',chars if(chars(5).ne.'abcdefghijklmnopqrst')then write(*,*)'*missingBlockData* E-R-R-O-R: bad load' else write(*,*)'*missingBlockData* loaded common block' endif end EOF cat >juinit2.f <<\EOF !__- blockdata juinit2 character chars(5)*(20) common /qindex2/chars save /qindex2/ data chars/5*'abcdefghijklmnopqrst'/ end !__- EOF ( exec 2>&1 set -x : __ export F90 F90='gfortran -Wall' : "compile with $F90" : __ : Make libex.a library $F90 -c juinit2.f nm juinit2.o : I thought JUINIT2 would be a T, not a B ?? ar rv libex.a juinit2.o rm juinit2.o : __ : run loading from library rm -f missingBlockData $F90 missingBlockData.f -L. -lex -o missingBlockData ./missingBlockData : __ : run not loading from library rm -f missingBlockData $F90 missingBlockData.f juinit2.f -o missingBlockData ./missingBlockData : __ : version date uname -a $F90 -v missingBlockData.f juinit2.f -o missingBlockData : __ : cleanup rm -f missingBlockData libex.a juinit2.f missingBlockData.f ) >> $0 exit *** *** RESULTS OF RUN: *** *** + set -x + : __ + export F90 + F90=gfortran -Wall + : compile with gfortran -Wall + : __ + : Make libex.a library + gfortran -Wall -c juinit2.f + nm juinit2.o b .bss d .data t .text B _juinit2_ D _qindex2_ + : I thought JUINIT2 would be a T, not a B ?? + ar rv libex.a juinit2.o ar: creating libex.a a - juinit2.o + rm juinit2.o + : __ + : run loading from library + rm -f missingBlockData + gfortran -Wall missingBlockData.f -L. -lex -o missingBlockData + ./missingBlockData chars= missingBlockData* E-R-R-O-R: bad load + : __ + : run not loading from library + rm -f missingBlockData + gfortran -Wall missingBlockData.f juinit2.f -o missingBlockData + ./missingBlockData chars=abcdefghijklmnopqrstabcdefghijklmnopqrstabcdefghijklmnopqrstabcdefghijklmnopqrstabcdefghijklmnopqrst *missingBlockData* loaded common block + : __ + : version + date Thu Dec 31 17:39:18 EST 2009 + uname -a CYGWIN_NT-6.0 urbanjs-PC 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin + gfortran -Wall -v missingBlockData.f juinit2.f -o missingBlockData Driving: gfortran -Wall -v missingBlockData.f juinit2.f -o missingBlockData -lgfortran Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ../trunk/configure --prefix=/usr/local/gfortran --enable-languages=c,c++,fortran --disable-bootstrap --enable-threads=posix --enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --disable-shared --disable-win32-registry --with-system-zlib --enable-checking=release --enable-werror --without-included-gettext --without-x --enable-libgomp Thread model: posix gcc version 4.5.0 20091119 (experimental) [trunk revision 152402] (GCC) COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic' /cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/f951.exe missingBlockData.f -ffixed-form -quiet -dumpbase missingBlockData.f -mtune=generic -auxbase missingBlockData -Wall -version -fintrinsic-modules-path /cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/finclude -o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccWoGlsE.s GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402] (i686-pc-cygwin) compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --par
[Bug middle-end/41925] ICE in get_alias_set, at alias.c:710
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-31 23:19 --- It is caused by revision 150695: http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00375.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-31 23:19:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41925
[Bug c++/42569] New: ICE in cp_parser_parenthesized_expression_list at cp/parser.c
while building gst-plugins-taglib-0.10.17: gstapev2mux.cc: In function 'void add_one_tag(const GstTagList*, const gchar*, void*)': gstapev2mux.cc:118:62: error: cannot call constructor 'TagLib::String::String' directly gstapev2mux.cc:118:62: note: for a function-style cast, remove the redundant '::String' gstapev2mux.cc:127:62: error: cannot call constructor 'TagLib::String::String' directly gstapev2mux.cc:127:62: note: for a function-style cast, remove the redundant '::String' gstapev2mux.cc:127:62: error: no matching function for call to 'TagLib::String::String(char*&, TagLib::String::Type, char*&, TagLib::String::Type)' /usr/include/taglib/tstring.h:164:5: note: candidates are: TagLib::String::String(const TagLib::ByteVector&, TagLib::String::Type) /usr/include/taglib/tstring.h:156:5: note: TagLib::String::String(const char*, TagLib::String::Type) /usr/include/taglib/tstring.h:147:5: note: TagLib::String::String(wchar_t, TagLib::String::Type) /usr/include/taglib/tstring.h:142:5: note: TagLib::String::String(char, TagLib::String::Type) /usr/include/taglib/tstring.h:134:5: note: TagLib::String::String(const wchar_t*, TagLib::String::Type) /usr/include/taglib/tstring.h:129:5: note: TagLib::String::String(const TagLib::wstring&, TagLib::String::Type) /usr/include/taglib/tstring.h:124:5: note: TagLib::String::String(const std::string&, TagLib::String::Type) /usr/include/taglib/tstring.h:116:5: note: TagLib::String::String(const TagLib::String&) /usr/include/taglib/tstring.h:109:5: note: TagLib::String::String() gstapev2mux.cc:136:44: internal compiler error: vector VEC(tree,base) push domain error, in cp_parser_parenthesized_expression_list at cp/parser.c:5326 Changing the code as the notes suggest allows it to compile, but it shouldn't ICE in any case. 4.4.2 works. $ gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.5.0-pre/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/configure --prefix=/usr --bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.5.0-pre --includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/include --datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre --mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/man --infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/include/g++-v4 --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/python --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo SVN' --enable-lto --enable-checking Thread model: posix gcc version 4.5.0-pre 20091230 (experimental) rev. 155514 (Gentoo SVN) -- Summary: ICE in cp_parser_parenthesized_expression_list at cp/parser.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dirtyepic at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42569
[Bug c++/42569] ICE in cp_parser_parenthesized_expression_list at cp/parser.c
--- Comment #1 from dirtyepic at gentoo dot org 2010-01-01 00:38 --- Created an attachment (id=19434) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19434&action=view) delta-reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42569
[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #1 from kargl at gcc dot gnu dot org 2010-01-01 00:46 --- Can you please read how to submit a bug report? I can't find anywhere were it states that a Bourne shell script should be submitted. It simply makes it almost impossible to read the actual bug report. In fact, all the crap with nm and ar is just unneeded cluttered. % gfc4x -c a2.f90 % ar -cur libex.a a2.o % gfc4x -o z a1.f90 -L. -lex % ./z chars=abcdefghijklmnopqrst *missingBlockData* loaded common block % gfc4x -c a2.f90 a1.f90 % ./z chars=abcdefghijklmnopqrst *missingBlockData* loaded common block % gfortran44 -c a2.f90 % ar -cur libex.a a2.o % gfortran44 -o z a1.f90 -L. -lex % ./z chars=abcdefghijklmnopqrst *missingBlockData* loaded common block % gfortran44 -o z a1.f90 a2.f90 % ./z chars=abcdefghijklmnopqrst *missingBlockData* loaded common block Appears to work for me. Where did you get your copy of gfortran? -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #2 from urbanjost at comcast dot net 2010-01-01 01:57 --- Subject: Re: BLOCKDATA referenced in EXTERNAL not loading from library I just got it from the gfortran Wiki because of problems with the previous version I had: http://gcc.gnu.org/wiki/GFortranBinaries then the "CygWin" version, which appears to point to http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-Cygwin-i686.tar.bz2 today, anyway. I guess tastes vary. We preferred shell scripts when I worked at Cray, HP, SGI, Compaq, and Digital; as you otherwise don't know which compiler switches, system level, and so on were used.. It works for me on several Linux boxes as well, just not CygWin. What platform are you on? I'm curious if you do a nm on your libex.a file if juinit2 is type T or B; I haven't used a non-Unix/GNU machine for so many years (except for CygWin) I guess it didn't occur to me a shell script would be harder, not easier, to use. Some examples in the Wiki of "ideal" bug reports would be useful. Note I just upgraded my CygWin a few days ago, to version 1.7; as X11 windows were not working. I have built the program I extracted the problem from many times in the past with older GFORTRAN versions (and G77 and G95) on CygWin; but a recent Vista upgrade broke CygWin (the X11 windows were a bit fragile on Vista anyway). It still builds with G95, and an older version still builds with G77. PS: I found it surprising that if I just compiled the main program I didn't get a warning about unsatisified external JUINIT2; I did with every other compiler I tried. It was also odd that if I put a no-op subroutine in the same file as the BLOCKDATA file and then called it from the main program that the BLOCKDATA was then initialized properly. - Original Message - From: "kargl at gcc dot gnu dot org" To: Sent: Thursday, December 31, 2009 7:46 PM Subject: [Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library > > > --- Comment #1 from kargl at gcc dot gnu dot org 2010-01-01 > 00:46 --- > Can you please read how to submit a bug report? I can't > find anywhere were it states that a Bourne shell script > should be submitted. It simply makes it almost impossible > to read the actual bug report. In fact, all the crap with > nm and ar is just unneeded cluttered. > > % gfc4x -c a2.f90 > % ar -cur libex.a a2.o > % gfc4x -o z a1.f90 -L. -lex > % ./z > chars=abcdefghijklmnopqrst > *missingBlockData* loaded common block > % gfc4x -c a2.f90 a1.f90 > % ./z > chars=abcdefghijklmnopqrst > *missingBlockData* loaded common block > % gfortran44 -c a2.f90 > % ar -cur libex.a a2.o > % gfortran44 -o z a1.f90 -L. -lex > % ./z > chars=abcdefghijklmnopqrst > *missingBlockData* loaded common block > % gfortran44 -o z a1.f90 a2.f90 > % ./z > chars=abcdefghijklmnopqrst > *missingBlockData* loaded common block > > Appears to work for me. Where did you get your copy of > gfortran? > > > -- > > kargl at gcc dot gnu dot org changed: > > What|Removed |Added > > Status|UNCONFIRMED |WAITING > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #3 from kargl at gcc dot gnu dot org 2010-01-01 02:49 --- (In reply to comment #2) > Subject: Re: BLOCKDATA referenced in EXTERNAL not loading from library > > I just got it from the gfortran Wiki because of problems with the previous > version I had: > http://gcc.gnu.org/wiki/GFortranBinaries > then the "CygWin" version, which appears to point to > http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-Cygwin-i686.tar.bz2 > today, anyway. > > I guess tastes vary. > We preferred shell scripts when I worked at Cray, HP, SGI, Compaq, and > Digital; > as you otherwise don't know which compiler switches, system level, and so on > were used.. Then please attach the script to the bug report. The web interface to bugzilla and cut-n-paste plays havoc with whitespace, long lines, etc. > It works for me on several Linux boxes as well, just not CygWin. What > platform are you on? FreeBSD on i686 and x86_64. > I'm curious > if you do a nm on your libex.a file if juinit2 is type T or B; % nm libex.a a2.o: B juinit2_ D qindex2_ > I haven't used a non-Unix/GNU > machine for so many years (except for CygWin) I guess it didn't occur to me > a shell script > would be harder, not easier, to use. Some examples in the Wiki of "ideal" > bug reports would > be useful. The ideal bug report is the shortest source code example that exhibits the problem, which you gave us. The simplest command line used to compile the code that exhibits the problem. If a data file or input is needed, the shortest such data is desirable. If the problem is an internal compiler error or segfault of the compiler, include the last several lines that appear on the terminal. If it's a runtime problem, either give the abort message or error message, or tell us what the expected output should have been. > Note I just upgraded my CygWin a few days ago, to version 1.7; This is my suspicion. There's a problem with the new cygwin. > (and G77 and G95) on CygWin; but a recent Vista upgrade broke CygWin (the > X11 windows > were a bit fragile on Vista anyway). It still builds with G95, and an older > version still builds with G77. > > PS: I found it surprising that if I just compiled the main program I didn't > get a warning about >unsatisified external JUINIT2; I did with every other > compiler I tried. I don't know much about how BLOCK DATA and COMMON are implemented. But, it looks like the compiler is simply eliminating the symbol as dead code. % gfc4x -o z a1.f % nm z | grep -i juin % nm a1.o t MAIN__ U _gfortran_compare_string U _gfortran_set_args U _gfortran_set_options U _gfortran_st_write U _gfortran_st_write_done U _gfortran_transfer_array U _gfortran_transfer_character 0197 T main 0060 r options.4.1509 0019 C qindex2_ AFAIK, there is no constraint in the Standard that something marked by EXTERNAL must be referenced. > It was also odd that > if I put a no-op subroutine in the same file as the BLOCKDATA file and then > called it from the main > program that the BLOCKDATA was then initialized properly. That is strange. It seems to be a linker problem. I suspect that you may need to ping the cygwin guys. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug libstdc++/21772] exception safety testing
--- Comment #17 from bkoz at gcc dot gnu dot org 2010-01-01 03:39 --- Subject: Bug 21772 Author: bkoz Date: Fri Jan 1 03:38:58 2010 New Revision: 155545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155545 Log: 2009-12-31 Benjamin Kosnik PR libstdc++/21772 part 3 * include/ext/throw_allocator.h: Add _GLIBCXX_IS_AGGREGATE. * testsuite/util/testsuite_container_traits.h (traits): Add has_insert. (traits): Add has_insert. (traits): Add has_size_type_constructor. * testsuite/23_containers/array/requirements/exception/ generation_prohibited.cc: New. * testsuite/21_strings/basic_string/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/ext/vstring/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/unordered_map/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/multimap/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/set/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/unordered_multimap/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/forward_list/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/unordered_set/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/vector/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/deque/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/multiset/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/unordered_multiset/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. * testsuite/23_containers/map/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string/requirements/exception/ trunk/libstdc++-v3/testsuite/21_strings/basic_string/requirements/exception/basic.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/requirements/exception/generation_prohibited.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/requirements/exception/propagation_consistent.cc trunk/libstdc++-v3/testsuite/23_containers/array/requirements/exception/ trunk/libstdc++-v3/testsuite/23_containers/array/requirements/exception/generation_prohibited.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/exception/ trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/exception/basic.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/exception/generation_prohibited.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/exception/propagation_consistent.cc trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/exception/ trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/exception/basic.cc trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/exception/generation_prohibited.cc trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/exception/propagation_consistent.cc trunk/libstdc++-v3/testsuite/23_containers/map/requirements/exception/ trunk/libstdc++-v3/testsuite/23_containers/map/requirements/exception/basic.cc trunk/libstdc++-v3/testsuite/23_containers/map/requirements/exception/generation_prohibited.cc trunk/libstdc++-v3/testsuite/23_containers/map/requirements/exception/propagation_consistent.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/requirements/exception/ trunk/libstdc++-v3/testsuite/23_containers/multimap/requirements/exception/basic.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/requirements/exception/generation_prohibited.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/requirements/exception/propagation_consistent.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/requirements/exception/ trunk/lib
[Bug libstdc++/21772] exception safety testing
--- Comment #18 from bkoz at gcc dot gnu dot org 2010-01-01 03:54 --- > multiset error ... was bogus. I adjusted the traits to fix this. > The std::array error seems indeed bogus: if I'm not wrong, it happens when > swapping arrays, and there are no guarantees that the operation doesn't throw > for std::array, because it's requires to just swap the ranges, thus copy > construct and copy assign each array element. It does happen when swapping arrays. I believe that array::swap does have a strong requirement via 23.2.1 p 10, but have xfailed this for the moment. In addition, I have removed the throwing on user defined ctors for throw_value_* via _GLIBCXX_IS_AGGREGATE to simulate a more aggregate-ish thing. However, even aggregates can have assignment operators and other operator actions that throw, and this still fails. (And note the value_type of std::array can have user defined ctors ie 8.5.1 p 13). > Another thing I noticed, about basic_string, something seems inappropriate for > it in the framework, since the value_type must be a POD! Four specializations are defined: char, wchar_t, char16_t, char32_t. That is the only part of basic_string that is special WRT container requirements that I can see. ? I went ahead and checked this in, xfailing the following failures: FAIL: 21_strings/basic_string/requirements/exception/propagation_consistent.cc execution test FAIL: 23_containers/array/requirements/exception/generation_prohibited.cc execution test FAIL: 23_containers/deque/requirements/exception/generation_prohibited.cc execution test FAIL: 23_containers/deque/requirements/exception/propagation_consistent.cc execution test FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc execution test I believe that deque/.../propagation_consistent.cc will have to be modified to take into account 23.3.2.3, and copy/assignment should be elided in this case (and vector via 23.3.6.4) Regardless, this can be tweaked in place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-01-01 06:22 --- I tried the test case with Cygwin running on WinNT-4.0 and it works fine with both 4.3.4 and 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-01-01 06:35 --- I forgot to mention I am using Cygwin 1.7, so this is beginning to look like some sort of installation issue. The gfortran version 4.5 I downloaded and installed per the gfortran wiki. The other possibility to consider is what version of Windows you are using. I notice some reports on the Cygwin list of Vista and Windows 7 bugs. However, these bugs are being actively worked. Try using Cygwin setup.exe and select the reinstall option for gcc core and gfortran. Also install all updates that are coming in daily almost on cygwin as the bugs are getting cleared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
