Loved The Compilation Of Your Resources

[Alexa Beckett via Fortran]

Hello,

My name is Alexa Beckett, a  Technical Instructor, and a regular reader of
your website.

I've been working on research for our  Technical Resources, I’ve been
following your site for quite some time and I really enjoy your resources –
especially the one you did on
http://fortranwiki.org/fortran/show/Fortran+Courses and I find it really
helpful!

I am contacting you because I think I could also offer something that might
be of interest and that you could use it as a resource for your site.
These are in-depth guides that I'm sure everyone will find useful.

EDUCBA  - This Free Software
Development Tutorial contains comprehensive information on Ethical
Hacking Tutorial, HTML Tutorial, Java Tutorial, Programming
Languages Tutorial, Python Tutorial, Installation of Software Tutorial,
HTMLTutorial, Network Security Tutorial, Careers, Ethical Hacking Tutorial,
SQL

*You may find free tutorials here:*

   - https://www.educba.com/tutorials/

If you consider these resources to be of value to readers and your
students, I would appreciate it if you could add it to your [
http://fortranwiki.org/fortran/show/Fortran+Courses] page or disclose it to
your readers at your own discretion.

I’m excited to hear back from you.

Thanks for taking the time to read this email. Above all, I hope you're
keeping safe?
*And If sent to the wrong contact, kindly redirect to the correct contact.*

Thanks & Regards,
Alexa
wallstreetmojo.com

Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test

[Tobias Burnus]

On 11.04.21 09:05, Paul Richard Thomas wrote:

Tobias noticed a major technical fault with the resubmission below: I
forgot to attach the patch :-(


LGTM. Plus as remarked in the first review: 'trans-expr_c' typo needs to
be fixed (ChangeLog).

Tobias



Please find it attached this time.

Paul

On Tue, 6 Apr 2021 at 18:08, Paul Richard Thomas
mailto:paul.richard.tho...@gmail.com>>
wrote:

Hi Tobias,

I believe that the attached fixes the problems that you found with
gfc_find_and_cut_at_last_class_ref.

I will test:
   type1%type%array_class2 → NULL is returned  (why?)
   class1%type%array_class2 → ts = class1 but array2_class is used
later on (ups!)
   class1%...%scalar_class2 → ts = class1 but scalar_class2 is used

The ChangeLogs remain the same, apart from the date.

Regtests OK on FC33/x86_64.

Paul


On Mon, 29 Mar 2021 at 14:58, Tobias Burnus
mailto:tob...@codesourcery.com>> wrote:

Hi all,

as preremark I want to note that the testcase class_assign_4.f90
was added for PR83118/PR96012 (fixes problems in handling
class objects, Dec 18, 2020)
and got revised for PR99124 (class defined operators, Feb 23,
2021).
Both patches were then also applied to GCC 9 and 10.

On 26.03.21 17:30, Paul Richard Thomas via Gcc-patches wrote:
> This patch comes in two versions: submit.diff with
Change.Logs or
> submit2.diff with Change2.Logs.
> The first fixes the problem by changing array temporaries
from class
> expressions into class temporaries. This permits the use of
> gfc_get_class_from_expr to obtain the vptr for these
temporaries and all
> the good things that come with that when handling dynamic
types. The second
> part of the fix is to use the array element length from the
class
> descriptor, when reallocating on assignment. This is needed
because the
> vptr is being set too early. I will set about trying to
track down why this
> is happening and fix it after release.
>
> The second version does the same as the first but puts in
place a load of
> tidying up that is permitted by the fix to class array
temporaries.

> I couldn't readily see how to prepare a testcase - ideas?
> Both regtest on FC33/x86_64. The first was tested by
Dominique (see the
> PR). OK for master?

Typo – underscore-'c' should be a dot-'c' – both changelog files

>   * trans-expr_c (gfc_trans_scalar_assign): Make use of
pre and

I think the second longer version is nicer in general, but at
least for
GCC 9/GCC10 the first version is simpler and, hence, less
error prone.

As you only ask about mainline, I would prefer the second one.

However, I am not happy about gfc_find_and_cut_at_last_class_ref:

> + of refs following. If ts is non-null the cut is at the
class entity
> + or component that is followed by an array reference, which
is not +
> an element. */ ... + + if (ts) + { + if (e->symtree + &&
> e->symtree->n.sym->ts.type == BT_CLASS) + *ts =
> &e->symtree->n.sym->ts; + else + *ts = NULL; + } + for (ref
= e->ref;
> ref; ref = ref->next) { + if (ts && ref->type ==
REF_COMPONENT + &&
> ref->u.c.component->ts.type == BT_CLASS + && ref->next &&
> ref->next->type == REF_COMPONENT + && strcmp
> (ref->next->u.c.component->name, "_data") == 0 + &&
ref->next->next +
> && ref->next->next->type == REF_ARRAY + &&
ref->next->next->u.ar.type
> != AR_ELEMENT) + { + *ts = &ref->u.c.component->ts; +
class_ref = ref;
> + break; + } + + if (ts && *ts == NULL) + return NULL; +
Namely, if there is:
   type1%array_class2 → array_class2 is used for 'ts' and
later (ok)
   type1%type%array_class2 → NULL is returned  (why?)
   class1%type%array_class2 → ts = class1 but array2_class is
used later on (ups!)
   class1%...%scalar_class2 → ts = class1 but scalar_class2 is
used
etc.

Thus this either needs to be cleaned up (separate 'ref' loop for
ts != NULL) – including the wording in the description which
tells what
happens if 'ts' is passed as arg but the expr has rank == 0 – and
what value is assigned to 'ts'. (You can then also fix
'class.c::' to
'class.c: ' in the description above the function.)

Alternatively, you can leave the current code ref handling
code in place
at build_class_array_ref, which might be the simpler alternative.

Otherwise, it looks sensible to me.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnul