--- Comment #13 from rguenth at gcc dot gnu dot org 2009-07-14 09:34
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-07-14 09:33
---
Subject: Bug 38921
Author: rguenth
Date: Tue Jul 14 09:32:55 2009
New Revision: 149620
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149620
Log:
2009-07-14 Richard Guenther
Backport from mainl
--- Comment #11 from bonzini at gnu dot org 2009-02-06 09:06 ---
See 39110 for another patch that would need to be backported (thinko fix).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38921
--- Comment #10 from bonzini at gnu dot org 2009-02-04 20:54 ---
Subject: Bug 38921
Author: bonzini
Date: Wed Feb 4 20:54:36 2009
New Revision: 143939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143939
Log:
2009-02-04 Paolo Bonzini
Hans-Peter Nilsson
--- Comment #9 from hp at gcc dot gnu dot org 2009-02-03 17:46 ---
Created an attachment (id=17237)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17237&action=view)
Proposed fix
Also folds may_trap_after_code_motion_p into may_trap_or_fault_p, as being the
original semantics.
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-24 10:21 ---
GCC 4.3.3 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from hp at gcc dot gnu dot org 2009-01-21 22:00 ---
(In reply to comment #6)
> However, I suspect that all the places that use may_trap_after_code_motion_p
> in
> fact expect it to have MTP_AFTER_MOVE | MTP_UNALIGNED_MEMS semantics as well.
Me too.
> So I would propose
--- Comment #6 from rakdver at gcc dot gnu dot org 2009-01-21 16:41 ---
(In reply to comment #4)
> Zdenek, could you please comment on comment #3?
>
Adding MTP_AFTER_MOVE seems like the right thing to do; after all, even the
comments for may_trap_or_fault_p specify that it should behav
--- Comment #5 from hp at gcc dot gnu dot org 2009-01-21 04:17 ---
(In reply to comment #3)
> For may_trap_or_fault_p, the current only callers are
> resource.c (reorg.c's old friend) ...
Typo/thinko; it's actually reorg.c itself, resource.c isn't involved.
--
http://gcc.gnu.org/bu
--- Comment #4 from hp at gcc dot gnu dot org 2009-01-21 03:48 ---
Zdenek, could you please comment on comment #3?
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from hp at gcc dot gnu dot org 2009-01-21 03:46 ---
Created an attachment (id=17156)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17156&action=view)
Fix.
Looks like reorg.c wasn't to blame after all. Changes were made to
may_trap_or_fault_p that made them stop con
--- Comment #2 from hp at gcc dot gnu dot org 2009-01-20 10:38 ---
To fit in gcc.dg/torture, the test needs a
/* { dg-do run } */
at the top.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38921
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.3.3
http://gcc
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-20 03:57 ---
Created an attachment (id=17150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17150&action=view)
testcase
Compile at -O2. Run in simulator (note the linker option) or compile with -O2
-S and observe:
mov
14 matches
Mail list logo