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: [Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array


Dear Andre,

At the risk of being boring, I repeat what I said in my last email:  I
am coming to the conclusion that his patch for PR60255 and mine for
PR55901 should be committed and then I will develop the above
extension.

Note that I am not paid for doing gfortran work. Nonetheless, in
common with the other gfortran maintainers, I try the best that I can
to make the compiler as complete and as effective as possible.
Therefore it gets a bit on my goat when people do just enough to get
paid. I will however, do the commits for you.

Paul

On 14 January 2015 at 11:56, Andre Vehreschild <vehre@gmx.de> wrote:
> Hi Paul,
>
> I have trouble digesting your patch, because it conflicts with my additional
> ones. My intention was to split these issues into small manageable portions. I
> get the impression, that a small patch is more likely to be reviewed than a big
> one comprising multiple issues. Therefore I don't understand, why you joined
> the two prs 60255 and 55901. I would have appreciated it to have 60255
> committed as a basis for future development. Then let your changes go into a
> patch for 55901 and may be add a new pr for the outstanding issues we have
> not yet addressed.
>
> I know my patch for 60255 does not address all aspects of the overall topic.
> But hey, it's a step in the right direction.
>
> Regarding your comments on your patch check1101.diff:
>
>> trans-expr.c
>> TODO these three additions should be broken out into a function
>> for lines 328-337, 385-396, and 406-416.
>
> I do see this for the first and the last portion, but the middle one is
> addressing array's partially. The common code would be quite small, imho. Just
> the last three statements of each block. What would the benefit be? Or do you
> expect more code to be needed?
>
>> TODO gfc_trans_pointer_assignment should have the _len component set
>> for all allowed assignments, using this function
>
> Er, which cases aren't covered? I mean, _len is set to 0 by the initializer.
> For none char arrays _len is of no interest, because its value is not used and
> therefore 0 is a good value in there. From what I remember, did my patch cover
> all relevant paths. Did I oversee something?
>
>> trans-stmt.c: 770-780
> I have another patch for a similar code fixing pr61337. Unfortunately did I mix
> that one with several others, all of them addressing the allocatable deferred
> component issue. I am now torn whether I should split those patches up into the
> relevant portions to address each pr separately, or submit a "big" patch (500
> lines) for all of them. Any thoughts?
>
>
> Please understand me right: I am contracted to resolve certain issue preventing
> a certain code to be compiled by gfortran. From an economic point of view I
> can't spend too much time on fixing additional aspects, although I see the need.
> This is not to make money. It just to sustain my live, w/o money, no food, no
> gfortran fixes.
>
> Regards,
>         Andre
>
> --
> Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
> Tel.: +49 241 9291018 * Email: vehre@gmx.de



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx


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