--- Comment #26 from stevenb dot gcc at gmail dot com 2010-05-01 22:30
---
Subject: Re: Mach-O LTO support needed for darwin
Do you mean the errors which have symbol xxx can't be undefined in a
subtraction expression?
Yes, exactly those.
A google shows this to look like
--- Comment #9 from stevenb dot gcc at gmail dot com 2010-04-26 16:06
---
Subject: Re: Mach-O LTO support needed for darwin
Mach-O section names are too short, but I have solved this with a
separate section with section names in a strings table. This is
similar to the solution from
--- Comment #7 from stevenb dot gcc at gmail dot com 2010-04-15 14:03
---
Subject: Re: Mach-O LTO support needed for darwin
Can we just use the LTO COFF patch...as a template?
That is certainly my plan, yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #25 from stevenb dot gcc at gmail dot com 2010-02-19 23:32
---
Subject: Re: [4.3/4.4/4.5 Regression] huge
performance regression on EEMBC bitmnp01
On 2/19/10, drow at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #24 from drow at gcc dot
--- Comment #11 from stevenb dot gcc at gmail dot com 2010-01-11 08:22
---
Subject: Re: redundant memory load
On Mon, Jan 11, 2010 at 7:47 AM, carrot at google dot com
gcc-bugzi...@gcc.gnu.org wrote:
iterate:
push{lr}
ldr r3, [r1]
.L6:
str r3
--- Comment #3 from stevenb dot gcc at gmail dot com 2010-01-08 07:31
---
Subject: Re: -fcompare-debug failure (length) with -O1
-fvariable-expansion-in-unroller -funroll-loops
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-01-08 07:10
---
Taking
--- Comment #18 from stevenb dot gcc at gmail dot com 2009-07-23 22:23
---
Subject: Re: [4.3/4.4/4.5 Regression] huge
performance regression on EEMBC bitmnp01
I had the patch ready but Matz' PRE patch means I have to rework things a bit.
Since I only have time
--- Comment #25 from stevenb dot gcc at gmail dot com 2009-02-23 17:47
---
Subject: Re: very long optimized compile
Re Comment #24:
I can look into it...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
--- Comment #95 from stevenb dot gcc at gmail dot com 2009-02-15 11:26
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Re: Comment #94
The trouble with LCM in RTL (i.e. GCSE-PRE) is not that it is slow (or
that it is disabled -- istr
--- Comment #92 from stevenb dot gcc at gmail dot com 2009-02-14 14:42
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Re: Comment #88
I think the patch is perfectly acceptable as a stop-gap solution. I
don't think we have anything better
--- Comment #5 from stevenb dot gcc at gmail dot com 2009-02-06 22:40
---
Subject: Re: gcc3.4.6 generates incorrect ppc32 code
for combination of bitfields and shifts
Whilst I am not complaining about 3.4 not being supported, I think it is
a pretty poor show that you
--- Comment #13 from stevenb dot gcc at gmail dot com 2009-01-02 18:45
---
Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806
On Fri, Jan 2, 2009 at 7:37 PM, Paolo Bonzini bonz...@gnu.org wrote:
At this point, if your patch costs say 0.3%, and removing all
--- Comment #7 from stevenb dot gcc at gmail dot com 2009-01-01 13:42
---
Subject: Re: [4.3/4.4 Regression] Inline heuristics run even at -O0
Note that the compile time at, say, -O1 for 4.3 vs. 4.4 is also a huge
difference for the test case (4.4 much slower, in part due
--- Comment #44 from stevenb dot gcc at gmail dot com 2008-12-10 22:30
---
Subject: Re: [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts
not understanding autoincrement)
Joern, can you attach the updated patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
--- Comment #8 from stevenb dot gcc at gmail dot com 2008-02-01 11:51
---
Subject: Re: [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3
I would say it is a target issue if the target return insn does not
mention that %edx is used.
--
http://gcc.gnu.org/bugzilla
--- Comment #22 from stevenb dot gcc at gmail dot com 2008-02-01 14:55
---
Subject: Re: [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3
Could you retain the gcc_assert (HARD_REGISTER_P (x)); please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
--- Comment #18 from stevenb dot gcc at gmail dot com 2008-02-01 14:14
---
Subject: Re: [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3
Why would we be calling expand_null_return to begin with, if there is
a proper return statement?
--
http://gcc.gnu.org/bugzilla
--- Comment #37 from stevenb dot gcc at gmail dot com 2008-01-30 20:13
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as
much??)
Those seems to be all just array manipulations.
AFAICT, they are exactly in the form that some targets like it (e.g.
auto
--- Comment #22 from stevenb dot gcc at gmail dot com 2008-01-21 14:29
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
On 21 Jan 2008 13:25:23 -, zadeck at naturalbridge dot com gcc-
I understand that, that is why if the pass does not specify DF_EQ_NOTES
--- Comment #12 from stevenb dot gcc at gmail dot com 2008-01-11 13:48
---
Subject: Re: [4.3 Regression] Fails to cross-jump
Richi, could you commit it for me?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #44 from stevenb dot gcc at gmail dot com 2007-12-20 15:08
---
Subject: Re: Inordinate compile times on large routines
On 20 Dec 2007 14:49:12 -, zadeck at naturalbridge dot com
[EMAIL PROTECTED] wrote:
--- Comment #43 from zadeck at naturalbridge dot com 2007
--- Comment #43 from stevenb dot gcc at gmail dot com 2007-12-20 06:15
---
Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions
I did not mean more bitmaps but more elements per bitmap, obviously.
I know the effect of the patch, or I wouldn't have written
--- Comment #37 from stevenb dot gcc at gmail dot com 2007-12-17 16:55
---
Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions
Compiling with checking disabled might give a less unfair comparison.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
--- Comment #45 from stevenb dot gcc at gmail dot com 2007-11-11 09:23
---
Subject: Re: [4.1/4.2/4.3 regression] Quadratic behavior with many sets for
the same register in VRP
Because it costs more than it brings: compile time on average goes
_up_ with that patch.
--
http
--- Comment #4 from stevenb dot gcc at gmail dot com 2007-08-12 10:36
---
Subject: Re: debug info of modules
This is still on my TODO-list, but not for GCC 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29635
--- Comment #6 from stevenb dot gcc at gmail dot com 2007-06-13 05:22
---
Subject: Re: [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3
I'll take a look this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
--- Comment #6 from stevenb dot gcc at gmail dot com 2007-05-07 09:46
---
Subject: Re: [4.2/4.3 Regression] Code size regression caused by fix to PR
31360
Constant / copy simplifications should be done in at least CSE,
fwprop, and the gcse CPROP passes (we run CPROP three times
--- Comment #8 from stevenb dot gcc at gmail dot com 2007-04-06 16:43
---
Subject: Re: -O -fregmove handles SSE scalar instructions incorrectly
The attached patch to remove '%' seems correct to me. Merge operating
wrapping the (commutative) plus/mult/min/max is not commutative, so
--- Comment #11 from stevenb dot gcc at gmail dot com 2007-01-29 18:22
---
Subject: Re: -Wunused doesn't warn about static function only called by
itself.
If it is unused, don't hesitate to remove it. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
--- Comment #8 from stevenb dot gcc at gmail dot com 2007-01-27 19:58
---
Subject: Re: -Wunused doesn't warn about static function only called by
itself.
Just one for everything should suffice.
Or, if you prefer, you can remove that one function with a separate
patch first, which, I
--- Comment #2 from stevenb dot gcc at gmail dot com 2007-01-02 15:27
---
Subject: Re: debug info of modules
I'm waiting for my gdb assignment to be finished. This will probably
be work for Q2 2007.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29635
--- Comment #18 from stevenb dot gcc at gmail dot com 2006-11-26 09:19
---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md tmp-condmd.c: /bin/sh: 13354 Memory
fault(coredump)
Just adding DF_HARD_REGS is not enough. At least this bit:
- if (use
--- Comment #10 from stevenb dot gcc at gmail dot com 2006-04-08 21:13
---
Subject: Re: IVs with the same evolution not eliminated
The new SCC value numberer for PRE i'm working on gets this case right (and
this is in fact, one of the advantages of SCC based value numbering
33 matches
Mail list logo
