--- Comment #18 from ubizjak at gmail dot com 2006-12-23 21:24 ---
(In reply to comment #12)
> As far as I can see, the i387 mode switching is already completely broken,
> because it treats the different modes of a single mode-switchable entity
> as separate entities.
NO, it is _NOT_ b
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-09-06 06:14
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #16 from kkojima at gcc dot gnu dot org 2006-09-05 21:41
---
Subject: Bug 28764
Author: kkojima
Date: Tue Sep 5 21:41:23 2006
New Revision: 116703
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116703
Log:
PR target/28764
* mode-switching.c (optimiz
--- Comment #15 from amylaar at gcc dot gnu dot org 2006-08-25 17:01
---
(In reply to comment #13)
> For any transparent sub-graph, considering the expression anticipatable
> in this graph is beneficial if the sum of the frequencies of outgoing edges
> on which the expression is anticip
--- Comment #14 from bonzini at gnu dot org 2006-08-25 16:36 ---
> On second thought, this can work with the current implementation of
> mode-switching using pre_edge_lcm, since it will never insert a computation
> in a path if it hasn't been there before.
Yes, and that's why I think th
--- Comment #13 from amylaar at gcc dot gnu dot org 2006-08-25 16:33
---
(In reply to comment #12)
> As far as I can see, the i387 mode switching is already completely broken,
> because it treats the different modes of a single mode-switchable entity
> as separate entities.
On second t
--- Comment #12 from amylaar at gcc dot gnu dot org 2006-08-25 14:33
---
(In reply to comment #11)
> This potentially affects i686-pc-linux-gnu as it also uses the mode switching
> code. I think this should go in.
As far as I can see, the i387 mode switching is already completely brok
--- Comment #11 from bonzini at gnu dot org 2006-08-25 13:43 ---
This potentially affects i686-pc-linux-gnu as it also uses the mode switching
code. I think this should go in.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #10 from kkojima at gcc dot gnu dot org 2006-08-25 11:25
---
I've confirmed that it fixes the build failure on sh4-linux. I'll
send it to gcc-patches after the test on i686-linux is completed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-08-25 11:07 ---
(In reply to comment #8)
> Do you mean the patch like this?
Yes, indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
--- Comment #8 from kkojima at gcc dot gnu dot org 2006-08-25 10:56 ---
> And when the other code to handle abnormal edges is fixed, we should not
> even try to insert a mode set on an abnormal edge, so the above code can
> be changed into
> gcc_assert (! (eg_flags & EDGE_A
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-08-24 16:22 ---
(In reply to comment #0)
Actually, I think this code:
/* If this is an abnormal edge, we'll insert at the end
of the previous block. */
if (eg->flags & EDGE_ABNORMAL)
.
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-08-24 15:32 ---
(In reply to comment #5)
> > I think the only sane way to handle this is not to emit any mode
> > switching code for exception edges at the potential trapping site,
> > and make the exception handling code assume no
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-08-23 23:54 ---
> I think the only sane way to handle this is not to emit any mode
> switching code for exception edges at the potential trapping site,
> and make the exception handling code assume no particular mode is
> present (u
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-08-23 15:20 ---
As far as I can see, the only reason why we can have a REG_EH_REGION note
on a non-call instruction is when the instruction may trap, and we compile
with -fnon-call-exceptions.
(In reply to comment #3)
> Here is a w
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-08-23 04:35 ---
Here is a workaround. Although it doesn't solve the issue
completely, it'd be better than nothing. It prevents to
insert the mode switching code after the last insn of BB
when that insn has the REG_EH_REGION note.
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-08-20 22:50
---
SH is not a primary or secondary platform.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:24 ---
This a build regression. This is eh related.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
18 matches
Mail list logo