[r12-2511 Regression] FAIL: gfortran.dg/PR93963.f90 -Os execution test on Linux/x86_64

[r12-2511 Regression] FAIL: gfortran.dg/PR93963.f90 -Os execution test on Linux/x86_64

[sunil.k.pandey]

On Linux/x86_64,

0cbf03689e3e7d9d6002b8e5d159ef3716d0404c is the first bad commit
commit 0cbf03689e3e7d9d6002b8e5d159ef3716d0404c
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Mon Jul 26 14:20:46 2021 +0200

    PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling

caused

FAIL: gfortran.dg/PR93963.f90   -O2  execution test
FAIL: gfortran.dg/PR93963.f90   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/PR93963.f90   -O3 -g  execution test
FAIL: gfortran.dg/PR93963.f90   -Os  execution test

with GCC configured with

../../gcc/configure --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2511/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/PR93963.f90 --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/PR93963.f90 --target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me at skpgkp2 at gmail dot com)

Re: [r12-2511 Regression] FAIL: gfortran.dg/PR93963.f90 -Os execution test on Linux/x86_64

[Tobias Burnus]

The automatic regression test of Sunil wrote:

On 26.07.21 19:27, sunil.k.pandey wrote:
> commit 0cbf03689e3e7d9d6002b8e5d159ef3716d0404c
>      PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling
> caused
> FAIL: gfortran.dg/PR93963.f90   -O2  execution test
> ...

(That's on x86-64-gnu-linux but (only) with -m32.)

I have filled: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101635

Let's see how soon we can fix this – otherwise, we have to XFAIL this testcase.

I don't completely understand why this only occurred with -m32,
but I believe it is an alias issue. The whole handling of the conversion
(prep code, library call, post-library handling) looks extremely fragile
and this is not the first issue in that this code causes.

I think the proper solution – having tons of advantages - is to move the
library code to the compiler itself and making use of the compile-time
known type, rank, etc. knowledge.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955