[Bug tree-optimization/40436] [4.5/4.6 regression] 0.5% code size regression caused by r147852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #41 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-14
09:06:41 UTC ---
Created attachment 22389
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22389
preprocessed ext/super.c
Hi,
this testcase shows that we are no longer able to optimize away ext3_sops
in
sb-s_magic = (__builtin_constant_p((__u16)((es-s_magic))) ? ({ __u16 __x =
(((es-s_magic))); ((__u16)( (((__u16)(__x) (__u16)0x00ffU) 8) |
(((__u16)(__x) (__u16)0xff00U) 8) )); }) : __fswab16(((es-s_magic;
if (sb-s_magic != 0xEF53) {
if (!silent)
printk(3
VFS: Can't find ext3 filesystem on dev %s.\n,
bdevname(dev));
goto failed_mount;
}
The problem is that varpool code now expect that variable accesses are
optimized out at the end of gimple queue instead of using
TREE_SYMBOL_REFERENCED bit. In this case sb-s_magic shomehow manages to get
undefined and in GIMPLE land we keep the conditional around, while in RTL land
init-regs initialize it to 0 that consequently makes mount to always fail.
I guess it is not real code quality bug since it happens only on undefined
behaviour code, but we might consider doing initialization by zero sometime in
gimple queue, too.
Also I am not quite sure if we are not misoptimizing the code, it is
convoluted.
[Bug target/46470] New: add $0x8,%rsp no longer optimized to pop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46470 Summary: add$0x8,%rsp no longer optimized to pop Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org Created attachment 22390 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22390 preprocessed testcase. This is another cause of CSiBE regression at x86_64. Mainline produces: 00f4 yyerror: f4: 48 83 ec 08 sub$0x8,%rsp f8: 48 89 famov%rdi,%rdx fb: 48 8b 3d 00 00 00 00mov0x0(%rip),%rdi# 102 yyerror+0xe 102: be 00 00 00 00 mov$0x0,%esi 107: 31 c0 xor%eax,%eax 109: e8 00 00 00 00 callq 10e yyerror+0x1a 10e: 31 c0 xor%eax,%eax 110: 48 83 c4 08 add$0x8,%rsp 114: c3 retq GCC 4.3 produces: 52: 48 83 ec 08 sub$0x8,%rsp 56: 48 89 famov%rdi,%rdx 59: 48 8b 3d 00 00 00 00mov0x0(%rip),%rdi# 60 yyerror+0xe 60: be 00 00 00 00 mov$0x0,%esi 65: 31 c0 xor%eax,%eax 67: e8 00 00 00 00 callq 6c yyerror+0x1a 6c: 31 c0 xor%eax,%eax 6e: 5a pop%rdx 6f: c3 retq This is because CFA_ADJUST_CFA reg note is in the way now. Richard, I think this is result of your changes, what would be best way to handle this? I guess peephole2 can just move the note when it translates one intstruction to one instruction. This however breaks because we want to split up to 3 pops when doing -Os. I guess also the epilogue code can just emit the pops directly. There always should be free register available at this time.
[Bug target/46471] New: Worse register regalloc leads to bigger code at -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46471 Summary: Worse register regalloc leads to bigger code at -Os Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org Created attachment 22391 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22391 Preprocessed testcase Another CSiBE regression I noticed in merged_1v_upsample. Gcc 4.3 gets around w/o stack frame: 0018 merged_1v_upsample: 18: 41 54 push %r12 1a: 49 89 d4mov%rdx,%r12 1d: 53 push %rbx 1e: 4c 89 cbmov%r9,%rbx 21: 48 83 ec 08 sub$0x8,%rsp 25: 41 8b 09mov(%r9),%ecx 28: 48 8b 87 60 02 00 00mov0x260(%rdi),%rax 2f: 8b 12 mov(%rdx),%edx 31: 49 8d 0c c8 lea(%r8,%rcx,8),%rcx 35: ff 50 18callq *0x18(%rax) 38: ff 03 incl (%rbx) 3a: 41 ff 04 24 incl (%r12) 3e: 58 pop%rax 3f: 5b pop%rbx 40: 41 5c pop%r12 42: c3 retq While current mainline produce: 0018 merged_1v_upsample: 18: 53 push %rbx 19: 48 89 d3mov%rdx,%rbx 1c: 48 83 ec 10 sub$0x10,%rsp 20: 41 8b 11mov(%r9),%edx 23: 48 8b 87 60 02 00 00mov0x260(%rdi),%rax 2a: 4c 89 4c 24 08 mov%r9,0x8(%rsp) 2f: 49 8d 0c d0 lea(%r8,%rdx,8),%rcx 33: 8b 13 mov(%rbx),%edx 35: ff 50 18callq *0x18(%rax) 38: 4c 8b 4c 24 08 mov0x8(%rsp),%r9 3d: 41 ff 01incl (%r9) 40: ff 03 incl (%rbx) 42: 58 pop%rax 43: 5a pop%rdx 44: 5b pop%rbx 45: c3 retq
[Bug tree-optimization/40436] [4.5/4.6 regression] 0.5% code size regression caused by r147852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436 --- Comment #42 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-14 09:27:09 UTC --- Fixing little bug in unreachable function removal and working around PR46470 gets me to: -2933 linux-2.4.23-pre3-testplatformfs/ext3/superb 8069 -1572 linux-2.4.23-pre3-testplatformdrivers/char/n_ttyb 6038 -1385 teem-1.6.0-srcsrc/limn/test/soidb 5396 -1267 linux-2.4.23-pre3-testplatformfs/ext3/iallocb 2582 -1203 linux-2.4.23-pre3-testplatformmm/filemapb 15592 -1057 teem-1.6.0-srcsrc/limn/test/tpsb 4159 -1010 linux-2.4.23-pre3-testplatformfs/ext3/inodeb 12315 -843 teem-1.6.0-srcsrc/ell/quatb 11314 -834 cg_compiler_opensrcsupportb 27636 -828 OpenTCP-1.0.4ethernetb 1495 -820 teem-1.6.0-srcsrc/nrrd/winKernelb 16288 -807 teem-1.6.0-srcsrc/nrrd/measureb 9444 -677 jikespg-1.3src/ctabsb 48223 -656 teem-1.6.0-srcsrc/echo/test/trendb 9744 -619 linux-2.4.23-pre3-testplatformmm/memoryb 8051 -605 bzip2-1.0.2decompressb 8454 -595 teem-1.6.0-srcsrc/nrrd/kernelb 21446 -586 linux-2.4.23-pre3-testplatformfs/nfsd/vfsb 9082 -582 linux-2.4.23-pre3-testplatformfs/ext3/ballocb 4095 -572 teem-1.6.0-srcsrc/echo/colorb 7500 -546 linux-2.4.23-pre3-testplatformfs/bufferb 14617 -521 linux-2.4.23-pre3-testplatformnet/ipv4/igmpb 12205 -511 linux-2.4.23-pre3-testplatformnet/core/devb 11233 -462 libpng-1.2.5pngrtranb 21062 -427 linux-2.4.23-pre3-testplatformfs/nfs/writeb 6586 -419 linux-2.4.23-pre3-testplatformfs/nameib 11526 -414 teem-1.6.0-srcsrc/ten/tendSatinb 5479 -404 linux-2.4.23-pre3-testplatformfs/jbd/transactionb 10746 -387 teem-1.6.0-srcsrc/echo/intxb 10122 -380 teem-1.6.0-srcsrc/mite/rayb 3376 -357 linux-2.4.23-pre3-testplatformfs/jbd/journalb 9266 -349 cg_compiler_opensrcprintutilsb 12377 -340 linux-2.4.23-pre3-testplatformfs/namespaceb 5715 -317 teem-1.6.0-srcsrc/limn/qnb 2544 -311 linux-2.4.23-pre3-testplatformnet/ipv4/tcp_minisocksb 5169 -306 linux-2.4.23-pre3-testplatformnet/sunrpc/xprtb 8042 -291 linux-2.4.23-pre3-testplatformnet/netlink/af_netlinkb 5792 -289 linux-2.4.23-pre3-testplatformlib/vsprintfb 4266 -286 linux-2.4.23-pre3-testplatformnet/sunrpc/svcsockb 6488 -274 compilervasb 6631 What surprise me is that so far there was no inliner (or size estimate) related problems... Does the ARM regression reported still exist? I suppose the fact that we do see regression at our x86_64 CSiBE testing might be just because of the unforunate 8 page alignments in the kernel.
[Bug c++/46472] New: [C++0X] constexpr is not constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46472
Summary: [C++0X] constexpr is not constexpr
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
The code this is reduced from used to compile before the introduction of
constexpr.
templateclass _T1, class _T2 struct pair {
_T1 first;
constexpr pair(){}
};
templatetypename _Tp, int _Nm
struct array
{
_Tp _M_instance[_Nm];
};
array pairint,int, 2 ps;
b.cc: In constructor ‘constexpr arraypairint, int, 2::array()’:
b.cc:6:8: error: ‘constexpr pair_T1, _T2::pair() [with _T1 = int, _T2 = int]’
is not ‘constexpr’
b.cc: At global scope:
b.cc:10:26: note: synthesized method ‘arraypairint, int, 2::array()’ first
required here
[Bug target/46468] enabling -fomit-frame-pointer by default breaks Wine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46468 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hjl at gcc dot gnu.org --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-14 10:46:39 UTC --- I think they require a FP for unwinding. But indeed -fno-omit-frame-pointer should work - can you check what code differences occur with -fno-omit-frame-pointer vs. --enable-frame-pointer?
[Bug objc/46473] New: 'in' not allowed in 'for' loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46473
Summary: 'in' not allowed in 'for' loop
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
The current implementation of Objective-C fast enumeration does not allow a
variable to be named 'in' if used inside a 'for' loop. For example (in c99):
int main (void)
{
for (int in = 0; in 10; in++)
printf (%d\n, in);
return 0;
}
Since Objective-C is (or should be) a superset of C (as much as possible), the
previous snippet of code, which is valid C, should also compile with the
Objective-C compiler.
Thanks
[Bug c++/46472] [C++0X] constexpr is not constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46472 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-14 11:00:26 UTC --- Again, let's add Jason in CC for this one too.
[Bug tree-optimization/40436] [4.5/4.6 regression] 0.5% code size regression caused by r147852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436 --- Comment #43 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-14 11:06:59 UTC --- Created attachment 22392 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22392 Preprocessed ialloc. One of smaller units that grows a lot. The culprint seems to be ext3_new_inode that is a lot smaller in GCC 4.3 variant. Not sure why, the inlining decisions seems sane.
[Bug c++/46364] [4.5 Regression] basic_string.h:541:32: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46364 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45722 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #36 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-14 11:26:15 UTC --- At least on the SPARC.
[Bug rtl-optimization/46315] [4.5 Regression] gcc-4.5.1 -O2 -fno-strict-overflow causes bad code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46315
--- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-14
11:34:42 UTC ---
The problem is indeed the note, but I don't think it comes from it being sort
of self-referential. The use of reg 83 in the note doesn't make it live so ce1
merges BB 4 just before insn 75:
(note 19 18 22 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 22 19 23 4 pr43615.c:10 (set (reg:SI 86)
(sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 83 [ s ])
(const_int 1 [0x1])) [0 S1 A8]))) 96 {extendqisi2}
(expr_list:REG_DEAD (reg/v/f:SI 73 [ s ])
(nil)))
(insn 23 22 24 4 pr43615.c:10 (parallel [
(set (reg/v:SI 81 [ d ])
(plus:SI (reg:SI 86)
(const_int -48 [0xffd0])))
(clobber (reg:CC 17 flags))
]) 197 {*addsi_1} (expr_list:REG_DEAD (reg:SI 86)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 24 23 25 4 pr43615.c:11 (set (reg:CC 17 flags)
(compare:CC (reg/v:SI 81 [ d ])
(const_int 9 [0x9]))) 6 {*cmpsi_1} (nil))
(jump_insn 25 24 26 4 pr43615.c:11 (set (pc)
(if_then_else (gtu (reg:CC 17 flags)
(const_int 0 [0x0]))
(label_ref:SI 68)
(pc))) 464 {*jcc_1} (expr_list:REG_DEAD (reg:CC 17 flags)
(expr_list:REG_BR_PROB (const_int 450 [0x1c2])
(nil)))
- 68)
(note 26 25 75 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 75 26 29 5 pr43615.c:10 (set (reg/v/f:SI 83 [ s ])
(reg/f:SI 95 [ s ])) -1 (expr_list:REG_EQUAL (plus:SI (reg/v/f:SI 83 [
s ])
(const_int 2 [0x2]))
(nil)))
with BB 11:
(note 67 68 5 11 [bb 11] NOTE_INSN_BASIC_BLOCK)
(insn 5 67 72 11 pr43615.c:12 (set (reg/v/f:SI 83 [ s ])
(const_int 0 [0x0])) 44 {*movsi_1} (nil))
yielding:
(note 19 18 22 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 22 19 23 4 pr43615.c:10 (set (reg:SI 86)
(sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 83 [ s ])
(const_int 1 [0x1])) [0 S1 A8]))) 96 {extendqisi2}
(expr_list:REG_DEAD (reg/v/f:SI 73 [ s ])
(nil)))
(insn 23 22 5 4 pr43615.c:10 (parallel [
(set (reg/v:SI 81 [ d ])
(plus:SI (reg:SI 86)
(const_int -48 [0xffd0])))
(clobber (reg:CC 17 flags))
]) 197 {*addsi_1} (expr_list:REG_DEAD (reg:SI 86)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 5 23 24 4 pr43615.c:12 (set (reg/v/f:SI 83 [ s ])
(const_int 0 [0x0])) 44 {*movsi_1} (nil))
(insn 24 5 25 4 pr43615.c:11 (set (reg:CC 17 flags)
(compare:CC (reg/v:SI 81 [ d ])
(const_int 9 [0x9]))) 6 {*cmpsi_1} (nil))
(jump_insn 25 24 26 4 pr43615.c:11 (set (pc)
(if_then_else (gtu (reg:CC 17 flags)
(const_int 0 [0x0]))
(label_ref:SI 46)
(pc))) 464 {*jcc_1} (expr_list:REG_DEAD (reg:CC 17 flags)
(expr_list:REG_BR_PROB (const_int 450 [0x1c2])
(nil)))
- 46)
(insn 75 26 29 5 pr43615.c:10 (set (reg/v/f:SI 83 [ s ])
(reg/f:SI 95 [ s ])) -1 (expr_list:REG_EQUAL (plus:SI (reg/v/f:SI 83 [
s ])
(const_int 2 [0x2]))
(nil)))
and insn 5 now feeds the note.
[Bug tree-optimization/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45722 --- Comment #35 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-14 11:24:52 UTC --- Author: ebotcazou Date: Sun Nov 14 11:24:47 2010 New Revision: 166731 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166731 Log: PR tree-optimization/45722 * tree-sra.c (build_ref_for_model): Always build a COMPONENT_REF if this is a reference to a component. * ipa-prop.c (ipa_get_member_ptr_load_param): Accept COMPONENT_REF. (ipa_note_param_call): Adjust comment. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/tree-sra.c
[Bug c++/46304] [4.5 Regression] g++ crashes with ICE in bitmap_first_set_bit, at bitmap.c:770
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46304 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-14 11:40:22 UTC --- Even though it looks similar to PR45959 backporting the C++ revisions 165306 and 165307 does not fix the tree sharing problem on the 4.5 branch.
[Bug bootstrap/46474] New: [4.6 regression] powerpc64-linux bootstrap comparison failure in libcpp/symtab.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46474 Summary: [4.6 regression] powerpc64-linux bootstrap comparison failure in libcpp/symtab.o Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se gcc-4.6-20101113 (r166720) fails to bootstrap on powerpc64-linux: Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! libcpp/symtab.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/mnt/scratch/objdir46' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir46' make: *** [bootstrap] Error 2 The previous weekly snapshot (20101106) bootstrapped w/o problems. Configured as: /mnt/scratch/gcc-4.6-20101113/configure --with-gmp=/home/mikpe/pkgs/linux-ppc64/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-ppc64/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-ppc64/mpc-0.8.2 --disable-plugin --disable-lto --disable-nls --enable-multilib --enable-threads=posix --with-cpu=default32 --enable-checking=release --disable-libmudflap --enable-languages=c,c++,objc,obj-c++,java,fortran
[Bug middle-end/44592] [4.5 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added AssignedTo|matz at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-14 11:47:55 UTC --- I will look at backporting the 4.6 variant.
[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.11.14 11:45:56 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-14 11:45:56 UTC --- Please verify if 4.5.1 is still broken.
[Bug bootstrap/46474] [4.6 regression] powerpc64-linux bootstrap comparison failure in libcpp/symtab.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46474 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-14 11:58:51 UTC --- I also see it on powerpc-apple-darwin9 (r166728, last bootstrap r166379+patches).
[Bug libstdc++/46455] shared_ptr consuming too many semaphores on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org 2010-11-14 11:58:43 UTC --- (In reply to comment #2) What's the value of __gnu_cxx::__default_lock_policy on Mingw? Is it the same for GCC 4.4 and 4.5? Between 4.4 and 4.5 there are some changes to the ghtr-win32.h file which provides the gthreads abstraction layer, but there are no significant changes to shared_ptr. So for the moment I think it's either a change in the atomic operations supported by mingw or a change in the threading layer, not shared_ptr Well, I've tested it with mingw-w64 toolchains (64-bit and 32-bit) and I couldn't reproduce this issue. Nevertheless it could be related here to some modifications done by mingw.org on their toolchain. So threading model is here something to look for. Kai
[Bug c/46462] [4.6 Regression] Revision 166700 caused new C test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46462 --- Comment #5 from Paolo Bonzini bonzini at gnu dot org 2010-11-14 13:10:45 UTC --- Author: bonzini Date: Sun Nov 14 13:10:41 2010 New Revision: 166732 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166732 Log: 2010-11-13 Paolo Bonzini bonz...@gnu.org PR c/46462 * c-decl.c (declspecs_add_type): Make variables with error types integers. * c-parser.c (c_parser_next_tokens_start_declaration): Two IDs do not start a declaration before an Objective-C foreach. (c_parser_declaration_or_fndef): Improve recovery after unknown type name. (c_parser_for_statement): Hoist entrance of foreach context before ifs, add corresponding reset where it was missing. Do not set objc_could_be_foreach_context for C. Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-parser.c
[Bug fortran/46405] Preprocessor generated code can exceed 132 characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.14 13:29:39 CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-11-14 13:29:39 UTC --- We _could_ set the line length to unlimited when invoking the preprocessor automagically. Would this be a good idea? Hmm...
[Bug debug/46101] [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|dseketel at redhat dot com |dodji at gcc dot gnu.org AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug debug/46101] [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101
--- Comment #2 from Dodji Seketeli dodji at gcc dot gnu.org 2010-11-14
14:15:06 UTC ---
I am currently testing the patch below:
From d16601c89e153c54ef017cca5db854898d9c6502 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli do...@redhat.com
Date: Sun, 14 Nov 2010 12:55:34 +0100
Subject: [PATCH 1/2] Fix PR debug/46101
gcc/
* dwarf2out.c (lookup_type_die_strip_naming_typedef): New
function.
(gen_generic_params_dies, scope_die_for, gen_type_die_for_member):
Replace uses of lookup_type_die with use of
lookup_type_die_strip_naming_typedef.
gcc/testsuite/
* g++.dg/debug/dwarf2/typedef5.C: New test
---
gcc/dwarf2out.c | 28 +++--
gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C | 10 +
2 files changed, 35 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 9bb569b..1094a9f 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -6160,6 +6160,7 @@ static void remove_child_TAG (dw_die_ref, enum
dwarf_tag);
static void add_child_die (dw_die_ref, dw_die_ref);
static dw_die_ref new_die (enum dwarf_tag, dw_die_ref, tree);
static dw_die_ref lookup_type_die (tree);
+static dw_die_ref lookup_type_die_strip_naming_typedef (tree);
static void equate_type_number_to_die (tree, dw_die_ref);
static hashval_t decl_die_table_hash (const void *);
static int decl_die_table_eq (const void *, const void *);
@@ -7920,6 +7921,27 @@ lookup_type_die (tree type)
return TYPE_SYMTAB_DIE (type);
}
+/* Like lookup_type_die, but if type is an anonymous type named by a
+ typedef[1], return the DIE of the anonymous type instead the one of
+ the naming typedef. This is because in gen_typedef_die, we did
+ equate the anonymous struct named by the typedef with the DIE of
+ the naming typedef. So by default, lookup_type_die on an anonymous
+ struct yields the DIE of the naming typedef.
+
+ [1]: Read the comment of is_naming_typedef_decl to learn about what
+ a naming typedef is. */
+
+static inline dw_die_ref
+lookup_type_die_strip_naming_typedef (tree type)
+{
+ dw_die_ref die = lookup_type_die (type);
+ if (TREE_CODE (type) == RECORD_TYPE
+ die-die_tag == DW_TAG_typedef
+ is_naming_typedef_decl (TYPE_NAME (type)))
+die = get_AT_ref (die, DW_AT_type);
+ return die;
+}
+
/* Equate a DIE to a given type specifier. */
static inline void
@@ -12883,7 +12905,7 @@ gen_generic_params_dies (tree t)
return;
if (TYPE_P (t))
-die = lookup_type_die (t);
+die = lookup_type_die_strip_naming_typedef (t);
else if (DECL_P (t))
die = lookup_decl_die (t);
@@ -17763,7 +17785,7 @@ scope_die_for (tree t, dw_die_ref context_die)
scope_die = comp_unit_die ();
}
else
-scope_die = lookup_type_die (containing_scope);
+scope_die = lookup_type_die_strip_naming_typedef (containing_scope);
}
else
scope_die = context_die;
@@ -18590,7 +18612,7 @@ gen_type_die_for_member (tree type, tree member,
dw_die_ref context_die)
gcc_assert (!decl_ultimate_origin (member));
push_decl_scope (type);
- type_die = lookup_type_die (type);
+ type_die = lookup_type_die_strip_naming_typedef (type);
if (TREE_CODE (member) == FUNCTION_DECL)
gen_subprogram_die (member, type_die);
else if (TREE_CODE (member) == FIELD_DECL)
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C
b/gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C
new file mode 100644
index 000..d9d058c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C
@@ -0,0 +1,10 @@
+// Origin: PR debug/46101
+// { dg-options -g -feliminate-dwarf2-dups }
+// { dg-do compile }
+
+typedef struct
+{
+ virtual void f () { }
+} A;
+
+A a;
[Bug target/46468] enabling -fomit-frame-pointer by default breaks Wine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46468 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-11-14 15:03:09 UTC --- It sounds like Wine doesn't use unwind library provided by gcc to unwind the Linux stack. When Wine unwinds Linux stack, it has to use the gcc unwind library, NOT Windows unwind library, to unwind Linux stack.
[Bug c/46475] New: [4.6 Regression] FAIL: gcc.dg/nofixed-point-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46475 Summary: [4.6 Regression] FAIL: gcc.dg/nofixed-point-2.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 166732 gave FAIL: gcc.dg/nofixed-point-2.c (test for warnings, line 12) Revision 166728 is OK.
[Bug c/46475] [4.6 Regression] FAIL: gcc.dg/nofixed-point-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46475 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||bonzini at gnu dot org Target Milestone|--- |4.6.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-14 15:34:11 UTC --- It may be caused by revision 166732: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00621.html
[Bug c/46475] [4.6 Regression] FAIL: gcc.dg/nofixed-point-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46475 --- Comment #2 from Paolo Bonzini bonzini at gnu dot org 2010-11-14 15:47:03 UTC --- Author: bonzini Date: Sun Nov 14 15:46:59 2010 New Revision: 166733 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166733 Log: 2010-11-14 Paolo Bonzini bonz...@gnu.org PR c/46475 * gcc.dg/nofixed-point-2.c: Change dg-warning to dg-bogus. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/nofixed-point-2.c
[Bug c/46475] [4.6 Regression] FAIL: gcc.dg/nofixed-point-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46475 --- Comment #3 from Paolo Bonzini bonzini at gnu dot org 2010-11-14 15:47:12 UTC --- I think I have to debug my test scripts. I'm committing the change from dg-warning to dg-bogus.
[Bug c/46475] [4.6 Regression] FAIL: gcc.dg/nofixed-point-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46475 Paolo Bonzini bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Paolo Bonzini bonzini at gnu dot org 2010-11-14 15:47:48 UTC --- fixed.
[Bug target/45365] X86 SSE FP add and multiply aren't commutative with 2 NaNs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2010.11.14 15:51:37 CC||ubizjak at gmail dot com Resolution|WONTFIX | Ever Confirmed|0 |1 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2010-11-14 15:51:37 UTC --- i386 backend should define HONOR_SNANS.
[Bug target/45365] X86 SSE FP add and multiply aren't commutative with 2 NaNs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2010-11-14 15:53:28 UTC --- Does -fsignaling-nans work here?
[Bug tree-optimization/40436] [4.5/4.6 regression] 0.5% code size regression caused by r147852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #44 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-14
16:16:35 UTC ---
OK, ialloc is because 4.3 folds:
oldbit_430 = 0;
D.12699_431 = oldbit_430 1;
D.12698_462 = D.12699_431;
D.12095_241 = D.12698_462;
if (D.12095_241 != 0)
goto bb 71;
else
goto bb 72;
In mainline the same sequence misses oldbit_430 = 0.
static __inline__ int
test_and_set_bit_simple(unsigned long nr, volatile void * addr)
{
unsigned long reg1, reg2;
int oldbit;
return oldbit 1;
}
static __inline__ int
test_and_clear_bit_simple(unsigned long nr, volatile void * addr)
{
unsigned long reg1, reg2;
int oldbit;
return oldbit 1;
}
static __inline__ int
test_and_change_bit_simple(unsigned long nr, volatile void * addr)
{
unsigned long reg1, reg2;
int oldbit;
return oldbit 1;
}
So another source code bug.
Richard, do you remember if we dropped initialization by zero for uninitialized
vars?
I am officially declaring kernel part of CSiBE irrelevant and will look at the
other tests.
Honza
[Bug c++/46476] New: Missing Warning about unreachable code after return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
Summary: Missing Warning about unreachable code after return
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com
It seems impossible to me that this issue has not been discussed already, but
in the library I fixed only two weeks ago a *very* stupid bug which went
unnoticed for *many* months exactly because of this. Couldn't believe that GCC
didn't warn even at -Wall -Wextra (and -O2). Thus:
int foo(int num)
{
return num;
++num; // Warn!
}
int bar(int num)
{
return num;
++num; // Warn!
return num;
}
For the record, ICC *does* warn, with -Wall.
[Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713 --- Comment #28 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-14 17:11:21 UTC --- For the record, my favorite example in the C++ library, testsuite/performance/27_io/fmtflags_manipulators.cc, pretty simple, still probably noticeable by many of our users, is by now perfectly optimized at -O2. Many thanks.
[Bug c++/46298] constexpr ICE on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46298 --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org 2010-11-14 17:19:03 UTC --- Jason - is this fixed now? If so can you close this please.
[Bug c++/46476] Missing Warning about unreachable code after return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.14 17:38:28 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-14 17:38:28 UTC --- Confirmed.
[Bug bootstrap/46474] [4.6 regression] powerpc64-linux bootstrap comparison failure in libcpp/symtab.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46474
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Milestone|--- |4.6.0
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-14
17:41:29 UTC ---
If it's due to the reported difference using fma and not using fma then
probably the tree fma code lacks checks for debug stmts. Try
Index: tree-ssa-math-opts.c
===
--- tree-ssa-math-opts.c(revision 166717)
+++ tree-ssa-math-opts.c(working copy)
@@ -1534,6 +1534,9 @@
use_stmt = USE_STMT (use_p);
+ if (is_gimple_debug (use_stmt))
+continue;
+
/* For now restrict this operations to single basic blocks. In theory
we would want to support sinking the multiplication in
m = a*b;
@@ -1603,10 +1606,14 @@
FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, mul_result)
{
gimple_stmt_iterator gsi = gsi_for_stmt (use_stmt);
- enum tree_code use_code = gimple_assign_rhs_code (use_stmt);
+ enum tree_code use_code;
tree addop, mulop1, result = mul_result;
bool negate_p = false;
+ if (is_gimple_debug (use_stmt))
+continue;
+
+ use_code = gimple_assign_rhs_code (use_stmt);
if (use_code == NEGATE_EXPR)
{
result = gimple_assign_lhs (use_stmt);
[Bug libstdc++/46455] shared_ptr consuming too many semaphores on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-14 17:50:21 UTC --- if mingw.org modify GCC then this bug should be reported there, as I don't see anything wrong in the libstdc++ code
[Bug bootstrap/46474] [4.6 regression] powerpc64-linux bootstrap comparison failure in libcpp/symtab.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46474 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-14 17:47:50 UTC --- (In reply to comment #2) If it's due to the reported difference using fma and not using fma then probably the tree fma code lacks checks for debug stmts. Try If it is due to FMA code, then we have floating point in the gcc code which we should remove.
[Bug tree-optimization/40436] [4.5/4.6 regression] 0.5% code size regression caused by r147852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #45 from rguenther at suse dot de rguenther at suse dot de
2010-11-14 17:38:46 UTC ---
On Sun, 14 Nov 2010, hubicka at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #44 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-14
16:16:35 UTC ---
OK, ialloc is because 4.3 folds:
oldbit_430 = 0;
D.12699_431 = oldbit_430 1;
D.12698_462 = D.12699_431;
D.12095_241 = D.12698_462;
if (D.12095_241 != 0)
goto bb 71;
else
goto bb 72;
In mainline the same sequence misses oldbit_430 = 0.
static __inline__ int
test_and_set_bit_simple(unsigned long nr, volatile void * addr)
{
unsigned long reg1, reg2;
int oldbit;
return oldbit 1;
}
static __inline__ int
test_and_clear_bit_simple(unsigned long nr, volatile void * addr)
{
unsigned long reg1, reg2;
int oldbit;
return oldbit 1;
}
static __inline__ int
test_and_change_bit_simple(unsigned long nr, volatile void * addr)
{
unsigned long reg1, reg2;
int oldbit;
return oldbit 1;
}
So another source code bug.
Richard, do you remember if we dropped initialization by zero for
uninitialized
vars?
I don't even remember that we did that. Btw, CCP should be able
to fold it with UNDEFINED given that 1 cannot yield zero (but
we're very conservative here now due to past bugs ...)
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #5 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-14 17:56:30 UTC --- After getting rid of the segfault, it is clear the runtime results are wrong. It does look like the span is not getting set correctly. So I begin to look for why it is not being set.
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-14 18:13:14 UTC --- (In reply to comment #5) After getting rid of the segfault, it is clear the runtime results are wrong. It does look like the span is not getting set correctly. So I begin to look for why it is not being set. It might be that this is one of those issues which can only be solved with the new array descriptor - but maybe one can also extend the hack to make it work. Regarding related bugs, cf. PR 40737 and PR 38471 See also http://gcc.gnu.org/wiki/ArrayDescriptorUpdate
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-14 18:50:30 UTC --- The code that sets the span is never reached. I am studying this to see if I can sort it out. I think the problem is in trans_decl.c (gfc_get_symbol_decl).
[Bug fortran/46405] Preprocessor generated code can exceed 132 characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-14 18:54:49 UTC --- I was thinking this same solution. But, maybe the user who is having the problem should just do that. In that case this is not really a bug. The problem is not knowing this is the problem. Is there a flag we can check and just not truncate at 132 or whatever length if CPP?
[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46367 --- Comment #4 from Zdenek Sojka zsojka at seznam dot cz 2010-11-14 19:09:16 UTC --- Created attachment 22393 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22393 reduced testcase Doesn't need -m32. $ gcc -O pr46367.C gcc: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/46405] Preprocessor generated code can exceed 132 characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-14 19:16:10 UTC --- (In reply to comment #2) We _could_ set the line length to unlimited when invoking the preprocessor automagically. Would this be a good idea? Hmm... I do not think that that's the proper solution. In that case you do not distinguish between lines which are genuine too long and those which are only too long due to the macro processing. I think if you want to have the latter, you need to plug into libcpp and add a line-length check there. Then, you can as a second step disable the line length check in the front-end itself. (In reply to comment #3) I was thinking this same solution. But, maybe the user who is having the problem should just do that. I think that's the cleanest solution. After all, even if the line length is only exceeded due to the CPP macro, it is still invaid Fortran. Is there a flag we can check and just not truncate at 132 or whatever length if CPP? Well, there is gfc_cpp_enabled().
[Bug rtl-optimization/46395] [4.6 regression] FAIL: 22_locale/numpunct/members/pod/2.cc execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46395 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2010-11-14 21:11:14 UTC --- That appears to be a bug in postreload in that it does not take exceptions into account. The change in rtl-opt/33721 just modifies the order how automatic variables are allocated and triggers a match in reload_combine_recognize_pattern.
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #98 from Paolo Bonzini bonzini at gnu dot org 2010-11-14 22:35:54
UTC ---
Minimized testcase:
int f (unsigned long arg, int *cr)
{
int *p = (int *) arg;
int x = *cr;
long pu_err = 0;
if (x)
asm volatile (stw %2,0(%1): =r (pu_err): r (p), r (x));
asm volatile (stw %2,0(%%sr3,%1): =r (pu_err): r (p), r (x));
return pu_err;
}
Fails at -O2.
[Bug c/46477] New: GCC doesn't understand %c in asm instruction with -mcmodel=large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46477
Summary: GCC doesn't understand %c in asm instruction with
-mcmodel=large
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: _kirpich...@mail.ru
Hi,
I'm trying to compile the following code snippet:
#ifdef CONFIG_X86_32
# define __BUG_C0 2:\t.long 1b, %c0\n
#else
# define __BUG_C0 2:\t.long 1b - 2b, %c0 - 2b\n
#endif
#define BUG() \
do {\
asm volatile(1:\tud2\n\
.pushsection __bug_table,\a\\n \
__BUG_C0 \
\t.word %c1, 0\n \
\t.org 2b+%c2\n \
.popsection \
: : i (__FILE__), i (__LINE__),\
i (10*sizeof(int))); \
} while (0)
int main()
{
BUG();
}
And everything is ok until -mcmodel=large is used.
When I'm trying to use -mcmodel=large the following error appears:
main.c:24:9: error: invalid 'asm': operand is neither a constant nor a
condition code, invalid operand code 'c'
gcc -dumpversion
4.5
BTW, if I change %c on %P then everything is ok and generated code looks the
same, but I didn't find any documentation about %P.
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #99 from dave at hiauly1 dot hia.nrc.ca 2010-11-14 23:12:25 UTC ---
On Sun, 14 Nov 2010, bonzini at gnu dot org wrote:
Minimized testcase:
int f (unsigned long arg, int *cr)
{
int *p = (int *) arg;
int x = *cr;
long pu_err = 0;
if (x)
asm volatile (stw %2,0(%1): =r (pu_err): r (p), r (x));
asm volatile (stw %2,0(%%sr3,%1): =r (pu_err): r (p), r (x));
return pu_err;
}
Fails at -O2.
Cool! The reduced code no longer makes any sense but it should compile.
I'm sure this was a fair bit of work.
Dave
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #100 from Paolo Bonzini bonzini at gnu dot org 2010-11-14 23:34:28 UTC --- Cool! The reduced code no longer makes any sense but it should compile. I'm sure this was a fair bit of work. Actually delta made all the work down to 31 lines of typedefs/structs and 35 lines of mostly-dead code. All I did manually was remove the remaining Linux structs (replacing them with multiple scalars), propagate constants, and little more. Anyway, I have a new patch that I'm bootstrapping; forward_propagate_asm wasn't adjusting use-def info properly, and the new stricter checking caught that. To avoid code duplication the patch is a bit different from the other. It's more aesthetic differences than practical differences in behavior, but still I prefer to test it first on x86_64 before posting it. It should take only a day or two.
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-15 06:43:24 UTC --- Created attachment 22394 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22394 A sample runtime case The sample runtime case. The pointer is set to the specified element of the vector which may be i the middle, Then the remaining values of the pointer array are the elements in array order so it can cross the boundary between two vectors in the array of vectors.
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339
Jerry DeLisle jvdelisle at gcc dot gnu.org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot
|gnu.org |gnu.org
--- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-15
06:50:58 UTC ---
Once I understood what I was seeing in the attachment. The first patch and
this cleaner one, actually works.
Index: trans-expr.c
===
--- trans-expr.c(revision 166686)
+++ trans-expr.c(working copy)
@@ -4881,7 +4881,8 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gf
/* If this is a subreference array pointer assignment, use the rhs
descriptor element size for the lhs span. */
- if (expr1-symtree-n.sym-attr.subref_array_pointer)
+ if (expr1-symtree-n.sym-attr.subref_array_pointer
+ DECL_LANG_SPECIFIC (expr1-symtree-n.sym-backend_decl))
{
decl = expr1-symtree-n.sym-backend_decl;
gfc_init_se (rse, NULL);
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-15 06:53:50 UTC --- Created attachment 22395 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22395 An alternate patch that also works This alternate patch also fixes the problem by initializing the lang_specific info sooner. I came up with this one when I though the other was not working.
