[Patch, fortran] PR 37131, inline matmul
Thomas Koenig
tkoenig@netcologne.de
Tue Jul 21 19:49:00 GMT 2015
Am 21.07.2015 um 19:26 schrieb Mikael Morin:
> Le 20/07/2015 23:55, Thomas Koenig a écrit :
>> Hi,
>>
>> I'm back from holiday, so I can finally reply.
>>
>>
>> Am 13.07.2015 um 21:54 schrieb Thomas Schwinge:
>>
>>> --- gcc/fortran/iresolve.c
>>> +++ gcc/fortran/iresolve.c
>>> @@ -2207,6 +2207,9 @@ gfc_resolve_fe_runtime_error (gfc_code *c)
>>> a->name = "%VAL";
>>>
>>> c->resolved_sym = gfc_get_intrinsic_sub_symbol (name);
>>> + //TODO
>>> + extern tree gfor_fndecl_runtime_error;
>>> + c->resolved_sym->backend_decl = gfor_fndecl_runtime_error;
>>> }
>>
>> This patch actually works quite well. I cannot check the varargs part
>> on x86_64, but the non-return part is OK. Obviously, the backend decl
>> for runtime_error needs to be set.
>>
>> The question is where to put this. iresolve.c seems conceptually wrong,
>> but I cannot find a clean place to put this in trans-*, without
>> special casing in strange places.
>>
>
> For what it's worth, I had started hacking on this; I attach what it
> looks like after a few cleanups.
This looks OK. You're right, it is more clean (although it replaces
a one-line patch with a 150-line one :-)
> I would like to avoid the hack in iresolve. So let's reuse the
> frontend-passes.c part of my patch (set resolved_isym)
I would much prefer if that was put into gfc_resolve_fe_runtime_error,
next to the assignment to c->resolved_sym.
> and then handle
> it in gfc_conv_intrinsic_subroutine, the way my patch does it (I'm not
> sure it actually fixes anything) or some other way (set
> resolved_sym->backend_decl as in iresolve, ...).
It does actually fix the issue. One way of constructing a test case
is to run
$ gfortran -fdump-tree-optimized -fno-realloc-lhs -fcheck=all -O -S
inline_matmul_2.f90
and count the number of calls to "_gfortran_runtime_error " in the
*.optimized dump (without the _at). It should be zero.
So, OK from my side with the change above and corresponding test case.
Regards
Thomas
More information about the Fortran
mailing list