https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #9 from Jakub Jelinek ---
Isn't this fixed by r12-4693-g90205f67e465ae7dfcf733c2b2b177ca7ff68da0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #8 from Segher Boessenkool ---
Created attachment 51664
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51664&action=edit
proposed patch
This is the patcgh I am currently testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
H.J. Lu changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #7 from H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
H.J. Lu changed:
What|Removed |Added
See Also||https://github.com/libffi/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #5 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #4)
> > At least in linux64_closure.S, perhaps guarding it with #ifdef __VEC__ might
> > be ok, because the C code will not use that code if __VEC__ isn't defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #4 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #1)
> The stvx stuff is guarded by #ifdef __VEC__, so perhaps the lvx stuff should
> be too, or there should be .machine push; .machine power7; ... .machine pop;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #3 from H.J. Lu ---
powerpc64-unknown-linux-gnu works with libffi upstream on
gcc110.fsffrance.org.
