--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-02 08:04 ---
Unfortunately, the patch didn't bootstrap.
One issue is loc_cmp, which asserts everywhere the modes are the same. Which
isn't necessarily true, we can end up comparing e.g.:
(subreg:QI (value/s/u:DI 28:4092
--- Comment #7 from burnus at gcc dot gnu dot org 2010-03-02 09:16 ---
I do not see the temporaries with [...] 4.5.0 20100214
but I see this with [...]4.5.0 20100227
I think the regression is due to:
http://gcc.gnu.org/viewcvs?view=revisionrevision=156926
Namely due
--- Comment #8 from burnus at gcc dot gnu dot org 2010-03-02 09:24 ---
Completely untested patch:
--- trans-array.c (revision 157160)
+++ trans-array.c (working copy)
@@ -,5 +,5 @@ gfc_conv_array_parameter (gfc_se * se, g
no_pack = ((sym sym-as
On 32-bit HWI host calling
simplify_binary_operation (MINUS, DImode, (reg/v:DI 60 [ x ]), (const_int
-2147483648 [0x8000]))
returns
(plus:DI (reg/v:DI 60 [ x ])
(const_int -2147483648 [0x8000]))
which is wrong. I guess we need to avoid the INTVAL wrap in that case.
2041 /* Don't
Compiling the original test for pr43199 with fortran-dev revision 157148 gives
a segmentation fault:
(gdb) run pr43199.f90
Starting program: /opt/gcc/gcc4.5d/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951
pr43199.f90
Reading symbols for shared libraries .. done
Program received
--- Comment #15 from dominiq at lps dot ens dot fr 2010-03-02 09:47 ---
I just opened pr43227 for a similar regression. For the record the backtrace
for the test in comment#1 with fortran-dev revision 157148 is
(gdb) run pr42274.f90
The program being debugged has been started already.
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-02 09:50 ---
For DATA gfortran already pads the Hollerith constant; maybe the simplest would
be to modify primary.c's match_hollerith_constant to simply add tailing spaces
such that the length is multiples of the storage size of,
--- Comment #9 from burnus at gcc dot gnu dot org 2010-03-02 10:01 ---
(In reply to comment #8)
Completely untested patch:
Still untested, but I think it might lead to wrong code with either
allocatable(1)%pointer(1:2) ! Potentially non-contiguous
or
pointer%allocatable(1:2) !
--- Comment #5 from spop at gcc dot gnu dot org 2010-03-02 10:23 ---
Subject: Bug 42640
Author: spop
Date: Tue Mar 2 10:22:30 2010
New Revision: 157161
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157161
Log:
Fix PR42640: Correctly initialize the value of the new induction
--- Comment #6 from spop at gcc dot gnu dot org 2010-03-02 10:24 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from dominiq at lps dot ens dot fr 2010-03-02 10:37 ---
Could pr41056 be related to this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-02 11:12 ---
The extra DEBUG stmts or DEBUG_INSNs only consume memory, they shouldn't affect
debug info generation, though perhaps it wouldn't hurt once or twice during
gimple optimizations and once or twice during RTL
--
jiez at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jiez at gcc dot gnu dot org
|dot org
When we read this kind of sctructure in gfortran, just the first values
(akh20(01,1)) is read. The others values are ignored an receives zeros.
akh2o(01,:)=0.02080, 0.01550, 0.01040, 0.00510, 0.00200,
0.00062
akh2o(02,:)=0.17070, 0.12910, 0.08630, 0.04300,
--- Comment #10 from spop at gcc dot gnu dot org 2010-03-02 11:39 ---
Comment #9 is not the same as the original reported bug.
I have a fix for #9.
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42326
--- Comment #16 from jwakely dot gcc at gmail dot com 2010-03-02 11:41
---
I might have caused a regression with this change:
FAIL: 30_threads/promise/members/set_value3.cc execution test
WARNING: program timed out.
Will investigate later today...
--
--- Comment #11 from spop at gcc dot gnu dot org 2010-03-02 11:51 ---
Subject: Bug 42326
Author: spop
Date: Tue Mar 2 11:51:21 2010
New Revision: 157162
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157162
Log:
Fix PR42326: handle default definitions.
2010-03-02 Sebastian Pop
--- Comment #11 from pault at gcc dot gnu dot org 2010-03-02 11:58 ---
Subject: Bug 43180
Author: pault
Date: Tue Mar 2 11:58:02 2010
New Revision: 157163
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157163
Log:
2010-03-02 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #10 from pault at gcc dot gnu dot org 2010-03-02 11:58 ---
Subject: Bug 43173
Author: pault
Date: Tue Mar 2 11:58:02 2010
New Revision: 157163
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157163
Log:
2010-03-02 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #11 from pault at gcc dot gnu dot org 2010-03-02 12:10 ---
Fixed on trunk, thanks for the report!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pault at gcc dot gnu dot org 2010-03-02 12:11 ---
Fixed on trunk, thanks for the report!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-02 12:15 ---
It's not really the vectorizers job to do this optimization but that of the
expander.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43225
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-02 12:18 ---
(In reply to comment #4)
Is it possible for aliased writes to affect a const pointer? I was assuming
that it wasn't.
Yes, it is possible. C const qualification doesn't add any useful
information for a compiler
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-02 12:34 ---
Updated patch which actually bootstraps/regtests posted:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00096.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from jwakely dot gcc at gmail dot com 2010-03-02 12:44
---
The 30_threads/promise/members/set_value3.cc test had a latent bug which was
revealed by the unique_ptr fix. I'll change the test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-02 12:46 ---
Luiz: Can you please state the version of gfortran? (Use: gfortran -v and
post the Target: line and the gcc version).
Additionally: For a good bugreport, please also include a minimal example.
Without an example
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-02 12:54 ---
On powerpc-apple-darwin9, I have the same kind of outputs (1, 4, 7, 8, and 9
are correct, 6 is correct but at the wrong place, the rest is 0 or garbage) for
the test in comment#1 from 4.2.4 to trunk.
--
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-02 13:17 ---
There is another very important issue and that is that
emit_note_insn_var_location and vt_expand_loc_callback completely ignores
cur_loc, but the code that decides whether a variable actually changed uses
heavily
/vondele/gcc_trunk/build/
--with-libelf=/data03/vondele/libelf-0.8.12/build/ --enable-gold --enable-lto
--enable-plugins
Thread model: posix
gcc version 4.5.0 20100302 (experimental) [trunk revision 157164] (GCC)
COLLECT_GCC_OPTIONS='-g' '-O3' '-ffast-math' '-v' '-shared-libgcc'
/data03/vondele
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Component|rtl-optimization|debug
Target Milestone|--- |4.5.0
On Linux/x86, revision 157158:
http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00030.html
caused:
FAIL: 30_threads/promise/members/set_value3.cc execution test
--
Summary: [4.5 regression] Revision 157158 failed
30_threads/promise/members/set_value3.cc
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43230
--- Comment #18 from hjl dot tools at gmail dot com 2010-03-02 13:31
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-02 13:41 ---
Confirmed on x86_64-apple-darwin10 with '-O3 -g -ffast-math'. It seems to
appear between revisions 157098 and 157143.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43229
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-02 13:48 ---
The disadvantage of clearing cur_loc in check_changed_vars_{1,2} is that we'd
lose track of the preferred location.
I guess we want to prefer the previous cur_loc (at least if it in the end
results in REG or MEM or
There is no vec_unpacks_{hi,lo}_v8sf necessary for v8sf - v8df float
extension.
Index: config/i386/sse.md
===
--- config/i386/sse.md (revision 157148)
+++ config/i386/sse.md (working copy)
@@ -3068,6 +3069,29 @@ (define_expand
--- Comment #1 from redi at gcc dot gnu dot org 2010-03-02 14:10 ---
see bug 43183
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from luflarois at gmail dot com 2010-03-02 14:10 ---
(In reply to comment #1)
Luiz: Can you please state the version of gfortran? (Use: gfortran -v and
post the Target: line and the gcc version).
Additionally: For a good bugreport, please also include a minimal
--- Comment #2 from redi at gcc dot gnu dot org 2010-03-02 14:13 ---
The fix is to remove the ~tester destructor, it's invalid to test the future's
state from the tester destructor, because the future state has already started
being destroyed and its condition_variable and mutex get
--- Comment #3 from redi at gcc dot gnu dot org 2010-03-02 14:16 ---
P.S. I won't be able to commit the change until later today, in 4-5 hours
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jamborm at gcc dot gnu dot org 2010-03-02 14:45
---
(In reply to comment #9)
This caused testsuite regressions for 4.4 on (at least) powerpc64 and arm:
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02633.html
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-03-02 14:56 ---
Mine.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-02 15:12 ---
Jerry, you wrote almost exactly one month ago: Funny how namelist always shows
up as we approach release. -- now that we have a new one: Does this mean that
we indeed approach a release? In any case, the half life
With a source as simple as the following:
-8
int foo(int a, int b) {
return a + b;
}
-8
a .eh_frame section is created on x86-64 when using -fno-exceptions. The
section is *not* created on x86.
on x86-64:
$ g++ -o test.o -c test.cpp -fno-exceptions
$ objdump -h
--- Comment #4 from paolo at gcc dot gnu dot org 2010-03-02 15:36 ---
Subject: Bug 43230
Author: paolo
Date: Tue Mar 2 15:36:00 2010
New Revision: 157166
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157166
Log:
2010-03-02 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #5 from paolo dot carlini at oracle dot com 2010-03-02 15:37
---
Thanks Jon, I did it for you to make regtesting faster.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-02 15:43 ---
That's because x86-64 defaults to -fasynchronous-unwind-tables. You really
want that by default on x86_64, as frame pointer is usually omitted.
--
jakub at gcc dot gnu dot org changed:
What
--- Comment #6 from redi at gcc dot gnu dot org 2010-03-02 15:51 ---
Thanks! sorry for the breakage, I missed that regression amongst some other
failures in 30_threads/promise which were caused by some local changes. I
should have backed them out before testing the fix for bug 43183
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-02 16:23 ---
Paul confirmed that it (comment 1) also fails on the trunk (4.5.0)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-02 16:34 ---
Created an attachment (id=20003)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20003action=view)
gcc45-pr43229.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-02 16:36 ---
It is caused by revision 157009:
http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00592.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Hi,
I found the following bug in gcc 3.3 and 3.4 with TLS on x86-32. It seems to be
OK with gcc 4.0-4.4. This problem affects the Userspace RCU library
(http://lttng.org/urcu). I am providing a small test case to show the problem.
comp...@compumobile:~/test$ gcc-3.4 -v -save-temps -c -o
--- Comment #2 from mh+gcc at glandium dot org 2010-03-02 17:37 ---
(In reply to comment #1)
That's because x86-64 defaults to -fasynchronous-unwind-tables. You really
want that by default on x86_64, as frame pointer is usually omitted.
Why would you want
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-02 17:40 ---
(In reply to comment #2)
(In reply to comment #1)
That's because x86-64 defaults to -fasynchronous-unwind-tables. You really
want that by default on x86_64, as frame pointer is usually omitted.
Why would
--- Comment #4 from mh+gcc at glandium dot org 2010-03-02 17:48 ---
Because it can be used for the backtrace when debugging. Without a frame
pointer on x86/x86_64, you cannot get a real backtrace without unwinding info.
So, in case I build with -g, I can just use
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-02 17:52 ---
(In reply to comment #4)
So, in case I build with -g, I can just use -fno-asynchronous-unwind-tables
safely ?
Yes it is safe but not recommended though. I should mention the x86_64 elf ABI
requires this section
--- Comment #6 from mh+gcc at glandium dot org 2010-03-02 17:56 ---
(In reply to comment #5)
(In reply to comment #4)
So, in case I build with -g, I can just use -fno-asynchronous-unwind-tables
safely ?
Yes it is safe but not recommended though. I should mention the x86_64 elf
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-02 18:15 ---
Fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-02 18:18 ---
Still happens on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37273
--- Comment #19 from pinskia at gcc dot gnu dot org 2010-03-02 18:24
---
Here is a testcase which shows the problem on MIPS too:
extern int f0(int *, int *);
int
f1()
{
int x = 0 , x1 = 0;
while (f0(x, x1));
return x + x1;
}
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-02 18:29 ---
Still happens as of today on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37262
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-02 18:34 ---
Hmm, we get worse code now on the trunk:
addi 9,1,-80
li 0,48
stvewx 2,9,0
lwz 0,-32(1)
stw 0,-16(1)
stw 0,-12(1)
stw 0,-8(1)
stw 0,-4(1)
li
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-02 18:52 ---
We do look through the memset at the tree level now but we don't remove it
still.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-02 18:53 ---
Still happens on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37471
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-02 18:58 ---
Even though the C++ front-end produces the NOP_EXPR still, the gimplifier
removes them early on and uses VCE instead. So this is no longer a missed
optimization. I am unassigning myself too.
--
pinskia at gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-02 19:01 ---
Still happens as of today on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38497
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-02 19:05 ---
This has been fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-02 19:07 ---
Still happens as of today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38885
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-02 19:09 ---
Still happens as of today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38884
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-02 19:14 ---
Still happens on the trunk as of today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30967
Source:
int g1,g2,g3;
int f1(int a, int b)
{
a = 1;
if (a) return g1;
return g2;
}
int f2(int a, int b)
{
a = 1;
if (b)
g3++;
if (a) return g1;
return g2;
}
Compiled with:
gcc -O3 -fomit-frame-pointer -S and_flags.c
f1 is ok but f2 generates this:
_f2:
Command line:
gcc -O1 -c testcase.c
Tested revisions:
trunk r157161 x86_64 - segfault
trunk r156472 i686 - segfault
trunk r153685 x86_64 - segfault
4.4 r157120 x86_64 - assert at tree-nrv.c:143
4.4 r156591 i686 - OK
4.4 r149995 x86_64 - assert at tree-nrv.c:143
(all with checking=yes)
Output
--- Comment #1 from zsojka at seznam dot cz 2010-03-02 19:32 ---
Created an attachment (id=20004)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20004action=view)
reduced testcase
Crashes with both
__attribute__((optimize(-ftree-loop-distribution)))
and
--- Comment #10 from mrs at gcc dot gnu dot org 2010-03-02 19:40 ---
Subject: Bug 41090
Author: mrs
Date: Tue Mar 2 19:40:02 2010
New Revision: 157172
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157172
Log:
PR c++/41090
* g++.dg/ext/label13.C (C::C): xfail for
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-02 19:42
---
The original testcase still ICEs, just not the reduced testcase.
On the trunk, the original testcase has:
(insn 218 217 219 26 t.c:624 (set (reg/v:DF 203 [ ___F64V2 ])
(mem:DF (plus:DI (reg:DI 197 [
--- Comment #11 from uweigand at gcc dot gnu dot org 2010-03-02 19:56
---
(In reply to comment #10)
I don't see where reload is creating the whole instruction; maybe I am
misunderstanding that statement.
Well, after reload you have insn 624, which presumably didn't exist before.
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-02 19:59 ---
I think this is the same issue as PR 36758.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
unsigned long long da;
da = ( 1234567ULL 32 ) | ( 362436069ULL );
unsigned int a;
a = da;
I would expect a warning on the assignment of a lower precision data type to a
higher precision data type with no cast. gcc V4.4.1-ubuntu with -Wall gives no
warning on the above code. The
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-02 20:08 ---
-Wconversion is needed for the warning you want to happen.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-03-02 20:09
---
I will try to get started on this tonight. Is the half-life proportaional to
the degrees of freedom? :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-02 20:10
---
Actually looking at comment #4 shows that is an exact duplicate of PR 36758 so
closing as a dup.
*** This bug has been marked as a duplicate of 36758 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-03-02 20:10
---
*** Bug 39837 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Tested revisions:
trunk r157161 - fail (fix for pr42640 doesn't help)
trunk r156598 - fail
It causes bootstrap comparison failure with BOOT_CFLAGS=-O2
-ftree-loop-distribution:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-02 20:17 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from zsojka at seznam dot cz 2010-03-02 20:20 ---
Created an attachment (id=20005)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20005action=view)
this patch causes bootstrap with BOOT_CFLAGS=-O2 -ftree-loop-distribution to
assert
Assert message is:
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-02 20:31 ---
Confirmed, the testcase is gcc.c-torture/execute/20051215-1.c by the way.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from zsojka at seznam dot cz 2010-03-02 20:33 ---
Created an attachment (id=20006)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20006action=view)
this patch causes regular bootstrap to assert
Assert message is:
/mnt/svn/gcc-trunk/libgcc/../gcc/libgcc2.c: In
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
On x86_64-linux with -O2 -g gcc creates invalid DW_AT_upper_bound:
struct S
{
int *a;
int b;
int **c;
int d;
};
void foo (struct S *);
void bar (struct S *);
int
baz (void)
{
struct S s;
foo (s);
{
int a[s.b];
int *c[s.d];
s.a = a;
s.c = c;
bar (s);
}
return
The attached preprocessed file (from the mplayer sources) results in a GCC 4.5
(today's SVN snapshot) segfault when compiled with any -O flag. Compilation
without -O completes correctly.
gcc -O -c -o af_format.o af_format.c
af_format.pre.c: In function 'play':
af_format.pre.c:1166:19: internal
--- Comment #1 from il dot basso dot buffo at gmail dot com 2010-03-02
20:53 ---
Created an attachment (id=20007)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20007action=view)
Preprocessed C source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43238
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-02 20:58 ---
af_format.pre.c: In function âplayâ:
af_format.pre.c:1166:19: internal compiler error: in try_improve_iv_set, at
tree-ssa-loop-ivopts.c:5238
Please submit a full bug report,
with preprocessed source if
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-02 20:58 ---
*** This bug has been marked as a duplicate of 43209 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-02 20:58 ---
*** Bug 43238 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I'm not sure if this should be reported on glibc or gcc, so I'll report it here
first.
When a program is compiled with -pg, and the SIGPROF signal occurs during
(perhaps certain points in) the fork () system call, it causes the program to
enter an endless loop of re-calling fork() and having the
--- Comment #3 from jason at gcc dot gnu dot org 2010-03-02 21:11 ---
I'm not seeing this with a cross-compiler.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
the code below behaves differently at -O1 and -O2.
#include stdio.h
static void swapcopy_int( int * target, char * source, int num_bytes )
{
int * to = target ;
int * from = (int *) source ;
for(int count=0; count num_bytes/sizeof(int); count++ ){
int t2 ;
int
--- Comment #4 from changpeng dot fang at amd dot com 2010-03-02 21:56
---
I have verified that the patch proposed in bug 43209 did
fix this problem. I am going to checkin the change soon.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43238
--- Comment #21 from steven at gcc dot gnu dot org 2010-03-02 21:56 ---
Prototype patch here: http://gcc.gnu.org/bugzilla/attachment.cgi?id=19755
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
1 - 100 of 120 matches
Mail list logo
