--- Comment #1 from sezeroz at gmail dot com 2010-03-19 06:51 ---
Happened on x86_64-pc-linux and my gcc-4.4 was affected too, gcc-3.4.6 seemed
fine.
--
sezeroz at gmail dot com changed:
What|Removed |Added
-
The -O0 result looks right. This behavior observed on x86 using r157445 and
x64 using r157542.
reg...@john-home:~$ current-gcc -O0 small.c -o small -Wall
reg...@john-home:~$ ./small
1
reg...@john-home:~$ current-gcc -O1 small.c -o small -Wall
reg...@john-home:~$ ./small
0
reg...@john-home:~$ ca
--- Comment #3 from iwamatsu at nigauri dot org 2010-03-19 06:11 ---
(In reply to comment #2)
> 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 #
--- Comment #5 from wlam at kosmix dot com 2010-03-19 04:23 ---
I think you're right--I built gcc trunk at r157545, and I don't see the
segmentation fault there. (Thanks for your quick response!)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43416
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-03-19 03:24
---
The front end work for this is complete. We simply forgot to implement on the
runtime side. One thing we have to be careful with is the kind of the integer.
Currently it is limited to kind=4 and all results are
--- Comment #1 from segher at gcc dot gnu dot org 2010-03-19 02:25 ---
Caused by / exposed by SVN r157476
Author: jakub
Date: Tue Mar 16 10:50:42 2010 +
PR debug/43051
PR debug/43092
...
--
segher at gcc dot gnu dot org changed:
What|Removed
Building a cross compiler to score-elf fails with:
/n/17/segher/src/gcc/libgcc/../gcc/libgcc2.c: In function '__mulsc3':
/n/17/segher/src/gcc/libgcc/../gcc/libgcc2.c:1889:1: internal compiler error:
in
cselib_record_set, at cselib.c:1864
--
Summary: build error
Product: g
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-19
00:47 ---
Andrew,
Do you still see this issue with current gcc trunk since...
Author: andreast
Date: Wed Nov 18 07:36:12 2009
New Revision: 154282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154282
L
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-03-19 00:36
---
Well for 4.5, make sure you configured with --enable-checking=release;
otherwise it is not a fair comparison.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
--- Comment #11 from kurt at garloff dot de 2010-03-19 00:34 ---
(In reply to comment #10)
> GCC 4.3.4 is being released, adjusting target milestone.
Very non-scientific benchmark:
Did compile latest gmic-1.3.4.0 on a 2xL5540 system (plenty of RAM) with make
-j8 and compile flags:
-O3
--- Comment #1 from mikpe at it dot uu dot se 2010-03-18 23:19 ---
Maybe fixed by:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00356.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43435
--- Comment #13 from mikestump at comcast dot net 2010-03-18 22:57 ---
Fix checked in as r157553.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
--- Comment #12 from mrs at gcc dot gnu dot org 2010-03-18 22:57 ---
Subject: Bug 36399
Author: mrs
Date: Thu Mar 18 22:56:38 2010
New Revision: 157553
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157553
Log:
2010-03-11 Francois-Xavier Coudert
Jack Howarth
--- Comment #12 from robertcnelson at gmail dot com 2010-03-18 22:53
---
(In reply to comment #11)
> Patch submitted here.
>
> http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00840.html
>
My beagle just finished testing your initial patch, it looks good:
http://rcn-ee.homeip.net:81/dl/
--- Comment #1 from spop at gcc dot gnu dot org 2010-03-18 22:04 ---
Also note that a similar problem occurs for hadamard8:
gcc-4.5 -c hadamard8.c -O3 -ffast-math -ftree-vectorizer-verbose=7 -msse2
[...]
hadamard8_diff.c:44: note: not vectorized: unhandled data-ref
hadamard8_diff.c:26:
--- Comment #2 from sam at gcc dot gnu dot org 2010-03-18 22:04 ---
I can reproduce the bug with 4.4.3 but not with gcc (GCC) 4.5.0 20100317
(experimental) on x86_64. This may already be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43106
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
http:
This kernel from FFmpeg is not vectorized with:
gcc-4.5 -c sub_hfyu_median_prediction.c -O3 -ffast-math
-ftree-vectorizer-verbose=7 -msse2
[...]
sub_hfyu_median_prediction.c:18: note: not vectorized: unhandled data-ref
Looking with GDB at it, I get:
(gdb) p debug_data_references (datarefs)
(Data
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-18 21:50 ---
Actually I am wrong but there is something else going on here.
failed: evolution of base is not affine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43434
Output of 'sh-elf-gcc -v -save-temps -O0 -m2a-nofpu -S -o tstint.asm tstint.c':
Using built-in specs.
Target: sh-elf
Configured with: ./gcc-4.3.4/configure --target=sh-elf --program-prefix=sh-elf-
--prefix=/opt/cross/sh-elf --disable-shared --with-multilib --disable-nls
--disable-libssp --enable-la
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-18 21:44 ---
Oh it might also need the patch for PR 29751 which I hope to submit for 4.6.
Note the patch in there still works and has been tested as of earlier this
week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43434
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-18 21:43 ---
Hint here, character types can alias any other type. Also I think s1 and s2
need to be marked as restrict to get the aliasing correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43434
--- Comment #11 from ramana at gcc dot gnu dot org 2010-03-18 21:40 ---
Patch submitted here.
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00840.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
--- Comment #7 from joseph at codesourcery dot com 2010-03-18 21:36 ---
Subject: Re: sinl is not computed correctly
On Thu, 18 Mar 2010, bangerth at gmail dot com wrote:
> Also: 1e22 is not exactly representable as a floating point number. By
5**22 is smaller than 2**53, so 1e22 (= 5
These kernels from FFmpeg are not vectorized with:
gcc-4.5 -c diff_pixels.c -O3 -ffast-math -ftree-vectorizer-verbose=7 -msse2
[...]
diff_pixels.c:10: note: not vectorized: data ref analysis failed D.2726_9 =
*s1_100;
Note that ICC 11.0 does vectorize these loop kernels.
The difficulty seems to be
--- Comment #3 from pault at gcc dot gnu dot org 2010-03-18 21:29 ---
Fixed on trunk.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pault at gcc dot gnu dot org 2010-03-18 21:29 ---
Fixed on trunk.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pault at gcc dot gnu dot org 2010-03-18 21:28 ---
Fixed on trunk.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pault at gcc dot gnu dot org 2010-03-18 21:24 ---
Subject: Bug 43043
Author: pault
Date: Thu Mar 18 21:23:35 2010
New Revision: 157552
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157552
Log:
2010-03-18 Paul Thomas
PR fortran/43039
* tra
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-18 21:24 ---
Subject: Bug 43044
Author: pault
Date: Thu Mar 18 21:23:35 2010
New Revision: 157552
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157552
Log:
2010-03-18 Paul Thomas
PR fortran/43039
* tra
--- Comment #3 from pault at gcc dot gnu dot org 2010-03-18 21:24 ---
Subject: Bug 43039
Author: pault
Date: Thu Mar 18 21:23:35 2010
New Revision: 157552
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157552
Log:
2010-03-18 Paul Thomas
PR fortran/43039
* tra
--- Comment #1 from spop at gcc dot gnu dot org 2010-03-18 21:08 ---
*** Bug 43433 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43432
--- Comment #1 from spop at gcc dot gnu dot org 2010-03-18 21:08 ---
Duplicated of PR43432: pressed "commit bug" twice.
*** This bug has been marked as a duplicate of 43432 ***
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--
Both these loop kernels from FFmpeg fail with:
gcc-4.5 -c vector_fmul_window.c -O3 -ffast-math -ftree-vectorizer-verbose=7
-msse2
[...]
vector_fmul_window.c:7: note: not vectorized: complicated access pattern.
They look similar in the fact that they use both an increasing and a decreasing
inductio
Both these loop kernels fail with:
gcc-4.5 -c vector_fmul_window.c -O3 -ffast-math -ftree-vectorizer-verbose=7
-msse2
[...]
vector_fmul_window.c:7: note: not vectorized: complicated access pattern.
They look similar in the fact that they use both an increasing and a decreasing
induction variables
--- Comment #1 from mt1 at systella dot fr 2010-03-18 21:05 ---
Strange... SQLite makefile builds shared library with this command:
gcc -shared .libs/sqlite3.o -L/usr/lib/sparcv9 -lc -mtune=niagara
-mcpu=niagara -m64 -m64 -m64 -m64 -Wl,-soname -Wl,libsqlite3.so.0 -o
.libs/libsqlite3.s
--- Comment #6 from bangerth at gmail dot com 2010-03-18 20:47 ---
Also: 1e22 is not exactly representable as a floating point number. By
consequence, 1e22 is different numbers when stored as a double or a
long double, and we should expect different results when applying the
sine to it.
The diagnostic message is not clear when compiling this code from FFmpeg with
gcc-4.5 -c vsad_intra.c -O3 -ffast-math -ftree-vectorizer-verbose=7 -msse2
[...]
ac3_downmix.c:10: note: cost model: vector iteration cost = 2060 is divisible
by scalar iteration cost = 7 by a factor greater than or equa
--- Comment #21 from jakub at gcc dot gnu dot org 2010-03-18 20:36 ---
Assuming this is fixed. If you have a new testcase, please file a new PR.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- 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 tests
--- 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 #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
Status|A
--- 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
Status|
--- 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
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 #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;
g=v
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 #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=gcc&view=rev&rev=157550
Log:
PR bootstrap/43399
* var-tracking.c (adjust_mems
--- 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=gcc&view=rev&rev=157549
Log:
PR bootstrap/43403
* var-tracking.c (vt_init_cfa_
--- 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=gcc&view=rev&rev=157548
Log:
PR debug/42873
* var-tracking.c (canonicalize_var
--- 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=gcc&view=rev&rev=157547
Log:
PR debug/43058
* var-tracking.c (non_suitable_co
--- 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 #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=gcc&view=rev&rev=157546
Log:
2010-03-18 Martin Jambor
PR middle-end/42450
--- 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 #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 #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 #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 abo
chf...@pathscale:~/gcc$ cat foo.c
float a[100], b[100], c[100];
void foo(int n)
{
int i;
for(i=1; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43428
--- 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
--- 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 w
--- 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 #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
chf...@pathscale:~/gcc$ cat foo.c
float a[100][100], b[100][100];
void foo(int n)
{
int i, j;
for(j=0; jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43427
--- 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 p
> 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 #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 |Adde
--- 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
> optimize_insn_for_spee
--- 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
-
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 #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 15
chf...@pathscale:~/gcc$ cat foo.c
int a[100], b[100];
void foo(int n, int mid)
{
int i, t = 0;
for(i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43425
--- 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=20140&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43424
--- 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.
t.c:
--- 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 #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=gcc&view=rev&rev=157544
Log:
Export __extendxftf2 to GCC_4.5.0 for 32bit libgcc.
2010-03-18 H.J.
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::vector v_make_prime(const
std::vector&, Integer&)':
vector_operations.cpp:300:17: error: statement marked for throw in middle of
block
# .MEM_36
chf...@pathscale:~/gcc$ cat foo.c
int a[100], b[100], c[100];
void foo(int n, int mid)
{
int i;
for(i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
--- 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
===
--- ../trunk/gcc
--- 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 #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 #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
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: vecto
--- 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
-
--- 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 #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
--- 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% /home/janis/t
--- 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
--- 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 #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 (s
--- 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 #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.
--
http://gcc.g
--- 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).
--
http://gc
--- 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 expec
--- 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 #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 #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 gc
--- 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=gcc&view=rev&rev=157543
Log:
PR middle-end/43419
* builtins.c (expand_builtin_po
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 anything
--- 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
---
--- 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
Assigne
1 - 100 of 139 matches
Mail list logo
