[Bug tree-optimization/27176] [4.1 Regression] Sun disklabel checksum code isn't being generated properly.
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-17 09:51 ---
Confirmed. Number of iteration analysis concludes the loop
ush_4 = label.23_3 + 510B;
if (label.23_3 <= ush_4) goto ; else goto ;
:;
# ush_16 = PHI ;
# csum_14 = PHI ;
:;
# VUSE ;
D.2866_8 = *ush_16;
csum_9 = D.2866_8 ^ csum_14;
ush_10 = ush_16 - 2B;
if (label.23_3 <= ush_10) goto ; else goto ;
:;
goto ();
runs once: (.t75.ivcanon)
(set_nb_iterations_in_loop = 1B))
Loop 1 iterates 0B times.
Unrolled loop 1 completely.
and the loop is gone. I guess its some signedness problem again:
(add_to_evolution
(loop_nb = 1)
(chrec_before = ush_4)
(to_add = 2B)
(res = {ush_4, +, -2B}_1))
(evolution_function = {ush_4, +, -2B}_1))
(set_scalar_evolution
(scalar = ush_16)
(scalar_evolution = {ush_4, +, -2B}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = 2B)
(get_scalar_evolution
(scalar = 2B)
(scalar_evolution = 2B))
)
(set_scalar_evolution
(scalar = ush_10)
(scalar_evolution = {ush_4 - 2B, +, -2B}_1))
)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org, rakdver at gcc dot gnu
||dot org
Status|UNCONFIRMED |NEW
Component|middle-end |tree-optimization
Ever Confirmed|0 |1
GCC build triplet|sparc64-unknown-linux-gnu |
GCC host triplet|sparc64-unknown-linux-gnu |
GCC target triplet|sparc64-unknown-linux-gnu |
Keywords||wrong-code
Known to fail||4.1.0
Known to work||4.0.3 4.2.0
Last reconfirmed|-00-00 00:00:00 |2006-04-17 09:51:04
date||
Summary|Sun disklabel checksum code |[4.1 Regression] Sun
|isn't being generated |disklabel checksum code
|properly. |isn't being generated
||properly.
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27176
[Bug tree-optimization/27176] [4.1 Regression] Sun disklabel checksum code isn't being generated properly.
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-17 10:10 --- This is a dup of PR26763, which is fixed for 4.1.1. *** This bug has been marked as a duplicate of 26763 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27176
[Bug tree-optimization/26763] [4.1/4.2 Regression] wrong final value of induction variable calculated
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-04-17 10:10 --- *** Bug 27176 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jciccone at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug tree-optimization/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-17 10:16 --- This may be fixed by Zdeneks optimization of phi argument rewrite and dominator updating. Though I bet these are not appropriate for 4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
[Bug middle-end/27136] [4.0/4.1/4.2 Regression] Compile failure with -O -ffast-math
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-17 10:34 --- #5 0x081a8738 in get_val_for (x=0xb7dedea0, base=0xb7d70480) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c:1254 1254 val = fold (TREE_OPERAND (stmt, 1)); (gdb) call debug_generic_expr(stmt) xD.1278_3 = __builtin_pow (4.0e+0, 2.0e+0) which we don't evaluate at compile-time. So loop_niter_by_eval builds (gdb) call debug_generic_expr(expr) __builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow (__builtin_pow .. on which we punt at some point. Now, we definitely should fold 4.0**2.0 at compile time, too. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, rakdver at gcc dot gnu ||dot org Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
[Bug middle-end/27136] [4.0/4.1/4.2 Regression] Compile failure with -O -ffast-math
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-17 10:51 --- Hmm, looks more like a tree sharing problem Breakpoint 5, fold_ternary (code=CALL_EXPR, type=0xb7d5fa6c, op0=0xb7d55540, op1=0xb7dd9048, op2=0x0) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/fold-const.c:9945 9945 tree arg0 = NULL_TREE, arg1 = NULL_TREE; (gdb) call debug_tree(op1) unit size align 64 symtab 0 alias set -1 precision 64 pointer_to_this > nothrow arg 0 readonly constant invariant arg 0 > arg 1 chain constant invariant 2.0e+0>>> t.c:5> chain constant invariant 3.2e+1>>> we are self-referencing and so built up an infinite chain of pow (pow (..., 2) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords|missed-optimization | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
[Bug middle-end/27136] [4.0/4.1/4.2 Regression] Compile failure with -O -ffast-math
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-17 11:12 --- 1329aval[j] = get_val_for (op[j], val[j]); (gdb) call debug_generic_expr(val[0]) __builtin_pow (xD.1278_4, 2.0e+0) (gdb) call debug_generic_expr(op[0]) xD.1278_3 Program received signal SIGSEGV, Segmentation fault. 0x08316db6 in operand_equal_p (arg0=0xb7dc0798, arg1=0xb7c556c0, flags=0) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/fold-const.c:2423 2423 if (TYPE_UNSIGNED (TREE_TYPE (arg0)) != TYPE_UNSIGNED (TREE_TYPE (arg1))) I think the brute-force evaluation should stop as soon as val[i] is no longer a constant. get_val_for (x=0xb7d3aea0, base=0xb7d39028) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c:1242 1246 if (TREE_CODE (stmt) == PHI_NODE) (gdb) call debug_generic_expr(stmt) xD.1278_3 = __builtin_pow (xD.1278_4, 2.0e+0) (gdb) call debug_generic_expr(x) xD.1278_3 (gdb) call debug_generic_expr(base) __builtin_pow (xD.1278_4, 2.0e+0) now, stmt is the same as the stmt of the first use. get_val_for (x=0xb7d40104, base=0xb7d39028) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c:1242 1242 if (!x) (gdb) finish Value returned is $11 = (union tree_node *) 0xb7d39028 (gdb) call debug_generic_expr($11) __builtin_pow (xD.1278_4, 2.0e+0) 1253 SET_USE (op, val); kaboom. We just created a self-referencing tree here. Now, either punt on non-constant/SSA_NAME val, or unshare val, or punt earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
[Bug middle-end/27136] [4.0/4.1/4.2 Regression] Compile failure with -O -ffast-math
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-17 11:18 --- Now, the comment before get_val_for is confusing, as it says * if BASE is NULL_TREE, X must be a constant and we return X. but we do if (!x) return base; now, I believe a gcc_assert (is_gimple_min_invariant (base)); before this statement is what needs to hold. So the caller needs to be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
[Bug c++/25874] [gomp] ICE in calc_dfs_tree()
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-04-17 12:09
---
The ICE reappeared.
Probably with Jakub's fix for PR26823.
Btw, the testcase in the testsuite didn't trigger, it
probably lacks the line
/* { dg-options "-O" } */
This should be fixed once this bug gets fixed again.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot org
Status|RESOLVED|REOPENED
Resolution|FIXED |
Summary|[gomp branch] ICE in |[gomp] ICE in
|calc_dfs_tree() |calc_dfs_tree()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25874
[Bug middle-end/25989] gomp ICE with -O2 and schedule(guided)
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-17 12:17 --- The testcase fails again (with a segfault): FAIL: gcc.dg/gomp/pr25989.c (test for excess errors) (from http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg00920.html) This is probably due to your fix from PR26823, Jakub. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25989
[Bug middle-end/27181] New: Does not fold access to base with cast to different derived type
Consider the following class hierarchy:
struct StorageBase {
int i;
};
struct NonPod1 : StorageBase {
int get() { return i; }
NonPod1() {}
};
struct NonPod {
NonPod() { x[0].i = 0; x[1].i = 0; }
NonPod1& operator[](int i) { return *static_cast(&x[i]); }
StorageBase x[2];
};
where StorageBase exists to allow the casting in NonPod::operator[] and
at the same time avoid default initialization of NonPod::x (if we were
using NonPod1 x[2]). The following two functions should be optimized
to return 0, the first requires a tree-combiner to do so, the second
requires fold to deal with ((NonPod1 *)&a.x[0])->D.1745.i to see that
x and D.1745 have the same type so it can be folded to a.x[0].i.
int foo(void)
{
NonPod a;
return a[0].get();
}
int bar(void)
{
NonPod a;
return static_cast(&a.x[0])->i;
}
--
Summary: Does not fold access to base with cast to different
derived type
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27181
[Bug middle-end/27181] Does not fold access to base with cast to different derived type
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-17 12:31 --- The tree-combiner requiring function depends on 27084. Also this happens in tramp3d again. Also related to 27090. Still fold needs to catch it first. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27084, 27090 OtherBugsDependingO||22501 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27181
[Bug middle-end/26823] ICE with OpenMP in add_stmt_to_eh_region_fn, at tree-eh.c:100
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-04-17 12:33 --- Fixed on mainline. Thanks for fixing this one, Jakub! Alas there seems to be some fallout: PR25874, PR25989. @Martin: I tried to reduce your testacse a little and got a segfault in can_throw_internal_1. So this is probably the same problem as PR26913. However the original segfault in your code is in duplicate_eh_regions. So maybe there's another bug. But I think that further reduction only makes sense when PR26913 is fixed. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
[Bug middle-end/27136] [4.0/4.1/4.2 Regression] Compile failure with -O -ffast-math
--- Comment #6 from patchapp at dberlin dot org 2006-04-17 13:10 --- Subject: Bug number PR 27136 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00623.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
[Bug target/27182] New: [4.1 regression] SH: wrong-code generation
Hi,
gcc-4.1.0 miscompiles on sh4-linux target.
Attached testcase does not trigger this bug on mainline,
and also correctly compiled with gcc-3.4.5.
For attached testcase, source line 514 is incorrectly compiled with
following command line.
g++ -O2 -g -fno-strict-aliasing -fwrapv \
-fno-implicit-templates -fno-exceptions -fno-rtti -S -o bad.s sql_select4.ii
incorrect result:
.loc 1 515 0
mov.l @(52,r14),r2
.loc 1 514 0
add #12,r1
.loc 1 515 0
mov.l r2,@-r1
.loc 1 514 0
mov #0,r2
mov.l r2,@r1 <= #0 is stored incorrect address
("add #4,r1" is needed bofore this
line)
Adding -fno-schedule-insns fixes this.
g++ -O2 -g -fno-schedule-insns -fno-strict-aliasing -fwrapv \
-fno-implicit-templates -fno-exceptions -fno-rtti -S -o good.s
sql_select4.ii
correct result:
mov #0,r2
.
fmov.s fr6,@r1
fmov.s fr7,@-r1
.loc 1 514 0
add #12,r1
mov.l r2,@r1
.loc 1 515 0
mov.l @(52,r14),r7
mov.l r7,@-r1
On mainline, this problem disapeares after following patch.
2005-11-30 Paolo Bonzini <[EMAIL PROTECTED]>
* simplify-rtx.c (simplify_plus_minus): Remove final parameter.
Always produce an output if we can remove NEGs or canonicalize
(minus (minus ...)) expressions. Provide a fast path for the
two-operand case.
(simplify_gen_binary): Do not call simplify_plus_minus.
(simplify_binary_operation_1): Reassociate at the end of the
function.
--
Summary: [4.1 regression] SH: wrong-code generation
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sugioka at itonet dot co dot jp
GCC build triplet: sh4-unknown-linux
GCC host triplet: sh4-unknown-linux
GCC target triplet: sh4-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27182
[Bug target/27182] [4.1 regression] SH: wrong-code generation
--- Comment #1 from sugioka at itonet dot co dot jp 2006-04-17 13:19 --- Created an attachment (id=11282) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11282&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27182
[Bug target/26826] [4.1/4.2 Regression] ICE in reg_or_subregno, at jump.c:2011
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-17 13:53 --- Subject: Bug 26826 Author: rguenth Date: Mon Apr 17 13:53:19 2006 New Revision: 113007 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113007 Log: 2006-04-17 Richard Guenther <[EMAIL PROTECTED]> PR target/26826 * reload.c (push_reload): Guard calls to get_secondary_mem for memory subregs. Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26826
[Bug target/26826] [4.1 Regression] ICE in reg_or_subregno, at jump.c:2011
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-17 13:54 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression] ICE in |[4.1 Regression] ICE in |reg_or_subregno, at |reg_or_subregno, at |jump.c:2011 |jump.c:2011 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26826
[Bug libgcj/27170] Deadlock in garbage collector
--- Comment #4 from green at redhat dot com 2006-04-17 14:43 --- Created an attachment (id=11283) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11283&action=view) Sample patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug libgcj/27170] Deadlock in garbage collector
--- Comment #5 from green at redhat dot com 2006-04-17 14:44 --- I've uploaded a patch that I've applied to the FC5 gcc RPM. I can't reproduce the problem with this patch. -- green at redhat dot com changed: What|Removed |Added CC||green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug fortran/27122] binary operator functions should require intent(in)
--- Comment #2 from patchapp at dberlin dot org 2006-04-17 15:00 --- Subject: Bug number PR27122 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00626.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27122
[Bug fortran/25615] Internal compiler error in compiling a module which have the same name procedure.
--- Comment #3 from pault at gcc dot gnu dot org 2006-04-17 15:12 --- This fellow now gives: Error: Procedure 'p' at (1) is already defined at (2) on trunk and 4.1, so it is fixed. Arigato goziamasu, Iguchi-san! -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25615
[Bug fortran/25619] temporary array of constant size character type goes wrong
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-17 15:14 --- HJ has fixed this one. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25619
[Bug fortran/25618] ICE with allocate on the return value of a function, character with a len of an argument
--- Comment #2 from pault at gcc dot gnu dot org 2006-04-17 15:18 --- Fixed on trunk and will be fixed on 4.1, when patch for PR25597 is applied next weekend. I will close this now since its purpose is served. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25618
[Bug fortran/25618] ICE with allocate on the return value of a function, character with a len of an argument
--- Comment #3 from pault at gcc dot gnu dot org 2006-04-17 15:18 --- Fixed! -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25618
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #33 from edmar at freescale dot com 2006-04-17 15:22 --- The latest round of patches cured the original problem. Unfortunately, the target itself is still broken. This time because of a bug originaly reported for the e500v1 target. (27075). I am not sure what is the right administrative thing to do. This one was a P3, 27075 was changed to P2 recently. Perhaps a comment on 27075 that it also affects e500v2 target ? I will leave to you guys to decide... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug fortran/23634] temporary array of character ICE with non constant size
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-17 15:32 --- HJ has fixed this one. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23634
[Bug fortran/21877] internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:165
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-17 15:35 --- This one now gives: Error: 's' at (1) must have constant character length in this context on trunk and 4.1 Fixed - thanks, Philippe! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21877
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #34 from mark at codesourcery dot com 2006-04-17 15:37 --- Subject: Re: [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets edmar at freescale dot com wrote: > --- Comment #33 from edmar at freescale dot com 2006-04-17 15:22 --- > The latest round of patches cured the original problem. Unfortunately, the > target itself is still broken. This time because of a bug originaly reported > for the e500v1 target. (27075). > I am not sure what is the right administrative thing to do. This one was a P3, > 27075 was changed to P2 recently. > Perhaps a comment on 27075 that it also affects e500v2 target ? I will leave > to > you guys to decide... If the problem reported in PR 26459 is resolved, then we should close PR 26459. If the problem in PR 27075 also effects E500v2, then we should not that there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #35 from edmar at freescale dot com 2006-04-17 15:44 --- The original problem was solved. For futher bootstrap problems on this target, see bug 27075. -- edmar at freescale dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/27075] [4.1/4.2 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE
--- Comment #9 from edmar at freescale dot com 2006-04-17 15:57 --- This bug also affects target e500v2. The e500v2 is configured with: --target=powerpc-unknowm-linux-gnuspe --enable-e500_double. I will try the patch on comment 8 overnight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075
[Bug libgcj/27170] Deadlock in garbage collector
--- Comment #6 from tromey at gcc dot gnu dot org 2006-04-17 16:00 --- We could either use here (see ltdl.c) or we could use libltdl instead of directly using dlopen... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug fortran/27122] binary operator functions should require intent(in)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-17 16:03:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27122
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #22 from law at redhat dot com 2006-04-17 16:40 ---
Here's some code which can be clearly improved with the in-progress patch to
add additional ASSERT_EXPRs:
int f(void);
void test(int x) {
if (x & 1 ? x == 0 : x > 0) f();
}
Right now we generate something like:
movl4(%esp), %eax
testb $1, %al
je .L2
testl %eax, %eax
sete%al
testb %al, %al
jne .L9
.L7:
rep ; ret
.p2align 4,,7
.L2:
testl %eax, %eax
setg%al
testb %al, %al
je .L7
.L9:
jmp f
With the work-in-progress patch we generate the more compact and efficient:
movl4(%esp), %eax
testb $1, %al
jne .L5
testl %eax, %eax
jg .L7
.L5:
rep ; ret
.p2align 4,,7
.L7:
jmp f
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-04-17 16:54
---
It also helps for propagating loop versioning guard information like
int foo(int i, int j)
{
int res = 0;
if (i==1 && j==2)
for (;i>0;--i)
res += j;
else
for (;i>0;--i)
res += j;
return res;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug middle-end/26823] ICE with OpenMP in add_stmt_to_eh_region_fn, at tree-eh.c:100
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-04-17 17:21 --- The failures in PR25874 and PR25989 are not caused by this patch. Sorry for blaming your patch, Jakub! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
[Bug fortran/27183] New: gfortran - testsuite unexpected failure - assembler error message
Running the testsuite gives an unexpected failure (error out of assembler with -O0) - [pactech01:~/tests] dir% gfortran -w -O3 -c ~/gfortran/gcc/gcc/testsuite/gfortran.dg/assign_2.f90 [pactech01:~/tests] dir% gfortran -w -O2 -c ~/gfortran/gcc/gcc/testsuite/gfortran.dg/assign_2.f90 [pactech01:~/tests] dir% gfortran -w -O1 -c ~/gfortran/gcc/gcc/testsuite/gfortran.dg/assign_2.f90 [pactech01:~/tests] dir% gfortran -w -O0 -c ~/gfortran/gcc/gcc/testsuite/gfortran.dg/assign_2.f90 /var/tmp//cc5uT7yz.s:28:section difference relocatable subtraction expression, "L2" minus "L001$pb" using a symbol at the end of section will not produce an assembly time constant /var/tmp//cc5uT7yz.s:28:use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = L2 - L001$pb [pactech01:~/tests] dir% gfortran --v Using built-in specs. Target: i386-apple-darwin8.6.1 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060417 (experimental) [pactech01:~/tests] dir% WARNING: Couldn't find the global config file. Test Run By dir on Mon Apr 17 09:22:47 2006 Native configuration is i386-apple-darwin8.6.1 === gfortran tests === Schedule of variations: unix Running target unix Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target. Using /Users/dir/gfortran/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/assign_2.f90 -O0 (test for excess errors) Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/vect/vect.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ... === gfortran Summary === # of expected passes12821 # of unexpected failures1 # of expected failures 7 # of unresolved testcases 1 # of unsupported tests 46 /Users/dir/gfortran/ibin/gcc/testsuite/gfortran/../../gfortran version 4.2.0 20060417 (experimental) -- Summary: gfortran - testsuite unexpected failure - assembler error message Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: i386-apple-darwin8.6.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27183
[Bug target/25765] gfortran.dg/assign_2.f90 -O0 fails
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-17 17:23 --- *** Bug 27183 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25765
[Bug fortran/27183] gfortran - testsuite unexpected failure - assembler error message
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-17 17:23 --- I already filed this before. *** This bug has been marked as a duplicate of 25765 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27183
[Bug libgomp/26651] [gomp] #omp for ordered leaks memory
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-17 17:24 --- RTH, alas there seems to be some fallout: PR25874, PR25989. (I first blamed Jakub's patch for PR26823 for the fallout, but closer inspection showed that it's your patch instead.) Would you mind having a look? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26651
[Bug middle-end/22366] [meta-bug] issues related to the removal of loop.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22366
[Bug rtl-optimization/26725] [4.2 Regression] ICE in check_reg_live, at haifa-sched.c:4645 with -O2 on ia64
--- Comment #2 from tbm at cyrius dot com 2006-04-17 18:29 --- What's the status of this bug? Did nobody comment on the proposed patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26725
[Bug debug/27036] ICE in dwarf2out_finish, at dwarf2out.c:14116
--- Comment #2 from tbm at cyrius dot com 2006-04-17 18:33 --- Looks like a duplicate of PR26881 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27036
[Bug libstdc++/21172] potential integer overflow error in STL heap functions
--- Comment #5 from pcarlini at suse dot de 2006-04-17 18:35 --- Working on a fix. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
[Bug tree-optimization/22538] Does not remove stores for struct assignments
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-17 18:36 --- Fixed by: 2006-04-17 Roger Sayle <[EMAIL PROTECTED]> * expr.c (expand_assignment): Optimize away no-op moves where the source and destination are equal and have no side-effects. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22538
[Bug target/24076] (vector char){x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x} code gen is not that good
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-17 18:39 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24076
[Bug c/27184] New: [4.0/4.1/4.2 Regression] Wrong code with pointers to arrays and types and strict aliasing
Testcase (at -O2 and above):
typedef long atype[];
typedef long atype1[];
int NumSift (atype *a, atype1 *a1)
{
(*a)[0] = 0;
(*a1)[0] = 1;
return (*a)[0];
}
int main(void)
{
long a[2];
if (!NumSift(&a, &a))
__builtin_abort ();
return 0;
}
--
Orginally reported here:
http://gcc.gnu.org/ml/gcc/2006-03/msg00638.html
--
Summary: [4.0/4.1/4.2 Regression] Wrong code with pointers to
arrays and types and strict aliasing
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
[Bug c/27184] [4.0/4.1/4.2 Regression] Wrong code with pointers to arrays and types and strict aliasing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
[Bug c++/26114] [4.2 Regression] g++.dg/init/ctor4.C and g++.old-deja/g++.jason/overload34.C and g++.old-deja/g++.mike/p11110.C fails
--- Comment #9 from janis at gcc dot gnu dot org 2006-04-17 19:36 --- Subject: Bug 26114 Author: janis Date: Mon Apr 17 19:35:56 2006 New Revision: 113010 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113010 Log: PR c++/26114, c++/26115 * typeck.c (cxx_mark_addressable): Restore check for extra_warnings. * class.c (check_field_decls): Ditto. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/typeck.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26114
[Bug fortran/25073] CASEs overlap
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-04-17 19:38 --- This is now fixed on mainline and 4.1: $ cat case.f90 program main logical :: l select case (l) case (.true.) case (.true.) end select end program main $ gfortran case.f90 In file case.f90:4 case (.true.) 1 In file case.f90:5 case (.true.) 2 Error: CASE label at (1) overlaps with CASE label at (2) $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran Thread model: posix gcc version 4.2.0 20060412 (experimental) All we need now is a test case, then we can close this. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25073
[Bug c/27184] [4.0/4.1/4.2 Regression] Wrong code with pointers to arrays and types and strict aliasing
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-17 19:55 --- Just to add some information from the conversation on this topic: > > Shouldn't the aliasing set for the type atype be the same as atype1? > > Im not entirely sure, but the C99 standard does at least not suggest > otherwise, instead it says (6.7.7/3) "A typedef declaration does not introduce > a new type, only a synonym for the type so specified." atype and atype1 are compatible bacsue of 6.7.5.2, Array declarators: 6 For two array types to be compatible, both shall have compatible element types, and if both size specifiers are present, and are integer constant expressions, then both size specifiers shall have the same constant value. If the two array types are used in a context which requires them to be compatible, it is undefined behavior if the two size specifiers evaluate to unequal values. I assume that compatible types should be in the same alias set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
[Bug c/27184] [4.0/4.1/4.2 Regression] Wrong code with pointers to arrays and types and strict aliasing
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-17 20:07 --- And this only fails for array types without their size specified. Confirmed. Btw. inside NumShift the two array types are unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > BLK align 32 symtab 0 alias set -1 pointer_to_this > unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > BLK align 32 symtab 0 alias set -1 pointer_to_this > still we create Variable: aD.1278, UID 1278, long intD.2[] *, type memory tag: TMT.5D.1303, default def: aD.1278_1 Variable: a1D.1279, UID 1279, long intD.2[] *, type memory tag: TMT.6D.1304, default def: a1D.1279_2 # TMT.5D.1303_6 = V_MAY_DEF ; (*aD.1278_1)[0] = 0; # TMT.6D.1304_8 = V_MAY_DEF ; (*a1D.1279_2)[0] = 1; # VUSE ; D.1282_3 = (*aD.1278_1)[0]; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-17 20:07:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
[Bug libgcj/27171] UTF8 PrintWriter goes haywire
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-17 20:13 ---
Simplified test case:
public class main {
public static void main(String[] args) {
char x = 56478;
System.out.println(new String(new char[] { x }));
}
}
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-04-17 20:13:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27171
[Bug libgcj/27171] UTF8 PrintWriter goes haywire
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-17 20:23 --- Testing a fix. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-17 20:13:49 |2006-04-17 20:23:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27171
gcc-4.1-20060414
Hello. There is part of build screen: mkdir -p -- libgcc if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi /e/build/gcc-4.1-20060414/host-i786-pc-cygwin/gcc/xgcc -B/e/build/gcc-4.1-20060414/host-i786-pc-cygw in/gcc/ -B/usr/i786-pc-cygwin/bin/ -B/usr/i786-pc-cygwin/lib/ -isystem /usr/i786-pc-cygwin/include - isystem /usr/i786-pc-cygwin/sys-include -O2 -I../.././gcc/../winsup/w32api/include -O2 -mcpu=pentium 4 -mmmx -msse3 -mtune=pentium4 -Os -pipe -s -std=gnu99 -DIN_GCC-W -Wall -Wwrite-strings -Wstric t-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAUL T -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../incl ude -I../.././gcc/../libcpp/include -DL_chkstk -xassembler-with-cpp -c ../.././gcc/config/i386/cygw in.asm -o libgcc/./_chkstk.o cc1: internal compiler error: Illegal instruction Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [libgcc/./_chkstk.o] Error 1 make[3]: Leaving directory `/e/build/gcc-4.1-20060414/host-i786-pc-cygwin/gcc' make[2]: *** [libgcc.a] Error 2 make[2]: Leaving directory `/e/build/gcc-4.1-20060414/host-i786-pc-cygwin/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/e/build/gcc-4.1-20060414' make: *** [all] Error 2 This error happened after core compiler has been build. Exist gcc version 4.1.0 Regards, GeM
[Bug libgcj/27171] UTF8 PrintWriter goes haywire
--- Comment #3 from tromey at gcc dot gnu dot org 2006-04-17 21:41 --- Subject: Bug 27171 Author: tromey Date: Mon Apr 17 21:41:47 2006 New Revision: 113013 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113013 Log: PR libgcj/27171: * testsuite/libjava.lang/pr27171.java: New file. * testsuite/libjava.lang/pr27171.out: New file. * gnu/gcj/convert/Output_UTF8.java (havePendingBytes): Return true if we've seen a high surrogate. (write): Handle high surrogates at the end of the stream. Properly emit isolated low surrogates. Added: trunk/libjava/testsuite/libjava.lang/pr27171.java trunk/libjava/testsuite/libjava.lang/pr27171.out Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/gcj/convert/Output_UTF8.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27171
[Bug libgcj/27171] UTF8 PrintWriter goes haywire
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-17 21:45 --- Subject: Bug 27171 Author: tromey Date: Mon Apr 17 21:45:42 2006 New Revision: 113014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113014 Log: PR libgcj/27171: * testsuite/libjava.lang/pr27171.java: New file. * testsuite/libjava.lang/pr27171.out: New file. * gnu/gcj/convert/Output_UTF8.java (havePendingBytes): Return true if we've seen a high surrogate. (write): Handle high surrogates at the end of the stream. Properly emit isolated low surrogates. Added: branches/gcc-4_1-branch/libjava/testsuite/libjava.lang/pr27171.java - copied unchanged from r113013, trunk/libjava/testsuite/libjava.lang/pr27171.java branches/gcc-4_1-branch/libjava/testsuite/libjava.lang/pr27171.out - copied unchanged from r113013, trunk/libjava/testsuite/libjava.lang/pr27171.out Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/gnu/gcj/convert/Output_UTF8.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27171
[Bug libgcj/27171] UTF8 PrintWriter goes haywire
--- Comment #5 from tromey at gcc dot gnu dot org 2006-04-17 21:46 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27171
[Bug ada/27186] New: GNAT BUG DETECTED with Booch Components Set_Test_Support
Compiles Booch Components but does not compile a package used for testing the components. Compiler creates the ali file but no object file. Cygwin from http://sources.redhat.com/cygwin/ Compiler (GNU Ada, package GNAT/GCC MS-Windows Cygwin, release 4.1.0 R4) from http://sourceforge.net/project/showfiles.php?group_id=12974&package_id=185727 Booch Components (version 20051222) from http://sourceforge.net/project/showfiles.php?group_id=135616 Attached will be the gnatchop input. Attached will be a BASH file 'build.sh' for reproducing the problem; its output is: gcc -v Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc-4.1.0/configure --enable-gmp --enable-mpfr --enable-threads=posix --prefix=/opt/gnat/gcc --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ i686-pc-cygwin Thread model: posix gcc version 4.1.0 uname -a CYGWIN_NT-5.1 DAL1K0496 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin gnatls -v GNATLS 4.1.0 Copyright 1997-2005 Free Software Foundation, Inc. Source Search Path: /opt/gnat/gcc/lib/gcc/i686-pc-cygwin/4.1.0/adainclude/ Object Search Path: /opt/gnat/gcc/lib/gcc/i686-pc-cygwin/4.1.0/adalib/ Project Search Path: /opt/gnat/gcc/lib/gnat/ gnatchop set-test-support-gnatchop-input.txt splitting set-test-support-gnatchop-input.txt into: bc.ads bc-containers.ads bc-containers-sets.ads bc-containers-sets-bounded.ads bc-support.ads bc-support-bounded_hash_tables.ads bc-containers-sets-dynamic.ads bc-support-dynamic.ads bc-support-hash_tables.ads bc-containers-sets-unbounded.ads bc-support-unbounded.ads bc-containers-sets-unmanaged.ads bc-support-unmanaged.ads bc-support-standard_storage.ads bc-support-managed_storage.ads bc-support-bounded_hash_tables.adb bc-support-hash_tables.adb bc-containers.adb bc-containers-sets.adb bc-containers-sets-bounded.adb bc-containers-sets-dynamic.adb bc-support-dynamic.adb bc-containers-sets-unbounded.adb bc-support-unbounded.adb bc-containers-sets-unmanaged.adb bc-support-unmanaged.adb global_heap.ads set_test_support.ads set_test_support.adb gnatmake -O2 -g -gnatqQafy -gnatwaL set_test_support gcc -c -O2 -g -gnatqQafy -gnatwaL set_test_support.adb +===GNAT BUG DETECTED==+ | 4.1.0 (i686-pc-cygwin) GCC error:| | in get_constraint_for_component_ref, at tree-ssa-structalias.c:2148 | | Error detected at set_test_support.adb:25:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. set_test_support.adb set_test_support.ads bc.ads bc-containers.ads bc-containers-sets.ads bc-containers-sets-bounded.ads bc-support.ads bc-support-bounded_hash_tables.ads bc-containers-sets-dynamic.ads bc-support-dynamic.ads bc-support-hash_tables.ads bc-containers-sets-unbounded.ads bc-support-unbounded.ads bc-containers-sets-unmanaged.ads bc-support-unmanaged.ads bc-support-standard_storage.ads global_heap.ads bc-support-managed_storage.ads bc-support-bounded_hash_tables.adb bc-support-hash_tables.adb bc-containers.adb bc-containers-sets.adb bc-containers-sets-bounded.adb bc-containers-sets-dynamic.adb bc-support-dynamic.adb bc-containers-sets-unbounded.adb bc-support-unbounded.adb bc-containers-sets-unmanaged.adb bc-support-unmanaged.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 gnatmake: "set_test_support.adb" compilation error -- Summary: GNAT BUG DETECTED with Booch Components Set_Test_Support Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: george dot chapman at lmco dot com GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #1 from george dot chapman at lmco dot com 2006-04-17 22:00 --- Created an attachment (id=11287) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11287&action=view) gnatchop input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #2 from george dot chapman at lmco dot com 2006-04-17 22:01 --- Created an attachment (id=11288) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11288&action=view) shell input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug target/27187] New: gcc.target/powerpc/doloop-1.c doesn't get desired branch insn
Test gcc.target/powerpc/doloop-1.c has failed on mainline for powerpc64-linux with -m64 and for powerpc-apple-darwin8.5.0 since this patch was added: http://gcc.gnu.org/viewcvs?view=rev&rev=112126 r112126 | mkuvyrkov | 2006-03-16 05:20:39 + (Thu, 16 Mar 2006) | 9 lines 2006-03-16 Maxim Kuvyrkov <[EMAIL PROTECTED]> * sched-rgn.c (extend_rgns): New static function. (find_rgns): Use it. (gather_region_statistics, print_region_statistics): New static functions. * params.def (PARAM_MAX_SCHED_EXTEND_REGIONS_ITERS): New parameter. * doc/invoke.texi (max-sched-extend-regions-iters): Document. The test fails because instruction bdnz is no longer generated. The loop in queston went from: .L7: add 4,4,9 addi 9,9,1 bdnz .L7 to: .L7: addic. 0,0,-1 add 4,4,9 addi 9,9,1 bne 0,.L7 -- Summary: gcc.target/powerpc/doloop-1.c doesn't get desired branch insn Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27187
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
-- bdavis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-09-19 00:49:39 |2006-04-17 22:53:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug target/27187] gcc.target/powerpc/doloop-1.c doesn't get desired branch insn
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-17 22:54 --- *** This bug has been marked as a duplicate of 26727 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27187
[Bug rtl-optimization/26727] [4.2 Regression] gcc.target/powerpc/doloop-1.c fails
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-17 22:54 --- *** Bug 27187 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26727
Bugs kopete-0.7.3
|| echo './'`kopetecontactlist.cpp kopetecontactlist.cpp: In member function `QStringList KopeteContactList::contactFileProtocols(const QString&)': kopetecontactlist.cpp:779: internal error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: ** [kopetecontactlist.lo] Erro 1 make[4]: Leaving directory `/home/kopete-0.7.3/kopete/libkopete' make[3]: ** [all-recursive] Erro 1 make[3]: Leaving directory `/home/kopete-0.7.3/kopete/libkopete' make[2]: ** [all-recursive] Erro 1 make[2]: Leaving directory `/home/kopete-0.7.3/kopete' make[1]: ** [all-recursive] Erro 1 make[1]: Leaving directory `/home/kopete-0.7.3' make: ** [all] Erro 2 [EMAIL PROTECTED]:/home/kopete-0.7.3#
[Bug c/27153] function result is dereferenced error
--- Comment #7 from alexey at cs dot sunysb dot edu 2006-04-18 00:06 --- (In reply to comment #6) > In C, there is no ordering left to right, please go read the C FAQ at: > http://www.eskimo.com/~scs/c-faq.com/expr/index.html > subpage: > http://www.eskimo.com/~scs/c-faq.com/expr/comma.html The problem has nothing to do with ordering. It is in because arguments are evaluated not completely before the next one is evaluated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
[Bug c/27153] function result is dereferenced error
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-18 00:21 ---
(In reply to comment #7)
> (In reply to comment #6)
> > In C, there is no ordering left to right, please go read the C FAQ at:
> > http://www.eskimo.com/~scs/c-faq.com/expr/index.html
> > subpage:
> > http://www.eskimo.com/~scs/c-faq.com/expr/comma.html
> The problem has nothing to do with ordering. It is in because arguments are
> evaluated not completely before the next one is evaluated.
Even then, the order inside the epxressions is not specified which means
a+b+c+d can be such that the a, b, c, and d subexpressions are in any order as
long as there are not squence points, even then it is only the a partial
ordering.
For an example:
(a, b) + (c, d) + (e, f)
can be evaulated in the following order and would be still be valid:
a c e b d f add add
or
a b c e d f add add
as long as the ordering of a comes before b and c comes before d and e comes
before f, it is valid. This is what is meant by partial ordering.
therefor in your orginal expample we have:
f ("", OP0(f0()), OP1(f1()), OP2(f2()));
the ordering here of each sub expression is not specified in that
f0() might come before f2() but it does have to come before the call to f and
the operation OP0 just because of dependicies.
Hopefully this explains what is going on here and why this bug is invalid and
is a dup of PR 11751.
What you need to think of is that the comma in a function call is just a
seperator and there is no evaulation requirement on which expression (or
subexpression) gets evaulated first in the same way:
(a++ + b++) + (a++ + b++);
there is no requirment which a++ (or b++) is evaulated first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #3 from george dot chapman at lmco dot com 2006-04-18 00:35 --- (From update of attachment 11287) Missing body for Managed_Storage. -- george dot chapman at lmco dot com changed: What|Removed |Added Attachment #11287|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #4 from george dot chapman at lmco dot com 2006-04-18 00:36 --- Created an attachment (id=11289) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11289&action=view) gnatchop input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #5 from george dot chapman at lmco dot com 2006-04-18 00:40 --- Compiles at "-O0" but not "-O1" and subsequent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug debug/27188] New: libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009
/home/dave/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gcc-4.2/objdir/./gcc/ -B/home/ dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hp pa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/include -isys tem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include -O2 -O2 -g -O2 -DI N_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold -style-definition -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DHAVE_GTHR_DE FAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I../../gcc /gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc /gcc/../libdecnumber -I../libdecnumber -DL_mulvdi3 -fvisibility=hidden -DHIDE_EX PORTS -c ../../gcc/gcc/libgcc2.c -o libgcc/./_mulvdi3.o ../../gcc/gcc/libgcc2.c:382: internal compiler error: in prune_unused_types_upda te_strings, at dwarf2out.c:14009 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [libgcc/./_mulvdi3.o] Error 1 -- Summary: libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
[Bug debug/27188] [4.2 Regression] libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aldyh at gcc dot gnu dot org Keywords||build, ice-on-valid-code Summary|libgcc2.c:382: internal |[4.2 Regression] |compiler error: in |libgcc2.c:382: internal |prune_unused_types_update_st|compiler error: in |rings, at dwarf2out.c:14009 |prune_unused_types_update_st ||rings, at dwarf2out.c:14009 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
[Bug debug/27188] [4.2 Regression] libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-18 01:33 --- Sorry Aldy for CCing you (I saw prune_unused and thought it was your front-end patch). When in fact it was: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00641.html That caused the ICE. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|aldyh at gcc dot gnu dot org|geoffk at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
[Bug c/27190] New: Support for multiline string constant
char* help = "Usage: foo [options] -v verbose -d debug "; Code like the above should work. It is really convenient when editing this code that you do not have to terminate your lines with cruft like \n\ Of course this is pure convenience, but I never heard any convincing argument why this should not be possible. If some C standard forbids it, then I think the standard is out of touch from user base and it would be a really good idea to add gcc specific extension. I do not mind if I have to turn the extension on with some -fmultiline-string-constant flag - such flags are easy enough to add to Makefile. --Sampo -- Summary: Support for multiline string constant Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sampo at symlabs dot com GCC build triplet: any GCC host triplet: any GCC target triplet: any http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27190
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #2 from wszafran at users dot sourceforge dot net 2006-04-18 03:10 --- Yes, it works like a charm now. I only built the CygWin-hosted, MinGW-targetting compiler with your patch applied, but I suppose a similar result would be achieved with a compiler bootstrapped on CygWin. I understand the patch you posted is your private copy, not applied to the official source tree yet. Do you think it'll make it for the next snapshot, so that others who are affected could use this fix? Thank you very much for your work on this, it's appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug c/27153] function result is dereferenced error
--- Comment #9 from bangerth at dealii dot org 2006-04-18 03:21 --- > It does not matter either. The evaluation of a function argument is an atomic > procedure. No, it actually isn't. > If it starts it should generate a result. Isn't it strange if the > compiler evaluates a little bit of the first argument, then a little bit of > the > second argument, then a little bit of the third argument, then goes back to > the > first and completes the evaluation? Maybe. But it's allowed under the standard, and if the compiler can produce better code this way it should use its liberty. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
[Bug c++/26838] Legal program rejection - protected base method addressing fails from grandchild class
--- Comment #4 from bangerth at dealii dot org 2006-04-18 03:28 --- This is not a bug. While the name in a function call is looked up from inside the class, the name of a member function is looked up in the global scope. There, the member in question here is inaccessible. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26838
[Bug c++/26917] [4.0/4.1/4.2 regression] ICE with -frepo on invalid code
--- Comment #1 from bangerth at dealii dot org 2006-04-18 03:30 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-18 03:30:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26917
[Bug c/27191] New: ice on bootstrap - dwarf2out.c
/home/jerry/gcc/4.2/./gcc/xgcc -B/home/jerry/gcc/4.2/./gcc/ -B/home/jerry/gcc/usr/i686-pc-linux-gnu/bin/ -B/home/jerry/gcc/usr/i686-pc-linux-gnu/lib/ -isystem /home/jerry/gcc/usr/i686-pc-linux-gnu/include -isystem /home/jerry/gcc/usr/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c \ ../../main/gcc/config/i386/crtfastmath.c \ -o crtfastmath.o /bin/sh ../../main/gcc/../move-if-change tmp-macro_list macro_list ../../main/gcc/config/i386/crtfastmath.c:110: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [crtfastmath.o] Error 1 -- Summary: ice on bootstrap - dwarf2out.c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27191
[Bug c++/26988] template constructor in template class derived from virtual base can not be specialized
--- Comment #2 from bangerth at dealii dot org 2006-04-18 03:45 ---
Confirmed, though this doesn't seem to have anything to do with PR 9050.
Here's a shorter testcase:
--
struct B{};
struct Bar : virtual B {
template Bar( T const& cast );
};
template <> Bar::Bar( int const & cast ) {}
template
struct Foo : virtual B {
template Foo( T1 const& cast );
};
template< > template< >
Foo< char >::Foo( int const & cast ) {}
-
g/x> /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c x.cc
x.cc:7: error: template-id ‘Bar<>’ for ‘Bar::Bar(const
int&)’ does not match any template declaration
x.cc:7: error: invalid function declaration
x.cc:15: error: template-id ‘Foo<>’ for ‘Foo::Foo(const
int&)’ does not match any template declaration
x.cc:15: error: invalid function declaration
The thing that makes me think that this has nothing to do with 9050 is that
if the inheritance is made non-virtual, then the bug goes away. That's
certainly odd behavior -- this is a bug in semantic analysis, not in the
parser!
This used to work in 2.95, so is a regression of rejects-valid kind.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Known to fail||3.3.5 3.4.4 4.0.1 4.1.0
Known to work||2.95
Priority|P3 |P2
Last reconfirmed|-00-00 00:00:00 |2006-04-18 03:45:10
date||
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26988
[Bug c++/26997] g++ reports misleading error message when the identifier with error occurs earlier on the same line
--- Comment #3 from bangerth at dealii dot org 2006-04-18 03:47 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-18 03:47:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26997
[Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
--- Comment #8 from bangerth at dealii dot org 2006-04-18 03:50 --- We've had numerous such reports in the past. The compiler can't do anything to detect whether it has run out of stack space. What happens is that a program allocates stack space, the operating systems gives it to the program but doesn't actually provide physical space. When the program starts to write into the area, the OS has to provide the memory, but when it's out of memory it just says that the read or write was a segmentation fault and aborts the program. The program can't know why this happened. There is (unfortunately) nothing we can do about the situation. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug c++/27053] symbol2.c:2102: internal error: Segmentation fault when i try to compile gSOAP in cross compilation
-- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27053
[Bug c/27191] ice on bootstrap - dwarf2out.c
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-04-18 03:51 --- I just found this already reported. *** This bug has been marked as a duplicate of 27188 *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27191
[Bug debug/27188] [4.2 Regression] libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-04-18 03:51 --- *** Bug 27191 has been marked as a duplicate of this bug. *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
[Bug c/27192] New: call through function pointer goes to wrong address
The program below confuses gcc in such a way that it generates code loading the
byte-address of bar() into the Z register, which causes icall to jump off to
neverneverland. Rather, the double-byte address of bar() should be loaded into
Z before the indirect call.
This bug is also present in gcc 4.0.3 and 3.4.3.
avr-gcc -v gives:
Target: avr
Configured with: ../gcc-4.1.0/configure --prefix=/home/regehr/gcc-4.1.0-avr-bin
--disable-libssp --disable-nls --target=avr
Thread model: single
gcc version 4.1.0
Compile with:
avr-gcc -Os -Wall shifty.c -o shifty.elf
Program:
struct fseqp_void
{
void (*p) (void);
char *e;
};
struct fseqp_void c[2];
void bar (void)
{
}
void foo (void)
{
int i;
for (i=0; i<32; i++);
}
int main (void)
{
c[0].e = (char *)bar + 2;
c[0].p = bar;
foo ();
struct fseqp_void x = c[0];
void (*start) (void) = x.p;
(*start)();
return 0;
}
--
Summary: call through function pointer goes to wrong address
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC host triplet: i686-linux-gnu
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192
[Bug c/27193] New: dump-tree-original-raw does not print the linkage for a variable with file scope.
dump-tree-original-raw does not print the linkage for
a variable with file scope.
--- test case (sta.c)---
static int static_var=9;
double global_var = 0;
main() {
int x;
x = 4+ static_var + global_var;
return x;
}
-- to reproduce ---
gcc -fdump-tree-original-raw sta.c
tail -7 sta.c.t02.original
-- bug ---
There is no linkage infomation "static" can be found for var_del static_var.
@39 var_decl name: @41 type: @7 srcp: sta.c:1
init: @42 size: @9 algn: 32
used: 1
@40 integer_cst type: @7 low : 4
@41 identifier_node strg: static_var lngt: 10
@42 integer_cst type: @7 low : 9
--- config ---
$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --enable-languages=c,c++
Thread model: single
gcc version 4.1.0
--
Summary: dump-tree-original-raw does not print the linkage for a
variable with file scope.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yokoyama-hxb at necst dot nec dot co dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27193
[Bug debug/27188] [4.2 Regression] libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009
--- Comment #3 from geoffk at gcc dot gnu dot org 2006-04-18 06:12 --- Preprocessed source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
[Bug c/27153] function result is dereferenced error
--- Comment #10 from falk at debian dot org 2006-04-18 06:27 --- Uhm, this has nothing to do at all with evaluation order. Evaluation order of arguments is unspecified (not undefined, which wouldn't make a lot of sense), but that is in fact irrelevant here, it could lead to, say, 3 1 2, but not 1 1 1. The actual problem is that val is modified more than once without an intervening sequence point, which makes the behavior undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
