This is the mail archive of the mailing list for the GCC 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] PR 44869: Missing TARGET check - and wrong code or accepts-invalid?

Le 10.07.2010 18:22, Janus Weil a écrit :
Hi all,

this PR is concerned about a TARGET check failing for polymorphic
variables. It is one of those problems that seem easy to solve but
drag along a tail of other problems.

The TARGET check is basically fixed by the hunk in primary.c
(gfc_variable_attr). This fix then triggered the insight that the
'class_pointer' attribute should be used instead of the 'pointer'
attribute in all places where the attributes of a CLASS variable are
accessed via the CLASS_DATA macro. Applying this change everywhere
uncovered more dormant bugs:

1) The 'class_pointer' attribute was never written to the .mod files.
2) In some cases we prematurely created a class container before all
attributes were known. This is fixed by the hunks in decl.c.

The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?


2010-07-10 Janus Weil<>

	PR fortran/44689
	* decl.c (build_sym,attr_decl1): Only build the class container if the
	symbol has sufficient attributes.
	* expr.c (gfc_check_pointer_assign): Use class_pointer instead of
	pointer attribute for classes.
	* match.c (gfc_match_allocate,gfc_match_deallocate): Ditto.
	* module.c (MOD_VERSION): Bump.
	(enum ab_attribute,attr_bits): Add AB_CLASS_POINTER.
	(mio_symbol_attribute): Handle class_pointer attribute.
	* parse.c (parse_derived): Use class_pointer instead of pointer
	attribute for classes.
	* primary.c (gfc_variable_attr,gfc_expr_attr): Ditto.
	* resolve.c (resolve_structure_cons,resolve_deallocate_expr,
	resolve_allocate_expr,resolve_fl_derived): Ditto.
	(resolve_fl_var_and_proc): Check for class_ok attribute.

2010-07-10 Janus Weil<>

	PR fortran/44689
	* gfortran.dg/class_24.f03: New.
Yes, it is OK.

I'm wondering whether we should use a more descriptive module version numbering scheme in the future, such as 4.6-0, 4.6-1, ..., 4.7-0, ... instead of 5, 6, 7, ...
It would be good from a user point of view to have at least the major gcc version attached to it, especially in case one has more than one gcc installed.
What's everybody's opinion (think about backwards compatibility) ?


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