--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org
--- Comment #2 from bonzini at gnu dot org 2006-04-12 07:30 ---
And the funny part is, it is again Dale's patch that causes the failure.
I'm more and more inclined to revert that part, but it may be a latent bug as
in the AIX case (note: David Edelsohn decided to "
--- Comment #9 from bonzini at gnu dot org 2006-04-18 08:13 ---
I'm reverting the PR19653 regclass.c patch for now. Joern of course if you
want to post your patch for testing, it'll help reinstating the patch in 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
--- Comment #7 from bonzini at gnu dot org 2006-04-18 13:25 ---
patch committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from bonzini at gnu dot org 2006-04-18 13:26 ---
bug is latent again :-)
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from bonzini at gnu dot org 2006-04-18 13:47 ---
Seems similar to PR24230, but cannot be fixed really in the same way.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2006-04-18 13:55 ---
richi: if bD.1520 does not have a default def because it is unused, your fix
makes sense. Can you confirm that it is "b" and not "c" that does not have a
default def, i.e. that "c" does ha
--- Comment #6 from bonzini at gnu dot org 2006-04-18 14:07 ---
pinskia: You're right in some sense but, shudder, this will make things
slw.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
--- Comment #15 from bonzini at gnu dot org 2006-04-18 14:12 ---
running a 4.1 bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
--- Comment #8 from bonzini at gnu dot org 2006-04-18 14:15 ---
Mark, I don't believe there is any chance that it be fixed in 4.0/4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
--- Comment #7 from bonzini at gnu dot org 2006-04-18 14:16 ---
Caused by removing ADDRESSOF. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983
--- Comment #18 from bonzini at gnu dot org 2006-04-18 14:23 ---
patch committed to 4.1 too.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from bonzini at gnu dot org 2006-04-18 14:29 ---
The mem is for a
(const_vector:V4SF [
(const_double:SF -NaN [-NaN])
(const_double:SF -NaN [-NaN])
(const_double:SF -NaN [-NaN])
(const_double:SF -NaN [-NaN])
])
--
http
--- Comment #10 from bonzini at gnu dot org 2006-04-18 14:39 ---
It's probably two different bugs, since the 4.1 bug is in loop.c. We need to
add a can_assign_to_reg_p call before creating a movable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
--- Comment #11 from bonzini at gnu dot org 2006-04-18 15:20 ---
... but then anyway the bug pops up in reload. So it is definitely the same
bug as PR24230, and here is a modified version of the PR24230 testcase:
/* Compile with -O2 -maltivec */
#define REGLIST
--- Comment #4 from bonzini at gnu dot org 2006-04-18 15:27 ---
And is the precision only encoded in FIELD_DECLs, for the C front-end as well?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2006-04-18 16:12 ---
Without getting in the merit of the bug, let me point out that GCC is *not*
free to make hard errors at its own will. What is an error and what isn't is
regulated by the standard, and GCC aims at adhering to the sta
--- Comment #10 from bonzini at gnu dot org 2006-04-18 16:18 ---
No, except in the unlikely case that the fix is hard to backport to 4.0.x.
Backports to older release branches (in this case 4.0.x) are evaluated on a
case-by-case basis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #8 from bonzini at gnu dot org 2006-04-18 16:22 ---
Richard, Roger's patch for VIEW_CONVERT_EXPR folding hit mainline now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26069
--- Comment #11 from bonzini at gnu dot org 2006-04-24 11:44 ---
patch applied to 4.2, 4.1 still not working
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2006-04-25 06:37 ---
Sure. The code meant to do so using trunc_int_for_mode, but it does not work
because constop is unsigned. The trunc_int_for_mode was introduced in
http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01397.html to cure a similar
--- Comment #11 from bonzini at gnu dot org 2006-04-26 07:13 ---
unassigning since David and Andrew's patch works, but mine does not.
My patch BTW could be a minor cleanup, but it is not even necessary because
GEN_INT (trunc_int_for_mode (...)) does not drop sign bits (it
--- Comment #3 from bonzini at gnu dot org 2006-05-22 07:24 ---
Hi richi, may I ask why I was added to the CC? Did I cause this bug? :-P
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
--- Comment #1 from bonzini at gnu dot org 2006-05-25 08:21 ---
Testing a patch.
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from bonzini at gnu dot org 2006-05-25 08:29 ---
Created an attachment (id=11510)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11510&action=view)
prototype patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27674
--- Comment #4 from bonzini at gnu dot org 2006-05-25 08:45 ---
Created an attachment (id=11511)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11511&action=view)
patch to document the option
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25453
--- Comment #6 from bonzini at gnu dot org 2006-05-26 07:46 ---
There are indeed differences in the generated code.
aj_f_times2 is equal without and with the patch.
aj_d_times2 has this (left = old, right = patched):
movsd %xmm0, -40(%rbp) | movsd %xmm0, -32
--- Comment #7 from bonzini at gnu dot org 2006-05-29 07:24 ---
The problem is that regstack is wrong when it comes to handling
COMPLEX_FLOAT_MODEs.
To handle clobbers, it calls move_nan_to_stack_reg twice on the same insn. But
the second call does *not* add a new insn, so we get only
--- Comment #8 from bonzini at gnu dot org 2006-05-29 09:38 ---
Created an attachment (id=11527)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11527&action=view)
patch to fix the bug
I would appreciate testing this patch on x86_64, also because it touches some
squeaky co
--- Comment #40 from bonzini at gnu dot org 2006-05-30 06:20 ---
We're on par with 4.0, we can close this now. The memory hog bug (27004) is
still open.
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #6 from bonzini at gnu dot org 2006-06-01 12:33 ---
documentation committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from bonzini at gnu dot org 2006-06-05 07:10 ---
This was fixed recently.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from bonzini at gnu dot org 2006-06-05 07:23 ---
Created an attachment (id=11594)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11594&action=view)
a different attempt
I don't like this patch, as I think it is based on too many assumptions. The
idea
--- Comment #5 from bonzini at gnu dot org 2006-06-05 10:20 ---
Created an attachment (id=11596)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11596&action=view)
patch to test
can anybody test this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
--- Comment #5 from bonzini at gnu dot org 2006-06-05 17:17 ---
thanks, committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from bonzini at gnu dot org 2006-06-05 17:33 ---
Created an attachment (id=11597)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11597&action=view)
and a third one
If this one works, I'd very much prefer it to the one I posted this morning.
It fixes
--- Comment #14 from bonzini at gnu dot org 2006-06-06 12:10 ---
Patch pr27390-more.patch was bootstrapped/regtested and the approach was
confirmed to be ok by Roger.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
--- Comment #7 from bonzini at gnu dot org 2006-06-07 12:01 ---
Created an attachment (id=11623)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11623&action=view)
updated libdecnumber configure script
try this. don't forget to not include fortran because it includes s
--- Comment #16 from bonzini at gnu dot org 2006-06-07 12:08 ---
fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from bonzini at gnu dot org 2006-06-08 06:10 ---
Created an attachment (id=11630)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11630&action=view)
a supposedly correct patch
No, the patch was wrong. Also the original proposed patch was right that some
m
--- Comment #10 from bonzini at gnu dot org 2006-06-08 06:20 ---
Created an attachment (id=11631)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11631&action=view)
really a different patch
Sorry, I attached the wrong patch again.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #11 from bonzini at gnu dot org 2006-06-08 08:36 ---
I would note, however, that Pentium Pro also means Pentium 2/3/M, Core, etc.
In practice every Intel chip after the Pentium Pro, except the P4 and Nocona,
is based on that pipeline.
--
http://gcc.gnu.org/bugzilla
--- Comment #10 from bonzini at gnu dot org 2006-06-08 12:08 ---
Reduced testcase:
long foo(long zz)
{
return zz * 15238614669586151335;
}
takes "ridiculously long" with -O2 -mdisable-fpregs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
--- Comment #11 from bonzini at gnu dot org 2006-06-08 12:24 ---
OUCH! The number is stored as a unsigned int in the cache, which means that
numbers > 2^32 never hit the cache!
Besides that, it's wise to enlarge the cache for 64-bit hosts, because there
every EXACT_DIV_EXPR w
--- Comment #12 from bonzini at gnu dot org 2006-06-08 12:26 ---
Created an attachment (id=11634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11634&action=view)
proposed patch
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #14 from bonzini at gnu dot org 2006-06-08 15:37 ---
Well, it shouldn't. My guess could be that we are hitting the case where the
logic is flawed. The we fill the cache with the algorithm for say 0x10085
(but then we only write 0x84 in the cache), and then use i
--- Comment #5 from bonzini at gnu dot org 2006-06-09 08:15 ---
I'll give it a shot. If combine could, well, combine the two instructions, it
would be quite easy to make a patch, and it would remove some most hackish
aspects of the Altivec implemention.
--
http://gcc.gn
--- Comment #19 from bonzini at gnu dot org 2006-06-13 13:06 ---
Fixed, but we may want the patch on 4.0 too.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2006-06-15 06:33 ---
I agree it is a packaging issue, but we can work around it and it can be useful
for other front ends as well. Taking the bug.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2006-06-15 06:35 ---
Also, fixing this PR would allow us to ship Objective-C++ in the objc tarball.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27063
--- Comment #12 from bonzini at gnu dot org 2006-06-15 07:21 ---
Created an attachment (id=11670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11670&action=view)
updated configure script for libdecnumber
Gerald, here it is. Again, don't forget to disable fortran.
--- Comment #6 from bonzini at gnu dot org 2006-07-03 07:58 ---
patch committed, should be ok.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from bonzini at gnu dot org 2006-07-04 17:03 ---
I don't know where I got the idea that you can do
calculate_dominance_info (CDI_DOMINATORS | CDI_POST_DOMINATORS);
instead of
calculate_dominance_info (CDI_DOMINATORS);
calculate_dominance
--- Comment #7 from bonzini at gnu dot org 2006-07-05 06:49 ---
patch committed to 4.1 branch and mainline (where it was latent)
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #13 from bonzini at gnu dot org 2008-11-20 08:48 ---
I agree with Steven that the bug title does not make sense. It is the same as
complaining that IRA has a regression because it disables regmove.
OTOH, this *is* a regression and the bug should stay open. For example, it
--- Comment #7 from bonzini at gnu dot org 2008-11-22 10:15 ---
Subject: Re: "if (i == n) ++i;" or "i += i == n;"?
> The form of the code before CSE is caught in noce_try_addcc. The second form
> obviously not (because we don't know that the value of
--- Comment #8 from bonzini at gnu dot org 2008-11-22 16:00 ---
The problem was that without -fprofile-generate the time spent there was
basically zero. Since the profiling code is building a MST of the control-flow
graph, it should produce absolutely no PRE opportunity and it's a
es not work for wide strings
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.g
--- Comment #1 from bonzini at gnu dot org 2008-12-01 07:31 ---
Why a ref-all pointer? Why not put the cast after the dereference instead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38334
--- Comment #4 from bonzini at gnu dot org 2008-12-05 09:02 ---
I'll look at it in a couple of days. In the meanwhile, could you please attach
the dumps of vrp and the pass just before it?
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #6 from bonzini at gnu dot org 2008-12-05 15:42 ---
Subject: Re: [4.4 Regression] (silent failure)
handling bitfield in ternary
> Folding statement: D.1241_5 = D.1242_4 != 0;
> Folded into: D.1241_5 = (int) D.1242_4;
>
> which is wrong for
>
>D.
--- Comment #40 from bonzini at gnu dot org 2008-12-07 02:55 ---
IIUC this is a typical case in which CSE was fixing something that earlier
passes messed up. Unfortunately fwprop does (better) what CSE was meant to do,
but does not do what I assumed was already done before CSE.
If the
--- Comment #18 from bonzini at gnu dot org 2008-12-19 06:05 ---
mine.
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #19 from bonzini at gnu dot org 2008-12-22 08:52 ---
Smaller testcase, without uninitialized variables too:
enum JSOp
{
JSOP_GETELEM = 5,
JSOP_LIMIT
};
extern void g ();
void
f (char *pc, char *endpc, int format, char ***fp, enum JSOp op)
{
while (pc <= en
--- Comment #20 from bonzini at gnu dot org 2008-12-22 09:05 ---
This is a latent bug in the handling of out-of-bounds values. It happens
because a value changes from [256, 256] to [256, 257]. VRP then forces the
upper bound to the max-value of the type, generating the invalid range
--- Comment #21 from bonzini at gnu dot org 2008-12-22 09:30 ---
Created an attachment (id=16961)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16961&action=view)
patch being tested
Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
--- Comment #7 from bonzini at gnu dot org 2008-12-29 12:25 ---
reopening...
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #20 from bonzini at gnu dot org 2008-12-29 12:26 ---
*** Bug 26908 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #8 from bonzini at gnu dot org 2008-12-29 12:26 ---
... to close as duplicate (since there's some discussion on the other bug)
*** This bug has been marked as a duplicate of 33932 ***
--
bonzini at gnu dot org changed:
What|Re
--- Comment #46 from bonzini at gnu dot org 2008-12-30 08:02 ---
What benchmark.cpp was that? And did you test -O2 or -O3?
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
--- Comment #23 from bonzini at gnu dot org 2008-12-30 10:38 ---
Fixed. However, you should check if the code is valid C++ at all, because
out-of-range enum values are handled differently in C and C++ (the bug stemmed
from the fact that op was set to a value that is beyond what the C
--- Comment #24 from bonzini at gnu dot org 2008-12-30 10:39 ---
patch committed -- bug may be latent on 4.3, but there is no known testcase.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2009-01-02 08:17 ---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Kenneth Zadeck wrote:
> 2009-01-01 Kenneth Zadeck
>
> PR rtl-optimization/35805
> * df-problems.c (df_lr_finalize): Add re
--- Comment #7 from bonzini at gnu dot org 2009-01-02 14:26 ---
Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806
> I think so. The global changed flag allows it to delete the case:
>
> loop:
> ... <- x // This is dead.
> x- <- ...
>
--- Comment #10 from bonzini at gnu dot org 2009-01-02 16:33 ---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
> I will test this patch, but we still need to resolve your issues with my
> approach.
The problem is that you're really doubling
--- Comment #12 from bonzini at gnu dot org 2009-01-02 18:38 ---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
> StevenB talked me out of this because he considered it wrong to have
> the client pass get conservative info. I agreed with him bu
--- Comment #9 from bonzini at gnu dot org 2009-01-19 06:05 ---
I agree with Alan.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #36 from bonzini at gnu dot org 2009-01-19 10:33 ---
Would you please attach the assembler diff:
1) between -m32 -O1 and -m32 -O1 -fforward-propagate
2) between the latter and -m32 -O1 -fforward-propagate -fschedule-insns2?
Thanks.
--
http://gcc.gnu.org/bugzilla
--- Comment #37 from bonzini at gnu dot org 2009-01-19 10:36 ---
This is the fishy part: notice that the %esi in the failing test case is
completely bogus.
- leal-680(%ebp), %esi
- movb$32, (%esi)
- movb$32, -679(%ebp)
- movw$8224, -678(%ebp
--- Comment #39 from bonzini at gnu dot org 2009-01-19 11:04 ---
Looks like a scheduling bug:
-O1 -fforward-propagate has
leal-676(%ebp), %edi
movl$19, %ecx
movl$538976288, %eax
rep stosl
movw$31096, -603(%ebp)
movb
--- Comment #43 from bonzini at gnu dot org 2009-01-19 14:06 ---
The bug is actually in target independent code. The code to change_address_1
in adjust_address_1 does nothing if the addr is simple, and this causes the
creation of shared or wrong RTL.
--
http://gcc.gnu.org/bugzilla
--- Comment #44 from bonzini at gnu dot org 2009-01-19 15:03 ---
Created an attachment (id=17146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17146&action=view)
patch under test
testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #48 from bonzini at gnu dot org 2009-01-20 13:25 ---
Fixed; the bug is latent in 4.3.
--
bonzini at gnu dot org changed:
What|Removed |Added
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot o
--- Comment #26 from bonzini at gnu dot org 2009-01-22 08:08 ---
This is a separate bug. The reduced testcase does not have a single && or || so
it probably existed also before my patch.
It is now bug 38932.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #1 from bonzini at gnu dot org 2009-01-22 08:09 ---
Can anyone check if this is a regression, and if so from which version?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2009-01-22 08:17 ---
Actually, there is no overflow in -9223372036854775807LL - 1 so this is a third
bug. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
--- Comment #3 from bonzini at gnu dot org 2009-01-22 08:23 ---
ah no there's no overflow bit on min
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
--- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00 ---
In PRE there is a fold_convert_const_int_from_int call simplifying "(signed
char) 249" to -7, but setting the TREE_OVERFLOW flag in the meanwhile. I
don't think it makes sense to set the overflow flag on a
--- Comment #7 from bonzini at gnu dot org 2009-01-22 11:04 ---
mine.
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Comment #8 from bonzini at gnu dot org 2009-01-22 12:10 ---
Fixing FRE still causes an ICE for this:
/* { dg-do compile } */
/* { dg-options "-O2 --std=gnu99" } */
/* This variable needed only to exercise FRE instead of CCP. */
unsigned char g;
extern void abort();
vo
ICE in set_value_range, at tree-
vrp.c:398
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, patch
Severity: critical
Priority: P3
Component: middle-end
AssignedTo: unassigne
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #14 from bonzini at gnu dot org 2009-01-24 08:59 ---
Regarding the target milestone, you mean I should apply a 4.3 patch before the
release goes out, too? (I'm currently regtesting it).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
--- Comment #16 from bonzini at gnu dot org 2009-01-24 09:54 ---
changing milestone appropriately then, it did sound strange.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2009-01-24 10:28 ---
Andrew, I'll do SPEC2000 soon so you can backport it to 4.3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
--- Comment #19 from bonzini at gnu dot org 2009-01-25 07:39 ---
no, it's waiting for a backport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
--- Comment #19 from bonzini at gnu dot org 2009-01-26 15:54 ---
fixed on 4.3 branch too.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from bonzini at gnu dot org 2009-01-26 15:56 ---
> This only happens with 32bit HWI.
Does this mean it is a front-end bug that TREE_OVERFLOW is set?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
1 - 100 of 1283 matches
Mail list logo
