I found a bug of ICE in gcc-4.4.3 on sh-elf.
gcc-4.3 and gcc-4.5 does not have this problem.
$ gcc -O2 mtest01-k-e.c
mtest01-k.c: In function emainf:
mtest01-k.c:88: error: could not split insn
(jump_insn 312 302 472 mtest01-k.c:64 (parallel [
(set (pc)
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-18 07:16 ---
BTW, if the PRE_MODIFY representation doesn't work well, I'd say just using a
PARALLEL with what the insn really does and checking that in the match_parallel
predicate probably wouldn't clash with anything else. If
--- Comment #1 from iwamatsu at nigauri dot org 2010-03-18 07:18 ---
Created an attachment (id=20138)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20138action=view)
The source code that can reproduce a problem.
this code generate by -E option.
Sorry. There is the code to
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-18 08:27 ---
Reopening...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2010-03-18 08:29 ---
...to close as dup of bug 39871
*** This bug has been marked as a duplicate of 39871 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from steven at gcc dot gnu dot org 2010-03-18 08:29 ---
*** Bug 43286 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from steven at gcc dot gnu dot org 2010-03-18 08:31 ---
In the test case from bug 43286, should_replace_address does not perform the
following replacement because the address cost is the same and the replacement
is only done if new_rtx is more expensive than old_rtx.
--- Comment #8 from ramana at gcc dot gnu dot org 2010-03-18 09:25 ---
(In reply to comment #7)
BTW, if the PRE_MODIFY representation doesn't work well, I'd say just using a
PARALLEL with what the insn really does and checking that in the
match_parallel
predicate probably wouldn't
--- Comment #9 from ramana at gcc dot gnu dot org 2010-03-18 10:21 ---
Created an attachment (id=20139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20139action=view)
patch
Patch that makes the ICE disappear by converting these into mem:BLKmode
(pre_modify (Pmode)). I will submit
during make:
./prev-gcc/g++ ... -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Icp
.../gcc/cp/parser.c -o cp/parser.o
error: converting false to
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-18 10:59
---
Can you try replacing it with NULL_TREE? If everything goes well on your end,
we can commit the fix as obvious (I'm going to sanity check it for a normal
build)
--
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-03-18 11:30
---
Confirming. 4.5 trunk needs lots of memory in PRE.
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ailin dot nemui at gmail dot com 2010-03-18 11:37
---
works fine :) thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43418
--- Comment #3 from paolo at gcc dot gnu dot org 2010-03-18 11:46 ---
Subject: Bug 43418
Author: paolo
Date: Thu Mar 18 11:46:15 2010
New Revision: 157536
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157536
Log:
2010-03-18 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #4 from paolo at gcc dot gnu dot org 2010-03-18 11:46 ---
Subject: Bug 43418
Author: paolo
Date: Thu Mar 18 11:46:33 2010
New Revision: 157537
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157537
Log:
2010-03-18 Paolo Carlini paolo.carl...@oracle.com
PR
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #5 from paolo dot carlini at oracle dot com 2010-03-18 11:47
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-18 12:21 ---
Subject: Bug 43402
Author: matz
Date: Thu Mar 18 12:20:50 2010
New Revision: 157538
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157538
Log:
PR tree-optimization/43402
* tree-cfgcleanup.c
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-03-18 12:39 ---
Looks the same issue in
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00747.html
though I can't reproduce the problem with my gcc-4.4.3 and
4.4 head compilers for the test case in #1.
Could you try the patch in the
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-18 12:46 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from dodji at gcc dot gnu dot org 2010-03-18 12:50 ---
Things have changed quite a bit in GCC 4.5 (trunk).
Now for the code:
class C
{
static const int foo;
};
int
main()
{
return 0;
}
GCC 4.5 will not generate any debug info for the class C at all, because it's
--- Comment #8 from dodji at gcc dot gnu dot org 2010-03-18 12:52 ---
Bug no more present in GCC 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #10 from dodji at gcc dot gnu dot org 2010-03-18 12:53 ---
Bug no more present in 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from hjl at gcc dot gnu dot org 2010-03-18 13:11 ---
Subject: Bug 43360
Author: hjl
Date: Thu Mar 18 13:10:49 2010
New Revision: 157539
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157539
Log:
Remove the REG_EQUAL note if we don't know its invariant status.
--- Comment #16 from hjl at gcc dot gnu dot org 2010-03-18 13:13 ---
Subject: Bug 43360
Author: hjl
Date: Thu Mar 18 13:13:42 2010
New Revision: 157540
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157540
Log:
Remove the REG_EQUAL note if we don't know its invariant status.
--- Comment #17 from hjl at gcc dot gnu dot org 2010-03-18 13:15 ---
Subject: Bug 43360
Author: hjl
Date: Thu Mar 18 13:15:21 2010
New Revision: 157541
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157541
Log:
Remove the REG_EQUAL note if we don't know its invariant status.
--- Comment #18 from hjl dot tools at gmail dot com 2010-03-18 13:16
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #19 from steven at gcc dot gnu dot org 2010-03-18 13:20 ---
For the record: bootstrapped+tested on amd64-linux and ia64-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot
|dot org
gcc replaces pow(x, 0.5) by sqrt(x). This is invalid when x is -0. Indeed,
according to ISO C99 (N1256), F.9.4.4:
pow(±0, y) returns +0 for y 0 and not an odd integer.
So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0 according
to the IEEE 754 standard (and F.9.4.5 from ISO
on line 6197 to 6205:
unsigned char buf[5];
unsigned int i, len;
unsigned long offset;
for (i = 0; i 9; i++)
{
GET_OP (buf[i]);
if ((buf[i] 0x80) == 0)
break;
}
An obviously small wrong
--- Comment #1 from vincent at vinc17 dot org 2010-03-18 14:33 ---
If I understand correctly, the bug appears with:
r119248 | rguenth | 2006-11-27 12:38:42 +0100 (Mon, 27 Nov 2006) | 10 lines
2006-11-27 Richard Guenther rguent...@suse.de
PR middle-end/25620
*
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-18 14:35 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #18 from vincent at vinc17 dot org 2010-03-18 14:37 ---
The patch affected C, where the transformation of pow(x, 0.5) into sqrt(x) is
incorrect. See PR 43419.
--
vincent at vinc17 dot org changed:
What|Removed |Added
--- Comment #5 from dodji at gcc dot gnu dot org 2010-03-18 14:38 ---
(In reply to comment #4)
As we discussed on IRC, it seems we'd need a way to express that we'd want the
debugger to create a temporary, initialize it and later destroy it. DWARF can't
express as of now. So we'll
--- Comment #3 from dominiq at lps dot ens dot fr 2010-03-18 14:41 ---
While you are looking at this part, you may have to check that a similar
problem does not exist when converting x*sqrt(x) to pow(w,1.5) and so on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-18 14:48 ---
I checked, and these and similar transformations are always guarded by
flag_unsafe_math_optimizations, so we should be fine, unless I missed a case
of course. If you notice one, please create a bug report.
--
--- Comment #3 from roman at binarylife dot net 2010-03-18 14:52 ---
This looks related.
$ cat test.c
_Decimal64 func() {
return 9e384dd + 9e384dd;
}
$ gcc -c test.c
test.c: In function 'func':
test.c:2:3: internal compiler error: in decimal_to_decnumber, at dfp.c:115
...
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-18 15:29 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-18 15:31 ---
Looks like we need to guard this with HONOR_SIGNED_ZEROS.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Compiling the code below (with -O2 -Wall -std=c99, gcc 4.4.3) gives the warning
apa.c: In function 'f':
cc1: warning: dereferencing pointer '({anonymous})' does break strict-aliasing
rules
apa.c:9: note: initialized from here
which is both unhelpful and dubious - is the code really doing
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:08 ---
Subject: Bug 43419
Author: matz
Date: Thu Mar 18 16:07:53 2010
New Revision: 157543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157543
Log:
PR middle-end/43419
* builtins.c
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:47 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-18 16:47 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-18 16:48 ---
readelf is not part of the GCC project but the binutils project. Please report
it to them (http://www.sourceware.org/bugzilla/ ).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-18 16:53 ---
That would indeed be my preferred approach. The alternative would be to
add much if (x == error_mark_node) sillyness all over the middle-end, like
the front-ends do. The middle-end should be able to rightfully expect
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-18 16:55 ---
A radical approach would be to not gimplify in case of errors
Part of the problem there is that the C++ front-end (at least used to), produce
errors while gimplifying (though that might be fixed).
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-18 16:57 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24222 for all the bugs about
emitting errors/warnings during gimplification; though as I said some of those
might be fixed; I have not checked yet.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-18 16:59 ---
I will be looking into this, we should be able to not have a function_type with
an error_mark_node as an argument but we should just have an error_mark_node
instead.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-18 17:05 ---
Actually this is a simple patch:
Index: c-decl.c
===
--- c-decl.c(revision 157518)
+++ c-decl.c(working copy)
@@ -6118,6 +6118,7 @@ grokparms
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-18 17:24 ---
I have a patch. It's just unfortunate ordering of phi-translation and missed
caching.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43415
--- Comment #20 from changpeng dot fang at amd dot com 2010-03-18 17:24
---
(In reply to comment #19)
Splitting critical edges for CDDCE will probably also solve this problem.
Richard.
Yes, splitting critical edges is an enhancement to CDDCE and can solve this
problem. There are
--- Comment #4 from janis at gcc dot gnu dot org 2010-03-18 17:27 ---
The tests also fail on powerpc64-linux, although the first one gets the same
error with and without optimization.
elm3c105% cat 43374-1.c
int func(_Decimal32 v) {
return __builtin_isinf(v);
}
elm3c105%
--- Comment #21 from rguenther at suse dot de 2010-03-18 17:30 ---
Subject: Re: [4.5 Regression] Empty loop not
removed
On Thu, 18 Mar 2010, changpeng dot fang at amd dot com wrote:
--- Comment #20 from changpeng dot fang at amd dot com 2010-03-18 17:24
---
(In reply to
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-03-18 17:37
---
Native functions aren't expected to work with a 'C' body.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-18 17:39 ---
Then it should produce an error and not an internal compiler error.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
gcc could not vectorize this simple reversed loop:
int a[100], b[100];
void foo(int n)
{
int i;
for(i=n-2; i=0; i--)
a[i+1] = a[i] + b[i];
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=2 -c foo.c
foo.c:6: note: not vectorized: complicated access pattern.
foo.c:3: note:
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-18 17:55 ---
Works on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43416
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-18 17:56 ---
Could be a dup of bug 42871 or PR 43074.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43416
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-03-18 17:59
---
All fine again. Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-18 18:00 ---
The following fixes the PR. I have not regtested yet but anticipate that all
will be well.
Index: ../trunk/gcc/fortran/trans-expr.c
===
---
chf...@pathscale:~/gcc$ cat foo.c
int a[100], b[100], c[100];
void foo(int n, int mid)
{
int i;
for(i=0; in; i++)
{
if (i mid)
a[i] = a[i] + b[i];
else
a[i] = a[i] + c[i];
}
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=7 -c foo.c
foo.c:6:
I just tried to compile the package normaliz-2.2
with the C++ compiler version 4.5 snapshot 20100311 and it said
vector_operations.cpp: In function 'std::vectorlong int v_make_prime(const
std::vectorlong int, Integer)':
vector_operations.cpp:300:17: error: statement marked for throw in middle of
--- Comment #4 from hjl at gcc dot gnu dot org 2010-03-18 18:12 ---
Subject: Bug 43383
Author: hjl
Date: Thu Mar 18 18:12:31 2010
New Revision: 157544
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157544
Log:
Export __extendxftf2 to GCC_4.5.0 for 32bit libgcc.
2010-03-18 H.J.
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-18 18:13 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-03-18 18:13
---
Graphite is able to split the loop, but then the vectorizer punts anyway:
gcc -O3 -ftree-vectorizer-verbose=7 -fgraphite-identity -S t.c
t.c:11: note: not vectorized: number of iterations cannot be computed.
--- Comment #1 from dcb314 at hotmail dot com 2010-03-18 18:13 ---
Created an attachment (id=20140)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20140action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43424
chf...@pathscale:~/gcc$ cat foo.c
int a[100], b[100];
void foo(int n, int mid)
{
int i, t = 0;
for(i=0; in; i++)
{
a[i] = b[i] + t;
t = b[i];
}
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=7 -c foo.c
foo.c:6: note: not vectorized: unsupported use in stmt.
--- Comment #1 from pault at gcc dot gnu dot org 2010-03-18 18:17 ---
This is fixed by the following, which is not yet regtested:
Index: ../trunk/gcc/fortran/resolve.c
===
--- ../trunk/gcc/fortran/resolve.c (revision
Hello,
I'm trying to build sqlite-3.6.22 on a sun4v server (T1 processor). I have
tried bith gcc 4.4.1 and 4.4.3 in 32 and 64 bits modes. sqlite build process
aborts with:
...
gcc -DSQLITE_THREADSAFE=0 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE
-mtune=niagara -mcpu=niagara -m64 -m64 -m64 -m64 -o
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-18 18:22 ---
Well it could be vectorized even without range splitting. The issue is the
sinking of the store to a[i].
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #46 from dominiq at lps dot ens dot fr 2010-03-18 18:29 ---
The answer to the question (b) in comment #35:
(b) why !optimize_size has been replaced with optimize_insn_for_speed_p ()?
seems to be
this patch replace some of optimize_size tests by
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-18 18:31 ---
Basically undoing predictive commoning (which we switched the order for 4.5 to
fix a different issue). Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Well it could be vectorized even without range splitting. The issue is the
sinking of the store to a[i].
You mean that the problem is the if-conversion of the stores
a[i] = ...
--- Comment #3 from sebpop at gmail dot com 2010-03-18 18:33 ---
Subject: Re: gcc should vectorize this loop
through iteration range splitting
Well it could be vectorized even without range splitting. The issue is the
sinking of the store to a[i].
You mean that the
chf...@pathscale:~/gcc$ cat foo.c
float a[100][100], b[100][100];
void foo(int n)
{
int i, j;
for(j=0; jn; j++)
for(i=0; i n; i++)
a[i][j] = a[i][j] + b[i][j];
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=2 -c foo.c
foo.c:6: note: not vectorized: can't create epilog
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-18 18:38 ---
(In reply to comment #3)
Subject: Re: gcc should vectorize this loop
through iteration range splitting
You mean that the problem is the if-conversion of the stores
a[i] = ...
If we rewrite the code
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-18 18:41 ---
-ftree-loop-linear can do it also; though neither graphite or that is on by
default.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-18 18:41 ---
(In reply to comment #2)
The following fixes the PR. I have not regtested yet but anticipate that all
will be well.
Looks good. Does is also fix PR 43039? Looking at Thomas' analysis and at the
patch, it might
--- Comment #5 from spop at gcc dot gnu dot org 2010-03-18 18:51 ---
Yes,
I think we should improve if-conversion to handle more complex cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
chf...@pathscale:~/gcc$ cat foo.c
float a[100], b[100], c[100];
void foo(int n)
{
int i;
for(i=1; in; i++)
{
a[i] = a[i] + c[i];
b[i] = b[i-1] + a[i];
}
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=2
-ftree-loop-distribution -c foo.c
foo.c:6: note: not
--- Comment #2 from spop at gcc dot gnu dot org 2010-03-18 18:59 ---
In the output of ./cc1 -O3 -floop-interchange -fdump-tree-graphite-all
-ftree-vectorizer-verbose=7
we have: Loops at depths 0 and 1 will be interchanged.
so we do the interchange, but then the vectorizer complains
--- Comment #3 from spop at gcc dot gnu dot org 2010-03-18 19:01 ---
./cc1 -O3 -msse2 -ffast-math -ftree-vectorizer-verbose=2 pr43427.c
-ftree-loop-linear
pr43427.c:6: note: not vectorized: complicated access pattern.
pr43427.c:7: note: LOOP VECTORIZED.
pr43427.c:3: note: vectorized 1
--- Comment #4 from pault at gcc dot gnu dot org 2010-03-18 19:09 ---
(In reply to comment #3)
(In reply to comment #2)
The following fixes the PR. I have not regtested yet but anticipate that
all
will be well.
Looks good. Does is also fix PR 43039? Looking at Thomas'
--- Comment #13 from a dot kumar at alumni dot iitm dot ac dot in
2010-03-18 19:25 ---
Hi!
I was wondering if this bug is likely to be fixed in the next GCC release; is
this likely to be the case?
Thanks!
Kumar
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
--- Comment #17 from jamborm at gcc dot gnu dot org 2010-03-18 20:07
---
Subject: Bug 42450
Author: jamborm
Date: Thu Mar 18 20:07:13 2010
New Revision: 157546
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157546
Log:
2010-03-18 Martin Jambor mjam...@suse.cz
PR
--- Comment #5 from pault at gcc dot gnu dot org 2010-03-18 20:12 ---
(In reply to comment #3)
(In reply to comment #2)
snip
I suspect that it is similar but not identical. Will look after dinner :-)
Paul
This surmise is correct. As soon as the other two fixes have
--- Comment #14 from jakub at gcc dot gnu dot org 2010-03-18 20:15 ---
Subject: Bug 43058
Author: jakub
Date: Thu Mar 18 20:15:05 2010
New Revision: 157547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157547
Log:
PR debug/43058
* var-tracking.c
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-18 20:17 ---
Subject: Bug 42873
Author: jakub
Date: Thu Mar 18 20:16:48 2010
New Revision: 157548
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157548
Log:
PR debug/42873
* var-tracking.c
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-18 20:17 ---
Subject: Bug 43403
Author: jakub
Date: Thu Mar 18 20:17:32 2010
New Revision: 157549
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157549
Log:
PR bootstrap/43403
* var-tracking.c
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-18 20:19 ---
Subject: Bug 43399
Author: jakub
Date: Thu Mar 18 20:18:53 2010
New Revision: 157550
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157550
Log:
PR bootstrap/43399
* var-tracking.c (adjust_mems)
Hello,
I'm trying to build sqlite-3.6.22 on a sun4v server (T1 processor). I have
tried bith gcc 4.4.1 and 4.4.3 in 32 and 64 bits modes. sqlite build process
aborts with:
...
gcc -DSQLITE_THREADSAFE=0 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE
-mtune=niagara -mcpu=niagara -m64 -m64 -m64 -m64 -o
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-18 20:22 ---
Reduced testcase:
struct vector
{
long operator[](int __n) { return *(_M_start + __n); }
~vector();
long *_M_start;
};
long v_gcd();
void v_make_prime(vector v,long g, long j){
int i;
vector w;
This code from FFmpeg is not vectorized:
gcc-4.5 -c vsad_intra.c -O3 -ffast-math -ftree-vectorizer-verbose=7 -msse2
[...]
vsad_intra.c:15: note: not vectorized: relevant stmt not supported: iftmp.0_7 =
[cond_expr] iftmp.0_35 0 ? iftmp.0_77 : iftmp.0_35;
typedef short DCTELEM;
typedef unsigned
--- Comment #15 from jakub at gcc dot gnu dot org 2010-03-18 20:30 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-18 20:31 ---
Fixed, thanks Alex.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-18 20:31 ---
Does it work now?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from jakub at gcc dot gnu dot org 2010-03-18 20:35 ---
The latter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-18
20:36 ---
Subject: Re: [4.5 Regression] ICE in stage1 compiling __bswapdi2
Does it work now?
Full regression test isn't complete. Bootstrap was successful and no
regressions were observed in gcc and acats
1 - 100 of 136 matches
Mail list logo
