[Bug fortran/108349] LTO mismatch for __builtin_realloc between glibc and gfortran frontend

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |tschwinge at gcc dot gnu.org,
                   |                            |vries at gcc dot gnu.org

--- Comment #6 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
As nvptx target is known to be sensitive to such mismatches (outside of the LTO
context reported here), I individually did test this commit
r13-5100-g0986c351aa8a9f08b3cb614baec13564dd62c114 "fortran: Fix up function
types for realloc and sincos{,f,l} builtins [PR108349]", and found that it also
resolves the following nvptx target compilation failures:

'gfortran.dg/pr35662.f90':

    ptxas /tmp/ccYNgEEN.o, line 44; error   : Illegal operand type to
instruction 'st'
    ptxas /tmp/ccYNgEEN.o, line 51; error   : Type of argument does not match
formal parameter '%in_ar0'
    ptxas /tmp/ccYNgEEN.o, line 51; error   : Alignment of argument does not
match formal parameter '%in_ar0'
    ptxas /tmp/ccYNgEEN.o, line 44; error   : Unknown symbol '%stack'
    ptxas fatal   : Ptx assembly aborted due to errors
    nvptx-as: ptxas returned 255 exit status

'gfortran.fortran-torture/compile/pr37236.f':

    ptxas [...]/build-gcc/gcc/testsuite/gfortran/pr37236.o, line 269; error   :
Illegal operand type to instruction 'st'
    ptxas [...]/build-gcc/gcc/testsuite/gfortran/pr37236.o, line 275; error   :
Type of argument does not match formal parameter '%in_ar0'
    ptxas [...]/build-gcc/gcc/testsuite/gfortran/pr37236.o, line 269; error   :
Unknown symbol '%stack'
    ptxas fatal   : Ptx assembly aborted due to errors
    nvptx-as: ptxas returned 255 exit status

These are now all-PASS.


In the nvptx target gfortran test suite logs remain however dozens more similar
instances.  I've not checked if what's underlying those would also be exposing
the same kind of LTO problem.