patch to both
copies in gnutls, test-stdalign passes, as does everything else.
Thanks for your gnulib patch!
Fang
David Fang wrote:
Hi Paul,
I tried applying the patch (just the stdalign.in.h bit) to the
powerpc-darwin8 build, but I still see (when changing the assert to
printf
t
#define __WINT_TYPE__ int
+#define __bool __attribute__((altivec(bool__))) unsigned
+#define __pixel __attribute__((altivec(pixel__))) unsigned short
#define __ppc__ 1
#define __strong
+#define __vector __attribute__((altivec(vector__)))
#define __weak
Fang
--
David Fang
http://www.csl.cornell.edu/~fang/
'm not entirely sure what is different between them.
If you have any suggestions, I can try them tonight.
Fang
David Fang wrote:
> Does this mean that it falls back to the distributed copy in
> gl/stdalign.h?
Yes, actually, it's basically a copy of gl/stdalign.in.h.
>
e any suggestions, I can try them tonight.
Fang
David Fang wrote:
Does this mean that it falls back to the distributed copy in
gl/stdalign.h?
Yes, actually, it's basically a copy of gl/stdalign.in.h.
I don't see any evidence of the replacement stdalign.h being tested in
co
Hi Paul,
On 12/15/2014 04:47 PM, David Fang wrote:
_alignas and _Alignas are broken on your platform, even with gnulib trying to
work around the breakage.
Is there a problem in the compiler, or rather some incorrect assumption
about the ABI in the test itself? This is the system compiler
tional data structure alignment
rules in its ABI. How should these results be interpreted?
Is there a problem in the compiler, or rather some incorrect assumption about
the ABI in the test itself? This is the system compiler, after all.
Thanks for any insights.
Fang
--
David Fang
http://www.csl.cornell.edu/~fang/
tional data structure
alignment rules in its ABI. How should these results be interpreted?
Is there a problem in the compiler, or rather some incorrect assumption
about the ABI in the test itself? This is the system compiler, after all.
Thanks for any insights.
Fang
--
David Fang
http://www.csl.cornell.edu/~fang/