https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41239
Andrew Pinski changed:
What|Removed |Added
CC||tiamat at komi dot mts.ru
--- Comment #7
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41239
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-08 09:35 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-08 09:26 ---
Subject: Bug 41239
Author: jakub
Date: Tue Sep 8 09:25:47 2009
New Revision: 151500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151500
Log:
PR rtl-optimization/41239
* sched-int.h (struct d
--- Comment #4 from vmakarov at redhat dot com 2009-09-03 21:40 ---
Oh well, another haifa-scheduler integration issue after so many years to
integrate it into GCC. It looks like the original haifa-scheduler treated
calls as always returning.
I think you should use last_function_ca
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-03 20:11 ---
Looking at sched-deps.c, it might be easiest for may_trap_p insns to be queued
onto deps->sched_before_next_call chain, but I'm not sure whether we want to do
that for all, or if it should ignore trapping memory as tha
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-03 10:31 ---
We can never move maybe trapping instructions across a function call that might
not return (and as we don't have an attribute for returns_always we have to
assume that a function may not return always apart from mayb
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-03 09:24 ---
sched-deps.c uses may_trap_p only to find out what insns can't be speculated,
possibly trapping MEMs are handled by deps_may_trap_p.
I wonder what exactly we want to forbid to cure this testcase.
Just DIV/MOD/UDIV/UMOD
