--- Comment #16 from bonzini at gnu dot org 2009-02-25 12:18 ---
The upcoming C++0x memory model forbids this; see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html (Concurrency
memory model compiler consequences). But it says that this is acceptable
instead:
tmp
--- Comment #5 from bonzini at gnu dot org 2009-02-25 17:03 ---
Subject: Re: libada parsing of multilib options
schwab at suse dot de wrote:
> --- Comment #3 from schwab at suse dot de 2009-02-25 16:57 ---
> Created an attachment (id=17360)
--> (http://gcc.gnu.org
--- Comment #24 from bonzini at gnu dot org 2009-02-25 18:43 ---
Andrew, your comments #6 #8 #9 clearly show that you haven't understood the
issue and are just talking past others.
The other hand the transformation has been shown to be an optimization on
single-thread cases; if
--- Comment #9 from bonzini at gnu dot org 2009-02-26 09:09 ---
comment #6 suggests that it is at least a regression *from 4.2 to 4.3*?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #11 from bonzini at gnu dot org 2009-02-26 09:12 ---
I remember seeing this kind of insertion in very old GCCs too (inserting all
sort of loads at the end of every branch of a switch statement). I like
Steven's patch, even though it's a bit brute force.
--- Comment #8 from bonzini at gnu dot org 2009-02-26 15:48 ---
Subject: Re: libada parsing of multilib options
I'll ping Marcello Presulli to submit his patch.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172
--- Comment #9 from bonzini at gnu dot org 2009-02-27 07:40 ---
Andreas, the patch you posted on gcc-patches is okay. Thanks very much!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172
--- Comment #8 from bonzini at gnu dot org 2009-03-02 06:11 ---
Subject: Re: gcc.dg/tree-ssa/vrp47.c fails on powerpc
> Is this the same issue, or should I open a different report?
I think it is the same, I will verify.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219
--- Comment #12 from bonzini at gnu dot org 2009-03-13 07:28 ---
I think you need a matching memory constraint instead of just "m" or the bug
might resurface.
(define_memory_constraint "H"
"@internal"
(match_test "cmpxchg8b_memory_operand
--- Comment #13 from bonzini at gnu dot org 2009-03-13 07:32 ---
Nevermind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431
--- Comment #4 from bonzini at gnu dot org 2009-03-24 15:03 ---
The only thing to be careful is to have set_reg_equal == FALSE if the insn has
multiple sets, and find which set in a multiple-set insn is actually referring
to USE (a combination of note_stores and loc_mentioned_in_p will
--- Comment #7 from bonzini at gnu dot org 2009-03-25 16:49 ---
> one is the rtx_cost (SET_SRC (set), SET, speed) > old_cost check
> (I wonder whether it is needed for asms at all and if yes, how to actually do
> it)
For addresses it is already done in should_replace_addre
--- Comment #9 from bonzini at gnu dot org 2009-03-26 08:47 ---
That's good to know. As I said, I'm okay with your patch. I just wondered if
for 4.5 the cse_not_expected trick fixes it. In that case I'd have no problem
applying the patch to 4.4, but I would reve
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: sh*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39561
n: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: arc-unknown-elf
http://gcc
rsion: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: xstormy16-unknown-elf
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #10 from bonzini at gnu dot org 2009-03-31 13:22 ---
The bug is still there FWIW.
--
bonzini at gnu dot org changed:
What|Removed |Added
Last reconfirmed
--- Comment #1 from bonzini at gnu dot org 2009-04-07 13:42 ---
More info from Solaris bug # 6323525:
if (number_of_cores() < 2) then don't have bug
if (family == 0xf && Model < 0x40) then have bug
if (rdmsr(MSR_BU_CFG/*0xC0011023*/) & 2) then bug i
ock erratum
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i386-*-*, x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39677
--- Comment #2 from bonzini at gnu dot org 2009-04-07 15:02 ---
I cannot see any better alternative, but I'll point out that saying
"wrong-code" is not exact.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39677
--- Comment #2 from bonzini at gnu dot org 2009-04-08 11:01 ---
Minimized testcase is this:
int baz (void *, ...);
static void bar();
char c;
float f;
void foo(void) { bar(0,0,0, c, c, f, foo); }
void bar (x1,x2,x3, ss, c, f, pf) { baz(&x1,&x2,&x3); }
--
bonzini at
--- Comment #11 from bonzini at gnu dot org 2009-04-09 10:34 ---
*** Bug 35655 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2009-04-09 10:34 ---
*** This bug has been marked as a duplicate of 32431 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2009-04-09 10:36 ---
seems to be fixed on trunk.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #16 from bonzini at gnu dot org 2009-04-09 11:00 ---
On i686 to spu cross, for -O2 45 minutes were not enough.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2009-04-10 06:42 ---
The Fortran problem is a real bug in the front-end that was masked by folding.
The problem is that we're folding less than without my patch. I'll prepare a
patch to both fix the Fortran problem and reestablish t
--- Comment #3 from bonzini at gnu dot org 2009-04-10 06:55 ---
The pr36901-* are correct to fail IMO -- they now give an "initializer is not
constant" error which they weren't giving before -- because you cannot know in
principle that &sc > 0 at compile-time
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39714
Thumb
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
MED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzill
n crx in IRA
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
n
mal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39719
mbine does not use LOAD_EXTEND_OP?
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugs
: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39721
on v850 and
mn10300
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot
ith long long shifts on v850
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDep
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org
pessimizations on floating-point
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO
rsion: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39726
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39727
--- Comment #1 from bonzini at gnu dot org 2009-04-10 15:25 ---
Another testcase, this one failing at -O2:
void foo (unsigned int n)
{
int i, j = -1;
for (i = 0; i < 10 && j < 0; i++)
if ((1UL << i) == n)
j = i;
}
--
http://gcc.gnu.org/bugz
--- Comment #6 from bonzini at gnu dot org 2009-04-10 16:05 ---
> We know it's not NULL.
I don't think the compiler can say so if not -fdelete-null-pointer-checks, and
the flag is off at -O0 and -O1 (which is a separate bug and a separate patch).
--
http://gcc.gnu
--- Comment #8 from bonzini at gnu dot org 2009-04-10 16:07 ---
The fortran problem is now latent. The PR39601 failures remain and will be
cured differently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
--- Comment #9 from bonzini at gnu dot org 2009-04-10 16:18 ---
Created an attachment (id=17614)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17614&action=view)
second part of the fix
This is an alternative way to fix the PR36901 failures by enabling
-fdelete-null-pointer
--- Comment #1 from bonzini at gnu dot org 2009-04-10 20:06 ---
This was actually fixed already with local patches, at least above -O1.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2009-04-14 07:28 ---
-O2 -frename-registers is enough actually.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39685
--- Comment #1 from bonzini at gnu dot org 2009-04-14 08:29 ---
Seems to be caused by a failure to simplify
(if_then_else (ne (zero_extract:SI (const_int 0 [0x0])
(const_int 1 [0x1])
(const_int 0 [0x0]))
(const_int 0 [0x0
nzini at gnu dot org
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39760
ssigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
--- Comment #1 from bonzini at gnu dot org 2009-04-14 08:57 ---
This is currently caught by RTL jump bypassing, but not on all machines.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2009-04-14 12:16 ---
Right, sorry -- it is only at -Os that we don't get it. VRP and DOM say that
the jump threading is not performed because the probability is too small, and
PRE does not run at -Os at all.
--
bonzini at gnu do
--- Comment #3 from bonzini at gnu dot org 2009-04-14 11:56 ---
No, it survives to RTL :-(
Adjusting subject.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #8 from bonzini at gnu dot org 2009-04-14 13:00 ---
It seems easier to lower complex phis. Though it doesn't work with vectors, it
shouldn't matter since we do not have vector extraction yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
--- Comment #11 from bonzini at gnu dot org 2009-04-14 13:41 ---
Yes, but programs cannot use it so it does not really count.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
--- Comment #11 from bonzini at gnu dot org 2009-04-14 13:52 ---
> I don't see the connection to SSA expansion
Well, now that you posted the patch my suppositions were partly true. The
important thing is that now you have a way to get an SSA_NAME's RHS into
expansion.
--- Comment #13 from bonzini at gnu dot org 2009-04-14 14:02 ---
Subject: Re: [4.4/4.5 Regression] Reload failure
on mplayer from SVN
> That's one of the reasons why TER doesn't forward all expressions even if
> they're used only once.
Yes -- indeed i
--- Comment #2 from bonzini at gnu dot org 2009-04-16 08:04 ---
Subject: Re: [cond-optab] CSE does not put subregs into
COMPAREs on many CC0 machines
> Is this a cond-optab regression or "just" an observation?
Yes, it causes extra moves on code using unions. Where we
NCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39806
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #4 from bonzini at gnu dot org 2009-04-20 15:48 ---
> Maybe a stupid question, but shouldn't this
> canon_true_dependence call receive canonicalized MEMs from 'base' and
> 'store_info->cse_base'?
I think so. The only way that DSE
--
bonzini at gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.1 |4.3.4
Version|4.4.0 |4.3.3
http
--- Comment #9 from bonzini at gnu dot org 2009-04-23 14:37 ---
(From update of attachment 17675)
The testcase includes an invalid asm (it should clobber memory).
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
Summary|[4.4 Regression] Wrong |[4.4/4.5 Regression] Wrong
|result of conditional
--- Comment #3 from bonzini at gnu dot org 2009-04-23 15:22 ---
Created an attachment (id=17684)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17684&action=view)
patch
Bootstrapped but not yet regtested. Testcase:
/* { dg-do link } */
/* { dg-options "-O2" } *
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org
--- Comment #7 from bonzini at gnu dot org 2009-04-23 16:09 ---
Eric, fold only does it for a >= C1 && a <= C2, not for variable C1 and C2. in
fact, in this case it would be illegal to do the transformation if the
front-end did not know that m->length is posit
--- Comment #8 from bonzini at gnu dot org 2009-04-23 16:10 ---
Eric, fold only does it for constant C1 and C2 in "a >= C1 && a <= C2", not for
variable C1 and C2. in fact, in the other case it would be illegal to do the
transformation. the front-end can do it
--- Comment #5 from bonzini at gnu dot org 2009-04-24 11:35 ---
Subject: Bug 39867
Author: bonzini
Date: Fri Apr 24 11:34:59 2009
New Revision: 146702
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146702
Log:
2009-04-24 Paolo Bonzini
PR middle-e
--- Comment #10 from bonzini at gnu dot org 2009-04-27 19:04 ---
Yeah, it's basically destroying caller-save optimization.
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #3 from bonzini at gnu dot org 2009-04-28 18:12 ---
H.J., please do not make up testcases and tell us who was actually using %z for
x87 as of March 31st, 2009.
Otherwise, this bug has the same level of seriousness as the one I'm closing it
as duplicate of.
*** This bu
--- Comment #13 from bonzini at gnu dot org 2009-04-28 18:12 ---
*** Bug 39949 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2009-04-28 18:13 ---
reopening...
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from bonzini at gnu dot org 2009-04-28 18:14 ---
... to mark as waiting.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from bonzini at gnu dot org 2009-04-28 19:33 ---
Subject: Re: [4.5 regression] Revision 146874 breaks %z on
x87 insns
> If I had told you that we had had several internal applications
> which use %z on x87 since 1998, would it make a difference?
Maybe n
--- Comment #11 from bonzini at gnu dot org 2009-04-29 05:09 ---
Subject: Re: [4.5 regression] Revision 146874 breaks %z on
x87 insns
> The right thing is just to document them.
Agreed. But the question is whether to break %z and all but one
person reckon it would
--- Comment #6 from bonzini at gnu dot org 2009-04-30 14:56 ---
Fails after PRE.
Reduced testcase requiring just a jc1 executable (assuming gcc is built in a
subdirectory of the toplevel, i.e. ../configure):
./jc1 "../../libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.
--- Comment #7 from bonzini at gnu dot org 2009-04-30 14:56 ---
Ah, I didn't bootstrap so jc1 cannot be miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #9 from bonzini at gnu dot org 2009-04-30 21:10 ---
Subject: Re: [4.5 Regression] Bootstrap failure in libjava on
i686-apple-darwin9
> I successfully bootstrapped libjava on powerpc-apple-darwin9 at revision
> 146999.
Interesting, can you try the command-
--- Comment #11 from bonzini at gnu dot org 2009-05-01 05:40 ---
Subject: Re: [4.5 Regression] Bootstrap failure in libjava on
i686-apple-darwin9
The file name is really gnuPOA$RefTemplate.class
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #12 from bonzini at gnu dot org 2009-05-01 05:42 ---
Subject: Re: [4.5 Regression] Bootstrap failure in libjava on
i686-apple-darwin9
-mtune=generic should be eliminated from the ppc build, too (but intel
fails also without it)
--
http://gcc.gnu.org/bugzilla
--- Comment #20 from bonzini at gnu dot org 2009-05-02 13:51 ---
Also reproducible with compiler to powerpc-apple-darwin, same error message.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #21 from bonzini at gnu dot org 2009-05-02 13:53 ---
> Java has always been broken at -m64 on ppc-darwin since no one has ever ported
> ffi to work on ppc64 for darwin.
But jc1 builds if you just "make jc1", and it exhibits the same bug.
--
http://gcc.
--- Comment #23 from bonzini at gnu dot org 2009-05-02 14:16 ---
Now this is funny. I get the same error even with a cross from i686-darwin to
i686-pc-linux-gnu!
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #24 from bonzini at gnu dot org 2009-05-02 14:20 ---
Created an attachment (id=17792)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17792&action=view)
debug output with -fdump-tree-all-details-blocks-vops
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #28 from bonzini at gnu dot org 2009-05-02 20:34 ---
Yes, fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #29 from bonzini at gnu dot org 2009-05-02 20:35 ---
what about 4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #5 from bonzini at gnu dot org 2009-05-03 12:11 ---
In many cases, opaque types are used in the prototypes just to avoid warnings.
You're right that the front-end should insert VIEW_CONVERT_EXPRs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
--- Comment #7 from bonzini at gnu dot org 2009-05-03 14:00 ---
> Ok, so the builtins should have a proper, but opaque vector type (like for
> VEC_CTU it should be an unsigned vector type, not a signed one).
No, there's no reason to have >1 opaque vector type for a single
--- Comment #8 from bonzini at gnu dot org 2009-05-03 14:25 ---
What's remaining was already in the database.
*** This bug has been marked as a duplicate of 30210 ***
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:25 ---
*** Bug 40009 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #10 from bonzini at gnu dot org 2009-05-03 14:26 ---
The wrong types in __builtin_altivec_ctu cause this:
FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal
compiler error)
FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:34 ---
To be more specific, the builtin call is created by the vectorizer, and the
vectorizer is quite careless in matching types. The front-end *does* insert
VIEW_CONVERT_EXPRs and so does rs6000-c.c.
--
http://gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28315
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54206
--- Comment #7 from Paolo Bonzini 2012-10-05 06:33:41
UTC ---
Building in srcdir usually works. Could it be as simple as this?
Index: Makefile.am
===
--- Makefile.am(r
--- Comment #16 from bonzini at gnu dot org 2009-08-14 12:17 ---
committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from bonzini at gnu dot org 2009-08-17 08:42 ---
Can you check if the same preprocessed source for deflate.c (the deflate.i file
obtained with --save-temps) compiles fine with both 3.4.0 and 4.4.1? If so,
please attach it together with the deflate.s files produced by the
--- Comment #12 from bonzini at gnu dot org 2009-08-17 13:30 ---
Please try again with GCC 4.4.1 -O2 vs. GCC 3.4.0 -O2 or -O3.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org
--- Comment #6 from bonzini at gnu dot org 2009-08-30 14:35 ---
committed to trunk, 4.4 will follow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41122
701 - 800 of 1283 matches
Mail list logo
