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
+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
