Hi all, here is a second patch for PR 51081, which fixes the rejection of the valid test case in comment 1.
The problem was that the checking for intrinsics came too early (in
gfc_match_rvalue), so that INT2 was marked as intrinsic, before it was
known that there is a contained procedure which shadows the intrinsic.
I have moved the check to resolution stage (resolve_symbol), where it
is done for all flavorless symbols. One has to be a bit careful here
with variable names which collide with intrinsic procedures. Initially
there were a couple of testsuite failures due to this, most of which I
have killed by checking if the symbol's type is known.
However, one testsuite failure was left
(gfortran.fortran-torture/compile/pr39937.f), for which I think it is
basically impossible to decide that 'SCALE' is meant to be a variable
name, and not an intrinsic procedure. So my interpretation would be
that SCALE refers to the intrinsic here, which makes the test case
invalid. I changed the name of the variable to make it valid. That
test case is apparently a reduction of a larger code (from SPEC CPU
2006), which hopefully will not fail due to this patch (unfortunately
I cannot check this).
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2012-07-29 Janus Weil <ja...@gcc.gnu.org>
PR fortran/51081
* primary.c (gfc_match_rvalue): Check for intrinsics came too early.
* resolve.c (resolve_symbol): Check if flavorless symbols could be
intrinsic.
2012-07-29 Janus Weil <ja...@gcc.gnu.org>
PR fortran/51081
* gfortran.fortran-torture/compile/pr39937.f: Modified.
* gfortran.dg/proc_ptr_37.f90: New.
pr51081_part2.diff
Description: Binary data
proc_ptr_37.f90
Description: Binary data
