http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440
--- Comment #11 from Richard Earnshaw rearnsha at gcc dot gnu.org 2010-11-13
23:08:31 UTC ---
Author: rearnsha
Date: Sat Nov 13 23:08:26 2010
New Revision: 166723
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166723
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-04-22 23:21
---
*** Bug 43860 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ramana at gcc dot gnu dot org 2010-03-21 09:23 ---
(In reply to comment #5)
The proper solution seems to be extremely simple to me and it should do
exactly
the same what an application programmer would do to workaround the bug. Just
when initially parsing
--- Comment #8 from siarhei dot siamashka at gmail dot com 2010-03-21
10:05 ---
What about just forbidding to use q registers in the inline assembly clobber
list? Is it difficult to do?
As a nice bonus, the existing potentially unsafe inline assembly will fail to
compile, will be
--- Comment #9 from ramana at gcc dot gnu dot org 2010-03-21 13:41 ---
(In reply to comment #8)
What about just forbidding to use q registers in the inline assembly clobber
list? Is it difficult to do?
It's not difficult to -
The patch only penalises the cases where an sreg ends
--- Comment #2 from ramana at gcc dot gnu dot org 2010-03-20 10:51 ---
TARGET_MD_ASSEMBLE_CLOBBERS might just be the help we need on this one - I
think I have a patch which generates the following code. Does that look any
better to you ?
foo:
@ args = 0, pretend = 0, frame =
--- Comment #3 from batuzovk at ispras dot ru 2010-03-20 12:35 ---
(In reply to comment #2)
Does that look any better to you ?
Yes, definitely better. Thank you for quick response.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-20 12:42 ---
Patch submitted here for comments.
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00925.html
IMO the reasons as described in my email is another motivation for Neon
programmers to be using intrinsics rather than
--- Comment #5 from siarhei dot siamashka at gmail dot com 2010-03-21
03:33 ---
I don't quite understand what's the problem: This patch has the unhappy side
effect of clobbering s0, s1 and s2 if s3 is used because that's the only way we
can indicate that q0 is clobbered by the write to
--- Comment #6 from siarhei dot siamashka at gmail dot com 2010-03-21
03:56 ---
(In reply to comment #4)
IMO the reasons as described in my email is another motivation for Neon
programmers to be using intrinsics rather than inline assembler and to improve
in general Neon
--- Comment #1 from ramana at gcc dot gnu dot org 2010-03-19 13:32 ---
Yes, there is no easy way of describing the container relationship of the Neon
registers to the compiler at the minute. Thus the only work around at the
moment is to indicate that all the registers contained as part
12 matches
Mail list logo
