This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran, OOP] PR 57305: ICE when calling SIZEOF on an unlimited polymorphic variable
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: Mikael Morin <mikael dot morin at sfr dot fr>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 26 Aug 2013 13:22:35 +0200
- Subject: Re: [Patch, Fortran, OOP] PR 57305: ICE when calling SIZEOF on an unlimited polymorphic variable
- Authentication-results: sourceware.org; auth=none
- References: <CAKwh3qi633jU-ojPKqRa_16DKWhXn9L2N0Wr4trAG9p1dJ-sXg at mail dot gmail dot com> <521686C0 dot 2030100 at sfr dot fr>
Hi Mikael,
>> the SIZEOF intrinsic currently returns the size according to the
>> *declared* type for polymorphic variables. I think this doesn't really
>> make much sense and it also causes ICEs when SIZEOF is called on
>> CLASS(*) variables (which don't really have a declared type).
>> Therefore I'm proposing to make SIZEOF return the size according to
>> the *dynamic* type instead. The same is done by STORAGE_SIZE (F08),
>> which however gives the size in bits. SIZEOF is a GNU extension, so we
>> are free to decide on its behavior. I don't remember why the declared
>> type was chosen in the first place, and I hope that no one seriously
>> depends on the current behavior (the size of the declared type is
>> probably not really useful after all).
>>
> I'm slightly inclined to kindly invite the user to switch to
> STORAGE_SIZE+SIZE instead. Any other opinion?
Since the SIZEOF intrinsic has been around for some time in gfortran
(before STORAGE_SIZE was available), I would say we should at least
continue to support it for backward compatibility. And I guess we
should also make it behave reasonably for all inputs. However, it
might be worth to add a note in the documentation that STORAGE_SIZE
and SIZE should be used instead in standard-conforming code.
>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
> Independently of the above, the patch seems to be forgetting the
> arg->rank != 0 case.
Right. Also I just noticed that STORAGE_SIZE does not seem to behave
correctly for class-array arguments, either ...
Cheers,
Janus