This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/53190] CSE (?) CSEs asms
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 03 May 2012 07:59:40 +0000
- Subject: [Bug rtl-optimization/53190] CSE (?) CSEs asms
- Auto-submitted: auto-generated
- References: <bug-53190-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53190
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-03 07:59:40 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (clobber (reg:QI 18 fpsr))
> > (clobber (reg:QI 17 flags))
> >
> >
> > It might clobber those but that is not considered an use. So CSE is doing the
> > correct thing as there is no use based on fpsr.
>
> The asm that depends on some unknown-to-gcc global processor state should be
> marked as volatile.
>
> This is a bug in glibc.
>
> As a side note, mathinline.h really needs some serious TLC, there are many
> functions that are much better implemented with gcc builtin functions, not to
> mention that x87 asm in 32bit case interferes *badly* with -mfpmath=sse.
>
> Fortunately, there is -D__NO_MATH_INLINES, used in my projects from day one.
>
> Really, there is no justification for mathinline.h to live, as far as gcc is
> concerned.
So you say that it's correct for CSE to CSE asm()s if they have the same
asm string and the same asm operands in case the asm is not volatile? I was
not aware we would do that ;) (but yes, it sounds like a reasonable thing)