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: [Patch, Fortran] OOP cleanup part 2


So, here goes the ChangeLog for this patch. Finally.

Also: Ping.

Cheers,
Janus



2010-05-29  Janus Weil  <janus@gcc.gnu.org>

	* gcc/fortran/gfortran.h (CLASS_DATA): New macro for accessing the
	$data compoenent of a class container.
	* gcc/fortran/decl.c (attr_decl1): Use macro CLASS_DATA.
	* gcc/fortran/expr.c (gfc_check_pointer_assign,gfc_check_assign_symbol,
	gfc_has_ultimate_allocatable,gfc_has_ultimate_pointer): Ditto.
	* gcc/fortran/interface.c (matching_typebound_op): Ditto.
	* gcc/fortran/match.c (gfc_match_allocate, gfc_match_deallocate): Ditto.
	* gcc/fortran/parse.c (parse_derived): Ditto.
	* gcc/fortran/primary.c (gfc_match_varspec, gfc_variable_attr,
	gfc_expr_attr): Ditto.
	* gcc/fortran/resolve.c (resolve_structure_cons, find_array_spec,
	resolve_deallocate_expr, resolve_allocate_expr, resolve_select_type,
	resolve_fl_var_and_proc, resolve_typebound_procedure,
	resolve_fl_derived): Ditto.
	* gcc/fortran/symbol.c (gfc_type_compatible): Restructured.
	* gcc/fortran/trans-array.c (structure_alloc_comps): Use macro
	CLASS_DATA.
	* gcc/fortran/trans-decl.c (gfc_get_symbol_decl,
	gfc_trans_deferred_vars): Ditto.
	* gcc/fortran/trans-stmt.c (gfc_trans_allocate): Ditto.



2010/5/24 Janus Weil <janus@gcc.gnu.org>:
> Hi all,
>
> here is another cleanup patch for OOP. It simply introduces the
> following macro in gfortran.h (as proposed by Paul):
>
> #define CLASS_DATA(sym) sym->ts.u.derived->components
>
> It often happens that we need to access the $data component of a class
> container, and the macro does exactly that ($data is the first
> component of the class container). I tried to apply the macro in all
> places where it's suitable and hope I forgot none.
>
> One place where the macro unfortunately cannot be applied for
> technical reasons is 'gfc_type_compatible' (still I made some
> modifications on this) and the beginning of 'resolve_fl_derived'.
>
> Paul, is this what you had in mind? Or are there more clever ways to do it?
>
> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
> (With a ChangeLog, which I yet have to construct).
>
> Cheers,
> Janus
>


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