This is the mail archive of the gcc-patches@gcc.gnu.org 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?


>> 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?
>>
>> Cheers,
>> Janus
>>
>>
>>
>> 2010-07-10 ?Janus Weil<janus@gcc.gnu.org>
>>
>> ? ? ? ?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<janus@gcc.gnu.org>
>>
>> ? ? ? ?PR fortran/44689
>> ? ? ? ?* gfortran.dg/class_24.f03: New.
>
> Yes, it is OK.

Thanks, Mikael. Committed as r162052.



> 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) ?

On the one hand I agree that it would be useful to have a connection
between the module version and the gfortran version. On the other hand
we should not introduce artificial incompatibilities by bumping the
module version for each release, even if the module format has not
changed. [Though in reality the module format will most likely change
between all major releases anyway. However, this is probably not true
for minor (bugfix) releases.]

So, I would agree to bump the module version now from "6" to "4.6-0"
(or "4.6-6"?) and continue bumping whenever necessary (and only if the
format changes), using the scheme that Mikael proposed.

Another option would be to keep the module versioning as it is, and
just document somewhere in the wiki (or the manual), which gfortran
release produces which module version (do we have this info somewhere
already?).

Cheers,
Janus


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