--- Comment #26 from pinskia at gcc dot gnu dot org 2008-09-23 23:50
---
*** Bug 37631 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
19:48 ---
*** Bug 24165 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From das at FreeBSD dot ORG 2005-01-14 21:34
---
Here's another test case that shows that gcc 3.4.2 on i386 will reschedule other
instructions (in particular, other asms that are not volatile) across a volatile
asm:
#include
#define __fldenv(env) __asm
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 01:33
---
In reply to comment #20:
Again, this is not scheduling, per se. This is register
rematerialization. We have a value at some point, and we
decide that it's cheaper to move the computation rather
than store and
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-02 07:18
---
No one suggested anything for clarification, but I don't see a bug here.
--
What|Removed |Added
--- Additional Comments From dalej at apple dot com 2005-02-02 18:19
---
Actually I adjusted the doc to my satisfaction in this thread:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01048.html
I suppose it's OK to close now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17884
--- Additional Comments From schlie at comcast dot net 2005-02-02 22:16
---
(In reply to comment #23)
Just to double check, however as may be required, instructions which
may be affected by a modifyable control register state may denote that
dependance in the instruction's rtl descript
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-12 17:39 ---
Ah, I see some amount of confusion here.
Yes, in the referenced message I do argue for "asm volatile" to be a scheduling
barrier. You'll note that what I'm most concerned about there is that the asm
remain in t
--- Additional Comments From dalej at apple dot com 2004-10-12 18:30 ---
OK, thanks. From this it appears that the only effect of 'asm volatile' that users
can safely rely on is that such an instruction will not be deleted. If this is
agreeable to everybody, I will revise the documentat