On 04-Jan-16 23:24, Michael Felt wrote:
The bulk is on my forums - the final post for today is:
Results to date:
A. It looks like I am going to need a newer compiler for C - xlc/xlC
V11 apparently does not understand this code:
"/data/prj/cran/R-3.2.3/src/main/memory.c", line 2149.31: 1506-046 (S)
Syntax error.
I will have to check if R-devel has different code before asking for
assistence.
+2139 #ifdef HAVE_STDALIGN_H
+2140 # include <stdalign.h>
+2141 #endif
+2142
+2143 #include <stdint.h>
+2144
+2145 long double *R_allocLD(size_t nelem)
+2146 {
+2147 #if __alignof_is_defined
+2148 // This is C11: picky compilers may warn.
+2149 size_t ld_align = alignof(long double);
+2150 #elif __GNUC__
+2151 // This is C99, but do not rely on it.
+2152 size_t ld_align = offsetof(struct { char __a; long double
__b; }, __b);
+2153 #else
This is a hint/hack - with xlc V11 I get past a syntax "failure" with
something like the following:
#if __alignof_is_defined
long double ldbl = 0.0;
// This is C11: picky compilers may warn.
size_t ld_align = alignof(ldbl);
#elif __GNUC__
+2154 size_t ld_align = 0x0F; // value of x86_64, known others are 4
or 8
+2155 #endif
+2156 if (ld_align > 8) {
+2157 uintptr_t tmp = (uintptr_t) R_alloc(nelem + 1,
sizeof(long double));
+2158 tmp = (tmp + ld_align - 1) & ~ld_align;
+2159 return (long double *) tmp;
+2160 } else {
+2161 return (long double *) R_alloc(nelem, sizeof(long
double));
+2162 }
+2163 }
If someone has a suggestion for how to test/fix so that I can proceed
with an older xlc compiler, that would be great!
If not, I shall download the try and buy C compiler to test.
On 04-Jan-16 15:52, Simon Urbanek wrote:
No, no duplicate warnings.
B. There is a very big difference in the way libraries are made when
gcc/gfortran are not used.
When gcc is being used "everything" is being turned into a shared
library. The only library I seem to be able
to affect via configure is libR.so (yes/no). The snip here shows that
all members of the .a archives are
"non-shared" objects rather that a combined group of .o files into a
single .so shared object.
So, it is not surprising that there are no duplicate symbols.
cran@x068:[/home/cran/64/R]dump -H src/*/*.a | head
src/appl/libappl.a[integrate.o]:
Loader section is not available
src/appl/libappl.a[interv.o]:
Loader section is not available
src/appl/libappl.a[maxcol.o]:
>FYI: I shall be downloading the "try and buy" xlc and xlfortran -
and I think you will certainly prefer my packaging then as they work
without the libgc dependencies that many of the rpm packages need.
>
>And, at your option - we can take this discussion over tools - "out
of forums". Or at least start a new thread.
>
We could leave the list out and create a Wiki or something with the
results of our tests.
>re: unsigned short - I have adopted the convention to use the *NN_t
types after running into a problem with unsigned longlong (from a
very old program). It goes back many years - and maybe they have
finalized short to mean 16-bits - but I remember when short was
meant to help when moving from 16-bit to 32-bit and the "word" size
changed - i.e., int became 32-bit same as long. nd for a long (no
pun intended) long was 32-bit and long long was 64-bit. Those
definitions are extinct.
>
I'm not sure what you refer here - the issue with TRE has nothing to
do with short - it can take any int type and like I said most
platforms use unsigned int which is big enough on all platforms.
>imho - the standard for wint_t is wrong as well - based on an
assumption about how "short" is defined. And, I consider it poor
practice that there are som many cases of type cast switches between
ushort and int.
>
Not really - it doesn't care about short at all - note that the short
typedef is never actually used on AIX since it has wchar support so
TRE is only using int.
Cheers,
Simon
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
