[Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9

[Tomas Kalibera]

On 4/17/21 6:55 PM, Tomas Kalibera wrote:
> Thank you Ryan and Ivan for reporting and debugging this. Godbolt.org 
> shows that icc 19.0.1 with -O2 -ipo (inter-procedural optimizations) 
> is too smart and optimizes this stack growth detection code so that it 
> returns incorrect result on x86_64. Detecting stack growth from C is 
> tricky - in principle, it cannot be done correctly in a portable way. 
> As the compilers are getting more sophisticated, it is increasingly 
> more difficult. We'll have to improve the test, perhaps re-using some 
> or completely remove it and assume stack grows down. I doubt anyone 
> today would run a real, non-emulated, system running R where stack 
> would grow up.
>
> (and yes, the elif conditional should use 255)

I've updated the test for direction of stack growth in R-devel.
If there are any remaining issues, please report.

Thanks
Tomas

>
> Tomas
>
>
> On 4/17/21 11:40 AM, Ivan Krylov wrote:
>> On Fri, 16 Apr 2021 18:39:04 +0000
>> Ryan Novosielski <novosirj using rutgers.edu> wrote:
>>
>>> I guess there’s probably some mode of m4 I could run against that and
>>> see if there’s any indication?
>> Here's a shell script that should be doing the same thing that
>> R's .../configure does, but a bit more verbose:
>>
>> -----------------------------------8<-----------------------------------
>> #!/bin/sh
>> cat > conftest1.c <<EOF
>> #include <stdint.h>
>> uintptr_t dummy_ii(void)
>> {
>>      int ii;
>>
>>      /* This is intended to return a local address. We could just return
>>         (uintptr_t) &ii, but doing it indirectly through ii_addr avoids
>>         a compiler warning (-Wno-return-local-addr would do as well).
>>      */
>>      volatile uintptr_t ii_addr = (uintptr_t) ⅈ
>>      return ii_addr;
>> }
>> EOF
>> cat > conftest.c <<EOF
>> #include <stdio.h>
>> #include <stdint.h>
>> extern uintptr_t dummy_ii(void);
>>
>> typedef uintptr_t (*dptr_type)(void);
>> volatile dptr_type dummy_ii_ptr;
>>
>> int main(int ac, char **av)
>> {
>>      int i;
>>      dummy_ii_ptr = dummy_ii;
>>               /* call dummy_ii via a volatile function pointer to 
>> prevent
>>         inlinining in case the tests are accidentally built with
>>         LTO */
>>      uintptr_t ii = dummy_ii_ptr();
>> #ifndef EXACTLY_AS_R_CONFIGURE
>>      printf(
>>          "main = %p, sub = %p, main %c sub, ret = %d\n",
>>          &i, (void*)ii,
>>          ((uintptr_t)&i > ii) ? '>' : ((uintptr_t)&i < ii) ? '<' : '=',
>>          ((uintptr_t)&i > ii) ? 1 : -1
>>      );
>> #endif
>>      /* 1 is downwards */
>>      return ((uintptr_t)&i > ii) ? 1 : -1;
>> }
>> EOF
>> echo "${CC:=cc} ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} ${MAIN_LDFLAGS}" \
>>      "-o conftest conftest.c conftest1.c"
>> ${CC} ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} ${MAIN_LDFLAGS} -o conftest \
>>      conftest.c conftest1.c || exit $?
>> echo ./conftest
>> ./conftest
>> ret=$?
>> echo "./conftest exited with $ret"
>> if test ${ret} = 1; then
>>    echo r_cv_cstack_direction=down
>> elif test ${ret} = 1; then
>>    echo r_cv_cstack_direction=up
>> fi
>> exit 0
>> -----------------------------------8<-----------------------------------
>>
>> Please run it similarly to the way you run .../configure:
>>
>> export CC=icc
>> export CFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
>> sh .../runme.sh
>>
>> Does it give the right answer, that is, r_cv_cstack_direction=down?
>> Does the answer change if you add -DEXACTLY_AS_R_CONFIGURE to CFLAGS?
>> If the answer is always "down" and you have reused the build directory
>> (keeping the config.site file between .../configure runs), this is going
>> to be hard to track down. If you manage to get the "up" answer, it
>> should be possible to tweak the test until ICC doesn't optimise it to
>> the point of confusing the stack growth direction.
>>
>> Either way, I think that the elif branch in the R_STACK_DIRECTION test
>> should be testing for $? = 255, not 1. I'm almost convinced that the
>> behaviour would be incorrect on platforms where the test exits with -1.
>>
>