https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82133

            Bug ID: 82133
           Summary: unroll-loops too aggressive
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nickpapior at gmail dot com
  Target Milestone: ---

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/generic/gcc/7.2.0/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix /opt/generic/gcc/7.2.0
--with-gmp=/opt/generic/gcc/7.2.0 --with-mpfr=/opt/generic/gcc/7.2.0
--with-mpc=/opt/generic/gcc/7.2.0 --with-isl=/opt/generic/gcc/7.2.0
--enable-lto --enable-threads --with-quad --with-multilib-list=m64
--enable-languages=c,c++,fortran,objc,obj-c++,go
Thread model: posix
gcc version 7.2.0 (GCC) 

The following bug has been confirmed by other parts and runned using these
variants:

 - SuSE tumbleweed with system GCC 7.1.1, Atom core
 - Debian stretch with custom 7.1.0 and 7.2.0 builds (according to flags
above), Haswell core
 - Another distribution (see martin-frbg user in below link).

As several 7.X versions are found; assigned 7.0.


When using unroll-loops to compile OpenBLAS (0.2.20 and developer) it produces
seg-faults when running the tests.
It happens at these minimum compilation options:

  -O1 -funroll-loops -fipa-ra

As long as -funroll-loops isn't in the compilation flags everything works as
expected (even for much higher optimization levels: -O3
-fexpensive-optimizations -ftree-vectorize -fprefetch-loop-arrays
-march=native)

It only happens with compilation with optimization, so a backtrace is unusable
(I am not experienced enough to run gdb efficiently).

An invalid memory reference is triggered:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.


I have filed a bug-report with OpenBLAS too and they indicate that it is
because GCC unrolls a loop one to many times.
For the discussion see here: https://github.com/xianyi/OpenBLAS/issues/1292


The bug can be reproduced by using this small script (in the OpenBLAS
directory):
###
#!/bin/bash

function run_all {
    echo "CFLAGS = $CFLAGS"
    echo "FCFLAGS = $FCFLAGS"
    make clean > /dev/null
    make COMMON_OPT="$CFLAGS" FCOMMON_OPT="$FCFLAGS" BINARY=64 SANITY_CHECK=1
MAX_STACK_ALLOC=2048 NUM_THREADS=48 USE_THREAD=0 libs netlib shared 2>
${1}_compilation.out > ${1}_compilation.out
    make COMMON_OPT="$CFLAGS" FCOMMON_OPT="$FCFLAGS" BINARY=64 SANITY_CHECK=1
MAX_STACK_ALLOC=2048 NUM_THREADS=48 USE_THREAD=0 tests 2> $1.out > $1.out
}
which gcc
sleep 1

unset FCFLAGS
unset CFLAGS
export CFLAGS="-O1 -funroll-loops -fipa-ra"
export FCFLAGS="$CFLAGS"
run_all minimum
###

Reply via email to