--- 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
--- 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 wrote:
>
>
> --- Comment #24 from drow at gcc dot gnu dot org
--- 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
wrote:
>> iterate:
>> push{lr}
>> ldr r3, [r1]
>> .L6:
&g
--- 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
--- 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 for th
--- 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 it is
--- 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 b
--- 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 y
--- 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 wrote:
>>> At this point, if your patch costs say 0.3%, and removing a
--- 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 to the
--- 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 #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 #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 #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.
a
--- 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 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 natura
--- 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 writt
--- 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/
--- 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, whi
--- 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 (
--- 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 numb
33 matches
Mail list logo
