--- Comment #10 from paul dot richard dot thomas at gmail dot com
2010-06-05 06:55 ---
Subject: Re: inline matmul for small matrix sizes
Dear Thomas,
> The preferred way would therefore be to state the rank 2 * rank 2 problem as
>
> do i=1,m
> do j=1,n
> c(i,j) = sum(a(i
--- Comment #9 from andris dot pavenis at iki dot fi 2010-06-05 06:38
---
Did some tests
Using my own patches (for libstdc++-v3 only error_constants.h and
autoconf/automake related stuff left over from earlier native builds of gcc for
DJGPP) build of Linux (x86_64, Fedora 12) to DJGPP
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.5.0 (GCC)
Using C++, shifting unsigned integers
uint64_t x;
x=x>>65; //produces same resu
--- Comment #2 from hjl at gcc dot gnu dot org 2010-06-05 00:49 ---
Subject: Bug 44421
Author: hjl
Date: Sat Jun 5 00:48:49 2010
New Revision: 160305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160305
Log:
Update df_lr_bb_local_compute for embedded bitmaps.
2010-06-04 H.J.
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-05 00:39 ---
It affects targets which define EH_USES:
ia64/ia64.h:#define EH_USES(REGNO) ia64_eh_uses (REGNO)
m32c/m32c.h:#define EH_USES(REGNO) 0 /* FIXME */
mips/mips.h:#define EH_USES(N) mips_eh_uses (N)
--
hjl dot tool
On Linux/ia64, revision 160300 gave:
../../src-trunk/gcc/df-problems.c: In function 'df_lr_bb_local_compute':
../../src-trunk/gcc/df-problems.c:906: error: incompatible type for argument 1
of 'bitmap_set_bit'
../../src-trunk/gcc/df-problems.c: In function 'df_byte_lr_bb_local_compute':
../../src-t
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-06-05 00:05 ---
>Interesting! What's the difference between 17 and 18?
Exact representation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43529
--- Comment #4 from eblot dot ml at gmail dot com 2010-06-04 23:41 ---
(fixing up description)
--
eblot dot ml at gmail dot com changed:
What|Removed |Added
Su
--- 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
--- 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 #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 #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
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
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
--- 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':
>
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 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 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 #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 #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 #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 #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 #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 #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 #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 #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: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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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: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 #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 #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 #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 #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 #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 #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
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 #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
--- 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
---
--
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
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
--- 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
--
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 #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)
--- 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 #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
-
--
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 #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
--- 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 #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 #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 #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
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 #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
--
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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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
1 - 100 of 108 matches
Mail list logo
