Hello world,
this fixes a 7/8/9 regression. The problem is that front-end inlining
of matmul could generate calls to _gfortran_runtime_error which were
called as non-variadic. This fixes the problem by setting the
backend_decl on the resovled symbol, so it always uses the right one.
Putting it into the resolution stage seems a bit strange, but I tried
several other methods such as putting it into the global symbol table,
and nothing else I tried worked.
You can check on x86_64 if the patch works by doing
$ cat nn.f90
module x
contains
subroutine mm(a,b,c)
real, dimension(:) :: a, c
real, dimension(:,:) :: b
c = matmul(a,b)
end subroutine mm
end module x
$ gfortran -S -O -fcheck=bounds nn.f90
and then looking for code snippets like
movl $89, %ecx
movq %rdi, %rdx
movl $.LC0, %edi
movl $0, %eax
call _gfortran_runtime_error
where setting %eax to zero indicates that we are indeed using
varargs, because %eax contains the number of float arguments,
which is zero.
No test case, because there is not really a good way to check for this.
So, OK for trunk?
Regards
Thomas
2019-03-17 Thomas Koenig <[email protected]>
PR fortran/68009
* iresolve.c: Include trans.h.
(gfc_resolve_fe_runtine_error): Set backend_decl on
resolved_sym.
Index: iresolve.c
===================================================================
--- iresolve.c (Revision 269624)
+++ iresolve.c (Arbeitskopie)
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3. If not see
#include "intrinsic.h"
#include "constructor.h"
#include "arith.h"
+#include "trans.h"
/* Given printf-like arguments, return a stable version of the result string.
@@ -2495,6 +2496,10 @@ gfc_resolve_fe_runtime_error (gfc_code *c)
a->name = "%VAL";
c->resolved_sym = gfc_get_intrinsic_sub_symbol (name);
+ /* We set the backend_decl here because runtime_error is a
+ variadic function and we would use the wrong calling
+ convention otherwise. */
+ c->resolved_sym->backend_decl = gfor_fndecl_runtime_error;
}
void
