This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: intrinsic.c (compare_actual_formal)


On Wednesday 05 May 2010 21:27:31 Tobias Burnus wrote:
> I think the reason for the "if (where)" is that the
> compare_actual_formal is also used for the generic resolution, where one
> only want to know whether a call to a generic procedure is conform with
> a given specific procedure or not. This is done via the call
> gfc_arglist_matches_symbol, which sets where to NULL.

Hi Tobias,

in both related PRs, PR34805 and PR35267, we deal with user defined 
assignement operators. If your conjecture is correct, I'd assume that 
compare_actual_formal should be called twice, once for the interface 
correctness check you mention (where == NULL) and once for the actual argument 
check (where != NULL). However, compare_actual_formal is called only once with 
the backtrace shown below.

It appears that one now may remove the blocking "if (where)" or try to find 
the right place to call compare_actual_formal again. Which would you think is 
the more correct fix?

Cheers

	Daniel


Breakpoint 1, compare_actual_formal (ap=0xbfffeedc, formal=0x8bf9160, 
ranks_must_agree=0, is_elemental=1, where=0x0) at /home/daniel/svn/gcc-
svn/gcc/fortran/interface.c:2139
2139              if (where)
(gdb) bt
#0  compare_actual_formal (ap=0xbfffeedc, formal=0x8bf9160, 
ranks_must_agree=0, is_elemental=1, where=0x0) at /home/daniel/svn/gcc-
svn/gcc/fortran/interface.c:2139
#1  0x080f6f65 in gfc_arglist_matches_symbol (args=0xbfffeedc, sym=0x8bf8210) 
at /home/daniel/svn/gcc-svn/gcc/fortran/interface.c:2625
#2  0x080f7007 in gfc_search_interface (intr=0x8bc0db0, sub_flag=1, 
ap=0xbfffeedc) at /home/daniel/svn/gcc-svn/gcc/fortran/interface.c:2654
#3  0x080f7c9a in gfc_extend_assign (c=0x8bfa740, ns=0x8bc0240) at 
/home/daniel/svn/gcc-svn/gcc/fortran/interface.c:3012
#4  0x081401f5 in resolve_ordinary_assign (code=0x8bfa740, ns=0x8bf9658) at 
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7993
#5  0x08140b57 in resolve_code (code=0x8bfa740, ns=0x8bf9658) at 
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:8308
#6  0x0814a551 in resolve_codes (ns=0x8bf9658) at /home/daniel/svn/gcc-
svn/gcc/fortran/resolve.c:12728
#7  0x0814a461 in resolve_codes (ns=0x8bc0240) at /home/daniel/svn/gcc-
svn/gcc/fortran/resolve.c:12714
#8  0x0814a629 in gfc_resolve (ns=0x8bc0240) at /home/daniel/svn/gcc-
svn/gcc/fortran/resolve.c:12755
#9  0x0812b0af in gfc_parse_file () at /home/daniel/svn/gcc-
svn/gcc/fortran/parse.c:4292
#10 0x0816aaca in gfc_be_parse_file (set_yydebug=0) at /home/daniel/svn/gcc-
svn/gcc/fortran/f95-lang.c:239
#11 0x08485cbb in compile_file () at /home/daniel/svn/gcc-
svn/gcc/toplev.c:1053
#12 0x08487d82 in do_compile () at /home/daniel/svn/gcc-svn/gcc/toplev.c:2423
#13 0x08487e48 in toplev_main (argc=4, argv=0xbffff3e4) at 
/home/daniel/svn/gcc-svn/gcc/toplev.c:2465
#14 0x081c069b in main (argc=4, argv=0xbffff3e4) at /home/daniel/svn/gcc-
svn/gcc/main.c:35


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]