[Bug libmudflap/20003] libmudflap.cth
--- Additional Comments From gschafer at zip dot com dot au 2005-07-26 06:07 --- (In reply to comment #1) Fixed at least in 4.0.1. No it's not. Please see these results for example (all from different folks): http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01370.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01310.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00831.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00621.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00603.html Here is an example of what shows up in the log file: Overriding timeout = 20 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000 3100 3200 3300 3400 3500 3600 3700 3800 3900 4000 4100 4200 4300 4400 4500 4600 4700 4800 4900 5000 FAIL: libmudflap.cth/pass40-frag.c execution test FAIL: libmudflap.cth/pass40-frag.c output pattern test Output pattern 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000 3100 3200 3300 3400 3500 3600 3700 3800 3900 4000 4100 4200 4300 4400 4500 4600 4700 4800 4900 5000 5100 5200 5300 5400 5500 5600 5700 5800 5900 6000 6100 6200 6300 6400 6500 6600 6700 6800 6900 7000 7100 7200 7300 7400 7500 7600 7700 7800 7900 8000 8100 8200 8300 8400 8500 8600 8700 8800 8900 9000 9100 9200 9300 9400 9500 9600 9700 9800 9900 1 Please reopen bug. Thanks. -- What|Removed |Added CC||gschafer at zip dot com dot ||au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
[Bug libmudflap/23069] New: libmudflap.cth timeouts too short
In these files:
libmudflap/testsuite/libmudflap.cth/pass3{7,9}-frag.c
the timeout is overridden to 3 seconds. This is way too short if for example
running the testsuite with -j3 on an SMP box. It results in many timeouts as per
these examples:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01114.html
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00451.html
I'm not sure what the ideal timeout should be but 20 seconds made the timeouts
go away for me. Thanks.
--
Summary: libmudflap.cth timeouts too short
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gschafer at zip dot com dot au
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23069
[Bug c/23070] New: CALL_V4_CLEAR_FP_ARGS flag not properly set
When a prototyped function of var-arg is called without any arguments
to the variable part, crxor 6,6,6 is not generated. -O0
-mno-prototype does NOT resolve the problem either.
test.c
int test(const char *a, ...);
void test1(const char *a)
{ test(a, 0); }
void test2(const char *a)
{ test(a); }
test.s
.file test.c
.section.text
.align 2
.globl test1
.type test1, @function
test1:
stwu 1,-24(1)
mflr 0
stw 31,20(1)
stw 0,28(1)
mr 31,1
stw 3,8(31)
lwz 3,8(31)
li 4,0
crxor 6,6,6== has it
bl test
lwz 11,0(1)
lwz 0,4(11)
mtlr 0
lwz 31,-4(11)
mr 1,11
blr
.size test1, .-test1
.align 2
.globl test2
.type test2, @function
test2:
stwu 1,-24(1)
mflr 0
stw 31,20(1)
stw 0,28(1)
mr 31,1
stw 3,8(31)
lwz 3,8(31)
bl test == does not have
lwz 11,0(1)
lwz 0,4(11)
mtlr 0
lwz 31,-4(11)
mr 1,11
blr
.size test2, .-test2
.ident GCC: (GNU) 3.4.3
--
Summary: CALL_V4_CLEAR_FP_ARGS flag not properly set
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tong_ho at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-eabi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23070
[Bug tree-optimization/23068] [4.1 Regression] errors in comparison operator for char
--- Additional Comments From Jean-pierre dot vial at wanadoo dot fr
2005-07-26 06:36 ---
(In reply to comment #1)
I cannot reproduce it on 20050725. What options are you using to create the
executable.
I tried with -O0, -O1, -O2, and -O3 and no success.
no bug with -O0 or -O1
bug with -O2 and -O3
incidentally, if the code is modified as
unsigned char c,d;
d=128;
for (c=127;c130;c++){
printf(test : (char) %d = 128 result %d\n,c,c=128);
printf(test : (char) %d 128 result %d\n,c,c128);
everything works fine
I am presently re-compiling version 20050725 in case of
hardware bug during my first compilation of the compiler.
I will see if this fixes the problem.
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23068
[Bug target/23071] New: Darwin alignment ignores attribute packed for first 'double' element of a struct
Darwin ignores the alignment/packed attributes on this structure, forcing the
structure to have 8-byte alignment and 16-byte size:
---
struct Test {
double D __attribute__((packed,aligned(4)));
short X;
};
---
Ian Lance Taylor did a great analysis of the history of this, tracking it back
to a patch by David Edelsohn in 1996. The analysis is here:
http://gcc.gnu.org/ml/gcc-help/2005-07/msg00280.html
-Chris
--
Summary: Darwin alignment ignores attribute packed for first
'double' element of a struct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: dje at watson dot ibm dot com
ReportedBy: sabre at nondot dot org
CC: gcc-bugs at gcc dot gnu dot org,ian at airs dot com
GCC host triplet: powerpc-darwin-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug tree-optimization/19049] not vectorizing a fortran loop
--- Additional Comments From irar at il dot ibm dot com 2005-07-26 07:07 --- The data dependence issue was solved by this patch http://gcc.gnu.org/ml/gcc- patches/2005-07/msg01195.html (committed). However, this loop is still not vectorizable because of noncontinuous access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19049
[Bug tree-optimization/22486] Upcasts are not folded away
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-26 07:35 --- Subject: Bug 22486 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-26 07:34:58 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: upcast-1.c Log message: 2005-07-26 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/22486 * fold-const.c (fold_unary): Fold away useless component references of the form (T *)T.x, if the address doesn't change. * gcc.dg/tree-ssa/upcast-1.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9546r2=2.9547 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.609r2=1.610 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5822r2=1.5823 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/upcast-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22486
[Bug tree-optimization/22486] Upcasts are not folded away
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-26 07:37 --- In principle this is fixed. Of course we either need a tree-combiner or forwprop on steroids to catch all cases. Which would make this bug a duplicate. Closed Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22486
[Bug tree-optimization/22504] [4.1 Regression] benchmark - galgel fails at runtime with miscompare output
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 08:26 --- These are the only bugs I could find in expand_complex_addition: Index: tree-complex.c === RCS file: /cvs/gcc/gcc/gcc/tree-complex.c,v retrieving revision 2.39 diff -u -3 -p -r2.39 tree-complex.c --- tree-complex.c 25 Jul 2005 23:04:33 - 2.39 +++ tree-complex.c 26 Jul 2005 08:26:07 - @@ -844,7 +844,7 @@ expand_complex_addition (block_stmt_iter case PAIR (VARYING, ONLY_IMAG): rr = ar; - ri = gimplify_build2 (bsi, MINUS_EXPR, inner_type, ai, bi); + ri = gimplify_build2 (bsi, code, inner_type, ai, bi); break; case PAIR (ONLY_REAL, VARYING): @@ -858,7 +858,7 @@ expand_complex_addition (block_stmt_iter if (code == MINUS_EXPR) goto general; rr = br; - ri = gimplify_build2 (bsi, MINUS_EXPR, inner_type, ai, bi); + ri = gimplify_build2 (bsi, code, inner_type, ai, bi); break; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22504
[Bug treelang/23072] New: multiple runs of treelang testsuite does not work...
In http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01369.html and test results of mine not yet posted, I see that if one tries to run the treelang test suite multiple times, e.g., with different compile options such as for multilibbed builds, the first run is done but not more... To me, this happens also on the 4.0 branch. -- Summary: multiple runs of treelang testsuite does not work... Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: treelang AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot joensson at gmail dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc64-unknown-linux-gnu GCC host triplet: sparc64-unknown-linux-gnu GCC target triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23072
07 Cok Gec olabilir
Okul Oncesi Couk ve Anne Baba Egitimi Okul Oncesi Cocuklar Icın Hazırlanmis Odullu CD'leri Gordunuzmu? http://www.cocukdunyasi.net
[Bug tree-optimization/22598] [4.1 Regression] 23_containers/set/explicit_instantiation/3.cc fails
--- Additional Comments From hp at gcc dot gnu dot org 2005-07-26 09:44 --- I'm betting it's the same bug that is visible with 1.cc (again, 1.cc indeed FAILs, does not PASS) on mmix-knuth-mmixware (cutnpaste from log): /home/hp/combined/mmix-regobj/mmix-knuth-mmixware/libstdc++-v3/include/bits/stl_set.h: In member fu\ nction 'std::pairtypename std::_Rb_tree_Key, _Key, std::_Identity_Key, _Compare, typename _Allo\ c::rebind_Key::other::const_iterator, bool std::set_Key, _Compare, _Alloc::insert(const _Key\ ) [with _Key = int, _Compare = std::lessint, _Alloc = std::allocatorint]':^M /home/hp/combined/mmix-regobj/mmix-knuth-mmixware/libstdc++-v3/include/bits/stl_set.h:318: internal\ compiler error: tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:46\ 6^M PASSED with Mon Jul 18 16:34:10 UTC 2005 FAILS with Mon Jul 25 22:33:14 UTC 2005 -- What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22598
[Bug c++/19932] [3.4 Regression] FAIL: g++.old-deja/g++.jason/rfg12.C (test for excess errors)
--- Additional Comments From giovannibajo at libero dot it 2005-07-26 09:46 --- What is the value of 'type' when error() is called? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19932
[Bug libstdc++/23053] Const-correctness issue in TR1 hashtable
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-26 09:46 --- Subject: Bug 23053 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-07-26 09:46:23 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/tr1: hashtable Added files: libstdc++-v3/testsuite/tr1/6_containers/unordered/hashtable: 23053.cc Log message: 2005-07-26 Dave Odell [EMAIL PROTECTED] PR libstdc++/23053 * include/tr1/hashtable (hashtable::find_node): Const-ify. * testsuite/tr1/6_containers/unordered/hashtable/23053.cc: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2917.2.69r2=1.2917.2.70 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/hashtable/23053.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/hashtable.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3r2=1.3.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23053
[Bug libstdc++/23053] Const-correctness issue in TR1 hashtable
--- Additional Comments From pcarlini at suse dot de 2005-07-26 09:48 --- Fixed for 4.0.2. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23053
[Bug tree-optimization/23073] New: [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
PASSes with Mon Jul 18 16:34:10 UTC 2005. FAILs with Mon Jul 25 22:33:14 UTC 2005. gcc.log says: Executing on host: /home/hp/combined/mmix-regobj/gcc/xgcc -B/home/hp/combined/mmix-regobj/gcc/ /hom\ e/hp/combined/combined/gcc/testsuite/gcc.dg/tree-ssa/ifc-20040816-2.c -c -O2 -ftree-vectorize -fd\ ump-tree-ifcvt-stats -fno-show-column -S -isystem /home/hp/combined/mmix-regobj/mmix-knuth-mmixwar\ e/./newlib/targ-include -isystem /home/hp/combined/combined/newlib/libc/include -o ifc-20040816-2.\ s(timeout = 300) /home/hp/combined/combined/gcc/testsuite/gcc.dg/tree-ssa/ifc-20040816-2.c: In function 'foo':^M /home/hp/combined/combined/gcc/testsuite/gcc.dg/tree-ssa/ifc-20040816-2.c:11: internal compiler err\ or: Segmentation fault^M .i forthcoming. -- Summary: [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc- 20040816-2.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: mmix-knuth-mmixware http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
[Bug tree-optimization/23073] [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
--- Additional Comments From hp at gcc dot gnu dot org 2005-07-26 09:58 --- Created an attachment (id=9362) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9362action=view) preprocessed testcase /home/hp/combined/mmix-regobj/gcc/cc1 -fpreprocessed ifc-20040816-2.i -quiet -dumpbase ifc-2004081\ 6-2.c -auxbase-strip ifc-20040816-2.s -O2 -version -ftree-vectorize -fdump-tree-ifcvt-stats -fno-sh\ ow-column -o ifc-20040816-2.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-07-26 10:06 ---
Subject: Re: [4.1 Regression] wrong code for casts and scev
After inlining, we end up with a loop containing the following code:
b.0_3 = (signed char) b_8;
D.1621_4 = (int) b.0_3;
a_5 = (signed char) D.1621_4;
D.1640_6 = (int) a_5;
b_7 = D.1640_6 - 127;
if (b_7 1) goto L3; else goto L9;
that is equivalent to:
b_7 = ((int) (signed char) (int) (signed char) b_8) - 127;
if (b_7 1) goto L3; else goto L9;
with b_8 = (unsigned char) {1, +, 1}
b_7 = ((int) (signed char) (int) (signed char) {(uchar)1, +, (uchar)1}) -
127;
if (b_7 1) goto L3; else goto L9;
A sequence of unsigned char 1, 2, ..., 255 has to be converted to
signed char that would wrap with -fwrapv: 1, 2, ..., 127, -128, ...
So here is a patch that keeps the cast if the sequence wraps. The
remaining problem is that with this patch, chrec_convert gets more
picky about the things that it transforms: in some of the testcases of
the vectorizer, we get some fails because the number of iterations is
not known, making scev_probably_wraps_p to return true, and finally
the conversion is kept.
I have bootstrapped this patch on x86_64, but there are some
regressions:
FAIL: gcc.dg/vect/vect-46.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Vectorizing an unaligned
access 2
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Alignment of access forced
using peeling 1
FAIL: gcc.dg/vect/vect-52.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-52.c scan-tree-dump-times Vectorizing an unaligned
access 2
FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times Alignment of access forced
using peeling 1
FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times Vectorizing an unaligned
access 2
FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times vectorized 1 loops 3
FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times Alignment of access forced
using peeling 3
In all these cases, the loop bound is a parameter. If IP-constant
propagation is not used, chrec_convert has not enough information for
removing the cast. I propose to modify all these testcases to make
the loop bound explicit.
FAIL: gcc.dg/vect/vect-77.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-77.c scan-tree-dump-times Vectorizing an unaligned
access 1
FAIL: gcc.dg/vect/vect-78.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-78.c scan-tree-dump-times Vectorizing an unaligned
access 1
For these two regressions, the problem is the same: we end with an
evolution: ib_16 + (aint *) ((long unsigned int) {off_11, +, 1}_1 * 4)
in which the casts cannot be removed because the offset is not known,
and even if the number of iterations is known, chrec_convert cannot
prove that it does not overflow. I propose to propagate the offset
by hand, or to wait for ipcp ;-)
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times Alignment of access forced
using peeling 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times Alignment of access forced
using peeling 1
For these two testcases we'll need IP-value range propagation. I
think that we'll have to modify these testcases by inlining the code.
Dorit, could you look at vect-{77,78,87,88}.c testcases? Thanks.
* tree-cfg.c (print_succ_bbs): Correctly print successors.
* tree-chrec.c (chrec_convert): Call scev_probably_wraps_p for checking
that the iv does not wrap before converting the iv.
* tree-ssa-loop-ivcanon.c: Correct typo in comment.
* tree-ssa-loop-ivopts.c (idx_find_step): Add a fixme note.
* tree-ssa-loop-niter.c (scev_probably_wraps_p): Check that AT_STMT is
not null.
(convert_step): Add a comment.
Index: tree-cfg.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.211
diff -d -u -p -r2.211 tree-cfg.c
--- tree-cfg.c 12 Jul 2005 13:20:28 - 2.211
+++ tree-cfg.c 26 Jul 2005 09:59:38 -
@@ -4454,7 +4454,7 @@ static void print_pred_bbs (FILE *, basi
static void print_succ_bbs (FILE *, basic_block bb);
-/* Print the predecessors indexes of edge E on FILE. */
+/* Print on FILE the indexes for the predecessors of basic_block BB. */
static void
print_pred_bbs (FILE *file, basic_block bb)
@@ -4463,11 +4463,11 @@ print_pred_bbs (FILE *file, basic_block
edge_iterator ei;
FOR_EACH_EDGE (e, ei, bb-preds)
-fprintf (file, bb_%d, e-src-index);
+fprintf (file, bb_%d , e-src-index);
}
-/* Print the successors indexes of
[Bug debug/20161] [4.0/4.1 Regression] ICE with dwarf for incomplete element type argument
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26
10:18 ---
Let's try this patch then.
Index: passes.c
===
RCS file: /cvs/gcc/gcc/gcc/passes.c,v
retrieving revision 2.105
diff -u -3 -p -r2.105 passes.c
--- passes.c19 Jul 2005 18:45:56 - 2.105
+++ passes.c26 Jul 2005 10:12:55 -
@@ -175,7 +175,10 @@ rest_of_decl_compilation (tree decl,
timevar_pop (TV_VARCONST);
}
- else if (TREE_CODE (decl) == TYPE_DECL)
+ else if (TREE_CODE (decl) == TYPE_DECL
+ /* Like in rest_of_type_compilation, avoid confusing the debug
+ information machinery when there are errors. */
+ !(sorrycount || errorcount))
{
timevar_push (TV_SYMOUT);
debug_hooks-type_decl (decl, !top_level);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20161
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
--- Additional Comments From richard dot guenther at gmail dot com 2005-07-26 10:38 --- Subject: Re: [4.1 Regression] wrong code for casts and scev You should also add the (two) testcases from the PR. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22236
[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 10:39 --- I can reproduce this with the C test case from comment #24 on x86_64-linux with -march=nocona. With -march=k8 that test case does _not_ abort. -- What|Removed |Added GCC target triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 10:43 --- Well I'll be damned! $ ./xgcc -B. t.c -O2 -march=nocona $ ./a.out Aborted $ ./xgcc -B. t.c -O2 -march=nocona -da -fdump-tree-all $ ./a.out $ $ ./xgcc -B. t.c -O2 -march=nocona -S -da $ mv t.s t.s.with_dumps $ ./xgcc -B. t.c -O2 -march=nocona -S $ diff -u t.s t.s.with_dumps --- t.s 2005-07-26 12:42:14.447531418 +0200 +++ t.s.with_dumps 2005-07-26 12:42:03.501170603 +0200 @@ -26,19 +26,20 @@ .type ListSwap, @function ListSwap: .LFB4: - movq(%rdi), %rcx - testq %rcx, %rcx + cmpq$0, (%rdi) je .L8 + movq(%rdi), %rdx movq(%rsi), %rax movq%rax, (%rdi) - movq%rcx, (%rsi) + movq%rdx, (%rsi) movq8(%rdi), %rdx movq8(%rsi), %rax movq%rax, 8(%rdi) movq%rdx, 8(%rsi) + movq(%rdi), %rdx movq8(%rdi), %rax movq%rdi, (%rax) - movq%rdi, 8(%rcx) + movq%rdi, 8(%rdx) movq(%rsi), %rdx movq8(%rsi), %rax movq%rsi, (%rax) wtf?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26
11:18 ---
My version of t.c:
===
void abort ();
typedef struct _Node
{
struct _Node *next, *prev;
} Node;
void __attribute__ ((noinline)) append (Node * q, Node * p)
{
p-next = q;
p-prev = q;
q-next = p;
q-prev = p;
}
inline void
swap (Node ** a, Node ** b)
{
Node *tmp = *a;
*a = *b;
*b = tmp;
}
/* Miscompilation seems to happen here. If one removes the if condition
(which should be true) the program works fine. */
void
ListSwap (Node * x, Node * y)
{
Node *tmp;
if (x-next)
{
swap (x-next, y-next);
swap (x-prev, y-prev);
x-next-prev = x-prev-next = x;
y-next-prev = y-prev-next = y;
}
}
int
main ()
{
Node A, A1, B, B1;
append (A, A1);
append (B, B1);
ListSwap (A, B);
if (A != A.next-prev)
abort ();
}
===
compiled with:
$ ./xgcc -B. t.c -O2 -m32 -march=pentium4 -da -fdump-tree-vars
gives me this for ListSwap:
===
ListSwap (x, y)
{
struct Node * * a;
struct Node * * b;
struct Node * tmp;
struct Node * * a;
struct Node * * b;
struct Node * tmp;
struct _Node * D.1621;
struct _Node * D.1614;
bb 0:
D.1614 = x-next;
if (D.1614 != 0B) goto L0; else goto L1;
L0:;
a = x-next;
b = y-next;
tmp = *a;
*a = *b;
*b = tmp;
a = x-prev;
b = y-prev;
tmp = *a;
*a = *b;
*b = tmp;
x-prev-next = x;
D.1614-prev = x;
D.1621 = y-next;
y-prev-next = y;
D.1621-prev = y;
L1:;
return;
}
===
Look at D.1614. It is loaded befoe the conditional, and later there is
a store to D.1614-prev. But isn't x-next already something else by
then? After all, x-next and y-next are swapped. I checked with Serge
Belyshev and he agrees this looks fishy:
/QUOTE/
a = x-next;
b = y-next;
...
*a = *b;
this changes x-next
D.1614-prev = x;
but this still uses old value of x-next
/QUOTE/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26
11:43 ---
Smaller test case:
==
void abort ();
typedef struct _Node
{
struct _Node *next, *prev;
} Node;
inline void
swap (Node ** a, Node ** b)
{
Node *tmp = *a;
*a = *b;
*b = tmp;
}
/* Miscompilation seems to happen here. If one removes the if condition
(which should be true) the program works fine. */
void
ListSwap (Node * x, Node * y)
{
Node *tmp;
if (x-next)
{
swap (x-next, y-next);
x-next-prev = x-prev-next = x;
}
}
==
Gives this .vars dump:
==
ListSwap (x, y)
{
struct Node * * a;
struct Node * * b;
struct Node * tmp;
struct _Node * D.1610;
bb 0:
D.1610 = x-next;
if (D.1610 != 0B) goto L0; else goto L1;
L0:;
a = x-next;
b = y-next;
tmp = *a;
*a = *b;
*b = tmp;
x-prev-next = x;
D.1610-prev = x;
L1:;
return;
}
==
In the .t22.ccp dump the function still looks OK:
D.1610_10 = x_1-next;
D.1613_11 = x_1-prev;
D.1613_11-next = x_1;
D.1614_12 = D.1613_11-next;
D.1610_10-prev = D.1614_12;
Then .t23.fre causes the problem because the wrong alias info is wrong:
D.1610_10 = D.1610_2;
D.1613_11 = x_1-prev;
D.1613_11-next = x_1;
D.1614_12 = D.1613_11-next;
D.1610_10-prev = D.1614_12;
Note btw how FRE does not replace D.1614_12 with x_1, which is a missed
optimization.
The alias info is already wrong when it is computed, so at least it is not
some kind of weird updating problem:
ListSwap (xD.1605, yD.1606)
{
struct NodeD.1598 * * aD.1660;
struct NodeD.1598 * * bD.1661;
struct NodeD.1598 * tmpD.1662;
struct NodeD.1598 * D.1663;
struct NodeD.1598 * tmpD.1609;
struct _Node * D.1614;
struct _Node * D.1613;
struct _Node * * D.1612;
struct _Node * * D.1611;
struct _Node * D.1610;
# BLOCK 0
# PRED: ENTRY (fallthru)
# VUSE TMT.31D.1669_13;
D.1610_2 = xD.1605_1-nextD.1596;
if (D.1610_2 != 0B) goto L0; else goto L1;
# SUCC: 1 (true) 2 (false)
# BLOCK 1
# PRED: 0 (true)
L0:;
D.1611_4 = yD.1606_3-nextD.1596;
D.1612_5 = xD.1605_1-nextD.1596;
aD.1660_6 = (struct NodeD.1598 * *) D.1612_5;
bD.1661_7 = (struct NodeD.1598 * *) D.1611_4;
# VUSE TMT.32D.1670_14;
tmpD.1662_8 = *aD.1660_6;
# VUSE TMT.32D.1670_14;
D.1663_9 = *bD.1661_7;
# TMT.32D.1670_15 = V_MAY_DEF TMT.32D.1670_14;
*aD.1660_6 = D.1663_9;
# TMT.32D.1670_16 = V_MAY_DEF TMT.32D.1670_15;
*bD.1661_7 = tmpD.1662_8;
# VUSE TMT.31D.1669_13;
D.1610_10 = xD.1605_1-nextD.1596;
# VUSE TMT.31D.1669_13;
D.1613_11 = xD.1605_1-prevD.1597;
# TMT.31D.1669_17 = V_MAY_DEF TMT.31D.1669_13;
D.1613_11-nextD.1596 = xD.1605_1;
# VUSE TMT.31D.1669_17;
D.1614_12 = D.1613_11-nextD.1596;
# TMT.31D.1669_18 = V_MAY_DEF TMT.31D.1669_17;
D.1610_10-prevD.1597 = D.1614_12;
# SUCC: 2 (fallthru)
# BLOCK 2
# PRED: 0 (false) 1 (fallthru)
L1:;
return;
# SUCC: EXIT
}
Notice that the stores to *a and *b are not killing TMT.31D.1669_13. That
is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
-- What|Removed |Added Priority|P2 |P1 Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression] wrong |std::swap() followed by |alias information causes an |list::erase() produces |incorrect redundant load |incorrect list::begin() |elimination http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug target/18170] [4.0/4.1 Regression] m32r-elf-as, m32r-linux-as debug relocation error for c++
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 12:01 --- What should we do with this bug? If m32r is no longer affected, then what is? Maybe suspend this one or close it as WONTFIX? -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18170
[Bug middle-end/21953] [4.1 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 12:03 --- Rainer, can you look into those failures a bit more closely? Maybe you can see in the testsuite log how they fail? -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
[Bug fortran/23074] New: g77-style typeless BOZ constants not implemented
In g77 you define a typeless BOZ constant that can be assigned to any other type, using the formats ''X, ''Z etc. This allows PARAMETERs to be defined like: PROGRAM TLBOZ DOUBLE PRECISION inf, nan PARAMETER ( inf = '7FF0'Z ) PARAMETER ( nan = 'FFF8'X ) print *, inf, nan END The relevant g77 description is at: http://gcc.gnu.org/onlinedocs/gcc-3.4.1/g77/Constants.html This is related to bug 18026. -- Summary: g77-style typeless BOZ constants not implemented Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: p dot w dot draper at durham dot ac dot uk CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23074
[Bug c/23075] New: Redundant / bogus warning
Compiling
int foo (void)
{
return;
}
with -ansi -pedantic gives two warnings; with GCC 3.3 it only gave one. As a
QOI issue 3.3's behaviour is superior - warning about control reaching the end
of the function is a bit odd.
--
Summary: Redundant / bogus warning
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23075
[Bug c/23075] Redundant / bogus warning
--- Additional Comments From neil at gcc dot gnu dot org 2005-07-26 12:13 --- I meant to add -Wall to the warning list. -- What|Removed |Added Summary|Redundant / bogus warning |Redundant / bogus warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23075
[Bug target/23070] CALL_V4_CLEAR_FP_ARGS flag not properly set
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23070
[Bug tree-optimization/23059] [4.1 Regression] ICE: verify_ssa failed with -O3 -ftree-vectorize -Woverloaded-virtual
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 12:54 --- Created an attachment (id=9363) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9363action=view) Smaller testcase -- What|Removed |Added Attachment #9359 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23059
[Bug tree-optimization/23059] [4.1 Regression] ICE: verify_ssa failed with -O3 -ftree-vectorize -Woverloaded-virtual
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 12:58 --- Confirmed, I cannot reduce the testcase any further. Removing any little unneeded code makes the bug go away. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-26 12:58:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23059
[Bug c/23076] New: GNU C extension / attribute destructor + static : invalid storage class for function
The follwing program:
#include stdio.h
#define LOG
FILE *log_file;
int f2 (int x)
{
#ifdef LOG
static long toto = 0;
static const char *fname = __func__;
static void __attribute__ ((destructor)) f (void) {
fprintf (log_file, %s: toto=%ld\n, fname, toto);
}
toto += x;
#endif
return 42;
}
int main ()
{
log_file = fopen (toto.log, w);
f2 (3);
return 0;
}
failed to compile with GCC 4.0.0 and GCC 4.0.1:
morpork tmp 69 % /localdisk/gcc-4.0.1/bin/gcc tgcc.c
tgcc.c: In function 'f2':
tgcc.c:12: error: invalid storage class for function 'f'
morpork tmp 68 % /localdisk/gcc-4.0.1/bin/gcc --version
gcc (GCC) 4.0.1
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
whereas it works perfectly with GCC 3.2.x, 3.3.x and GCC 3.4.x.
--
Summary: GNU C extension / attribute destructor + static :
invalid storage class for function
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppelissi at caramail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23076
[Bug fortran/23074] g77-style typeless BOZ constants not implemented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:03 --- This isn't just related, this is a dup of PR 18026. *** This bug has been marked as a duplicate of 18026 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23074
[Bug fortran/18026] boz initialization of REALs fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:03 --- *** Bug 23074 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||p dot w dot draper at durham ||dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
==operator gives unexpected result using -O0
Hello,
I do apologize if my ignorance is the problem here, but I am having a strange
problem with the version of gcc included in suse 9.3: gcc version 3.3.5
20050117 (prerelease) (SUSE Linux). The same problem was observed with gcc
3.3.1. I have not tried later versions, but I can't find the problem in
bugzilla so I assume it is either so trivial that I should be ashamed or
unknown. It is an intel XEON processor.
It seems to me that if a,b, and c are float or double values and if a has been
assigned b*c
then
a == (b*c)
should return true since a should contain the same bitpattern as the temporary
being assigned the value of b*c. Is it not so?
Never the less, the following piece of code does not work as expected when
compiling with -O0. It works FINE when compiling with -O1 or higher.
---
#include iostream
using namespace std;
int main()
{
double b = 9.5245435435564536;
double c = 7.98786542345446565;
double a = b*c;
//Does not work.
cout (a == (b*c)) endl;
// Works
double d = b*c;
cout (a == d) endl;
}
---
With O0 the output is
0
1
With O1, O2 or O3 the output is
1
1
as one would expect.
I have made a similar program in C and I also changed double to float. It
makes no difference. Nor does the actual float/double values. The
optimization flag seems to decide what happens.
Any insight would be appreciated.
Andreas
[Bug c/23076] GNU C extension / attribute destructor + static : invalid storage class for function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:05 --- Just remove the static and it will work. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|GNU C extension / attribute |GNU C extension / attribute |destructor + static : |destructor + static : |invalid storage class for |invalid storage class for |function|function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23076
[Bug c/23076] GNU C extension / attribute destructor + static : invalid storage class for function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:06 --- I should note static functions inside a function is invalid code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23076
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-26
13:10 ---
I have (with whatever load of patches applied...)
;; Function ListSwap (ListSwap)
ListSwap (x, y)
{
struct Node * tmp;
struct _Node * D.1292;
bb 0:
tmp = x-next;
if (tmp != 0B) goto L0; else goto L1;
L0:;
x-next = y-next;
y-next = tmp;
D.1292 = x-next;
x-prev-next = x;
D.1292-prev = x;
L1:;
return;
}
--
What|Removed |Added
Priority|P1 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug c/23075] [4.0/4.1 Regression] Redundant / bogus warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:11 --- Confirmed, one warning comes from the front-end and the other bogus warning comes from the middle-end. I have not looked to see if we set TREE_NO_WARNING on the return and if the middle-end looks at that flag but I think that might be a way around the issue. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-07-26 13:11:36 date|| Summary|Redundant / bogus warning |[4.0/4.1 Regression] ||Redundant / bogus warning Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23075
[Bug tree-optimization/23073] [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
[Bug tree-optimization/22598] [4.1 Regression] 23_containers/set/explicit_instantiation/3.cc fails
-- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22598
[Bug tree-optimization/21445] [meta-bug] we need a reassociate pass
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-26 13:14 --- We have one now :) -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445
[Bug tree-optimization/19104] in range test not noticed
-- Bug 19104 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19104
[Bug tree-optimization/15878] a b ~a ~b not optimized at the tree level
-- Bug 15878 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15878
[Bug tree-optimization/19105] fold does not spot anti-range test
-- Bug 19105 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19105
[Bug tree-optimization/16157] gcc fails to optimize redundant expression (reassocation)
-- Bug 16157 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16157
[Bug tree-optimization/17955] Perform associative optimization when it is safe
-- Bug 17955 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17955
[Bug target/23067] Incorrect struct layout on darwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:14 --- Confirmed based on what Apple's GCC does and what Geoff said. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-26 13:14:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug debug/20253] [3.4 regression]: Macro debug info broken due to lexer change
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-26 13:16 --- This has moved very much off my radar since it was fixed in 4.1.0 and 4.0.0 -- What|Removed |Added AssignedTo|dberlin at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to fail|3.4.0 4.0.0 |3.4.0 Known to work|3.3.3 3.2.3 4.1.0 |3.3.3 3.2.3 4.1.0 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20253
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
--- Additional Comments From pcarlini at suse dot de 2005-07-26 13:17 --- Yes, but why P1 - P2?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/19581] Missed store motion on the tree level
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-26 13:18 --- Richard guenther is working on aliasing for arrays, i'll leave this one for him -- What|Removed |Added CC||rguenth at gcc dot gnu dot ||org AssignedTo|dberlin at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19581
[Bug tree-optimization/22488] [4.1 Regression] ICE: in first_vi_for_offset, at tree-ssa-structalias.c:2585 with -O3
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-26 13:21 --- http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01608.html does not help -- What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:21 --- I still don't believe this is a bug. As the alignment of whole struct is still 8 as double is first, even if the alignment of that double is 4. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC host triplet|powerpc-darwin-*| GCC target triplet||powerpc-darwin, powerpc-aix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug fortran/23074] g77-style typeless BOZ constants not implemented
--- Additional Comments From p dot w dot draper at durham dot ac dot uk 2005-07-26 13:28 --- Andrew, I've said this is related to bug 18026, rather than a duplicate, as the actual format used for these typeless BOZ constants is none standard and not the same as in bug 18026. As in gfortran, g77 typed constants have the format X'', whereas these are ''X, the difference may not be apparent at first glance. If you missed this point please reopen or merge this report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23074
[Bug tree-optimization/19581] Missed store motion on the tree level
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-26
13:29 ---
For a reduced array with only 4 elements (I know - this should be a --param) we
now get in .vars (with the array aliasing patch):
f (n)
{
int n.39;
unsigned int ivtmp.33;
int lsm_tmp.32;
int lsm_tmp.31;
int lsm_tmp.30;
int lsm_tmp.29;
bb 0:
n.39 = n - 1;
if (n.39 != 0) goto L6; else goto L2;
L6:;
lsm_tmp.29 = r[2];
lsm_tmp.30 = r[1];
lsm_tmp.31 = r[3];
lsm_tmp.32 = r[0];
ivtmp.33 = 0;
L0:;
lsm_tmp.32 = lsm_tmp.32 + lsm_tmp.31;
lsm_tmp.30 = lsm_tmp.32 + lsm_tmp.30;
lsm_tmp.29 = lsm_tmp.30 + lsm_tmp.29;
lsm_tmp.31 = lsm_tmp.31 + lsm_tmp.29;
ivtmp.33 = ivtmp.33 + 1;
if (ivtmp.33 != (unsigned int) n.39) goto L0; else goto L10;
L10:;
r[2] = lsm_tmp.29;
r[1] = lsm_tmp.30;
r[3] = lsm_tmp.31;
r[0] = lsm_tmp.32;
L2:;
return;
}
and the asm loop looks like
.L4:
addl%edx, %eax
incl%esi
addl%eax, %ecx
addl%ecx, %ebx
addl%ebx, %edx
cmpl%edi, %esi
jne .L4
as in exactly what you want. Don't hold your breath for 4.1, though.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2005-06-09 16:37:28 |2005-07-26 13:29:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19581
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
--- Additional Comments From dorit at il dot ibm dot com 2005-07-26 13:59
---
Subject: Re: [4.1 Regression] wrong code for casts and
scev
Hi Sebastian,
The modifications you suggest will make the tests uninteresting - they were
introduced with unknown loop-bound/offset on purpose. In fact, for most of
these tests there are already versions with explicit constant values for
the loop-bound/offset -
vect-46.c with explicit loop-bound becomes vect-40.c
vect-50.c with explicit loop-bound becomes vect-44.c
vect-52.c with explicit loop-bound becomes vect-48.c
vect-58.c with explicit loop-bound becomes vect-54.c
vect-60.c with explicit loop-bound becomes vect-56.c
vect-77.c and vect-78.c with explicit offset become vect-75.c
and vect-92.c also uses unknown loop-bound on purpose.
Can we change something else in the tests to make the evolution-analyzer
return something saner? by changing types of variables? by using some flag?
(by the way, where does it fail the vectorizer? (what are the last things
that dump details reports?))
dorit
FAIL: gcc.dg/vect/vect-46.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Vectorizing an
unaligned access 2
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Alignment of access
forced using peeling 1
FAIL: gcc.dg/vect/vect-52.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-52.c scan-tree-dump-times Vectorizing an
unaligned access 2
FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times Alignment of access
forced using peeling 1
FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times Vectorizing an
unaligned access 2
FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times vectorized 1 loops 3
FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times Alignment of access
forced using peeling 3
In all these cases, the loop bound is a parameter. If IP-constant
propagation is not used, chrec_convert has not enough information for
removing the cast. I propose to modify all these testcases to make
the loop bound explicit.
FAIL: gcc.dg/vect/vect-77.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-77.c scan-tree-dump-times Vectorizing an
unaligned access 1
FAIL: gcc.dg/vect/vect-78.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-78.c scan-tree-dump-times Vectorizing an
unaligned access 1
For these two regressions, the problem is the same: we end with an
evolution: ib_16 + (aint *) ((long unsigned int) {off_11, +, 1}_1 * 4)
in which the casts cannot be removed because the offset is not known,
and even if the number of iterations is known, chrec_convert cannot
prove that it does not overflow. I propose to propagate the offset
by hand, or to wait for ipcp ;-)
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times Alignment of access
forced using peeling 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times Alignment of access
forced using peeling 1
For these two testcases we'll need IP-value range propagation. I
think that we'll have to modify these testcases by inlining the code.
Dorit, could you look at vect-{77,78,87,88}.c testcases? Thanks.
* tree-cfg.c (print_succ_bbs): Correctly print successors.
* tree-chrec.c (chrec_convert): Call scev_probably_wraps_p for
checking
that the iv does not wrap before converting the iv.
* tree-ssa-loop-ivcanon.c: Correct typo in comment.
* tree-ssa-loop-ivopts.c (idx_find_step): Add a fixme note.
* tree-ssa-loop-niter.c (scev_probably_wraps_p): Check that AT_STMT is
not null.
(convert_step): Add a comment.
Index: tree-cfg.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.211
diff -d -u -p -r2.211 tree-cfg.c
--- tree-cfg.c 12 Jul 2005 13:20:28 - 2.211
+++ tree-cfg.c 26 Jul 2005 09:59:38 -
@@ -4454,7 +4454,7 @@ static void print_pred_bbs (FILE *, basi
static void print_succ_bbs (FILE *, basic_block bb);
-/* Print the predecessors indexes of edge E on FILE. */
+/* Print on FILE the indexes for the predecessors of basic_block BB. */
static void
print_pred_bbs (FILE *file, basic_block bb)
@@ -4463,11 +4463,11 @@ print_pred_bbs (FILE *file, basic_block
edge_iterator ei;
FOR_EACH_EDGE (e, ei, bb-preds)
-fprintf (file, bb_%d, e-src-index);
+fprintf (file, bb_%d , e-src-index);
}
-/* Print the successors indexes of edge E on FILE. */
+/* Print on FILE the indexes for the successors of basic_block BB. */
static void
print_succ_bbs (FILE *file, basic_block bb)
@@ -4476,7 +4476,7 @@ print_succ_bbs (FILE *file,
[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-26 14:08 --- The ABI specifies the alignment of the entire record is doubleword if the first field is an FP double, regardless of the alignment of the type itself. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-22 08:23:53 |2005-07-26 14:26:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug libobjc/22606] Exceptions cannot be thrown from -forward::
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-26 14:27 --- Subject: Bug 22606 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-26 14:27:33 Modified files: gcc/testsuite : ChangeLog libobjc: ChangeLog Makefile.in Added files: gcc/testsuite/objc.dg: try-catch-11.m Log message: 2005-07-26 Andrew Pinski [EMAIL PROTECTED] PR libobjc/22606 * Makefile.in (ALL_CFLAGS): Add -fexceptions. 2005-07-26 Andrew Pinski [EMAIL PROTECTED] PR libobjc/22606 * objc.dg/try-catch-11.m: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5823r2=1.5824 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/objc.dg/try-catch-11.m.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/ChangeLog.diff?cvsroot=gccr1=1.168r2=1.169 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/Makefile.in.diff?cvsroot=gccr1=1.48r2=1.49 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22606
[Bug libobjc/22606] Exceptions cannot be thrown from -forward::
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 14:28 --- Fixed, added your testcase also. Also I noticed that your testcase fails with the next runtime, oh well. Not my bug. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22606
[Bug middle-end/21992] [4.1 regression] testsuite failure: many objc execution tests fail, first objc/execute/_cmd.m execution
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 14:32 --- I think I see the same thing at -O2 on a couple of tests on ppc-darwin. Is the execution a missing symbol? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21992
[Bug c/23077] New: Invalid code with O2 flag (bad alias analysis?)
Source code:
#include stdio.h
int main (int argc, char * argv[])
{
unsigned int t[2] = {1, 1};
*((double *)t) = 0.0;
printf(%d\n, t[1]);
}
This code prints 1 insted of 0 when with: gcc foo.c -o foo -O2
Output of gcc -v foo.c -o foo2 -O2:
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: /var/tmp/portage/gcc-3.4.4/work/gcc-3.4.4/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libgcj --enable-languages=c,c++,f77 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1 -quiet -v foo.c -quiet -dumpbase
foo.c -mtune=pentiumpro -auxbase foo -O2 -version -o /tmp/ccFePbg2.s
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include
/usr/include
End of search list.
GNU C version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8) (i686-pc-linux-gnu)
compiled by GNU C version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0,
pie-8.7.8).
GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113127
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o /tmp/ccokr9zW.o /tmp/ccFePbg2.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o foo2
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4 -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4
-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../.. /tmp/ccokr9zW.o -lgcc -lgcc_eh
-lc -lgcc -lgcc_eh /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../crtn.o
I suspect that the alias analysis use an incorrect size for double.
--
Summary: Invalid code with O2 flag (bad alias analysis?)
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicos at maunakeatech dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23077
[Bug c/23077] Invalid code with O2 flag (bad alias analysis?)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 14:36 --- No this is not bad alias analysis, You are invoking undefined code by violating aliasing rules in C/C++. This is a dup of bug 21920. *** This bug has been marked as a duplicate of 21920 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23077
[Bug c/21920] alias violating
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 14:37 --- *** Bug 23077 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||nicos at maunakeatech dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-07-26 14:46 --- (In reply to comment #31) Smaller test case: This works for me. The original test case does abort, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-07-26 15:15 ---
Subject: Re: [4.1 Regression] wrong code for casts and scev
Dorit Naishlos wrote:
The modifications you suggest will make the tests uninteresting - they were
introduced with unknown loop-bound/offset on purpose. In fact, for most of
these tests there are already versions with explicit constant values for
the loop-bound/offset -
Okay, I won't modify any of these testcases.
vect-46.c with explicit loop-bound becomes vect-40.c
vect-50.c with explicit loop-bound becomes vect-44.c
vect-52.c with explicit loop-bound becomes vect-48.c
vect-58.c with explicit loop-bound becomes vect-54.c
vect-60.c with explicit loop-bound becomes vect-56.c
vect-77.c and vect-78.c with explicit offset become vect-75.c
and vect-92.c also uses unknown loop-bound on purpose.
Can we change something else in the tests to make the evolution-analyzer
return something saner? by changing types of variables? by using some flag?
I don't think it is possible to properly convert these ivs without
knowing an approximation of the number of iterations.
We can get this either from -fipcp, but this would make the testcases
redundant as you said, or having the IP alias analysis that tells us
that the only pointers passed to main1 () in vect-46 point to data
whose size is 256, and from this extract an estimation of the number
of iterations, or last solution explained below.
(by the way, where does it fail the vectorizer? (what are the last things
that dump details reports?))
compiling vect-46.c produces the following:
(...
(set_scalar_evolution
(scalar = D.2054_15)
(scalar_evolution = (afloat * restrict) {0, +, 4}_1 + pb_14))
)
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: Access
function of ptr: (afloat * restrict) {0, +, 4}_1 + pb_14
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: not
vectorized: ptr is loop invariant.
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: not
vectorized: unhandled data ref: D.2055_16 = *D.2054_15
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: bad data
references.
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: vectorized
0 loops in function.
Now that we keep the cast, (afloat * restrict) {(uint) 0, +, (uint)
4}_1 + pb_14 cannot be folded into {(afloat * restrict)pb_14, +,
(afloat * restrict)4}_1, that's why the vectorizer cannot recognize
the pattern.
The main problem is that the code in the loop contains a cast of the
signed iv i_18 to unsigned:
bb_2 (preds = {bb_3 bb_1 }, succs = {bb_3 bb_5 })
{
# TMT.5_17 = PHI TMT.5_27(3), TMT.5_26(1);
# i_18 = PHI i_24(3), 0(1);
L0:;
D.2050_6 = (long unsigned int) i_18;
D.2051_7 = D.2050_6 * 4;
D.2052_8 = (afloat * restrict) D.2051_7;
D.2053_10 = D.2052_8 + pa_9;
D.2054_15 = D.2052_8 + pb_14;
# VUSE TMT.5_17;
D.2055_16 = *D.2054_15;
D.2056_21 = D.2052_8 + pc_20;
# VUSE TMT.5_17;
D.2057_22 = *D.2056_21;
D.2058_23 = D.2055_16 * D.2057_22;
# TMT.5_27 = V_MAY_DEF TMT.5_17;
*D.2053_10 = D.2058_23;
i_24 = i_18 + 1;
if (n_3 i_24) goto L9; else goto L11;
}
The solution is to have an estimation of the loop bound based on the
fact that i_24 and i_18 do not wrap. From this estimation, I think
that the other vars D.2050_6, D.2051_7 and D.2052_8 can be proved to
not wrap. I'm working on some code for estimating niter from signed
non wrapping ivs.
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22236
[Bug tree-optimization/23073] [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-26
15:21 ---
Confirmed.
The following testcase crashes on i686-pc-linux-gnu when compiled with
-O -ftree-vectorize -msse2:
==
void foo(int* __restrict__ p, int* __restrict__ q)
{
int i;
for (i=0; i2; ++i)
p[i] = q[i] = 0;
}
==
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2005-07-26 15:21:56
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
[Bug tree-optimization/23073] [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 15:26 --- Here is the backtrace: #0 0x00424b88 in fwrite () from /lib/tls/libc.so.6 #1 0x081381fd in vect_analyze_data_refs_alignment (loop_vinfo=0xa3bebb0) at /home/peshtigo/ pinskia/src/gnu/gcc/src/gcc/tree-vect-analyze.c:1063 #2 0x0813b078 in vect_analyze_loop (loop=0xa385bb0) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/tree-vect-analyze.c:1863 #3 0x08134088 in vectorize_loops (loops=0xa39d850) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/tree-vectorizer.c:2024 #4 0x0812be24 in tree_vectorize () at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/tree-ssa-loop.c: 194 Someone is writting to vect_dump without checking to see if it is opened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
[Bug c++/23078] New: m68k ICE
g++ -O3 -Iboxes -Ierrors -Ievaluate -Igenerator -Iparser -Ipropagate -Isignals -Itlib -Idraw-c -o boxes/boxtype.o boxes/boxtype.cpp boxes/boxtype.cpp: In function 'void getBoxType(CTree*, int*, int*)': boxes/boxtype.cpp:74: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.0/README.Bugs. make[2]: *** [boxes/boxtype.o] Error 1 -- Summary: m68k ICE Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wouter at grep dot be CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: m68k-linux-gnu GCC target triplet: m68k-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23078
[Bug c++/23078] m68k ICE
--- Additional Comments From wouter at grep dot be 2005-07-26 15:29 --- Created an attachment (id=9364) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9364action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23078
[Bug middle-end/21992] [4.1 regression] testsuite failure: many objc execution tests fail, first objc/execute/_cmd.m execution
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 15:31 --- This fails on PPC-darwin also. -- What|Removed |Added GCC target triplet|mmix-knuth-mmixware |mmix-knuth-mmixware, ||powerpc-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21992
[Bug middle-end/21992] [4.1 regression] testsuite failure: many objc execution tests fail, first objc/execute/_cmd.m execution
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 15:34 --- I wonder why this does not fail on i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21992
[Bug target/23078] m68k ICE
-- What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23078
[Bug middle-end/21992] [4.1 regression] testsuite failure: many objc execution tests fail, first objc/execute/_cmd.m execution
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 15:39 --- === objc Summary === # of expected passes1309 # of unexpected failures328 # of unresolved testcases 3 # of unsupported tests 1 Those are what I get on ppc-darwin, bad, very bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21992
[Bug middle-end/21992] [4.1 regression] testsuite failure: many objc execution tests fail, first objc/execute/_cmd.m execution
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 15:52 --- I think libobjc is also being miscompiled which is why some fails at -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21992
[Bug tree-optimization/23079] New: ICE in tree_low_cst, at tree.c:4268 with -ftree-vectorize
When I compile the small program with the actual snapshot of
gcc41 (20050723) I get an ICE.
Michael Cieslinski
unsigned int foo ()
{
unsigned int y[256];
unsigned int* x;
for (x = y + 1; x y + 256; ++x) *x += x[-1];
return y[0];
}
gcc41h -O -ftree-vectorize -c sort.i -o sort.o
sort.i: In function 'foo':
sort.i:3: internal compiler error: in tree_low_cst, at tree.c:4268
Please submit a full bug report, with preprocessed source if appropriate.
gcc41h -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050723/configure --prefix=/usr/local/gcc41h --
program-suffix=41h --with-arch=opteron --enable-languages=c,c++ --enable-
checking
Thread model: posix
gcc version 4.1.0 20050723 (experimental)
--
Summary: ICE in tree_low_cst, at tree.c:4268 with -ftree-
vectorize
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23079
[Bug tree-optimization/23079] ICE in tree_low_cst, at tree.c:4268 with -ftree-vectorize
--- Additional Comments From micis at gmx dot de 2005-07-26 16:14 --- last working snapshot is gcc-4.1-20050508 first failing snapshot is gcc-4.1-20050528 (between these 2 I didn't compile other snapshots) gcc401 is working correctly -- What|Removed |Added Summary|ICE in tree_low_cst, at |ICE in tree_low_cst, at |tree.c:4268 with -ftree-|tree.c:4268 with -ftree- |vectorize |vectorize http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23079
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-07-26
16:19 ---
Testing patch. The shortcut we were taking in may_alias_p is invalid even with
strict aliasing.
--- tree-ssa-alias.c25 Jul 2005 12:04:50 - 2.107
+++ tree-ssa-alias.c26 Jul 2005 16:16:34 -
@@ -1511,23 +1511,6 @@ may_alias_p (tree ptr, HOST_WIDE_INT mem
alias_stats.tbaa_queries++;
- /* If VAR is a pointer with the same alias set as PTR, then dereferencing
- PTR can't possibly affect VAR. Note, that we are specifically testing
- for PTR's alias set here, not its pointed-to type. We also can't
- do this check with relaxed aliasing enabled. */
- if (POINTER_TYPE_P (TREE_TYPE (var))
- var_alias_set != 0
- mem_alias_set != 0)
-{
- HOST_WIDE_INT ptr_alias_set = get_alias_set (ptr);
- if (ptr_alias_set == var_alias_set)
- {
- alias_stats.alias_noalias++;
- alias_stats.tbaa_resolved++;
- return false;
- }
-}
-
/* If the alias sets don't conflict then MEM cannot alias VAR. */
if (!alias_sets_conflict_p (mem_alias_set, var_alias_set))
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/23079] [4.1 Regression] ICE in tree_low_cst, at tree.c:4268 with -ftree-vectorize
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 16:19 --- Confirmed, also fails with 20050714. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu|x86_64-linux-gnu Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-07-26 16:19:49 date|| Summary|ICE in tree_low_cst, at |[4.1 Regression] ICE in |tree.c:4268 with -ftree-|tree_low_cst, at tree.c:4268 |vectorize |with -ftree-vectorize Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23079
[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct
--- Additional Comments From sabre at nondot dot org 2005-07-26 16:25
---
Okay, in that case, how does one change the alignment of the structure? The
only way I'm aware of to
do this is with attribute packed, but that will also modify the inter-field
padding of the structure. For
example, in this case:
struct Test {
double D __attribute__((packed,aligned(4)));
short X;
int Y;
short Z;
} __attribute__((packed,aligned(4)));
Not only is the alignment of the structure reduced to 4 bytes, the structure is
also packed, resulting in
the 'int' being unaligned and the size of the structure being 16 bytes (instead
of 20).
it sure would be nice if you could use 'attribute aligned' to reduce alignment
without attribute packed
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug c/23080] New: m68k ICE
cc -c -O4 -DSYSINC -I/usr/include/lam -Df77IsF2C -DBlacsDebugLvl=0 -DUseMpi2 BI_BeComb.c BI_BeComb.c: In function 'BI_BeComb': BI_BeComb.c:102: internal compiler error: Segmentatie fout Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.0/README.Bugs. make[3]: *** [BI_BeComb.o] Fout 1 -- Summary: m68k ICE Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wouter at grep dot be CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: m68k-linux-gnu GCC target triplet: m68k-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23080
[Bug target/23080] m68k ICE
-- What|Removed |Added Component|c |target Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23080
[Bug target/23080] m68k ICE
--- Additional Comments From wouter at grep dot be 2005-07-26 16:29 --- Created an attachment (id=9365) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9365action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23080
[Bug libstdc++/23081] New: Finish the implementation of tr1::array
It would be nice to complete the implementation in time for 4.1: a few members are more or less trivial, like front(), back() and data()... -- Summary: Finish the implementation of tr1::array Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23081
[Bug c++/18462] [3.4 Regression] Segfault on declaration of large array member
--- Additional Comments From giovannibajo at libero dot it 2005-07-26 16:39 --- The testcase in PR18602 does not cause a segfault anymore for GCC 3.4 CVS. Is this bug fixed then? Or do we need a new testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18462
[Bug tree-optimization/23082] New: internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
When the attached is compiled as follows, it generates an ICE: pluto gcc -c -O1 -ftree-vectorize a.c a.c: In function a: a.c:4: internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. pluto gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gcc410 --enable-languages=c,c++,f95 Thread model: posix gcc version 4.1.0 20050725 (experimental) The attached code compiles OK with gcc 4.0.1 -- Summary: internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: p dot van-hoof at qub dot ac dot uk CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23082
[Bug tree-optimization/23082] internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Additional Comments From p dot van-hoof at qub dot ac dot uk 2005-07-26 16:46 --- Created an attachment (id=9366) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9366action=view) code that causes the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23082
[Bug tree-optimization/23082] [4.1 Regression] internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
-- What|Removed |Added Keywords||ice-on-valid-code Summary|internal compiler error:|[4.1 Regression] internal |tree check: expected|compiler error: tree check: |ssa_name, have var_decl in |expected ssa_name, have |verify_ssa, at tree-|var_decl in verify_ssa, at |ssa.c:746 |tree-ssa.c:746 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23082
[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct
--- Additional Comments From ian at airs dot com 2005-07-26 16:55 --- The whole point of attribute ((packed)) is to change the ABI. If it can't change the ABI, it is meaningless. So I don't find the argument based on the ABI to be particularly convincing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct
--- Additional Comments From dje at watson dot ibm dot com 2005-07-26 16:58 --- Subject: Re: Darwin alignment ignores attribute packed for first 'double' element of a struct If Chris and Apple want to change the behavior for Darwin, be my guest. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-26 17:02 --- reopen -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct
-- What|Removed |Added AssignedTo|dje at watson dot ibm dot |unassigned at gcc dot gnu |com |dot org Status|UNCONFIRMED |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug tree-optimization/23082] [4.1 Regression] internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 17:03 --- Confirmed, this worked on the 18th. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-26 17:03:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23082
[Bug tree-optimization/22504] [4.1 Regression] benchmark - galgel fails at runtime with miscompare output
--- Additional Comments From uttamp at us dot ibm dot com 2005-07-26 17:27 --- Steven's patch has fixed the galgel failure. I've verified it on Powerpc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22504
[Bug target/23067] Incorrect struct layout on darwin
--- Additional Comments From sabre at nondot dot org 2005-07-26 17:35 --- Potential patch: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01732.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug tree-optimization/23083] New: internal compiler error: Segmentation fault
The attached code causes the compiler to crash when compiled as follows: pluto gcc -c -O1 -ftree-vectorize m.c m.c: In function C: m.c:7: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. pluto gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gcc410 --enable-languages=c,c++,f95 Thread model: posix gcc version 4.1.0 20050725 (experimental) The code compiles OK with gcc 4.0.1 -- Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: p dot van-hoof at qub dot ac dot uk CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23083
[Bug target/23067] Incorrect struct layout on darwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26
17:37 ---
Patch does not get the following correct:
struct f
{
long long i;
int j;
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug tree-optimization/23083] internal compiler error: Segmentation fault
--- Additional Comments From p dot van-hoof at qub dot ac dot uk 2005-07-26 17:37 --- Created an attachment (id=9367) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9367action=view) code fragment that causes the crash -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23083
