--- Comment #8 from tkoenig at gcc dot gnu dot org 2010-06-04 07:06 ---
After the discussion, I think we can close this as WONTFIX.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-06-04 07:15 ---
Can we close this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40452
--- Comment #5 from steven at gcc dot gnu dot org 2010-06-04 07:45 ---
AFAIU, you can't randomly change signed to unsigned, due to different overflow
semantics, which is why IVOPTS doesn't make this change itself. Imagine you
enter the loop with count = 0, and with a second counter hidde
--- Comment #30 from jakub at gcc dot gnu dot org 2010-06-04 09:02 ---
Created an attachment (id=20833)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20833&action=view)
rh598310.i.bz2
Another testcase from wine,
./cc1 -m32 -fPIC -fno-strict-aliasing -g -O2 rh598310.i -quiet
takes
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-04 09:08 ---
If the result of the conversion is only used in an exit equality test against a
constant it can be dropped. This could also happen in a following
forwprop run which is our single tree-combiner (though that currently
--- Comment #31 from jakub at gcc dot gnu dot org 2010-06-04 09:24 ---
Created an attachment (id=20834)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20834&action=view)
limit-depth.patch
Quick patch that brings the time down to 1 minute 15 sec.
>From the callgrind dump on this te
--- Comment #32 from jakub at gcc dot gnu dot org 2010-06-04 09:30 ---
Created an attachment (id=20835)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20835&action=view)
hack
Hack that shows that the maximum depth is 3 even for the found == NULL cases.
Alex tells me on IRC he has t
--- Comment #33 from aoliva at gcc dot gnu dot org 2010-06-04 09:51 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned a
--- Comment #2 from doko at ubuntu dot com 2010-06-04 09:51 ---
having an objdump which supports both the host and the target works around this
issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
--- Comment #4 from doko at ubuntu dot com 2010-06-04 09:53 ---
this is fixed on the trunk
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43759
--- Comment #34 from aoliva at gcc dot gnu dot org 2010-06-04 10:03 ---
Created an attachment (id=20836)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20836&action=view)
Patch that fixes the bug and verifies recursion is bounded as expected
This patch (except for comments and Chan
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-04 11:00 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-04 11:00 ---
Subject: Bug 41584
Author: rguenth
Date: Fri Jun 4 11:00:09 2010
New Revision: 160258
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160258
Log:
2010-06-04 Richard Guenther
PR lto/41584
--- Comment #35 from rguenth at gcc dot gnu dot org 2010-06-04 11:03
---
Created an attachment (id=20837)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20837&action=view)
bnc611650
Another testcase from open-office this time, on i?86-linux only.
$> time g++ -c -g -Os -fomit-fra
--- Comment #36 from jakub at gcc dot gnu dot org 2010-06-04 11:15 ---
With Alex' patch with checking guarded with #ifdef ENABLE_CHECKING (currently
bootstrapping/regtesting that) I see on x86_64 on the trunk:
time ./cc1plus -m32 -quiet -g -Os -fomit-frame-pointer bug-611650_analysis.ii
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-04 12:03 ---
More complete testcase:
// PR c++/44412
// { dg-do compile }
// { dg-options "-Wunused" }
struct S
{
static const int a = 3;
static int b;
int c;
};
const int S::a;
int S::b = 4;
int
f1 ()
{
S s;
return s
This code:
#include
int foo(const std::string &a, const std::string &b) { return a.compare(b); }
compiles to code like this on x86-64:
[...]
subq%rdx, %r8
movl$2147483647, %eax
cmpq$2147483647, %r8
jg .L2
movl$-2147483648, %eax
--- Comment #6 from burnus at gcc dot gnu dot org 2010-06-04 12:22 ---
Yes, we can CLOSE the bug as FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
When I recently needed to use htab_* functions from libiberty's hashtab.h, I
found
that they are completely undocumented: the comments in the header aren't enough
to use them, so I had to look at both the implementation and other uses to
figure
things out.
--
Summary: hashtab.h functi
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-04 12:32 ---
libiberty has documentation in source libiberty/hashtab.c.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
The recent introduction of this patch
2010-05-29 Mike Stump
* configure.ac: Add multilib support for gmp. Proper -I and -L
flags for gmp are added.
broke bootstrap on i386-pc-solaris2.11 and almost certainly at least all
Solaris 2
platforms with a static libgmp:
/bin/ksh ../
--- Comment #7 from bernds at gcc dot gnu dot org 2010-06-04 12:44 ---
Subject: Bug 42502
Author: bernds
Date: Fri Jun 4 12:44:01 2010
New Revision: 160260
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160260
Log:
PR rtl-optimization/39871
PR rtl-optimization/4
--- Comment #6 from bernds at gcc dot gnu dot org 2010-06-04 12:44 ---
Subject: Bug 42500
Author: bernds
Date: Fri Jun 4 12:44:01 2010
New Revision: 160260
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160260
Log:
PR rtl-optimization/39871
PR rtl-optimization/4
--- Comment #24 from bernds at gcc dot gnu dot org 2010-06-04 12:44 ---
Subject: Bug 39871
Author: bernds
Date: Fri Jun 4 12:44:01 2010
New Revision: 160260
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160260
Log:
PR rtl-optimization/39871
PR rtl-optimization/
--- Comment #7 from bernds at gcc dot gnu dot org 2010-06-04 12:44 ---
Subject: Bug 40615
Author: bernds
Date: Fri Jun 4 12:44:01 2010
New Revision: 160260
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160260
Log:
PR rtl-optimization/39871
PR rtl-optimization/4
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-06-04 12:45
---
Subject: Bug 41371
Author: rguenth
Date: Fri Jun 4 12:44:41 2010
New Revision: 160261
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160261
Log:
2010-06-04 Richard Guenther
Backport from mainl
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415
--- Comment #16 from ro at gcc dot gnu dot org 2010-06-04 12:53 ---
Confirmed: fails for 32-bit and Solaris 10+, unsupported on Solaris 8 and 9.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from ro at gcc dot gnu dot org 2010-06-04 12:58 ---
This is not proper documentation: most part of libiberty use comments which
can be extracted and put into the .texi files, while hashtab.c does not.
--
ro at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-04 13:08 ---
(In reply to comment #1)
> Because our tree reassoc doesn't re-associate them.
>
The tree reassoc pass makes it slower:
[...@gnu-6 44382]$ cat x.i
extern int a, b, c, d, e, f;
void
foo ()
{
a = (b * c) * (d * e)
--
fabien at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fabien at gcc dot gnu dot
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-04 13:21 ---
Yes, reassoc linearizes instead of building a tree (saves one (or was it two?)
registers at best).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
On Linux/x86-64, revision 160243 failed to
build 447.dealII in SPEC CPU 2006 at -O2 and -O3:
g++ -c -o block_vector.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS
-Ddeal_II_dimension=3 -O3 -ffast-math -funroll-loops -DSPEC_CPU_LP64
block_vector.cc
In file included from include/l
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-04 13:26 ---
It may be caused by revision 160231:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00144.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-04 13:42
---
I do not have access to those benchmarks. Whoever has, should check that
ptrdiff_t is used properly, either after including , then it can be
used both qualified with std:: and unqualified together with v3, or q
make check-target-libstdc++-v3 fails because ptrdiff_t is undefined.
std::ptrdiff_t works.
Maybe this bug is related to the Linux system run on. I have openSuse 11.1
running.
configure --enable-languages=c,c++ --program-suffix=-rep
--prefix=$HOME/gcc/install_trunk_1
In file included from
/home/
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-04 13:49
---
I can't reproduce this. I booted and tested many times on various linux systems
and HJ already reported many succesfull testresults since. Please remove
everything from the build dir, gave everything fresh and
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-04 13:56 ---
(In reply to comment #3)
> Yes, reassoc linearizes instead of building a tree (saves one (or was it two?)
> registers at best).
>
Should we always build a tree? It may increase register pressure.
--
http://gcc
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-04 14:12 ---
Created an attachment (id=20838)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20838&action=view)
gcc46-pr44412.patch
Untested patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44412
--- Comment #2 from singler at kit dot edu 2010-06-04 14:16 ---
I had cleaned the builddir already.
Adding
#include
solves the problem.
The crucial file seems to be
lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/stddef.h
Only if it is (indirectly) included, ptrdiff_t is defined i
--- Comment #3 from singler at kit dot edu 2010-06-04 14:19 ---
Bug 44417 is very likely to have the same cause, but here, we can reproduce it
more easily, using the testsuite.
*** This bug has been marked as a duplicate of 44417 ***
--
singler at kit dot edu changed:
Wh
--- Comment #3 from singler at kit dot edu 2010-06-04 14:19 ---
*** Bug 44416 has been marked as a duplicate of this bug. ***
--
singler at kit dot edu changed:
What|Removed |Added
---
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-04 14:23
---
To be clear: does a normal 'make check' (either from the root of the build dir
or from inside the library build dir) work? Because it works here and fo
everybody else on the testresult mailing list, also for pe
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-04 14:28
---
Hey, 44416 is *not* a duplicate! Please re-open it immediately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-04 14:29
---
Not a duplicate, another issue.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #49 from ro at gcc dot gnu dot org 2010-06-04 14:33 ---
Subject: Bug 42776
Author: ro
Date: Fri Jun 4 14:32:19 2010
New Revision: 160269
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160269
Log:
Backport from mainline:
2010-04-27 Dave Korn
--- Comment #5 from hjl dot tools at gmail dot com 2010-06-04 14:40 ---
tree-ssa-reassoc.c has
2. Left linearization of the expression trees, so that (A+B)+(C+D)
becomes (((A+B)+C)+D), which is easier for us to rewrite later.
During linearization, we place the operands of th
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-04 14:52
---
Note that cxxabi.h already includes and at that line 371 uses
ptrdiff_t unqualified, thus everything is fine. I suspect you simply forgot to
update your compiler, because the current library does not work with
--- Comment #7 from paolo dot carlini at oracle dot com 2010-06-04 14:55
---
Closing.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Sta
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-06-04 14:56
---
I don't have the SPEC benchmarks either, but probably deal.II uses ptrdiff_t
unqualified, without explicitly including either or
http://www.dealii.org/developer/doxygen/deal.II/block__vector_8h.html
--
htt
--- Comment #6 from jwakely dot gcc at gmail dot com 2010-06-04 15:00
---
certainly true for an older version
http://ganymed.iwr.uni-heidelberg.de/~deal/5.2.0/doxygen/deal.II/block__vector_8h.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-04 15:16 ---
Subject: Bug 25880
Author: manu
Date: Fri Jun 4 15:15:38 2010
New Revision: 160274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160274
Log:
2010-06-04 Manuel López-Ibáñez
PR c/25880
*
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-04
15:21 ---
Subject: Re: lto-elf.c fails to compile on Solaris
> --- Comment #11 from rguenth at gcc dot gnu dot org 2010-06-03 13:47
> ---
> The problem seems to have vanished, so eventually the fix can be
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-04 15:21 ---
The infrastructure to enable this has been added in GCC 4.6 and some
diagnostics are already making use of it, in particular the one reported here.
So I consider this FIXED.
If anyone finds particular diagnostics that
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-04 15:50 ---
I am going to close this as WONTFIX for the following reasons:
* We do not want this because:
a) We have too many options.
b) These options would be of very limited and temporary use but we will have
to support the
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-04 15:56 ---
Hi Jay,
-Wuninitialized is quite unreliable in old compilers and also we do not know
what patches Apple applies to its copy of GCC. This is why -Werror is not used
in the first stage of building GCC. We do not see thes
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-04 15:59 ---
Who is in charge of GCC infrastructure (wiki, mailing lists, bugzilla)?
I am afraid there is no one, so this is not going to be fixed soon. Meanwhile
use Google.
--
manu at gcc dot gnu dot org changed:
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-04 16:03 ---
As mentioned in the comments above, there is an easy way to achieve this
already without needing to make the compiler more complex and slower. So I will
close this as WONTFIX.
--
manu at gcc dot gnu dot org changed:
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-04 16:11 ---
Please fellow GCC maintainers, after checking that a bug is indeed a bug,
please set the status to NEW. What more than 1000 unconfirmed reports!
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jay dot krell at cornell dot edu 2010-06-04 16:20
---
Then don't use when I -disable-bootstrap..
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-04 16:22 ---
(In reply to comment #5)
> Then don't use when I -disable-bootstrap..
>
Do you mean that -Werror is used when you disable-bootstrap? If so, I think
that is a bug. Or you mean to not use warnings? I think that would be
--- Comment #7 from jay dot krell at cornell dot edu 2010-06-04 16:30
---
I mean -Wuninitialized.
-Werror is already omitted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
--- Comment #7 from bangerth at gmail dot com 2010-06-04 16:36 ---
As the author of the benchmark I can confirm that we apparently forgot
to include the proper header file. So you can call it a defect in 447.dealII.
The question is how to deal with this, of course.
W.
--
bangerth a
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-04 16:36 ---
-Wuninitialized is enabled by -Wall (or perhaps -Wextra), not explicitly. I
think we should not enable any warnings when building with the host compiler,
unless the user requests them. It is probably faster and would pr
--- Comment #7 from maksim at kde dot org 2010-06-04 16:38 ---
Created an attachment (id=20839)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20839&action=view)
Preprocessed source
Actually, never mind that --- got it on x86-64 from an another KDEer (credit to
Alex Fiestas).
--
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-04 16:40 ---
(In reply to comment #7)
> As the author of the benchmark I can confirm that we apparently forgot
> to include the proper header file. So you can call it a defect in 447.dealII.
> The question is how to deal with thi
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-06-04 16:42 ---
Thanks for a nice testcase. I've been looking at this briefly today
and so far I am inclined to say that this is not SRA's fault. First,
I have identified the function that is miscompiled
(boost::detail::function::b
--- Comment #38 from jakub at gcc dot gnu dot org 2010-06-04 16:42 ---
Subject: Bug 41371
Author: jakub
Date: Fri Jun 4 16:42:27 2010
New Revision: 160280
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160280
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pd
--- Comment #10 from jakub at gcc dot gnu dot org 2010-06-04 16:44 ---
Subject: Bug 44013
Author: jakub
Date: Fri Jun 4 16:43:42 2010
New Revision: 160281
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160281
Log:
PR rtl-optimization/44013
* sched-deps.c (add_de
--- Comment #39 from jakub at gcc dot gnu dot org 2010-06-04 16:48 ---
Subject: Bug 41371
Author: jakub
Date: Fri Jun 4 16:47:41 2010
New Revision: 160282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160282
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pd
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-04 16:52 ---
Seems like a reasonable suggestion for improvement. I don't know if anyone
relies on the current behaviour, so it might not get changed.
--
redi at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from zadeck at naturalbridge dot com 2010-06-04 17:18
---
I would just like to say that i think that target_reinit should be removed.
It is nothing but trouble. We tried to use it on our private port and it was
very slow and most of the time ended up crashing. Furth
--- Comment #17 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
17:24 ---
Created an attachment (id=20840)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20840&action=view)
Minimal test with -O1
I've managed to shrink this down to a 44-line testcase that fails with the
op
--- Comment #18 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
17:24 ---
Created an attachment (id=20841)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20841&action=view)
Minimal test objdump with -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
Since revision 160215 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00263.html ) one gets the
following failures on powerpc-apple-darwin9:
FAIL: gcc.target/powerpc/recip-1.c scan-assembler-times frsqrte 2
FAIL: gcc.target/powerpc/recip-1.c scan-assembler-times fmsub 2
FAIL: gcc.target/powe
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-04 17:48 ---
First off this is not a regression; I ran into this issue back a couple of
years ago with libjava requiring libgmp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-04 17:49 ---
See PR 39747.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-04 17:52 ---
Created an attachment (id=20842)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20842&action=view)
assembly for recip-1.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-04 17:52 ---
Created an attachment (id=20843)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20843&action=view)
assembly for recip-2.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-04 17:52 ---
Created an attachment (id=20844)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20844&action=view)
assembly for recip-3.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
--- Comment #3 from jyasskin at gmail dot com 2010-06-04 17:56 ---
Thanks for the prompt answers. I understand that you've picked the right
direction for gcc as a whole, even though it'll inconvenience me temporarily.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44244
--- Comment #39 from dominiq at lps dot ens dot fr 2010-06-04 18:25 ---
I confirm that the failures for libjava reported in comment #33 were due to
some misconfiguration.
With the patches in http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762 and
http://gcc.gnu.org/bugzilla/attachment.cg
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-04 18:43 ---
Subject: Bug 44362
Author: jakub
Date: Fri Jun 4 18:42:42 2010
New Revision: 160289
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160289
Log:
PR c++/44362
* call.c (build_conditional_expr): I
--- Comment #40 from iains at gcc dot gnu dot org 2010-06-04 18:45 ---
(In reply to comment #39)
> I confirm that the failures for libjava reported in comment #33 were due to
> some misconfiguration.
> With the patches in http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762 and
> http://g
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-04 18:46 ---
Subject: Bug 44412
Author: jakub
Date: Fri Jun 4 18:45:07 2010
New Revision: 160290
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160290
Log:
PR c++/44412
* typeck.c (build_class_member_acces
--- Comment #8 from singler at gcc dot gnu dot org 2010-06-04 18:51 ---
I can't help it, "make check" in the libstdc++-v3 directory still does not work
for me, even after reconfiguring and recompiling everything from scratch, using
vanilla rev 160275.
Let's have a look at attached testsu
--- Comment #9 from singler at gcc dot gnu dot org 2010-06-04 18:51 ---
Created an attachment (id=20845)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20845&action=view)
Failing test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-04 18:55
---
Something is broken in your system, I also tested on an Open Suse 11.1, to be
sure, and everything works fine. Remove everything, fetch again the entire gcc
mainline and try again.
--
paolo dot carlini at
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-04 19:34 ---
After the recent var-tracking.c PR41371 changes this is down to 67 seconds.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #25 from dodji at gcc dot gnu dot org 2010-06-04 19:36 ---
Created an attachment (id=20846)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20846&action=view)
Fixes all regressions of C FE's testsuite
This update fixes all the regressions I have noticed in the test suite
--- Comment #13 from kristiaan dot lenaerts at gmail dot com 2010-06-04
20:10 ---
Created an attachment (id=20847)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20847&action=view)
Updated fix for improper PCH dependency tracking
I got hit by this bug a few weeks ago when working
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-04 20:15 ---
Created an attachment (id=20848)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20848&action=view)
The src.alt for 447.dealII
This works for me. Can someone try it?
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #26 from manu at gcc dot gnu dot org 2010-06-04 20:22 ---
(In reply to comment #25)
>
> $ ./cc1 -quiet test.c
> While expanding macro OPERATE at test.c:2:8
> While expanding macro SHIFTL at test.c:5:14
> While expanding macro MULT2 at test.c:8:3
> test.c: In function 'g':
>
When building gcc for e500v2:
--target=powerpc-unknown-linux-gnuspe --enable-e500_double
The build stops with an ICE:
/tmp/edmar/build_jobs/Xe500v2/obj_gccsys/./gcc/xgcc
-B/tmp/edmar/build_jobs/Xe500v2/obj_gccsys/./gcc/
-B/tmp/edmar/build_jobs/installs_final/gnu-gcc-4.5-binutils-2.19-eglibc-2.9-X
This is a follow-up to http://gcc.gnu.org/ml/gcc-help/2010-06/msg5.html :
Consider the following case:
uint32_t foo, bar;
...
foo = bar << 20;
Of course, this operation can overflow and warning about this probably does not
make sense as the programmer should be aware of this case. Howe
--- Comment #9 from tkoenig at gcc dot gnu dot org 2010-06-04 22:31 ---
I have thought a little bit about this, and the problem is
a bit daunting ;-) Of course, this is at least partly because
my experience with the scalarizer is close to non-existant, but you
have to learn sometime.
I
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-06-04 22:39 ---
The particular test case from comment #1 is now fixed.
Here's one that still fails:
subroutine foo(a, b)
real :: a(40), b(40)
a(1:20:3) = a(1:19:3)
a(1:19:3) = a(1:19:3)
end subroutine foo
g...@linux-fd1f:/t
--- Comment #2 from changpeng dot fang at amd dot com 2010-06-04 23:15
---
Interesting! What's the difference between 17 and 18?
int main()
{
double i;
for(i=0; i<18; i+=1); /* gcc -O3, empty loop not removed */
}
int main()
{
double i;
for(i=0; i<1
--- Comment #3 from changpeng dot fang at amd dot com 2010-06-04 23:29
---
(In reply to comment #2)
> Interesting! What's the difference between 17 and 18?
>
> int main()
> {
> double i;
> for(i=0; i<18; i+=1); /* gcc -O3, empty loop not removed */
> }
The funny thing
1 - 100 of 108 matches
Mail list logo
