--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-03 07:04 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-03 07:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-03 07:02 ---
Subject: Bug 43237
Author: jakub
Date: Wed Mar 3 07:02:37 2010
New Revision: 157190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157190
Log:
PR debug/43237
* dwarf2out.c (add_bound_info): If
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-03 07:01 ---
Subject: Bug 43177
Author: jakub
Date: Wed Mar 3 07:01:27 2010
New Revision: 157189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157189
Log:
PR debug/43177
* var-tracking.c (loc_cmp): Don't
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-03 06:59 ---
Subject: Bug 43177
Author: jakub
Date: Wed Mar 3 06:59:09 2010
New Revision: 157188
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157188
Log:
PR debug/43177
* var-tracking.c (loc_cmp): Don't
--- Comment #4 from zsojka at seznam dot cz 2010-03-03 06:30 ---
(In reply to comment #3)
When output is uncommented, -Os shows different behaviour than -O[123] (but
still wrong):
-Os zeroes items [8] - [18]
-O[123] zeroes [9] - [18]
expected is [10] - [19]
--
http://gcc.gnu.org/bu
--- Comment #3 from zsojka at seznam dot cz 2010-03-03 06:26 ---
Created an attachment (id=20008)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20008&action=view)
minimal executable testcase
Fails when compiled with -ftree-loop-distribution at all -O[123s] levels:
$ /mnt/svn/gcc-t
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-03 03:28 ---
t.c:16: warning: comparison is always true due to limited range of data type
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following C code caused an infinite loop to be created when using -O2
optimization:
--
#include
int
main (void)
{
int x=0, y=0;
long z=0;
for (; y<1000; y++) {
if (y%7 == 0)
continue;
x = 0;
while (x<100) { /
--- Comment #3 from paolo dot carlini at oracle dot com 2010-03-03 01:16
---
Yeah, this is not matter for a PR, a *lot* of work is needed for std::regex (at
this point nobody really cares about tr1::regex).
--
paolo dot carlini at oracle dot com changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Summary|std::tr1::regex does not|std::tr1:
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-03 00:20 ---
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00227.html for the patch itself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-03 00:20 ---
Oh this change was on purpose:
r143125 | bkoz | 2009-01-06 09:41:02 -0800 (Tue, 06 Jan 2009) | 10 lines
2009-01-05 Benjamin Kosnik
* include/tr1_impl/regex: Remove unimplemented function definitions.
A simple testcase:
#include
int main() {std::tr1::regex r("^$"); }
--- CUT ---
Does not link. It did with 4.3 though.
/tmp/ccyEcV0U.o: In function `std::tr1::basic_regex >::basic_regex(char const*, unsigned int)':
t.cc:(.text._ZNSt3tr111basic_regexIcNS_12regex_traitsIcEEEC2EPKcj[_ZNSt3tr111bas
--- Comment #6 from janus at gcc dot gnu dot org 2010-03-02 23:31 ---
Here is another very similar example:
implicit none
type :: lorenz
end type lorenz
type(lorenz) :: attractor
print *,output(attractor)
contains
function output(this) result(coordinates)
class(lorenz)
--- Comment #2 from Greg dot Beeley at LightSys dot org 2010-03-02 23:07
---
Thanks - will resubmit this with the glibc folks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43239
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-02 22:14 ---
SIGPROF means this is not a GCC issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-02 22:02 ---
It is pretty obvious from doing a cross build. We get a couple sets of:
lwz 0,112(1)
rlwinm 0,0,4,0x
mtcrf 1,0
rlwinm 0,0,28,0x
beq 7,.L6
Which loads r0 from
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-02 21:58 ---
Can you post the output .s of gcc, and the .s you expect?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- 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
--- 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
the code below behaves differently at -O1 and -O2.
#include
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 t1 = *fr
--- 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
--
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 n
--- 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
---
--- 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 #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 appropriat
--- 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=20007&action=view)
Preprocessed C source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43238
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 co
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);
}
retur
--
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
--- 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=20006&action=view)
this patch causes regular bootstrap to assert
Assert message is:
/mnt/svn/gcc-trunk/libgcc/../gcc/libgcc2.c: In functi
--- 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 #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=20005&action=view)
this patch causes bootstrap with BOOT_CFLAGS="-O2 -ftree-loop-distribution" to
assert
Assert message is:
/mnt/svn/gcc-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- 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|
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 comparis
--- 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
-
--- 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 #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 #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
--
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 beha
--- 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
-
--- 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.
T
--- 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 [ D.2974
--- 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=gcc&view=rev&rev=157172
Log:
PR c++/41090
* g++.dg/ext/label13.C (C::C): xfail fo
--- 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=20004&action=view)
reduced testcase
Crashes with both
__attribute__((optimize("-ftree-loop-distribution")))
and
__attribute__((optimize("
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
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:
--- 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
--- 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 #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 #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 #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 #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 d
--- 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 #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 #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 0,6
--- 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 #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 #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 #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
Sta
--- 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
--- 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 #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 -fno-asynchronous-
--- 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 wo
--- 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 -fasynchronous-unwind-tabl
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 gccbug-t
--- 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
---
--- 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=20003&action=view)
gcc45-pr43229.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- 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 #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 #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|Removed
--- 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 #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=gcc&view=rev&rev=157166
Log:
2010-03-02 Jonathan Wakely
PR libstdc++/43230
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 t
--- 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 t
--- 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
AssignedTo|unassigned
--- 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
> http://gcc.gnu.org/ml/gcc-testresults/2010-02
--- 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 #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 dest
--- 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 #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
AssignedTo|unassign
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 "vec
--- 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 if
--- 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 #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
--
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
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
Produ
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Component|rtl-optimization|debug
Target Milestone|--- |4.5.0
http://gcc.
a03/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' '
--- 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 cur_l
--- 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.
--
http://gc
--- 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 #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 #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 #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 #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 #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
---
1 - 100 of 120 matches
Mail list logo
