--- Comment #10 from bonzini at gnu dot org 2010-03-17 06:41 ---
REG_EQUAL notes are not there to guarantee correctness. Relying on them to
avoid misoptimization is always wrong and just hides the bug.
It is a regression from 4.2.
--
bonzini at gnu dot org changed:
What
--- Comment #7 from wilson at gcc dot gnu dot org 2010-03-17 01:50 ---
Created an attachment (id=20121)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20121&action=view)
untested patch for gcc-4.4
We will also need an equivalent patch for mainline/4.5.
--
http://gcc.gnu.org/bu
--- Comment #6 from wilson at codesourcery dot com 2010-03-17 01:46 ---
Subject: Re: New: [4.4 regression] ICE in final_scan_insn,
at final.c:2604
The testcase has
>if (newCapacity > std::numeric_limits::max() / sizeof(T))
> do { *(int *)(uintptr_t)0xbbadb
--- Comment #9 from redi at gcc dot gnu dot org 2010-03-17 00:23 ---
fixed
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from redi at gcc dot gnu dot org 2010-03-17 00:23 ---
Subject: Bug 43397
Author: redi
Date: Wed Mar 17 00:22:56 2010
New Revision: 157504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157504
Log:
2010-03-17 Jonathan Wakely
PR libstdc++/43397
*
--- Comment #18 from changpeng dot fang at amd dot com 2010-03-17 00:22
---
(In reply to comment #16)
> > In this case, the loop itself is "empty" and we can replace every use of the
> > phi with "n" (exit value of the iv).
>
> I don't think that is done by remove_empty_loop anyways an
--- Comment #17 from changpeng dot fang at amd dot com 2010-03-17 00:18
---
(In reply to comment #8)
> And
>
> int foo (int b, int j)
> {
> if (b)
> {
> int i;
> for (i = 0; i<1000; ++i)
> ;
> j = b;
> }
> return j;
> }
>
With "j=b", "b" is not f
--- Comment #19 from mikpe at it dot uu dot se 2010-03-16 23:39 ---
(In reply to comment #18)
> rebuilding binutils 2.20.1 with the patch from comment #17 shows one
> regression:
>
> Running /home/doko/binutils/binutils-2.20.1/ld/testsuite/ld-arm/arm-elf.exp
> ...
> FAIL: ld-arm/unwind
--- Comment #18 from doko at ubuntu dot com 2010-03-16 23:30 ---
rebuilding binutils 2.20.1 with the patch from comment #17 shows one
regression:
Running /home/doko/binutils/binutils-2.20.1/ld/testsuite/ld-arm/arm-elf.exp ...
FAIL: ld-arm/unwind-4
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #7 from redi at gcc dot gnu dot org 2010-03-16 23:19 ---
oops, good catch :) thanks, I'll check in asap
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43397
--- Comment #6 from paolo dot carlini at oracle dot com 2010-03-16 23:17
---
Awesome. PS: remember the stupid test variable ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43397
--- Comment #5 from redi at gcc dot gnu dot org 2010-03-16 23:14 ---
Created an attachment (id=20120)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20120&action=view)
use perfect forwarding for mem_fn
patch for and extended test based on the one in this report
--
http://gcc.
--- Comment #6 from paolo dot carlini at oracle dot com 2010-03-16 23:03
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severit
--- Comment #4 from rth at gcc dot gnu dot org 2010-03-16 23:02 ---
Subject: Bug 43365
Author: rth
Date: Tue Mar 16 23:02:35 2010
New Revision: 157499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157499
Log:
PR middle-end/43365
* tree-eh.c (replace_goto_queue):
--- Comment #5 from paolo at gcc dot gnu dot org 2010-03-16 23:01 ---
Subject: Bug 43394
Author: paolo
Date: Tue Mar 16 23:01:28 2010
New Revision: 157498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157498
Log:
2010-03-16 Paolo Carlini
PR libstdc++/43394
*
--- Comment #4 from paolo dot carlini at oracle dot com 2010-03-16 22:56
---
Thanks Jon. About DR920, up to you of course... in any case, I would say, let's
deal with that separately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43397
--- Comment #4 from paolo dot carlini at oracle dot com 2010-03-16 22:40
---
For 4.5.0 we'll have __k8 and __core2. Other improvements belong to
libstdc++/34106. If you are willing to contribute to this kind of issues,
please work on that other bug, for 4.6.0. Thanks.
--
http://gcc
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-16 22:37 ---
(In reply to comment #2)
> The way I'm fixing it is adding __k8 to the list of sub targets at lines #150
> and #303 of compatibility.h. Seems good enough for 4.5.0. Further improvements
> fall under libstdc++/34106.
--- Comment #3 from redi at gcc dot gnu dot org 2010-03-16 22:29 ---
Testing a patch.
I could implement the resolution of DR920 at the same time but I think that can
wait for 4.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43397
--- Comment #2 from redi at gcc dot gnu dot org 2010-03-16 22:04 ---
mem_fn needs to support rvalue references, shouldn't be too hard to fix
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from paolo dot carlini at oracle dot com 2010-03-16 21:58
---
The way I'm fixing it is adding __k8 to the list of sub targets at lines #150
and #303 of compatibility.h. Seems good enough for 4.5.0. Further improvements
fall under libstdc++/34106.
--
http://gcc.gnu.or
--- Comment #4 from spop at gcc dot gnu dot org 2010-03-16 21:38 ---
I think it is not due to the number of parameters: as 3 is pretty low.
It might be the code that we generate for all the cases.
I will give it a look.
--
spop at gcc dot gnu dot org changed:
What|Rem
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-16 21:38
---
Jon, can you have a look to this issue?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-16 21:35
---
I'm fixing it momentarily.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #3 from zsojka at seznam dot cz 2010-03-16 21:32 ---
With various values of --param graphite-max-nb-scop-params=n, compile time
changes as follows:
n=1..3 "zero" time (<0.1s)
n=4..10 ~8.2s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43396
--- Comment #2 from sje at cup dot hp dot com 2010-03-16 21:23 ---
Using:
#define TARGET_CXX_LIBRARY_RTTI_COMDAT hook_bool_void_false
like DARWIN has, doesn't completely fix the problem. I still get the same
failure but now only with 2 typeinfo's instead of with all the typeinfos
crea
--- Comment #2 from spop at gcc dot gnu dot org 2010-03-16 21:23 ---
You may want to lower the --param graphite-max-nb-scop-params=5
the current value is at 10. Does this help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43396
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-16 21:22 ---
This is an invalid use of the naked attribute.
There are a number of places in the main function that you are using the
address of a local variable that has to go on the stack. If you look at the
documentation of th
std::function can't forward rvalue reference for pointer to member function
struct Foo
{
void operator() ( int && ) { }
void func( int && ) { }
} ;
int main()
{
Foo foo ;
// OK
std::function< void ( int && ) > f1( foo ) ;
f1(0) ;
// Error
std::function< void (
--- Comment #1 from zsojka at seznam dot cz 2010-03-16 20:39 ---
Created an attachment (id=20119)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20119&action=view)
reduced testcase (from testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c)
gcc -O1 -fgraphite-identity -c pr43396.c
Command line:
gcc -O1 -fgraphite-identity
or
gcc -Os -fgraphite-identity
(doesn't happen at -O[023])
Tested revisions:
trunk r157460 - fail (after pr43349 fix)
trunk r153685 - fail
I am not sure if this is a regression - 4.4 compiles quickly, but time report
doesn't show any information about time
[...@gnu-6 pr43379]$ cat y.c
void *foo(void)
{
lab:
return &&lab;
}
[...@gnu-6 pr43379]$ gcc -S y.c
y.c: In function foo:
y.c:4: warning: function returns address of local variable
[...@gnu-6 pr43379]$
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00704.html
--
--- Comment #2 from redi at gcc dot gnu dot org 2010-03-16 18:52 ---
(In reply to comment #0)
>
> PS: Sorry, I don't see how I could append the 't.ii' file created with the
> '-save-temps' option, that seems to be a bit too long for putting it directly
> into this form...
You can use "
I'm seeing the below warnings during a default configured x86_64-linux multilib
build. This is not normal anymore, because i686 is now (finally!) the default
subarch. I think something in the "diagnostics" should be updated...
.../trunk-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/parall
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-16 18:33
---
I can't reproduce the problem with either current 4_4-branch or mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43392
--- Comment #1 from sje at cup dot hp dot com 2010-03-16 18:09 ---
If I remove the assert and look at all the times this is triggered in my small
test case they all seem to involve builtin typeinfos created by
emit_support_tinfos. If you look at this routine there are some comments
abo
--- Comment #1 from vsoni at tilera dot com 2010-03-16 17:55 ---
Created an attachment (id=20118)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20118&action=view)
preprocessed test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43393
The integral promotion behavior of long bit-fields has changed with g++ 4.4.0
on x86_64-linux, and appears broken. Consider:
#include
#define T unsigned long
int main()
{
struct { T f : 33; } s = { 1UL << 32 };
printf("%lx %lx %lx\n", (T)s.f, (T)(s.f << 1), (T)((s.f << 1) >> 1));
struct {
When trying to compile this program
#include
class Baz {
private:
int foo, bar;
public:
Baz(int a = 0, int b = 0) : foo(a), bar(b) {}
};
int main()
{
std::vector a = {{}, {1, 2}};
}
with
g++ -std=c++0x -W -Wall -o t t.cpp
the compiler crashes with the errror message
t.cpp: I
--- Comment #17 from mikpe at it dot uu dot se 2010-03-16 17:29 ---
I decided to attack things from the binutils side. The problematic binutils
change rolls two distinct changes into one (add cantunwind table entries, merge
adjacent equivalent table entries). Disabling the "merge" part e
--- Comment #45 from dominiq at lps dot ens dot fr 2010-03-16 17:13 ---
> -Os optimizes for size current translation unit, it doesn't (nor easily can)
> guess whether or not you are linking libm.a or libm.so and whether in the
> former case using a call would be the only place that calls
--- Comment #44 from jakub at gcc dot gnu dot org 2010-03-16 16:58 ---
-Os optimizes for size current translation unit, it doesn't (nor easily can)
guess whether or not you are linking libm.a or libm.so and whether in the
former case using a call would be the only place that calls some r
--- Comment #43 from dominiq at lps dot ens dot fr 2010-03-16 16:38 ---
> log, exp? What code are you looking at now?
AFAIK all pow(a,b) boils down to exp(b*log(a)), unless special values: n,
n/2.0, n/3.0, ... for 'b' are handled in a different way.
So from what I know about coding, r
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-16 16:27 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00633.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #42 from rguenther at suse dot de 2010-03-16 16:07 ---
Subject: Re: [4.4/4.5 Regression] Weird interaction
between optimize_insn_for_speed_p and -funsafe-math-optimizations
On Tue, 16 Mar 2010, dominiq at lps dot ens dot fr wrote:
>
>
> --- Comment #41 from dominiq
--- Comment #41 from dominiq at lps dot ens dot fr 2010-03-16 16:04 ---
> > > Especially on embedded targets with soft-float the multiplication would
> > > add a significant code size penalty.
> >
> > Even in this case this would strongly of the code. It may be true if other
> > pieces
--- Comment #40 from rguenther at suse dot de 2010-03-16 15:52 ---
Subject: Re: [4.4/4.5 Regression] Weird interaction
between optimize_insn_for_speed_p and -funsafe-math-optimizations
On Tue, 16 Mar 2010, dominiq at lps dot ens dot fr wrote:
>
>
> --- Comment #39 from dominiq
--- Comment #5 from bernds at codesourcery dot com 2010-03-16 15:51 ---
I believe this is exactly the same problem as PR40615.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42500
--- Comment #39 from dominiq at lps dot ens dot fr 2010-03-16 15:49 ---
> Especially on embedded targets with soft-float the multiplication would
> add a significant code size penalty.
Even in this case this would strongly of the code. It may be true if other
pieces require log and exp.
--- Comment #3 from redi at gcc dot gnu dot org 2010-03-16 15:26 ---
But it's not necessarily a mistake, so a warning is not appropriate.
That warning would make functions such as boost::lexical_cast and boost::bind
unusable, since they have template parameters which cannot be deduced,
--- Comment #28 from amonakov at gcc dot gnu dot org 2010-03-16 15:26
---
To provide an update of the situation on 4.5 trunk:
AFAIK the situation has been generally improved with Zdenek's second commit (in
comment #23) and auto-inc-dec improvements in 4.5. However, on the particular
te
--- Comment #38 from rguenth at gcc dot gnu dot org 2010-03-16 15:26
---
Btw, the testcase has
D.1610_34 = __builtin_pow (D.1564_28, 1.5e+0);
which would expand to
D.1564_28 * sqrt (D.1564_28)
which is estimated as being larger than the call to pow. Now this isn't
exactly
true
--- Comment #37 from rguenther at suse dot de 2010-03-16 15:11 ---
Subject: Re: [4.4/4.5 Regression] Weird interaction
between optimize_insn_for_speed_p and -funsafe-math-optimizations
On Tue, 16 Mar 2010, dominiq at lps dot ens dot fr wrote:
>
>
> --- Comment #36 from dominiq
--- Comment #36 from dominiq at lps dot ens dot fr 2010-03-16 15:06 ---
> Note that the replacement for x**(n/3) * cbrt(x)**(n%3) does not seems guarded
> by any optimisation flag.
The condition is implemented further down in the code and I missed it:
if (real_identical (&c2, &c)
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-16 14:57 ---
The issue is that logical(kind=4) seems to have TYPE_PRECISION of 1 (just
guessing). But BIT_FIELD_REF extracts 32bits from
the vector, failing to truncate the result to 1 bit precision, possibly
leading to wrong-c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-16 14:54 ---
*** Bug 43252 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43390
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-16 14:54 ---
*** This bug has been marked as a duplicate of 43390 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|bootstrap |middle-end
E
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Summary|make_decl_rtl failure for |[4.5 Regression]
|C++ on AIX and HPUX |make_dec
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-03-16 14:38 ---
4.4 does not issue any such warnings and therefore this is a
regression. I am currently testing a patch.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rmanoj at umich dot edu 2010-03-16 14:37 ---
The issue is not whether the type can be deduced or how to invoke template
specialization so that the deduction is correctly performed. Rather it is about
complex template specifications where such specifications are cumber
The patch for GCC PR c/43288 causes C++ bootstrap failure on AIX and HPUX:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00468.html
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00487.html
internal compiler error: in make_decl_rtl, at varasm.c:1447
This affects libstdc++
--
Summary:
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-03-16 14:32 ---
Mine.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #3 from michael dot haubenwallner at salomon dot at 2010-03-16
14:30 ---
While the input from comment#0 indeed seems to work with gcc-4.2.4 too, this
one has the same problem with 4.2.4, 4.3.1 and 4.4.3 (each hp-gcc):
class A
{
public:
virtual ~A();
virtual vo
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-16 14:07 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #5 from hjl at gcc dot gnu dot org 2010-03-16 14:06 ---
Subject: Bug 43336
Author: hjl
Date: Tue Mar 16 14:06:40 2010
New Revision: 157483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157483
Log:
Delete temporary output files.
2010-03-16 Dmitry Gorbachev
--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-16 13:58 ---
Found the right spot in the standard (well, actually Bill Long did):
"if source-expr is specified, each allocate-object is allocated with the
dynamic type and type parameter values of source-expr; otherwise, each
all
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-16 13:57 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00669.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-16 13:55 ---
Variant which also crashes on x86-64 systems:
logical :: l1(4)
logical :: l2(4)
l1 = (/.TRUE.,.FALSE.,.TRUE.,.FALSE./)
l2 = (/.FALSE.,.TRUE.,.FALSE.,.TRUE./)
if (dot_product (l1, l2)) call abort ()
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-16 13:55 ---
Downgrading to P2 based on Josephs comments.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from doko at ubuntu dot com 2010-03-16 13:42 ---
this change doesn't make any change to the libjava test results (configured
--with-mode=thumb).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-16 11:55 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITI
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-16 11:53 ---
Works with 4.3.4, fails with trunk and 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from burnus at gcc dot gnu dot org 2010-03-16 13:38 ---
Ira, what do you think? Is this a front-end or a middle-end/vectorizer issue?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-16 11:51 ---
4.4 ICEs for me:
> g++-4.4 -S t.C -std=c++0x
t.C: In function int main():
t.C:12: internal compiler error: in tsubst_copy, at cp/pt.c:10077
Please submit a full bug report,
with preprocessed source if appropriate.
--- Comment #11 from aldot at gcc dot gnu dot org 2010-03-16 13:35 ---
(In reply to comment #10)
> Well, simply re-ordering the visibility and the weak check in
> varasm.c:default_binds_local_p_1 should do the trick.
>
It does.
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00665.html
-
--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-16 13:35 ---
The complete source code (minus comments) is:
logical :: l1(4) = (/.TRUE.,.FALSE.,.TRUE.,.FALSE./)
logical :: l2(4) = (/.FALSE.,.TRUE.,.FALSE.,.TRUE./)
if (dot_product (l1, l2)) call abort ()
l2 = .TRUE.
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-16 12:32 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-16 12:31 ---
Subject: Bug 43379
Author: rguenth
Date: Tue Mar 16 12:31:38 2010
New Revision: 157478
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157478
Log:
2010-03-16 Richard Guenther
PR middle-end/43379
Ken Werner reported for spu-unknown-elf:
"I'm getting the following message: "error: integral result type precision does
not match field size of BIT_FIELD_REF".
It looks like this could be a problem of the frontend. Please find attached the
complete output and let me know if you need further inf
--- Comment #4 from hjl dot tools at gmail dot com 2010-03-16 13:21 ---
A small tectcase;
--
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
typedef int __v4si __attribute__ ((__vector_size__ (16)));
__v4sf my_asin(__v4sf x)
{
static const __v4si g_Mask{ 0x7fff, 0x000
--- Comment #30 from rguenth at gcc dot gnu dot org 2010-03-16 13:15
---
I do have updated numbers.
4.3.[012] -O3: 57s
4.3.[34] -O[123]: 0.4s
4.4.[0123] -O[123]: 0.4s
4.5 -O0: 1.6s
4.5 -O[123]: 50s (*sigh*)
that makes it fixed on the release branches and a 4.5 regression only.
--
F2003 supported
ALLOCATE( A, SOURCE=B)
where the dynamic type of B determined the dynamic type of A plus where the
values where copied from B to A.
Fortran 2008 now also offers MOLD= where only the type is used, but no data is
copied.
Fortran 2008 draft FDIS: ftp://ftp.nag.co.uk/sc22wg5/N1801-N
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-16 11:49 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|glibc regex testsuite |[4.5 Regression] glibc regex
|failures
--- Comment #6 from aldyh at gcc dot gnu dot org 2010-03-16 11:36 ---
Fixed here:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00560.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from aldyh at gcc dot gnu dot org 2010-03-16 11:34 ---
Subject: Bug 42917
Author: aldyh
Date: Tue Mar 16 11:33:45 2010
New Revision: 157477
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157477
Log:
PR tree-optimization/42917
* lambda-code.c (remov
--- Comment #4 from bernds at codesourcery dot com 2010-03-16 10:56 ---
Created an attachment (id=20117)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20117&action=view)
A patch to fix it.
The andsi3 expander has code to do the right thing, but
avoid_expensive_constant prevents it
--- Comment #19 from dodji at gcc dot gnu dot org 2010-03-16 10:55 ---
FWIW, I have tested the patch posted for PR c++/43206 and it fixes this one
too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-16 10:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-16 10:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #11 from jakub at gcc dot gnu dot org 2010-03-16 10:51 ---
Subject: Bug 43051
Author: jakub
Date: Tue Mar 16 10:50:42 2010
New Revision: 157476
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157476
Log:
PR debug/43051
PR debug/43092
* cselib.c
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-16 10:51 ---
Subject: Bug 43092
Author: jakub
Date: Tue Mar 16 10:50:42 2010
New Revision: 157476
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157476
Log:
PR debug/43051
PR debug/43092
* cselib.c
--- Comment #3 from paolo dot carlini at oracle dot com 2010-03-16 10:27
---
Thanks Chris.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-16 10:14 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #3 from russell at strong dot id dot au 2010-03-16 09:56
---
Created an attachment (id=20116)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20116&action=view)
environment sourced by build script
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43387
--- Comment #2 from russell at strong dot id dot au 2010-03-16 09:55
---
Created an attachment (id=20115)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20115&action=view)
build script
This is the script I used to build gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43387
--- Comment #1 from russell at strong dot id dot au 2010-03-16 09:54
---
Created an attachment (id=20114)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20114&action=view)
main.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43387
[russ...@silultt004 gcc-bug]$ arm-elf-gcc -v -c main.i
Using built-in specs.
Target: arm-elf
Configured with: /home/russell/toolchain/build_dir/gcc-4.4.3/configure
--prefix=/home/russell/toolchain --target=arm-elf --with-cpu=arm7tdmi-s
--enable-interwork --enable-thumb --enable-multilib --with-floa
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-16 09:22 ---
Fixed at revision 157467, hence closing. Thanks for the patch.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
1 - 100 of 106 matches
Mail list logo
