[Bug preprocessor/45696] Continuation character gets lost or not taken into account
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-17 07:09 --- You can use gcc -E -P, then it doesn't print # lineno file lines and puts the label and fn on the same line (as, without the line notes locations aren't preserved anyway). As Andrew wrote, gcc -E is a C/C++ preprocessor, and the semantics of label: fn (args) is the same as label: fn (args) and the former maintains better the location info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696
[Bug preprocessor/45696] Continuation character gets lost or not taken into account
--- Comment #5 from manu at gcc dot gnu dot org 2010-09-17 08:54 --- I have seen this question/bug reported a couple of times in bugzilla and a few more in gcc-help, so I added a FAQ: http://gcc.gnu.org/wiki/FAQ#cpp_continuation_discarded I suggest that it is rather more useful to answer such questions in the wiki and then always provide a link. Moreover, the answers in the wiki tend to be more satisfactory and clear (if not, they can be gradually improved). Otherwise, the same questions are answered again and again but the answers tend to not be uniform in terms of clarity and quality. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-17 08:55 --- Subject: Re: [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC --- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-16 20:57 --- This is really strange case. The patch should at most introduce extra inlining that naturally should not introduce undefined symbols. It is used as: sethi %hi(_GLOBAL_OFFSET_TABLE_-(.LL363-.)), %o3 or %o3, %lo(_GLOBAL_OFFSET_TABLE_-(.LL363-.)), %o3 callgnat__debug_pools__put_line, 0 so it is passed to gnat__debug_pools__put_line. Any idea what should be there? It does not seem like variable, rather like code label. Can I have Unfortunately not; you'd have to ask one of the Ada maintainers. Eric is on the Cc:, he might know. -fdump-tree-optimized (or perhaps better -fdump-tree-all) dumps? Sure. I couldn't attach it to the PR (1.8 MB even compressed with bzip2), so I've put it at http://www.cebitec.uni-bielefeld.de/~ro/files/g-debpoo-dump-tree-all.tar.bz2 Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
[Bug libobjc/23680] @synchronized support is not in GNU runtime
--- Comment #3 from nicola at gcc dot gnu dot org 2010-09-17 09:00 --- @synchronized support is now available in the GNU runtime. :-) Thanks -- nicola at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23680
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-09-17 09:00 --- Subject: Bug 45678 Author: rguenth Date: Fri Sep 17 09:00:23 2010 New Revision: 164356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164356 Log: 2010-09-17 Richard Guenther rguent...@suse.de PR middle-end/45678 * builtins.c (fold_builtin_memory_op): Always properly adjust alignment of memory accesses. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug c/23104] [4.3/4.4/4.5/4.6 Regression] C does not reject the same function in two different TUs with -combine
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug tree-optimization/26850] unused function not eliminated with -fwhole-program --combine
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
[Bug c/24068] Unconditional warning when using -combine
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug c/27899] Compile warning with --combine and global register variables.
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- 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=27899
[Bug middle-end/29171] forgotten memcpy with -ffreestanding -fwhole-program --combine
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
[Bug middle-end/30075] Missed optimizations with -fwhole-program -combine
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- 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=30075
[Bug c/35034] weakref vs. -combine
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug tree-optimization/37756] ICE building object file with -O3 and -combine
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37756
[Bug c/37973] Document that -MM and -combine don't mix
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37973
[Bug middle-end/40506] ICE with -fwhole-program --combine (verify_stmts failed)
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- 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=40506
[Bug tree-optimization/40150] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188 with -combine
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- 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=40150
[Bug driver/41962] gcc fails to compile with -combine -no-integrated-cpp
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- 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=41962
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program -combine
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- 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=44776
[Bug c/44041] [4.5 regression] -combine ICE: verify_gimple failed (invalid conversion in return statement)
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 09:06 --- -combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX. -- 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=44041
[Bug tree-optimization/45623] [4.5 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-09-17 09:09 --- (In reply to comment #28) (In reply to comment #27) Fixed for trunk sofar. Is there an eta for 4.5 backport? We need this to switch Firefox to 4.5 on Linux. I just want to play safe and see if there is any fallout on trunk. You can use the attachment in comment #24 for the 4.5 branch (and I'd appreciate testing if this fixes your original problem) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug objc/16398] Dynamic Inheritance in Objective-C
--- Comment #4 from nicola at gcc dot gnu dot org 2010-09-17 09:28 --- This proposed enhancement seems to be a major change to the language! :-) It basically would mean that every object has a customized class hierarchy. So, when a message is sent to the object, the object's custom class hierarchy would need to be traversed - instead of the standard one. (that would indeed complicate messaging quite a lot) When an instance variable of the object is accessed, again the object's custom ivar list would need to be examined to determine the offset of that specific ivar ... instead of using a standard ivar/offset information for all objects. (again this would indeed complicate instance variables quite a lot). I suppose my point is that this object-dependent class hierarchy is not just an enhancement - it is so radical that it would basically transform Objective-C into another language (it's a nice idea though!). ;-) The simpler version of all of this is to be able to replace a class with another one. So, you'd replace 'myRootObject' with 'myDebuggingRootObject' and that would happen everywhere in your application for all the objects. This is called 'poseAs:'. It is clearly much easier to implement than custom replacement of classes for a single object, but it is still quite hard. So hard tha Apple removed it from their runtime and deprecated it. It's no longer available there and probably will be removed from the GNU runtime too. Anyway, if you're interested in this dynamic modifications of class hierarchies, you may want to look into up (and maybe open up a new issue on that). I'd like to close this issue just because the enhancement proposed is too radical. ;-) Thanks -- nicola at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Priority|P2 |P4 Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16398
[Bug bootstrap/45700] New: [4.5/4.6 Regression] --enable-checking=fold bootstrap failures
On the trunk (and supposedly on 4.5 too) fold checking bootstrap fails e.g. while building dyncast.cc in libsupc++ (and some ada compilations too). I've debugged the dyncast.cc failure, the problem is that fold_build3_loc on loc, COND_EXPR, type, EQ_EXPR, 1, 0 modifies the EQ_EXPR by changing its locus. This is because /* Convert A ? 1 : 0 to simply A. */ folding calls pedantic_non_lvalue_loc, and that one if !pedantic_lvalues modifies the passed expr's locus. I'd say most of the protected_set_expr_location calls in fold-const.c are suspicios. Either it is in places where fold-const first calls build[1-5] followed by protected_set_expr_location, IMHO in these cases we should just apply Tobias' build[1-5]_loc patch and use those routines instead, and the rest either should be dropped altogether (fold_convert_loc also ignores locus if the type is already right, etc.), or, if the locus is really essentialy, should do nothing if the locus is equal and if not, do a copy_node and set the locus on the copy and return it. -- Summary: [4.5/4.6 Regression] --enable-checking=fold bootstrap failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45700
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Incorrect copy constructor |[4.6 Regression] Incorrect |generated with -O |copy constructor generated ||with -O Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699
[Bug c++/45697] __restrict__ inconsistent in presence of typedefs
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 09:39 --- Confirmed. Both variants are rejected when using the C frontend. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2010-09-17 09:39:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45697
[Bug rtl-optimization/45695] [4.5/4.6 Regression] -O1 wrong-code by cmove
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |rtl-optimization Known to work||4.5.1 Priority|P3 |P1 Summary|-O1 wrong-code by cmove |[4.5/4.6 Regression] -O1 ||wrong-code by cmove Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45695
[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693
[Bug rtl-optimization/45685] GCC optimizer for Intel x64 generates inefficient code
--- Comment #4 from ubizjak at gmail dot com 2010-09-17 09:59 ---
This all happens in IF conversion pass.
4.6 regresses in the sense that a branch is emitted instead of cmov for:
int
summation_helper_1 (long * products, unsigned long count)
{
int s = 0;
unsigned long i;
for (i = 0; i count; i++)
{
int val = (products[i] 0) ? 1 : -1;
products[i] *= val;
if (products[i] != i)
val = -val;
products[i] = val;
s += val;
}
return s;
}
gcc-4.4.4 -O3 produces:
.L16:
movq(%rdi,%rdx,8), %r10
testq %r10, %r10
setg%r8b
xorl%ecx, %ecx
testq %r10, %r10
movzbl %r8b, %r9d
movzbl %r8b, %r8d
setle %cl
leaq-1(%r8,%r8), %r8
leal-1(%rcx,%rcx), %ecx
leal-1(%r9,%r9), %r9d
imulq %r8, %r10
movslq %ecx,%r11
cmpq%r10, %rdx
cmovne %r11, %r8
cmove %r9d, %ecx
movq%r8, (%rdi,%rdx,8)
addq$1, %rdx
addl%ecx, %eax
cmpq%rdx, %rsi
ja .L16
and gcc-4.6 20100917
.L15:
movq(%rdi,%rdx,8), %r8
testq %r8, %r8
movq%r8, %r10
setg%cl
xorl%r9d, %r9d
testq %r8, %r8
movzbl %cl, %r11d
movzbl %cl, %ecx
setle %r9b
leaq-1(%rcx,%rcx), %rcx
leaq-1(%r9,%r9), %r9
imulq %rcx, %r10
cmpq%r10, %rdx
cmove %rcx, %r9
leal-1(%r11,%r11), %ecx
movq%r9, (%rdi,%rdx,8)
je .L12
xorl%ecx, %ecx
testq %r8, %r8
setle %cl
leal-1(%rcx,%rcx), %ecx
.L12:
addq$1, %rdx
addl%ecx, %eax
cmpq%rsi, %rdx
jne .L15
--
ubizjak at gmail dot com changed:
What|Removed |Added
Last reconfirmed|-00-00 00:00:00 |2010-09-17 09:59:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
[Bug rtl-optimization/45685] GCC optimizer for Intel x64 generates inefficient code
--- Comment #5 from ubizjak at gmail dot com 2010-09-17 10:02 --- Confirmed. Regression? -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2010-09-17 09:59:36 |2010-09-17 10:02:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
[Bug testsuite/45692] FAIL: objc/execute/exceptions/throw-nil.m execution on darwin with -m32
--- Comment #2 from nicola at gcc dot gnu dot org 2010-09-17 10:14 --- Ok ... I fixed the testcase in trunk. Please can you let me know if it works fine now (I don't have a darwin machine to test). :-) Thanks -- nicola at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45692
[Bug target/45701] New: [regression 4.5] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment
This was implemented in gcc-4.5, still works in gcc-4.5 branch.
2009-06-02 Richard Earnshaw rearn...@arm.com
* arm.c (arm_get_frame_offsets): Prefer using r3 for padding a
push/pop multiple to 8-byte alignment.
However, it doesn't work any longer on gcc-4.6 trunk. Reproduced on the
following steps,
$ arm-none-linux-gnueabi-gcc -Os -mthumb -march=armv7-a bashline.c -S
On gcc-4.5 branch, r3 is used to keep stack alignment, which is expected.
history_expand_line_internal:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, r4, r5, r6, r7, lr}
However, on gcc-4.6 trunk, we can see that, r8 is used to keep stack alignment,
which is *not* expected.
history_expand_line_internal:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, r5, r6, r7, r8, lr}
--
Summary: [regression 4.5] Fail to prefer using r3 for padding a
push/pop multiple to 8-byte alignment
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: qiyao at gcc dot gnu dot org
GCC host triplet: i486-build_pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45701
[Bug target/45701] [regression 4.5] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment
--- Comment #1 from qiyao at gcc dot gnu dot org 2010-09-17 10:52 --- Created an attachment (id=21816) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21816action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45701
[Bug tree-optimization/26850] unused function not eliminated with -fwhole-program --combine
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-09-17 11:09 --- Well, this is still something we should solve at LTO. Indirect inlining should take away references that are fully resolved so function becomes unreachable. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[regression 4.5] Fail to|[4.6 Regression] Fail to |prefer using r3 for padding |prefer using r3 for padding |a push/pop multiple to 8- |a push/pop multiple to 8- |byte alignment |byte alignment Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45701
[Bug rtl-optimization/45695] [4.5/4.6 Regression] -O1 wrong-code by cmove
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-17 12:05 --- Created an attachment (id=21817) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21817action=view) gcc46-pr45695.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45695
[Bug rtl-optimization/45621] [4.6 Regression] ICE: verify_cgraph_node failed: inlined_to pointer is set but no predecessors found with -fipa-cp-clone -flto
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-17 12:17 --- Created an attachment (id=21818) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21818action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45621
[Bug lto/44246] ICE with -fwhopr/-flto when using strlen and strcat without previous declaration
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-09-17 12:19 --- seems like streamer bug. We should not ever see any comdat groups here. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-22 14:34:30 |2010-09-17 12:19:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44246
[Bug testsuite/45692] FAIL: objc/execute/exceptions/throw-nil.m execution on darwin with -m32
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-17 12:42 --- Ok ... I fixed the testcase in trunk. Is there not a simpler way to fix the test with dejagnu directives? Please can you let me know if it works fine now With the new test the failures are gone. Thanks. (I don't have a darwin machine to test). :-) You can always monitor the regress bot on http://gcc.gnu.org/ml/gcc-testresults/2010-*. When nobody has broken its bootstrap, you can get an idea of what's wrong with darwin three times a day. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45692
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #37 from paolo dot carlini at oracle dot com 2010-09-17 12:42 --- Created an attachment (id=21819) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21819action=view) Tested x86_64-linux, mainline This is a carefully tested patch (tested in mainline, per the normal policy, where I also added two additional seekoff correctness testcases), which works in limited circumstances (enough to fix the testcase, anyway) when I can convince myself it's fully correct and consistent with our general framework. My plan is committing it first and then possibly generalizing it, always together with additional accompanying testcases, anyway. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Attachment #21769|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug lto/45702] New: [4.6 Regression] New test failures
On Linux/x86, revision 164357 gave FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+ (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+ -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+ -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+1 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+1 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+1 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+3 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs1 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs1 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs1 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs3 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs3 -O3 (test for excess errors) FAIL: gcc.dg/pr27898.c (test for excess errors) FAIL: gcc.dg/pr28706.c (test for excess errors) FAIL: gcc.dg/pr28712.c (test for excess errors) FAIL: gcc.dg/pr30762-1.c (test for excess errors) FAIL: gcc.dg/pr31529-1.c (test for excess errors) FAIL: gcc.dg/pr34457-1.c (test for excess errors) FAIL: gcc.dg/pr34668-1.c (test for excess errors) FAIL: gcc.dg/pr34989-1.c (test for excess errors) FAIL: gcc.dg/pr43557-1.c (test for excess errors) Revision 164355 is OK. -- Summary: [4.6 Regression] New test failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-17 12:46 ---
You now set the location, but I believe the wrong one.
esra changes are:
foo (struct S * arg)
{
+ int SR.1;
+ int s$a;
struct S s;
struct S D.2694;
int D.2690;
@@ -72,10 +37,12 @@ foo (struct S * arg)
goto bb 5;
bb 4:
- [pr25923.c : 13:7] s = [pr25923.c : 13] *arg_2(D);
+ [pr25923.c : 13:7] s$a_9 = [pr25923.c : 13] MEM[(struct S *)arg_2(D)];
bb 5:
- [pr25923.c : 14:3] D.2694 = s;
+ # s$a_8 = PHI s$a_7(D)(3), [pr25923.c : 13:7] s$a_9(4)
+ [pr25923.c : 14:3] SR.1_10 = s$a_8;
+ MEM[(struct S *)D.2694] = SR.1_10;
return D.2694;
}
The added MEM = SR.1_10 uses location_t of the stmt after it, as
sra_modify_expr
emits statements before gsi. I'm arguing that in this case the MEM[(struct S
*)D.2694] = SR.1_10; stmt is not related to return D.2694, but to D.2694 = s
that has been removed and thus I believe it should inherit its locus as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505
[Bug lto/44246] ICE with -fwhopr/-flto when using strlen and strcat without previous declaration
--- Comment #3 from hubicka at ucw dot cz 2010-09-17 12:48 --- Subject: Re: ICE with -fwhopr/-flto when using strlen and strcat without previous declaration seems like streamer bug. We should not ever see any comdat groups here. We stream the node twice for some reason (I can see this happening for multiple units since we do share builtin decls but not for single unit) and double translation of comdat_group breaks. Have patch to avoid this, but wonder from what the double streaming comes in this unit.. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44246
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #1 from rguenther at suse dot de 2010-09-17 12:56 --- Subject: Re: New: [4.6 Regression] New test failures On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote: On Linux/x86, revision 164357 gave FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+ (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+ -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+ -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+1 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+1 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+1 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+3 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs+3 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs1 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs1 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs1 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs3 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gstabs3 -O3 (test for excess errors) FAIL: gcc.dg/pr27898.c (test for excess errors) FAIL: gcc.dg/pr28706.c (test for excess errors) FAIL: gcc.dg/pr28712.c (test for excess errors) FAIL: gcc.dg/pr30762-1.c (test for excess errors) FAIL: gcc.dg/pr31529-1.c (test for excess errors) FAIL: gcc.dg/pr34457-1.c (test for excess errors) FAIL: gcc.dg/pr34668-1.c (test for excess errors) FAIL: gcc.dg/pr34989-1.c (test for excess errors) FAIL: gcc.dg/pr43557-1.c (test for excess errors) Revision 164355 is OK. What are the excess errors? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug rtl-optimization/45685] [4.6 Regression] GCC optimizer for Intel x64 generates inefficient code
--- Comment #6 from hjl dot tools at gmail dot com 2010-09-17 13:04 --- (In reply to comment #4) This all happens in IF conversion pass. 4.6 regresses in the sense that a branch is emitted instead of cmov for: This is caused by revision 159106: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00156.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||matz at suse dot de Summary|GCC optimizer for Intel x64 |[4.6 Regression] GCC |generates inefficient code |optimizer for Intel x64 ||generates inefficient code Target Milestone|--- |4.6.0 Version|4.4.3 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
[Bug lto/44246] ICE with -fwhopr/-flto when using strlen and strcat without previous declaration
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-17 13:13 --- OK, the problem is that we stream two cgraph nodes. One for strlen function and other for __bulitin_strlen. Decl of __bulitin_strlen have same asm name as strlen: (gdb) p debug_tree (node-decl) function_decl 0x77f4 strlen type function_type 0x77f3db28 type integer_type 0x77ed0690 long unsigned int public unsigned DI size integer_cst 0x77ebc7d0 constant 64 unit size integer_cst 0x77ebc7f8 constant 8 align 64 symtab 0 alias set 4 canonical type 0x77ed0690 precision 64 min integer_cst 0x77ebc820 0 max integer_cst 0x77ebc7a8 18446744073709551615 QI size integer_cst 0x77ebc4d8 constant 8 unit size integer_cst 0x77ebc500 constant 1 align 8 symtab 0 alias set -1 canonical type 0x77ee attributes tree_list 0x77f3ac58 purpose identifier_node 0x77ecfc30 nonnull arg-types tree_list 0x77ee6640 value pointer_type 0x77ee3dc8 chain tree_list 0x77ebceb0 value void_type 0x77ed0e70 void pointer_to_this pointer_type 0x75aebb28 addressable used nothrow public external built-in decl_2 decl_5 decl_6 QI file built-in line 0 col 0 align 8 built-in BUILT_IN_NORMAL:BUILT_IN_STRLEN attributes tree_list 0x77f3acf8 chain function_decl 0x77f40100 __builtin_strncasecmp $6 = void (gdb) c Continuing. Breakpoint 1, lto_output_node (set=0x77f98c00, vset=0x77f98c20) at ../../gcc/lto-cgraph.c:416 416 boundary_p = !cgraph_node_in_set_p (node, set); (gdb) c Continuing. Breakpoint 1, lto_output_node (set=0x77f98c00, vset=0x77f98c20) at ../../gcc/lto-cgraph.c:416 416 boundary_p = !cgraph_node_in_set_p (node, set); (gdb) p debug_tree (node-decl) function_decl 0x77f3ef00 __builtin_strlen type function_type 0x77f3db28 type integer_type 0x77ed0690 long unsigned int public unsigned DI size integer_cst 0x77ebc7d0 constant 64 unit size integer_cst 0x77ebc7f8 constant 8 align 64 symtab 0 alias set 4 canonical type 0x77ed0690 precision 64 min integer_cst 0x77ebc820 0 max integer_cst 0x77ebc7a8 18446744073709551615 QI size integer_cst 0x77ebc4d8 constant 8 unit size integer_cst 0x77ebc500 constant 1 align 8 symtab 0 alias set -1 canonical type 0x77ee attributes tree_list 0x77f3ac58 purpose identifier_node 0x77ecfc30 nonnull arg-types tree_list 0x77ee6640 value pointer_type 0x77ee3dc8 chain tree_list 0x77ebceb0 value void_type 0x77ed0e70 void pointer_to_this pointer_type 0x75aebb28 nothrow public external built-in decl_6 QI file built-in line 0 col 0 align 8 built-in BUILT_IN_NORMAL:BUILT_IN_STRLEN attributes tree_list 0x77f3ac80 chain function_decl 0x77f4 strlen and when reading back those two decls identify into single and thus also the cgraph nodes. Richi: is that intended behaviour? -- hubicka at gcc dot gnu dot org changed: What|Removed |Added CC||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44246
[Bug lto/44246] ICE with -fwhopr/-flto when using strlen and strcat without previous declaration
--- Comment #5 from rguenther at suse dot de 2010-09-17 13:26 --- Subject: Re: ICE with -fwhopr/-flto when using strlen and strcat without previous declaration On Fri, 17 Sep 2010, hubicka at gcc dot gnu dot org wrote: --- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-17 13:13 --- OK, the problem is that we stream two cgraph nodes. One for strlen function and other for __bulitin_strlen. Decl of __bulitin_strlen have same asm name as strlen: (gdb) p debug_tree (node-decl) function_decl 0x77f4 strlen type function_type 0x77f3db28 type integer_type 0x77ed0690 long unsigned int public unsigned DI size integer_cst 0x77ebc7d0 constant 64 unit size integer_cst 0x77ebc7f8 constant 8 align 64 symtab 0 alias set 4 canonical type 0x77ed0690 precision 64 min integer_cst 0x77ebc820 0 max integer_cst 0x77ebc7a8 18446744073709551615 QI size integer_cst 0x77ebc4d8 constant 8 unit size integer_cst 0x77ebc500 constant 1 align 8 symtab 0 alias set -1 canonical type 0x77ee attributes tree_list 0x77f3ac58 purpose identifier_node 0x77ecfc30 nonnull arg-types tree_list 0x77ee6640 value pointer_type 0x77ee3dc8 chain tree_list 0x77ebceb0 value void_type 0x77ed0e70 void pointer_to_this pointer_type 0x75aebb28 addressable used nothrow public external built-in decl_2 decl_5 decl_6 QI file built-in line 0 col 0 align 8 built-in BUILT_IN_NORMAL:BUILT_IN_STRLEN attributes tree_list 0x77f3acf8 chain function_decl 0x77f40100 __builtin_strncasecmp $6 = void (gdb) c Continuing. Breakpoint 1, lto_output_node (set=0x77f98c00, vset=0x77f98c20) at ../../gcc/lto-cgraph.c:416 416 boundary_p = !cgraph_node_in_set_p (node, set); (gdb) c Continuing. Breakpoint 1, lto_output_node (set=0x77f98c00, vset=0x77f98c20) at ../../gcc/lto-cgraph.c:416 416 boundary_p = !cgraph_node_in_set_p (node, set); (gdb) p debug_tree (node-decl) function_decl 0x77f3ef00 __builtin_strlen type function_type 0x77f3db28 type integer_type 0x77ed0690 long unsigned int public unsigned DI size integer_cst 0x77ebc7d0 constant 64 unit size integer_cst 0x77ebc7f8 constant 8 align 64 symtab 0 alias set 4 canonical type 0x77ed0690 precision 64 min integer_cst 0x77ebc820 0 max integer_cst 0x77ebc7a8 18446744073709551615 QI size integer_cst 0x77ebc4d8 constant 8 unit size integer_cst 0x77ebc500 constant 1 align 8 symtab 0 alias set -1 canonical type 0x77ee attributes tree_list 0x77f3ac58 purpose identifier_node 0x77ecfc30 nonnull arg-types tree_list 0x77ee6640 value pointer_type 0x77ee3dc8 chain tree_list 0x77ebceb0 value void_type 0x77ed0e70 void pointer_to_this pointer_type 0x75aebb28 nothrow public external built-in decl_6 QI file built-in line 0 col 0 align 8 built-in BUILT_IN_NORMAL:BUILT_IN_STRLEN attributes tree_list 0x77f3ac80 chain function_decl 0x77f4 strlen and when reading back those two decls identify into single and thus also the cgraph nodes. Richi: is that intended behaviour? No, we shouldn't stream them at all. Why do we even bother? And yes, same cgraph node is intended (one is an alias for the other). Maybe that's what we get wrong even in non-LTO mode? Do we have two different cgraph nodes for strlen vs. __builtin_strlen? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44246
[Bug tree-optimization/43432] Missed vectorization: complicated access pattern for increasing and decreasing data indexing
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-17 13:26 --- Subject: Bug 43432 Author: matz Date: Fri Sep 17 13:26:43 2010 New Revision: 164367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164367 Log: PR tree-optimization/43432 * tree-vect-data-refs.c (vect_analyze_data_ref_access): Accept backwards consecutive accesses. (vect_create_data_ref_ptr): If step is negative generate decreasing IVs. * tree-vect-stmts.c (vectorizable_store): Reject negative steps. (perm_mask_for_reverse, reverse_vec_elements): New functions. (vectorizable_load): Handle loads with negative steps when easily possible. testsuite/ PR tree-optimization/43432 * lib/target-supports.exp (check_effective_target_vect_perm_byte, check_effective_target_vect_perm_short): New predicates. (check_effective_target_vect_perm): Include x86_64. * gcc.dg/vect/pr43432.c: New test. * gcc.dg/vect/vect-114.c: Adjust. * gcc.dg/vect/vect-15.c: Ditto. * gcc.dg/vect/slp-perm-8.c: Use new predicate. * gcc.dg/vect/slp-perm-9.c: Ditto. Added: trunk/gcc/testsuite/gcc.dg/vect/pr43432.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/slp-perm-8.c trunk/gcc/testsuite/gcc.dg/vect/slp-perm-9.c trunk/gcc/testsuite/gcc.dg/vect/vect-114.c trunk/gcc/testsuite/gcc.dg/vect/vect-15.c trunk/gcc/testsuite/lib/target-supports.exp trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43432
[Bug lto/44246] ICE with -fwhopr/-flto when using strlen and strcat without previous declaration
--- Comment #6 from hubicka at ucw dot cz 2010-09-17 13:30 --- Subject: Re: ICE with -fwhopr/-flto when using strlen and strcat without previous declaration Richi: is that intended behaviour? No, we shouldn't stream them at all. Why do we even bother? And yes, Because we need to get stuff in sync to be able to read them correctly :) same cgraph node is intended (one is an alias for the other). Maybe that's what we get wrong even in non-LTO mode? Do we have two different cgraph nodes for strlen vs. __builtin_strlen? Yes, we do. It is violation of one decl rule I would say. Probably could be declared frontend bug, why it produces two decls at first place? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44246
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-17 13:35 --- I got # /export/build/gnu/gcc-32bit/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-32bit/build-i686-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r -nostdlib /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -o pr28712.exe -v /export/build/gnu/gcc-32bit/build-i686-linux/gcc/collect-ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o pr28712.exe -r -L/export/build/gnu/gcc-32bit/build-i686-linux/gcc /tmp/ccLvxKIY.o /tmp/ccpjReNk.o /tmp/ccBVusXG.o -lm /usr/local/bin/ld: cannot find -lm collect2: ld returned 1 exit status For some reason, gcc driver failed to pass -L/usr/lib to collect-ld. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 13:36 --- -m32 works on Intel64 since gcc driver passes /export/build/gnu/gcc/build-x86_64-linux/gcc/collect-ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o pr28712.exe -r -L/export/build/gnu/gcc/build-x86_64-linux/gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/export/build/gnu/gcc/build-x86_64-linux/gcc /tmp/ccLRsGQH.lto.o -lm to collect-ld. Only ia32 fails. -- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/44246] ICE with -fwhopr/-flto when using strlen and strcat without previous declaration
--- Comment #7 from rguenther at suse dot de 2010-09-17 13:43 --- Subject: Re: ICE with -fwhopr/-flto when using strlen and strcat without previous declaration On Fri, 17 Sep 2010, hubicka at ucw dot cz wrote: --- Comment #6 from hubicka at ucw dot cz 2010-09-17 13:30 --- Subject: Re: ICE with -fwhopr/-flto when using strlen and strcat without previous declaration Richi: is that intended behaviour? No, we shouldn't stream them at all. Why do we even bother? And yes, Because we need to get stuff in sync to be able to read them correctly :) Hm? We explicitly don't stream built-in decls, did you remove that? You simply get the available builtins from function-code from input-node. same cgraph node is intended (one is an alias for the other). Maybe that's what we get wrong even in non-LTO mode? Do we have two different cgraph nodes for strlen vs. __builtin_strlen? Yes, we do. It is violation of one decl rule I would say. Probably could be declared frontend bug, why it produces two decls at first place? Well, one is an alias for the other and we do have decls for aliases. I'd say what probably happens is that at output time the decls look different (after all they miss a prototype) and we fail to carry over that state properly. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44246
[Bug rtl-optimization/45685] [4.6 Regression] GCC optimizer for Intel x64 generates inefficient code
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-17 13:45 --- It might have been exposed by that revision, but that merely points out a deficiency in RTL if conversion. The final gimple code doesn't have explicit jumps in the inner loop, but uses cond_expr: bb 3: # s_22 = PHI 0(2), s_30(3) # i_19 = PHI 0(2), i_31(3) D.2693_11 = MEM[base: products_9(D), index: i_19, step: 8, offset: 0B]; val_4 = [cond_expr] D.2693_11 = 0 ? -1 : 1; prephitmp.9_39 = [cond_expr] D.2693_11 = 0 ? -1 : 1; prephitmp.10_40 = [cond_expr] D.2693_11 = 0 ? 1 : -1; prephitmp.11_41 = [cond_expr] D.2693_11 = 0 ? 1 : -1; D.2698_21 = D.2693_11 * prephitmp.9_39; D.2699_25 = (long unsigned int) D.2698_21; val_3 = [cond_expr] i_19 != D.2699_25 ? prephitmp.10_40 : val_4; prephitmp.11_43 = [cond_expr] i_19 != D.2699_25 ? prephitmp.11_41 : prephitmp.9_39; MEM[base: products_9(D), index: i_19, step: 8, offset: 0B] = prephitmp.11_43; s_30 = val_3 + s_22; i_31 = i_19 + 1; if (i_31 != count_7(D)) goto bb 3; else goto bb 4; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #4 from rguenther at suse dot de 2010-09-17 13:48 --- Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote: --- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 13:36 --- -m32 works on Intel64 since gcc driver passes /export/build/gnu/gcc/build-x86_64-linux/gcc/collect-ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o pr28712.exe -r -L/export/build/gnu/gcc/build-x86_64-linux/gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/export/build/gnu/gcc/build-x86_64-linux/gcc /tmp/ccLRsGQH.lto.o -lm to collect-ld. Only ia32 fails. Hm. Maybe the -nostdlib I added causes this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-17 13:52 --- Works fine in 64bit with -m32 [...@gnu-6 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r -nostdlib /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -m32 -o pr28712.exe [...@gnu-6 gcc]$ Failed on ia32. [...@gnu-6 gcc]$ /export/build/gnu/gcc-32bit/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-32bit/build-i686-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r -nostdlib /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -o pr28712.exe /usr/local/bin/ld: cannot find -lm collect2: ld returned 1 exit status [...@gnu-6 gcc]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-09-17 13:57 --- Subject: Bug 45678 Author: rguenth Date: Fri Sep 17 13:57:04 2010 New Revision: 164369 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164369 Log: 2010-09-17 Richard Guenther rguent...@suse.de PR middle-end/45678 * gcc.dg/torture/pr45678-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr45678-1.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #6 from jakub at gcc dot gnu dot org 2010-09-17 13:57 --- With -r -nostdlib when -lm is mentioned on the command line, it is looking for libm.a. Guess you have it installed on one box and not on the other one. That said, the tests really shouldn't have -lm on their link line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #7 from rguenther at suse dot de 2010-09-17 13:58 --- Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote: --- Comment #5 from hjl dot tools at gmail dot com 2010-09-17 13:52 --- Works fine in 64bit with -m32 [...@gnu-6 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r -nostdlib /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -m32 -o pr28712.exe [...@gnu-6 gcc]$ Failed on ia32. [...@gnu-6 gcc]$ /export/build/gnu/gcc-32bit/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-32bit/build-i686-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r -nostdlib /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -o pr28712.exe /usr/local/bin/ld: cannot find -lm collect2: ld returned 1 exit status [...@gnu-6 gcc]$ The question is, why do we add -lm with -nostdlib anways? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-09-17 14:01 --- Created an attachment (id=21820) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820action=view) testcase for problem As this test need more then on header, please extract it and compile then main.c to reproduce it. At least I was able to do this on linux64 by this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 --- Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a way to bypass that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #9 from rguenther at suse dot de 2010-09-17 14:07 --- Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote: --- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 --- Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a way to bypass that. Hm, so I'd say blame it on the host system of HJ. Or alternatively add an empty main() to each of the testcases to be able to drop -r -nostdlib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #10 from hjl dot tools at gmail dot com 2010-09-17 14:08 --- (In reply to comment #6) With -r -nostdlib when -lm is mentioned on the command line, it is looking for libm.a. Guess you have it installed on one box and not on the other one. That said, the tests really shouldn't have -lm on their link line. /usr/lib/libm.a is available. 32bit gcc driver doesn't pass -L/usr/lib to ld and 64bit gcc driver does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #11 from hjl dot tools at gmail dot com 2010-09-17 14:11 --- (In reply to comment #9) Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote: --- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 --- Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a way to bypass that. Hm, so I'd say blame it on the host system of HJ. Or alternatively As I said, it is a REGRESSION, which means it passed before. I believe it is caused by your --combine change. See: http://gcc.gnu.org/ml/gcc-regression/2010-09/msg00267.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 |2010-09-17 14:11:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #12 from rguenther at suse dot de 2010-09-17 14:14 --- Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote: --- Comment #11 from hjl dot tools at gmail dot com 2010-09-17 14:11 --- (In reply to comment #9) Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote: --- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 --- Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a way to bypass that. Hm, so I'd say blame it on the host system of HJ. Or alternatively As I said, it is a REGRESSION, which means it passed before. I believe it is caused by your --combine change. See: http://gcc.gnu.org/ml/gcc-regression/2010-09/msg00267.html Of course it is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program -combine
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-09-17 14:21 --- Should we just XFAIL this on darwin then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 14:29 --- It is caused by revision 159362: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00414.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||mjambor at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
-- 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 |2010-09-17 14:29:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699
[Bug driver/45703] New: [4.6 regression] --help -v no longer shows linker help
gcc --help -v no longer runs ld --help because collect2 handles --help itself without running ld. -- Summary: [4.6 regression] --help -v no longer shows linker help Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at linux-m68k dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45703
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-17 14:39 --- I'll have a look at it but please be patient, my bug queue is rather long at the moment. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC|mjambor at suse dot cz |jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699
[Bug c++/45605] Missed devirtualization
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-09-17 14:46 --- Honza submitted a patch (http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01369.html) so I guess it is his PR now :-) -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jamborm at gcc dot gnu dot |hubicka at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug tree-optimization/45704] New: [4.5 Regression] load byte instruction is used for volatile int
A cast to volatile int pointer is ignored on gcc 4.5 with this test case.
struct st {
int ptr;
};
int foo(struct st *st)
{
int v = *(volatile int *)st-ptr;
return v 0xff;
}
mipsel-linux-gcc-4.5.1 -O2 foo.c -S output:
lbu $2,0($4)
j $31
nop
It seems the cast are ignored and load int and mask was optimized to load
byte.
gcc 4.4.4 works fine.
mipsel-linux-gcc-4.4.4 -O2 foo.c -S output:
lw $2,0($4)
j $31
andi$2,$2,0x00ff
git-bisect tell me 0d9f1189f3df5ce5c0efc3ecadc7c0a4f75b202d is the first bad
commit.
URL: http://gcc.gnu.org/viewcvs?view=revisionrevision=156571
The commit is fix for Bug 42956.
The PR 42956 bugzilla shows same fix was applied to both 4.5.0 and 4.4.4,
but they behave differently on this test case.
Comparing patches for 4.4 branch and 4.5, I see the latter contains two more
changes for gimplify.c:
A STRIP_NOP line and lines starting with /* *(foo *)complexfoo = __real__
complexfoo */ comment.
I do not know gcc internal at all but it seems reverting this change fixes this
problem.
- STRIP_USELESS_TYPE_CONVERSION (sub);
+ STRIP_NOPS (sub);
Hope this helps.
--
Summary: [4.5 Regression] load byte instruction is used for
volatile int
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anemo at mba dot ocn dot ne dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-09-17 15:08 --- (In reply to comment #7) The added MEM = SR.1_10 uses location_t of the stmt after it, as sra_modify_expr emits statements before gsi. I'm arguing that in this case the MEM[(struct S *)D.2694] = SR.1_10; stmt is not related to return D.2694, but to D.2694 = s that has been removed and thus I believe it should inherit its locus as well. Unfortunately no, the statement SR.1_10 = s$a_8; is produced when replacing the original assignment, MEM[(struct S *)D.2694] = SR.1_10; is created when processing the return statement, it is updating the original agregate D.2694 with data in its replacements (in this case there is only one but there can be more) before it is used as a whole. I can't see how it could be otherwise. It would be difficult also to set the location of the MEM_REF statement according to the definition of its RHS because when the statement is built the RHS is not yet in SSA form. Thinking about it more, the RHS in that statement, SR.1_10 has its TREE_NO_WARNING set and so that line should not be a problem at this stage. So I guess s$a_8 is propagated there at some point later. Perhaps the fwprop could change the location when it substitutes an operand in situations like this? I know it would be a bit ugly but doing the same in SRA would require some aggregate data flow analysis which would be quite hard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505
[Bug middle-end/45705] New: [4.3/4.4/4.5/4.6 Regression] Useless store not optimized away
int x;
void
foo (void)
{
if (x == 0)
x = 0;
}
was optimized into empty routine with gcc 3.4 and 4.0, but isn't any longer in
4.1+. In 4.0 apparently the store went away in *.optimized, and with
-fno-tree-ter in ce1+combine removed it. This occurs quite a lot in
http://embed.cs.utah.edu/embarrassing/
--
Summary: [4.3/4.4/4.5/4.6 Regression] Useless store not optimized
away
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program -combine
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-17 15:13 --- (In reply to comment #5) Should we just XFAIL this on darwin then? You mean it still fails? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
[Bug middle-end/45705] [4.3/4.4/4.5/4.6 Regression] Useless store not optimized away
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 15:18 --- Eventually predicated value-numbering will fix this as part of the redundant store removal eliminate() performs. A similar thing can be added to DOM, which already can do the predication. I'll give that a quick try. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, matz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-17 15:18:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program -combine
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-17 15:18 --- You mean it still fails? Yes!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
[Bug middle-end/45705] [4.3/4.4/4.5/4.6 Regression] Useless store not optimized away
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-17 15:19 --- ce1+combine removed it. I think it still does on targets that don't have a direct to memory store of 0 like PPC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
[Bug middle-end/45705] [4.3/4.4/4.5/4.6 Regression] Useless store not optimized away
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-17 15:39 ---
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 164371)
+++ tree-ssa-dom.c (working copy)
@@ -1804,6 +1804,37 @@ eliminate_redundant_computations (gimple
tree def = gimple_get_lhs (stmt);
+ if (gimple_assign_single_p (stmt)
+ TREE_CODE (def) != SSA_NAME)
+{
+ tree rhs = gimple_assign_rhs1 (stmt);
+ gimple new_stmt;
+ /* Build a new statement with the RHS and LHS exchanged. */
+ if (TREE_CODE (rhs) == SSA_NAME)
+{
+ gimple defstmt = SSA_NAME_DEF_STMT (rhs);
+ new_stmt = gimple_build_assign (rhs, def);
+ SSA_NAME_DEF_STMT (rhs) = defstmt;
+}
+ else
+new_stmt = gimple_build_assign (rhs, def);
+ gimple_set_vuse (new_stmt, gimple_vuse (stmt));
+ cached_lhs = lookup_avail_expr (new_stmt, false);
+ if (cached_lhs
+ (rhs == cached_lhs
+ || (TREE_CODE (rhs) == SSA_NAME
+ SSA_NAME_VALUE (rhs) == cached_lhs)))
+ {
+ gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
+ basic_block bb = gimple_bb (stmt);
+ unlink_stmt_vdef (stmt);
+ gsi_remove (gsi, true);
+ if (gimple_purge_dead_eh_edges (bb))
+ ;
+ return;
+ }
+}
+
/* Certain expressions on the RHS can be optimized away, but can not
themselves be entered into the hash tables. */
if (! def
works for both constants and SSA names. Need to clean the patch up
(removing stmts at that point is probably going to wreck dom, removing
EH edges for sure I guess).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Keywords|missed-optimization |
Last reconfirmed|2010-09-17 15:18:08 |2010-09-17 15:39:14
date||
Target Milestone|4.3.6 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
[Bug middle-end/45705] [4.3/4.4/4.5/4.6 Regression] Useless store not optimized away
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45705
[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-17 15:45 --- Confirmed. 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 |2010-09-17 15:45:01 date|| Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program -combine
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-09-17 15:46 --- Reopen. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program
--- Comment #9 from dominiq at lps dot ens dot fr 2010-09-17 15:57 --- Apparently the problem is that when compiled with -fipa-matrix-reorg -O[123s] -fwhole-program in 64 bit mode, the executable gives: ... a.out(83070) malloc: *** error for object 0x1001000c0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort (see comment #0). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
[Bug middle-end/45706] New: [4.6 regression] gcc.dg/vect/vect-114.c
On Linux/ia32, revision 164369 gave FAIL: gcc.dg/vect/vect-114.c scan-tree-dump-times vect vectorized 0 loops 1 Revision 164366 is OK. It may be caused by revision 164367: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00661.html -- Summary: [4.6 regression] gcc.dg/vect/vect-114.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug middle-end/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #1 from matz at gcc dot gnu dot org 2010-09-17 16:12 --- This passes for me, even in -m32 mode (if -msse is added, like vect.exp does): % ./cc1 -ftree-vectorize -fno-vect-cost-model -msse2 -O2 \ vect-114.c -ftree-vectorizer-verbose=2 21 | grep note: vect-114.c:13: note: LOOP VECTORIZED. vect-114.c:6: note: vectorized 1 loops in function. -- matz at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.6 regression]|[4.6 regression] |gcc.dg/vect/vect-114.c |gcc.dg/vect/vect-114.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug c/45707] New: infinite loop
#include stdio.h
int main()
{
int i;
while(1)
{
if(i0)
{
break;
}
i++;
}
return 0;
}
compiled with -O3
infinite loop:
.L5:
jmp .L5
--
Summary: infinite loop
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pzielins at icm dot edu dot pl
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45707
[Bug middle-end/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-17 16:30 --- (In reply to comment #1) This passes for me, even in -m32 mode (if -msse is added, like vect.exp does): % ./cc1 -ftree-vectorize -fno-vect-cost-model -msse2 -O2 \ vect-114.c -ftree-vectorizer-verbose=2 21 | grep note: vect-114.c:13: note: LOOP VECTORIZED. vect-114.c:6: note: vectorized 1 loops in function. Please note. The failure is FAIL: gcc.dg/vect/vect-114.c scan-tree-dump-times vect vectorized 0 loops 1 ^^^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug middle-end/45706] [4.6 regression] gcc.dg/vect/vect-114.c
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 16:30 --- For some reason, it only fails with 32bit gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45706
[Bug c/45707] infinite loop
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-17 16:32 --- This code depends on two undefined behavior. First it depends on an uninitialized value of i. If i is greater than 0 to begin with it depends on signed integer overflow which is undefined. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45707
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #24 from hjl dot tools at gmail dot com 2010-09-17 16:35 --- Created an attachment (id=21821) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21821action=view) A patch The problem is we failed to update stack alignment when we increase alignment of local variable. This patch works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug testsuite/45692] FAIL: objc/execute/exceptions/throw-nil.m execution on darwin with -m32
--- Comment #4 from nicola at gcc dot gnu dot org 2010-09-17 16:40 --- Ok ... I fixed the testcase in trunk. Is there not a simpler way to fix the test with dejagnu directives? Probably. :-) The fix in trunk does work and is consistent with other files in the same directory. But feel free to suggest a better way, and send a patch. We could maybe tidy up all the files in that directory ;-) Thanks -- nicola at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45692
[Bug libobjc/38881] Two problem in objc-list.h in list_remove_elem
--- Comment #1 from nicola at gcc dot gnu dot org 2010-09-17 16:53 --- Thanks well spotted :-) Unfortunately, the list_remove_elem() function is obsolete (never used inside the runtime itself, and deprecated for usage outside of it as of 4.6.0) so there is not much point in working on it any more. ;-) Thanks -- nicola at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38881
[Bug testsuite/45692] FAIL: objc/execute/exceptions/throw-nil.m execution on darwin with -m32
--- Comment #5 from iains at gcc dot gnu dot org 2010-09-17 17:05 ---
(In reply to comment #4)
Ok ... I fixed the testcase in trunk.
Is there not a simpler way to fix the test with dejagnu directives?
Probably. :-)
well that's why I added the /torture dir under objc.dg - if tests require that
..
(also obj-c++.gc/torture)
If possible, it would be better to add all new tests under
objc.dg/{,torture,} as necessary... and avoid objc/*
.. it gives access to more flexible and selective features - which can help in
the transition to ObjC2 on NeXT.
if there are a significant number of new gnu-runtime-only-torture tests - then
perhaps we should create a gnu-runtime subdir under the torture heading. If
there are not many that are gnu-only (as at present) then dg-skip works for
me.
We could maybe tidy up all the files in that directory ;-)
yeah, it would be good to move all of the objc/* to objc.dg - when someone has
time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45692
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #25 from hjl dot tools at gmail dot com 2010-09-17 17:26 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01425.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||09/msg01425.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #26 from hjl at gcc dot gnu dot org 2010-09-17 17:49 --- Subject: Bug 45678 Author: hjl Date: Fri Sep 17 17:49:30 2010 New Revision: 164375 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164375 Log: Update stack alignment when increasing local variable alignment. gcc/ 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45678 * cfgexpand.c (update_stack_alignment): New. (get_decl_align_unit): Use it. (expand_one_stack_var_at): Call update_stack_alignment. gcc/testsuite/ 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45678 * gcc.dg/torture/pr45678-2.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/pr45678-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #38 from potswa at mac dot com 2010-09-17 17:51 ---
Created an attachment (id=21822)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21822action=view)
Works with codecvt. Tested Tested x86_64-darwin, mainline
Ah, now I see the trick:
if (__off == 0 !(_M_mode ios_base::out))
So if the file is open for writing, disable the optimization.
I had a problem with this condition for these testcases:
27_io/basic_filebuf/sputbackc/char/1-io.cc
27_io/basic_filebuf/sputbackc/char/2-io.cc
which contain code such as
strmsz_2 = fb_01.sputn(, i wanna reach out and, 10);
fb_01.pubseekoff(0, std::ios_base::cur); // if this doesn't flush
c1 = fb_01.sgetc(); // this underflow is ignored
c2 = fb_01.sputbackc('z'); // as well as this putback
Essentially, pubseekoff(0,cur) is being used as a sync(). I see nothing in the
Standard to support that, and indeed the sync() shouldn't be needed either, so
I was planning to open a new bug.
Anyway, if I apply your limitation to my patch, it passes the unmodified
testsuite, so here it is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug middle-end/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca
--- Comment #17 from hjl at gcc dot gnu dot org 2010-09-17 18:00 --- Subject: Bug 45234 Author: hjl Date: Fri Sep 17 18:00:40 2010 New Revision: 164377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164377 Log: Make sure that all variable sized adjustments are multiple of preferred stack boundary after stack alignment. gcc/ 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45234 * calls.c (expand_call): Make sure that all variable sized adjustments are multiple of preferred stack boundary after stack alignment. gcc/testsuite/ 2010-09-17 H.J. Lu hongjiu...@intel.com PR middle-end/45234 * gcc.dg/torture/stackalign/alloca-5.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/stackalign/alloca-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #39 from potswa at mac dot com 2010-09-17 18:04 --- Oops, no, I'm on the 4.5.2 series, not mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-17 18:21 --- The problem is a big one. In short, placement new operator changes the type of an object to another, which re-sets up the VMT. Then there is call of a virtual method of the latter type. CCP however happily propagates the initial declaration (of a type with no virtual methods) to the OBJ_TYPE_REF and attempts to fold it. The folding function naturally expect to see some virtual methods in BINFOs but there are none and we dereference a NULL pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #15 from ktietz at gcc dot gnu dot org 2010-09-17 18:37 --- (In reply to comment #14) Created an attachment (id=21820) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820action=view) [edit] testcase for problem As this test need more then on header, please extract it and compile then main.c to reproduce it. At least I was able to do this on linux64 by this testcase. Patch for it posted to ML. See http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01394.html -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-09-16 17:04:34 |2010-09-17 18:37:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- Comment #40 from paolo dot carlini at oracle dot com 2010-09-17 18:53 --- In general, our users know that seeking allows to switch from reading to writing, and viceversa (when the stream has been appropriately opened of course). This assumption remained true for years and years. Thus, for now at least, I would rather not change it, whether the Standard is completely clear in this area or not. Also, I don't think the name __is_tell is appropriate, because of course this kinf of situation in principle can occur also when tell is not involved (like in your testcase ;) Modulo the above comments, I think we can enable the optimization for codecvt too, yes, let me reformat your other tweaks and more cleanly incorporate the !(_M_mode ios_base::out) thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45708] New: fstream reads after writes, or vice versa, don't work
basic_filebuf (and therefore fstream) does not allow you to put a write
operation directly after a read operation, or vice versa. Instead, the write
and the read must be separated by a seek or tell (tell being equivalent to a
seek-to-current-position).
As the Standard specifies behavior in terms of the file's contents, the current
position in the file, and get and put areas, this requirement has no basis in
it. basic_filebuf::underflow is required to return the next character in the
pending sequence, regardless of the contents of the put area. (27.5.2.4.3/8-9)
The problem lies in the implementation of the state machine of _M_reading and
_M_writing. These variables should be redundant: we are reading if the get area
is non-empty, and writing if the put area is non-empty. For example, underflow
is bracketed by
const bool __testin = _M_mode ios_base::in;
if (__testin !_M_writing)
{
Reading after a write operation causes an underflow with an empty get area. If
the user has not explicitly flushed the buffer with seekoff or sync, the
current implementation refuses to switch modes. (And sync does not work for
writing after reading, as it does nothing unless the put area is not empty.)
It looks like the fix is to eliminate _M_reading and _M_writing in favor of
member functions that test the get and put areas, and calling overflow and
underflow to ensure prerequisites.
--
Summary: fstream reads after writes, or vice versa, don't work
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: potswa at mac dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45708
[Bug tree-optimization/43430] Missed vectorization: stmt not supported: cond_expr
--- Comment #9 from spop at gcc dot gnu dot org 2010-09-17 19:01 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43430
