--- Comment #79 from bonzini at gnu dot org 2010-09-04 16:49 ---
Created an attachment (id=21699)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21699&action=view)
incomplete patch
This shows what I plan to do. It doesn't even compile stage2, so it is more or
less use
--- Comment #5 from bonzini at gnu dot org 2010-09-20 16:01 ---
Looks like a problem in expand. CCing Matz.
--
bonzini at gnu dot org changed:
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #82 from Paolo Bonzini 2010-10-13 07:36:45
UTC ---
My patch is not finished and doesn't bootstrap, I'll look at it (promised) next
weekend. I suggest just using BOOT_CFLAGS="-O2 -fno-forward-propagate".
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #8 from Paolo Bonzini 2010-10-18 12:20:39
UTC ---
Would it make sense to make the statement volatile even if only some
subcomponents (or all subcomponents) are volatile?
I like (2); if I understand it correctly, in this case vv1 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #12 from Paolo Bonzini 2010-10-18 17:12:59
UTC ---
It would be nice if for
struct a {
char a,b,c,d;
volatile int e;
};
struct a v1, v2;
...
v1 = v2;
the compiler emitted only _two_ memory accesse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
Paolo Bonzini changed:
What|Removed |Added
Attachment #21699|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #89 from Paolo Bonzini 2010-10-20 14:09:33
UTC ---
The armv5 failure is a stage2 miscompilation. Is it caused by Bernd's patch
too? Or by fwprop?
According to comment 22, previously it was not bootstrapping but the failure
was else
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #92 from Paolo Bonzini 2010-10-29 22:33:04
UTC ---
See followup here: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01636.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46243
Summary: [4.6 Regression] expected tree that contains ‘decl
minimal’ structure, have ‘tree_list’ in start_decl, at
c-decl.c:4049
Product: gcc
Version: unknown
Stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46243
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46243
Paolo Bonzini changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37272
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
Target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
--- Comment #24 from Paolo Bonzini 2010-11-01 16:38:53
UTC ---
You'd need also the patch for bug 41064.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
Paolo Bonzini changed:
What|Removed |Added
CC||nospamname at web dot de
--- Comment #25
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
Paolo Bonzini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
--- Comment #27 from Paolo Bonzini 2010-11-01 16:58:20
UTC ---
Better: not for this testcase. We found it on CRIS, but the bug could really
happen on any target.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23047
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
Known to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
--- Comment #5 from Paolo Bonzini 2010-11-13 10:01:38
UTC ---
Author: bonzini
Date: Sat Nov 13 10:01:33 2010
New Revision: 166700
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166700
Log:
2010-10-30 Paolo Bonzini
PR c/20385
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46463
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46462
--- Comment #1 from Paolo Bonzini 2010-11-13 16:19:38
UTC ---
Author: bonzini
Date: Sat Nov 13 16:19:33 2010
New Revision: 166711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166711
Log:
2010-11-13 Paolo Bonzini
PR c/46462
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46462
--- Comment #2 from Paolo Bonzini 2010-11-13 16:27:24
UTC ---
FAIL: gcc.dg/pr14963.c (internal compiler error)
FAIL: gcc.dg/pr14963.c (test for excess errors)
I actually new about this, it's PR45062.
The Objective-C failures are bad.
The other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46462
--- Comment #4 from Paolo Bonzini 2010-11-14 01:01:58
UTC ---
Patches have been posted, I'm waiting for Objective-C maintainers to (not)
object before committing. The warnings you see are cured by the c-decl.c part:
the behavior of choosing int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46462
--- Comment #5 from Paolo Bonzini 2010-11-14 13:10:45
UTC ---
Author: bonzini
Date: Sun Nov 14 13:10:41 2010
New Revision: 166732
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166732
Log:
2010-11-13 Paolo Bonzini
PR c/46462
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46475
--- Comment #2 from Paolo Bonzini 2010-11-14 15:47:03
UTC ---
Author: bonzini
Date: Sun Nov 14 15:46:59 2010
New Revision: 166733
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166733
Log:
2010-11-14 Paolo Bonzini
PR c/46475
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46475
--- Comment #3 from Paolo Bonzini 2010-11-14 15:47:12
UTC ---
I think I have to debug my test scripts. I'm committing the change from
dg-warning to dg-bogus.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46475
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #98 from Paolo Bonzini 2010-11-14 22:35:54
UTC ---
Minimized testcase:
int f (unsigned long arg, int *cr)
{
int *p = (int *) arg;
int x = *cr;
long pu_err = 0;
if (x)
asm volatile ("stw %2,0(%1)": "=r" (pu_err): "r" (p),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #100 from Paolo Bonzini 2010-11-14
23:34:28 UTC ---
> Cool! The reduced code no longer makes any sense but it should compile.
> I'm sure this was a fair bit of work.
Actually delta made all the work down to 31 lines of typedefs/stru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
--- Comment #8 from Paolo Bonzini 2010-11-15 16:24:52
UTC ---
That works.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
--- Comment #9 from Paolo Bonzini 2010-11-17 16:14:32
UTC ---
Another case in which we still do not detect the unsigned type is after
declspecs:
typedef uintt16_t pid_t;
extern uintt16_t x;
I think that until this is fixed, there are still enou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #101 from Paolo Bonzini 2010-11-17
23:44:28 UTC ---
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01832.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #102 from Paolo Bonzini 2010-11-22
16:20:26 UTC ---
Author: bonzini
Date: Mon Nov 22 16:20:16 2010
New Revision: 167038
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167038
Log:
2010-11-22 Paolo Bonzini
PR bootstrap/449
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33637
--- Comment #13 from Paolo Bonzini 2010-11-23 12:25:19
UTC ---
On 11/23/2010 12:46 PM, jakub at gcc dot gnu.org wrote:
> If not (it would surprise me if everything worked, e.g.
> $1=`cd $with_build_time_tools&& pwd`/$2
> in acx.m4 will not do w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46750
--- Comment #5 from Paolo Bonzini 2010-12-02 01:50:39
UTC ---
More like, everyone's Makefiles problem. This is a serious limitation of
-flto=jobserver, I wonder if it makes sense to keep the option at all.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46920
Summary: suboptimal register allocation with local register
variables
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ra
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46920
--- Comment #2 from Paolo Bonzini 2010-12-14 08:21:33
UTC ---
> To generate the proposed code, we should assign r12 to p63. IRA marks p63
> conflicting with r12 because DF-infrastructure reports r12 having intersected
> live ranges with p63.
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46920
--- Comment #4 from Paolo Bonzini 2010-12-14 16:48:20
UTC ---
Yes, I agree that excessive peppering of the code with register asm causes
worse performance. The interpreter is only placing the very hot ip and sp
registers in hard-coded registers.
--- Comment #11 from bonzini at gnu dot org 2010-05-09 14:14 ---
Patch posted now.
Sorry, I was busy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
--- Comment #2 from bonzini at gnu dot org 2010-05-21 07:27 ---
What if you call AC_LANG_WERROR just before the test? This wouldn't be a final
patch because then you need to restore the previous value, but it's a start.
Ralf, maybe we want in Autoconf (and hence in over
--- Comment #6 from bonzini at gnu dot org 2010-05-25 16:21 ---
The patch needs a fat comment saying what's going on, then it should be okay.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44216
--- Comment #3 from bonzini at gnu dot org 2010-05-29 17:32 ---
I don't think this bug is of any use. Unlike nonnull, unused return values do
not trigger undesirable optimizations and (as far as I can tell) cannot
possibly result in miscompilation.
This bug is indeed about a loo
--- Comment #5 from bonzini at gnu dot org 2010-05-30 06:42 ---
Richi, I think we're saying the same thing from two different directions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44321
--- Comment #11 from bonzini at gnu dot org 2010-06-22 17:28 ---
That would be WONTFIX for 4.5 and earlier, right? 4.4 and earlier are
definitely out of question, but maybe your patch alone gives the same effect on
4.5 branch too, without any of the other ivopts and ARM improvements
--- Comment #5 from bonzini at gnu dot org 2010-06-30 11:51 ---
I agree that the problem is a wrong pattern.
Here you have non-matching mode between the udiv/umod and the first argument:
> (ior:HI (ashift:HI (zero_extend:HI (umod:QI (reg:HI 68)
> (reg:QI 61 [
--- Comment #5 from bonzini at gnu dot org 2010-07-08 16:24 ---
The patch is okay, but it should be tested with bootstrap, `make install' and a
smoke test after install with:
- in-tree GMP, in-tree MPFR 2.3
- in-tree GMP, in-tree MPFR 3.0
- out-of-tree GMP, in-tree MPFR 2.3
- o
--- Comment #12 from bonzini at gnu dot org 2010-07-11 07:51 ---
I agree.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #23 from bonzini at gnu dot org 2010-07-11 07:51 ---
This is fixed on ARM, what about PPC?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
--- Comment #8 from bonzini at gnu dot org 2010-07-13 09:32 ---
Yes, C-only bootstrap is enough.
Regarding the removal of an installed GMP, in theory yes, it would be
preferable. In practice removing it would force you to use an old bootstrap
GCC that does not use MPC/MPFR/GMP, and
--- Comment #10 from bonzini at gnu dot org 2010-07-13 14:43 ---
Great! Do you have commit rights? Patch is ok for all 4.5 and 4.6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
--- Comment #12 from bonzini at gnu dot org 2010-07-13 15:31 ---
Subject: Re: GCC fails to build if MPFR 3.0.0 (Release
Candidate) is used
On 07/13/2010 05:01 PM, marc dot glisse at normalesup dot org wrote:
> --- Comment #11 from marc dot glisse at normalesup dot org 2010-07
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721
--- Comment #17 from Paolo Bonzini 2011-08-03 06:32:42
UTC ---
H.J., I agree with what you write in comment 16. But unless we are sure that
the problematic composition will never be generated (e.g. by ivopts), we cannot
afford that.
The patch i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50047
--- Comment #1 from Paolo Bonzini 2011-08-12 17:13:10
UTC ---
Author: bonzini
Date: Fri Aug 12 17:13:04 2011
New Revision: 177706
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177706
Log:
2011-08-12 Paolo Bonzini
PR bootstrap/500
--- Comment #17 from bonzini at gnu dot org 2007-10-29 10:05 ---
> This issue with -4 offset is annoying because code size of offsetted load insn
> is huge:
>
>f: c7 40 fc 01 00 00 00movl $0x1,-0x4(%eax)
-0x4(%eax) is 2 bytes more than (%eax), where IIRC it wou
--- Comment #8 from bonzini at gnu dot org 2007-10-31 13:21 ---
Reopening and marking as enhancement.
A patch like this should work:
Index: sparseset.c
===
--- sparseset.c (revision 129768)
+++ sparseset.c (working copy
--- Comment #16 from bonzini at gnu dot org 2007-11-05 08:21 ---
No, but I don't think this should hold up marking this PR as fixed.
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #6 from bonzini at gnu dot org 2007-11-06 17:05 ---
I think P1 is a little too much since this requires -fforce-addr.
Anyway, here are my findings and thoughts:
1) reduced testcase:
void oc_frag_recon_inter2_mmx(unsigned char *_dst,int _dst_ystride,
const unsigned char
--- Comment #7 from bonzini at gnu dot org 2007-11-06 17:10 ---
I would also like to know the status, because I would like to get rid of
-fforce-addr. :-)
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #9 from bonzini at gnu dot org 2007-11-06 20:08 ---
Can you try -O3 -fno-predictive-commoning and -O3 -fno-tree-vectorize?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
--- Comment #11 from bonzini at gnu dot org 2007-11-06 21:23 ---
michael dot olbrich at gmx dot net wrote:
> --- Comment #10 from michael dot olbrich at gmx dot net 2007-11-06 21:01
> ---
> 4.2 4.3 |
> ---
> 4.4s 15.9s |-O3
> 4.6s 16
--- Comment #3 from bonzini at gnu dot org 2007-11-07 11:04 ---
Created an attachment (id=14495)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14495&action=view)
patch that fixes the bug
I'm not sure about the correctness of the i386.c hunk. The problem is that a
--- Comment #2 from bonzini at gnu dot org 2007-11-07 11:03 ---
fwprop should check costs just like combine does. Unfortunately the cost do
need a little bit of tweaking even if one implements the idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34012
--- Comment #19 from bonzini at gnu dot org 2007-11-07 16:35 ---
Might be tree-level forwprop, CCing richi...
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
isprinted in gimple dump
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34014
--- Comment #18 from bonzini at gnu dot org 2007-11-07 16:26 ---
Created an attachment (id=14498)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14498&action=view)
never say minimal!
So this is a testcase constructed from scratch. 4.3 is 4.5x slower (0.8s vs.
0.18s). Furt
--- Comment #16 from bonzini at gnu dot org 2007-11-07 14:22 ---
4.3 does much less SRA.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #15 from bonzini at gnu dot org 2007-11-07 13:09 ---
Created an attachment (id=14496)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14496&action=view)
self contained testcase
4.2 4.3
-O214.5s11
--- Comment #6 from bonzini at gnu dot org 2007-11-07 17:02 ---
Created an attachment (id=14499)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14499&action=view)
patch using rtx_cost
This patch uses rtx_cost instead of insn_rtx_cost, which is faster and does not
require t
--- Comment #17 from bonzini at gnu dot org 2007-11-07 16:03 ---
Created an attachment (id=14497)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14497&action=view)
"minimal" testcase
This is as small as I could get it (130 lines). Can be made smaller, bu
--- Comment #11 from bonzini at gnu dot org 2007-11-08 19:56 ---
-fforce-addr for SPECfp is neutral, with big improvements in equake (and a
little on swim+lucas, but the latter has huge fluctuations).
SPECint drops from 1156 to 1130, with clear changes for the worse as
highlighted by
--- Comment #12 from bonzini at gnu dot org 2007-11-08 19:58 ---
Who prepares the patch? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
--- Comment #14 from bonzini at gnu dot org 2007-11-10 13:04 ---
I reviewed the patch and it seems ok except that the option should be kept
undocumented for 4.3.
fforce-addr
- Common Report Var(flag_force_addr) Optimization
- Copy memory address constants into registers before use
--- Comment #9 from bonzini at gnu dot org 2007-11-10 18:10 ---
You should report the problem to SPEC so they update
http://www.spec.org/cpu2006/Docs/450.soplex.html and create a src.alt (I think,
at least this is how it was for CPU2000).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #14 from bonzini at gnu dot org 2007-11-11 07:16 ---
It could also be possible to do something like this to avoid default
construction.
@@ -46,8 +46,8 @@ namespace soplex
class UnitVector : public SVector
{
private:
- Element themem; ///< memory for 1st sparse vec
--- Comment #10 from bonzini at gnu dot org 2007-11-13 08:16 ---
Anyway, it looks like a latent bug somewhere else.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #11 from bonzini at gnu dot org 2007-11-13 08:21 ---
Since you are at it, could you test on *exactly* the involved revisions, i.e.
130042 and 130043?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
--- Comment #21 from bonzini at gnu dot org 2007-11-14 11:04 ---
I am not following you. Why do both executions abort? We don't want to find
two different wrong-code bugs, but to compare one correct and one wrong
execution. Also, it would be okay to have no output as long as w
--- Comment #23 from bonzini at gnu dot org 2007-11-14 12:12 ---
Created an attachment (id=14553)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14553&action=view)
patch to test
I had this alternative patch to fix the addr-sel-1.c failure on
i686-pc-linux-gnu. Could you c
--- Comment #16 from bonzini at gnu dot org 2007-11-19 09:45 ---
Steven, post it to gcc-patches and I'll be happy to commit it as soon as it is
approved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
--- Comment #4 from bonzini at gnu dot org 2007-11-21 09:47 ---
Created an attachment (id=14589)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14589&action=view)
attempt
Can you try this patch? I don't have the resources now to build a cross and
test it.
--- Comment #12 from bonzini at gnu dot org 2007-11-29 11:43 ---
I think this should use find_comparison_args.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2007-11-30 05:41 ---
What were the benchmarks where the cost model was slower?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from bonzini at gnu dot org 2007-11-30 05:39 ---
One suspect is fwprop. Anyone can confirm?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2007-11-30 07:17 ---
So -fvect-cost-model is doing its job. The vectorizations must not be
profitable, or are they?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
--- Comment #18 from bonzini at gnu dot org 2007-11-30 14:58 ---
It would be -fno-forward-propagate, but what I meant is that the changes
*connected to* fwprop could be the culprit. One has to look at dumps to
understand if this is the case.
It would be possible, maybe, to put an asm
--- Comment #8 from bonzini at gnu dot org 2007-11-30 13:30 ---
Testing a one-liner.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
--- Comment #6 from bonzini at gnu dot org 2007-11-30 10:59 ---
Looking at
http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/gfortran-run.dat and
http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/gfortranVecCost-run.dat
I think we should turn on cost model by default, at
--- Comment #27 from bonzini at gnu dot org 2007-12-03 10:17 ---
It seems to me that the "old" RAW_CXX_FOR_TARGET is unused after the patch.
Can you confirm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
--- Comment #29 from bonzini at gnu dot org 2007-12-03 13:17 ---
It might be me, but I cannot see when they are used. Or better, yes, they are
used in LTCXXCOMPILE but there a few -L... switches shouldn't make any
difference, so you could use CXX_FOR_LIB also in LTCXXCOMPILE (an
--- Comment #5 from bonzini at gnu dot org 2007-12-03 15:15 ---
As a start, let's limit register passing convention to regparm=2. The risk of
running out QImode registers is quite real, as is the risk of getting extremely
bad code...
--
bonzini at gnu dot org ch
--- Comment #29 from bonzini at gnu dot org 2007-12-04 11:17 ---
Could you try 4.2 vs. 4.3 on:
- http://gcc.gnu.org/bugzilla/attachment.cgi?id=14496
- http://gcc.gnu.org/bugzilla/attachment.cgi?id=14497
- http://gcc.gnu.org/bugzilla/attachment.cgi?id=14497 with the first #if 0
enabled
--- Comment #11 from bonzini at gnu dot org 2007-12-10 08:36 ---
committed, cost model now enabled for i386.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #15 from bonzini at gnu dot org 2007-12-10 08:37 ---
As I committed PR32086 to use the cost model, this should be fixed. However, I
prefer to leave it open as a missed optimization since Richard G.'s comments
suggest that: a) there should be a DCE pass after vectoriz
--- Comment #13 from bonzini at gnu dot org 2007-12-10 16:37 ---
I think so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
--- Comment #15 from bonzini at gnu dot org 2007-12-14 14:31 ---
I have a patch that makes the reduce_bitfield_operations langhook a per-type
field, but it doesn't affect code generation.
Isn't there a testcase in the C++ library that fails if the langhook is
false?...
--- Comment #7 from bonzini at gnu dot org 2007-12-14 13:10 ---
(right commit was 10718)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10178
0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34479
--- Comment #23 from bonzini at gnu dot org 2007-12-17 06:14 ---
You're perfectly right; OTOH if I hadn't meant to fix it, I would have
unassigned it. Sometimes people are busy, and for a build patch I usually do
more than bootstrap/regtest on one architecture.
1001 - 1100 of 1283 matches
Mail list logo
