[Bug c/87345] New: The compiler of the old version (for example: 4.9.3 version or 6.3.0 version) can stop the infinite cross-border loop, but the new version does not work.

jingtian at loongson dot cn gcc-bugzilla@gcc.gnu.org
Tue Sep 18 07:18:00 GMT 2018


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

            Bug ID: 87345
           Summary: The compiler of the old version (for example: 4.9.3
                    version or 6.3.0 version) can stop the infinite
                    cross-border loop, but the new version does not work.
           Product: gcc
           Version: 8.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jingtian at loongson dot cn
  Target Milestone: ---

Created attachment 44713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44713&action=edit
this is *.i file

Hello, in fact, I don't know if this is a bug, or I don't know if the old
version of GCC can be tolerated, but the new version of GCC has the most
stringent requirements to have such a phenomenon. Since I started to forget to
forget to provide the return value in the void* type of function, but I am
compiling on a lower version of GCC, I tried versions 4.9 and 6.3. There was no
problem at this time, but when I used the newer versions 8.1 and 8.2, it
prompted me to have a Segmentation fault (core dumped).
If I normalize my writing, such as changing void* to void, or adding a return
NULL to the void* type of function, this problem can be solved.


Below is my gcc version information(This is how I made a docker on the mips
machine with a debain system installed.Similarly, I will use gcc 8.1.0 on
fedora28 to have the same situation.)

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/mips64el-linux-gnuabi64/8/lto-wrapper
Target: mips64el-linux-gnuabi64
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-4'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=mips64el-linux-gnuabi64- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-multilib
--with-mips-plt --with-arch-64=mips64r2 --with-madd4=no --enable-targets=all
--with-arch-32=mips32r2 --with-fp-32=xx --enable-checking=release
--build=mips64el-linux-gnuabi64 --host=mips64el-linux-gnuabi64
--target=mips64el-linux-gnuabi64
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-4) 


The GCC compile command I am using is :
gcc -g -O3 -o demotest demotest.cpp 
(The same use of O1 O2 O3 will have problems, but do not choose the
optimization option, only the -o option, there will be no such situation)

Here is my code:
#include "stdio.h"
#include "stdlib.h"
#include "string.h"
#include "ctype.h"
void *strlwr(char *str)
{

        for(; *str!='\0'; str++)
        {
                *str = tolower(*str);
        }
       //return NULL;
}

int main()
{
        char res[20];
        char a[20]="ABCDEFGhijklmn";
        memset(res,'\0',20*sizeof(char));
        strcpy(res,a);
        printf("%s\n",res);
        strlwr(res);
        printf("%s\n",res);     
        return 0;
}

This is the information that was reported during execution:
ABCDEFGhijklmn
Segmentation fault (core dumped)


I am seeing the instructions on the website, saying that this infinite loop
problem can be avoided by adding the -fno-aggressive-loop-optimizations option,
but I added this to the compile option, but it still doesn't work.

I just started to be a developer. My English is not particularly good. I have
seen the needs of the website for a long time. I don't know if I qualified to
submit this small question. If there is no good place to do it, I I am very
sorry, increasing your workload.


More information about the Gcc-bugs mailing list